The invention relates to TDMA (Time Division Multiple Access) ad hoc radio networks. It is aimed, more particularly, at the allocation of the slots between the various nodes of the network and the capacity for reserving resources including constraints on throughput and end-to-end latency.
It applies, also, in TDMA multi-channel systems (for example T/FDMA for Time and Frequency Division Multiple Access), radio networks using OFDMA (Orthogonal Frequency Division Multiple Access) modulation and any other system, which uses time slots and a dynamic allocation scheme instead of a fixed allocation scheme.
TDMA radio networks generally use static allocations. The allocation is either completely fixed (cyclic frame with one slot per node), or defined in advance for a configuration.
The new radio systems are beginning to give consideration to quality of service, but this consideration does not yet make it possible to support the global reservation of resources with end-to-end service guarantee (in terms of throughput and latency), in particular the IP (Internet Protocol) based service guarantee protocols, such as the RSVP (standing for Reservation Protocol) resource reservation protocol.
Another drawback of the prior art is its inability to avoid saturation of the heavily worked nodes, even if the other nodes of the network possess unused and available resources.
As regards the allocation of resources, current TDMA radio systems do not support the reservation of resources and the network may not guarantee both minimum throughput and maximum end-to-end latency.
The invention relates to a medium access control MAC level method allowing the dynamic allocation of the resource slots with a service guarantee. Two types of traffic are distinguished: elastic traffic and session traffic. The session traffic corresponds to continuous multimedia streams (voice and video) and time-real data streams for which a strong service guarantee (throughput and latency) is desired.
The invention makes it possible, on the one hand, to receive and to process resource reservation requests for session streams originating from the higher layers (IP layer typically). These reservation requests include the constraints of minimum throughput, but also of maximum packet transmission deadline (over a hop). They are typically formulated by a global reservation process, such as the RSVP over IP protocol, making it possible to dissect global constraints of guaranteed minimum throughput and of maximum end-to-end latency into local throughput constraints for known application stream characteristics associated with a maximum packet transmission deadline, at the level of each of the nodes of the path.
The invention makes it possible, on the other hand, to carry out dynamic allocations of session slots in a local manner, that is to say without recourse to centralized management, during normal operation. The method according to the invention relies, notably, on explicit allotting of the session slots to one or more nodes and on a concept of reserving these slots. A slot allotted to a node can be freely reserved by this node so as to satisfy a resources reservation request. Viewed from a given node, the set of unreserved session slots forms a group or pool of resources from which it can potentially draw.
In a first step, the node which receives a reservation request will formulate a configuration for reserving session slots. A resources allocation algorithm will then select slots from this pool in such a way that the reservation configuration satisfies the constraints while favoring its own slots. A node which does not have sufficient inherent resources to satisfy the reservation request, will formulate a reservation configuration by using the session slot pool involving its own session slots to the maximum, but also session slots of the pool which are not allotted to it.
In a second step, the allocation is negotiated with the neighboring nodes, while taking account of the slots used by the neighbors (effective sharing of a resource) but also, of the potential interference situations relating to the spatial reuse of the slot in space (spatial reuse of a resource). The management of such interference therefore allows the spatial reuse of the session slots, thus allowing scaling, as a function of the number of nodes of the network.
Additionally, a switch to the MAC level (relaying) can be performed on the session streams so as to reduce the transit time in each node, avoid going to the higher layer (IP typically) and guarantee low jitter by maintaining an MAC path for the session by carrying out “route pinning” at the MAC level.
The invention relates to a method for reserving resources with service guarantee in terms of throughput and deadline at the level of the N nodes of a radio network using time slots to send and transmit data, characterized in that it implements a global reservation process in which a reservation message sent uses at least one of the following two parameters: the maximum deadline required to access the radio medium and/or the minimum throughput required in order to satisfy the service guarantee.
The subject of the invention relates to a method of resource reservation with service guarantee in terms of throughput and deadline at the level of the N nodes of a radio network using time slots to send and transmit data, characterized in that it implements a global reservation process in which, a reservation message sent uses at least one of the following two parameters: the maximum deadline required to access the radio medium, the minimum throughput required in order to satisfy the service guarantee.
It implements, for example, a dynamic time slot allocation scheme defined in the following manner: the N nodes each comprising K slots, including a control slot, P elastic slots and (K-1-P) session slots, the (K-1-P) session slots are amalgamated for the allocation of resources required by a node at a given instant.
The method and the system according to the invention offer notably the following advantages:
Other characteristics and advantages of the present invention will be more apparent on reading the description which follows and an example given by way of wholly nonlimiting illustration, in conjunction with the figures which represent:
In order to better elucidate the principle implemented in the method according to the invention, the description is given by way of wholly nonlimiting illustration, for a TDMA ad hoc radio network in which all the nodes are autonomous and play one and the same role. For this purpose, they are each equipped with a processor suitable for implementing the steps of the method according to the invention. They are also provided with radio means, sender and receiver, making it possible to transmit and to receive the messages transmitted to other nodes or originating from these other nodes. Each node comprises, as is detailed hereinafter, several tables: a DRAM table containing the information relating to the nodes, a table of visibility of the other nodes, a status table, a time slot table, etc. A few reminders and definitions are given as a preamble to the description of the method and of the system according to the invention.
Terminology
The architecture of a radio frame is made up of four layered elements in which the useful data will be conveyed:
MAC Packet
The MAC packet is an elementary data structure at the MAC level. NPS is the number of MAC packets that a node can transmit in a time slot.
Time Slot and Basic Frame
The basic frame and the “slots” are illustrated in
Cn: control slot for node n
Dn: slot allotted to node n
Ts: duration of the slot
K: number of slots making up the basic frame
TBF: duration of the basic frame with TBF=K*Ts
Each basic frame relates to a specific node. The example illustrated in
The slot Dni (where i=1 . . . K−1) represents one of the K-1 slots allotted, a priori, to node n. This node n can use this slot to transmit its own data or can lend this slot to another node, by implementing the steps of the method according to the invention. This implies that, in relation to
The slots can be divided into two classes:
Frame
Each node is responsible for managing its own basic frame (on initializing the method, the basic frame defines notably the allotted slots). The sequence of the basic frames for the set of nodes of the network makes up the frame. If the network is formed of N nodes, the frame structure is, for example, that which is represented in
BFn corresponds to the basic frame managed by node n; K the number of slots making up a basic frame; TF the duration of the frame, with TF=N*TBF=N*K*Ts.
The period of a frame depends on the parameters K number of slots making up a basic frame, and N, the number of nodes making up the network.
Slot Management and Resource Reservation Request
Each node can potentially use any session slot of the pool, although the control slot and the elastic slots are definitively allocated to a node.
In the presence of a new session, the MAC layer receives a resource reservation request together with a minimum throughput constraint and with a maximum radio access deadline constraint.
Each slot is characterized by an associated elementary throughput. A node n can thus evaluate the number of slots which it requires in order to satisfy the reservation request in terms of throughput based on the elementary throughput offered by a slot.
In relation to the requirements of the applications, the higher layer can request an increase or a decrease in the occupancy of the MAC layer by way of resource reservation requests. It is the MAC layer which carries out the actual allocation of the resources corresponding to a resource reservation request for a session. This MAC layer decides how many session slots are necessary in order to satisfy the resource reservation request and commences inherent procedures to establish which slots in the frame will be used, and more particularly which MAC packets are reserved.
Interleaving Method
In order to make the radio access time homogeneous and minimal for all the nodes, it is possible to interleave the slots. An inherent interleaving algorithm is used by each of the nodes to define the real-time sequence of the slots.
Allocation of the Session Slots
Upon a request to reserve resources for a new session, a resource allocation algorithm formulates a configuration for reserving session slots, and more particularly MAC packets (belonging to the session slots).
Several constraints are taken into account at the level of this algorithm:
Moreover, the method according to the invention can implement an optimization algorithm which makes it possible to increase the transmission capacity of a node by using notions of reuse of resources, spatial reuse of slots.
If node A (zone 1) and a node of zone 3, for example node G (zone 3), transmit packets in the same slot, there is no collision on this slot, since the addressees of node A for this slot are not in range of the other nodes of zone 3, such as G, which use this slot. For the same reason, node A and another node situated in zone 3 can reuse the same slot.
Conversely, if node A (zone 1) and node F (zone 2) use the same slot, node C and node D cannot receive the set of packets transmitted in this slot because of the collision.
To summarize, the nodes fewer than 2 hops away cannot use one and the same slot, but conversely, a slot can be spatially reused beyond 3 hops. On this base, the method will formulate at the level of each node, a knowledge of the allocation of the slots over a horizon of two nodes, thereby making it possible, on the one hand, to negotiate the slot loan locally and, on the other hand, to spatially reuse the slots.
Each node thus stores its knowledge of the slots used by the nodes which are one or two hops away in a DRAM table.
For maximum avoidance of reservation conflicts, before using slots managed by other nodes, a node must verify its DRAM table and propagate its content to all the nodes which are one hop and two hops away. This information is dispatched by way of dedicated messages.
DRAM Table
The dynamic resource allocation mechanism is based on an exchange of information performed by virtue of the MAC control packets conveyed in the control slots CTRL. For this purpose, a DRAM table stores:
In the DRAM table of a node, only the information relating to the nodes which are one or two hops away is stored. For the other nodes, more than two hops away, the node has no visibility. All the nodes of the network construct their own table in the same manner.
Visibility Table
A node also possesses a visibility table made up of two columns. The first column corresponds to the nodes which are situated one hop away from the node, it contains the ID or identifier of the nodes situated one hop away. The second column contains the identifiers ID of the nodes situated two hops away, which can be reached by way of the node which is stored in the first column and the same row.
Based on its visibility table, and on N, the maximum number of nodes in the network, each node can construct another table, the table of distant nodes, which contains all the identifiers ID of the nodes which are further than two hops away. This table of distant nodes is used, notably, to search for the identifiers ID of the nodes whose resources can be reused.
The visibility table and the table of distant nodes are constructed by dispatching “Hello” messages (containing the identity of the sender node) in the control slots.
Status Table
The table of statuses contains two fields “next hop” which contains the IDs of the nodes and “status” which contains true or false. The status can be true, if a slot allocation confirmation message is received or else false otherwise.
Table of Slots
Another useful table is the table of slots,
Its content is as follows:
IDs of session K: this value represents the identifier (the IDs) corresponding to the session. The sessions are differentiated in the figure by hatching.
Table of Reservation Requests Undergoing Processing
When a request for a new session is sent by the higher layers, the session IDs and the priority level are, for example, stored in a special table whose content is as follows:
A request may be undergoing processing for the following reasons:
If several requests arrive, they are stored in the table and are processed one after another. When the node has to choose the request to be served, the session having the highest priority is served first.
Types of Packets
All the MAC packets have the structure shown schematically in
Procedure for Negotiating the Slots
There are, for example, four types of messages used in the procedure for negotiating the slots
Dynamic Allocation Method
The dynamic allocation method according to the invention, can be divided, for example, into three main steps:
E1—calculation of the minimum total number of MAC packets and of slots required for a session as a function of the minimum throughput constraint imposed by the reservation request;
E2—calculation of the identities (ID) of the slots in the frame so as to satisfy the reservation request. The algorithm for selecting the session slots must comply with the maximum radio access deadline constraint imposed by the reservation request as well as the minimum number of reserved MAC packets;
E3—negotiation with the neighbors in the case when new slots are impressed by way of an SAR request message.
Determination of the Number of Slots Required
The calculation of the total number of slots required for a session depends on the constraints imposed in the resource reservation request. The input parameters are given in the request and are used to determine the necessary slots:
The way in which the higher layer reservation method (such as typically for RSVP over IP) is dissected in terms of resource reservation request is detailed further on.
The other parameters, given as system constraints, are for example:
The maximum number of bits which can be transmitted in a slot is given by the product of the throughput and the duration of the slot
Bs=BR*Ts
The number of bits used for the encapsulation of a data packet of the application is subtracted from Bs. Thus, the maximum number of useful bits for the encapsulation of data UBs is given by:
UBs=Bs−M*NPS
The number of slots necessary to satisfy just the throughput (“bandwidth”) constraint BWs is given by:
where TF is the duration of the frame given by:
T
F
=N*K*T
S
the total number of slots in a frame is given by:
NSF=N*K
Taking into account the deadline constraint MD, the number of slots DS necessary to satisfy this requirement is:
Once BWS and DS have been calculated, the number of necessary slots TNS is given by the maximum of the two parameters:
TN
S=max(BWS,DS)
The method thereafter determines the maximum distance between a first session slot and the next; this value MDS is given by:
This signifies that there is a session slot every MDS slots in the frame. If the maximum size of the packet PS is larger than the useful value of the bit UBS, the number of consecutive slots is:
Calculation of a Reservation Configuration, of the Identifiers ID of the Slots and of the MAC Packets to be Reserved with Pre-Emption Mechanism
Starting from the value of the distance MDS (maximum distance between two slots) determined during the previous step, and the minimum throughput constraint, it is necessary to determine the identifiers ID of the slots to be reserved.
The selection of the session slots and the formulation of a reservation configuration is carried out with the aid of a resource allocation algorithm. This algorithm determines an allocation solution which complies with the following constraints:
The input parameters for this step are:
The formulation of the reservation configuration at node level relies on a resource allocation algorithm integrating the constraints sent in the reservation request. One heuristic consists, for example, in examining each slot beginning from the first free slot in the basic frame, and then searching gradually to select a session slot which satisfies the maximum radio access deadline constraint. At the end of this selection process, new slots are optionally reserved if the minimum throughput constraint is not complied with. The algorithm knows, by consulting a DRAM table associated with the node considered, whether a session slot is free or occupied, that is to say already completely used by the node considered (and no longer having any MAC packet available) or already reserved by another node which is situated one or two hops away from the node itself.
Thus, in the heuristic described, the session slots are examined chronologically in the frame. If the slot is free, its identifier ID is placed in a list of slot ID's and we go to the slot ID which is a value MDs slots away from the current slot. If this new slot is free its ID is stored in the previous list. Otherwise, we return slot by slot until a free session slot is found. The heuristic continues to be played out until the end of the frame is reached. At the end the method has a list of slots that can be used for the session.
The useful bits in a slot and the number of slots, necessary to satisfy the bandwidth constraint, are calculated as set out hereinafter:
The value BWS, of minimum number of slots to satisfy the throughput constraint, is approximated to the first largest integer. In this case, the value BWS is equal to 1.
As regards the constraint on the maximum deadline, the number of slots necessary to satisfy this request, is given by:
TN
S=max(BWS,DS)=6
The maximum distance between one session slot and the next is given by:
This signifies that a session slot is needed every 5 slots in the frame.
Let us assume that the slots labeled with a star in
To calculate the identifier of the available slot IDs, the method commences from slot 2, it checks whether it is free. If it is, it stores this identifier ID(2) in a list. Thereafter, it hops 5 slots ahead and checks the status of the new current slot. In this example, this is slot 7. By verifying in the DRAM table (of node 3), it turns out that this slot is already occupied, therefore we backtrack until we find a free slot. In the example, this slot corresponds to slot 3. By following this principle, the available slots are 2, 3, 8, 12, 17, 19, 24 and 29.
The last test to be executed is to verify that the distance between the last available slot (slot 29) and the first slot available in the next frame (slot 2) is less than MDs. In the example, the test is OK.
The entire procedure is repeated, beginning from the second free slot in the frame until the end of the frame, if necessary.
At the end of this reservation configuration formulation procedure, if no solution has been found, the MAC layer rejects the resource reservation request for the instigation of a new session. Moreover, if the solution found selects only slots already allotted to the node considered, the request is accepted and the associated MAC packets are reserved. In the case where the solution involves slots not allotted to the node considered, we pass to the step of sending an SAR allocation request for negotiation with the neighboring nodes.
One of the input parameters for the slot allocation is its priority level. If there exist enough session slots which can be allocated to a session, the priority level of the request is satisfied. If there is a session having a lower priority level, the method examines whether by deallocating all the slots belonging to this session of low priority, whether it is possible to find a reservation configuration solution for the new session of higher priority level.
This mechanism is called a pre-emption mechanism and ensures that the services of high priority can be guaranteed locally optionally, by deallocating slots belonging to sessions of lower priority level.
SAR Request for the Allocation of Slots
In order to explain the slot allocation request process, let us assume that node 3 has chosen the set of slots [2, 3, 8, 12, 17, 19, 24, 29] and wishes to send a request for slot allocation. This information is transmitted by an SAR message (Slot Allocation Request) to the other neighboring nodes of the network.
When a node transmits an SAR packet, it creates a table containing its close neighbor nodes within the sense of “next hop” and a status field. This status field can be filled in with true or false, depending on the reception of the corresponding slot allocation confirmation dispatched by its close neighbor nodes (next hop nodes). Moreover, the node initializes a time counter “timer” so as to check whether an SAC packet has been lost. Generally, the node waits an entire frame period before renewing the request.
Referring to node 3, its status table is:
Node 3 has nodes 2, 5 and 6 as nodes situated a “next hop” away. Initially, the status corresponding to the nodes is set to false. The node waits until it has received all the SAC packets of its close hop nodes. If there is no problem, the statuses of all the nodes in the status table are set to true, as indicated above, and the DRAM table of node 3 is updated by setting to 1 the bit, in the column corresponding to the slot ID which has been requested, corresponding to the nodes ID.
In the example, the third bit in the status field of the column corresponding to the slot IDs 2, 3, 8, 12, 17, 19, 24 and 29 is set to 1.
If there is no problem, see
If the timer expires, then the node erases all the tables and dispatches a new SAR message.
An SAC packet is received with a destination address which is different from that of the node: in this case, the DRAM table is reupdated. Thereafter a comparison test is performed which compares the identities of the slots that the node has requested in its SAR packet and those of the SAC packet received.
If there are no common slots a new SAR message is dispatched. Otherwise, a deallocation message “Slot Deallocation Requested (SDR)” is dispatched and the procedure is repeated.
An SDR message declares the SAR message previously transmitted obsolete and invites all the nodes which have received the SAR message to deallocate all the slots contained in this message
On receipt of the SAC message of node 5, node 1 sees that the destination address is node 1 instead of node 3 and that node 1 has sent a request for slot 2. Since node 1 is 2 hops away from node 3, they may not use the same slot. Thus, node 3 dispatches an SRD message. Nodes 2, 5 and 6 each update their DRAM table by canceling the previous requests and dispatch a slot deallocation confirmation message (SDC message).
Input DRAM table of nodes 2 and 6 after receipt of the SAR and SDR messages.
When a node receives an SAR message, it updates its DRAM table and dispatches an SAC message using the source address of the SAR packet received as destination address. As long as a node has not sent an SAC confirmation message, it does not take account of any new SAR messages. For each SDR message, a node must wait until all the nodes situated in proximity “next hop(s)” have responded with an SDC packet. Otherwise, the SDR message is transmitted anew.
If a slot is used by more than one session, its ID is not dispatched in the deallocation message.
The use of the slots requested by a node will be considered to be possible only when it has received the confirmation of all its direct neighbors. The acceptance of the request to reserve resources is then proclaimed and the associated slots are actually reserved.
Dissection of a Global Resource Reservation, of RSVP Type, at the MAC Layer Level
In order to support the resource reservation request at the MAC level, two parameters are introduced in the MAC request:
These two parameters are used in the allocation algorithm set out above or in any other type of allocation algorithm, so as to guarantee compliance with the reservation request with service guarantee.
In the case of a periodic TDMA, the message Resv for the RSVP resource request is expressed in the MAC layer in terms of MAC reserved packets.
The RSVP parameters are described according to the RFC specifications of the IETF known to the person skilled in the art.
For example, the parameters used to describe the envelope of the traffic according to the token seal model are (according to the “token bucket” recommendation RFC 2212):
The transmission deadlines for each node I are described by the following two parameters:
Thus, the bound of the transmission deadline for a packet at a minimum throughput R for node I is:
τi=Ci/R+Di
In the case of a TDMA with slots which are completely periodic at the level of each node the RSVP calculation method can be used by establishing a rigorous correspondence between the MAC parameters and the RSVP parameters.
The mathematical relations between the parameters Ci and Di of the AdSpec field (of the PATH message of the RSVP protocol) and of the parameters of the MAC level previously described are then as follows:
For identical nodes, the parameters are independent of the node and no longer need to be indexed (in the description C and Ci are employed to designate one and the same parameter; the same holds for D and Di).
Note that the relation for the parameter C is rigorously valid only if the interleaving algorithm leads to a uniform temporal distribution of the physical slots of each node inside the global frame and if the MAC packets of one and the same session are distributed over distinct physical slots.
In the case of periodic access to a radio network by a node (this implies that all the TDMA slots used are also distributed in the frame), the maximum deadline τ to transmit a packet for a session considered is:
τ=N.K.Ts/m+D (for m≦K+H)
and available throughput R (for the session considered) is:
R=m.BR/(K.N.NPS)
With the following MAC parameters (in part previously defined):
N: number of nodes of the network,
K: number of physical slots for a node,
H: number of physical slots borrowed by the node considered,
Ts: duration of a physical slot,
m: number of MAC packets (logic slots) reserved (m≦(K+H).q),
NPS: number of MAC packets per physical slot,
the maximum transmission deadline for the node may therefore be written:
D+C/R=τ+D
i.e.:
C/R=N.K.Ts/m
therefore C=BR.Ts/NPS=size (number of bytes) of an MAC packet.
D is often negligible, a relay node generally having time to process the packet during the slot waiting time.
The throughput consumed at the MAC level for the encapsulation of the packets has not been taken into account for the sake of simplification. Taking this encapsulation into account amounts to considering R as the useful throughput for the application.
In the general case of a TDMA with non-periodic access of the nodes (due to a distribution of the MAC packets which is generally not periodic because of an irregular temporal spacing of the slots):
the values τ (maximum packet transmission deadline) and R (minimum throughput required) are not independent and are even strongly related:
For example, R can be deduced approximately from the maximum deadline τ. Actually, by using at least one MAC packet every τ seconds, the minimum value of R is:
Rmin=(N.K.Ts/τ)(BR/(K.N.NPS))=Ts.BR/(τ.NPS)
and the more regularly the MAC packets are spaced out over time, the closer R is to Rmin.
It is therefore possible to write:
τ=α.C/R
where: C=BR.Ts/NPS=size or capacity (number of bytes) of an MAC packet
At the RSVP level, the characteristics of the envelope of the application traffic are then considered to be in agreement with the token seal model such as described previously.
Now, by considering the maximum end-to-end latency, δ, and by making the assumption that the maximum transmission deadline and minimum throughput are the same for each node (identical nodes on the path), the following mathematical relation is established:
where n is the number of hops of the session path this formula is rewritten in the form:
the usual RSVP relation is:
where the parameters Ci and Di characterize node i
thus, the RSVP calculation method can still be used by defining the parameters Ci and Di in the following manner:
Actually, in this case, the Resv request based on a required minimum throughput calculation with the usual formula leading to the following MAC resource reservation request:
and the maximum deadline τ and the available minimum throughput R then satisfy the following relations:
τ≦C/R′
R≧R′
hence:
thereby guaranteeing the end-to-end latency requested.
The RSVP request can then be dissected at the MAC layer:
If the resource reservation is solely due to the end-to-end latency constraint (R′>r), the request of the MAC layer is based on the maximum transmission deadline required C/R′ (the constraint on the throughput will then be satisfied automatically).
Conversely, if the resource reservation is due solely to the throughput constraint (R′=r) and if the end-to-end constraint is not meaningful, the MAC request is based solely on the throughput required r (nominal throughput of the data of the application).
1—Status: Waiting
This is the standby state waiting for a new resource reservation request possible events:
2—Status: C1
in this state, the node analyzes the current transmission resources so as to establish whether the constraints relating to a session request are compatible with the available slots.
Events:
3—status S3: waiting to transmit SAR in its slot
the node waits to transmit its SAR packet in its control slot.
Event:
4—status S2: it waits to transmit SAC or SDC in its control slot
the node must respond with an SAC or SDC message in its control slot.
Events:
5—status C5: it tests the source of SDR
in this state, the node must test the origin of the SDR received, named SSDR, so as to compare it with the origin of the SAR received, named SSAR. If SSDR and SSAR are equal, the system transmits an SDC packet to the origin of the SAR message. Otherwise no operation is done.
Events
6—Status C3: it tests the priority
There is not a sufficient number of free slots to satisfy the resource reservation request. The node compares the priority of the new session with the priorities of the current sessions so as to close the sessions which have a lower priority level.
Events:
7—status C4: it checks the DRAM table
The node having halted the sessions, it checks the DRAM table so as to establish whether it is necessary to deallocate new slots or to deallocate nodes not used or else both.
Events:
8—Status C5: it tests the source of SDR
In this state, the node must test the origin of the SDR received, named SSDR, so as to compare it with the origin of the SAR received, named SSAR. If SSDR and SSAR are equal, the node must transmit a packet of the origin of the SAR message. Otherwise no operation is done.
Events:
9—Status S4
ditto status S2
10—status S5: it receives an SAC message
The node must transmit the SAR message so as to request the necessary slots and thereafter it waits for the confirmation message (SAC) relating to the SAR message transmitted.
Events:
11—status C6: it checks SAC/SDC
The node analyzes the ID slot field of the message received so as to check whether the set of slot IDs carried in this packet complies with the set of IDs that the node has chosen.
Events:
12—status C7: it tests the request
when the node receives a session closure request, it must deallocate the related slots only if they are not used by other sessions.
Events:
13—status S6: it waits to transmit SAC or SDC in its slot ditto status S2.
14—status C2: it tests the source of SDR
In this state the node must test the origin of an SDR received, named_SSDR, so as to compare it with the origin of the SAR received, named SSAR. If the SSDR and SSAR are equal, the node must transmit an SDC packet to the sender of the SAR message. Otherwise no operation should be done.
Events:
a) no operation: SSAR and SSDR are not equal,
b) RX SDC from X: SSAR and SSDR are equal.
15—status S7: it waits to transmit SDR in its slot
The node waits to transmit an SDR message in its own control slot.
Events:
16—status S8: it waits to receive an SDC message
the node must transmit the SDR message so as to deallocate unnecessary slots and thereafter it must receive the confirmation message (SDC) relating to the SDR message transmitted.
Events:
Number | Date | Country | Kind |
---|---|---|---|
0611279 | Dec 2006 | FR | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP07/64427 | 12/21/2007 | WO | 00 | 8/9/2010 |