AU784771B2 - An access process - Google Patents

Description

P/00/011 Regulation 3.2

AUSTRALIA

Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT

(ORIGINAL)

*i

.I

Name of Applicant: Actual Inventors: The University of Melbourne, of Grattan Street, Parkville, Victoria 3052, Australia Chuan Heng FOH Moshe ZUKERMAN DAVIES COLLISON CAVE, Patent Attorneys, of 1 Little Collins Street, Melbourne, Victoria 3000, Australia An access process Address for Service: Invention Title: Details of Associated Provisional Application: PR4113/01 The following statement is a full description of this invention, including the best method of performing it known to us:- P:\OPERDBWr41 13-0l.dc-28 March 2002 -1- AN ACCESS PROCESS FIELD OF THE INVENTION The present invention relates to an access process for communications networks, and in particular to a process for accessing a channel of a communications network.

BACKGROUND

A multiple access protocol specifies how a broadcast channel of a communications network is allocated to competing users who wish to send data on that channel. In the framework of the open systems interconnection (OSI) reference model for networks, 10 multiple access protocols are implemented in a sublayer known as the Medium Access Control (MAC) layer within the data link layer. Multiple access protocols are used in radio-frequency networks, such as cellular telecommunications networks, and also in local o.

area networks (LANs). The challenge in developing a MAC layer protocol for networks is to establish a simple and efficient protocol, and particularly to ensure that its efficiency is not degraded to an unacceptable degree as the number of users accessing the broadcast channel increases. A MAC layer protocol ideally minimises collisions between nodes Swhose broadcasts overlap, whilst maximising the amount of data transmitted on the channel. One method of reducing the probability of collisions is for each node to check that the channel is idle before attempting to transmit data on it. Such a protocol is known as a carrier sense protocol. The efficiency of the protocol may be further improved if the transmission is aborted as soon the transmitting node senses a collision. Such a protocol is known as carrier sense multiple access (CSMA) with carrier detect or CSMA/CD.

The IEEE 802.3 standard for Ethemrnet networks defines a version of this protocol.

Other protocols, such as IEEE 802.14, use an intelligent Central Controller (CC) to receive requests for bandwidth from a multiplicity of nodes. After receiving the requests, the CC transmits scheduling information to the nodes, which then transmit their data frames without collision. Other reservation protocols are based on a distributed control principle.

Examples are the IEEE 802.5 token ring and the IEEE 802.6 Distributed Queue Dual Bus P:%OPERDBW~pr41 13-0Idoc-28 Marh 2002 -2- (DQDB). These protocols achieve collision free transmission at the cost of node complexity.

The CSMA/CD protocol has been retained by the IEEE 802.3z working group as the MAC layer protocol for channel assignment in Gigabit Ethemrnet networks. However, collisions may not be detected by the transmitting node in a high-speed network if the frame transmission time is less than the propagation delay of the network. Due to the high data rate of these networks, to achieve backward compatibility and guarantee the proper operation of CSMA/CD, the IEEE 802.3z working group has introduced a carrier 10 extension operation. If a data frame is too short for collision detection purposes, nodes append predefined carrier signals to the short data frame for a period of time that is long enough for collision detection. Another modification to the protocol is the increase of slot g. time by almost an order of magnitude, from 512-bit time in 10/100 Mb/s Ethernet to 4096bit time for Gigabit Ethernet. Consequently, each collision in a Gigabit Ethemrnet network 15 results in a loss of 10 times more data than in 10 or 100Mb/s Ethernet networks. Moreover, the utilisation efficiency of this protocol degrades as the number of users attempting to access the broadcast channel increases. Furthermore, the IEEE 802.3z protocol does not support service differentiation, whereby different priorities may be assigned to different *.kinds of services. Service differentiation is important to ensure that delay-sensitive 20 services such as voice-over-IP and video-on-demand are not degraded as the network becomes more congested.

It is desired, therefore, to provide a process for accessing a channel of a communications network that alleviates the above difficulties, or provide at least a useful alternative to existing access processes.

SUMMARY OF THE INVENTION The present invention provides a process for accessing a channel of a communications network, said process executed by a node of said network, and including the steps of: generating request data; P:\OPERkDBW\29278-02 ,pe.doc-054/06 -3sending, to said channel, a request for access to said channel, said request including said request data and address data for said node; monitoring said channel for requests, including said request; selecting a request from said requests on the basis of request data of said requests; and accessing said channel if the address data of the selected request corresponds to said node.

The present invention also provides a process for operating a communications network having a repeater and a plurality of nodes, including the steps of:sending a request signal for channel access from one of said nodes to said repeater; sending said request signal from said repeater to each of said plurality of *o nodes, including the one node; and 15 receiving said request signal at said one node, and accessing said channel in Theo response thereto.

The present invention also provides a process for accessing a channel of a communications network having a repeater, including the steps of: 20 sending a request for access to said channel from a node of said network to said repeater; monitoring said channel for requests, including said request; and accessing said channel on the basis of said request.

accessing said channel on the basis of said request.

P:\OPERJDBW pr41 13-01.do-28 Marc 2002 -4- BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a schematic diagram of a preferred embodiment of a gigabit ethernet network; Figure 2 is a schematic diagram of a finite state machine representing an access process executed by nodes of the network; Figure 3 is a schematic diagram showing the structures of frames broadcast on the network; 10 Figure 4 is a schematic diagram showing the relative timing of events of the access "process; and Figure 5 is a graph showing the throughput of the access process and a prior art *O o IEEE 802.3z process as a function of the number of nodes in the network.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS o. 15 A Gigabit Ethernet local area network, as shown in Figure 1, includes nodes 4 to 18 arranged in a star configuration and interconnected by fiber optic cables 2. The nodes 4 to 18 comprise data terminal equipment (DTE) such as personal computers, network servers, and printers, each with at least one network interface controller (NIC) or transceiver, and may further include interfaces to other networks. Each of the cable segments 2 shown in Figure 1 comprises a pair of optical fibers, one for each signal direction. The network also includes a passive hub or repeater 20 that receives signals broadcast from nodes 4 to 18 on incoming fibers of the cables 2, and repeats them to the outgoing fibers of the cables 2. For example, the passive repeater 20 may be a 10Obase-FP star, such as a CodeStar passive hub manufactured by Data Base Access Systems, Inc. Due to the presence of the repeater the cables 2 constitute a single broadcast channel, because a signal sent by any one of the nodes 4 to 18 to the repeater 20 is retransmitted by the repeater 20 on all of the cables 2 and is received by all of the nodes 4 to 18, including the node that sent the signal. Access to the broadcast channel is determined by a request contention multiple access (RCMA) MAC layer process executed by each node 4 to 18 of the network, and described in detail below. In this context, access is for the purpose of transmitting user or system data and the P:\OPER)BV'pr4I3-0l.drc-28Marc, 2002 transmission of request data to the channel in order to request access to the channel is not itself regarded as access. It will be appreciated by the skilled addressee that the access process can be executed by a network interface controller of each node, either alone, or in conjunction with one or more other processors of the node, and that the RCMA process may be executed as software code, or by dedicated hardware circuits such as applicationspecific integrated circuits (ASICs), or a combination of each.

The RCMA process or protocol makes use of the return signals repeated by the passive optical repeater 20 to allow a transmitting node to verify if its earlier transmission was successful. To improve the efficiency of the protocol, RCMA uses a very small request frame for each node contending for the channel access right to reserve the channel for o longer data frame transmissions. The RCMA protocol is based on distributed control 4.

0 :principle, and achieves efficient scheduling and fairness with low overhead, intelligence S o.

and complexity. It is more efficient than the IEEE 802.3z MAC protocol, and unlike the 15 latter, the performance of RCMA remains stable as the number of nodes increases.

Furthermore, RCMA can easily support service differentiation. In the description below, the word "node" is used to refer to a network view of a node. For example, when it is said *O4 o that a "node" is "idle", this refers to a state of affairs wherein the NIC of the node is neither sending nor receiving data on the broadcast channel.

The nodes 4 to 18 of the network execute an RCMA process, as shown in the state diagram of Figure 2. Transitions between states S4 to S26 are indicated by state transition events El to E13 and give rise to timer events *S1 to *S3, as shown in Table 1, and described below P:\OPER\DBWkpr4I 13.0.do-28 Mah, 2002 -6- Table 1 State Transition Events Timer Events El: ready E2: busy channel detected *Sl: reset and activate RWTimer E3: RWTimer expired *S2: reset and activate RCTimer E4: transmission completed *S3: reset and activate ICTimer RCTimer expired E6a: all requests checked, the channel is assigned to this station E6b: the channel is not assigned to this station E7: maximum request retry reached E8: an interframe gap period detected E9: ICTimer expired data frame detected El1: NEXT frame detected E12a: NEXT frame checked, the channel is assigned to this station E12b: the channel is not assigned to this station El3: no data frame is waiting for transmission Initially, the network channel is idle, and a node 4 of the network is in an idle state S4.

When the node 4 is ready for a data transmission, it is referred to as a ready node, and it performs a request contention operation. The node 4 first prepares a request frame 22, as shown in Figure 3. The request frame 22 includes preamble bits 21, a 1-byte start control frame delimiter (SCFD) 23, a 1-byte request number a 6-byte source address (SA) 26, and a 1-byte short frame check sequence (SFCS) 28 for error detection. The node 4 randomly generates a 6-bit request number and stores it in the request number (RN) field 24 of the request frame 22. Its MAC address is stored in the source address (SA) field 26 of the request frame 22.

Once the request frame 22 has been prepared, the node 4 enters El a request waiting state S6 and activates Si a timer called the request-waiting timer, or RWTimer. The RWTimer value is set to w-Ts, where w is a uniformly distributed random integer between zero and k- 1, where k is a parameter of the protocol, and T, is the minislot time, which is the time required to transmit the request frame 22 plus a short guard time. The guard time is included to ensure that the minislot time is not less than the transmit time, for example, in case a node's clock is running slightly faster than those of other nodes. After activating S the RWTimer, the node 4 monitors its incoming optical fiber. Detection E2 of a request or data frame generated by another node during the timer period causes the node 4 to abort its P:\OPER)BW\pr4113-OI.doc.28 Marh 2002 -7pending request and enter a channel monitoring state S7. This is because if the channel carries a request frame that was transmitted earlier by another node, that node is given access priority, based on a 'first come first served' principle.

However, if the incoming channel remains idle when the RWTimer expires E3, the node 4 enters a request sending state S8, and transmits its request frame on the broadcast channel.

During transmission, the node 4 continues to monitor the incoming channel. If a carrier is detected on this channel, the request frame transmission is aborted immediately. The cables 2 of the network are long enough so that a request frame will not return back to the originating node whilst the latter is transmitting that request frame. However, request frame transmissions are subject to collisions. If two nodes transmit the request almost at the same time, so that the request frames meet at the passive repeater 20, these request frames are corrupted due to the overlapping signals. Otherwise, the request frames are considered successfully transmitted and can be read correctly.

The maximum signal propagation delay between the transmission and reception of a signal broadcast on the network cables 2, the time it takes a signal sent from a node at the end of the longest cable segment 2 to reach the repeater 20, be retransmitted back along the outgoing fiber of each cable segment 2, and reach the same node, has a value of t seconds.

i 20 However, in the preferred embodiment, the cable segments 2 are of equal length. After the very last bit of the request frame has been transmitted E4, the node 4 enters a request collecting state S 10, and activates S2 another timer called the request-collection timer, or RCTimer. This timer is set to 2r plus a short guard time. During this time interval, the node 4 monitors its incoming channel and collects any request frame, including its own request frame, transmitted earlier. Any incorrect or incomplete request frames are discarded. When RCTimer expires E5, the node 4 can be sure that all transmitted request frames have arrived and no further request frames are still propagating in the network. The node 4 then enters a request checking state S12, and compares all the received requests.

The request with the largest request number is the winning request. The node that originally sent the winning request is given the channel access right, and will henceforth be called the winner.

P:\OPER\DBW\pr4l 13-OI.do-2 Mach 2002 -8- All nodes contending for the channel access right, including the winner, can identify the winner by comparing the request numbers, and identifying the MAC address of the winning node from the source address field 26 of the request frame with the largest request number. It is possible that two or more nodes may choose the same request number. In this case, the node with the larger numerical MAC address is the winner. This does not affect the fairness significantly because this event is very rare.

The winning node now enters E6a a data frame sending state S 14, and sends its data frame on the outgoing fiber. The data frame structure used on the network is the IEEE 802.3 frame 30, as shown in Figure 3. Unlike CSMA/CD, no collision detection is required during data frame 30 transmission. Any other nodes who have pending requests enter E6b a request pending state S18, and when they detect E2 that the channel is busy, enter a channel monitoring state S7. Similarly, nodes with no data to send, and are in the idle state 15 S4, also detect E2 that the channel is busy, and also enter the channel monitoring state S7.

When nodes in this state S7 detect ElO the winning node's data frame 30, they enter a data frame receiving state S22.

*V

After the data frame has been sent and an interframe gap (IFG) period has passed, the SO- 20 winning node enters E4 a NEXT frame sending state S16, and the requesting nodes enter E8 a channeling monitoring state S24. The winning node constructs and transmits a control frame 32 referred to as a NEXT frame, as shown in Figure 3, containing a list 34 of request numbers and corresponding source addresses from the other access requests collected by the node during its request collecting state S10, sorted by request number. The list 34 is delimited at either end by a NEXT frame indicator byte (NFI) 25. After the NEXT frame 32 is transmitted E4, or if no NEXT frame 32 was transmitted because no other requests were collected, the winning node enters the idle state S4. If a NEXT frame 32 was sent, the remaining nodes with pending requests enter a non-contention channel assignment operation.

P:\OPER\DBW\r4 13-O41.dc-28 March, 2002 -9- When the pending nodes detect El1 the winning node's NEXT frame 32, they enter a NEXT frame checking state S26, in which each node compares its MAC address with the first MAC address 36 in the NEXT frame 32. The node whose MAC address matches the source address 36 in the NEXT frame 32 enters El2a the data frame sending state S14 and becomes the winning node, and the remaining nodes enter E12b the requestpending state S 18. The winning node sends its data frame, removes its record from the NEXT frame 32, transmits the modified NEXT frame 32, and enters the idle state S4.

When the last node in the list 34 in the NEXT frame 32 completes its data frame transmission, no NEXT frame is sent. After an IFG period has passed E8, nodes in the channel monitoring state S24 enter the request contention operation by returning to the request waiting state S6. Nodes without data to send return E13 to the idle state S4, and the entire process continues as described above.

15 If all the transmitted request frames 22 collide, no data frame 30 transmission will occur.

S After discovering that there is no data frame 30 transmission, all ready nodes immediately repeat the request contention operation to compete for the channel access right.

oOO•,e° S "Specifically, nodes whose pending request was aborted, and are in the channel monitoring state S7, will detect E8 an IFG, and enter the request pending state S18. Nodes who sent a 20 request frame 22 and are in the request checking state S 12 will also enter E6b the request pending state S 18.

An important aspect of RCMA is its implicit channel assignment property. If the assigned node fails to initiate its transmit, a deadlock situation could potentially occur. To avoid this problem, when the channel is assumed to be assigned to a winning node, each node in the request pending state S18 activates a timer called idle-channel timer, or ICTimer. The duration of this timer is greater than the duration of RCTimer. The ICTimer is reset if the incoming channel is sensed busy, and the nodes enter the channel monitoring state S7.

Otherwise, if the incoming channel remains idle after the ICTimer expires E9, the winning node forfeits its transmission right, and the nodes return to the request waiting state S6.

However, if the number of transmissions of a request frame from a node exceeds a P:\OPER\DBWVpr4113-01.doc-28 Mch. 2002 maximum attempt number, the channel access fails and the node returns E7 to the idle state S4. Each ready node then repeats the request contention operation to compete for the channel access right. Nodes without data to send return E13 to the idle state S4.

The timing of events in the RCMA process is illustrated in Figure 4. After a data frame is sent by a winning node, a period of the propagation delay r the IFG passes before every node has detected the end of the data frame transmission. If another IFG period passes without a NEXT frame being detected, a total time of r 2 IFG after the data frame is transmitted, the nodes detect 51 the end of all transmission for this cycle 48, and return 10 to the request waiting state S6.

In an alternative embodiment, the RCMA protocol described above is extended to support service differentiation by dividing possible request numbers into two or more groups, e.g., a higher group; and (ii) a lower group. A higher priority service may choose its request 15 number from the higher group to ensure that it will have the channel transmit right before a lower priority service, provided that its request frame is successfully transmitted. In another alternative embodiment, the performance of RCMA is improved by allowing the transmission of several data frames with one request, similar to the frame bursting operation in the IEEE 802.3z standard.

In one variant of Gigabit Ethernet, buffered distributors replace repeaters to achieve better performance, as described in J. Kadambi, I. Crayford and M. Kalkunte, "Gigabit Ethernet: Migrating to High-Bandwidth LANs," Prentice Hall, 1998. In a further alternative embodiment, the passive optical repeater 20 of the RCMA network is replaced by a buffered distributor without replacing RCMA transceivers in the network. As in Gigabit Ethernet, the buffered distributor acts as a central controller, collecting request frames and scheduling data frame transmissions according to the collected requests. However, the overhead of channel assignment in RCMA is lower than that of standard Gigabit Ethernet due to the non-contention channel assignment operation of RCMA.

P:\OPERDBWpr41 13-Ol.d-28 Marh, 2002 -11- For very high data rate LANs such as 10Gb/s'LANs, where the time required to transmit an IEEE 802.3 frame 30 becomes very short relative to the propagation delay, reserving the channel for such a short transmission may not be efficient. In yet another alternative embodiment, a small data frame is encapsulated within an RCMA request frame. If the request frame transmission does not collide with other request frames, then the data frame transmission is also collision-free. To support this feature, nodes exclude requests that contain data frames when comparing collected requests, because no further data transmission is required for those requests.

10 The performance of RCMA can be simulated and compared to the simulated performance of IEEE 802.3z. For example, consider a network of m nodes where the distance between any two nodes is the same, and each node is 'saturated', that is, it always has data to transmit. Consequently, the event El shown in Figure 2 occurs as soon as any node enters the idle state S4, and the node will therefore enter the request waiting state S6.

o Consider a realistic data frame size distribution, wherein 35% of the data frames 30 carry 46 bytes of useful information and the remaining 65% carry 1500 bytes of useful o• information, corresponding to the minimum and maximum sizes of IEEE 802.3 frames The RCMA channel is subject to a cyclic series of event periods, as shown in Figure 4.

S 20 Each cycle 48 has an I-period 40, an R-period 42, a C-period 44, and a D-period 46, representing idle, request transmission, request collection and data frame transmission periods respectively. The I-period 40 begins 51 as soon as the previous D-period 46 ends.

In the I-period 40, all ready nodes, including the node that transmitted a data frame, enter the request waiting state S6. A node in this state S6 transmits its request when its RWTimer expires. As soon as the first transmitted request frame appears on the channel, the I-period 40 ends and the R-period 42 begins. During the R-period 42, each node is not aware of request frames transmitted by other nodes, hence whenever any node's RWTimer expires, it transmits its request frame 22. When the first bit of the first request frame 22 reaches 52 all nodes, the R-period 42 ends, and the C-period 44 begins.

PAOPERkDBWpr4I3.O1.d.-28 M lh. 2002 -12- When the C-period 44 begins, no further request frames 22 are transmitted. During this period, each node that sent a request resets and starts its RCTimer and collects requests on the channel. When a node's RCTimer expires, it checks its collected requests to determine the winner. Any node that is not the winning node resets and starts 53 its ICTimer.

The winning node initiates 54 its data frame transmission. At some point 56 during this transmission, the ICTimers of the other nodes expire; these nodes detect the busy channel and do not attempt to access it. The C-period 44 ends when the winning node begins 54 its data frame transmission. Due to the non-contention channel assignment operation during the D-period 46, several data frames can be transmitted by the winning node. The D-period 10 46 ends when there is no NEXT frame transmission after a data frame transmission, as described above.

Let B be the data rate of the network. Given m saturated nodes, let the random variables I, R, C, D be the duration of the I-period 40, the R-period 42, the C-period 44 and the D- 15 period 46, respectively. Let the random variable U be the duration of the actual data transmission, excluding all IEEE 802.3 frame overheads during a cycle 48, and the random variable H be the duration of the overhead transmission such that D=H+U. Then the RCMA saturation throughput for m saturated nodes, SRCMA, can be expressed by:

E[U]

SRCMA E[I+R+C+H+U] (1) where E[ represents the average value of the parameter within the square parentheses. As described above, RWTimer=w-.T, where w is a uniformly distributed random integer between zero and k-1, and T, is the minislot time duration. The I-period 40 ends when at least one request frame 22 appears on the channel. Hence the probability that the I-period lasts for x minislots is the probability that any of the m nodes choose to transmit their request frames given that no request frame transmission appears in previous minislots. The probability distribution function (PDF) of is thus: x ,x=Q ,i=X P{I =x.Tq x=k 0 ,x=k P:\OPER\DBWpr4113-01.doc-28 March 2002 -13where qx 1 is the probability that any of the m nodes chooses to transmit its request frame after x idle minislots.

For the R-period 42, since the distance between any two nodes is fixed, the duration for a signal to propagate from any node to all nodes is constant. Thus: R= (3) When the R-period 42 ends, no further request frames are transmitted. Since the R-period 42 is constant, then the number of minislots, r, within the R-period 42 is also a constant, 10 and is given by: r (4) 9 The duration of the C-period 44 depends on the position of the winner within the r 0@SS minislots. If k<r, then the winner will appear within the k minislots instead. Recall that the 15 winner is determined from the request numbers of all the successful requests. Since the request number is randomly and uniformly chosen between zero and k-1 by each node, hence if there is at least one successful request during the R-period 42, the probability that the winner will appear at the xth minislot in the R-period 42, making the C-period 44 to be o. (r+x.Ts) unit of time, is similar, except when the winner appears at the first minislot in the R-period 42. This is because if the winner does not appear at the first minislot in the Rperiod 42, the first minislot is not idle. Thus the possibility that no nodes pick the first minislot, causing the first minislot to be idle, is excluded if the winner does not appear at the first minislot in the R-period 42. With this condition, the PDF of the C-period 44 is approximately: ,=1 PC=xT,+r)= a- x n where n min(r, k) where a can be obtained by summing up the probability for and equating the sum to unity.

the sum to unity.

P:\OPER\DB\pr4113.0 Ido.-28 Makh 2002 -14- Given m saturated nodes, r minislots and the k parameter, the PDF of the number of request frames successfully detected by all nodes during the R-period 42, N, can be derived recursively to be: P{N Nb r,k, m) x=0,1, ,Ir (6) Na m) where N, r, k, m) (MJN, r, k 1, m) (M)N IN(x 1, r 1, k 1, m 1 (J)NC(x, r-1, k-i, m -n N r, (mJNC r 1, k-i1, m) +IIN,(x ,r -1,k ,m 00* IJN,(x,r ,k ,m -n .0.N 0 m)=km with (M and the following initial conditions: n!Qnm- n!) Nb(x =0; Nb 0, r,k 1, m= 0) 0 0Nb(x k=1, m =1)=0;Nb(x k =1,m 1) =1; ~Nb(x k 1, m Nb 1, r, k= 1, m )=1;Nb (x r, k= 1,m Nb(x !2,r,k 1,m=0)=0;Nb(X>!2,r k=1 m)=0; and N,(x 0; N, (x k m=0) 1; N, 0, r, k= 1, m= 0; N(x=0, r, k m 1)=1; N,(x ,r 0; N, r, k m=0) =0; N, (x r, k m= 1; N(x= 1, r, k= 1, m N,(x !2,r

N

0 (x !2,r,k k P:\OPERUDBWpr4113-01.doc.28 March 2002 where Nc(x,r,k,m) is the total number of possible permutations, that x out of r minislots will carry successful requests, given m and k. Nb(x,r,k,m) is similar to Nc(x,r,k,m) but Nb(x,r,k,m) is the number of possible permutations under the assumption that no idle slot appears in any of the previous minislots. Na(k,m) is the total number of possible permutations given m and k.

The duration of the D-period 46 depends on the number of successful requests that appear in the R-period given in Equation 6. If there were no successful requests, all ready nodes will enter the request pending state S18 due to events E6b and E8. Not all nodes discover the failure of channel assignment at the same time, but the difference between the time each node enters the request pending state S18 is insignificant. Therefore, all nodes may be considered to return to the request pending state S 18 at the same time after the C-period 44 ends. In the case where there is no winner, if ICTimer lasts for 2x, then it will take a duration of 2r before this cycle 48 ends. With this assumption, the relationship between the 15 number of successful requests, N, obtained in Equation 6, and the duration of the D-period 46 is: 2 T

N

0 SE[TFRAME] T 2- TF G N D= (E[TFRA]+ TF TNT(i)+) (7) E[TFRE]+T TFo ,N with 8-(10+7i)/B, and where TFRAME, TNEXT and TIFG are the transmission time of the IEEE 802.3 frame, the NEXT frame, and the IFG duration, respectively. Knowing the distribution of a data frame, the mean of D can be computed.

The time duration of useful information transmitted during a cycle 48, U, also depends on N in Equation 6, and may be expressed as U N E[T, N r (8) where Tu is the transmission time of the useful information. Having obtained the PDF of I, R, C, D, and U, their mean values can be computed, as well as the saturation throughput of RCMA given in Equation 1.

P:\OPER\DBW\pr41 3-01.doc-28 Maeh, 2002 -16- The saturation throughput of Ethernet has been determined in C. Foh and M. Zukerman, "Performance Comparison of CSMA/RI and CSMA/CD with BEB," to appear in Proceedings of IEEE ICC 2001 Some modifications of the calculations in this paper are made below to include the carrier extension operation of Gigabit Ethernet.

From Foh, the saturation throughput of IEEE 802.3z, SCSMA, is: E[UCv] s HE[+csM (9) cs E[Ics Ccs Hc +U csm where the random variables ICSMA, CCSMA, HcsMA, UCSMA are the idle, contention, overhead transmission, and useful information transmission periods respectively in CSMA/CD. Let 10 DCSMA be the frame transmission period including the overhead, thus DCSMA=HCSMA+UCSMA.

By Foh: 0* E[Ic ]=0 E[CcsMA Lm 1) TSCSMA where Lm is the mean number of slots required to resolve a collision caused by m nodes and to obtain a successful transmission in CSMA/CD, and TSCSMA is the slot time.

15 The mean values of DCSMA and UCSMA are: E[DcM E[TFRAME]+E[TcAuwER+TIFG

T

11) E[UcA] where TIFG, TCARRIER, TFRAME and T, are the duration of the IFG, the duration of carrier extension, the IEEE 802.3 frame transmission time, and the useful information transmission time, respectively. By substituting Equations 10 and 11 into Equation 9, the saturation throughput of the IEEE 802.3z Gigabit Ethernet MAC protocol can be obtained.

The saturation throughputs of RCMA and IEEE 802.3z at 1Gb/s can be compared, using parameters from IEEE 802.3/ISO 8802-3, "Information processing systems Local area networks Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications, 2nd edition," September 21, 1990, and (ii) J. Kadambi, I. Crayford and M. Kalkunte, "Gigabit Ethernet: Migrating to High- Bandwidth LANs," Prentice Hall, 1998, as shown in Table 2, for numerical computations and simulations.

PA\OPER\DBWpr4130I.doc-28 Mard, 2002 -17- Table 2 Parameters Values Data rate, B 1Gb/s node numbers, m Propagation delay, r 2tsec IEEE 802.3 frame overhead including preamble and SFD 0.208psec (26 bytes) Useful transmission duration for a short IEEE 802.3 frame 0.386gsec (46 bytes) Useful transmission duration for a long IEEE 802.3 frame 12psec IFG time duration, TIFG 0.049pisec Slot time in IEEE 802.3z, TSCSMA 4.096isec minislot time duration in RCMA, Ts 0.128psec (16 bytes) minislot numbers in RCMA, r Parameter k for RCMA r In addition, 35% of the data frames 30 are taken to be short frames, with the remaining 65% being long frames. The mean data frame transmission time and the useful information transmission time for RCMA and IEEE 802.3z are shown in Table 3. In IEEE 802.3z, if the data frame transmission duration (excluding preamble bits and start frame delimiter (SFD)) is less than a slot time, the transmission will be extended with carriers until the duration of a slot time is reached. E[TCARRIER] represents the average time wasted due to carrier extension for each data frame transmission with the assumed data frame distribution.

Table 3 Mean frame transmission time, E[TFRAME] 8.1368 psec Mean useful information transmission time, 7.9288 psec Mean duration of carrier extension in IEEE 802.3z, E[TCARRIER] 1.2544 [sec The saturation throughput 60 of RCMA and the saturation throughput 62 of IEEE 802.3z are shown in Figure 5. Analytical and simulation results are shown with solid lines and symbols respectively. The saturation throughput 62 of IEEE 802.3z drops significantly when the number of saturated nodes increased from one to five, and continues to drop as the number of saturated nodes increases: The throughput 62 even drops below 10% when P:XOPERODBVWpr4113-O0.doc-28 Mah. 2002 -18 there are over 32 saturated nodes sharing the 1Gb/s bandwidth. That is, each saturated node only receives around 3.125Mb/s bandwidth on average under these conditions.

In contrast, the saturation throughput 60 of RCMA is stable, and offers over efficiency for up to 50 nodes, except when there are fewer than three saturated nodes. This is because when the number of saturated nodes is low, the channel assignment overhead for each data frame transmission is slightly higher due to the need for requests prior to data frame transmission. However, as the number of saturated nodes increases, the noncontention channel assignment operation of RCMA becomes effective, more data frame transmissions can be assigned during a request contention period, and therefore the channel assignment overhead for each data frame transmission becomes relatively small. In the S. case of 32 saturated nodes, RCMA achieves around 70% throughput, which is equivalent to a 21.875 Mb/s bandwidth for each node on average, seven times higher than that in the IEEE 802.3z protocol.

The IEEE 802.3z protocol performs better than RCMA only when there is exactly one saturated node in the network. In this case, no collisions occur in the IEEE 802.3z protocol.

As the number of saturated nodes increases, collisions become more likely, and the throughput of the IEEE 802.3z MAC protocol drops significantly.

S"Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

P:\OPER\DBW\pr4113-01.doc-28 Mach 2002 -19- The reference to any prior art in this specification is not, and should not be taken as, an acknowledgment or any form of suggestion that that prior art forms part of the common general knowledge in Australia.

We a e oo

Claims (29)

1. A process for accessing a channel of a communications network, said process executed by a node of said network, and including the steps of: generating request data; sending, to said channel, a request for access to said channel, said request including said request data and address data for said node; monitoring said channel for requests, including said request; selecting a request from said requests on the basis of request data of said requests; and accessing said channel if the address data of the selected request corresponds to said node. S-2. A process as claimed in claim 1, wherein said step of generating includes generating random request data.

3. A process as claimed in claim 2, wherein said random request data includes a random request number.

4. A process as claimed in claim 1, including, before step the step of monitoring S"said channel for request data sent by other nodes, and executing step only if request data is not detected. A process as claimed in claim 4, wherein the monitoring step is performed over a randomly determined period of time, said period being an integer multiple of a minislot time, wherein said minislot time is substantially equal to the time required to send a request.

6. A process as claimed in claim 1, wherein step includes simultaneously monitoring said channel for request data broadcast by other nodes, and aborting said step if said request data is detected. P:\OPERDB\V\pl4 13-0I.dmc28 March. 2002 -21-

7. A process as claimed in claim 1, wherein if step fails to detect any requests, said process returns to step

8. A process as claimed in claim 1, wherein said monitoring step is performed over a monitoring period of time at least twice as long as the maximum propagation delay of said network.

9. A process as claimed in claim 3, wherein said selecting step includes selecting a request with the greatest request number.

10. A process as claimed in claim 9, wherein if two or more requests share the same greatest request number, a request is chosen from said two or more requests on the basis of address data of said two or more requests.

11. A process as claimed in claim 1, wherein said address data includes a MAC address of said node.

12. A process as claimed in claim 3, including, after step a further step of sending 20 said requests except for said selected request. a

13. A process as claimed in claim 12, wherein the sent requests are sorted by request number and are sent in a control frame.

14. A process as claimed in claim 8, including, after step the further steps of: monitoring said channel for data sent by another node of said network; and returning to step if no data is detected. A process as claimed in claim 1, wherein said monitoring step is performed over a period of time exceeding said monitoring period. P:\OPER\DB Wpr4I 134)I.doc-28 rMah. 2002 22

16. A process as claimed in claim 1, including, after step the further steps of: monitoring said channel for data sent by another node of said network; incrementing a request counter; and returning to step if no data was detected and if the value of said request counter is less than a predetermined maximum request count value.

17. A process as claimed in claim 1, including the further steps of: monitoring said channel for a control frame containing at least one request; returning to step if no control frame is detected; selecting a request from said control frame; returning to step (e)

18. A process as claimed in claim 17, wherein said monitoring step is performed for a period substantially equal to an inter-frame gap of said network. .o

19. A process as claimed in claim 17, wherein said selecting step selects the first request of said control frame. A process as claimed in claim 1, wherein said generating step includes generating request data on the basis of at least one of a priority of said node and a priority of user data to be sent during said access step

21. A process as claimed in claim 20, wherein said request data includes a randomly generated number within a range of values corresponding to said priority.

22. A process for operating a communications network having a repeater and a plurality of nodes, including the steps of: sending a request signal for channel access from one of said nodes to said repeater; sending said request signal from said repeater to each of said plurality of nodes, including the one node; and PAOPER\DBWpr4II 3-0Idoc-2 Mrh. 2002 23 receiving said request signal at said one node, and accessing said channel in response thereto.

23. A process as claimed in claim 22, wherein said process may also include the step of checking the integrity of said signal.

24. A process as claimed in claim 23, wherein the length of the request signal is short relative to the length of a data transmission signal.

25. A process for accessing a channel of a communications network having a repeater, including the steps of: sending a request for access to said channel from a node of said network to said repeater; monitoring said channel for requests, including said request; and accessing said channel on the basis of said request.

26. A process as claimed in claim 25, including the additional step of sending said request from said repeater to each of said plurality of nodes, including said one node. 20 27. A process as claimed in claim 1, including, after step the step of checking the integrity of said request.

28. A network node having components for executing the steps of any one of claims 1 to 27.

29. A network transceiver having components for executing the steps of any one of claims 1 to 27. A communications network, including a plurality of nodes having components for executing the steps of any one of claims 1 to 27. P:\OPER\DBW29278-02 spc.doc-05406 -24-

31. A computer readable storage medium, having stored thereon program code for executing the steps of any one of claims 1 to 27.

32. A process for accessing a channel of a communications network, substantially as herein described with reference to the accompanying drawings.

33. A process for operating a communications network, substantially as herein described with reference to the accompanying drawings.

34. A network node, substantially as herein described with reference to the accompanying drawings. A transceiver, substantially as herein described with reference to the accompanying drawings.

36. A communications network, substantially as herein described with reference to the accompanying drawings. DATED this 5th day of April 2006 THE UNIVERSITY OF MELBOURNE By its Patent Attorneys DAVIES COLLISON CAVE