GB2549967A

GB2549967A - Improved reservation of channels in an 802.11AX network

Info

Publication number: GB2549967A
Application number: GB1607810.7A
Authority: GB
Inventors: Viger Pascal; Baron Stéphane; Nezou Patrice
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-05-04
Filing date: 2016-05-04
Publication date: 2017-11-08
Also published as: GB201607810D0

Abstract

The invention relates to reservation of channels in an IEEE 802.11ax wireless network based on Carrier Sense Multiple Access with Collision Avoidance, CSMA/CA. An access point sends an Multi-User, MU, Request-to-Send, MU-RTS, frame which associates nodes with 20MHz channels, for instance through allocations of Resource Units, RUs, composing the 20MHz channels to the nodes. Based on the node-channel associations, the nodes build the same list(s) of ordered nodes. In case a node fails to send a Clear-to-Send, CTS, frame (reservation acknowledging frame) in response to the MU-RTS frame, a next node according to the list take over from the previous node to send such CTS frame if the communication channel is sensed as idle. As a higher number of nodes can send the CTS frames, there are more chances that a requested Transmit Opportunity, TXOP, be granted. Improves usage of network bandwidth.

Description

IMPROVED RESERVATION OF CHANNELS IN AN 802.11 AX NETWORK

FIELD OF THE INVENTION

The present invention relates generally to communication networks and more specifically to methods for reserving channels in a wireless network, and corresponding devices.

The invention finds application in wireless communication networks, in particular to the access of an 802.11 ax composite channel and of OFDMA Resource Units forming for instance an 802.11 ax composite channel for Uplink communication to the access point.

BACKGROUND OF THE INVENTION

Reservation of channels is used to secure availability of the channels for transmitting data without collision.

The IEEE 802.11 MAC standard defines a way wireless local area networks (WLANs) must work at the physical and medium access control (MAC) level. Typically, the 802.11 MAC (Medium Access Control) operating mode implements the well-known Distributed Coordination Function (DCF) which relies on a contention-based mechanism based on the so-called “Carrier Sense Multiple Access with Collision Avoidance” (CSMA/CA) technique.

The 802.11 medium access protocol standard or operating mode is mainly directed to the management of communication nodes waiting for the wireless medium to become idle so as to try to access to the wireless medium.

The network operating mode defined by the IEEE 802.11ac standard provides very high throughput (VHT) by, among other means, moving from the 2.4GHz band which is deemed to be highly susceptible to interference to the 5GHz band, thereby allowing for wider frequency contiguous channels of 80 MHz to be used, two of which may optionally be combined to get a 160 MHz composite channel as operating band of the wireless network.

The 802.11ac standard also provides control frames such as the Request-To-Send (RTS) and Clear-To-Send (CTS) frames, involved in a well-known RTS/CTS handshake, to allow reservation of composite channels of varying and predefined bandwidths of 20, 40 or 80 MHz, the composite channels being made of one or more channels that are contiguous within the operating band. The 160 MHz composite channel is possible by the combination of two 80 MHz composite channels within the 160 MHz operating band. The control frames specify the channel width (bandwidth) for the targeted (or “requested”) composite channel. A composite channel therefore consists of a primary channel on which a given node performs EDCA backoff procedure to access the medium, and of at least one secondary channel, of for example 20 MHz each. The primary channel is used by the communication nodes to sense whether or not the channel is idle, and the primary channel can be extended using the secondary channel or channels to form a composite channel.

Given a tree breakdown of the operating band into elementary 20 MHz channels, some secondary channels are named tertiary or quaternary channels.

According to the 802.11ac standard, all the transmissions, and thus the possible composite channels, include the primary channel. This is because the nodes perform full Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) and Network Allocation Vector (NAV) tracking on the primary channel only. The other channels are assigned as secondary channels, on which the 802.11ac nodes have only capability of CCA (clear channel assessment), i.e. detection of an availability state/status (idle or busy) of said secondary channel.

An issue with the use of composite channels as defined in the 802.11η or 802.11ac is that the 802.11η and 802.11ac-compliant nodes (i.e. HT nodes standing for High Throughput nodes) and the other legacy nodes (i.e. non-HT nodes compliant only with for instance 802.11a/b/g) have to co-exist within the same wireless network and thus have to share the 20 MHz channels.

To cope with this issue, the 802.11η and 802.11ac standards provide the possibility to duplicate control frames (e.g. RTS/CTS or CTS-to-Self or ACK frames to acknowledge correct or erroneous reception of the sent data) on each 20MHz channel in an 802.11a legacy format (called as “non-HT”) to establish a protection of the requested channels forming the whole composite channel, during the TXOP.

This is for any legacy 802.11a node that uses any of the 20 MHz channel involved in the composite channel to be aware of on-going communications on the 20 MHz channel used. As a result, the legacy node is prevented from initiating a new transmission until the end (as set on the NAV parameter) of the current composite channel TXOP granted to an 802.11n/ac node.

As originally proposed by 802.11η, a duplication of conventional 802.11a or “non-HT” transmission is provided to allow the two identical 20 MHz non-HT control frames to be sent simultaneously on both the primary channel and the secondary channels forming the requested and used composite channel.

This approach has been widened for 802.11ac to allow duplication over the channels forming an 80 MHz or 160 MHz composite channel. In the remainder of the present document, the “duplicated non-HT frame” or “duplicated non-HT control frame” or “duplicated control frame” means that the node device duplicates the conventional or “non-HT” transmission of a given control frame over secondary 20 MHz channels of the (40/80/160 MHz) operating band.

More recently, Institute of Electrical and Electronics Engineers (IEEE) officially approved the 802.11ax task group, as the successor of 802.11ac. The primary goal of the 802.11 ax task group consists in seeking for an improvement in data speed to wireless communicating devices used in dense deployment scenarios.

Recent developments in the 802.11 ax standard sought to optimize usage of the composite channel by multiple nodes in a wireless network having an access point (AP). Indeed, typical contents have important amount of data, for instance related to high-definition audio-visual real-time and interactive content. Furthermore, it is well-known that the performance of the CSMA/CA protocol used in the IEEE 802.11 standard deteriorates rapidly as the number of nodes and the amount of traffic increase, i.e. in dense WLAN scenarios.

In this context, multi-user (MU) transmission has been considered to allow multiple simultaneous transmissions to/from different users in both downlink (DL) and uplink (UL) directions from/to the AP. In the uplink to the AP, multi-user transmissions can be used to mitigate the collision probability by allowing multiple nodes to simultaneously transmit.

To actually perform such multi-user transmission, it has been proposed to split a granted 20MHz channel into one or more sub-channels, also referred to as resource units (RUs), that are shared in the frequency domain by the multiple nodes, based for instance on Orthogonal Frequency Division Multiple Access (OFDMA) technique. Each RU may be defined by a number of tones, the 20MHz channel containing up to 242 usable tones. OFDMA is a multi-user variation of OFDM which has emerged as a new key technology to improve efficiency in advanced infrastructure-based wireless networks. It combines OFDM on the physical layer with Frequency Division Multiple Access (FDMA) on the MAC layer, allowing different subcarriers to be assigned to different nodes in order to increase concurrency. Adjacent sub-carriers often experience similar channel conditions and are thus grouped to sub-channels: an OFDMA sub-channel or RU is thus a set of sub-carriers.

The multi-user feature of OFDMA allows the AP to assign different RUs to different nodes in order to increase competition. This may help to reduce contention and collisions inside 802.11 networks.

As currently envisaged, the granularity of such OFDMA sub-channels is finer than the original 20MHz channel band. Typically, a 2MHz or 5MHz sub-channel may be contemplated as a minimal width, therefore defining for instance 9 sub-channels or resource units within a single 20MHz channel.

To support multi-user uplink, i.e. uplink transmission to the 802.11ax access point (AP) during the granted TXOP, the 802.11 ax AP has to provide signalling information for the legacy nodes (non-802.11ax nodes) to set their NAV and for the 802.11 ax nodes to determine the allocation of the resource units RUs. It has been proposed for the AP to send a trigger frame (TF) to the 802.11 ax nodes to trigger uplink communications. A resource unit RU can be reserved for a specific node, in which case the AP indicates, in the TF, the node to which the RU is reserved. Such RU is called Scheduled RU. The indicated node does not need to perform contention on accessing a scheduled RU reserved to it.

Another kind of resource units can be accessed by the nodes using contention access. It means that the nodes compete for accessing such resource units. Such RUs are called Random RUs. A current version of IEEE 802.11ax extends the usage of the RTS/CTS handshake mechanism to multi-user UL/DL scenarios. It is known as the “MU-RTS/CTS procedure”.

According to the current version of the standard, the MU-RTS/CTS procedure allows an access point to reserve a TXOP for multi-user transmission through resource units, by sending a multi-user request control frame, noted MU-RTS frame, to request reservation of one or more 20MHz communication channels. The MU-RTS frame is considered as a variant of the above-mentioned trigger frame.

The MU-RTS trigger frame is duplicated on each requested 20MHz channel and solicits, on each 20MHz channel, the sending of a response frame or reservation acknowledging frame, CTS, by at least one node.

The standard specifies that the node sending the CTS frame should have been allocated one of the scheduled resource units.

In the conventional RTS/CTS handshake mechanism, the addressee node designated in the RA address field of the RTS frame is in charge of sending the responding CTS frame.

In sharp contrast, the multi-user context makes that several nodes may be assigned a Scheduled RU per each 20MHz channel.

The current version of the standard is not satisfactory as to how the access point efficiently designates one or the other of these several nodes, to optimize reservation of the requested composite channel over which MU UL and/or MU DL communications may take place.

SUMMARY OF INVENTION

The present invention seeks to overcome the foregoing concerns.

In this context, embodiments of the invention provides a method for reserving at least one communication channel in a wireless network comprising nodes, the method comprising the following steps, at a first node: receiving a multi-user request control frame from a second node, preferably an access point as indicated below, wherein the multi-user request control frame requests reservation of a transmission opportunity on one or more communication channels of the wireless network, the one or more communication channels including a plurality of resource units for exchanging data with the nodes during the reserved transmission opportunity; and upon receiving the multi-user request control frame: determining an ordered node list of some of the nodes, based on a content of the received multi-user request control frame, preferably based only on the sole content thereof, the ordered node list including an initial node and one or more subsequent nodes; and using the ordered node list to determine if and when said first node has to send a reservation acknowledging frame to the second node on one of the communication channels if sensed as idle by said first node, to acknowledge reservation of the communication channel.

Correspondingly, the embodiments of the invention also provide a communication device acting as a node in a wireless network comprising nodes, the communication device comprising at least one microprocessor configured for carrying out the steps of: receiving a multi-user request control frame from a second node, wherein the multiuser request control frame requests reservation of a transmission opportunity on one or more communication channels of the wireless network, the one or more communication channels including a plurality of resource units for exchanging data with the nodes during the reserved transmission opportunity; and upon receiving the multi-user request control frame: determining an ordered node list of some of the nodes, based on a content of the received multi-user request control frame, the ordered node list including an initial node and one or more subsequent nodes; and using the ordered node list to determine if and when said first node has to send a reservation acknowledging frame to the second node on one of the communication channels if sensed as idle by said first node, to acknowledge reservation of the communication channel.

As the nodes receive the same MU request control frame from the second node, they are all able to build the same ordered node list. Based on this “shared” list, an efficient acknowledgment of the MU request control frame to actually reserve the transmission opportunity TXOP is obtained. This is because, for instance by following the order of the list, the nodes avoid or drastically reduce risks of collision when acknowledging. In addition, contrary to the conventional approach, various nodes are involved in the acknowledgment, thereby increasing chances that the requested TXOP be actually reserved.

The result of the above is that a better use of the wireless network is obtained. Optional features of embodiments of the invention are defined in the appended claims. Some of these features are explained here below with reference to a method, while they can be transposed into system features dedicated to any communication device according to embodiments of the invention.

In some embodiments, using the ordered node list comprises: sensing the communication channel to determine whether any node preceding the first node in the ordered node list sends, on the communication channel, a reservation acknowledging frame to the second node in response to the multi-user request control frame, or not; and in case no preceding node has sent a reservation acknowledging frame within a predefined time period, sending the reservation acknowledging frame on the communication channel to the second node.

According to this provision, the first node takes over from any preceding node in the process of acknowledging the reservation of the TXOP. Compared to conventional approaches where a single node is designated to send the CTS frame, this provision increases the chances to have the TXOP actually reserved, in particular if the conventionally designated node experiences collision or hidden node.

In some specific embodiments, the predefined time period lasts n times an elementary duration, n being the number of nodes preceding the first node in the ordered node list, and the elementary duration being a fraction of a time required by any node to send a reservation acknowledging frame. Note that the predefined time period usually starts after a SIFS following reception of the multi-user request control frame.

In this configuration, the nodes taking over from previous nodes are able to detect the failure of these previous nodes quite quickly, i.e. without waiting for the whole timeslot required for sending an acknowledging (CTS) frame. Thus, the time required for the whole TXOP acknowledging process is kept reasonable, while reducing the risks that legacy nodes access the same channels if no acknowledging frame is sent quickly. A good ratio between the subsequent data transmission time and this required time is also kept.

Of course, said fraction should be preferably determined in such a way the nodes are able to detect the failure of any previous node in sending an acknowledging frame.

In alternative specific embodiments, the predefined time period lasts n times a timeslot required by any node to send a reservation acknowledging frame, n being the number of nodes preceding the first node in the ordered node list. Note that the predefined time period usually starts after a SIFS following reception of the multi-user request control frame, and a timeslot is made of a SIFS period plus the time required to actually send the CTS frame.

In other specific embodiments, the method further comprises, at the first node, sending, immediately after having sent the reservation acknowledging frame, padding data on the communication channel, during a predefined padding duration. Thanks to this configuration, the first node acknowledging the TXOP reservation can block access to the resource units until a predefined instant at which the UL/DL transmissions over these resource units should start.

Indeed, according to a specific feature, the end of the predefined padding duration defines a start of data transmission by the nodes over the resource units of the communication channel.

This is advantageously useful when a plurality of 20MHz channels needs to be synchronized for UL/DL transmission over the RUs. In this context, the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels (which reservation may be made by duplicating the MU frame over each channel and/or by specifying, in the MU frame, a width encompassing all the channels), each communication channel being made of one or more resource units, and data transmissions, after padding if any, over the resource units of all the communication channels start simultaneously. In other words, as the various 20MHz channels are successively acknowledged through CTS frames, the acknowledging nodes send padding data until the simultaneous transmission start.

The start time can be determined. For instance, the method may further comprise, at the first node, determining an ordered node list for each communication channel, based on the content of the received multi-user request control frame, and the end of the predefined padding duration, thus defining the start time, is time-aligned with the end of a timeslot defined for the last node of the largest ordered node list to send a reservation acknowledging frame on the corresponding communication channel (i.e. associated with the largest list).

In yet other specific embodiments, the method further comprises, at the first node, emitting on the communication channel a preamble starting an OFDMA transmission shared between a plurality of the nodes over resource units forming the communication channel. This avoids having collision when starting an UL OFDMA transmission shared by nodes.

In yet other specific embodiments, the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and the first node sends the reservation acknowledging frame or a duplicate thereof to the second node simultaneously over two or more of the communication channels (of course that it senses as idle for the requested reservation).

This configuration lets the choice to the second node, which has emitted the multiuser request control frame (usually the AP), of selecting at least one node, regardless of the number of communication channels in the composite channel. Selecting only one node for the ordered list is an easiest solution for the second node, typically when there is little interference with legacy communications.

In other embodiments, using the ordered node list comprises: determining a waiting time duration based on the position of the first node within the ordered node list; and waiting for the determined waiting time duration from the reception of the multi-user request control frame, and upon the waiting time duration ending, sending the reservation acknowledging frame to the second node on the communication channel.

Here, the sending of the CTS frame occurs if the communication channel is sensed as idle for the requested reservation, regardless of whether other nodes actually sent or not a CTS frame on the same channel. It means that all the nodes of the list will send a CTS (if they can - e.g. due to sensed idleness of the channel) one after the other.

Such approach may provide a great amount of information to the second node, e.g. an access point, while actually reserving the TXOP. Indeed, the second node may thus have knowledge of which nodes are available or blocked due to legacy communications. Thanks to this information, the second node may adjust overtime any allocation of the resource units to the various nodes.

In some specific embodiments, the nodes of the ordered node list wait different time durations based on their respective positions in the ordered node list, before sending (upon end of the waiting time) respective reservation acknowledging frames to the second node on the same communication channel if they respectively sense the communication channel as idle for said requested reservation. Idleness for the requested reservation means that the acknowledging frames, CTS, sent by the other nodes for acknowledging the same requested reservation are not considered as occupying the communication channel considered. The sensing is more directed to detecting legacy communications.

This provision explicitly defines the successive sending of CTS or the like frames by the various nodes forming the list.

In other specific embodiments, the waiting time duration lasts n times a timeslot required by any node to send a reservation acknowledging frame, n being the number of nodes preceding the first node in the ordered node list. Note that the predefined time period usually starts after a SIFS following reception of the multi-user request control frame, and a timeslot is made of a SIFS period plus the time required to actually send the CTS frame.

In yet other specific embodiments, the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and sending the reservation acknowledging frame upon the waiting time duration ending includes sending the reservation acknowledging frame or a duplicate thereof on each one of the plurality of communication channels that is sensed, by the first node, as idle for said requested reservation. More generally each node involved in the ordered node list sends a CTS and duplicates thereof over all the requested 20 MHz channels sensed as idle.

Thus each node contributes to the actual reservation of each 20MHz channel, thereby increasing the chances to have a maximum number of channels reserved.

In alternative specific embodiments, the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and sending the reservation acknowledging frame upon the waiting time duration ending includes sending the reservation acknowledging frame or a duplicate thereof on each communication channel that is sensed, by the first node, as idle for said requested reservation and that includes a resource unit assigned to the first node as indicated in the received multiuser request control.

In this configuration, each node is restricted to acknowledge the reservation of the 20MHz channels in which it is about to exchange data (an RU may be assigned to it). Compared to the previous configuration, this reduces the time required for the reservation acknowledging process, since the number of nodes for each channel is usually reduced compared to the number of nodes for the whole set of channels.

According to a specific feature, an ordered node list is determined for each one of the communication channels based on the content of the received multi-user request control frame, and the method further comprises, if the first node is the last node in one of the ordered node lists, sending padding data or repeating sending the reservation acknowledging frame, on the corresponding communication channel during a predefined padding duration. Again, this is to preferably align the start of the UL/DL OFDMA transmissions, or the like, over the plurality of communication channels.

For instance, the end of the predefined padding duration defines a start of data transmission by the nodes over the resource units forming the communication channels.

For instance, data transmissions, after padding or repeating if any, over the resource units of all the communication channels start simultaneously.

For example, the end of the predefined padding duration is time-aligned with the end of a timeslot defined for the last node of the largest ordered node list to send a reservation acknowledging frame on the corresponding communication channel.

In other embodiments of the invention, the multi-user request control frame indicates an addressee node of the frame, and the initial node starting the ordered node list is the addressee node. This configuration keeps compliance with the conventional approach according to which the addressee node is the one naturally dedicated to send the CTS frames.

In variants, the initial node starting the ordered node list is determined from nodes to which at least one of the resource units is assigned as indicated in the received multi-user request control frame. As the addressee node of the requesting frame may not be concerned by the communication channel or channels considered, it may be worth soliciting a concerned node for sending the CTS frames or the like.

In other variants, the initial node starting the ordered node list is determined from a list of nodes indicated in the received multi-user request control frame.

When the initial node is not determined from the addressee node, it may be because the multi-user request control frame includes an addressee node address field set to a broadcast or group address designating a plurality of nodes. In other words, the addressee node address field does not designate a specific node.

In other embodiments of the invention, the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and an ordered node list is determined for each one of the communication channels based on the content of the received multi-user request control frame, and the subsequent node or nodes, and possibly the initial node, of each ordered node list only include nodes which are associated, in the received multi-user request control frame, with the corresponding communication channel.

In other words, each 20MHz channel has its own list driving its actual reservation for the TXOP, based only on nodes that are concerned by this 20MHz channel. Again, this reduces the required time for the reservation acknowledging process (compared to situations where all the nodes are involved).

In specific embodiments, the method further comprises, at the first node: sensing each communication channel corresponding to an ordered node list in which the first node is included, to determine whether the communication channel is idle or not for the requested reservation, using the ordered node list corresponding to each communication channel sensed as idle, to determine if and when the first node has to send a reservation acknowledging frame on the communication channel sensed as idle.

In yet other embodiments of the invention, the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and a single ordered node list is built for the plurality of communication channels, and the subsequent node or nodes, and possibly the initial node, of the single ordered node list only include nodes which are associated, in the received multi-user request control frame, with at least one of the communication channels.

In some embodiments, the received multi-user request control frame assigns resource units of the one or more communication channels to respective nodes. Compared to the conventional MU-RTS frame, the frame according to this provision further includes the allocation of the RUs composing the communication channels. Thus a conventional trigger frame is no longer required, saving bandwidth.

In specific embodiments, the subsequent node or nodes, and possibly the initial node, of an ordered node list associated with one or more communication channels only include nodes which are associated, in the received multi-user request control frame, with the one or more associated communication channels, and the association between the nodes and the communication channels in the received multi-user request control frame results from the resource unit assignments.

This approach makes that only nodes concerned by one of the RUs (due to allocation by the MU-RTS frame or the like) are allowed to participate to the process of acknowledging reservation of the 20MHz channels, for instance by taking over from the initial node (or subsequent node) that failed to send a CTS frame or the like.

It may result that the first node sends a reservation acknowledging frame or duplicate thereof only on communication channels (it senses as idle for the requested reservation) having a resource unit assigned to the first node as indicated in the received multiuser request control frame.

According to a specific feature, an order of the nodes within a said ordered node list is built based on an order in which the assignments of the resources units to the nodes are declared in the multi-user request control frame, e.g. the same order. In a variant, the order may follow an order of node identifiers of the assigned nodes within the frame.

This advantageously requires low processing capabilities at the nodes.

In other specific embodiments relating to the RU allocations, the method further comprises receiving a trigger frame from the second node, the trigger frame providing assignments of resource units to nodes that are different from the resource unit assignments of the received multi-user request control frame. This is because the granted 20MHz channels may be different from the 20MHz channels forming the requested composite channel (e.g. CTS frames are not received on some 20MHz channels). Thus the RU allocations may be refined to provide fair use of the RUs between the nodes.

This provision particularly applies to the uplink transmissions for which some RUs are “scheduled” to nodes. These nodes thus access the RUs according to the RU allocations provided in the trigger frame, to send their data.

In some embodiments, the multi-user request control frame includes a list of responding nodes with respective associated communication channel or channels, the subsequent node or nodes, and possibly the initial node, of an ordered node list associated with one or more communication channels only include nodes which are associated, in the received multi-user request control frame, with the one or more associated communication channels, and the association between the nodes and the communication channels in the received multi-user request control frame results from said list of responding nodes.

In this configuration, the second node may have made this list explicit, so that each node can read it easily without involving complex processing. As a consequence, the second node may accurately drive the other nodes in participating to the reservation acknowledgment process.

In addition, this configuration advantageously provides ordering indications to the nodes in situation when no RU allocation is provided by the same multi-user request control frame, for instance if only Random RUs are provided or if the second node (the AP) only contemplates performing downlink communication to the nodes.

According to a specific feature, an order of the nodes within a said ordered node list is built based on the order of the nodes within the list of responding nodes.

In specific embodiments, the list of responding nodes and the RU assignments may be combined to build one or more ordered node lists. For instance, the association between the nodes and the communication channels in the received multi-user request control frame results from both said list of responding nodes and the resource unit assignments, and an order of the nodes within a said ordered node list is first built based on the order of the nodes within the list of responding nodes and then based on an order in which the assignments of the resources units to the nodes are declared in the multi-user request control frame.

It means that the ordered node list is first built based on the list of responding nodes, and for instance the additional nodes that may be identified thanks to the RU assignments are also added at the end of the list.

Of course, variants may contemplate ordering the list first based on the RU allocations and then based on the list of responding nodes.

In some specific embodiments, an order of the nodes within a said ordered node list gives priority (i.e. earlier position in the list) to a node associated with a higher number of communication channels compared to a node associated with a lower number of communication channels. For example, the same node has the same position in every ordered node list in which it is included.

In other embodiments of the invention, the ordered node list includes a maximum number of nodes depending on a maximum number of antennas of the second node. In variants or combination, the received multi-user request control frame specifies a maximum number of nodes for the ordered node list or lists to be determined by the first node.

Thus the number of nodes involves in the process for actually acknowledging reservation of the TXOP can be limited. This reduces the corresponding time, thereby increasing UL/DL transmission time in the RUs.

In yet other embodiments of the invention, the method further comprises, at the first node, receiving duplicates of the multi-user request control frame on one or more of the communication channels, simultaneously to receiving the multi-user request control frame on another communication channel. This is to keep compliance with the current version of the 802.11 ax standard.

In yet other embodiments of the invention, the method further comprises, at the first node, sending a reservation acknowledging frame at the determined time instant on the communication channel sensed as idle by the first node.

In yet other embodiments of the invention, the second node is an access point managing the wireless network for the other nodes. Trigger frames, such as MU-RTS, are preferably used by an access point willing to offer UL/DL OFDMA transmissions to a group of nodes (e.g. BSS).

In yet other embodiments of the invention, each communication channel is a 20 MHz channel according to the 802.11 standard.

In yet other embodiments of the invention, the multi-user request control frame is a Multi-User Request-To-Send, MU-RTS, frame according to the 802.11 ax standard.

Another aspect of the invention relates to a wireless communication method in a wireless network comprising nodes, the method comprising, at a first node: reserving one or more communication channels according to the above, and exchanging data with the second node using a resource unit assigned to the first node from amongst the plurality of resource units of the one or more communication channels.

Another aspect of the invention relates to a wireless communication system having an access point and nodes, wherein at least one of the nodes is a communication device as defined above.

Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a device, causes the device to perform any method as defined above.

The non-transitory computer-readable medium may have features and advantages that are analogous to those set out above and below in relation to the methods and node devices.

Another aspect of the invention relates to a communication method in a wireless network comprising an access point and a plurality of nodes, substantially as herein described with reference to, and as shown in, Figure 8, or Figures 8 and 9a, or Figures 8 and 9b, or Figures 8 and 10, or Figures 8 and 11a, or Figures 8 and 11b of the accompanying drawings.

At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Further advantages of the present invention will become apparent to those skilled in the art upon examination of the drawings and detailed description. Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings.

Figure 1 illustrates a typical wireless communication system in which embodiments of the invention may be implemented;

Figure 2 is a timeline schematically illustrating a conventional communication mechanism according to the IEEE 802.11 standard;

Figure 3 illustrates 802.11ac channel allocation that supports composite channel bandwidths of 20 MHz, 40 MHz, 80 MHz or 160 MHz, as known in the art;

Figure 4 illustrates an example of 802.11 ax OFDMA transmission scheme, wherein the AP issues a Trigger Frame for reserving a transmission opportunity of OFDMA resource units on an 80 MHz channel as known in the art;

Figure 4a illustrates an example of 802.11 ax OFDMA transmission scheme, wherein the AP issues an MU-RTS Trigger Frame for reserving a transmission opportunity of OFDMA resource units on an 80 MHz channel;

Figures 5a, 5b and 5c illustrate a format of a Trigger frame as known by the 802.11 ax standard;

Figures 5d, 5e and 5f illustrate changes in the format of a Trigger frame according to embodiments of the invention;

Figure 6 shows a schematic representation a communication device or node in accordance with embodiments of the present invention;

Figure 7 shows a block diagram schematically illustrating the architecture of a wireless communication device in accordance with embodiments of the present invention;

Figure 8 illustrates, using a flowchart, general steps at a node of the network, according to embodiments of the invention;

Figure 9a illustrates, using a timeline, a first scenario of reserving channels according to embodiments of the invention;

Figure 9b illustrates, using a timeline, a second scenario of reserving channels according to embodiments of the invention;

Figure 10 illustrates, using a timeline, a third scenario of reserving channels according to embodiments of the invention;

Figure 11a illustrates, using a timeline, a fourth scenario of reserving channels according to embodiments of the invention; and

Figure 11b illustrates, using a timeline, a fifth scenario of reserving channels according to embodiments of the invention.

DETAILED DESCRIPTION

The invention will now be described by means of specific non-limiting exemplary embodiments and by reference to the figures.

Figure 1 illustrates a communication system in which several communication nodes (or stations) 101-107 exchange data frames over a radio transmission channel 100 of a wireless local area network (WLAN), under the management of a central station, or access point (AP) 110, also seen as a node of the network. The radio transmission channel 100 is defined by an operating frequency band constituted by a single channel ora plurality of channels forming a composite channel.

Access to the shared radio medium to send data frames is based on the CSMA/CA technique, for sensing the carrier and avoiding collision by separating concurrent transmissions in space and time.

Carrier sensing in CSMA/CA is performed by both physical and virtual mechanisms. Virtual carrier sensing is achieved by transmitting control frames to reserve the medium prior to transmission of data frames.

Next, a source or transmitting node first attempts through the physical mechanism, to sense a medium that has been idle for at least one DIFS (standing for DCF InterFrame Spacing) time period, before transmitting data frames.

However, if it is sensed that the shared radio medium is busy during the DIFS period, the source node continues to wait until the radio medium becomes idle.

Access to the medium is driven by a backoff counter that is decremented over time, to defer the transmission time for a random interval, thus reducing the probability of collisions on the shared channel. Upon the backoff time expiring, the source node may send data or control frames if the medium is idle.

One problem of wireless data communications is that it is not possible for the source node to listen while sending, thus preventing the source node from detecting data corruption due to channel fading or interference or collision phenomena. A source node remains unaware of the corruption of the data frames sent and continues to transmit the frames unnecessarily, thus wasting access time.

The Collision Avoidance mechanism of CSMA/CA thus provides positive acknowledgement (ACK) of the sent data frames by the receiving node if the frames are received with success, to notify the source node that no corruption of the sent data frames occurred.

The ACK is transmitted at the end of reception of the data frame, immediately after a period of time called Short InterFrame Space (SIFS).

If the source node does not receive the ACK within a specified ACK timeout or detects the transmission of a different frame on the channel, it may infer data frame loss. In that case, it generally reschedules the frame transmission according to the above-mentioned backoff procedure.

To improve the Collision Avoidance efficiency of CSMA/CA, a four-way handshaking mechanism is optionally implemented. One implementation is known as the RTS/CTS exchange, defined in the 802.11 standard.

The RTS/CTS exchange consists in exchanging control frames to reserve the radio medium prior to transmitting data frames during a transmission opportunity called TXOP in the 802.11 standard as described below, thus protecting data transmissions from any further collisions.

Figure 2 illustrates the behaviour of three groups of nodes during a conventional communication over a 20 MHz channel of the 802.11 medium: transmitting or source node 20 (which may be the access point), receiving or addressee or destination node 21 and other nodes 22 not involved in the current communication.

Upon starting the backoff process 270 prior to transmitting data, a station e.g. source node 20, initializes its backoff time counter to a random value as explained above. The backoff time counter is decremented once every time slot interval 260 for as long as the radio medium is sensed idle (countdown starts from TO, 23 as shown in the Figure).

Channel sensing is for instance performed using Clear-Channel-Assessment (CCA) signal detection which is a WLAN carrier sense mechanisms defined in the IEEE 802.11 -2007 standards.

The time unit in the 802.11 standard is the slot time called ‘aSlotTime’ parameter. This parameter is specified by the PHY (physical) layer (for example, aSlotTime is equal to 9ps forthe 802.11η standard). All dedicated space durations (e.g. backoff) add multiples of this time unit to the SIFS value.

The backoff time counter is ‘frozen’ or suspended when a transmission is detected on the radio medium channel (countdown is stopped at T1,24 for other nodes 22 having their backoff time counter decremented).

The countdown of the backoff time counter is resumed or reactivated when the radio medium is sensed idle anew, after a DIFS time period. This is the case for the other nodes at T2, 25 as soon as the transmission opportunity TXOP granted to source node 20 ends and the DIFS period 28 elapses. DIFS 28 (DCF inter-frame space) thus defines the minimum waiting time for a source node before trying to transmit some data. In practice, DIFS = SIFS + 2 * aSlotTime.

When the backoff time counter reaches zero (26) at T1, the timer expires, the corresponding node 20 requests access onto the medium in order to be granted a TXOP, and the backoff time counter is reinitialized 29 using a new random backoff value.

In the example of the Figure implementing the RTS/CTS scheme, at T1, the source node 20 that wants to transmit data frames 230 sends a special short frame or message acting as a medium access request to reserve the radio medium, instead of the data frames themselves, just after the channel has been sensed idle fora DIFS or after the backoff period as explained above.

The medium access request is known as a Request-To-Send (RTS) message or frame. The RTS frame generally includes the addresses of the source and receiving nodes ("destination 21") and the duration for which the radio medium is to be reserved for transmitting the control frames (RTS/CTS) and the data frames 230.

Upon receiving the RTS frame and if the radio medium is sensed as being idle, the receiving node 21 responds, after a SIFS time period 27 (for example, SIFS is equal to 16 ps for the 802.11η standard), with a medium access response, known as a Clear-To-Send (CTS) frame. The CTS frame also includes the addresses of the source and receiving nodes, and indicates the remaining time required for transmitting the data frames, computed from the time point at which the CTS frame starts to be sent.

The CTS frame is considered by the source node 20 as an acknowledgment of its request to reserve the shared radio medium for a given time duration.

Thus, the source node 20 expects to receive a CTS frame 220 from the receiving node 21 before sending data 230 using unique and unicast (one source address and one addressee or destination address) frames.

The source node 20 is thus allowed to send the data frames 230 upon correctly receiving the CTS frame 220 and after a new SIFS time period 27, in a transmission opportunity that is thus granted to it thanks to the RTS/CTS exchange.

An ACK frame 240 is sent by the receiving node 21 after having correctly received the data frames sent, after a new SIFS time period 27.

If the source node 20 does not receive the ACK 240 within a specified ACK Timeout (generally within the TXOP), or if it detects the transmission of a different frame on the radio medium, it reschedules the frame transmission using the backoff procedure anew.

Since the RTS/CTS four-way handshaking mechanism 210/220 is optional in the 802.11 standard, it is possible for the source node 20 to send data frames 230 immediately upon its backoff time counter reaching zero (i.e. at T1).

The requested time duration for transmission defined in the RTS and CTS frames defines the length of the granted transmission opportunity TXOP, and can be read by any listening node ("other nodes 22" in Figure 2) in the radio network.

To do so, each node has in memory a data structure known as the network allocation vector or NAV to store the time duration for which it is known that the medium will remain busy. When listening to a control frame (RTS 210 or CTS 220) not addressed to itself, a listening node 22 updates its NAVs (NAV 255 associated with RTS and NAV 250 associated with CTS) with the requested transmission time duration specified in the control frame. The listening nodes 22 thus keep in memory the time duration for which the radio medium will remain busy.

Access to the radio medium for the other nodes 22 is consequently deferred 30 by suspending 31 their associated timer and then by later resuming 32 the timer when the NAV has expired.

This prevents the listening nodes 22 from transmitting any data or control frames during that period.

It is possible that receiving node 21 does not receive RTS frame 210 correctly due to a message/frame collision or to fading. Even if it does receive it, receiving node 21 may not always respond with a CTS 220 because, for example, its NAV is set (i.e. another node has already reserved the medium). In any case, the source node 20 enters into a new backoff procedure.

The RTS/CTS four-way handshaking mechanism is very efficient in terms of system performance, in particular with regard to large frames since it reduces the length of the messages involved in the contention process.

To meet the ever-increasing demand for faster wireless networks to support bandwidth-intensive applications, 802.11ac is targeting larger bandwidth transmission through multi-channel operations. Figure 3 illustrates 802.11ac channel allocation that supports composite channel bandwidth of 20 MHz, 40 MHz, 80 MHz or 160 MHz. IEEE 802.11ac introduces support of a restricted number of predefined subsets of 20MHz channels to form the sole predefined composite channel configurations that are available for reservation by any 802.11ac node on the wireless network to transmit data.

The predefined subsets are shown in the Figure and correspond to 20 MHz, 40 MHz, 80 MHz, and 160 MHz channel bandwidths, compared to only 20 MHz and 40 MHz supported by 802.11η. Indeed, the 20 MHz component channels 300-1 to 300-8 are concatenated to form wider communication composite channels.

In the 802.11ac standard, the channels of each predefined 40MHz, 80MHz or 160MHz subset are contiguous within the operating frequency band, i.e. no hole (missing channel) in the composite channel as ordered in the operating frequency band is allowed.

The 160 MHz channel bandwidth is composed of two 80 MHz channels that may or may not be frequency contiguous. The 80 MHz and 40 MHz channels are respectively composed of two frequency adjacent or contiguous 40 MHz and 20 MHz channels, respectively. However the present invention may have embodiments with either composition of the channel bandwidth, i.e. including only contiguous channels or formed of non-contiguous channels within the operating band. A node is granted a TxOP through the enhanced distributed channel access (EDCA) mechanism on the “primary channel” (300-3). Indeed, for each composite channel having a bandwidth, 802.11ac designates one channel as “primary” meaning that it is used for contending for access to the composite channel. The primary 20MHz channel is common to all nodes (STAs) belonging to the same basic set, i.e. managed by or registered to the same local Access Point (AP).

However, to make sure that no other legacy node (i.e. not belonging to the same set) uses the secondary channels, it is provided that the control frames (e.g. RTS frame/CTS frame) reserving the composite channel are duplicated over each 20MHz channel of such composite channel.

As addressed earlier, the IEEE 802.11ac standard enables up to four, or even eight, 20 MHz channels to be bound. Because of the limited number of channels (19 in the 5 GHz band in Europe), channel saturation becomes problematic. Indeed, in densely populated areas, the 5 GHz band will surely tend to saturate even with a 20 or 40 MHz bandwidth usage per Wireless-LAN cell.

Developments in the 802.11ax standard seek to enhance efficiency and usage of the wireless channel for dense environments.

In this perspective, one may consider multi-user transmission features, allowing multiple simultaneous transmissions to different users in both downlink and uplink directions. In the uplink, multi-user transmissions can be used to mitigate the collision probability by allowing multiple nodes to simultaneously transmit.

To actually perform such multi-user transmission, it has been proposed to split a granted 20MHz channel (300-1 to 300-4) into sub-channels 410 (elementary sub-channels), also referred to as sub-carriers or resource units (RUs), that are shared in the frequency domain by multiple users, based for instance on Orthogonal Frequency Division Multiple Access (OFDMA) technique.

This is illustrated with reference to Figure 4 which illustrates an example of OFDMA transmission scheme. In this example, each 20 MHz channel (300-1, 300-2, 300-3 or 300-4) is sub-divided in frequency domain into four OFDMA sub-channels or RUs 310 of size 5 MHz. These sub-channels (or resource units or sets of “sub-carriers”) may also be referred to as “traffic channels”.

Of course the number of RUs splitting a 20 MHz channel may be different from four. For instance, between two to nine RUs may be provided (thus each having a size between 10 MHz and about 2 MHz).

Contrary to downlink OFDMA wherein the AP can directly send multiple data to multiple stations (supported by specific indications inside the PLOP header), a trigger mechanism has been adopted for the AP to trigger uplink communications from various nodes.

To support an uplink multi-user transmission (during a pre-empted TXOP), the 802.11 ax AP has to provide signalling information for both legacy stations (non-802.11ax nodes) to set their NAV and for 802.11 ax nodes to determine the Resource Units allocation.

In the following description, the term legacy refers to non-802.11 ax nodes, meaning 802.11 nodes of previous technologies that do not support OFDMA communications.

As shown in the example of Figure 4, the AP sends a trigger frame (TF) 430 to the targeted 802.11 ax nodes, to trigger uplink communications. The trigger frame TF is additional to other control (or signaling) frames sent by the AP, such as beacon frames or probe messages defined in 802.11 ax.

The bandwidth or width of the targeted composite channel is signalled in the TF frame, meaning that the 20, 40, 80 or 160 MHz value is added. The TF frame is sent over the primary 20MHz channel and duplicated (replicated) on each other 20MHz channels forming the targeted composite channel. As described above for the duplication of control frames, it is expected that every nearby legacy node (non-HT or 802.11ac nodes) receiving the TF on its primary channel, then sets its NAV to the value specified in the TF frame in order. This prevents these legacy nodes from accessing the channels of the targeted composite channel during the TXOP.

Based on an AP’s decision, the trigger frame TF may define a plurality of resource units (RUs) 410.

Some resource units may be “Random RUs” which can be randomly accessed by the nodes of the network. In other words, Random RUs designated or allocated by the AP in the TF may serve as basis for contention between nodes willing to access the communication medium for sending data. A collision occurs when two or more nodes attempt to transmit at the same time over the same RU.

Some resource units may be “Scheduled resource units” which are reserved by the AP for certain nodes. In that case no contention for accessing such RUs is needed for these nodes. Such RUs and their corresponding scheduled nodes are indicated in the trigger frame. For instance, a node identifier, such as the Association ID (AID) assigned to each node upon registration, is added in association with each Scheduled RU in order to explicitly indicate the node that is allowed to use each Scheduled RU.

An AID equal to 0 may be used to identify random RUs.

In embodiments of the present invention, Random and Scheduled RUs may be combined in the same TF.

Also the AP may assign Random RUs to a specific group of nodes, which thus compete for contending for access to these Random RUs. For instance, the AP may specify a node group ID, such as a BSSID (standing for “Basic Service Set Identification”) in case the AP handles a plurality of BSSs.

In the example of Figure 4, each 20MHz channel (400-1, 400-2, 400-3 or 400-4) is sub-divided in frequency domain into four sub-channels or RUs 410, typically of size 5 Mhz.

Of course the number of RUs splitting a 20MHz channel may be different from four. For instance, between two to nine RUs may be provided (thus each having a size between 10MHz and about 2MHz).

Once the nodes have used the RUs to transmit data to the AP, the AP responds with an acknowledgment (not show in the Figure) to acknowledge the data on each RU. A current version of IEEE 802.11 ax extends the usage of the above-described RTS/CTS handshake mechanism to multi-user UL/DL scenarios. It is known as the “MU-RTS/CTS procedure”.

An aim of this procedure is to be more robust against legacy nodes.

According to the current version of the standard, the MU-RTS/CTS procedure allows an access point to reserve a TXOP for multi-user transmission through resource units, by sending a multi-user request control frame, noted MU-RTS frame, in replacement of the conventional RTS frame to request reservation of one or more 20MHz communication channels.

The MU-RTS frame is duplicated on each requested 20MHz channel and solicits, on each 20MHz channel, the sending of a response frame or reservation acknowledging frame, CTS, by at least one node.

This is illustrated in Figure 4a.

In this example, the AP duplicates an MU-RTS control frame 420 on each 20Mhz channel (sensed as free by the AP) of the intended 80MHz bandwidth composite channel.

At least one receiving node replies with a CTS frame on a 20Mhz channel sensed as free by this receiving node. Different nodes may reply with CTS frames on different 20MHz channels.

If the receiving node(s) has (have) successfully received MU-RTS frames from the entire 80MHz bandwidth, a total of (at least) four CTS frames is transmitted to cover the requested 80MHz channel bandwidth, thereby actually reserving the whole 80MHz for the TXOP.

While this example shows a complete reserved band of 80MHz, there may be that one or up to 3 secondary 20Mhz channels 300-4, 300-2, 300-1 (except the primary 20 Mhz channel 300-3 which is mandatorily free) are seen as busy by the AP. In that case, no duplicate of the MU-RTS is sent by the AP over these busy 20MHz channels. Thus there may be 20MHz holes within the requested composite channel.

As mentioned above, thanks to the duplication of the MU-RTS frame, every nearby legacy node (non-HE/non-802.11ax) receiving it on its primary channel sets its NAV to the value specified in the MU-RTS frame, thereby protecting the channels from these legacy nodes, during the requested TXOP.

The MU-RTS/CTS procedure shown in Figure 4a may protect two modes of OFDMA transmission.

The first mode is the uplink (UL) direction (from the nodes to the AP). As mentioned above, the 802.11 ax standard originally defined a trigger frame 430 to be sent by the AP on the reserved and granted (through conventional RTS/CTS handshake) channel. The conventional Trigger Frame 430 defines a plurality of resource units 410 forming the one or more communication channels 300-x for UL OFDMA transmission during the reserved transmission opportunity. The conventional Trigger Frame 430 is now protected through the MU-RTS frame 420 and CTS frames,

The second mode is the downlink (DL) direction (from the AP to the nodes). The AP emits data inside OFDMA RUs 410 directly after the duplicated CTS frames are received from the node(s) in response to the MU-RTS frame(s). The use of the MU-RTS frame makes it possible to solicit specific nodes to send the CTS frames, thereby increasing protection of the following OFDMA RUs. In this second mode, the RU allocations are defined within the PHY header of the RUs 410 (typically spread over a 20 MHz width, not represented in the figure). The nodes thus do not require any RU allocation inside the MU-RTS frame 420, but only expect obtaining channel assignments to nodes for the process of sending CTS frames.

At that time, the 802.11 ax standard thus envisages including, in the MU-RTS frame, indications of 20MHz channel assignments to nodes with a view of indicating which nodes should send a CTS frame. The conventional TF is sent thereafter, for UL direction only, to define the RU allocations to the nodes, for exchanging data.

Figure 5a illustrates the MAC format of a trigger frame compliant with the 802.11 ax standard. The MU-RTS frame follows the same format, wherein a Trigger Type subfield 514 indicates the MU-RTS type. A Trigger frame, and thus the MU-RTS frame, is used to respectively allocate / protect resource units for UL/DL MU transmission by 802.11 ax nodes. The frame is duplicated in each 20 MHz channel of the targeted composite channel to reserve a transmission opportunity over the composite channel. The trigger frame follows the legacy format of control frames (no specific HT preamble).

The frame 500 is made up of a MAC header and of additional fields.

The MAC header includes the following fields common to all control frames: a frame control field 501, a duration field 502, a RA (Receiver Address) field 503, a TA (Transmitter Address) field 504.

The Duration field 502 is set to the estimated time, in microseconds, required for the pending OFDMA transmissions, i.e. the expected duration for the requested TXOP. It is used to set the NAV of legacy nodes to avoid collision.

The RA field 503 is set to the address of the recipient node or nodes. As a Trigger frame is intended for a group of nodes (a BSS), one proposed implementation (not described in the standard) is the wildcard MAC address (FF:FF:FF:FF:FF:FF) as a broadcast indication or a group MAC address known by the 802.11 ax nodes or even a pointer to a list of node addresses specified in another field of the frame. Note that the legacy nodes do not know the format of the Trigger Frames. So, the legacy nodes, even if they are included in the broadcast indication, are not able to understand the frame, and thus shall ignore it (except for setting their NAV).

The TA field 504 is set to the address of the node transmitting the Trigger frame. It is typically the MAC address of the AP which sends the MU-RTS. One may note that, if the AP hosts several virtual APs for multiple BSSs, the MAC address of the current BSS (i.e. the specific BSSID or MAC address of the virtual AP concerned) is preferably used for the TA field 504.

The additional fields of the frame 500 include a data portion formed of a Common Info field 510 and one or more Per User Info fields 520 specific to the TF to define the allocation of the RUs to the nodes, and a FCS (Frame Check Sequence, or also called checksum or CRC) field. The FCS field may optionally be preceded by a padding field of variable size, for considerations out of scope of the present invention.

As the frame is dedicated to a single BSS, through the specific BSSID set in the TA field 504, the physical AP (hosting several virtual APs) can send successively a plurality of trigger frames to provide respective transmission opportunities (with resource units) to various BSSs. This is indicated to the 802.11 ax nodes thanks to the cascade indication field 511 (mentioned below). Due to this information, the 802.11 ax nodes not concerned by the first frame (because the BSSID is of another BSS) does not set their NAV as indicated in the frame, so to be ready to detect the next trigger frame sent by the AP in cascade.

Figure 5b illustrates one Common Info field 510 forming part of the additional fields in the TF 500.

Common Info field 510 includes a Cascade Indication subfield 511 to indicate successive trigger frames. For instance, Cascade Indication subfield 511 is set to 1 when a subsequent Trigger frame will follow the current Trigger frame. Otherwise, the Cascade Indication subfield is set to 0.

Common Info field 510 also includes a Trigger Type subfield 514 to indicate the type of the Trigger frame. The Trigger Type subfield 514 may be set to a value indicating MU-RTS type for the frames 420, and a distinct value for the basic TF 430.

Other subfields in Common Info field 510 are of less importance for the present invention (Length, CS required, HE-SIG-A Info, CP and LTF Type, Trigger Dependent Common Info subfields and possibly other non-illustrated subfields indicate some parameters to format the HE trigger-based PPDU response, that is to say the uplink multi-user OFDMA frame).

Figure 5c illustrates Per User Info field 520 also forming part of the additional fields in the TF 500. The Per User Info field 520 is especially suitable for basic trigger frames 430 in order to define the allocation of one or more resource units to nodes of the BSS addressed in TA field 504. A plurality of Per User Info fields 520 is usually used to define the allocation of all the resource units of the transmission opportunity.

User Identifier subfield 521 contains the 12 LSBs of the Association IDentifier (AID) of the node(s) to which the RU identified in RU Allocation field 522 is allocated, to transmit the MPDU(s) in the uplink direction.

The AID is a 16-bit unique value assigned to a node by the AP during association handshake, i.e. during registration. The values other than 1-2007 (0 and 2008-65535) are reserved, limiting the number of nodes for an AP to 2007. This is why using the 12 LSBs is sufficient. In particular, AID = 0 is reserved for assigning the group of nodes forming the BSS currently addressed (TA Field 504), thereby declaring the RU identified in RU Allocation field 522 as being a Random RU.

Of course, a 16-bit field may be used to store the whole AID.

The AID management is performed per each virtual AP (i.e. per BSS).

As mentioned above, RU Allocation subfield 522 indicates the RU or RUs that are allocated to the one or more nodes identified in User Identifier subfield 521. The length and coding of RU Allocation subfield are not defined yet, but an index of ordered RUs may be used.

The other fields of Per User Info field 520 are of less importance for the present invention.

For the sake of illustration, the table below illustrates an example of allocation of resource units to seven nodes STA1 to STA7, each being allocated with one RU.

The present invention seeks to improve the reservation of the TXOP for multi-user transmission. It is thus directed to a method for reserving at least one communication channel in a wireless network comprising nodes, wherein a first node received a multi-user request control frame from a second node, preferably an access point, wherein the multi-user request control frame requests reservation of a transmission opportunity on one or more communication channels of the wireless network, the one or more communication channels including a plurality of resource units the one or more communication channels for exchanging data with the nodes during the reserved transmission opportunity.

To facilitate reservation of the requested communication channel or channels for the TXOP, the present invention provides that, upon receiving the multi-user request control frame, the first node: determines an ordered node list of some of the nodes, based on a content of the received multi-user request control frame, preferably based only on the sole content thereof, the ordered node list including an initial node and one or more subsequent nodes; and uses the ordered node list to determine if and when said first node has to send a reservation acknowledging frame to the second node on one of the communication channels if sensed as idle by said first node, to acknowledge reservation of the communication channel.

Thus, the nodes know the same list and can take over from any preceding node in the list to increase the chances that a CTS frame is sent on a maximum number of 20MHz channels. As a consequence, requested TXOP are more often obtained by the second node, usually the access point, thereby providing efficient UL/DL OFDMA transmission (through RUs) to the nodes.

An exemplary wireless network is an IEEE 802.11 ax network (and future versions). However, the invention applies to any wireless network comprising nodes (for instance an access point AP 110 and a plurality of nodes 101-107) exchanging data through a multi-user transmission. The invention is especially suitable for data transmission in resource units of an IEEE 802.11 ax network (and future versions).

An exemplary management of multi-user transmission in such a network has been described above with reference to Figures 1 to 5.

Figure 6 schematically illustrates a communication device 600 of the radio network 100, configured to implement at least one embodiment of the present invention. The communication device 600 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 600 comprises a communication bus 613 to which there are preferably connected: • a central processing unit 611, such as a microprocessor, denoted CPU; • a read only memory 607, denoted ROM, for storing computer programs for implementing the invention; • a random access memory 612, denoted RAM, for storing the executable code of methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to embodiments of the invention; and • at least one communication interface 602 connected to the radio communication network 100 over which digital data packets or frames or control frames are transmitted, for example a wireless communication network according to the 802.11 ax protocol. The frames are written from a FIFO sending memory in RAM 612 to the network interface for transmission or are read from the network interface for reception and writing into a FIFO receiving memory in RAM 612 under the control of a software application running in the CPU 611.

Optionally, the communication device 600 may also include the following components: • a data storage means 604 such as a hard disk, for storing computer programs for implementing methods according to one or more embodiments of the invention; • a disk drive 605 for a disk 606, the disk drive being adapted to read data from the disk 606 or to write data onto said disk; • a screen 609 for displaying decoded data and/or serving as a graphical interface with the user, by means of a keyboard 610 or any other pointing means.

The communication device 600 may be optionally connected to various peripherals, such as for example a digital camera 608, each being connected to an input/output card (not shown) so as to supply data to the communication device 600.

Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 600 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 600 directly or by means of another element of the communication device 600.

The disk 606 may optionally be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the apparatus, possibly removable and adapted to store one or more programs whose execution enables a method according to the invention to be implemented.

The executable code may optionally be stored either in read only memory 607, on the hard disk 604 or on a removable digital medium such as for example a disk 606 as described previously. According to an optional variant, the executable code of the programs can be received by means of the communication network 603, via the interface 602, in order to be stored in one of the storage means of the communication device 600, such as the hard disk 604, before being executed.

The central processing unit 611 is preferably adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard disk 604 or in the read only memory 607, are transferred into the random access memory 612, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.

In a preferred embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

Figure 7 is a block diagram schematically illustrating the architecture of the communication device or node 600, either the AP 110 or one of the nodes 101-107 adapted to carry out, at least partially, the invention. As illustrated, node 600 comprises a physical (PHY) layer block 703, a MAC layer block 702, and an application layer block 701.

The PHY layer block 703 (e.g. a 802.11 standardized PHY layer) has the task of formatting, modulating on or demodulating from any 20 MHz channel or the composite channel, and thus sending or receiving frames over the radio medium used 100, such as 802.11 frames, for instance MU-RTS/CTS/TF/ACK frames, MAC data and management frames based on a 20 MHz width to interact with legacy 802.11 stations, as well as of MAC data frames of OFDMA type having smaller width than 20 MHz legacy (typically 2 or 5 MHz) to/from that radio medium.

The MAC layer block or controller 702 preferably comprises a MAC 802.11 layer 704 implementing conventional 802.11 ax MAC operations, and two additional blocks 705 and 706 for carrying out, at least partially, embodiments of the invention. The MAC layer block 702 may optionally be implemented in software, which software is loaded into RAM 612 and executed by CPU 611.

Preferably, the additional blocks include a station management module 705 which drives the node in sending frames for the TXOP reservation and/or processing received frames for same TXOP; and a channel allocation module 706 to process the allocation of the RUs.

For instance and not exhaustively, the operations at the AP may include, by module 705, generating and sending a MU-RTS including associations between nodes and 20MHz channels obtained from module 706, receiving and processing CTS from the nodes; and may include, by module 706, defining associations between nodes and 20MHz channels, for instance based on history of use.

Also the operations at the nodes may include, by module 705, processing received MU-RTS in order to determine the above-mentioned ordered node list, and sending CTS frames based on that list and possibly on other triggering criteria; and may include, by module 706, retrieving the 20MHz channel-node associations (for instance to feed module 705 to build the ordered node list) and performing OFDMA communication on accessed 20MHz channels.

On top of the Figure, application layer block 701 runs an application that generates and receives data packets, for example data packets of a video stream. Application layer block 701 represents all the stack layers above MAC layer according to ISO standardization.

Embodiments of the present invention are now illustrated through a flowchart illustrating main steps of the process at nodes receiving an MU-RTS trigger frame (Figure 8).

No flowchart is provided to illustrate main steps of a corresponding process at the node emitting the MU-RTS, i.e. usually at the access point. However, these main steps are explicitly described below or can be directly inferred from the teachings below.

At step 800, a multi-user request control frame (MU-RTS trigger frame) is received by the node, from the AP. The MU-RTS trigger frame may request reservation of a transmission opportunity TXOP on a composite channel made of one or more 20MHz channels.

In this example, the MU-RTS trigger frame is replicated over each 20MHz subchannel (300-1 to 300-4) forming the targeted composite channel.

However, in other embodiments, the MU-RTS trigger frame may be replicated only on some of the 20MHz channels (possibly non-contiguous) forming the composite channel. For instance, it may be because the other 20MHz channels of the composite channel are detected as busy by the AP. The receiving node may know the composite channel because the MU-RTS trigger frame includes bandwidth information.

Embodiments of the invention provides that the MU-RTS trigger frame defines RUs splitting the requested 20MHz channel and also includes RU allocation to the nodes (random or scheduled RUs) using for instance User identifier field 521 and RU allocation field 522. This sharply contrasts with the use of MU-RTS frames as defined in the 802.11 ax standard.

The description above with reference to Figures 4a and 5 shows that a Trigger frame can be used to declare the RUs and define the allocation of them to the nodes, as desired by the AP upon requesting a TXOP. These embodiments of the invention thus use the structure of the trigger frame to provide, within the MU-RTS frame, the RU allocations.

It results that the conventional trigger frame 430 is no longer necessary.

However, as one may understand, the entire requested composite channel may not be obtained, for instance because legacy nodes are already transmitting data in the vicinity of the node designated to send a CTS frame in response. In this case, one may contemplate still sending a conventional Trigger Frame 430 following the MU-RTS procedure in order to adjust the original allocation (in the MU-RTS) of the uplink RUs (in particular to take into account that one or more requested 20MHz channels are not granted, to avoid allocating RUs in the non-granted bandwidth).

In practice, any 802.11 ax node can determine that the received MU-RTS requests a TXOP shared with other nodes. This is made by the simple analysis of field of the frame: source address and/or the receiver address of the MU-RTS trigger frames (e.g. if the RA address includes a broadcast or groupcast addresses), or specific-TF contents such as the Per User info sections 520 which identify various nodes through their User Identifier fields 521.

If the node is not concerned by the received MU-RTS TF, the process ends (the node sets its NAV according to the duration specified in the received MU-RTS TF).

Otherwise, upon receiving the MU-RTS trigger frame, the node analyses its content at step 801, which content associated nodes with one or more communication channels. Thanks to this analysis, the node may determine one or more ordered node lists of some of the nodes. Various embodiments about the number of lists and about how each of these lists is built are described below.

Based on the list or lists, the node may determine which 20MHz channels it has to monitor for the process of acknowledging the reservation of the requested TXOP on these channels according to embodiments of the invention.

Next, step 802 consists for the node in actually monitoring these channels. In particular, this includes sensing each of the to-be-monitored 20MHz channels to determine whether or not it is idle for the requested reservation, i.e. whether or not legacy nodes (not concerned by the received MU-RTS frame) communicate on this channel. Indeed, the node is able to distinguish between CTS frames sent by other nodes in response to the received MU-RTS (in which case the channel is still considered as being idle) and other frames sent by legacy nodes (in which case the channel is considered as busy).

Step 803 consists for the node in using the list or lists to determine if and when the node has to send a reservation acknowledging frame, e.g. a CTS frame, to the AP on one or more of these channels, in response to the MU-RTS frame, to acknowledge reservation of the 20MHz channel or channels. In particular, the node will respond with a CTS frame only on monitored 20MHz channels it has sensed as idle.

Various embodiments driving the rules to determine if the node (and more generally any node of the network) has to send a CTS frame on the 20MHz channels are proposed below.

Figures 9 and 10 illustrate some embodiments in which the node takes over from other nodes that failed to send a CTS in due time.

On the other hand, Figures 11 illustrate other embodiments in which the node must send a CTS on each monitored channel (sensed as idle), regardless of whether or not the other nodes have sent CTSs.

Also various embodiments may drive the rules to determine when the node has to send such a CTS frame. It is mainly based on how the ordered node list or lists are built as briefly introduced above.

In the affirmative of step 803, the node sends a CTS frame to acknowledge reservation of the TXOP on the sensed-as-idle monitored 20MHz channels, at the appropriate determined time instant. This is step 804.

Note that the nodes not designated by the ordered node list or lists to send a CTS frame still perform the monitoring of the channels through step 802 for instance to determine when the MU UL/DL OFDMA data transmission period starts. Some embodiments described below show that it may start just after a CTS frame is sent, or may require a certain acknowledging period (based on a number of nodes that should send CTS frames) to elapse.

If the node is not elected for sending a CTS frame at step 803, or after step 804, the node can start its own OFDMA communication, if any, in one or more RUs of the granted composite channel (i.e. formed of the granted 20MHz channels) which may be different from the requested 20MHz channels). For instance, the node accesses an RU (random RU using contention, or scheduled RU) to send data it has in a transmission buffer or listens to some RUs to receive data from the AP.

If the node is elected for sending a CTS frame at step 803, but has no RU allocated over the granted composite channel, the node may set its NAV according to the duration specified in the transmitted CTS frame. In case the node has sent a CTS at step 804, it thus set its NAV based on the duration content of its proper CTS frame.

Not shown in the process, but depicted in Figure 4a, a TF 430 may be received from the AP after the CTS frame sending period, in particular if it is proposed to refine the RU allocations due to some 20MHz channels not granted through the RTS/CTS handshake. According to embodiments of the invention for the uplink case (since the RU allocations are indicated in the MU-RTS 420), the TF 430 now becomes optional and may be transmitted only in case of some 20MHz channels were not been successfully granted.

Referring back to step 801, one or more ordered node lists are created based on the sole content of the received MU-RTS TF. The lists are then used by the nodes to determine if and when they have to send CTS frames.

As mentioned above, various ways to build such lists are proposed according to various embodiments.

Two groups of embodiments are contemplated.

In a first group of embodiments, a single ordered node list is built for all the 20MHz channels of the requested composite channel.

In a second group of embodiments, an ordered node list is determined for each requested 20MHz channel.

The ordered node list or lists define orders in which the nodes must be successively considered to send a CTS frame on the corresponding 20MHz channel.

Each list starts with an initial node. In some embodiments, the initial node starting the ordered node list is the addressee node (defined in RA field 503, different from a broadcast or group address) of the received MU-RTS. Thus, the addressee node will be the first node designated to send a CTS in response to the MU-RTS, on the 20MHz channel or channels associated with the list considered. This usage has the advantage of keeping the legacy way of the RTS/CTS handshake, with an addressee node explicitly specified.

The subsequent node(s) of the list may thus be determined according to any of the list-building approaches ways as described below (possibly combining some of them together).

These various list-building approaches may also determine the initial node of the list(s) in case the addressee node address field (RA field 503) of the MU-RTS indicates a broadcast or group address designating a plurality of nodes. Each list-building approach builds a list from which the first node is considered as the initial node of the final ordered node list according to the invention.

Proposed list-building approaches are based on information, in the received MU-RTS, describing how nodes are associated with the 20MHz channels.

In case a single list is built, the subsequent node or nodes, and possibly the initial node, of the single ordered node list may only include nodes which are associated, in the received multi-user request control frame, with at least one of the communication channels.

While, in case a list is built per each 20MHz channel, the subsequent node or nodes, and possibly the initial node, of each ordered node list may only include nodes which are associated, in the received multi-user request control frame, with the corresponding communication channel.

In some embodiments, the ordered node list or lists are built based on the RU allocations (field 522 associated with field 521) defined in the received MU-RTS. In other words, the association between the nodes and the 20MHz channels in the received MU-RTS results from the resource unit assignments. As the Per User info sections 520 are provided in an order within the MU-RTS frame, an approach may be consider to order the nodes within the ordered node list(s) based on the order (e.g. the same order) in which the assignments of the resources units to the nodes are declared in the multi-user request control frame, i.e. the order of the Per User info sections 520 in relation with the node they respectively identify in their User Identifier field 521.

Note that if a single list is built for all the 20MHz channels, the RU allocation field 522 is not taken into account, and only the order in which the User Identifier fields 521 are declared is used.

On the other hand, if an ordered node list is created per each 20MHz channel, the list for a given 20MHz channel is built by taking into account only the User Identifier fields 521 associated with an RU allocation field identifying an RU of said given 20MHz channel.

In case the initial node of the list(s) is not the one specified in RA field 503, the initial node starting the ordered node list is thus determined from nodes to which at least one of the resource units (in particular an RU of the considered 20MHz channel in case of a list per channel) is assigned as indicated in the received MU-RTS frame.

In other embodiments, the ordered node list or lists are built based on a CTS-allocation list explicitly indicated by the AP in the received MU-RTS. Having a CTS-allocation list distinct from the RU allocations may avoid having a subsequent non-HT duplicate TF 430 for the UL OFDMA direction, thereby increasing channel usage as such a TF is usually sent in low modulation thus occupying greater time duration. It may be noted that this modified scheme breaks the classical alternation between sender and receiver, because a node sending a CTS frame triggers its proper MU UL transmission (in addition to the other parallel RUs).

Preferably, the nodes listed in the CTS-allocation list are those concerned by the RU allocations defined in the same MU-RTS frame.

In these embodiments, the association between the nodes and the communication channels in the received multi-user request control frame thus results from a CTS-allocation list of responding nodes. In particular, the CTS-allocation list associates each listed node with one or more 20MHz channels (preferably those concerned by RU allocation for the same node). Of course, the order of the CTS-allocation list may be kept in the ordered node list or lists (taking into account the associated 20MHz channels for building a list per each 20MHz channel).

The addition of the CTS-allocation list may require modifying the structure of the MU-RTS frame. Exemplary modifications are shown in Figures 5d to 5f.

In first embodiments for the CTS-allocation list, it is declared in the Common Info section 510 as shown in Figures 5d and 5f. A field 531 called “CTS required” indicates that the AP mandates such a CTS-allocation list defining the nodes to emit a CTS frame in response to the MU-RTS, for instance if a previous node failed to send such a CTS frame. Thus, this field 531 set to 1 indicates the presence of at least one information element 533, more generally a series of such elements, in the “Trigger dependent common info” field ending the Common Info section 510.

In a variant, the “CTS required” is absent and the node always parses the “Trigger dependent common info” field.

Each information element 533 identifies one node through its AID 521, along with a Channel Allocation field (532) indicating one or more 20MHz channels) associated with that node for the process of sending CTS frames.

As shown in Figure 5f, the Channel Allocation field 532 may be made of a Channel width field 532a and of an Allocation bitmap 532b.

If the node is concerned by the primary 20 MHz channel 300-3, the Channel Width field 532a is set to 0. For the primary 40 MHz channel (i.e. 300-3 and 300-4), it is set to 1. For the primary 80MHz channel (300-1 to 300-4), the value is set to 2. For the whole 160 MHz channel width (or 80+80 MHz), a value of 3 is used. Note that, this indication may be used, as described below, to determine which node has priority over other nodes, because it may be sought to provide priority to nodes able to acknowledge reservation (i.e. send CTS frames) on the wider channel.

Of course, it may be possible to cover the 60MHz case and other configurations of 40MHz and 80 MHz channels. However, the above configuration advantageously provides backward compatibility with 802.11ac supported cases for RTS/CTS (that is to say 20/40/80MHz channel support).

The Allocation bitmap 532b may be an 8-bit bitmap, with each bit corresponding to a 20MHz channel. In variant it may also be of variable length depending on the value of the Channel width field 532a, to include a bit per each 20MHz of the declared channel width.

Thus an 8-bit bitmap is used for a declared 160MHz channel, wherein each bit represents a 20MHz channel of the overall composite channel. The bits corresponding to the 20MHz channels associated with the nodes (for CTS response) are thus set to 1.

The advantage of using a bitmap format is to support selecting several 20MHz channels (compared to a format through indices, like the RU allocation envisaged by the standard, wherein an index would indicate a unique RU allocation).

In a variant, the Allocation bitmap 532b is not used, keeping only the Channel width field 532a. Thus the latter must be put in correspondence with all the “RU Allocation” fields 522 concerned by the same node. It means that the node is concerned, for CTS sending, by each 20MHz channel (forming the targeted the Channel width) that includes one RU allocated to the node.

In second embodiments for the CTS-allocation list, it is still declared through the CTS required field 531. However, no information element 533 is present in the “Trigger dependent common info” field. On the other hand, at least one ‘Per User Info’ section 520 is modified in order to add a similar Channel Allocation field 532 inside, as shown in Figure 5e. Thus the CTS-allocation list follows the same order as the RU allocations, because it fully depends on the order of the Per User Info sections 520.

The above list-building approaches provide an ordered list of nodes.

In variants, the ordered list or lists may be built by combining the CTS-allocation list and the RU allocations provided in the MU-RTS frame. For instance, the CTS-allocation list may be processed first to feed the list or lists, which are then supplemented by the RU allocations. Of course, the reverse can be envisioned.

This combination thus provides that the association between the nodes and the communication channels in the received MU-RTS frame results from both said list of responding nodes (CTS-allocation list) and the resource unit assignments, and an order of the nodes within a said ordered node list is first built based on the order of the nodes within the list of responding nodes and then based on an order in which the assignments of the resources units to the nodes are declared in the multi-user request control frame.

As mentioned above, the list or lists can be slightly adapted to provide priority to nodes concerned by wider channels. It means that an order of the nodes within a said ordered node list gives priority (i.e. earlier position in the list) to a node associated with a higher number of communication channels compared to a node associated with a lower number of communication channels.

Typically, a 40MHz node, i.e. a node that must monitor two 20MHz channels, should be given a higher priority than a 20MHz node, as the former one emits in non-HT duplicate mode. It means that the nodes may check the channel width of each node of the list to reorder it. As a consequence, any 20MHz allocated node will defer its sending of a CTS frame after a 40MHz allocated node residing in the band of 20MHz channels.

This is because the (non-HT) duplicate mode (typically for bands greater than or equal to 40MHz) means a single CTS frame is duplicated over each 20MHz channel, requiring the transmission timing of these duplicated frames to be the same (start time and duration). As a consequence, a wider node (e.g. 40MHz) cannot take over from a narrower node (e.g. 20MHz), while the opposite is of course possible.

In more details, it is not possible for a 40MHz node to start sensing one 20MHz channel to detect some inactivity, while (at the same start time) sending a first CTS on a contiguous 20MHz channel. This is because, if the sensing period (less than the time required to send a CTS) finally leads to decide to send a second CTS frame on the other 20MHz channel, the node is not able to send it as the transmissions of the two CTS would not be aligned in time. A consequence of this priority scheme in case several ordered node lists are created (e.g. one per each 20MHz channel) is that the same node has the same position in every ordered node list in which it is included. It is to ensure the duplicated CTSs will be sent at the same time by the node.

As it will be apparent from the various scenarii described below with reference to Figures 9 to 11, the number of nodes in the ordered node lists may impact more or less network efficiency as it may delay the time when the MU UL/DL OFDMA transmissions start in the RUs. As a consequence, the number of nodes in the lists may be restricted. For instance, the ordered node list may include a maximum number of nodes depending on a maximum number of antennas of the AP. Also, such a maximum number may be indicated by the AP in the MU-RTS, meaning that the received MU-RTS frame specifies a maximum number of nodes for the ordered node list or lists to be determined by the first node.

The invention envisages making mandatory that a node emits a CTS if it discovers that it is listed by the AP inside the received MU-RTS frame and if CTS sending conditions are fulfilled (20MHz channel idle, previous nodes in the list have not sent a CTS frame).

Turning now to the various embodiments driving the rules to determine if the node (and more generally any node of the network) has to send a CTS frame on the 20MHz channels, it is made reference to Figures 9 and 10 illustrating some embodiments in which the node takes over from other nodes that failed to send a CTS in due time, and to Figures 11 illustrating other embodiments in which the node must send a CTS on each monitored channel (sensed as idle), regardless of whether or not the other nodes have sent CTSs.

The RU splitting configurations shown in these Figures are only examples. Other splitting of all or part of the 20MHz channels into different numbers of RUs are also possible. A given request control frame (RTS, or MU-RTS) is usually addressed to an addressee node, but the other 802.11 ax nodes (forming a group) are able to detect (listen or sense) the (MU-)RTS frames on the medium. As already mentioned, an (MU-)RTS frame sent on a first sub-channel calls for a response control frame CTS from the corresponding addressee node on the same sub-channel, in order to finalize the handshake process for reserving a TXOP for this first sub-channel. Indeed, this CTS frame indicates the availability of the first subchannel for the addressee node.

In the first embodiments illustrated by Figures 9 and 10, a single CTS frame is sent per each 20Mhz channel in response to the MU-RTS 420 (unless no CTS frame at all is sent is all the nodes of the corresponding ordered node list sense this 20MHz channel as busy).

In these first embodiments, the nodes use the ordered node list(s) to sense the 20MHz communication channel or channels in order to determine whether any node preceding it in the concerned ordered node list sends, on the 20MHz channel(s), a CTS frame to the AP in response to the MU-RTS frame (in which case the reservation is acknowledged), or not. Thus, in case no preceding node has sent a CTS frame within a predefined time period, the node may sends a CTS frame on the 20MHz channel(s) to the AP, to acknowledged the reservation for all the nodes.

The first node designated to send a CTS frame in response to the MU-RTS may be the one indicated in the RA field 503 of the received MU-RTS frame. The other nodes that must determine if a previous node failed to send a CTS frame, in order to send a CTS frame, are those subsequent nodes in the created ordered node lists.

As indicated above, if the MU-RTS frame is duplicated over each of a plurality of 20MHz channels, a list may be created for each 20MHz channel, thereby possible leading to different nodes sending CTS frames over different 20Mhz channels.

Sensing of CTS-sending failure by all the nodes preceding a considered node is preferably performed by sensing the corresponding 20MHz channel for the above-mentioned predetermined time period, which may depend on the position of the considered node within the considered ordered node list. The considered node sends a CTS frame upon the predetermined time period elapsing, in case all preceding nodes failed to do so.

The predefined time period may last n times an elementary duration, n being the number of nodes preceding the first node in the ordered node list, and the elementary duration being a fraction of a time required by any node to send a CTS frame. This is illustrated below with reference to Figure 9, wherein Figure 9a illustrates a situation where MU UL/DL OFDMA transmission on a 20MHz channel starts immediately after the CTS frame on the same channel, while Figure 9b illustrates a situation where the MU UL/DL OFDMA transmissions on all the RUs of the composite channel (made of two or more 20MHz channels) are aligned in time. This is achieved by providing padding data between the CTS frames and the MU UL/DL OFDMA transmission start.

In variants, the predefined time period may last n times a timeslot required by any node to send a CTS frame, n being the number of nodes preceding the first node in the ordered node list. This is illustrated below with reference to Figure 10.

Referring now to Figure 9a, a plurality (here four) of MU-RTS frames is sent by the AP to the nodes, for initiating a transmission opportunity (TXOP) reservation for the allocated group on a composite channel, here made of four sub-channels 300-1 to 300-4.

As already mentioned, the MU-RTS frame is replicated (duplicated) on the primary 300-3, secondary 300-4, tertiary 300-2 and quaternary 300-1 channels, and each MU-RTS frame indicates the bandwidth for which the TXOP is wanted. Therefore, in embodiments where no MU-RTS frame is sent on some of the 20MHz channels because the AP is disrupted on these channels, the nodes can know the desired bandwidth thanks to the indication within a MU-RTS frame received in any of the other 20MHz channels.

In a slight variant to the duplication of the same MU-RTS frame, one may provide simultaneously different MU-RTS frames on the various 20MHz channel, to drive differently the way to build the corresponding ordered node lists.

There is an ordered node list for each 20MHz channel, which defines nodes to answer a CTS frame on the respective 20MHz channel. The list is created as mentioned above, in particular based on the content of the received MU-RTS control frame.

In the illustrated example, the content of the MU-RTS designates successively nodes 1 and 2 for the ordered node list of primary 20MHz channel 300-3, nodes 3, 4 and 5 for secondary 20MHz channel 300-4, and nodes 1, 6, 7, 8 for secondary 40MHz channel (made of channels 300-2 and 300-1).

Regarding primary 20MHz channel 300-3, node 1 does not respond to the received MU-RTS after the conventional SIFS time interval. This is probably because node 1 sees this 20MHz channel as busy due to legacy (hidden) nodes. On the contrary, node 1 senses secondary 40MHz channel as idle, and thus sends simultaneously a CTS frame on 20MHz channel 300-2 and a duplicate thereof on 20MHz channel 300-1, after the SIFS interval, thereby acknowledging reservation of the concerned 40 MHz channel. This makes it possible for MU UL/DL transmissions to take place in the two corresponding 20MHz channels, right after a new SIFS period following the CTS frame. One may note that the duration of the MU UL/DL transmissions is the duration of TXOP minus the duration for transmitting the CTS frame (including the two SIFS guard intervals).

Also node 3 sees 20MHz channel 300-4 as busy from its standpoint, and thus does not send a CTS frame on this channel after the SIFS interval following the received MU-RTS.

In the same time, node 2 for the primary channel and node 4 for the secondary 20MHz channel 300-4, which are second nodes in the corresponding ordered node lists, determine (by sensing their respective channel) that the first node in the corresponding list has not sent a CTS frame during the interval Δ following the conventional SIFS. As noted above, Δ is a fraction of a conventional duration for sending a CTS frame, for instance one or two 802.11 ‘aSlotTime’.

Regarding primary channel, node 2 senses this channel as being idle and thus takes over from node 1 to actually send a CTS frame in response to the MU-RTS. This acknowledges reservation of the primary channel 300-3. This makes it possible for MU UL/DL transmissions to take place in this 20MHz channel, right after a new SIFS period following the CTS frame sent by node 2. One may note that the duration of the MU UL/DL transmissions is reduced by the duration Δ compared to the conventional scheme (or to the situation of the secondary 40MHz channel 300-1/300-2). In return, the primary channel has been actually reserved and thus granted, whereas the conventional scheme would have cancelled the TXOP. Usage of the operating band of the network is thus also improved.

The duration specified in the sent CTS should remain consistent with the TXOP requested originally and thus with the remaining TXOP time. It thus indicates the TXOP time that would normally be set in the CTS frame (as done by node 1 on the secondary 40 MHz channel) minus the number of Δ durations that occurred before sending the CTS frame. This is because the ends of MU UL/DL transmissions should be synchronized for the AP to either send (in case of UL direction) or receive (in case of DL direction) acknowledgments. Furthermore, it helps having the primary channel occupied during the whole TXOP length as required by the standard.

Simultaneously, node 4 senses secondary 20MHz channel 300-4 as busy and thus does not send a CTS frame to take over from node 3. The next node in the ordered node list corresponding to this channel is node 5, which, after having detected no CTS frame from node 3 (first duration Δ) and from node 4 (second duration Δ), senses the same channel as being idle and thus takes over from nodes 3 and 4 to actually send a CTS frame in response to the MU-RTS. Thus node 5 has waited duration Δ a number of times corresponding to the number of nodes preceding it in the relevant ordered node list (here two nodes 3 and 4 precede it in the list).

This CTS sending acknowledges reservation of the secondary channel 300-4. This makes it possible for MU UL/DL transmissions to take place in this 20MHz channel, right after a new SIFS period following this CTS frame sent by node 5. One may note that the duration of the MU UL/DL transmissions is reduced by twice the duration Δ compared to the conventional scheme. In return, this secondary channel has been actually reserved and thus granted, increasing the bandwidth availability for the MU UL/DL transmissions with the AP.

As the MU UL/DL transmissions start asynchronously, the AP may use an antenna for each new MU UL/DL transmission. A maximum number MAX of Δ durations is thus defined (and possibly indicated in the MU-RTS frame) that depends on physical restrictions of the AP. For instance, the schemes described above work with the support of an AP having the number of antennas in correspondence with the numerous delays for starting the MU UL/DL transmissions (and possibly a legacy communication). That means the AP will support a maximum of Δ sensing delays corresponding to it maximum number of antennas.

As an example, for four antennas/reception chains, the AP may support four delays in an 80MHz band (up to four delays issued on each 20MHz channel). However, for a 160MHz band, the AP may only allocate 40MHz widths to CTS addressee stations to cope with the four-chain limitation.

Those delays in starting the MU transmissions have no effect for DL direction (destination nodes will wait in the correct 20MHz sub-channel and then switch their reception onto their dedicated RU in case of MU DL transmission). For the UL direction, the AP has to detect the various sensing delays (if any) in order to direct its PHY reception engines: this is to allocate one PHY engine/antenna per sensing delay and to receive MU UL RUs starting at the same time (anyway their 20MHz sub-channels are contiguous or not).

Figure 9b illustrates a variant of Figure 9a wherein the MU UL/DL OFDMA transmissions on all the RUs of the composite channel (made of two or more 20MHz channels) are aligned in time, by providing padding data (in black in the Figure), if needed, between the CTS frames and the MU UL/DL OFDMA transmission start.

The node thus sends, immediately after having sent the CTS frame, padding data on the communication channel, during a predefined padding duration. To align the start of the MU UL/DL OFDMA transmissions, the end of the predefined padding duration defines a start of data transmission by the nodes over the resource units forming the communication channel. As the same approach is performed on each 20MHz channels forming the requested composite channel (for each of these channels that are available at the end), data transmissions, after padding if any, over the resource units of all the communication channels may start simultaneously.

By inserting padding data, this embodiment secures the reservation of the 20MHz channels as their reservations are acknowledged by CTS frames. Indeed, without padding, a 20MHz wireless channel may be empty for a while, and thus suffer risk to be overtaken by a legacy or overlapping BSS (OBSS) node.

Note that the padding data may be included in the CTS frame itself to make the latter as large as the required time to the data transmission start.

In the example of Figure 9b, the ordered node lists created from the received MU-RTS are the same as for Figure 9a, except that the list for the secondary 40MHz channel is made of nodes 6, 7 and 8. This is to have lists with at most three nodes for ease of illustration. Of course a higher number of nodes may be used.

By determining these lists, the nodes are able to accurately determine when the MU UL/DL OFDMA transmissions will start. This is after a time sufficient for all the nodes of the lists to consider whether or not they have to send a CTS frame. The end of the predefined padding duration, thus defining the start time, is thus time-aligned with the end of a timeslot defined for the last node of the largest ordered node list to send a CTS frame on the corresponding communication channel. It means that the padding time will last N times duration Δ, where N is the difference between the size of the largest ordered node list and the position of the node sending the CTS frame (in its own list).

In the present example, the maximum size is 3 nodes. Thus the maximum padding duration is twice duration Δ (see secondary 40MHz channel). However it may be shorter, such as a single duration Δ if the second node of the list sends a CTS frame (see primary channel), or even be null if the last node of the largest list is the node sending a CTS frame (see secondary 20MHz channel 300-4).

In a preferred embodiment, the AP stipulates, in the Trigger Frame (MU-RTS), the maximum number MAX of Δ durations for the current medium reservation. This has two impacts: first it drives the nodes in building lists with a limited number MAX of nodes per list; second it limits the padding time, and thus the transmission time reduction, before MU UL/DL OFDMA transmissions. The padding duration can thus also be obtained from the maximum number of Δ durations (specified in TF MU-RTS) minus the elapsed Δ duration(s) used for sensing a prior CTS frame before the node determines it should sent by its own a CTS frame.

One may understand that the AP may decide to adjust this maximum number MAX set in the MU-RTS (from 0 to many, where many means linked to AP transmission chain capabilities). This is to adapt the channel access policy used by the nodes. This may be adjusted based on history of CTS frames received in response to MU-RTS frames. Indeed, the AP may decide allowing more nodes to send CTS frames in case the network is high loaded (few requested 20MHz channels are allowed for past MU-RTSs). This is to increase the chances to have the requested composite channel to be actually granted.

Figure 10 illustrates variants of Figures 9a and 9b wherein duration Δ is set to the time required by any node to send a CTS frame (including the conventional SIFS guard time).

Thus, each node that sends a CTS frame at the end has waited n times such timeslot, where n is the number of nodes preceding such node in the considered ordered node list. MU UL/DL transmissions can start just after the last node of the list has been considered. In variants, they can be aligned through the various 20MHz channels, in which case padding (not shown) may be provided).

The embodiments described above are based on several ordered node list per each channel forming the requested composite channel. In variants already introduced above, a single ordered node list may be used for all the channels forming the composite channel. In that case, a current node sensing one or more channels are available preferably sends the CTS frame and/or duplicates thereof simultaneously over the two or more of the communication channels sensed as idle.

In some embodiments, in particular related to UL OFDMA transmission, the node sending the CTS frame on a 20MHz channel (node to which a RU of this channel is also allocated) takes the responsibility of emitting the legacy preamble of the OFDMA transmission. In other words, the node emits on the communication channel (on which it sent a CTS frame) a preamble starting an OFDMA transmission shared between a plurality of the nodes over the resource units forming the communication channel.

The Legacy preamble and HE-SIG-A parts of an 802.11 ax frame have to be conveyed over a 20MHz width, and then following modulated sections (HE-STF/HE-LTF/data) will be transmitted according to the RU width.

This approach advantageously avoids having collisions between nodes when starting the MU UL transmission. Next, each scheduled node sends data only on it allocated RU as indicated by the AP in the MU-RTS.

In the second embodiments illustrated through Figures 11, all the nodes of the lists send a CTS frame (of course if the 20MHz channel is sensed as idle from their point of view), regardless of whether or not the other nodes have sent CTS frames.

In these second embodiments, the nodes use the ordered node list(s) to determine a waiting time duration based on the position of the node within the ordered node list corresponding to a given 20MHz channel; and thus wait for the determined waiting time duration from the reception of the MU-RTS frame, and upon the waiting time duration ending, send the CTS frame to the AP on the communication channel, to acknowledged the reservation for all the nodes. Thus several nodes may acknowledge reservation of the same 20MHz channel. This is shown in Figures 11.

In these embodiments, the nodes of the ordered node list thus wait different time durations based on their respective positions in the list, before sending (upon end of the waiting time) respective CTS frames to the AP on the same communication channel if they respectively sense the communication channel as idle for said requested reservation.

In the examples of the Figures, the waiting time duration lasts n times a timeslot required by any node to send a CTS frame (including the conventional SIFS guard interval), n being the number of nodes preceding the node in the ordered node list.

In the example of Figure 11a, a single ordered node list is built for the whole 80MHz composite channel. Given the RU allocation provided by the MU-RTS as shown in the bottom left part of the Figure, the ordered node list is made of nodes 1,2.....6 and 7. Note that an allocated OFDMA RU may be a subpart of a 20MHz channel or a whole 20MHz channel (e.g. for node 7).

All the nodes are able to listen (i.e. to detect or sense) control frames that are exchanged between them over the network.

As for the previous Figures, a plurality (here four) of (duplicated) MU-RTS frames are sent by the AP to the nodes, for initiating a transmission opportunity (TXOP) reservation for the allocated group on a composite channel, here made of four sub-channels 300-1 to 300-4.

Each of the nodes waits a respective waiting time based on its position in the list: for node 1, the waiting time is zero, meaning that it should send its CTS frame or frames after a SIFS following the MU-RTS frame; for node 2, the waiting time is dCTs corresponding to the time required for sending a CTS frame plus the SIFS guard interval; for node 3, the waiting time is 2.dCTsI for node 4, the waiting time is 3.dCTs; and so on.

When its waiting time ends, each node sends a CTS frame or a duplicate thereof on each one of the plurality of 20MHz channels that it senses as idle for said requested reservation.

In the example shown, node 1 sends a CTS frame on each 20MHz channel, whereas node 2 senses channels 300-1 and 300-2 as busy and thus sends CTS frame only on channels 300-3 and 300-4.

As reservation of the 20MHz channels may be acknowledged by other nodes that the addressee node, higher chances are provided that the requested TXOP be granted. Thus, better use of the network is obtained.

In the example of Figure 11b, one ordered node list is built per each 20MHz channel, according to any list-building approach described above.

For instance based on the RU allocation provided by the MU-RTS (through the RU allocation fields 522) as shown in the bottom left part of the Figure, the ordered node list for primary channel 300-3 is nodes 1 and 2; for secondary channel 300-4, nodes 3 and 4; for tertiary channel 300-2, nodes 5 and 6; and for quaternary channel 300-1, node 7.

Thus, the nodes will only emit a CTS response on the 20Mhz channel or channels which include their allocated RU. As mentioned above, if a node is involved in two or more 20MHz channels (because it has allocated RUs from these channels), it should send CTS frames simultaneously. As a consequence, priority in the ordered node lists is given to the nodes involved in a higher number of 20MHz channels.

As illustrated, node 1 first sends a CTS frame, while node 2 waits for dCTs before also sending a CTS frame because it senses the primary channel as idle (i.e. the CTS frame sent by node 1 is not considered as a legacy communication preventing the channel from being reserved). The same behavior is observed for secondary and tertiary 20MHz channels: nodes 3 and 4 send CTS frames in sequence on channel 300-4, while nodes 5 and 6 send CTS frames in sequence on channel 300-2.

As node 7 is alone in the corresponding ordered node list, it sends only a single CTS without waiting. At this stage, the quaternary 20MHz channel is reserved and thus blocked from any legacy communication.

In a variant, not illustrated, node 7 may emit two CTS frames to occupy the same time as the CTS response process on the other 20MHz channels. In a variant to repeating the CTS frame, it may sends padding data, in a similar fashion as for Figure 9b. More generally, if the node is the last node in one of the ordered node lists, it may send padding data or repeat sending the CTS frame, on the corresponding 20MHz channel during a predefined padding duration, which is as defined above for Figure 9b, for instance N.dCTs> where N is the difference between the size of the largest ordered node list and the position of the last node sending the CTS frame (i.e. the size of the list considered). Note that the padding data may be included in the sole CTS frame send by the last node of the current list, in order to make the CTS frame as large as required to reach the data transmission start.

This shows that this approach is well suited when the RU allocation configuration allocates RUs of each 20MHz channel to the quite same number of nodes.

The CTS frame is no longer a non-HT duplicate frame, but a single non-HT frame.

It should be noted that, for all the embodiments described above, the various CTS frames that can be sent by various nodes over time provide useful indications to the AP. For instance, the AP may efficiently determine which nodes always reply with a CTS frame, or which node often senses one or the other 20MHz channel as being busy.

Based on such history of CTS frames, the AP may establish a map of availability, indicating the status of each 20MHz channel (busy or idle/free) for each node. Next, the AP may use this map to provide a more efficient RU allocation configuration.

For instance, it may avoid allocating, to a node, an RU of a 20MHz channel the node often sees as busy - due to a hidden node. In another example, the AP may move the nodes encountering less problems (those which always respond with a CTS frame) on top of the ordered node lists (e.g. by declaring their respective associations to 20MHz channels first in the MU-RTS).

Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention.

Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Although not described, embodiments of the invention may include the sending of a trigger frame 430 between the CTS frames and the start of the MU UL transmissions. This is to adjust the allocations of the RUs in case one or more 20MHz channels are not reserved at the end of the CTS-sending process. Sending TF 430 particularly applies to the situations where the MU UL transmissions over all the RUs start simultaneously (Figures 9b, 10, 11a and 11b).

Claims

1. A method for reserving at least one communication channel in a wireless network comprising nodes, the method comprising the following steps, at a first node: receiving a multi-user request control frame from a second node, wherein the multiuser request control frame requests reservation of a transmission opportunity on one or more communication channels of the wireless network, the one or more communication channels including a plurality of resource units for exchanging data with the nodes during the reserved transmission opportunity; and upon receiving the multi-user request control frame: determining an ordered node list of some of the nodes, based on a content of the received multi-user request control frame, the ordered node list including an initial node and one or more subsequent nodes; and using the ordered node list to determine if and when said first node has to send a reservation acknowledging frame to the second node on one of the communication channels if sensed as idle by said first node, to acknowledge reservation of the communication channel.

2. The method of Claim 1, wherein using the ordered node list comprises: sensing the communication channel to determine whether any node preceding the first node in the ordered node list sends, on the communication channel, a reservation acknowledging frame to the second node in response to the multi-user request control frame, or not; and in case no preceding node has sent a reservation acknowledging frame within a predefined time period, sending the reservation acknowledging frame on the communication channel to the second node.

3. The method of Claim 2, wherein the predefined time period lasts n times an elementary duration, n being the number of nodes preceding the first node in the ordered node list, and the elementary duration being a fraction of a time required by any node to send a reservation acknowledging frame.

4. The method of Claim 2, wherein the predefined time period lasts n times a timeslot required by any node to send a reservation acknowledging frame, n being the number of nodes preceding the first node in the ordered node list.

5. The method of Claim 2, further comprising, at the first node, sending, immediately after having sent the reservation acknowledging frame, padding data on the communication channel, during a predefined padding duration.

6. The method of Claim 5, wherein the end of the predefined padding duration defines a start of data transmission by the nodes over the resource units of the communication channel.

7. The method of Claim 5, wherein the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and data transmissions, after padding if any, over the resource units of all the communication channels start simultaneously.

8. The method of Claim 7, further comprising, at the first node, determining an ordered node list for each communication channel, based on the content of the received multiuser request control frame, wherein the end of the predefined padding duration is time-aligned with the end of a timeslot defined for the last node of the largest ordered node list to send a reservation acknowledging frame on the corresponding communication channel.

9. The method of Claim 2, further comprising, at the first node, emitting on the communication channel a preamble starting an OFDMA transmission shared between a plurality of the nodes over resource units forming the communication channel.

10. The method of Claim 2, wherein the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and the first node sends the reservation acknowledging frame or a duplicate thereof to the second node simultaneously over two or more of the communication channels.

11. The method of Claim 1, wherein using the ordered node list comprises: determining a waiting time duration based on the position of the first node within the ordered node list; and waiting for the determined waiting time duration from the reception of the multi-user request control frame, and upon the waiting time duration ending, sending the reservation acknowledging frame to the second node on the communication channel.

12. The method of Claim 11, wherein the nodes of the ordered node list wait different time durations based on their respective positions in the ordered node list, before sending respective reservation acknowledging frames to the second node on the same communication channel if they respectively sense the communication channel as idle for said requested reservation.

13. The method of Claim 11, wherein the waiting time duration lasts n times a timeslot required by any node to send a reservation acknowledging frame, n being the number of nodes preceding the first node in the ordered node list.

14. The method of Claim 11, wherein the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and sending the reservation acknowledging frame upon the waiting time duration ending includes sending the reservation acknowledging frame or a duplicate thereof on each one of the plurality of communication channels that is sensed, by the first node, as idle for said requested reservation.

15. The method of Claim 11, wherein the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and sending the reservation acknowledging frame upon the waiting time duration ending includes sending the reservation acknowledging frame or a duplicate thereof on each communication channel that is sensed, by the first node, as idle for said requested reservation and that includes a resource unit assigned to the first node as indicated in the received multiuser request control.

16. The method of Claim 15, wherein an ordered node list is determined for each one of the communication channels based on the content of the received multi-user request control frame, and the method further comprises, if the first node is the last node in one of the ordered node lists, sending padding data or repeating sending the reservation acknowledging frame, on the corresponding communication channel during a predefined padding duration.

17. The method of Claim 16, wherein the end of the predefined padding duration defines a start of data transmission by the nodes over the resource units forming the communication channels.

18. The method of Claim 16, wherein data transmissions, after padding or repeating if any, over the resource units of all the communication channels start simultaneously.

19. The method of Claim 18, wherein the end of the predefined padding duration is time-aligned with the end of a timeslot defined for the last node of the largest ordered node list to send a reservation acknowledging frame on the corresponding communication channel.

20. method of Claim 1, wherein the multi-user request control frame indicates an addressee node of the frame, and the initial node starting the ordered node list is the addressee node.

21. The method of Claim 1, wherein the initial node starting the ordered node list is determined from nodes to which at least one of the resource units is assigned as indicated in the received multi-user request control frame.

22. The method of Claim 1, wherein the initial node starting the ordered node list is determined from a list of nodes indicated in the received multi-user request control frame.

23. The method of Claim 21 or 22, wherein the multi-user request control frame includes an addressee node address field set to a broadcast or group address designating a plurality of nodes.

24. The method of Claim 1, wherein the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and an ordered node list is determined for each one of the communication channels based on the content of the received multi-user request control frame, wherein the subsequent node or nodes, and possibly the initial node, of each ordered node list only include nodes which are associated, in the received multi-user request control frame, with the corresponding communication channel.

25. The method of Claim 24, further comprising, at the first node: sensing each communication channel corresponding to an ordered node list in which the first node is included, to determine whether the communication channel is idle or not for the requested reservation, using the ordered node list corresponding to each communication channel sensed as idle, to determine if and when the first node has to send a reservation acknowledging frame on the communication channel sensed as idle.

26. The method of Claim 1, wherein the multi-user request control frame requests reservation of a composite channel made of a plurality of communication channels, each communication channel being made of one or more resource units, and a single ordered node list is built for the plurality of communication channels, wherein the subsequent node or nodes, and possibly the initial node, of the single ordered node list only include nodes which are associated, in the received multi-user request control frame, with at least one of the communication channels.

27. The method of Claim 1, wherein the received multi-user request control frame assigns resource units of the one or more communication channels to respective nodes.

28. The method of Claim 27, wherein the subsequent node or nodes, and possibly the initial node, of an ordered node list associated with one or more communication channels only include nodes which are associated, in the received multi-user request control frame, with the one or more associated communication channels, and the association between the nodes and the communication channels in the received multi-user request control frame results from the resource unit assignments.

29. The method of Claim 28, wherein an order of the nodes within a said ordered node list is built based on an order in which the assignments of the resources units to the nodes are declared in the multi-user request control frame.

30. The method of Claim 27, further comprising receiving a trigger frame from the second node, the trigger frame providing assignments of resource units to nodes that are different from the resource unit assignments of the received multi-user request control frame.

31. The method of Claim 1, wherein the multi-user request control frame includes a list of responding nodes with respective associated communication channel or channels, the subsequent node or nodes, and possibly the initial node, of an ordered node list associated with one or more communication channels only include nodes which are associated, in the received multi-user request control frame, with the one or more associated communication channels, and the association between the nodes and the communication channels in the received multi-user request control frame results from said list of responding nodes.

32. The method of Claim 31, wherein an order of the nodes within a said ordered node list is built based on the order of the nodes within the list of responding nodes.

33. The method of Claims 28 and 31, wherein the association between the nodes and the communication channels in the received multi-user request control frame results from both said list of responding nodes and the resource unit assignments, wherein an order of the nodes within a said ordered node list is first built based on the order of the nodes within the list of responding nodes and then based on an order in which the assignments of the resources units to the nodes are declared in the multi-user request control frame.

34. The method of any of Claims 24, 25, 26, 28, 29, 31, 32 and 33, wherein an order of the nodes within a said ordered node list gives priority to a node associated with a higher number of communication channels compared to a node associated with a lower number of communication channels.

35. The method of Claim 24 or 33, wherein the same node has the same position in every ordered node list in which it is included.

36. The method of Claim 1, wherein the ordered node list includes a maximum number of nodes depending on a maximum number of antennas of the second node.

37. The method of Claim 1, wherein the received multi-user request control frame specifies a maximum number of nodes for the ordered node list or lists to be determined by the first node.

38. The method of Claim 1, further comprising, at the first node, receiving duplicates of the multi-user request control frame on one or more of the communication channels, simultaneously to receiving the multi-user request control frame on another communication channel.

39. The method of Claim 1, further comprising, at the first node, sending a reservation acknowledging frame at the determined time instant on the communication channel sensed as idle by the first node.

40. The method of Claim 1, wherein the second node is an access point managing the wireless network for the other nodes.

41. The method of Claim 1, wherein each communication channel is a 20 MHz channel according to the 802.11 standard.

42. The method of Claim 1, wherein the multi-user request control frame is a Multi-User Request-To-Send, MU-RTS, frame according to the 802.11 ax standard.

43. A wireless communication method in a wireless network comprising nodes, the method comprising, at a first node: reserving one or more communication channels according to Claim 1, and exchanging data with the second node using a resource unit assigned to the first node from amongst the plurality of resource units of the one or more communication channels.

44. A communication device acting as a node in a wireless network comprising nodes, the communication device comprising at least one microprocessor configured for carrying out the steps of: receiving a multi-user request control frame from a second node, wherein the multiuser request control frame requests reservation of a transmission opportunity on one or more communication channels of the wireless network, the one or more communication channels including a plurality of resource units for exchanging data with the nodes during the reserved transmission opportunity; and upon receiving the multi-user request control frame: determining an ordered node list of some of the nodes, based on a content of the received multi-user request control frame, the ordered node list including an initial node and one or more subsequent nodes; and using the ordered node list to determine if and when said first node has to send a reservation acknowledging frame to the second node on one of the communication channels if sensed as idle by said first node, to acknowledge reservation of the communication channel.

45. A wireless communication system having an access point and nodes, wherein at least one of the nodes is a communication device according to the preceding claim.

46. A communication method in a wireless network comprising nodes, substantially as herein described with reference to, and as shown in, Figure 8, or Figures 8 and 9a, or Figures 8 and 9b, or Figures 8 and 10, or Figures 8 and 11a, or Figures 8 and 11b of the accompanying drawings.