Trigger frames adapted to packet-based policies in an 802.11 network
11553525 · 2023-01-10
Assignee
Inventors
- Stéphane Baron (Le Rheu, FR)
- Romain Guignard (Rennes, FR)
- Pascal Viger (Janze, FR)
- Patrice Nezou (Saint Sulpice la Foret, FR)
Cpc classification
International classification
Abstract
In 802.11ax networks with access points, a trigger frame offers scheduled and random resource units to nodes for data uplink communication to the access points. To make more effective the usage of the network, the access point may design the trigger frame to force the nodes to send some categories of data. Resource units may be defined in trigger frames to be dedicated to small packets or to some access category data. Adjusting the time length of the resource units helps restricting the type of data that can be conveyed by the resource units. Also, using various frequency widths for resource units in the same trigger frame helps reducing padding in the resource units when various traffic types coexist.
Claims
1. A communication apparatus comprising: a sending unit configured to send a trigger frame, wherein the trigger frame reserves at least one wireless communication channel to be used by designated apparatuses and notifies the designated apparatuses of a splitting of the reserved at least one wireless communication channel in a frequency domain into a plurality of resource units which are available for use by the designated apparatuses, and wherein the trigger frame includes an indicator for each of the plurality of resource units, each indicator being associated with a respective resource unit and each indicator indicating an access category selected from the four access categories (AC) defined in the 802.11 standard; and a receiving unit configured to receive data from the designated apparatuses which respond to the trigger frame.
2. The communication apparatus according to claim 1, wherein the trigger frame reserves at least one wireless communication channel by making other apparatuses set Network Allocation Vector (NAV).
3. The communication apparatus according to claim 1, wherein the selected access category is one of the following: AC_BK for background data, AC_BE for best-effort data, AC_VI for video applications or AC_VO for voice applications.
4. The communication apparatus according to claim 1, further comprising: a determination unit configured to determine a frequency of sending a trigger frame based on statistics of a wireless network where the communication apparatus is.
5. The communication apparatus according to claim 4, wherein the statistics include one or more of the following: a number of apparatuses in the wireless network, a number of collisions or a collision ratio occurring during one or more previous transmission opportunities, a distribution of packet sizes received by the communication apparatus, in particular a packet size distribution relative to a maximum packet size, an amount of data transmitted by a plurality of apparatuses of the wireless network, an amount of data transmitted by the plurality of apparatuses of the wireless network for each access category from among a plurality of predefined access categories, and a ratio of medium busyness.
6. The communication apparatus according to claim 1, further comprising: a determination unit configured to determine a number of resource units indicated by the trigger frame, based on statistics of a wireless network where the communication apparatus is.
7. The communication apparatus according to claim 6, wherein the statistics include one or more of the following: a number of apparatuses in the wireless network, a number of collisions or a collision ratio occurring during one or more previous transmission opportunities, a distribution of packet sizes received by the communication apparatus, in particular a packet size distribution relative to a maximum packet size, an amount of data transmitted by a plurality of apparatuses of the wireless network, an amount of data transmitted by the plurality of apparatuses of the wireless network for each access category from among a plurality of predefined access categories, and a ratio of medium busyness.
8. The communication apparatus according to claim 1, wherein the trigger frame defines various selected access categories for various respective resource units.
9. The communication apparatus according to claim 1, wherein the communication apparatus is an access point.
10. A method performed by a communication apparatus, the method comprising: sending a trigger frame, wherein the trigger frame reserves at least one wireless communication channel to be used by designated apparatuses and notifies the designated apparatuses of a splitting of the reserved at least one wireless communication channel in a frequency domain into a plurality of resource units which are available for use by the designated apparatuses, and wherein the trigger frame includes an indicator for each of the plurality of resource units, each indicator being associated with a respective resource unit and each indicator indicating an access category selected from the four access categories defined in the 802.11 standard; and receiving data from the designated apparatuses which respond to the trigger frame.
11. A non-transitory computer-readable medium storing executable instructions, which when executed by one or more processors, cause a communication apparatus to perform operations comprising: sending a trigger frame, wherein the trigger frame reserves at least one wireless communication channel to be used by designated apparatuses and notifies the designated apparatuses of a splitting of the reserved at least one wireless communication channel in a frequency domain into a plurality of resource units which are available for use by the designated apparatuses, and wherein the trigger frame includes an indicator for each of the plurality of resource units, each indicator being associated with a respective resource unit and each indicator indicating an access category selected from the four access categories defined in the 802.11 standard; and receiving data from the designated apparatuses which respond to the trigger frame.
12. A communication apparatus comprising: a receiving unit configured to receive a trigger frame from another communication apparatus, wherein the trigger frame reserves at least one wireless communication channel to be used by designated apparatuses and notifies the designated apparatuses of a splitting of the reserved at least one wireless communication channel in a frequency domain into a plurality of resource units which are available for use by the designated apparatuses, and wherein the trigger frame includes an indicator for each of the plurality of resource units, each indicator being associated with a respective resource unit and each indicator indicating an access category selected from the four access categories (AC) defined in the 802.11 standard; and a transmitting unit configured to transmit data to the another communication apparatus on one or more resource units in a case where the communication apparatus is designated by the trigger frame.
13. The communication apparatus according to claim 12, wherein the trigger frame reserves at least one wireless communication channel by making other apparatuses set Network Allocation Vector (NAV).
14. The communication apparatus according to claim 12, wherein the selected access category is one of the following: AC_BK for background data, AC_BE for best-effort data, AC_VI for video applications or AC_VO for voice applications.
15. The communication apparatus according to claim 12, wherein the another communication apparatus is an access point.
16. The communication apparatus according to claim 12, further comprising: a determination unit configured to determine, from local transmitting memory, data having an access category corresponding to the indicated access category by the trigger frame, and wherein the transmitting unit transmits the determined data.
17. The communication apparatus according to claim 16, wherein the local transmitting memory includes a plurality of transmitting queues, each being associated with an access category.
18. The communication apparatus according to claim 12, wherein the transmitting unit transmits data having a plurality of access categories.
19. A method performed by a communication apparatus, the method comprising: receiving a trigger frame from another communication apparatus, wherein the trigger frame reserves at least one wireless communication channel to be used by designated apparatuses and notifies the designated apparatuses of a splitting of the reserved at least one wireless communication channel in a frequency domain into a plurality of resource units which are available for use by the designated apparatuses, and wherein the trigger frame includes an indicator for each of the plurality of resource units, each indicator being associated with a respective resource unit and each indicator indicating an access category selected from the four access categories defined in the 802.11 standard; and transmitting data to the another communication apparatus on one or more resource units in a case where the communication apparatus is designated by the trigger frame.
20. A non-transitory computer-readable medium storing executable instructions, which when executed by one or more processors, cause a communication apparatus to perform operations comprising: receiving a trigger frame from another communication apparatus, wherein the trigger frame reserves at least one wireless communication channel to be used by designated apparatuses and notifies the designated apparatuses of a splitting of the reserved at least one wireless communication channel in a frequency domain into a plurality of resource units which are available for use by the designated apparatuses, and wherein the trigger frame includes an indicator for each of the plurality of resource units, each indicator being associated with a respective resource unit and each indicator indicating an access category selected from the four access categories defined in the 802.11 standard; and transmitting data to the another communication apparatus on one or more resource units in a case where the communication apparatus is designated by the trigger frame.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) 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.
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
DETAILED DESCRIPTION
(18) The invention will now be described by means of specific non-limiting exemplary embodiments and by reference to the figures.
(19)
(20) 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.
(21) 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.
(22) Next, a source 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.
(23) 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. To do so, it starts a countdown backoff counter designed to expire after a number of timeslots, chosen randomly between [0, CW], CW (integer) being referred to as the Contention Window. This backoff mechanism or procedure is the basis of the collision avoidance mechanism that defers the transmission time for a random interval, thus reducing the probability of collisions on the shared channel. After the backoff time period, the source node may send data or control frames if the medium is idle.
(24) 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.
(25) 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.
(26) The ACK is transmitted at the end of reception of the data frame, immediately after a period of time called Short InterFrame Space (SIFS).
(27) 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. However, this can be seen as a bandwidth waste if only the ACK has been corrupted but the data frames were correctly received by the receiving node.
(28) 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.
(29) 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.
(30)
(31) 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 T0, 23 as shown in the Figure).
(32) Channel sensing is for instance performed using Clear-Channel-Assessment (CCA) signal detection.
(33) CCA is a WLAN carrier sense mechanisms defined in the IEEE 802.11-2007 standards as part of the Physical Medium Dependant (PMD) and Physical Layer Convergence Protocol (PLCP) layer. It involves two functions:
(34) Carrier Sense (CCA-CS) which is the ability of the receiving node to detect and decode an 802.11 frame preamble. From the PLCP header field, the time duration for which the medium will be occupied can be inferred and when such 802.11 frame preamble is detected, a CCA flag is held busy until the end of data transmission.
(35) Energy Detect (CCA-ED) which is the ability of the receiving node to detect non-802.11 energy in a specific 20 MHz channel and back off data transmission. In practice, a level of energy over the 20 MHz channel is sensed and compared to an ED threshold discriminating between a channel state with or without 802.11 energy channel. The ED threshold is for instance defined to be 20 dB above the minimum sensitivity of a PHY layer of the node. If the in-band signal energy crosses this threshold, CCA is held busy until the medium energy becomes below the threshold anew.
(36) 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 9 μs for the 802.11n standard). All dedicated space durations (e.g. backoff) add multiples of this time unit to the SIFS value.
(37) 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).
(38) 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.
(39) 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.
(40) 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 for a DIFS or after the backoff period as explained above.
(41) 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.
(42) 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 μs for the 802.11n 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.
(43) 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.
(44) 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.
(45) 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.
(46) To provide QoS support, 802.11 has defined various levels of priorities for data the source node 20 wants to transmit. The levels are mainly defined based on the nature of the data.
(47) In 802.11e, four Access Categories (AC) are defined:
(48) AC_BK has the lowest priority for background data,
(49) AC_BE has the next priority for best-effort data,
(50) AC_VI has higher priority for video applications, and
(51) AC_VO has the highest priority for voice applications.
(52) Each access category owns one or more traffic classes as defined in the IEEE standard 802.11e-2005.
(53) In practice, the source node 20 has one transmitting buffer queue for each access category and thus implements a backoff counter for each access category. The backoff counter having the lowest value from among the four AC backoff counter is considered as being the backoff counter for the node as discussed above, since it is the first one to reach zero.
(54) 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.
(55) 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.
(56) 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).
(57) 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
(58) 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.
(59) 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.
(60) This prevents the listening nodes 22 from transmitting any data or control frames during that period.
(61) 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.
(62) 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.
(63) In detail, assuming perfect channel sensing by each communication node, collision may only occur when two (or more) frames are transmitted within the same time slot after a DIFS 28 (DCF inter-frame space) or when their own back-off counter has reached zero nearly at the same time T1. If both source nodes use the RTS/CTS mechanism, this collision can only occur for the RTS frames. Fortunately, such collision is early detected by the source nodes since it is quickly determined that no CTS response has been received.
(64) As described above, the original IEEE 802.11 MAC always sends an acknowledgement (ACK) frame 240 after each data frame 230 received.
(65) However, such collisions limit the optimal functioning of the radio network. As described above, simultaneous transmission attempts from various wireless nodes lead to collisions. The 802.11 backoff procedure was first introduced for the DCF mode as the basic solution for collision avoidance. In the emerging IEEE 802.11n/ac/ax standards, the backoff procedure is still used as the fundamental approach for supporting distributed access among mobile stations or nodes.
(66) 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.
(67) IEEE 802.11ac introduces support of a restricted number of predefined subsets of 20 MHz 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.
(68) 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.11n. Indeed, the 20 MHz component channels 300-1 to 300-8 are concatenated to form wider communication composite channels.
(69) In the 802.11ac standard, the channels of each predefined 40 MHz, 80 MHz or 160 MHz 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.
(70) 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.
(71) 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 20 MHz 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).
(72) 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 20 MHz channel of such composite channel.
(73) 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.
(74) Developments in the 802.11ax standard seek to enhance efficiency and usage of the wireless channel for dense environments.
(75) 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.
(76) To actually perform such multi-user transmission, it has been proposed to split a granted 20 MHz 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. Each RU may be defined by a number of tones, the 20 MHz channel containing up to 242 usable tones. This multi-user transmission is illustrated with reference to
(77) 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.
(78) Contrary to downlink OFDMA wherein the AP can directly send multiple data to multiple stations (supported by specific indications inside the PLCP header), a trigger mechanism has been adopted for the AP to trigger uplink communications from various nodes.
(79) To support an uplink multi-user transmission (during a pre-empted TxOP), the 802.11ax AP has to provide signalling information for both legacy stations (non-802.11ax nodes) to set their NAV and for 802.11ax nodes to determine the Resource Units allocation.
(80) In the following description, the term legacy refers to non-802.11ax nodes, meaning 802.11 nodes of previous technologies that do not support OFDMA communications.
(81) As shown in the example of
(82) The trigger frame TF may designate at least one resource unit (RU) 410, or “Random RU”, which can be randomly accessed by more than one node. 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. An exemplary embodiment of such random allocation is illustrated by
(83) The trigger frame TF may also designate Scheduled resource units, in addition or in replacement of the Random RUs. Scheduled RUs may be reserved for certain nodes in which case no contention for accessing such RUs is needed.
(84) In this context, the TF includes information specifying the type (Scheduled or Random) of the RUs. For instance, a tag may be used to indicate that all the RUs defined in the TF are Scheduled (tag=1) or Random (tag=0). In case, Random RUs and Scheduled RUs are mixed within the TF, a bitmap (or any other equivalent information) may be used to define the type of each RU (the bitmap may follow a known order of the RUs throughout the communication channels).
(85) 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.
(86) In the example of
(87) Of course the number of RUs splitting a 20 MHz 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.2 MHz).
(88) As shown in the Figure, all the RUs 410 have the same time length 230 (corresponding to the length of the TXOP).
(89)
(90) An AP sends a trigger frame TF defining RUs with random access. In the example of the Figure, eight RUs with the same bandwidth are defined for a 40 MHz composite channel, and the TF 430 is duplicated on the two 20 MHz channels forming the composite channel. In other words, the network is configured to handle four OFDMA Resource Units per each 20 MHz channel.
(91) Each node STA1 to STAn is a transmitting node with regards to receiving AP, and as a consequence, each node has at least one active backoff value (corresponding to the AC backoff counter having the lowest value).
(92) The random allocation procedure comprises, for a node of a plurality of nodes having an active backoff 510, a first step of determining from the trigger frame the sub-channels or RUs of the communication medium available for contention, a second step of verifying if the value of the active backoff local to the considered node is not greater than the number of detected-as-available RUs, and then a step of sending data is performed on the RU whom number equals the backoff value.
(93) In other words, the Random RUs may be indexed in the TF, and each node uses the RUs having an index equal to the backoff value of the node.
(94) As shown in the Figure, some Resource Units may not be used, for instance RUs indexed 2 (410-2), 5, 7 and 8. This is due to the randomization process, and in the present example, due to the fact that none of the nodes has a backoff value equal to 2, 5, 7 or 8 when the TF is sent.
(95)
(96) The AP sends a TF with the duration 550 for instance 3 ms and a number of Random RUs and/or Scheduled RUs.
(97) Upon receiving the TF, the nodes access the Scheduled RUs or contend for access (e.g. as described above with reference to
(98) In this example, the data traffics sent by the nodes are heterogeneous, i.e. video, voice, web application, control frames, etc. are mixed within the same UpLink (UL) MultiUser (MU) OFDMA transmission.
(99) As shown in the Figure, the resulting PPDUs are very different one from the other in term of duration.
(100) This is because the amount of data to be transmitted greatly varies from one data type to the other.
(101) This is also because, even for the same type of data traffic or for the same quantity of data to transmit, the modulation used by the nodes (the modulation is linked to the distance between the transmitting node and the Access Point) substantially modifies the transmission duration. According to the modulation used (MCS0 to 9 in IEEE802.11ac), the number of bit carried by each OFDM symbol changes, and for a given quantity of data, the transmission duration changes also knowing that the symbol duration is fixed.
(102) For instance, node STA1 may transmit web browsing traffic (AC_BE: access category best effort), node STA2 may transmit a control frame, and node STA4 may transmit a large aggregation of video data frames (AC_VI: access category Video).
(103) As shown in the Figure, the PPDU sent by STA4 (553) use the full TXOP duration of the UL MU OFDMA while the PPDU send by STA1 (551) requires padding (552) to maintain a signal on the RU #1 for the entire TXOP duration. Indeed, if the data transmission lasts less than the TXOP duration 550, the nodes have to pad up (send padding data) up to the end of the UL MU transmission.
(104) This example of
(105) The so-called “small packets” as the one sent by STA7 suffer from important overhead, due to the important amount of padding required to have a signal up to the end of TXOP 230. There is a need to mitigate this situation and to improve efficiency of the Trigger Frame mechanism when small packets are transmitted.
(106) Also, due to the heterogeneity of the different PPDUs transmitted by the nodes, a huge quantity of padding data is sent over the RUs. There is a need to adapt the Trigger Frame mechanism to the heterogeneity of data between the RUs.
(107) All of these needs seek to improve usage of the network, in particular by reducing the padding.
(108) Embodiments of the present invention find a particular application in enhancements of the 802.11ac standard, and more precisely in the context of 802.11ax wherein dense wireless environments are more ascertained to suffer from previous limitations.
(109) Embodiments of the present invention provide improved wireless communications with more efficient use of bandwidth while limiting the risks of collision. In particular, it is sought to reduce the amount of padding data.
(110) An exemplary wireless network is an IEEE 802.11ac network (and upper versions). However, the invention applies to any wireless network comprising an access point AP 110 and a plurality of nodes 101-107 transmitting data to the AP through a multi-user transmission. The invention is especially suitable for data transmission in an IEEE 802.11ax network (and future versions) requiring better use of bandwidth.
(111) An exemplary management of multi-user transmission in such a network has been described above with reference to
(112) First main embodiments of the present invention provide that, in addition to reserving at least one communication channel of the wireless network for a transmission opportunity and defining a plurality of resource units forming the communication channel, the trigger frame includes an indicator restricting data to be sent on at least one of the resource units to data having a restricted type of data.
(113) As a consequence, the nodes may determine, from the trigger frame, an indicator defining a restricted type of data authorized for at least one of the resource units; determine, from local transmitting memory, data having a type corresponding to the determined restricted type of data; and transmit the determined data to the access point on the said resource unit.
(114) By using such indicator, the AP may force the nodes to send specific data that are particularly adapted to the design of the RUs.
(115) Two main approaches are proposed for the first embodiments.
(116) On one hand, the restricted type of data defines small MAC packets relative to the MAC packets conveyed over the wireless network. This approach, described with more details below with reference to
(117) On the other hand, the restricted type of data defines a traffic type of data. Main embodiments refer, for the restricted traffic type of data, to one of the four access categories defined in the 802.11 standard, namely AC_BK for background data, AC_BE for best-effort data, AC_VI for video applications and AC_VO for voice applications. This approach is described with more details below with reference to
(118) Other main embodiments of the invention provide that, in a trigger frame reserving at least one communication channel of the wireless network for a transmission opportunity and defining a plurality of resource units forming the communication channel, the plurality of resource units having the same time length, resource units within the communication channel are defined with different frequency widths.
(119) The RUs provided in a composite channel are thus more adapted to heterogeneous data traffic. By selecting the RU to be used in an appropriate way (examples of selection procedure are described below), the nodes generally reduce the amount of padding sent. Usage of the network bandwidth is thus improved.
(120) For instance, the node may determine whether or not one of the resource units matches an amount of data to be sent in the priority AC transmitting queue of the node, and in case of positive determining, transmitting the data of the priority AC transmitting queue on the matching resource unit.
(121) The approach of these other main embodiments is described below with reference to
(122) The main approaches of the first main embodiments and the approaches of the other main embodiments may be partly or entirely combined in order to add their benefits in reducing the overall padding.
(123)
(124) 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.
(125) 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.
(126) 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.
(127) 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.
(128) 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.
(129) 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.
(130) 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).
(131)
(132) The PHY layer block 703 (here an 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 medium access trigger frames TF 430 to reserve a transmission slot, 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.
(133) The PHY layer block 703 includes CCA capability to sense the idle or busy state of 20 Mhz channels and to report the result to the MAC 702 according to 802.11 standard. Upon detecting a signal with significant received signal strength, an indication of channel use is generated.
(134) The MAC layer block or controller 702 preferably comprises a MAC 802.11 layer 704 implementing conventional 802.11ax MAC operations, and an additional block 705 for carrying out, at least partially, 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.
(135) Preferably, the additional block 705, referred to as the MU management module, implements the parts dedicated to implement all or part of the embodiments of the invention that regards node 600.
(136) For instance, when implementing the first approach of the first main embodiments of the invention, an illustrating example of which being described below with reference to
(137) When implementing the second approach of the first main embodiments of the invention, an illustrating example of which being described below with reference to
(138) When implementing the other main embodiments of the invention, an illustrating example of which being described below with reference to
(139) MU management module 705 includes a frequency width management module 7053, which also includes a “TF Handler” sub-block for the AP to implement the algorithm of
(140) The exemplary node of
(141) 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.
(142)
(143) Small packets may be defined in various ways.
(144) First, small MAC packets may be MAC packets having a packet size lower than a predetermined maximum small packet size (i.e. threshold). For instance, the predefined maximum packet size equals a so-called RTS Threshold parameter set for the wireless network according to the 802.11 standard. Typically, a value equal to 256 bit can be selected. The threshold size may be set in advance in the AP by the administrator or by default factory settings.
(145) In a variant, the small packets may be defined relative to their overhead cost. For instance, small MAC packets may be MAC packets having an overhead due to a MAC header in the packets that is higher than a predetermined maximum overhead (i.e. threshold). A typical ratio value is 20% or 30%.
(146) In a third embodiment, the threshold value (either the predetermined maximum small packet size or the predetermined maximum overhead) can be dynamically determined using a learning mechanism as described below with reference to step 804.
(147)
(148) Such a SP trigger frame is built in order to force the nodes to send only small packets in specific RUs (preferably all the RUs or all the Random RUs defined by the SP TF). To achieve that, the SP TF includes an indicator specifying such restriction to small packets.
(149) Various implementations may be contemplated.
(150) For instance, the restricting indicator specified in the SP TF may be a predetermined maximum small packet size or maximum overhead providing an upper bound when evaluating whether packets are small packets or not. Such information may be provided using a dedicated field 1522 in the signaling shown in
(151) In variant, such upper bound may be predefined and known by all the AP and nodes of the network. In such a case, there is only a need to indicate that the TF is SP TF either for all the RUs or for some RUs.
(152) In embodiments, the restricting indicator defines a trigger frame type, namely the SP TF. It indicates that all the RUs defined by the SP TF are restricted to small packets. In other words, the trigger frame includes a single indicator that define the same restricted type of data for all the resource units of the at least one communication channel.
(153) In other embodiments, the restriction may be defined at the RU level. That means that an indicator defined an RU traffic type: either restricted to small packets, or not restricted. It means that the trigger frame includes one indicator per resource unit, thus defining various restricted types of data for various respective resource units. For instance, a dedicated RU SP or traffic type field may be used in the RU description as described below with reference to
(154) In a variant to the use of a specific restricting indicator in the SP TF, embodiments may provide that the duration of the TXOP is voluntarily made very short in order to implicitly allow only small packets to be transmitted. To achieve this configuration, the AP shall determine a duration of the transmission opportunity based on a predefined resource unit frequency width and a predetermined maximum small packet size, so that the at least one resource unit can only include MAC packets having a packet size lower than the predetermined maximum small packet size. Preferably, the predefined maximum small packet size equals the so-called RTS Threshold parameter set for the wireless network according to the 802.11 standard, and the predefined resource unit width is a minimal frequency width authorized by the 802.11 standard (2.2 MHz when a 20 MHz channel is split into nine RUs).
(155) As described below, a scheduling of the SP TF sending is determined in order to optimize the reduction of the small packet overhead. This includes determining a frequency of sending a trigger frame having a restricted type indicator, based on network statistics on one or more previous transmission opportunities. It corresponds to the first steps 800-803 of the process now described.
(156) The process starts at step 799 where the AP determines if a new event occurs. If a new event occurs, step 799 determines whether the new event corresponds to the reception of a packet at MAC level, or corresponds to the expiration of a SP TF timer as explained below, or corresponds to any other event.
(157) When a packet is received at MAC level, next step 800 is executed during which the AP (in a more general manner, any node in the network may initiate a TXOP by sending a TF, in which case
(158) Exemplary statistics include the number of nodes in the network, the number or ratio of collisions (collided RUs), the number or ratio of used RUs, the number or ratio of unused RUs, a distribution of the packet size received by the AP, etc.
(159) The statistics may be updated each time a new MAC packet is received and decoded by the AP.
(160) Next, at step 801, the AP determines a maximum waiting time between two successive SP trigger frame transmissions.
(161) The determination is based on the updated statistics, and may be performed using pre-computed abacus of the optimal waiting time between two successive SP TFs. To be more precise, the abacus may draw an optimal waiting time as a function of the number of nodes in the network and/or as a function of a collision rate (number of collided RUs out of the total number of RUs during the last N TXOP).
(162) Note that different abacus may be used for different AP profiles: for instance one abacus for an AP acting as a hot spot, one for an AP acting as a home set top box, one for an AP acting as an enterprise AP, etc. This is to better match with network conditions.
(163) In a variant, the time interval between two successive SP TFs may be determined using a learning mechanism. For instance, the AP has received small packets from some nodes during the previous TXOPs.
(164) The ratio of used RUs and the number of small packets received as determined during step 800 may be used to change the scheduling interval. For instance, if a given threshold of RUs is used (typically 80%), the AP may reduce the interval between two SP TFs by dividing a current time interval by a ratio, typically by two. On the contrary, a small usage ratio of the RUs (less than 50%) may drive to increase the interval between two SP TFs by multiplying the current time interval by a ratio, typically by 2.
(165) While two mechanisms (abacus usage and learning mechanism) are suggested above, any other mechanism may be used to adapt the scheduling of the SP TF sending.
(166) Next to step 801 having determined the maximum waiting time, step 802 consists for the AP to schedule the next time instant at which the next SP TF should be emitted. Thus, the AP adapts the delay until the next SP TF must be sent, based on the sending time of the previous SP TF and the maximum waiting time determined at step 801.
(167) Steps 801 and 802 thus define a SP TF timer before sending a new SP TF.
(168) Once, the next sending time instant is known, step 803 consists for the AP to determine when the delay/timer ends. If the delay has just expired, a SP TF has to be sent and step 804 is executed. Otherwise, the SP TF timer value is modified or adjusted according to the delay determined at step 802 (if no timer is running, for instance during the activation phase, a new timer is initiated with the waiting value), and the system returns in the waiting step 799, waiting for a new packet reception.
(169) When the SP TF timer has expired as detected either through test 803 or test 799, step 804 is executed.
(170) At step 804, the AP determines the characteristics of the SP TF: for instance the number of RUs, and which ones are Scheduled RUs and which ones are Random RUs; the number of RUs allocated to small packets, and which ones from all the RUs; the TXOP duration; the maximum size or overhead defining the small packets for the current SP TF.
(171) For instance, the AP may adjust the predetermined maximum small packet size or maximum overhead from one trigger frame to the other, based on network statistics on one or more previous transmission opportunities. This information (maximum size or overhead) may be specified within the AP for the nodes to know the upper limit of the small packets.
(172) Also, the AP may determine the number of resource units forming the communication channel, based on network statistics on one or more previous transmission opportunities. Again, this is to optimize usage of the network bandwidth given the nodes' needs.
(173) In a first embodiment, the number of resource units, the predetermined maximum small packet size or maximum overhead and the TXOP duration are fixed and known by all the nodes. Step 804 only retrieves these values. For instance, a maximum small packet size is set, typically to 256 bytes; the number of RUs dedicated to small packets is equal to the total number of possible RUs (typically 9 RU per 20 MHz channel) in the composite channel (typically 40 Mhz composite channel will contain 18RU); and the TXOP duration is set to fit the predefined maximum small packet size given the number of RUs.
(174) In a more complex second embodiment, step 804 uses predefined abacus to obtain a value for those TF characteristics.
(175) For instance, the number of RUs dedicated to small packets may be set according to a predefined abacus (typically linking the number of SP RUs to the number of nodes in the cell depending on the AP type: hot spot, home, enterprise, etc.).
(176) A similar mechanism may be used to determine the maximum small packet size.
(177) Again, the TXOP duration may be set to fit the abacus-based maximum small packet size given the abacus-based number of RUs.
(178) The abacus may be determined using simulation models or real measurement during evaluation tests of the access point implementing the invention.
(179) In a third embodiment, a learning mechanism is used during step 804 to determine the TF characteristics.
(180) For instance, the number of RUs dedicated to small packets may be determined as a function of the ratio of used RUs during the last TXOP dedicated to small packets. The ratios of used RUs, collided RUs and/or unused RUs are gathered at step 800. Based on such rations, a typical algorithm may be performed at step 804 to determine the number of small packet RUs: if the ratio of used RUs is more than 80%, the maximum number of SP RUs is doubled; if the ratio is less than 50%, the maximum number of SP RUs is divided by two; otherwise, the maximum number of SP RUs is unchanged.
(181) Note that the number of RUs per 20 MHz should not exceed a maximum number of RUs, typically nine RUs per 20 MHz channel. Such value (9 RUs per channel) may be used by the AP as a default value when starting the wireless network cell.
(182) Of course, combinations of these embodiments may be contemplated within the scope of the present first embodiments: for instance, a fixed maximum small packet size and a number of SP RUs determined dynamically.
(183) Next to step 804, step 805 creates and sends the SP trigger frame having the characteristics determined at step 804. This SP TF sending causes one or more nodes of the network to transmit their pending small packets in Random RUs during the SP TXOP. Step 805 also launches a new SP TF timer initiated with the current waiting interval value.
(184)
(185) At step 900, the node waits until a MAC packet addressed to it is received. Upon receiving such MAC packet, the process goes to step 811 in which the node determines whether or not the received packet is a SP trigger frame.
(186) To do so, the node checks, at step 901, whether or not at least one RU defined by the TF is dedicated to small packets, by reading the appropriate restricting indicator in the TF (for instance the RU traffic type field 1521—see
(187) If it is not, the received MAC packet is processed according to conventional mechanisms, and the process loops back to step 900. In particular, in case the AP has sent a trigger frame with no indication of small packet collection but with a very short TXOP to force the nodes to only send small packets, the node performs a conventional processing, meaning that it will looks for appropriate (small packet) data in its transmitting buffer queues.
(188) If the received packet is a SP TF, step 902 is executed during which the node determines whether or not it has some small packets to transmit.
(189) To do so, the node first determines the maximum small packet size or overhead ratio. Depending on how the SP TF characteristics are defined as described above with reference to step 804, this maximum small packet size or overhead ratio can be known in advance (fixed parameter), or transmitted in the SP TF (through field 1522 of each RU for instance—see
(190) As conventionally known, 802.11 nodes usually have a plurality of ordered transmitting queues (or Wi-Fi Multimedia (WMM) waiting queues). The queues are usually associated with traffic classes or access categories as mentioned above. Each WMM waiting queue is associated with a dynamic priority value which is usually an AC backoff counter.
(191) During step 902, the node builds a list of small packets (SP list) to be sent. In a first embodiment, only the first (according to a transmission order in the queue) small packet from the WMM transmitting queue having the highest priority value (i.e. with the smallest backoff counter), given the maximum small packet size or overhead, is considered. So, a single small packet is added to the list and thus sent by the node during the current SP TXOP.
(192) In a second embodiment, the first small packet from each WMM transmitting queue, given the maximum small packet size or overhead, is considered. So, a maximum of four small packets (in case of the four 802.11 WMM queues) is added to the list and thus sent during the current SP TXOP.
(193) In a third embodiment, all the small packets from all the WMM transmitting queues, given the maximum small packet size or overhead, are considered.
(194) In a fourth embodiment, in addition to the four existing 802.11 WMM queues, the node may maintain a fifth transmitting queue in which it queues only small packets (given the maximum small packet size or overhead) as they are generated from transmission. In this embodiment, all the packets of the fifth transmitting queue storing only small packets are considered.
(195) Once the SP list has been built, step 903 determines whether the SP list is empty or not (i.e. are there one or more small packets to transmit?).
(196) If the SP list is not empty, step 904 is executed. Otherwise, the process loops back to step 900.
(197) At step 904, the node selects one or several RUs to transmit all or part of the small packets of the SP list.
(198) In a first embodiment, only one RU is selected, for instance one Random
(199) RU among the SP RUs using the random allocation procedure 500 of
(200) In a second embodiment, if the SP list contains a plurality of packets, a plurality of RUs may be selected (e.g. a Random RU), for instance one RU per packet of the SP list. However, several packets per RU can also be contemplated.
(201) For illustrative purposes only, one RU per packet may be selected for the first and second embodiments described at step 902. In this configuration, the TXOP duration is preferably short so that the SP RUs are designed to fit more or less the maximum small packet size. This reduces the amount of padding.
(202) Still for illustrative purposes, a number of RUs allowing the transmission of all the small packets of the SP list (in one or several RUs if needed) may be selected for the third and fourth embodiments described at step 902.
(203) If a plurality of RUs is to be selected, a random allocation procedure is applied, for instance the procedure 500 described above with reference to
(204) Next to step 904, the node transmits the small packets of the SP list in the selected RU or RUs, at step 905.
(205) In the first and second embodiments described above at step 902, each small packet of the SP list may be sent on a different RU.
(206) In the third and fourth embodiments described above at step 902, the small packets are for instance aggregated (or concatenated) to fill in the selected RU or RUs, according to the TXOP duration. When small packets are aggregated, the TXOP duration may be of conventional time length because several small packets are sent within a single RU. The aggregation thus helps reducing the amount of padding. Next to step 905, the process loops back to step 900.
(207) Turning now to
(208)
(209) During the initialization of the AP, the number of RUs to be allocated during an OFDMA transmission is predetermined at step 1000. This number can be fixed or dynamically updated. Various frequency widths may be contemplated for the RUs within the same composite channel, as described below with reference to the embodiments of
(210) Once the number of RUs is known, step 1001 consists for the node in gathering some statistics about the wireless network during one or more previous TXOPs. As described below, these statistics will be used to define the traffic policy through which each RU to be reserved is associated with a traffic type.
(211) Several events and statistics can be tracked by the AP, for instance: a collision ratio (of colliding RUs). Such ratio corresponds to a percentage of bandwidth loss due to collisions among the nodes of the 802.11 network cell.
(212) When there are many collisions, many nodes contend for access the wireless medium at the same time. As a consequence, bandwidth sharing driven by the AP can make the wireless access more fluent. So, for instance, when the collision ratio is greater than a predetermined threshold, one or several TT trigger frame can be sent; statistics regarding traffic types (for instance the four 802.11 access categories). An example of statistics is the part of each traffic type among the overall amount of data sent by the nodes. It corresponds to network statistics on the amount of data received in one or more previous transmission opportunities for each of the predefined traffic types. Note that
(213) It is for the AP to assign a RU traffic type to each RU of the TT trigger frame based on the part of each traffic type in the overall traffic. A trigger frame profile may thus be generated and adapted, later on, as the network traffic evolves (due to evolving traffic requirements such as the latency of each data traffic); a queue size associated with each traffic type representing the sum of all corresponding traffic waiting to be sent by all the nodes.
(214) As known in the 802.11 standard, the MAC header of the send packet includes a “Queue Size” field indicating the amount of buffered traffic for a given traffic type that is waiting in the transmitting node. Based on such information, the AP is able to compute global statistics on total queue size for each of the predefined traffic types, a total queue size for a predefined traffic type summing the sizes of transmission queues that are associated, in the nodes, with the predefined traffic type. The AP may then build an associated TT trigger frame defining RUs with dedicated traffic types.
(215) Next to step 1001, step 1002 uses the statistics to dedicate one or more RUs to respective specific RU traffic types.
(216) When all the RUs of a trigger frame have been reserved for dedicated traffic types (in a variant when a predetermined number of RUs have been reserved for dedicated traffic types) (test 1003), the trigger frame is built and broadcasted to all the nodes (1004 and 1005).
(217)
(218) Based on statistics (including latency associated with each of the four 802.11 standard access categories [voice, video, best effort, background] that have different requirements about latency—step 1011), the AP may determine at step 1012 a time interval before sending the next TT Trigger Frame, also depending on which traffic types will be associated with the RUs of the TT Trigger Frame. As the most critical access category is the video access category, the time interval will be shorter for such a TT Trigger Frame including Video Access RUs than for a TT Trigger Frame including RUs only of the other access categories.
(219) In a second sub-process, the AP waits for the end of the determined time interval (test 1013), and then prepare the TT Trigger Frame (step 1004) before sending it (step 1005).
(220)
(221) Upon receiving a TT trigger frame, i.e. a trigger frame defining one or more RUs associated with restricting traffic types (test 1100), the node checks whether it is a TT Trigger Frame indicating a single restricting traffic type or not (test 1101).
(222) If only one restricting traffic type is defined in the TT Trigger Frame, the node selects the corresponding access category WMM queue (step 1120).
(223) Next, it checks (step 1121) whether or not there is at least one packet ready to be sent in the selected AC WMM queue. In such a way, the node selects data in a transmitting queue storing data having only the determined restricted type of data.
(224) If there is one or more packets in the selected AS WMM queue, the node selects (step 1122) one (or more) RU having the restricting traffic type, for instance by using the procedure 500 of
(225) Next, the node transmits MPDU frames with the packets of the selected AS WMM queue, in the selected RU or RUs (step 1123) and waits for a corresponding acknowledgment from the AP indicating a successful transmission (step 1124).
(226) If two or more restricting traffic types are defined in the TT Trigger Frame (mixed traffic type), the node successively considers the transmitting queue according to an highest-to-lowest priority value order, until data is sent on a resource unit; and for each transmitting queue successively considered, it determines whether a resource unit in the communication channel has the restricted traffic type, and in case of positive determination, transmits data from the transmitting queue currently considered on the determined resource unit.
(227) As shown in the Figure, the node first selects the access category having the (next) highest priority, i.e. the access category having the current smallest backoff value (step 1110).
(228) Next, the node parses the list of RUs as defined in the received TT Trigger Frame in order to select an RU having the same traffic type as the (next) highest priority (step 1111).
(229) If a single RU having the (next) highest priority traffic type is detected, it is selected (step 1122).
(230) In case several RUs have the appropriate traffic type, a random allocation procedure as procedure 500 of
(231) Once an RU has been selected, steps 1123 and 1124 described above are executed to perform data transmission.
(232) If no RU defined in the TT TF has a dedicated traffic type matching the (next) highest priority traffic type, it is determined if a non-processed access category remains (step 1112), in which case the process loops back to step 1110.
(233) Thanks to the restriction of RUs to specific traffic types, the AP may efficiently adapt the TXOP to the various types of traffic.
(234) Turning now to
(235)
(236)
(237) The process starts at step 1200 in which the AP gathers statistics on the traffic in the network cell (BSS), for instance statistics regarding each traffic type (for instance the four 802.11 access categories—video, voice, background, best effort). An example of statistics is the part of each traffic type among the overall amount of data sent by the nodes. Other statistics may include the number of registered nodes, the modulation scheme (MCS) used by each node, the modulation scheme (MCS) used on each RU, an identification of steady traffic (video streaming, VoIP . . . ) or random traffic (Web browsing, control frame . . . ), the mean duration of transmission (without padding i.e. the duration for a transmission outside multi-user OFDMA uplink transmission or in a multi-user OFDMA uplink transmission by excluding padding duration).
(238) Next, at the step 1201, the AP determines the number of concurrent (i.e. simultaneous) nodes and/or traffic types.
(239) The number of concurrent nodes/traffics is used by the AP to define the number of RUs to allocate for the MU UL TXOP. For instance, the higher the number of simultaneous nodes/traffics, the higher the number of RUs.
(240) For illustrative purpose, the number of RUs may be set equal to the number of active nodes (i.e. transmitting data) in the N previous TXOPs (possibly TXOPs implementing the present embodiment of
(241) In any case, a traffic type is associated to each RU.
(242) Step 1202 thus consists in reserving RUs in the TF for specific nodes or traffics.
(243) Note that the RU allocation of step 1202 should preferably take into account the number of concurrent data traffics within each node, since a corresponding number of RUs should be provided for the specific node, if at all possible. For instance, a node may transmit two separate data traffics through the AP: a video stream may coexist with a VoIP communication in a smartphone.
(244) As a consequence, the number of RUs may be set equal to the number of pairs (traffic type, transmitting node) detected during the N previous TXOPs (possibly TXOPs implementing the present embodiment of
(245) Step 1202 thus defines an optimal number of RUs that should be provided to satisfy the network needs, each RU being dedicated to a respective traffic type. Note that this optimal number of RUs is not necessarily correlated to the real number of available RUs at this stage of the process (it means that the optimal number may be higher than the number of possible RUs in the composite channel).
(246) Next, steps 1203 and 1204 are executed in relation with each other and may be looped to avoid inconsistency to define the duration of the TXOP or the number of RUs and corresponding frequency widths first, and the other in relation to the information first defined.
(247) At step 1203, the AP computes the duration of the next MU UL transmission, i.e. the next TXOP triggered by the trigger frame to be sent.
(248) To do so, the AP determines which types of data traffic are currently conveyed in the network (based on statistics on previous N TXOPs for instance or on the traffic types associated with the RUs determined at step 1202) and more especially the repartition of data traffic, for instance according to the four 802.11 ACs, in order to adjust the TXOP duration accordingly.
(249) More generally, the duration may be determined according to the average duration of N (integer) previous transmissions in order to minimizing the padding on average.
(250) In a variant, the duration may also be determined to give priority to some traffic. For instance, if a lot of best effort traffic is conveyed in the RUs during one or more previous TXOPs, a short TXOP duration may be chosen, for instance by taking the time allowing the transmission of the typical quantity of data of the best effort access category (according the statistics obtained in 1200). On the contrary, if several video streams are on-going, a larger TXOP duration may be chosen, preferably close to the TXOP limit defined for the video access category.
(251) Without any statistic, the TXOP duration may be set to ¼ of the TXOP limit duration of the video access category (AC_VI) and accordingly one RU with a 106 tones width is allocated for video—AC_VI (or traffic with large quantity of data to transmit), one RU with a 52 tones width is allocated for VoIP—AC_VO (or traffic with intermediate quantity of data to transmit) and three RUs with 26 tones each, are allocated for respectively Best effort, Background access category (AC_BE, AC_BK) and control packet in a 20 MHz channel, i.e. one RU per each traffic type on the 20 MHz band.
(252) Once the TXOP duration has been determined, the AP defines, at step 1204, the RU characteristics for the next TXOP.
(253) This includes the number of RUs. Furthermore, as the TXOP duration is set, the other main RU characteristic to be determined is the frequency width (number of tones) for each RU forming the TF.
(254) According to the TXOP duration and the quantity of data to transmit for each traffic type (list of the optimal RU allocation and associated quantity of data), the AP determines the frequency width of each RU (for each traffic type) in term of tones (the quantity of data to transmit being a function of the TXOP duration and of the RU_width_in_tones).
(255) Next, the AP decides how to allocate the tones available on the composite channel to various RUs, in order to define the TF. This takes into account the RU_width_in_tones for each traffic type.
(256) For instance, four RU_width_in_tones may be defined for a channel of 20 MHz (26 tones, 52 tones, 106 tones and 242 tones).
(257) For a 20 MHz channel in OFDMA MU Uplink, the maximum number of RUs with respect to the definition of the RU_width_in_tones may be defined as follow: nine RUs of 26 tones each; or four RUs of 52 tones each plus one RU of 26 tones; or two RUs of 106 tones each plus one RU of 26 tones; or one RU of 242 tones. These are exemplary RU profiles among a wide set of possible RU profiles. The only limitation to mix the different RU_width_in_tones is the maximum number of tones for a channel (e.g. for 20 MHz, 242 tones).
(258) Back to the previous RU profile example, the AP may allocate for instance three RUs of 26 tones plus one RU of 52 tones plus one RU of 106 tones in a channel of 20 MHz.
(259) If the number of required RUs defined at step 1202 as the optimal number of RUs is higher than the capability of the composite channel given the RU_width_in_tones for each traffic type, a prioritization is performed. It can be made based on the traffic categories, to give priority to steady streams, small packets, or to minimize as much as possible padding by excluding the RU or RUs for which the actual transmission duration of useful data (by taking into account the modification of duration applied by the number of tones allocated) is very different from the TXOP duration defined in the previous step. These RUs are those for which too few data are scheduled for transmission.
(260) After, the allocation and the definition of the RU characteristics, the TXOP duration can be refined (if necessary) to adjust the transmission duration with the effective RU slots.
(261) The RU frequency width is preferably determined based on the traffic type to which it is dedicated as determined at step 1202 based on statistics. That is the frequency width of the resource units is determined based on statistics on data related to each traffic type as received in one or more previous transmission opportunities. Note that the RUs may be explicitly assigned to a specific traffic type in the TF, using the mechanisms described above with reference to
(262) However, the specific traffic type may not be signalled in the TF. This is because, by designing the RUs with appropriate sizes, the nodes will select data that fit well the available bandwidth of the RUs, i.e. the intended content (traffic type) is implicitly designated. For instance, RUs with large frequency width are implicitly dedicated for large contents such as video.
(263) An example of RU frequency widths is the following: the AP allocates 4 times more tones to a video RU_traffic_type than to a background RU_traffic_type and 2 times more tones to a voice RU_traffic_type than to a background RU_traffic_type in order to keep the differentiation brought by the TXOP Limit parameter of the 802.11n standard. In other words, the resource unit or units associated with AC_BK and AC_BE traffic type have a first frequency width (for instance the minimal frequency width authorized by the 802.11 standard, i.e. 2.03 MHz when the 20 MHz channel is split into nine RUs), the resource unit or units associated with AC_VO have a frequency width equal to twice the first frequency width and the resource unit or units associated with AC_VI have a frequency width equal to four times the first frequency width.
(264) Due to the 1/4 ratio of the frequency width between AC_BK RUs and AC_VO RUs, the TXOP duration is preferably set less or equal to a quarter of the TXOP Limit parameter set for the wireless network according to the 802.11 standard.
(265) For illustrative purposes, the 802.11n standard defines a TXOP Limit of 3.008 ms for the video access category (AC_VI), 1.504 ms for the voice access category (AC_VO) and Oms (i.e. 1 MPDU) for the background and best effort access categories (resp. AC_BK and AC_BE). When implementing the present embodiment, the AC_BK and AC_BE may be defined with the minimum number of tones (e.g. 26 tones), the AC_VO with twice more tones, i.e. 52 tones and the AC_VI with four times more tones, i.e. 106 tones. For this configuration the duration of the MU UL transmission, thus defining the TXOP duration, is set to 752 μs (3.008 ms/4).
(266) Furthermore, the frequency width (number of tones) for an RU may also depend on the modulation scheme, MCS (which also impact the transmission duration) used by the node to reach the AP (an MCS may be defined by each node, but also per RU in each node). In other words, the frequency width of a resource unit associated with a traffic type is adjusted based on a modulation scheme used by the nodes to send data having the associated traffic type in one or more previous transmission opportunities.
(267) On the other hand, the AP may also set the MCS to use in order to minimize padding and to maximize BER.
(268) Once all the RU characteristics are known, the TF can be generated and sent on the network at step 1205. A signalling of some RU characteristics in the TF is further described below with reference to
(269) Note that, for Random RUs, the TF should signal at least the TXOP duration, the number of Random RUs and the frequency width (RU_width_in_tones) for each Random RU. If an RU is explicitly dedicated to a specific traffic type, it is signalled in the TF using a RU_traffic_type field. The latter may be substituted to the RU_width_in_tones if the number of tones is fixed per traffic type.
(270) Next to the TF sending, the AP waits, at step 1206, for the end of the TXOP and sends an acknowledgment (1207), if appropriate, to acknowledge reception of all or part of the MPDUs transmitted from multiple users within the OFDMA TXOP.
(271) Preferably, the ACK frame is transmitted in a non-HT duplicate format in each 20 MHz channel covered by the initial TF's reservation.
(272) Next, at step 1208, the AP updates its statistics according to the current transmission.
(273)
(274) At step 1300, the node detects a trigger frame reserving a composite channel. The TF is then decoded in order to analyse its content. The TF defines a plurality of RUs.
(275) At step 1301, the node selects one (or more) of the RUs using the RU characteristics specified in the TF. The selection may also be based on the traffic types it has to transmit.
(276) The node selects any Scheduled RU corresponding to its node_AID and determines the possible traffic type associated with the Scheduled RU if any. This is to send appropriate data in the RUs.
(277) For Random RUs, the node selects one (or more) Random RU:
(278) either having a signalled traffic type corresponding to a traffic type the node has to transmit (for instance the priority AC queue). This is to drive the node to transmit, on one resource unit, data having the same traffic type as the traffic type associated with the resource unit,
(279) or having a frequency width in tones that matches, given the TXOP duration, as much as possible the amount of data it has to transmit (for instance from the priority AC queue). It means that the node determine whether or not one of the resource units matches the amount of data to be sent in the transmitting queue having the highest priority value, and only in case of positive determining, it transmits the data of the transmitting queue having the highest priority value on the matching resource unit.
(280) The node may also use other information from the TF, such as MCS, to adjust its transmission parameter.
(281) Next, at optional step 1302, the node may adapt or adjust a modulation scheme for modulating the data on the resource unit (possibly resource units), the adapting maximizing the time duration of transmitting the data within the transmission opportunity. This step of reducing the MCS seeks to minimize padding in relation to the TXOP duration for the next MU UL transmission. However the same amount of data is transmitted, but with a better BER.
(282) Next, at step 1303, the node transmits the data on the respective one or more RUs selected at step 1201.
(283) At step 1304, the node waits for an acknowledgement from the AP.
(284) When a successful transmission acknowledgment is received, the node flushes the buffered data from the AC transmitting queues at step 1305, ending the process.
(285)
(286) As shown in the Figure, the AP sends a TF with RUs having different frequency widths (in tones number) and having a shorter TXOP duration 550′ compared to
(287) In the example of the Figure, the PPDU of node STA4 comprise the same amount of data between
(288) On the other hand, the nodes that where sending a lot of padding in
(289) Note that the nodes to which no RU has been allocated (STA3, STA7 and STA8 cannot transmit in this MU UL OFDMA transmission) will transmit in a next MU UL transmission or through a conventional access to the wireless medium (EDCA).
(290) The embodiment of
(291) Random RUs may be used at the creation of the network cell driven by the AP, before Scheduled RUs are used.
(292) Initially, predefined statistics defining a proportion of the different traffic types in a cell and a typical number of nodes in a cell according to the AP characteristics (office, home, stadium . . . ) may be used to define the initial number of Random RUs. TXOP duration and the RU frequency widths may be defined by keeping the scale factor of the 802.11 standard, for instance the AC_BK and AC_BE are defined with 26 tones, the AC_VO with 52 tones and the AC_VI with 106 tones, while the MU UL transmission duration is set to 750 μs.
(293) The initial Random-based phase may be a transitory step used as a learning phase to learn about the traffic type or types sent by each node, the modulation used by each node and/or on each RU, etc. before the Scheduled-based mode is used. In other words, it is a phase during which the node collects or gathers statistics as those mentioned above with reference to step 1200.
(294) During the learning phase, the Random RUs may be dynamically adjusted or refined based on the statistics dynamically gathered. This is to progressively modify the RUs to mirror the real traffic proportions and the number of active registered nodes. A result of the learning phase is that the width of each RU and the allocation of each RU to a dedicated node can be defined precisely according to current network usage. Preferably, the RU frequency width is chosen based on traffic types, but also based on the modulation scheme because the latter can greatly modify the transmission duration required for a fixed data quantity (for instance modulation MCS 0 provides a bitrate of 6.5 Mbps, while modulation MCS 1 provides a bitrate of 13 Mbps).
(295) Next, the Scheduled RU mode is used where the AP explicitly allocates the designed RUs to specific nodes based on node's needs (for instance transmitted during a previous TXOP; or the AP may use traffic specification, e.g. TSPEC in HCCA, supplied by some nodes to define their need).
(296)
(297) The ‘RU Information Element’ (1510) is used by the AP to embed additional information inside the trigger frame related to the OFDMA TXOP. It format preferably follows the ‘Vendor Specific information element’ format as defined in the IEEE 802.11-2007 standard.
(298) The ‘RU Information Element’ (1510) is a container of one or several RU attributes (1520), having each a dedicated attribute ID for identification. The header of RU IE can be standardized (and thus easily identified by the nodes) through the Element ID, OUI, OUI Type values.
(299) The RU attributes 1520 are defined to have a common general format consisting of a one-byte RU Attribute ID field, a two-byte Length field and variable length attribute specific information fields.
(300) The usage of Information Element inside the MAC frame payload is given for illustration only, any other format may be supportable.
(301) The choice of embedding additional information in the MAC payload is advantageous for keeping legacy compliancy with the medium access mechanism, because any modification performed inside the PHY header of the 802.11 frame would have inhibited any successful decoding of the MAC header by legacy devices.
(302) As shown in the Figure, a dedicated RU attribute follows the following format: The Attribute ID is a dedicated value identifying the ‘al Info’. A value unused in the standard, e.g. in the range 19-221, may be selected. This one-byte value is a tag starting the ‘RU Info’. A two-byte length field defining the length of the attribute body.
(303) The attribute body varies according to the embodiments considered. Attribute body 15a refers to the small packet embodiment of
(304) To efficiently signal the small packet mode (
(305) an SP type field 1521 to indicate if the RU (or all the RUs) is restricted to small packets (or if the TF is a SP TF). This field set to the SP type (small packet type) indicates to the receiving node that the RU (or all the RUs) can only be used to send small packets, for instance smaller than a maximum small packet size;
(306) a maximum small packet size field 1522 used by the AP to explicit define a maximum size for the small packets.
(307) To efficiently signal the traffic type mode (
(308) a TF_type field 1523 to indicate if the Trigger Frame specifies the mixed mode of step 1101 or not (i.e. specifies a list of RUs with the same traffic type or a list of RU with different mixed traffic types);
(309) an RU_nb field 1524 to define the number of Resource Units composing the composite channel. This number also gives the number of entries in the next field;
(310) an RU_list field 1525 listing the characteristics of each RU of the current OFDMA TXOP. Each entry in the list 1525 may include the following set of field:
(311) an RU_index field to specify the index of the current RU in the RU list;
(312) an RU_type field to specify the Random or Scheduled mode of the RU (only in case of mixed mode);
(313) an RU_traffic_type field to specify the traffic type supported by the RU; and
(314) an optional Node_AID field to define the identifier of a node in case of a Scheduled RU. This could be the MAC address, or the Association Identifier (AID), or the Partial AID of a node.
(315) To efficiently signal the RU frequency widths (
(316) an RU_nb field 1524 to define the number of Resource Units composing the composite channel. This number also gives the number of entries in the next field;
(317) an RU_list field 1525 listing the characteristics of each RU of the current OFDMA TXOP. Each entry in the list 1525 may include the following set of field:
(318) an RU_index field to specify the index of the current RU in the RU list;
(319) an RU_width_in_tones field to specify the number of tones for this RU;
(320) an RU_type field to specify the Random or Scheduled mode of the RU (only in case of mixed mode);
(321) an RU_traffic_type field to specify the traffic type supported by the RU;
(322) an optional MCS field to specify the modulation scheme to use for the RU; and
(323) an optional Node_AID field to define the identifier of a node in case of a Scheduled RU. This could be the MAC address, or the Association Identifier (AID), or the Partial AID of a node.
(324) All or part of the various attribute bodies described above may be combined to define for instance an SP Trigger Frame which is also a TT Trigger Frame with RUs having varying frequency widths.
(325) 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.
(326) 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.
(327) 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.