FR2942685A1 - Access managing method for e.g. time division multiple access network, involves determining priority request, and authorizing access to node during time sharing slot, where node emits priority access request during collision time slot - Google Patents

Abstract

The method involves receiving information during a pre-assigned time slot (PTS), where the information indicates whether a node detects an access request during a time sharing slot. A priority access request is determined, among the requests whose positive reception indications are received, based on a predetermined selection criterion. The access is authorized to the node during the time sharing slot, where the node emits the priority access request during a collision time slot. Independent claims are also included for the following: (1) a computer program product comprising program code instructions for implementing an access managing method (2) a computer readable storage medium for storing a computer program to implement the access managing method (3) a decision-maker node for managing access of a node to a communication network.

Description

A method of managing access to a communication network during a shared time slot, computer program product, storage means and corresponding decision node. FIELD OF THE INVENTION The field of the invention is that of communication networks. More specifically, the invention relates to a method making it possible to control access to a shared time slot while avoiding collision cases in which at least two nodes transmit simultaneously in the same time slot, especially when there are masks. 2. TECHNOLOGICAL BACKGROUND 2.1 Context and problem In the remainder of this document, we will focus on the problems that exist in the context of a multichannel audiovisual content broadcasting system, which was faced the inventors of the present patent application. Wireless data transmission systems are now more and more numerous. They respond to the growing need of users for systems providing a very high transmission rate while offering high quality of service and ease of use.

Thanks to an extended bandwidth, the 60GHz radio transmission systems are particularly well suited for very high speed data transmission. One of the physical characteristics of the millimetric band is the high attenuation rate combined with the low reflection rate on the obstacles that can be encountered in a domestic environment. These properties make this radio technology well suited for the deployment of a wireless LAN type PAN (for Personal Area Network in English) within a limited operating radius. A 60GHz wireless PAN will therefore be a preferred way to ensure, for example, the connectivity between the different elements of a home theater or a videoconferencing system. This type of application requires perfect synchronism between the transmitter (s) and the receivers, in particular in the case of a system for broadcasting a multichannel audio content (or surround sound system in English), comprising for example up to with 8 speakers. In this case, a transmitter (also including an audio decoder) will perfectly synchronously transmit different audio channels from a single source to a subset of receivers, each comprising a speaker, all of these receivers. having to restore the sound in a perfectly synchronized way overall in order to bring to the sound a spatialization effect. In addition, in the case of a home theater system with a flat screen wall mounted, it is advantageous for the user to be able to wirelessly connect the screen to the video source. To ensure synchronization of applications, it is advantageous to rely on a synchronous system that guarantees a fixed transmission latency. This is why the preferred medium access mode is of the TDMA (Time Division Multiple Access) type, with a cyclic and predefined time interval for each transmitter node of the network. The TDMA cycle is called super-frame or SDTC (Synchronous Data Transmission Cycle in English). A SDTC cycle is divided into a predefined number of time slots and each interval corresponds to a time slot reserved for a single node of the network. The assignment of a time slot to a network node depends on its role in relation to the applications as well as the external environment. If the node is connected to an audio source, it will probably only need one time slot, but a node connected to a video source will need more than one. Conversely, a node only connected to a speaker will only need to transmit control data, for example an acknowledgment message following the receipt of a command to increase the volume of the sound. This type of node will need a time interval but it will be weakly used. Finally, some nodes will need one or more time slots because they will have a repeater role. Indeed, in order to mitigate possible masking, punctual or permanent, due to obstacles between the nodes of the network, it is necessary to have the data repeated several times by different nodes. This rehearsal game creates a mesh network, which avoids the loss of data. The counterpart of this technique is to increase the latency of the network because several SDTC cycles will generally be necessary to perform all the repetitions, but a major disadvantage is also to reduce the useful bandwidth available.

We realize that it is necessary to have a distribution and a judicious use of the time slots allocated to the nodes of the network. It must be ensured that each node receives at least once the data transmitted by the other nodes while guaranteeing sufficient bandwidth for the applications. This step of allocating (or assigning) the time slots occurs, for example at the initialization of the system, after each radio transmission path has been tested, and each node has indicated its bandwidth requirements. . This set, consisting of at least one time interval, is called PTS (or Predefined Time Slot (s) in English).

Rather than reserving at least one time slot for all the nodes of the network, it seems interesting to do it only for the nodes having a strategic role: the nodes connected to a data source and the nodes used as repeaters. For other nodes in the network that do not have synchronous data and few asynchronous data to transmit, it is not optimal to allocate a predefined time interval for each SDTC cycle. To gain bandwidth, it is then reserved for all these nodes a limited number or even a single time slot with shared access, forming a set said STS (for Shared Time Slot (s) in English). The arbitration for access to the STS time slot is done by means of a (short) collision time interval, also called CTS (Collision Time Slot). The preferred embodiment consists in dividing the super-frame into three phases: a PTS phase supporting the synchronous data transport, an STS phase supporting only the asynchronous data transport which is shared between the nodes of the network (and could for example, to nodes that do not have a time slot to transmit their data in the PTS phase), and a CTS phase that includes a time slot for sending access requests to a time slot of the STS phase. . The CTS time interval arbitration technique is widely used in wireless networks. Each node wishing to use a next STS shared access time slot issues a request during the corresponding CTS collision time interval. The request containing the node identifier and a priority indicator, only one node will finally be allowed to transmit in the shared time slot. If several nodes issue their request at the same time, there is a collision between the access requests and the radio signals are unusable. To reduce the probability of collision, the nodes start to emit each one after a random time. However this is not enough to avoid all cases of collision. Indeed, a request may be completely noisy because one or more other access requests are issued simultaneously. On the other hand, two nodes which emit their request in a very distinct way, but which are too far apart from each other or masked relative to each other, will not have detected any other request than that which each one will have emitted himself. In any case, there is always uncertainty about the decision to use the time share interval, and therefore there is always a risk of collision in the timeslot. 2.2 Limits of the State of the Art To reduce this risk of collisions, many protocols have been described as the CSMA / CA protocol (for Carrier Sense Multiple Access with Collision Avoidance in English) used by the IEEE 802.11 standard. The CSMA / CA protocol uses a collision avoidance mechanism based on a principle of mutual acknowledgment between the sender and the receiver. First, the node wanting to broadcast listens to the network. If the network is congested, the transmission is delayed. In the opposite case, if the medium is free during a given time called DIFS (for Distributed Inter Frame Space in English), then the node can emit. It first transmits a message called RTS (Ready To Send or Request To Send), containing information on the volume of data it wishes to transmit and the transmission rate enivsagée. The receiver, usually an access point, responds with a message called CTS (for Clear To Send) meaning that the medium is free, then the node starts transmitting the data. After receiving all the data, the receiver sends an acknowledgment ACK (to acknowledge in English). After detection of an RTS message or a CTS message, all the nodes of the network other than the sender of the message then wait for the time which they consider to be that necessary for the transmission of the volume of information to be transmitted to the advertised speed. This technique, however, remains inefficient to ensure that no collision occurs in the time-share interval. Indeed, if a node A sends a request for a node B and a node C sends a request for a node D while the pair (A, B) is temporarily masked from the pair (C, D), then A and C will attempt to use the shared time slot simultaneously. If the masking between (A, B) and (C, D) is maintained, this is not a problem, but if the masking disappears (for example a person was moving in this geographical area), then the data transmitted during the shared time interval will be unworkable. An improvement of this protocol called FPRP (for Five-Phase Reservation Protocol in English) is proposed by C. Zhu and MS Corson ("A Five-Phase Reservation Protocol (FPRP) for Mobile Ad Hoc Networks," IEEE INFOCOM Proc '98 ). The protocol describes a mechanism for reserving a time slot in a TDMA transmission system with a low probability of collision. The reservation of a time slot is propagated to the nodes located at two jumps (or hop in English) of the node issuing the reservation. Two nodes separated by a jump means that it is necessary to introduce an intermediary relay node so that these two nodes can communicate with each other. With this protocol, the CTS collision time interval is divided into five phases, and each phase corresponds to the emission of a protocol message. However, this technique has the drawback of significantly lengthening the duration of the CTS collision time interval, which correspondingly reduces the useful bandwidth available.

Another method of arbitration is disclosed in US Patent 6,594,247. A specific node, called the master node, is responsible for detecting any collisions during the CTS collision time interval. If a collision occurs, the master signals it by asking certain nodes in the network to communicate the access requests they have seen during the CTS collision time interval. The master node then determines the winning node of the competition and gives it permission to broadcast.

However, this technique is unreliable because it assumes that the master node is visible to all other nodes in the network. In case of masking, it is possible that the master node did not see all access requests and therefore does not detect a collision. In addition, it is possible that the access authorization decision granted to a node given by the master node is not received by all the nodes of the communication network. In view of the prior art, it thus clearly appears a need for an arbitration technique that is both simple, low bandwidth consuming and reliable despite the random nature of masking in a wireless communications system. 3. OBJECTIVES OF THE INVENTION The invention, in at least one embodiment, is intended in particular to overcome the various drawbacks of the state of the art. More specifically, in at least one embodiment of the invention, an object of the present invention is to provide a technique for controlling access to a time slot shared by a plurality of nodes of a communications network (e.g. TDMA type), so that only one node accesses this time slot. The present invention notably makes it possible to avoid all collision cases in which at least two nodes simultaneously transmit in the same shared time slot. Such a result must be obtained regardless of the state of the network communication paths. In particular in the case of a wireless network, the present invention makes it possible to overcome the phenomena of masking, permanent or temporary, which prevent direct communication between nodes of the network.

A complementary objective of at least one embodiment of the invention is to provide such a technique for optimizing the use of the bandwidth available on the medium. Indeed, in a TDMA type system for example, when a time slot is reserved for a node, it can not be used by any other node of the network even if this time slot is weakly used. It is therefore interesting to be able to limit the number of nodes with reserved time interval, and to reserve to the other nodes a time slot with shared access. 4. DISCLOSURE OF THE INVENTION In a particular embodiment of the invention, there is provided a method of managing access to a communication network during a shared time slot, a collision time slot enabling transmission a request for access to the shared time slot, a predetermined set of at least one node each having at least one pre-assigned time slot for accessing said network, This method is remarkable in that a node decision-maker performs steps of: - receiving, during the pre-assigned time interval, information indicating, for each node of said predetermined set, whether or not said node has detected at least one access request to the shared time interval; determining, among the request or requests for which a positive reception indication has been received, a priority access request based on at least one predetermined selection criterion; and in that access to said shared time slot is allowed to the node that issued said priority access request during the collision time interval. Thus, the invention is based on an entirely new and inventive approach to a method of using nodes having a pre-assigned time slot to detect whether at least one request for access to the shared time slot has occurred. was issued by a requesting node. Thus, this method makes it possible to control the access to a time slot shared by several nodes of a communication network, so that only one and only node accesses this time slot in each network cycle. The present invention makes it possible in particular to avoid collision cases in which at least two nodes simultaneously access the network during the same shared time slot. In particular in the case of a wireless network, the present invention makes it possible to overcome the masking phenomena, permanent or temporary, which prevent the direct communication between nodes of the network, at the time of the transmission of the requests of access (that is, during the collision interval). Also, the available bandwidth is optimized. Indeed, in a network system (of the TDMA type for example), when a time slot is pre-assigned to a node, it can not be used by another node of the network under any circumstances even if this time interval is weak. used. It is therefore interesting to be able to limit the number of nodes with pre-assigned time interval, and to reserve to the other nodes a time slot with shared access. Advantageously, each node of said predetermined set relays each access request to the shared time slot that said node has detected during said collision time interval. Thus, it optimizes the probability that the decision-making node receives said at least one access request since an indication of the request or requests can be received either conventionally using the collision interval, or according to the invention using at least one pre-assigned time interval of at least one node of said predetermined set. Advantageously, if the network comprises only one said decision-making node, said step of determining the priority access request is also performed among access requests received during the collision time interval by said decision-making node. . Thus, the decision-making node makes a decision concerning access to the shared time slot according to a list of requests that it has itself detected during the collision interval, a list that it can modify according to the indications of detecting requests received from the nodes of said predetermined set. Thus, the reliability of the decision process is increased. Since the decision-making node can make an intermediate decision based on the requests it has detected during the collision interval, the decision-making process is accelerated. Advantageously, when a node of said predetermined set detects several requests for access to the shared time slot transmitted during said collision time interval, said node of said predetermined set performs a step of classifying, in a list, said access requests detected according to said predetermined selection criterion, and in that it transmits during its pre-assigned time interval information relating to a priority request, among said detected access requests, according to the selection criterion predetermined.

Thus, the decision-making process is accelerated and the bandwidth consumption relating to the transmission of the indications of requests detected during the collision interval is reduced. A particular embodiment of the invention provides that each node of said predetermined set relays, during its pre-assigned time interval, access request indication information of access to the shared time interval detected by at least another node of said predetermined set during the collision time interval. Thus, it is reinforced that requests indications are received by the decision node, when at least one node of said predetermined set is masked from the decision node. Advantageously, a requesting node being a node transmitting a request for access to the shared time slot, if each requesting node is a said decision node, said decision node performs steps of: - issuing an access request during said collision time interval; transmitting data on said network during said shared time slot, if said priority access request is identical to the access request transmitted by said given requesting node. Thus, in this first embodiment, the present invention can be implemented in a distributed manner in the requesting nodes.

According to an interesting feature of a particular embodiment of the invention, if said decision-making node is not a requesting node, said decision-making node performs a step of transmitting, to the requesting node having previously sent said request to priority access, information allowing said requesting node to access said network during said shared time slot.

Thus, in this second embodiment, the present invention can be implemented centrally in a node other than a requesting node. According to another advantageous characteristic of a particular embodiment of the invention, the number of transmission cycles separating a transmission cycle in which an access request has been transmitted and a transmission cycle in which the interval is located. time share associated with the request, is fixed and predetermined. Thus, it is possible to set up mechanisms for repeating, by a first node, data previously transmitted by a second node. A compromise must be found between latency from request until access to said shared time slot and guarantee that the decision node takes into account all the requests (which also limits collisions during the shared time interval related divergent decision-making in a distributed environment, as mentioned above). In another embodiment, the invention relates to a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor. This computer program product includes program code instructions for carrying out the aforesaid method (in any one of its various embodiments), when said program is run on a computer.

In another embodiment, the invention relates to a computer readable storage means, possibly totally or partially removable, storing a computer program comprising a set of instructions executable by a computer to implement the aforementioned method (in any of its different embodiments).

In another embodiment, the invention relates to a decision-making node for access management of at least one node to a communication network during a shared time slot, a collision time slot for issuing a request. access to the shared time slot, a predetermined set of at least one node each having at least one pre-assigned time slot for accessing said network. This decision-making node is remarkable in that it comprises: reception means, during the set of pre-assigned time interval, information indicating, for each node of said predetermined set, whether said node has or has not been detected at minus a request to access the shared time slot; means for determining, among the request or requests whose positive reception indication has been received, a priority access request as a function of at least one predetermined selection criterion; means for authorizing access to said shared time slot for the node having sent said priority access request during the collision time interval. Advantageously, each node of said predetermined set comprises means for relaying each request for access to the shared time slot transmitted during said collision time interval. According to an advantageous characteristic of a particular embodiment of the invention, if the network comprises only a single said decision-making node, each decision-making node comprises means adapted so that the priority access request is also determined among the requests. received during the collision time interval.

Advantageously, each node of said predetermined set comprises means for detecting access request indication information for access to the shared time slot detected by a node of said predetermined set during the collision time interval and relayed by another node of said predetermined set during its pre-assigned time interval. Advantageously, a requesting node being a node issuing a request for access to the shared time slot, if each requesting node is a said decision node, said decision node further comprises: first means for sending a request access during said collision time interval; second means for transmitting data on said network during said shared time slot, if said priority access request is identical to the access request transmitted by said given requesting node. Furthermore, if said decision-making node is not a requesting node, said decision-making node comprises third transmission means, to the requesting node having previously sent said priority access request, information allowing said requesting node to accessing said network during said shared time slot. 5. LIST OF FIGURES Other features and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given as a simple illustrative and nonlimiting example, and the accompanying drawings, among which: - Figure 1 illustrates schematically, according to a particular embodiment of the invention, a 60GHz communication system consisting of 9 communication nodes; FIG. 2 schematically illustrates the structure of radio packets cut into RDB radio data blocks, according to a particular embodiment of the invention; FIG. 3 diagrammatically illustrates a distribution matrix of the synchronous bandwidth initialized at the start of the system, according to one particular embodiment of the invention; - Figure 4 schematically illustrates an architecture of a synchronous communication module, according to a particular embodiment of the invention; FIG. 5 schematically illustrates the data stored for the implementation of the present invention, according to a particular embodiment of the invention; FIG. 6 schematically illustrates the operation of a communication module according to a particular embodiment of the invention; FIG. 7 schematically illustrates a flow diagram of the operation of the radio packet transmission block 95 according to a particular embodiment of the invention; FIG. 8 schematically illustrates a flow diagram of the operation of the radio packet reception block 94 according to a particular embodiment of the invention. DETAILED DESCRIPTION In connection with FIG. 1, a communication system 60 GHz consisting of 9 communication nodes implementing the present invention according to a particular embodiment is presented.

Take the example of a 60GHz communication system consisting of 9 communication nodes according to the invention, such a system is shown schematically in Figure 1. More particularly, the system comprises 8 nodes la, 2a, 3a, 4a, 6a. , 7a, 8a, and 9a type WAR (for Wireless Audio Renderer English or French wireless audio receiver) each of which is equipped with digital audio channel amplifier means (or Digital Audio Channel Amplifier in English), respectively lb, 2b, 3b, 4b, 6b, 7b, 8b, and 9b which integrates a loudspeaker (or speaker in English), and a node 5a of WAD type (for Wireless Audio Decoder in English or wireless audio decoder in French) , comprising a multi-channel audio decoder (or surround sound decoder in English), respectively 5b, for example integrated in a flat screen and capable of transmitting via the 60GHz communication system, in a perfectly synchronized manner, the different audio channels associated with the video displayed on the screen.

Each of the nodes 1a, 2a, 3a, 4a, 5a, 6a, 7a, 8a, and 9a, integrates a synchronous communication module, SCM (for Synchronous Communication Module in English), which integrates the various means according to the present invention. . The total available bandwidth delivered by the system is divided into synchronous virtual channels. The useful rate is characterized by the processing frequency of the virtual channels, for example 8KHz, as well as by the size of the samples, for example 48 bits. Thus, a virtual channel VC (for Virtual Channel in English) has a constant bit rate of 384 Kbps (kilobits per second). The complete sequence comprising a sample of each of the virtual channels available constitutes a complete Synchronous Data Processing Cycle (SDPC) whose duration is equal to 125 lts in the case of a processing frequency of 8 kHz. virtual channels. An audio channel of 96KHz-24bit resolution will therefore use 6 virtual channels, for example for a complete 8-channel system (typically called 7.1), a total of 48 virtual channels, and therefore a useful bit rate of 18.432 Mbps (megabits per second) only for the transfer of audio information. In addition, for the transfer of additional information (system control, protocol, user command, ...) virtual channels are reserved for the transmission nodes of the system, so that a SDPC cycle is here composed of 54 channels virtual, a useful bitrate of 20,352 Mbps. Thus among the virtual channels 0 to 47 transmitted by the synchronous communication module 5 SCM # O of the node 5a: the virtual channels 0 to 5 are decoded and then processed by the synchronous communication module 9 SCM # 1 of the node 9a, and corresponding front-center speaker (or Front-Center Speaker); the virtual channels 6 to 11 are decoded and then processed by the synchronous communication module 4 SCM # 2 of the node 4a, and corresponding to the front-left speaker (for Front-Left Speaker in English); the virtual channels 12 to 17 are decoded and then processed by the synchronous communication module 7 SCM # 3 of the node 7a, and corresponding to the front-right speaker (or Front-Right Speaker); the virtual channels 18 to 23 are decoded and then processed by the synchronous communication module 3 SCM # 4 of the node 3a, and corresponding to the side-left speaker (or Side-Left Speaker); the virtual channels 24 to 29 are decoded and then processed by the synchronous communication module 8 SCM # 5 of the node 8a, and corresponding to the right-side speaker (or Side-Right Speaker); the virtual channels 30 to 35 are decoded and then processed by the synchronous communication module 2 SCM # 6 of the node 2a, and corresponding to the rear-left speaker (for Rear-Left Speaker); the virtual channels 36 to 41 are decoded and then processed by the synchronous communication module 1 SCM # 7 of the node 1a, and corresponding to the right rear speaker (or Rear-Right Speaker); the virtual channels 42 to 47 are decoded then processed by the synchronous communication module 6 SCM # 8 of the node 6a, and corresponding to the subwoofer (or subwoofer). The virtual channels 48 to 53 are decoded and then processed by all the nodes for the exchange of additional data synchronously. They are called virtual control channels. Thus the nodes involved in the transmission of synchronous data have at least one reserved virtual control channel for sending additional data to all the other nodes of the system, for example: for the SCM # O node, the virtual channels 48 and 49; for the SCM node # 2, the virtual channel 50; for the SCM node # 3, the virtual channel 51; for the SCM node # 4, the virtual channel 52; for the SCM node # 5, the virtual channel 53.

A VC Chunk (Virtual Channel Chunk) virtual channel container processing sequence, consisting of all samples of the same virtual channel (for Virtual Channel S ample), must be performed for one SDTC cycle. Therefore, the transmission sequence of this same VC Chunk container must be performed during the next SDTC cycle. Consequently, the duration of a cycle SDTC is a multiple of the duration of a cycle SDPC, and is thus called STPR (for synchronous transmission to processing ratio in English or synchronous transmission cycle report on synchronous processing cycle in French) . This entire report thus defines the size of the transmission sequence of a virtual channel, in common whatever the virtual channels. In the particular embodiment of the present invention, STPR = 8. A transmission sequence of a virtual channel container, VC Chunk, therefore consists of 48 useful bytes (the 48-bit sample size multiplied by the STPR. The total size of a VC Chunk container is nevertheless 49 bytes because, to the 48 useful octets, it is necessary to add a byte of head indicating the validity of the data transported in each of the 8 virtual channels. application did not provide data when writing a virtual channel, it will be written with a null symbol (for example 0x000000000000) and in the byte of the VC Chunk container, the bit corresponding to the null VC takes the value `0 'If a VC contains valid data, its bit in the header of the VC Chunk container takes the value` 1' Figure 2 schematically illustrates the structure of the radio packets broken into blocks a SDTC cycle is divided into n three phases: - a phase PTS (for Predefined Time Slots in English) ensuring the transport of synchronous data with repetition to avoid losses due to masking; an STS phase (for Shared Time Slot in English) which corresponds in the particular embodiment described here to a single time slot shared between the nodes of the network; and a CTS phase (for Collision Time Slot in English) which corresponds to a time interval for sending access requests to the STS shared time slot. The durations are given by way of example and are not limiting.

Within a SDTC cycle, each node involved in the synchronous data transmission sends at least one radio packet. In a preferred embodiment of the invention, 6 radio packets are transmitted in a predefined sequence: the first 2 packets (10, 11) of a SDTC cycle are transmitted by the node 5 of type WAD, SCM # O; and the following 4 packets (12, 13, 14, 15) are transmitted by WAR nodes, for example in a predefined order: SCM # 2, SCM # 3, SCM # 5, SCM # 4. SCM # 1, SCM # 6, SCM # 7, and SCM # 8 do not have a predefined time interval. They must then use the STS shared time slot to transmit a radio packet 16. The transmission of a request for the reservation of a shared time slot is performed during the CTS collision time slot 17. In this case, Regarding data processing, during the same SDTC cycle, each synchronous communication module must process 8 (in the case where STPR = 8) SDPC cycles 1054 to 1754, each having a duration equal to 1251Lts. During each SDPC cycle, the synchronous communication module SCM handles the processing of the 54 virtual channel samples and only some of them are represented in FIG. 2. Among others, the samples 1000, 1030, 1031, 1053 will be processed during the SDPC cycle 1054 , the sample 1100, during the SDPC cycle 1154 and the samples 1700, 1730, 1753 during the SDPC cycle 1754. A radio packet consists first of a preamble 54, then of a field 50 head said RPH (for Radio Packet Header in English) and finally a field of useful data 55, said RPP (for Radio Packet Payload in English). Preamble 54 allows the receiver to synchronize and locate the beginning of the packet.

The header field 50 includes at least the number of the time interval in which the radio packet is transmitted, and the identifier of the node that transmits this packet. The SCM # O module is arbitrarily designated as the master node that dictates the timing of the SDTC cycles. The SCM modules of the other nodes, called slave nodes, must locally reproduce a timing of the SDTC cycles in phase with the master node. To do this, a slave node uses the detection of a start of radio packet reception, as well as the number of the time slot of the header of the packet to be in the SDTC cycle. With this information, a slave node slaved its local timing SDTC cycles on that of the master.

Furthermore, the RPP field 55 is divided into a set of radio data block RDB 20 to 49 (for Radio Data Block in English) of a length of 58 bytes after adding an error correction code (for example 8 redundancy bytes are added to the VC Chunk container). An RDB block may contain data specific to the transmitting node, or data to be repeated from other nodes of the network.

For all radio packets, the RPP field contains 29 RDB blocks. Thus, in our example, and in accordance with the field 112 of the synchronous bandwidth distribution matrix illustrated in FIG. 3, the SCM # O node transmits a radio packet 11, consisting of an RPP field 55, which notably contains the block of RDB radio data 26, containing 8 samples of VC # 30 generated by this SCM # O node during the previous SDTC cycle and transmitted for the first time during the current cycle. To take another example, still in this same radio packet 11, there is the radio data block RDB 48, corresponding to the retransmission of the 8 samples of the VC # 53 transmitted during the previous SDTC cycle by the node SCM # 5, in accordance with FIG. at field 119 of the synchronous bandwidth distribution matrix illustrated in FIG. 3. FIG. 3 schematically illustrates the distribution matrix of the synchronous bandwidth initialized at the start of the system by the CPU 87 processor of FIG. 4 (more fully described by FIG. the following). This matrix represents the contents of each radio packet transmitted in the PTS phase of the SDTC cycle. A complete cycle of synchronous data transmission is divided into 174 blocks of RDB radio data corresponding to the transmission of six radio packets per SDTC cycle, each radio packet comprising 29 RDB blocks. The lines 100, 110, 120, 130, 140, 150 of the matrix each describe the contents of the RDB fields of the 6 radio packets transmitted respectively by the SCM # O modules (which is the only one to emit two consecutive packets and which is the node master), SCM # 2, SCM # 3, SCM # 4, SCM # 5. Each line of the matrix is thus composed of 29 elements each representative of an RDB radio data block according to its position in the radio packet. For a simplified representation, the larger fields, such as the field 101, describe 6 elements of the matrix, while the others, such as the field 105, describe only one element for the sake of simplification of the figure. 3.

Thus, the field 101 contains the elements representing 6 blocks RDB (0, j) for j varying from 0 to 5. The field 105 contains a single element, which is representative of the RDB block (0, 24). The channel capacity distribution matrix describes the meaning of the different RDB fields (i, j), (i <5; j <28), during a SDTC cycle.

For 54 of these RDB radio data blocks, the transported useful information contains a newly transmitted VC Chunk container (present for the first time). These are fields 101 to 105, 111 to 115, and fields 125, 135, 145, 155. For the other 120 of these RDB radio data blocks, the transported useful information contains a previously received VC Chunk container. then retransmitted (ie relayed), which is either from the same SDTC cycle (n), or from one or more previous SDTC (nm) cycles. In our particular embodiment of the invention, the retransmission is limited to the previous cycle only (m = 1). Thus, the fields 141 to 144, 151 to 154, 136, 137, 146 to 148, 156 to 159, are representative of 57 RDB blocks retransmitted during the same cycle SDTC (n) that of their first transmission. The remaining fields, representative of the remaining 63 RDB blocks, identify retransmitted (or relayed) RDB blocks, the first transmission of which was done during the previous SDTC (n-1) cycle. In a particular embodiment of the invention, it is required that each RDB block be transmitted up to 6 times with a minimum of 3 times, which partly characterizes the distribution of the RDB blocks within the channel capacity matrix. . The audio data corresponding to fields 101 to 104 and 111 to 114 will be transmitted 3 times. The additional control data corresponding to fields 105, 115, 125, 135, 145, 155 will be transmitted 5 times. For each element of the synchronous bandwidth distribution matrix, there is at least the following information: a VCB (Virtual Channel Bank) field indicates a synchronous band number with which the virtual channel of the VC container is associated Chunk. It is a common identifier for VC virtual channels assigned to the transmission of the same content. In the example described, there is one VCB band audio, that is to say 8 VCB bands in total. A VCB band is thus composed of 6 virtual VC channels. All VC virtual channels belonging to the same VCB band will indicate the same predefined value for this VCB field. This field is optional and for example an undefined value for VC virtual channels 48 to 53 for the transport of additional (control) data. a VC field indicates the virtual channel number of the VC Chunk container; an Rx field indicates whether the node is destination of the virtual channel (value = `1 ') or not (value =` 0'); - a STDC field indicates the cycle in which the VC Chunk container was transmitted for the first time, a STDC field of a current cycle taking the value `0 'or a STDC field of a previous cycle taking the value` 1 '; a Repeat field indicates whether it is an RDB block to be repeated (value = `1 ') or not (value =' 0. For example, for the element of the matrix corresponding to the 61st block RDB of the first radio packet transmitted in a SDTC cycle: RDB (1; 6) = {VCB = 6; VC = 30; Rx = INDEFINI; SDTC = 0; Repeat = 0;}. In the figure, the Rx, SDTC, and Repeat fields The choice of repeater nodes is not an innocuous one, it depends on the topology of the network.The SCM # 2, SCM # 3, SCM # 4, SCM # 5 are well placed to repeat the audio data transmitted by the SCM # 0. Thanks to the repetitions, all the nodes of the network receive several copies of the same data by different radio paths.The different copies are then compared to locate the errors, and the The decoder associated with the error correction code is applied to correct the errors, as illustrated in Figures 2 and 3. transmission is fixed and identical for all virtual channels. In the particular embodiment of the invention, the latency for a VC is exactly three SDTC cycles. This is the latency between the writing in the sending node of a 48-bit sample in the SDPC cycle k of the SDTC cycle n, and the reading in the receiving node of this same sample in the cycle SDPC k of the cycle SDTC n + 3.

FIG. 4 schematically illustrates an architecture of a synchronous communication module. The synchronous communication module consists of a CPU 87 processor (for Central Processing Unit in English) to which is associated a block of RAM RAM 86 (for Random Access Memory in English) and a block of non-volatile memory ROM 85 (for Read Only Memory in English). The processor CPU 87 communicates with the communication module 84 through the block 93 (denoted CPU IF which notably manages the interrupt signals intended for the processor, as well as the data exchanges between the different blocks of the communication device 84 and the CPU 87 processor.

Thus, at the initialization of the system, the CPU 87 performs the transfer of the configuration information, in particular the synchronous bandwidth distribution matrix, from the memory 85 to the interface block 93. Possibly a configuration choice can be made. performed among several configurations, all stored in ROM 86, based on user information the system environment and on the application. After starting the system, the CPUs of the different nodes of the network are able to exchange protocol messages via virtual control channels. The processor CPU 87 also supports the control of the radio interface module 99 (denoted RF IF) by defining in particular the operation to be performed (transmission, reception) and the configuration of the antennas for each time interval of the SDTC cycle. Finally, the CPU 87 provided to block 95 the data to be transmitted in the case of an access request in the CTS collision time interval and the data to be transmitted in the case of a radio packet in the interval STS time share. Likewise, the processor CPU 87 retrieves from block 94 the access requests received in the collision time interval CTS and the received radio packets in the shared time interval STS. The communication module 84 ensures the transfer of the synchronous data between the radio interface block 99 at 60 GHz and the synchronous interface block 98 (noted Audio IF) to / from the audio channel processing module 82, which is located be either a digital audio channel amplifier (or Digital Audio Channel Amplifier in English), or a multi-channel audio decoder (or Surround sound decoder in English). Within the device 84 is on the processing side of the synchronous data, the write block 89 and the block 88 for reading VC Chunks containers. The write block 89 is responsible for constructing the VC Chunks containers from the virtual VC channels written at each SDPC cycle as described in connection with FIG. 2. In the SCM # 0 module, the samples of the virtual audio channels 0 to 47 as well as the virtual control channel 48 are provided by the interface block 98. The samples of the virtual control channel 49 are provided by the CPU 87 through the interface block 93. In the SCM module # 2, the block 89 will only process the samples of the virtual channel 50 provided by the processor CPU 87. On the other hand, the read block 88 is responsible for extracting the virtual channels from the VC Chunk containers received and returning them, for each SDPC cycle, either at the interface block 98 or at the processor CPU 87 via the interface block 93. Thus, for example, in the SCM module # 2, the samples of the virtual audio channels 6 to 11 and that the virtual control channel 48 are transmitted at the radio interface block 98. The samples of the virtual control channels 49, 51, 52, 53 are supplied to the CPU 87 via the interface block 93.

During a SDTC cycle, the device 84 must perform the reading and writing of all the samples corresponding to the virtual channels it has to process for 8 consecutive SDPC cycles (this in the case where STPR = 8). Within the device 84 is, on the transmission side of the synchronous data, the transmission block 95 and the radio packet reception block 94. The block 95 includes the modulation functions, for example OFDM type, and preamble insertion indicating the start of transmission of a radio packet. Thus the block 94 performs the inverse functions of those implemented in the block 95, including demodulation, and detection of the preamble indicating the beginning of reception of a radio packet.

Block 92 is responsible for coding VC Chunk containers to create the RDB radio data blocks to be transmitted. After encoding, the RDB blocks are stored in a synchronous transmission buffer (or buffer) located in the block 95. The block 91 is responsible for decoding the received RDB radio data blocks. After decoding, VC Chunk containers are stored in a buffer located in block 88. Block 91 for retransmitting RDB radio data blocks retrieves some of the RDB blocks received by block 94, and stores them before retransmission by the block. 95.

The synchronization block 97 controls the regular sequence of SDTC cycles. The start cycle signal SDTC is supplied to all the blocks of the node, in particular to the processor CPU 87 via the interface block 93. The synchronization block 97 controls the synchronization block 96 which controls it the regular sequence SDPC cycles, for a perfectly synchronous transfer of samples, for each virtual channel, between blocks 88 and 89 and block 98. Synchronization block 97 also defines the beginning of each time slot of a SDTC cycle. The signal marking the start of a time interval or the beginning of a CTS collision time interval is provided to the radio packet transmission block 95, the radio packet reception block 94, and the radio block. Figure 5 schematically illustrates the data stored in the RAM 86 and managed by the CPU 87 for the implementation of the present invention. In the particular embodiment of the invention, the fixed latency between the sending of an access request to a shared time slot and the effective access to this time slot is 5 super-frames (c '). that is, 5 SDTC cycles). An access request transmitted in the SDTC cycle n, is followed by the operation of writing the control channels in the cycle n + 1, then the transmission (and repetitions) of the control channels in the cycles n + 2 and n + 3, then the reading of the control channels in the n + 4 cycle, and finally the determination of the winning node in the n + 5 cycle. Thus, the RAM 86 has six memory areas 500, 501, 502, 503, 504, 505 containing the same type of information but for different SDTC cycles (as well as SDTC cycles necessary to perform the constant duration arbitration for access to the STS timeslot of a given cycle). The processor CPU 87 manages a counter changing from 0 to 5, which is incremented at the beginning of cycle SDTC and which indicates (modulo 5) the table number corresponding to the current SDTC cycle. If this counter is 3, this means that the information for the current SDTC cycle (noted n) is in table 3 (element 503) and is therefore stored in RAM 86 from the base address of the table. 3 (element 503). As a result, the table 4 (element 504) contains the information for the SDTC cycle n + 1 following the current cycle n, the table 5 (element 505) contains the information for the cycle SDTC n + 2, the table 0 (element 500) contains the information for the SDTC cycle n + 3, the table 1 (element 501) contains the information for the SDTC cycle n + 4, the table 2 (element 502) contains the information for the cycle SDTC n + 5. This memory management therefore makes it possible to continuously manage access to the shared time slot for 5 consecutive super-frames (or consecutive SDTC cycles). Each memory zone corresponds to a table that contains three fields. In Figure 5 are shown only the reference fields 520 to 522 for the table 502.

The packet state field 520 indicates whether an asynchronous packet is to be transmitted in the shared time interval STS of the SDTC cycle corresponding to this table. This field also contains the identifier of the packet to be transmitted. The asynchronous packets to be transmitted are stored in an unrepresented queue. The request receive status field 521 gives the list of the nodes using the PTS phase, for which access requests have been received from requesting nodes issuing an access request for the STS shared time slot corresponding to this table. In the remainder of the description, these access requests originating from requesting nodes and relayed during the PTS phase are called confirmations of access requests or else relayed access requests. The request receive state field 521 is a vector where each bit corresponds to a node of the network. A bit with the value `1 'means that the corresponding node is a node that has been assigned a time slot in the PTS phase and that access request confirmations from that node have not been received. To have the right to use an STS time slot, it is necessary that this field is null, ie it is necessary to know all the access request confirmations of all the nodes using the phase. PTS. At the initialization of the table, the bits corresponding to the nodes with time interval in the PTS phase have the value `l '.

In an alternative embodiment of the invention, it is not necessary to obtain access request confirmations from all nodes using the PTS phase. A predetermined set of nodes may be predefined and be a subset of the nodes using the PTS phase. For example, this set of nodes can be predefined according to their geographical location within the communication network. Indeed, within a wireless communication network such as the network of Figure 1 implementing a home cinema type application, some nodes can have privileged positions in the communication network. For example, the communication node attached to the loudspeaker restoring the central channel and those attached to the speakers restoring the side channels, allow, despite the presence of at least one user of the home cinema application to relay ( as part of normal use of the application) a message to all nodes of the network, and this through the use of quasi-omnidirectional antenna (that is to say, broad-spectrum angular of radiation, for example between 90 ° and 180 °). The query list field 522 stores access request confirmations as they are received. The processor CPU 87 will be in charge of sorting these access requests to determine the priority node that will be authorized to use the STS shared time slot corresponding to this table.

This sorting is performed following the receipt of access request confirmations. However, for a node that has received the access requests during the relevant CTS collision time interval, a ranking (or pre-ranking) of the received requests can then be made at the end of this CTS collision time interval. . This speeds up the decision-making process as the STS timeslot arrives. However, in order to confirm or adapt the classification obtained, it remains to wait for the receipt of access request confirmations from all the nodes using the PTS phase. For a node that issued an access request during a CTS collision interval to be able to use the STS shared time slot concerned, its own node identifier must be declared as a priority at the end of this sorting process. . FIG. 6 schematically illustrates the operation of an SCM communication module according to a particular embodiment of the invention.

After starting the system and initializing the various blocks described in relation to FIG. 4, the processor CPU 87 goes into the synchronization standby position of the node in a step 600. For the SCM # O module of the master node, the state synchronized is immediate and permanent. For other nodes (slave nodes), it is necessary to wait for the reception of the first radio packets from the PTS phase of the next SDTC cycle (s). The changeover to the synchronization state is indicated by the cycle controller SDTC 97 in a step 601. Then, in a next step 602, the processor CPU 87 waits for one of the following four events: a desynchronization signal or ; a start signal of a new cycle SDTC or; a reception signal of one or more access requests to the shared time interval STS or; a signal for receiving one or more messages via virtual control channels.

In the case of desynchronization (step 610) indicated by the cycle controller SDTC 97, the processor CPU 87 then performs, in a step 611, a reading of the tables 500 to 505 in order to identify the asynchronous packets being processed. These packets are purged from the queue and the packet generating application is informed of the transmission failure. Then, CPU 87 resets tables 500 to 505, resets the counter pointing to the representative table of the current SDTC cycle (noted n), and then returns to step 600 waiting for synchronization. A slave node is declared out of sync if it has no longer received radio packets from the PTS phase for a predefined number of consecutive SDTC cycles.

In the case of the start of cycle SDTC (step 620) indicated by the cycle controller SDTC 97, the processor CPU 87 increments, in a step 621, the counter pointing to the representative table of the current SDTC cycle (denoted n). In a next step 622, the processor CPU 87 first performs the processing consecutive to the operation performed at the previous STS shared time interval (thus in the SDTC cycle n-1). For this, the processor CPU 87 reads the packet state field of the representative table of the cycle SDTC n + 5 (which previously pointed to the current SDTC cycle). If an asynchronous packet was to be transmitted, the processor CPU 87 reads an internal register to the radio packet transmission block 95 to know the result of the transmission. This result is transmitted to the application generating the packet, and if the transmission has failed the application may later request a retransmission. If there was no asynchronous packet to be transmitted, the processor CPU 87 reads an internal register to the radio packet reception block 94 to know if a packet has been received. If this is the case, the packet is retrieved by reading the asynchronous reception buffer (or buffer) of block 94, and the packet is transmitted to the application. Once these operations have been performed, the CPU 87 can reset the representative table of the SDTC cycle n + 5, which is therefore free.

Then a step 623 is executed. This step 623 corresponds to an analysis of the queue where the asynchronous packets to be transmitted are stored. If a new packet is to be processed, it is necessary to send an access request in the CTS collision interval of the current SDTC cycle. For this, in a step 624, the processor CPU 87 constructs the request message which comprises the local identifier of the node (one byte) and a priority information (one byte) according to a chosen criterion. For example, the priority information may be a value representative of an access rate by the node considered at the shared time slot STS (a node that has rarely had access to the shared time slot STS will have a high priority). Other priority criteria are possible. For example, it is possible to use a generated number (pseudo-) randomly and to classify the access requests according to the random number they contain. In addition, this priority information is dispensable when using a priority criterion based on a classification of access requests according to the local identifier (unique in the network) of the node. To the payload of the access request, redundancy bytes are added to enable the detection of transmission errors. In addition, the processor CPU 87 calculates a pseudo-random delay which corresponds to the delay to wait after the start of the CTS collision time interval before transmission of the access request. This waiting time makes it possible to limit the cases of collision where several access requests are transmitted at the same time by different nodes. Once the access request is constructed, it is written in the access request transmission buffer of the radio transmission block 95, the delay before transmission is written in an internal register. CPU 87 also configures radio interface module 99 for the upcoming CTS collision time interval indicating that the transmit mode will be used. To finish this step, the processor CPU 87 updates the packet status field of the table associated with the SDTC cycle n + 5. Then a step 625 is executed (this step is more fully described later). If no new packet is to be processed, step 625 is directly executed. In step 625, CPU 87 focuses on determining which node is allowed to access the STS shared time slot in the current SDTC cycle (denoted n). For this, it performs a reading of the query list field of the table associated with the cycle SDTC n. If confirmations of access requests have been received, the access requests are sorted in order of priority according to the criterion chosen, and the identifier of the priority node is stored.

Then a step 626 makes it possible to check whether the access to the shared time slot is authorized. If the identifier of the priority node determined in step 625 is not the local identifier, access is not allowed. In this case, in a step 628, the packet status field of the table associated with the cycle SDTC n is read, to know if an asynchronous packet was to be transmitted. If no asynchronous packet was to be transmitted (step 628), a step 630 is directly executed.

If an asynchronous packet was to be transmitted (step 628) then, in a step 629, the processor CPU 87 purges the packet from the queue, informs the application generating the packet of the failure of the transmission, and sets day the packet status field of the table indicating that no packet is to be transmitted. If the identifier of the priority node determined in step 625 corresponds to the local identifier, access to the shared time interval STS is possible (step 626). Before granting access, however, the processor CPU 87 must read the request reception status field of the table associated with the SDTC cycle n. If this field is not null, the control information of all the nodes has not been received. Access to the STS shared time slot is then denied and the previously described step 628 is directly executed. This verification is necessary because if all the elements are not known, there is always a risk of mistakenly selecting a priority node. There is therefore always a potential risk of collision in the STS time slot. If the request receive state field is zero, access to the STS shared time slot of the current SDTC cycle is allowed (step 626). The CPU 87 can then proceed, in a step 627, the transfer of the packet in the buffer (or buffer in English) asynchronous transmission of the radio packet transmission block 95. In a subsequent step 630, the processor CPU 87 configures the radio interface module 99 for the upcoming STS time slot. For example, it indicates the mode (transmission or reception) and the configuration of the antenna taking into account the results of steps 625 to 629. Then in a step 631, the processor CPU 87 prepares the sending of confirmations of access requests received in the CTS collision interval of the previous SDTC cycle (i.e., n-1). This is obviously only valid for a node which has been assigned a time slot in the PTS phase. The processor CPU 87 reads the query list field from the table associated with the SDTC cycle n + 4. This field has been entered in the previous SDTC cycle according to the description of steps 640 and 641, more fully described in the following description. If this field is not empty, the processor CPU 87 writes a control message to the control transmission buffer (buffer) in VC Chunk container write block 89. This message consists of: - a header field with a byte to indicate the contents of the message and a byte to indicate the size (in bytes) of the message; a data field that corresponds to the list of requests of the table. The size of the data field depends on the number of stored access requests, but the size of the message must remain smaller than the size of a VC Chunk container to ensure a fixed transmission latency for the entire data field. Four modules (SCM # 1, SCM # 6, SCM # 7, and SCM # 8) are capable of sending access requests, placing themselves in a particular embodiment of the invention where the nodes that can access the timeslot are those that have not been assigned time slots of the PTS phase. The maximum size of this type of control message will therefore be 10 bytes. Because the capacity of a VC Chunk container is 48 bytes, there will be 38 free bytes left to carry other information in the control VC Chunk container. After step 631 the CPU 87 has completed the processes triggered by the start of a new SDTC cycle. It then positions itself again on hold (step 602). Or now the case of processing following the receipt of access request, in a step 640, by the block 94 radio packet reception. This event occurs at the end of the CTS collision time interval if access requests have been detected by the block 94. In a next step 641, the processor CPU 87 will then read the request receive buffer. access block 94 and store, in the table corresponding to the cycle SDTC n + 5 among the tables 500 to 505, access requests read. It then positions itself again on hold (step 602). Chronologically, the operation performed in step 641 occurs well after the operations of steps 622 to 624. The newly registered access requests are written to a VC virtual control channel at the next SDTC cycle (ie say n + 1). The corresponding RDB block (Radio Data Block) is transmitted on the medium during SDTC cycles n + 2 and n + 3. These access requests are then received by all nodes of the network at the SDTC cycle n + 4. They are part of the information processed by all the nodes of the network to determine the node authorized to access the shared time slot STS of the cycle SDTC n + 5.

When the processor CPU 87 receives the signal receiving control message (s) in step 650, it will eventually be possible to complete the list of confirmed access requests for access to the STS shared time slot of the next SDTC cycle. This information contained in the control channels was constructed three SDTC cycles earlier, as described in step 631. Then this information was transmitted on the medium for two SDTC cycles according to the distribution matrix of FIG. 5. It is the VC Chunk container read block 88 which signals the receipt of control message (s) to the processor CPU 87 via the interface block 93. For example, at the SCM # 2 module, the Control messages may be received by the four VC Chunk containers respectively containing the virtual channels 49 (of SCM # O), 51 (of SCM # 3), 52 (of SCM # 4), 53 (of SCM # 5). In block 88, four message buffers are reserved: one for SCM # O messages, one for SCM # 3 messages, one for SCM # 4 messages and one for messages. of the SCM # 5 module.

At each SDPC cycle, the block 88 extracts from each VC Chunk container received the data of the virtual channel associated with the current SDPC cycle. For example, if a node receives the VC Chunk # 2 container, it contains 16 virtual VC channels: the VC # 2 virtual channel of the SDPC # O cycle, the VC # 2 virtual channel # 2 of the SDPC cycle, and so on. to VC # 2 virtual channel of the SDPC # 15 cycle. When starting a new SDPC cycle, for example the fifth of the super frame (SDPC cycle # 4), it is the fifth VC virtual channel that is extracted from the VC Chunk container. When the block 88 reads the contents of a virtual channel, if this virtual channel VC does not contain valid data, the block 88 proceeds to the processing of the next VC virtual channel without doing anything. If the VC virtual channel contains valid 48-bit data, this data is written to the corresponding receive buffer. Therefore, if the virtual channel 51 contains valid data, it is written to the message receiving buffer associated with the SCM # 3 module. In step 650, the VC Chunk container play block 88 has finished reading all the virtual channels for the 8 SDPC cycles that make up an SDTC cycle. Chronologically, this is the end of the SDTC cycle. In a next step 651, the processor CPU 87 reads the contents of each message receiving buffer. Each message is popped and the header analyzed in a step 652.

For the implementation of a particular embodiment of the invention, only the request confirmation type messages are used. When this type of message is detected (step 652), then in a step 653, the data field of each message is written in the table 500 to 505 associated with the cycle SDTC n + 1.

If a confirmation of access requests had already been entered previously in the table, it is not written in duplicate. Also at this stage, the processor CPU 87 updates the request reception status field of the table (the bit corresponding to the node having sent a message of request confirmation type takes the value '0'). The CPU 87 then performs step 602 again.

In this algorithm, it should be noted that the tables associated with SDTC cycles n + 2 and n + 3 are not subject to any processing. During these two SDTC cycles, the data of the control channels are transmitted on the medium during the PTS phase according to the distribution matrix described in FIG.

The flowchart of FIG. 7 schematically illustrates the operation of the radio packet transmission block 95. In a step 700, the block 95 is waiting for a start of a new time interval, whether it is the beginning of a time interval of the PTS phase, the beginning of the CTS collision interval, or the beginning the STS time share interval. This event is indicated by the SDTC 97 cycle controller in a next step 701. In a step 702, the block 95 checks whether it is the beginning of the CTS collision interval. If this is the case, the block 95 checks, in a step 703, whether an access request to be transmitted is present in its access request transmission buffer. If an access request to be transmitted is present, the block 95 reads the register accessible by the processor CPU 87 indicating the delay to wait before transmission. After waiting for this delay in a step 704, the block 95 proceeds, in a step 705, to the transmission of the access request, then returns to the waiting position of a new time interval (step 700). If in step 702 it was not a start of the CTS collision interval, block 95 then checks, in a step 706, whether this is the beginning of the time interval. shared STS. If this is the case, the block 95 checks, in a step 707, whether a packet to be transmitted is present in its asynchronous packet transmission buffer. If a packet to be transmitted is present in its asynchronous packet transmission buffer, the block 95 proceeds, in a step 708, to the transmission of the asynchronous packet.

At the end of transmission, the block 95 fills an internal register accessible by the processor CPU 87 indicating the positive result of the transmission. Block 95 then returns to the waiting position of a new time interval (step 700). If the test of step 706 is negative, it is a start of a time interval of the PTS phase. Since the block 95 knows the TDMA sequence (that is to say the access sequence to the medium according to the assignments of the time intervals from the PTS phase to the nodes of the network), it is able to determine, in a step 709 if it is a time slot reserved for the node to which it belongs.

If it is not a time slot reserved for the node to which it belongs, the block 95 returns directly to the waiting position of a new time slot (step 700). If it is a time slot reserved for the node to which it belongs, block 95 proceeds, in a step 710, to the transmission of the synchronous packet whose header field is constructed by block 95 and whose field data was provided by blocks 92 and 91. The data field includes the control channel of the sending node and possibly the repetition of control channels issued by other nodes. The block 95 can then return to the waiting position of a new time interval (step 700).

The flowchart of Figure 8 schematically illustrates the operation of the radio packet receiving block 94. In a step 800, the block 94 is waiting for a start of a new time interval, whether it is the beginning of a time interval of the PTS phase, the beginning of the CTS collision interval, or the beginning the STS time share interval. This event is indicated by the SDTC 97 cycle controller in a step 801. In a step 802, the block 94 checks whether it is the beginning of the CTS collision interval. If it is the beginning of the CTS collision interval, the block 94 attempts to detect a radio preamble in a step 804 until the CTS collision interval has expired. During the CTS collision interval, the radio interface module 99 is in the reception position unless an access request transmission has been requested by the CPU 87. If no preamble is detected at step 804 a step 806 is directly executed. This step 806 consists in checking, by block 94, whether this is the end of the collision interval CTS. If a preamble is detected in step 804, the packet, which contains a priori an access request, is stored in a step 805. In a step 806, the block 94 checks whether it is the end of the CTS collision interval. If the test is negative at step 806, block 94 attempts to detect other packet receptions. At the end of the CTS collision interval, in a step 807, the block 94 checks for each received packet that there have been no transmission errors and stores the valid access requests in its buffer memory. , receiving access requests. At the end of this step, block 94 sends an interrupt signal to CPU 87 to signal receipt of valid access requests. Block 94 then returns to the waiting position of a new time interval. If in step 802 it is not the beginning of the CTS collision interval, the block 94 then checks, in a step 808, whether it is the beginning of the STS shared time slot. If this is the case, the block 94 tries to detect a radio preamble in a step 809 until a predefined delay has elapsed. During the STS time slot, the radio interface module 99 is in the receiving position unless an asynchronous packet transmission has been requested by the CPU 87.

If in step 809 no preamble is detected after a predefined delay, there are three possibilities: - no node has asynchronous packet to transmit or; the local node (to which the block 94 belongs) is the transmitter of the asynchronous packet or else; another node issues an asynchronous packet but a masking or remoteness prevents the reception of this packet. A step 810 makes it possible to check whether a predetermined delay is reached. If it is not, step 809 is executed again.

If this is the case, the block 94 returns directly to the waiting position of a new time interval (step 800). If in step 809 a preamble is detected, the asynchronous packet is received and stored in the asynchronous message receiving buffer in a step 811.

At the end of reception, the block 94 fills an internal register accessible by the processor CPU 87 by indicating that an asynchronous packet (or lean) has been received. Block 94 can then return to the waiting position of a new time interval (step 800). If the test of step 808 is negative, it is a start of the PTS phase time interval. In a step 812, the block 94 then tries to detect a radio preamble until a predefined delay has elapsed. During each time period of the PTS phase, the radio interface module 99 is in the reception position unless a synchronous packet transmission is provided (i.e. if the time slot is assigned to the node at which block 94 belongs). If no preamble is detected after a predefined delay in step 812, there are two possibilities: either the local node (to which block 94 belongs) is the transmitter of the synchronous packet; - Or another node sends a synchronous packet but a masking or removal prevents the reception of this packet. A step 813 makes it possible to check whether a predetermined delay is reached. If it is not, step 812 is executed again.

If this is the case, the block 94 returns directly to the waiting position of a new time interval (step 800). If during step 812 a preamble is detected, the synchronous packet is received in a step 814. The header field of the packet is transmitted to the cycle controller SDTC 97 which manages the synchronization and the data field is transmitted to the decoding block 90. The data field includes virtual control channels transmitted by other nodes according to the distribution matrix of FIG. 5. Block 94 can then return to the waiting position of a new time interval.

The description of FIGS. 6 to 8 above refers to a particular embodiment of the invention for which each requesting node is able to make the decision whether or not to access the STS shared time slot as a function of the requests ( or indication of requests) relayed by the nodes having (at least) a pre-assigned time slot in the PTS phase. It is also possible in this embodiment that a non-requesting node can determine which requesting node has obtained access permission to the shared time slot. This information can then enable this node to parameterize its reception antenna so as to capture, during the shared time interval STS, the signals transmitted by the requesting node having obtained access authorization to the time interval. shared STS.

An alternative embodiment uses a decision node, which validates the network access permissions during the shared time slot, from requests issued during the CTS collision interval. The general principle rests in this case also on the transmission, by nodes having time slots pre-assigned during the PTS phase, queries (or indications of these queries) that were detected by these nodes during the phase PTS . As in the case of a distributed implementation environment, nodes having pre-allocated time slots during the PTS phase can (or not) retransmit according to a repetition scheme defined by the band distribution matrix synchronous pass-through (see FIG. 3), the requests (or indications of these requests) that have been detected by other nodes having pre-allocated time slots during the PTS phase. It is then sufficient for the decision-making node to transmit the result of the decision regarding access to the STS at least to the requesting node whose request has been selected as a priority. To do so, the decision-making node may for example have a pre-assigned time slot during the PTS phase. This decision may also be relayed by nodes having time slots pre-assigned during the PTS phase. It will be noted that the invention is not limited to a purely material implantation but that it can also be implemented in the form of a sequence of instructions of a computer program or any form mixing a material part and a part software. In the case where the invention is partially or totally implemented in software form, the corresponding instruction sequence can be stored in a removable storage means (such as for example a floppy disk, a CD-ROM or a DVD-ROM) or no, this storage means being partially or completely readable by a computer or a microprocessor.

Claims (16)

REVENDICATIONS1. A method of managing access to a communication network during a shared time slot (STS), a collision time interval (CTS) for issuing a request for access to the shared time slot (STS) a predetermined set of at least one node each having at least one pre-assigned time slot (PTS) for accessing said network, characterized in that a decision node performs steps of: - receiving (640) during the pre-assigned time slot (PTS), information indicating, for each node of said predetermined set, whether or not said node has detected at least one request for access to the shared time slot ( STS); determining (625), among the request or requests for which a positive reception indication has been received, a priority access request according to at least one predetermined selection criterion; and that access to said shared time interval (STS) is allowed at the node that issued said priority access request during the collision time interval (CTS). The method of claim 1, characterized in that each node of said predetermined set relays each access request to the shared time slot (STS) that said node has detected during said collision time interval. 3. Method according to any one of claims 1 and 2, characterized in that, if the network comprises only one said decision-making node, said step (625) of determining the priority access request is also performed among access requests received during the collision time interval by said decision node. The method according to any one of claims 1 to 3, characterized in that when a node of said predetermined set detects a plurality of requests for access to the shared time interval (STS) transmitted during said collision time interval, said node of said predetermined set performs a step of classifying, in a list, said detected access requests based on said predetermined selection criterion, and that it transmits during its pre-assigned time slot (PTS) information relating to a given priority request, among said detected access requests, according to the predetermined selection criterion. 5. A method according to any one of claims 1 to 4, characterized in that each node of said predetermined set relays, during its pre-assigned time interval (PTS), the request receive indication indication information. access to the shared time interval (STS) detected by at least one other node of said predetermined set during the collision time interval (CTS). 6. Method according to any one of claims 1 to 5, a requesting node being a node issuing a request for access to the shared time interval (STS), characterized in that, if each requesting node is a said node decision-maker, said decision-making node performs steps of: - issuing an access request, during said collision time interval (CTS); transmitting data on said network during said shared time slot, if said priority access request is identical to the access request transmitted by said given requesting node. 7. Method according to any one of claims 1 to 5, a requesting node being a node issuing a request for access to the shared time interval (STS), characterized in that, if said decision node is not a requesting node, said decision node performs a step of transmitting, to the requesting node having previously transmitted said priority access request, information allowing said requesting node to access said network during said shared time interval (STS). 8. Method according to any one of claims 1 to 7, characterized in that the number of transmission cycles separating a transmission cycle in which has been transmitted an access request and a transmission cycle in which is located The shared time interval (STS) associated with the request is fixed and predetermined. 9. Computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, characterized in that it comprises program code instructions for the implementation of the method according to at least one of claims 1 to 8, when said program is run on a computer. A computer readable storage medium, possibly totally or partially removable, storing a computer program comprising a set of instructions executable by a computer for carrying out the method according to at least one of claims 1 to 8. 11. Decision node for the access management of at least one node to a communication network during a shared time slot (STS), a polling time interval (CTS) for issuing an access request to the shared time slot (STS), a predetermined set of at least one node each having at least one pre-allocated time slot (PTS) for accessing said network, characterized in that said decision node comprises: means for receiving, during the pre-assigned time slot (PTS) set, information indicating, for each node of said predetermined set, whether said node has detected at least one access request to the shared time slot (STS); means for determining, among the request or requests whose positive reception indication has been received, a priority access request as a function of at least one predetermined selection criterion; means for granting access to said shared time interval (STS) for the node having sent said priority access request during the collision time interval (CTS). The decision node according to claim 11, characterized in that each node of said predetermined set comprises means for relaying each request for access to the shared time interval (STS) transmitted during said collision time interval. 13. decision-making node according to any one of claims 11 to 12, characterized in that it comprises receiving means for receiving, during said collision interval, at least one request for access to the shared time slot, and in that, if the network comprises only a single said decision node, the priority access request is also determined among the access requests received during the collision time interval. 14. Decision-making node according to any one of claims 11 to 13, characterized in that each node of said predetermined set comprises means for detecting access request indication information for access to the shared time slot ( STS) detected by a node of said predetermined set during the collision time interval (CTS) and relayed by another node of said predetermined set during its pre-assigned time interval (PTS). A decision node according to any one of claims 11 to 14, a requesting node being a node transmitting a request for access to the shared time slot (STS), characterized in that, if each requesting node is a said decision-making node, said decision-making node further comprises: first means for transmitting an access request, during said collision time interval (CTS); second means for transmitting data on said network during said shared time slot, if said priority access request is identical to the access request transmitted by said given requesting node. 16. Decision node according to any one of claims 11 to 14, a requesting node being a node issuing a request for access to the shared time interval (STS), characterized in that, if said decision node is not a requesting node, said decision node comprises third transmission means, to the requesting node having previously sent said priority access request, information allowing said requesting node to access said network during said shared time slot ( STS) .15