Medium access technique for LAN systems

Present invention is concerned with regulation of access to the transmission capacity in a communication system comprising several nodes and a scheduler interconnected by a transmission medium in which transmitted information sequentialy passes the scheduler and nodes, such as in ring systems or recirculating bus systems. In particular, the invention is applicable to systems in which data are transmitted by insertion into time slots, and in which reservation for time slots is made upon previous request by nodes.

Such systems are known e.g. from European patent application No. 0'388'574 entitled "Method and Apparatus for Distributed Queue Multiple Acces in a Communication System" or European patent application No. 0'393'293 entitled "Method and Apparatus for Cyclic Reservation Multiple Access in a Communication System". The system described in EP-A-0'393'293 is a dual-bus system in which a reserve command is issued for each of several consecutive cycles by a header station, each node requiring access amends a reservation count in this command, and stores in a local queue the number of slots it requested for that cycle. The header station receives the total number of slots requested and checks whether this can be granted. If yes, it sends a confirm command to all nodes and enters the respective slot count (and cycle number) into a global queue. Later, it issues a corresponding number of slots after start of that cycle, and each node knowing how many slots it had reserved can use the respective number of free slots.

If the accumulated request arriving at the header cannot be granted, a general cancel command is issued so that nodes must also cancel the respective reservations. A partial or selective grant is not provided.

In such systems, techniques may be introduced to reuse slots when they have served the communication for which they were reserved, but the traffic situation and location of nodes will give them different opportunities to use this additional transmission capacity.

It would be desirable to have a reservation and grant mechanism which allows a node individual handling, which automatically adapts to the current traffic situation, and which requires a minimum of overhead.

It is an object of present invention to devise, for a communication system comprising several nodes and a scheduler interconnected by a sequential transmission medium, and in which data are transmitted in fixed-format time slots which can be either reserved or gratis, a slot reservation mechanism which allows node-individual handling and which ensures that all nodes get a fairly balanced chance to transmit, depending on their demands.

This object is achieved by a communication system as defined in claim 1, and by a method as defined in claim 3.

The invented system and method have the following advantages: Slot requests can be selectively granted on a node-individual basis, but the scheduler need not know the identities of the nodes involved. Available gratis slots can be used freely to allow maximum utilization of transmision capacity, but when slot reservations are requested by nodes, the previous transmission chances which any node had are considered in the grants. The scheduler needs not to collect and keep information on current source-destination patterns of traffic, but can rely on information received in the reserve commands. The reservation and confirm signaling needs a very low portion of the transmission capacity, and nodes do not have to make signaling information changes on the fly requiring immediate calculations, but only have to insert or remove reserve and confirm numbers.

These and other advantages will become apparent from an embodiment of the invention which is described in the following with reference to drawings.

Following drawings are provided: <dl id="dl0001"><dt><b>Fig. 1</b></dt><dd>is a schematic representation of the network structure and further shows, in connection with this structure, the path of a reserve and a confirm command;</dd><dt><b>Fig. 2</b></dt><dd>represents the basic slot format for data transmission in the network;</dd><dt><b>Fig. 3</b></dt><dd>shows details of the header of the slot format of Fig.2, including a control section with several fields for control information relevant for present invention;</dd><dt><b>Fig. 4</b></dt><dd>is a block diagram of the node structure provided in the communication system;</dd><dt><b>Fig. 5</b></dt><dd>illustrates the sequence of reserve commands, transmission slots, and confirm commands as they leave and enter the scheduler, and the length of a reservation round;</dd><dt><b>Fig. 6</b></dt><dd>(Figs. 6A and 6B) show the circulation of a reserve and confirm command and their modifications due to insertion and removal of information by the nodes;</dd><dt><b>Fig. 7</b></dt><dd>shows three counters provided in each node for executing the invention, and their input and output information;</dd><dt><b>Fig. 8</b></dt><dd>illustrates the calculation of confirm counts from received reserve counts and gratis counts, for the example of the reserve and confirm commands shown in Fig.6;</dd><dt><b>Fig. 9</b></dt><dd>shows an example of status modifications of a slot during its circulation around the ring; and</dd><dt><b>Fig. 10</b></dt><dd>(Figs. 10A, 10B, 10C) shows examples of slot status modifications during several circulations of one slot around the ring.</dd></dl>

DETAILED DESCRIPTION

<i>1) System, Data, and Node Structure</i>

An implementation of the invention is described in the following for a ring communication system whose structure is shown in Fig.1. The transmission medium is a closed unidirectional ring (11) to which several nodes or stations (13) which are numbered 1 through K are connected; furthermore, a scheduler S (15) is provided. It should be noted here already that the invention can also be used in other communication system configurations such as dual-bus systems or similar systems in which information which started at a scheduler or header station, after sequentially passing several nodes, can be recirculated (retransmitted) via a single bus to the initial scheduler (header).

The basic data transmission format on the transmission ring is a time slot having e.g. a structure as shown in Fig.2 and is called a basic slot (17). Each basic slot is a sequence of Atomic Data Units (ADUs). An ADU is the smallest unit of information which is handled as a whole. It may e.g. consist of 32 bits because the data path and logic units in the circuitry used in the system provide for the handling of 32 parallel bits.

The basic slot consists of e.g. 16 sequential ADUs which are arranged as a slot header comprising 2 ADUs (19, 21), a data payload comprising 13 ADUs (23), and a trailer consisting of 1 ADU (25). The header begins with the start delimiter and further contains various control information. The payload just carries the data to be transmitted by the slot. The trailer begins with the end delimiter and carries some further control information.

Fig. 3 shows some more detail of the control information carried in the slot header (first ADU). The first eight bits (27) are the start delimiter, as was already mentioned. Next, three bits (28) indicate the priority to allow the same types of operations and transmissions to be carried out separately for eight different priority classes. Three bits (29) indicate the slot type, i.e. whether the slot is for synchronous information, asynchronous information, etc. The next two 2-bit groups are not used in the present example. One bit (31) indicates whether the slot is RESERVED or GRATIS (to be explained later), a further bit (32) indicates whether the slot is BUSY or FREE (i.e. whether it carries valid data or not). Finally, there are a Monitor/Bus bit; a Synchronous-Transfer bit (33); and two bits for indicating first/middle/last/single slot position (for frames using several slots). The last eight bits are unused in present case. The most relevant control bits for the present invention are marked in Fig.3 by an asterisk.

The structure of the principal data paths in a node are illustrated in Fig.4. The node comprises input circuitry 41 and output circuitry 43 connecting it to the incoming and outgoing portions of the transmission ring 11. A control 45 evaluates incoming data and the current status of the node to generate control signals for the various portions of the data paths. Multiplexer (or switching) circuitry 47 selects one of plural data paths for transferring data to the transmission ring.

There are four principal path for the data. A direct path 49 allows to directly transfer incoming data to the output circuitry (e.g. for synchronous data). An insert buffer 51 is provided for temporarily storing arriving data which can be released later to the ring via path 53. Local data of the node which have to be transmitted and may be stored in several transmission (output) buffers can be selected by multiplexer circuitry 55 for transfer to the output multiplexer via path 57. Incoming data which are to be received by the node can be transferred via a path 59 through a demultiplexer (switching means) 61 to several buffers or local units in the node.

<i>2) Transmission Organization and Reservation Technique</i>

Fig.5 illustrates how slot reservation and slot marking by the scheduler are organized. (Cf. also Fig.1, right hand portion = A) Reserve and B) Confirm). Initially, the scheduler releases a Reserve command into which each node requiring slots for data transmission can enter its request (reservation). While the Reserve command circulates on the ring, the scheduler transmits gratis slots which can be used (if free) by any node without previous reservation. When the Reserve command returns to the scheduler, the information is evaluated to determine whether all or only a portion of the slot requests can be granted. Details will be described later. When the scheduler has finished its calculation, it releases a Confirm command to inform all nodes how many slots were granted and will be reserved for the requesting nodes. Immediately after the Confirm command, the scheduler starts to mark slots as reserved; the number of reserved slots corresponds to the total number of confirms given in the Confirm command. Each node will know, from the Confirm command, how many of the reserved slots it may use.

Because of the wrap-around effect in rings, the scheduler sees free gratis slots, busy gratis slots, and free reserved slots. All gratis slots (either free or busy) passing the scheduler are marked by the scheduler as reserved as long as reservations are required.

The scheduler maintains a "current length" count CL indicating how many reserved slots have still to be marked in the current round. The current length counter CL is decreased for every slot marked from gratis to reserved. Free reserved slots pass the scheduler without counter decrease. Free reserved slots arriving at the scheduler occur when busy reserved slots become free and only the upstream nodes (between scheduler and the node removing the slots) have confirmed reservations.

Thereafter, the scheduler sends out the next Reserve command. The interval between the issuance of two Reserve commands is called a "round". Rounds may be of different lengths, depending on the transmission demands of the nodes. No transmission capacity is wasted during the Reserve command circulation and during confirm calculation because of the transmission of gratis slots during that time. Though the issuance of a next Reserve command in present preferred embodiment is immediately after issuance of the necessary number of reserved slots, any other timing of the Reserve commands is of course possible, as will be explained in the last section (alternatives).

<i>3) Reserve / Confirm Command Insertion / Signalling</i>

Signalling, i.e. Reserve command transmission could be done in specific portions of each slot header, as was suggested in various previous systems. However, another technique is used in present embodiment. It is explained with reference to Fig.6. When the scheduler wants to issue a Reserve command, it releases a Start flag (Start-of-Reserve SOR) immediately followed by an End flag (End-of-Reserve EOR). These two flags are inserted in the data stream between two successive slots, as is shown in Fig.6 (buffer insertion technique). Each node desiring to reserve slots, waits for a SOR flag to come, and inserts its reserve field (RES) before the EOR flag. Thus, during its circulation, the Reserve command grows until it has accumulated all nodes' reserve, cf. Fig.6. Both flags and also each reserve field have exactly the size of one Atomic Data Unit ADU.

For granting reserved slots to the nodes, the scheduler will issue a Confirm command of exactly the same structure, i.e. having a start flag (SOC), several confirm fields (CON), and an end flag (EOC).

This signalling technique allows immediate insertion of signalling information whenever necessary, without wasting any transmisison capacity. It is termed "insert/remove signalling".

Details of Reserve command handling and transmission, and of Confirm command transmission are explained in the sequel with reference to Figs. 6A and 6B. Fig.6A shows the circulation and growing of one Reserve command. After the scheduler, there are only the Start and End flag SOR and EOR. Node 1 inserts its reservation (RES1) between the two flags, i.e. a "3" (the second number serves a purpose to be explained later). Node 2 which does not require transmission forwards the Reserve command unchanged. Node 3 inserts its reservation (RES3) for 4 slots between the last reserve field and the End flag. Finally, a node i inserts its reservation request (RESi) for 10 slots, and the scheduler receives the accumulate Reserve command train as shown in the bottom of Fig.6A. The scheduler knows how many slots each node has requested, and can determine the slots to be granted in the respective round. Details of the algorithm and of the "gratis" slot slot counts with each reserve field will be explained below.

The scheduler then isses a Confirm command which has the same structure and the same number of fields as the Reserve command: A start flag SOC, followed by several confirm fields CON1, CON3, CONi, and an End flag EOC. Each node which previously made a request now extracts the first confirm field from the command and stores the respective number (e.g. a 0 in node 1) and eliminates the respective confirm field from the command. The command diminishes during its circulation until only the Start and End flag return to the scheduler which will eliminate them.

This procedure allows a node-individual handling of requests and grants, without the necessity for the scheduler to identify the nodes involved. Thus, a fine tuning of traffic/grants and a fair handling of all nodes is possible.

Rules for insertion and remove operations in the reservation process

1) Scheduler sends Reserve command

The issued Reserve command consists initially only of two ADUs (start flag ADU, and end flag ADU). When they are inserted, two ADU's of the data stream must be stored (delayed) in an insertion buffer of the scheduler. From now on, the data path in the scheduler becomes longer by two ADUs until that buffer is emptied again.

2) Reserve command arrives at a node

Every node having requests will insert its reserve field ADU, requiring that one ADU from the data stream must be stored (delayed) in an insertion buffer of the node. Now, all data is delayed in that node by one ADU until the insertion buffer is emptied again.

3) Reserve command returns to scheduler

The scheduler receives the Reserve command and can eliminate from its insertion buffer two ADUs (caused by Start/End). All other Reservation ADUs travel further on the medium as idle ADUs (causing a temporary gap).

4) Scheduler issues the Confirm command

After processing of the Reserve command, which may take a time corresponding to several slots, the scheduler inserts the Confirm command, delaying incoming slot ADUs correspondingly in its insertion buffer. Apart from Start flag and End flag the amount of ADUs is the same as the gap of idle ADUs currently on the medium.

5) Confirm command arrives at a node

Every node which previously made a request removes its confirm field ADU and empties also its insertion buffer.

6) Gap of idle ADUs returns to scheduler

When the gap of idle ADUs (remainder of the circulated Reserve command) returns to the scheduler the corresponding number of ADUs contained in the insertion buffer (because of inserting the Confirm command) can be removed.

7) Confirm command arrives at scheduler

Finally, when the Confirm command returns to the scheduler it consists now only of two ADUs (Start and End flag), so that now the the last two ADUs in the insertion buffer of the scheduler can be removed. From this moment on, all ADU delays on the medium caused by the reservation process are eliminated.

<i>4) Special Fairness Technique</i>

According to present invention, a special technique for achieving fairness between nodes is employed. This is based on an evaluation of the gratis slots which a node has used in any round. As can be remembered, the scheduler transmits in each round a number of gratis slots which can be used by any node without reservation. The provision of gratis slots helps to improve system performance, but due to the fact that nodes immediately downstream of the destination nodes more often see gratis slots will introduce unfairness. An accounting of gratis slot usage is introduced by a special technique disclosed herewith for correcting this unfairness. The correction is done by taking into consideration the number of gratis slots a node could use during the previous (reservation) round. Depending on the current source-destination matrix, the nodes have different opportunities to use gratis slots. Therefore, only those nodes which have been penalized by a temporarily unfavorable position must be promoted to obtain their fair throughput share.

Fig. 7 shows three different counters which are provided in each node. There is a first counter 65 for a number NW, representing the number of slots which are waiting for transmission. Whenever there is a request in the node for transmission of a packet or message consisting of M slots, the respective number M is added to the contents of this counter. Whenever local data are transmitted in a slot, number NW is decreased by one. There is a second counter 67 for a number NC representing the number of confirmed slots. Whenever the active node receives a confirm field with a Confirm command (i.e. after it had made a reservation request), the number will be stored as NC in this counter. When the node makes a transmission in a reserved slot, it decreases the number NC by one unit. Another reason for decreasing this number is explained below. When a zero is stored in this counter, the node must not use any more reserved slots.

In case that a node still has confirmed reservations when the node has no more data to send, the node changes a free reserved slot into a free gratis slot and decreases its confirmed number of reservations NC by one. This happens when the node had used gratis slots to transmit all or part of its data.

An additional counter 69 stores a number NG, the count of gratis slots used. This will be utilized for the fairness procedure presently explained. The number is increased by one whenever the node uses a free gratis slot for data transmission. When a Reserve command arrives, the node inserts not only the number NW as reserve count NR for requesting the respective number of slots, but also the number NG as gratis slot count, thus admitting, simultaneously with requesting reserved slots, how many gratis slots it had used in the previous round. Contents of the NG counter is then reset to zero.

Both numbers, i.e. the reserve count and the gratis slot count, are inserted into the same reserve field (ADU) of the Reserve command, as is shown in Fig.6A. How the confirmation is computed from the information (numbers) received by the scheduler with the Reserve command, is disclosed in the next section.

Computation of Confirm Numbers

Fig. 8 schematically shows the computation of the slot grants, i.e. the confirm numbers, in the scheduler. Input data for this process are the reserve counts NR and the gratis slot counts NG received with the returning Reserve command, and a threshold value H. This threshold can be a fixed value or a value which is adapted in response to current traffic situations. It determines the maximum number of reserved slots that may be granted (confirmed) by the scheduler in a single round. For the present example, a threshold H = 8 slots is assumed. This number will of course be much higher in a system with hundreds of nodes.

For each involved node, i.e. for each reserve request received with the Reserve command, the scheduler establishes three counts including count values NR_i and NR_i as received, and a third count NC_i. Counts NR and NG are initially set to the respective received values, and count NC is reset to zero. Slot confirmations are determined in a step-by-step procedure, each step including the following operations: <ul id="ul0001" list-style="none" compact="compact"><li>A) Successively for each established count group (i.e. for the count groups of three nodes in present example): <ul id="ul0002" list-style="none" compact="compact"><li>1. Decrease count NG_i by one (if not yet zero);</li><li>2. If NG_i already zero, decrease NR_i by one (if not yet zero);</li><li>3. If NR_i was decreased by one, increase count NC_i by one (i.e. add one slot confirmation for node i).</li></ul></li><li>B) Commonly for all count groups involved: <ul id="ul0003" list-style="none" compact="compact"><li>1. Add the sum of slot confirmations of the respective step (i.e. the number of nodes for which one slot confirmation was made in part A of that step) to a common accumulated confirmation count NC_ACC).</li><li>2. Determine, whether NC_ACC &lt; THRESHOLD (i.e. whether total number of slot confirmations granted so far to the different nodes involved is still below threshold), and whether any NR_i &gt; 0 (i.e. whether there are still unconfirmed reservation requests). <ul id="ul0004" list-style="none" compact="compact"><li>• If true, perform another step with operations A1...A3 and B1...B2.</li><li>• If false (i.e. threshold already reached or all requests satisfied), shift the values of all NC_i counts into a FIFO register for subsequent insertion into a Confirm command.</li></ul></li></ul></li></ul>

To resume:

For calculating the confirm numbers, the scheduler applies a simple additive algorithm. Involved nodes get assigned slot confirmations in a stepwise manner whereby the sum of gratis slot count and reserve count for each node is decreased by one in each step (provided this sum is positive). As long as a node has a gratis part, its confirm number remains zero. Thus, confirm numbers only increase during decrement of the reserve part. A new assignment step is started if the sum of the granted reservations is below threshold H and some nodes still have reservation requests. (The values given in Fig. 8 correspond to the reserve/gratis counts of the example in Fig.6).

Principal Operation in the Scheduler:

In the scheduler an arriving Reserve command is input into a FIFO store. Every of its reserve fields (ADUs) is entered into a respective NR/NG counter pair. The end delimiter of the Reserve command indicates the end of all reservations and triggers the start of the calculation of confirm numbers which is performed as previously described. Confirm numbers NC for the individual nodes are transferred into an output FIFO and are finally returned to the nodes in a Confirm command.

<i>5) Operations on Slots and Slot Conversions in Nodes and Scheduler</i>

Depending on the status of a node (i.e. whether it has data waiting for transmission and whether it has a confirmed number of slots), and on the status of an arriving slot (gratis/reserved, busy/free) different operations on and conversions of a slot will occur. These various operations and their conditions are shown in Tables 1A...1C below. The tables also show the adaptation of counter contents after the respective operations. <tables id="tabl0001" num="0001"><table frame="all"><title>Table 1A</title><tgroup cols="2" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row><entry namest="col1" nameend="col2" align="left"><b>Slot type changes when slot becomes free</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">free slots</entry><entry namest="col2" nameend="col2" align="left">no operation</entry></row><row><entry namest="col1" nameend="col1" align="left">BG→FG</entry><entry namest="col2" nameend="col2" align="left">busy gratis becomes free gratis</entry></row><row><entry namest="col1" nameend="col1" align="left">BG_S→FG</entry><entry namest="col2" nameend="col2" align="left">busy gratis (synchronous) becomes free gratis</entry></row><row><entry namest="col1" nameend="col1" align="left">BR_i→FR_i</entry><entry namest="col2" nameend="col2" align="left">busy reserved (priority i) becomes free reserved (priority i)</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">BRT→FR_S</entry><entry namest="col2" nameend="col2" align="left">busy reserved with transfer becomes free reserved (synchronous)</entry></row></tbody></tgroup></table></tables><tables id="tabl0002" num="0002"><table frame="all"><title>Table 1B</title><tgroup cols="2" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row><entry namest="col1" nameend="col2" align="left"><b>Waiting for synchronous slot transmission</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">Busy slots</entry><entry namest="col2" nameend="col2" align="left">no operation</entry></row><row><entry namest="col1" nameend="col1" align="left">FR_S BG_S</entry><entry namest="col2" nameend="col2" align="left">access if NR_S&gt;0, with NR_S=NR_S-1</entry></row><row><entry namest="col1" nameend="col1" align="left">FG→BG_S</entry><entry namest="col2" nameend="col2" align="left">access, with NG_S=NG_S+1</entry></row></tbody></tgroup><tgroup cols="2" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row><entry namest="col1" nameend="col2" align="left"><b>Waiting for asynchronous slot transmission for priority i</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">Busy slots</entry><entry namest="col2" nameend="col2" align="left">no operation</entry></row><row><entry namest="col1" nameend="col1" align="left">FR_i→BG</entry><entry namest="col2" nameend="col2" align="left">access if NR_i&gt;0, with NR_i=NR_i-1</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">FG→BG</entry><entry namest="col2" nameend="col2" align="left">access, with NG_i=NG_i+1</entry></row></tbody></tgroup></table></tables><tables id="tabl0003" num="0003"><table frame="all"><title>Table 1C</title><tgroup cols="2" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row><entry namest="col1" nameend="col2" align="left"><b>Slot type changes at scheduler : synchronous slot marking</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">Reserved slots</entry><entry namest="col2" nameend="col2" align="left">No operation</entry></row><row><entry namest="col1" nameend="col1" /></row><row><entry namest="col1" nameend="col1" align="left">FG→FR_S</entry><entry namest="col2" nameend="col2" align="left">free gratis becomes free reserved (synchronous)</entry></row><row><entry namest="col1" nameend="col1" align="left">BG→BRT</entry><entry namest="col2" nameend="col2" align="left">busy gratis becomes busy reserved with synchronous-transfer bit set</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">BG_S→BR_S</entry><entry namest="col2" nameend="col2" align="left">busy gratis (synchronous) becomes busy reserved (synchronous)</entry></row><row><entry namest="col1" nameend="col2" align="left">"</entry></row></tbody></tgroup><tgroup cols="2" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row><entry namest="col1" nameend="col2" align="left"><b>Slot type changes at scheduler : asynchronous slot marking (priority i)</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">Reserved slots</entry><entry namest="col2" nameend="col2" align="left">No operation</entry></row><row><entry namest="col1" nameend="col1" /></row><row><entry namest="col1" nameend="col1" align="left">FG→FR_i</entry><entry namest="col2" nameend="col2" align="left">free gratis becomes free reserved (priority i)</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">BG→BR_i</entry><entry namest="col2" nameend="col2" align="left">busy gratis becomes busy reserved (priority i)</entry></row></tbody></tgroup></table></tables>

Following designations are used in these Tables 1A...1C and later in Figs.9 and 10A...10C: FR = Free Reserved, FG = Free Gratis; BR = Busy Reserved; BG = Busy Gratis. The index "i" indicates a respective priority level for the slot, and the index "s" indicates that the slot is only for synchronous traffic. The scheduler will mark its slot reservations respectively. Gratis slots are always asynchronous and have no priority indication.

The tables are self-explaining and can well be understood in connection with Figs.10A...10C and the explanation given in following section 6.

<i>6) Circulation of a Slot on the Ring and Possible Conversions</i>

Each individual slot, when travelling around the ring, can assume several states and can be converted many times. This is basically illustrated in Fig.9. A more detailed illustration of the conversions of a travelling slot is given in Figs.10A...10C.

Fig.9 shows a ring with a scheduler and six nodes N1...N6. Starting at a point marked by an asterisk, a free and gratis slot arrives at node N1. This has data to transmit and will use that slot, converting it to busy but leaving the gratis indication. When the slot passes the scheduler, it must be left busy (assuming the data it carries are destined for node N2 further downstream), but the scheduler, which still has to mark reserved slots for the current round, converts the slot to reserved (for later use by a node which had previously made a reservation which was confirmed). When the slot arrives at N2, data have reached their destination and the slot can be set free, but the reserved status will be kept. Thus, a free but reserved slot arrives at N3 which is assumed to have data for transmssion and to have still a confirmed slot number. When N3 uses the slot by entering its data, it converts the indications to busy and to gratis (because the confirmed reservation now has been served). Assuming the data were destined for N4, this node will receive them and set the slot to free (gratis remains). Then any node further downstream, e.g. node N5, can use it for transmission of data, setting the indicators to busy but leaving the slot gratis. When the data then reach their destination, e.g. at N6, the slot can again be converted to free and will also remain gratis.

This history of a slot shows that during a single circulation, one slot may carry independent data several times, e.g. from three sources to three destinations, despite the fact that it was reserved only for one of these transmissions. The additional transmissions in gratis slots are taken into account in the reservation process of the next round. This is the reason for the effective and fair operation of the system when present invention is used.

Figs.10A...10C each show several consecutive circulations of a slot around the ring with various conversions. The first Fig.10A shows the principles without considering several classes of slots (all slots being equal). Fig.10B shows the slot history when several different priorities are provided (each designated by "i"), where each priority has its own reservation mechanism. In Fig.10C, there is shown a slot history where slots can be designated as either asynchronous (traffic which can be delayed in insertion buffers) or synchronous (traffic which is directly forwarded in each node, cf. Fig.4 and respective text explaining the node structure).

The figures are time-space diagrams. For this example, it is assumed that the system has seven active nodes N1...N7, each represented by a horizontal line in the drawings. In each drawing, the history of a single slot is shown in several roundtrips each from the scheduler output around the ring back to the scheduler input. Each slot roundtrip is marked in the drawings by "RTn" for reference purposes.

1) Slot usage trace for slot reservations

Fig.10A illustrates the basic slot-type changes of a slot. Initially, a free gratis slot (FG) is considered. On its network roundtrip 1, the scheduler marks it free reserved (FR), and thus the slot becomes part of the reserved round. As it arrives at node 2 with confirmed reservations, the slot becomes busy gratis (BG). Now, on roundtrip 2 the scheduler marks it busy reserved (BR), so that as soon as the slot becomes free it is accessible only by nodes with reservations. Thus after being freed (at node 2), the slot is then of type free reserved (FR). Node 3 with confirmed reservations uses it and changes it again to busy gratis (BG). It becomes free gratis (FG) at destination node 4. Now two other nodes use the gratis slot consecutively and it passes the scheduler as busy gratis (BG). At the beginning of roundtrip 3 the slot is therefore marked busy reserved (BR) and then becomes free reserved (FR) at node 7 receiving the data. It passes the scheduler unchanged at the beginning of roundtrip 4 because it is reserved already. Node 2 which still has a confirmed reservation but no more data to send (because it had used a gratis slot) converts the slot from reserved (FR) to gratis (FG) so that it can be used by node 3 even if it had no more confirmed reservations. At the beginning of further roundtrips 5 and 6 (not shown), slots do not change their type at the scheduler because it is assumed here that the scheduler finished slot marking (i.e. current length counter CL = 0) and the Confirm command starting the next round has not been sent out yet.

2) Slot usage trace for priority slot reservations

In Fig.10B, the corresponding slot-type changes of a priority slot reservation is shown. It is the same example as in Fig.10B except that now the scheduler sets the priority number i into the slot when it marks a gratis slot as reserved.

3) Slot usage trace for synchronous slot reservations

Next, Fig.10C shows slot-type changes for synchronous slot reservations. Note that when the slot is of type synchronous it by-passes insertion buffers. Initially, the considered slot is free gratis (FG). At the begin of roundtrip 1, the scheduler marks it as free reserved synchronous (FR_S). When it is used by node 2 with reservations for synchronous slots the slot type changes to busy gratis synchronous BG_S. At the beginning of roundtrip 2, the scheduler makes it busy reserved synchronous BR_S. When the data arrive at their removal point (node 2) it is made free reserved synchronous FR_S. Then it is again used by node 3 having a synchronous reservation and converted to busy gratis synchronous BG_S and later changes (at node 4) to free gratis (FG). A node with asynchronous traffic demand makes it busy gratis (BG) and as it passes the scheduler at the beginning of roundtrip 3 the slot is marked as busy reserved with the synchronous-transfer bit set (BRT). This is done because the slot cannot be made synchronous immediately since otherwise it would start to by-pass the insertion buffers. However, when the asynchronous slot becomes free (at node 7), the node changes the slot-type to free reserved synchronous (FR_S).

Despite of the fact that a slot changes between several slot types (indicated by a free/busy bit, reserved/gratis bit, synchronous-transfer bit, asynchronous/synchronous bit, and three bits for priorities), the hardware implementation for slot-type changes are rather simple operations with a linear translation whereby a multiple-input type relates to single-output type.

<i>7) Alternatives</i>

In the above description, one specific and preferred embodiment was disclosed. For some of the features, alternative solutions or applications are possible. They will be briefly explained in this section.

7a) Other Mechanism to Transfer Reserve and Confirm Information

In the described embodiment, the transmission of Reserve and Confirm commands was achieved by a special signalling procedure using the insert and remove principle. This appears to be the most effective way of reservation signalling.

However, the signalling information to be transferred, i.e. the reserve counts and gratis slot counts from nodes to scheduler, and the confirm counts from scheduler to nodes, can be conveyed in another manner. One could use, e.g., regular slots payload of highest priority for reservation signaling. Also, a signalling section or field could be provided in each normal slot header, and the reservation information would have to be entered into a number of successive slots following the slot carrying the start-of-reserve flag (or start-of-confirm flag respectively).

7b) Dual Bus System / Folded Bus System

As was mentioned already, the invention cannot only be used in ring-structured communication systems, but also in any other system in which the information is transferred sequentially from node to node and then can return to the scheduler. Examples of such systems were described in above-mentioned European patent applications EP-A-0'388'574 and EP-A-0'393'293.

7c) Other Timing of Rounds

In the embodiment described, a new reserve command is issued as soon as the last slot marked reserved has left the scheduler, i.e. when the length count CL has become zero (assuming that then new reservations will be required anyway). However, other rules for issuing the reserve commands can well be used.

E.g., reserve commands could be issued at reguler intervals, which would mean however that possibly the current length count CL in the scheduler (which indicates how many reserved slots have still to be released because they were confirmed already) would not yet be zero in some instances. Thus, the fixed timing of reserve commands should be restricted to situations when the traffic volume is low. It would also be possible to vary this interval in dependence of the number of free gratis slots which pass the scheduler.

7d) Other Algorithms for Computing Confirmations

One algorithm for calculating the confirm counts in response to a received reserve command was explained in connection with Fig.8. There are of course numerous other possibilities to process the reserve counts and gratis counts for determining the confirm count for each node making a request.

An alternative method would be e.g. to determine the confirm count for each node in dependence of the ratio between the reserve count and the gratis count (thus admitting that a highly active node would be allowed to use relatively more gratis slot. Another possibility is to grant to each requesting node a minimum number of confirms and then deduct the gratis count from the remaining reserve count.

In any case, the availability of the gratis slot use count for each node demanding further slot grants, which is enabled by this invention, is a valuable input for any suitable confirm algorithm that might be selected.