Transmitting device, transmitting method and receiving device

Abstract

A transmitting device, a transmitting method, and a receiving device, the transmitting device comprising: a transmitter, transmitting a trigger frame for allocating resources for uplink multi-user (UL) MU transmission, the trigger frame comprising a common information field, the common information field comprising a type subfield indicating one of a plurality of trigger types, wherein the plurality of trigger types include a first trigger type; and a receiver, receiving data of the UL MU transmission, wherein, in response to the type subfield indicating the first trigger type, the trigger frame comprises a first dependent type field, the first dependent type field comprising information indicating a traffic identifier TID of the data to be used for the UL MU transmission.

Description

[0001] This application is a divisional application of the Chinese invention patent application with the application date of July 4, 2017, application number 201780036777.5, invention name “Transmission device and transmission method”, and the applicant is Panasonic Electric (USA) Intellectual Property Corporation. Technical Field

[0002] The present disclosure generally relates to a transmission apparatus and a transmission method for exchanging multi-user management frames. Background Art

[0003] The IEEE (Institute of Electrical and Electronics Engineers) 802.11 working group is currently standardizing the next generation WLAN (Wireless Local Area Network) technology under the 802.11ax task group. The main goal of the task group is to improve spectrum efficiency to enhance system throughput / area in high-density scenarios of access points (APs) and / or terminal stations ("non-AP STAs" or simply STAs in the rest of the document). Devices based on the IEEE802.11ax specification are generally referred to as High-Efficiency (HE) devices. Among the various technologies proposed, Orthogonal Frequency Division Multiple Access (OFDMA) and uplink multi-user transmission are two key technologies adopted by the IEEE 802.11ax task group to achieve the throughput improvement goals. Figure 1 An example 802.11ax WLAN network 100 having an AP 190 and several STAs associated with the AP 190 is illustrated.

[0004] The IEEE 802.11 specification defines various types of frames that can be exchanged within a wireless network based on IEEE 802.11. Management frames are used to enable and maintain wireless communications within a wireless network. These frames are generated within the medium access control (MAC) layer of the IEEE802.11 device and are usually sent with a more robust modulation and coding method (MCS) to ensure their correct reception. Some management frames are broadcast by access points (APs) within a wireless basic service set (BSS). Broadcast management frames include, for example, beacon frames that announce the existence of the BSS and its various attributes (such as the wireless channel it is operating on, its service set identifier (SSID), etc.). If a STA within the communication range of the AP has not yet joined the BSS, it can use the information obtained from the beacon frame to initially join the BSS, or if it has already joined the BSS, update its BSS record. However, most management frames are used in a unicast manner (i.e., addressed to a specific STA or AP).

[0005] In some cases, the AP may send a management frame to a specific STA to request it to perform a specific action (e.g., a disassociation frame to request the STA to leave the BSS). However, in most cases, there will be an exchange of relevant management frames between the AP and the STA. As an example, an association request frame is sent by the AP to the STA, and the STA sends an association response frame back to the AP to join the BSS. As another example, an add block acknowledgement (ADDBA) request is sent by the AP to the STA, and the STA sends an ADDBA response frame back to the AP to set up the use of the block acknowledgement (Ack) mechanism between the two devices.

[0006] Citation List

[0007] Non-patent literature

[0008] [NPL 1] IEEE802.11-15 / 0132r17, Specification Framework for TGax, May 2015

[0009] [NPL 2]IEEE802.11-16 / 0024r1, Proposed TGax draft specification

[0010] [NPL 3]IEEE Std 802.11-2012 Summary of the invention

[0011] Although multi-user transmission is possible in the downlink using Multi-User Multiple Input Multiple Output (MU-MIMO), and Orthogonal Frequency Division Multiple Access (OFDMA) can be used in both the downlink (DL) and uplink (UL), it is difficult to perform management frame exchanges in multi-user transmission in an efficient manner.

[0012] Therefore, a non-limiting exemplary embodiment of the present disclosure provides a transmission device, including: a transmitting unit, transmitting a trigger frame for allocating resources for uplink multi-user (UL MU) transmission, the trigger frame including a common information field, the common information field including a type subfield indicating one of a plurality of trigger types, the plurality of trigger types including a first trigger type indicating a basic trigger for soliciting any type of response frame from a receiver terminal station, and a second trigger type indicating a specific trigger for soliciting a specific type of UL MU response frame from a plurality of terminal stations; and a receiving unit, receiving a specific type of UL MU response frame from a plurality of terminal stations when the type subfield indicates the second trigger type.

[0013] According to one aspect of the present invention, a transmitting device includes: a transmitter, which transmits a trigger frame for allocating resources for uplink multi-user UL MU transmission, the trigger frame including a common information field, the common information field including a type subfield indicating one of a plurality of trigger types, wherein the plurality of trigger types include a first trigger type; and a receiver, which receives data of the UL MU transmission, wherein, in response to the type subfield indicating the first trigger type, the trigger frame includes a first dependent type field, the first dependent type field including information indicating a traffic identifier TID of the data to be used for the UL MU transmission.

[0014] According to another aspect of the present invention, a transmission method includes: sending a trigger frame for allocating resources for uplink multi-user ULMU transmission, the trigger frame including a common information field, the common information field including a type subfield indicating one of a plurality of trigger types, wherein the plurality of trigger types include a first trigger type; and receiving data of the UL MU transmission, wherein, in response to the type subfield indicating the first trigger type, the trigger frame includes a first dependent type field, the first dependent type field including information indicating a traffic identifier TID of the data to be used for the UL MU transmission.

[0015] According to another aspect of the present invention, a receiving device includes: a receiver receiving a trigger frame for allocating resources for uplink multi-user UL MU transmission, the trigger frame including a common information field, the common information field including a type subfield indicating one of a plurality of trigger types, wherein the plurality of trigger types include a first trigger type; and a transmitter transmitting data of the UL MU transmission, wherein, in response to the type subfield indicating the first trigger type, the trigger frame includes a first dependent type field, the first dependent type field including information indicating a traffic identifier TID of the data to be used for the UL MU transmission.

[0016] These general and specific aspects may be implemented using devices, systems, methods and computer programs, and any combination of devices, systems, methods and computer programs.

[0017] The methods described in this disclosure enable multi-user management frame exchanges in an efficient manner.

[0018] Other benefits and advantages of the disclosed embodiments will become apparent from the description and drawings. Benefits and / or advantages may be obtained individually by various embodiments and features of the description, and it is not necessary to provide all of these embodiments and features in order to obtain one or more such benefits and / or advantages. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 is a diagram of a specific embodiment of a system utilizing multi-user management frame switching.

[0020] Figure 2 is a diagram of an example frame exchange sequence involving the setup and teardown of a Block Ack mechanism.

[0021] Figure 3 is a diagram of an example frame exchange sequence for Block Ack setup between an AP and multiple STAs.

[0022] Figure 4A The diagram illustrates an element structure for carrying the TF timeout field as used in the first embodiment.

[0023] Figure 4B A table showing the meaning of the TF Timeout field in the first embodiment is illustrated.

[0024] Figure 5 is a diagram of an example multi-user management frame exchange initiated by an AP in accordance with the present disclosure.

[0025] Figure 6 is a diagram of another example multi-user management frame exchange initiated by an AP according to the present disclosure.

[0026] Figure 7 is a diagram of another example multi-user management frame exchange initiated by a STA according to the present disclosure.

[0027] Figure 8 is a diagram of yet another example multi-user management frame exchange initiated by a STA according to the present disclosure.

[0028] Fig. 9A The structure of the trigger frame according to the first embodiment is illustrated.

[0029] Fig. 9B The structure of the common information field according to the first embodiment is illustrated.

[0030] Fig. 9C The structure of the type-dependent common information field according to the first embodiment is illustrated.

[0031] Fig.9D A table showing a description of several frame types according to a first embodiment is illustrated.

[0032] Fig.9E The structure of the subtype specific subfield according to the first embodiment is illustrated.

[0033] Fig.9F A table showing a description of an action category subfield according to the first embodiment is illustrated.

[0034] Figure 9G A table showing description of subfields of the action field according to the first embodiment is illustrated.

[0035] Fig. 10A The structure of the HE variant aggregation control (A-Control) subfield for carrying the TF timeout field used in the second embodiment is illustrated.

[0036] Fig. 10B The format of the control subfield according to the second embodiment is illustrated.

[0037] Fig. 10C A table showing description of a Control ID subfield value according to the second embodiment is illustrated.

[0038] Fig.11A A table showing descriptions of various trigger types according to the second embodiment is illustrated.

[0039] Fig. 11B The format of the preferred response type subfield according to the second embodiment is illustrated.

[0040] Fig. 11C A table showing description of frame subtypes according to the second embodiment is illustrated.

[0041] Fig.11D A table showing descriptions of various action field values ​​according to the second embodiment is illustrated.

[0042] Fig.11E The format of the user information field according to the second embodiment is illustrated.

[0043] Fig. 12A The format of the ADDBA extension element field according to the third embodiment is illustrated.

[0044] Fig. 12B The format of the ADDBA capability field according to the third embodiment is illustrated.

[0045] Fig. 12C A table showing descriptions of various TF timeout values ​​according to the third embodiment is illustrated.

[0046] Fig.13A The structure of the preferred response type subfield according to the third embodiment is illustrated.

[0047] Fig. 13B A table showing descriptions of various frame type values ​​according to the third embodiment is illustrated.

[0048] Fig.14 is a structure for carrying the UL MU Response Scheduling Control subfield of TF Timeout as used in the fourth embodiment.

[0049] Fig.15is a diagram of an example multi-user management frame exchange initiated by an AP according to a fourth embodiment.

[0050] Fig.16 is a flow diagram of operations performed by an AP to initiate a multi-user management frame exchange in accordance with the present disclosure.

[0051] Fig.17 is a flow chart of operations performed by a STA in order to participate in a multi-user management frame exchange initiated by an AP in accordance with the present disclosure.

[0052] Fig.18 is a block diagram of an example AP.

[0053] Fig.19 is a block diagram of an example STA. DETAILED DESCRIPTION

[0054] The present disclosure may be better understood with the aid of the following drawings and examples. The embodiments described herein are merely exemplary in nature and are used to describe some possible applications and uses of the present disclosure and should not be considered to limit the present disclosure with respect to alternative embodiments not expressly described herein.

[0055] Figure 2 An example sequence 200 of frame exchanges between two 802.11 devices is shown, which involves exchanging management frames for the purpose of negotiating Block Ack parameters. In an infrastructure BSS, one of the 802.11 devices will be an AP and the other will be a STA. The sequence 200 consists of three distinct phases: (a) a Block Ack setup phase 210, (b) one or more data exchange phases 220, and (c) a Block Ack teardown phase 230. Block Ack is a feature introduced in the IEEE 802.11e revision. And allows an 802.11 device to send a burst of frames to another 802.11 device without requiring the receiving unit to immediately send back an Ack frame for each received frame.

[0056] The 802.11 device that initiates a burst transmission is called the initiator, and the receiving 802.11 device is called the receiver. After completing the burst, the initiator can request the receiver to send a Block Ack containing a bitmap of the received frame by sending a Block Ack Request frame. This exchange is done in Figure 2220 in the Block Ack Setup phase. The IEEE 802.11n amendment further enhances this feature by allowing bursts of data to be aggregated in a single Management Protocol Data Unit (MPDU) called an A-MPDU. Although Block Ack is a useful feature, both the initiator and the receiver need to prepare additional resources before this feature can be used. The receiver not only needs to allocate additional buffers to receive bursts of frames, but also needs to maintain a scoreboard to record the reception status of the frames. Similarly, the initiator also needs to maintain a record of the frames sent. This preparation is completed in the Block Ack Setup phase 210. In this phase, the two 802.11 devices can negotiate the buffer size, the traffic identifier (TID) of the frames involved, the duration that the negotiation will be effective, etc. Once the data exchange phase is completed, either party can dismantle the Block Ack protocol in the Dismantling Phase 230.

[0057] As explained earlier, most management frame exchanges occur between two 802.11 devices, typically an AP and a STA. Figure 3 The management frame exchanges involved in the Block Ack Establishment Phase 210 are depicted in more detail in FIG. 3. In this example, the AP is the initiator and the STA is the receiver. Before the AP can use the Block Ack feature, it needs to establish the Block Ack feature for each STA with which it intends to use the Block Ack feature, one STA at a time. Frame exchange sequences 300, 310, and 320 are initiated by the AP to establish the Block Ack feature for STA1, STA2, and STAn, respectively. Each of these involves exchanging ADDBA Block Ack action management frames between the AP and the corresponding STA. For example, in sequence 300, the AP initiates the exchange by contending for the wireless medium; throughout this disclosure, such a contention attempt is represented by symbol 302 in the figure.

[0058] Once the AP wins the contention right, it sends an ADDBA request frame 304 uniquely addressed to STA1. After receiving the ADDBA request frame 304, STA1 sends an Ack frame 306 back to the AP for the duration of the short interframe space (SIFS) after the end of the ADDBA request frame. The transmission of the Ack frame does not require contention for the wireless medium. Once the STA has processed the ADDBA request frame and if it accepts the request, the STA sends back an ADDBA response frame 308 after contention and winning the wireless medium. The AP confirms receipt of the ADDBA frame by sending an Ack frame. If the STA intends to use the block Ack feature, a similar frame exchange is also required in the reverse direction, that is, initiated by the STA. Obviously, if many STAs are involved, this establishment process will take a lot of time.

[0059] Although multi-user transmission is possible using Multi-User Multiple Input Multiple Output (MU-MIMO) in the downlink (DL) and Orthogonal Frequency Division Multiple Access (OFDMA) in both the DL and uplink (UL), there are still issues that prevent efficient multi-user communication when it comes to management frame exchange, especially in the UL direction. These issues can be summarized into the following two problems: 1) Most management frames are sent using the highest Enhanced Distributed Channel Access (EDCA) Access Category (AC) AC_VO. If an AP sends multiple management frames to multiple STAs within a DL multi-user PHY Protocol Data Unit (PPDU), the STA that successfully receives the frame will send the corresponding response management frame back to the AP as soon as the STA is ready. At the same time, in order to solicit multiple response management frames from the STA in a multi-user manner, the AP will try to send a basic variant of a newly defined control frame called a trigger frame.

[0060] The basic trigger frame contains information to be used for UL transmission, such as resource unit (RU) allocation, PPDU length, MCS, etc. Upon receiving the trigger frame, the STA to which the RU is allocated in the trigger frame can send back the corresponding UL frame in the UL multi-user PPDU. This causes the STA's response management frames to compete for the wireless medium between them and within the AP's trigger frame. If the trigger frame cannot obtain access to the medium or its transmission is delayed, then the STA will not be able to use multi-user transmission for its UL frame. 2) The basic variant of the trigger frame does not specify the frame type that the STA can send back in the UL multi-user PPDU. This causes some STAs to send back frames other than response management frames, resulting in a situation where the AP needs to send one or more trigger frames to those STAs. These two factors not only cause inefficiency, but also due to the delay in returning the response frame, some of the request frames may also need to be reissued due to timeout issues.

[0061] Although the technology described in this disclosure can be applied to many wireless communication systems, for the purpose of example, the remainder of the description in this disclosure is described in terms of IEEE 802.11 WLAN systems and their related terminology. This should not be considered as limiting the disclosure to alternative wireless communication systems.

[0062] Reference again Figure 1, the example wireless network 100 may include an AP 190 and many associated STAs. STA2 120 and STA6 160 represent a class of devices that have high processing capabilities and possibly high QoS requirements and relatively low power saving requirements. STA1 110 and STA4 140 represent another class of devices that may also have high processing capabilities and possibly high QoS requirements but are relatively more concerned about power consumption. At the other extreme, STA3 130 and STA5 150 represent another class of devices that may have low processing capabilities and may be very sensitive to power consumption. In IEEE 802.11ax terminology, STA1 110, STA2 120, STA4 140, and STA6 160 may be considered Class A devices, which are high-performance devices, while STA3 130 and STA5 150 may be considered Class B devices, which are low-performance devices.

[0063] The fundamental challenge in any wireless communication is the fact that a wireless transceiver unit can be either transmitting or receiving at any one time. Even if a wireless device contains multiple transceivers, since the transmitted signal is several orders of magnitude stronger than the received signal, and the transceiver unit transmits at a specific frequency, it cannot receive any signal at the same frequency. Therefore, almost all wireless devices operate in half-duplex communication. This fact also leads to the next challenge: the transmitting unit itself cannot detect any collisions that may occur with its transmitted signals.

[0064] In IEEE 802.11, this is overcome by using positive confirmation from the receiver device. If requested by the sending unit, the receiver will send back some kind of confirmation frame (Ack / Block Ack, etc.) to confirm the successful reception of the frame of the sending unit. If the sending unit fails to receive any confirmation for its transmission, it will assume that the transmission has failed and can continue to perform recovery actions, such as resending frames, etc. As for preventive measures, IEEE 802.11 uses channel sensing multiple access with collision avoidance (CSMA / CA) as the main channel access mechanism. Collision avoidance is achieved by using random backoff, and CSMA involves the use of physical and virtual channel sensing (CS) mechanisms. The physical CS mechanism is provided by the PHY layer and involves actual sensing of the wireless medium (either preamble detection or energy detection or both). The virtual CS mechanism is provided by the MAC layer and utilizes a network allocation vector (NAV). NAV maintains a prediction of future traffic on the medium based on the duration information announced in most IEEE 802.11 frames. This duration may be contained in the MAC header and / or may also be obtained from the transmit opportunity (TXOP) duration in the PHY header, if present. When either the physical CS or the virtual CS indicates that the medium is busy, the device is not allowed to send any signals except for some special frames (such as Ack frames or Block Ack frames). Although NAV is useful for protecting a device's transmission from third-party devices within its communication range, NAV is not designed to prevent contention from a STA that is the recipient of the frame that sets the NAV.

[0065] Multi-user transmission was introduced in the IEEE 802.11ac amendment through MU-MIMO technology, but only in the downlink. The AP can send different unicast frames addressed to different STAs using different spatial streams. However, this feature was not introduced in the uplink direction due to the need for additional antennas and other complexities. As explained earlier, multi-user transmission using OFDMA in both the downlink and uplink directions is a key technology adopted by the IEEE 802.11ax task group to achieve throughput improvement goals. In the downlink direction, multi-user transmission is relatively simpler because it is the AP that will send all multi-user frames. The DL multi-user PPDU consists of a wide channel PHY header that carries information about the narrowband channel (called a resource unit or RU) that carries each individual PHY service data unit (PSDU). In theory, up to 37 independent transmissions can be carried to 37 different STAs in a multi-user PPDU within a 20MHz channel.

[0066] Transmissions in the uplink direction are more complex because time synchronization between transmissions from multiple STAs is required, and it must also be ensured that transmissions from different STAs do not interfere with each other, i.e., each STA must be assigned a unique RU. This is implemented in IEEE 802.11ax through a special control frame called a trigger frame, which is sent by the AP. The trigger frame contains information for UL transmissions, such as resource unit (RU) allocation, PPDU length, MCS, etc. Upon receiving the trigger frame, the STA assigned the RU in the trigger frame can send the corresponding UL frame in the UL multi-user PPDU after SIFS from the end of the trigger frame without contending for the wireless medium. In addition to the basic trigger frame that can be used to solicit any type of frame, various variants of the trigger frame are defined to solicit specific types of frames. For example, the MU-RTS variant is used to solicit CTS frames from multiple STAs, while the MU-BAR is used to solicit block Ack frames from multiple STAs, etc.

[0067] Based on the above knowledge, the inventors of the present application have arrived at the present disclosure. A method is disclosed that enables efficient and timely exchange of multi-user management frame exchanges. According to one aspect of the present disclosure, the AP indicates a duration in a DL PPDU carrying one or more frames, during which the recipient STA addressed in the frame contained in the DL PPDU is not allowed to send any frames other than an immediate acknowledgment of the previous DL PPDU until the STA receives another frame that explicitly grants the STA permission to send again. This can be viewed as the transmitting unit protecting its future transmissions from one or more STAs that are recipients of its earlier transmissions. By using the traditional NAV protection mechanism, protection against third-party STA influence can be ensured. This will allow the AP to send a trigger frame soliciting a UL multi-user PPDU in a timely manner.

[0068] A second aspect of the present disclosure involves customizing the trigger frame to limit the frame types solicited in the UL PPDU to those preferred by the AP. In the case of multi-user management frame exchange, this involves using a specific trigger frame type in the trigger frame or using a new variant of the basic trigger frame to indicate the exact management frame type and subtype, and other details that will enable the addressed STA to unambiguously identify the exact management frame type preferred by the AP to be included in the UL PPDU.

[0069] Various exemplary embodiments for the multi-user management frame exchange proposed in the present disclosure are described in detail in the following sections.

[0070] <First Embodiment>

[0071] As mentioned earlier, when the exchange is initiated by the AP by sending a DL multi-user PPDU containing a management request frame addressed to multiple STAs, one of the challenges of the multi-user management frame exchange is that the corresponding single-user management response / report frames from the corresponding STAs will compete with the AP's trigger frame for the medium and cause a delay in the transmission of the trigger frame. This will cause a disruption in the multi-user management frame exchange because it is not allowed to send a UL multi-user PPDU carrying multiple management response frames without receiving a trigger frame from the AP.

[0072] The AP may try to protect subsequent response frames from the STA by including a longer TXOP duration in the DL PPDU that initiates the frame exchange, thereby setting the NAV of the third-party STA. Alternatively, the AP may also use a protection mechanism such as exchanging multi-user RTS (MU-RTS) and CTS frames before the management frame exchange. However, this does not solve the problem of delayed trigger frames due to contention from the STA that is the recipient of the DL PPDU, because the NAV setting rules do not apply to the STA. The AP may try to avoid the above-mentioned contention from the STA that is the recipient of the DL PPDU by sending a trigger frame after a short interframe space (SIFS) from the end of the UL PPDU carrying the STA's Ack frame for the DL PPDU, thereby preventing the STA's single-user management response / report frame from competing for the medium. However, this approach may not always work because the STA may not be able to prepare a management response / report frame within this duration. This may be due to several factors, such as: the processing performance of the STA, or the nature of the management frame being exchanged, or the STA is busy with other processing when receiving the management request frame, etc. This will result in the RU of the ULPPDU being unused, which not only uses the medium inefficiently, but in extreme cases, may also cause a third-party STA to sense the medium as idle and transmit, causing a collision at the AP.

[0073] To address this issue, a new protection mechanism is introduced in the present disclosure. This involves the AP including a duration representing a trigger frame timeout, referred to herein as a TF timeout, in a downlink unicast frame. Including a TF timeout in a frame indicates that the AP intends to send a trigger frame as the next downlink frame within the timeout duration, which allocates an RU to the recipient STA to send an uplink frame. The TF timeout can be carried as a separate field in a new element defined for the explicit purpose of carrying the TF timeout, or it can also be carried in an existing element.

[0074] Figure 4AThe construction of an element 400 carrying a TF timeout duration according to a first embodiment is illustrated. The element 400 includes an element ID 410, a length field 420, and a TF timeout field 430. The element ID 410 uniquely identifies the element, is eight bits long and is defined by the IEEE 802.11 specification. The length field 420 is also eight bits long and specifies the number of eight bits following the length field. In this example, the length field indicates one eight bit.

[0075] The TF timeout field 430 is also eight bits long and is encoded as follows: Figure 4B As shown in Table 450 in . If TF Timeout is set to 0, it indicates that no timeout is set, or if TF Timeout was previously set to a non-zero value, then TF Timeout will be reset. If set to a non-zero value, TF Timeout indicates the timeout duration in time units (TU, 1TU = 1024 μs).

[0076] Figure 5 An example multi-user management frame exchange 500 made possible by the present disclosure is illustrated. The frame exchange sequence in this example is Figure 3 The multi-user version of the Block Ack setup process mentioned in and involves the exchange of ADDBA request frames from the AP (initiator) and ADDBA response frames from the STAs (receivers). The frame exchange is initiated by the AP through the contention medium and wins the contention, sending an OFDMA DL multi-user PPDU 502, which carries one or more unicast ADDBA request frames 504, 506, ..., 508 addressed to STA1, STA2, ..., STAn. The phrases "X, ..., Y" here and in the subsequent text represent objects numbered in ascending order from X to Y. The letter "n" in STAn represents a number greater than 2 and less than the maximum number of STAs that can be addressed in a multi-user PPDU.

[0077] According to the first embodiment, each of the ADDBA request frames 504, 506, ..., 508 also carries the element 400 including the TF timeout field 430. The TF timeout field 430 indicates a duration visualized by 518 during which the STAs STA1, STA2, ..., STAn with addresses matching the receiving unit address fields of the corresponding ADDBA request frames 504, 506, ..., 508 are not allowed to send any frames other than the immediate acknowledgement of the previous DL PPDU frame until the STAs receive a trigger frame 510 that allocates RUs to the STAs to send their corresponding UL frames. To decide on an appropriate value for the TF timeout duration, the AP may consider several factors, such as the type of management frames being exchanged or the processing performance of the STAs. For example, the AP may set a longer TF timeout duration for the exchange of ADDTS management frames because the ADDTS frame involves many parameters and the STAs may need a longer time to prepare the ADDTS frame. Similarly, if all STAs involved in the exchange are higher performance Class A devices, then the AP may set a shorter TF timeout duration, whereas if the STAs are lower performance Class B devices, then the AP may set a longer TF timeout duration.

[0078] The selection of the TF timeout duration by the AP can also be based on the AP's knowledge of the previous block Ack establishment attempt with the STA. For example, if the previous block Ack establishment attempt with the STA fails because the STA cannot send the ADDBA response frame on time, the AP can select a longer TF timeout duration for the STA in the subsequent block Ack establishment attempt. The TF timeout duration of the STA group participating in the same frame exchange should be set to the same value. The TF timeout duration calculation can be completed by a dedicated module 1854 in the MAC layer of the AP, or it can be implemented as a software function within the MAC. The STA receiving the TF timeout duration can implement a separate timer (TF timeout timer 1954) within the MAC layer to count down this duration, and can set the TX limit flag 1958, which limits any transmission when the timer value is non-zero. When a valid trigger frame is received from the AP, the RU is assigned to the STA to send its UL frame, the TF timeout timer 1954 will be reset to zero and the TX limit flag 1958 will be cleared.

[0079] After the AP has received the Ack frame for the ADDBA request frame, it will send a trigger frame 510 to the STA to solicit an ADDBA response frame from the STA that sent back the Ack frame. In addition to the other information mentioned above, the trigger frame 510 will include information for limiting the frame type that the STA can send in the immediately following UL PPDU to an ADDBA response frame. In the example sequence 500, the trigger frame 510 allocates RUs 512, 514, ..., 516 to STA1, STA2, ..., STAn, respectively. The trigger frame can be sent as a broadcast trigger frame in a single-user PPDU format, or it can be sent as multiple unicast trigger frames in a multi-user PPDU format.

[0080] If the AP is confident that the STA will be able to prepare the ADDBA response frame in time, the AP can contend for the medium and attempt to send a trigger frame 510 immediately after receiving the Ack frame from the STA. Alternatively, it may choose to attempt the transmission slightly later in order to provide the STA with more time to prepare the ADDBA response frame, but this involves the risk that other third-party STAs may preempt the transmission of the trigger frame. This risk can be minimized by using protection mechanisms such as the exchange of multi-user RTS (MU-RTS) and CTS frames before the management frame exchange. How the AP selects the TXOP duration or initial downlink MU PPDU to be used in the MU-RTS / CTS exchange to protect the multi-user management frame exchange may also depend on the TF timeout duration. Ideally, in order to protect the management frame exchange from being affected by a third-party STA, a TXOP duration covering the entire management frame exchange is preferred, but this may be undesirable when the TF timeout duration is relatively long because such protection may be considered unfair to third-party stations.

[0081] A more reasonable approach may be for the AP to set the TXOP duration just long enough to protect the trigger frame 510 soliciting a response management frame, and for the trigger frame 510 to initiate the next TXOP with a TXOP duration long enough to protect subsequent frame exchanges. An even more conservative approach may be to set the TXOP duration only until the Ack frame acknowledges the downlink MU PPDU 502, in which case there will be no protection for third-party STAs. How the AP or STAs participating in the management frame exchange contend for the medium to send a trigger frame or a single-user response management frame may also depend on the length of the TXOP duration. Within the TXOP duration, contention may only involve sensing the medium for a fixed duration (e.g., PIFS) without performing random backoffs, while outside the TXOP duration, medium contention also involves random backoffs.

[0082] Upon receiving the trigger frame 510, each of the STAs STA1, STA2, ..., STAn will send a UL multi-user PPDU 520, a PHY header occupying the entire full band, and a corresponding ADDBA response frame 522, 524, ..., 526 occupying a narrow band on the corresponding allocated RU 512, 514, ..., 516. Upon receiving the UL multi-user PPDU 520, the AP completes the frame exchange by sending an acknowledgment frame 530 as a DL multi-user PPDU carrying individual Ack frames 532, 543, ..., 536 on separate RUs.

[0083] Figure 6 Frame exchange sequence 600 is illustrated, which is very similar to frame exchange sequence 500, but gives an example of a situation where one or more STAs cannot prepare a solicited management frame (i.e., an ADDBA response frame in this example) in a timely manner. Here, STA1 cannot send back an ADDBA response frame, and the RU allocated to STA1 is empty, as depicted by 612. In this case, the AP will use the knowledge that STA1 has previously acknowledged the ADDBA request frame to make an educated assumption that STA1 will attempt to send an ADDBA response frame at a later point in time.

[0084] To avoid inefficiencies in EDCA channel access, the AP may send another trigger frame 622 to STA1 in the same DL multi-user PPDU carrying Ack frames 624, ..., 626 to STA2, ..., STAn, with each Ack frame occupying one RU. Since the trigger frame 622 is longer than the Ack frame, the AP may allocate a larger RU to the trigger frame than the RU carrying the Ack frame to minimize padding. In addition, since the trigger frame 622 allocates RUs for only one STA (i.e., STA1), the AP will most likely allocate the maximum RU in that band, 242-tone RUs for a 20 MHz operating band. This would be considered a special use of the trigger frame because the solicited uplink PPDU carries a PSDU from a single user, rather than the more common case of multiple PSDUs from multiple users.

[0085] For management frame exchanges other than ADDBA frame exchanges, if the AP and STA have performed a block Ack setup, the AP can also use a single multi-STA block Ack variant frame to confirm the ADDBA request frames from STA2, ..., STAn, instead of separate Ack frames 624, ..., 626. This will also help balance the RU size between the trigger frame 622 and the Ack frame. After the SIFS duration after the end of the trigger frame 620, STA1 sends the ADDBA response frame 630 back to the AP on the RU allocated to it by the trigger frame 622. Finally, the AP ends the frame exchange by sending an Ack frame 640. Although only STA1 failed to send the ADDBA response frame in the first round in this example, many other scenarios in which other STAs also fail to send corresponding ADDBA response frames or STAs fail to send ADDBA response frames even after the second or subsequent trigger frames are also possible. It will be obvious to those skilled in the art that the recovery action described here (i.e., sending another trigger frame in the same PPDU as the Ack frame) will also be used to recover the frame exchange sequence in this case. The AP may repeat this process until the number of STAs that fail to send an ADDBA response frame falls below a preset value, or the recovery attempt has exceeded a preset timeout duration determined by the AP for the multi-user frame exchange sequence.

[0086] Figure 7 Another example multi-user management frame exchange sequence 700 is illustrated for establishing a block Ack mechanism between STA1, STA2, ..., STAn (initiators) and the AP (receiver) associated with the STA. In the case of a single user, the STA will initiate an ADDBA frame exchange by sending an ADDBA request to the AP. It is always possible for the AP to wait for many such requests from multiple STAs and consolidate the ADDBA response frames in the DL multi-user PPDU. However, a more efficient approach would be to synchronize the ADDBA requests from the STAs.

[0087] It is assumed that the AP will have enough information about the STA that is most likely to request a Block Ack setup. The AP can gather this information in advance by passively collecting unsolicited buffer status reports from the STA, or the AP can also actively poll the STA to obtain its buffer status report using a buffer status report polling (BSRP) variant trigger frame. STAs that indicate that the buffer unit load is above a certain threshold can be considered candidates for multi-user Block Ack setup. The AP can also use information about existing service flows (TS) that the STA can establish with the AP to decide on candidate STAs for multi-user Block Ack setup. The AP initiates a frame exchange sequence by sending a trigger frame 710 that solicits ADDBA request frames from candidate STAs STA1, STA2, ..., STAn.

[0088] Upon receiving the trigger frame 710, each addressed STA prepares corresponding ADDBA request frames 722, 724, ..., 726 and sends them in the corresponding allocated RUs in the UL multi-user PPDU 720. The AP acknowledges the reception of the UL multi-user PPDU 720 by sending a DL multi-user PPDU 730 carrying a corresponding Ack frame. Once the AP finishes preparing all ADDBA response frames, it contends for the medium and sends a DL multi-user PPDU 740 carrying an ADDBA response frame to the STA when it wins the contention. Finally, the STA ends the frame exchange sequence by sending a UL multi-user PPDU carrying a corresponding Ack frame.

[0089] Figure 8 Another management frame exchange sequence 800 is illustrated, which is very similar to the frame exchange sequence 700. The AP initiates the frame exchange sequence by sending a trigger frame 810 that solicits ADDBA request frames from candidate STAs STA1, STA2, ..., STAn. Upon receiving the trigger frame, each addressed STA prepares a corresponding ADDBA request frame and sends them in the corresponding allocated RU in the UL multi-user PPDU 820. In this example, the AP is fast enough to prepare an ADDBA response frame within the SIFS duration of receiving the ADDBA request frame. In order to avoid the inefficiency of EDCA contention, for each STA, the AP aggregates the Ack frame into the ADDBA request frame and the corresponding ADDBA response frame, and sends them in the DL multi-user PPDU 830 SIFS after the end of the UL PPDU 820. Finally, the frame exchange sequence is ended by the STA by sending a UL multi-user PPDU carrying the corresponding Ack frame. In this example, it is assumed that the AP sets the TXOP duration in the trigger frame 810 to be long enough to complete the entire frame exchange sequence 800.

[0090] Fig. 9A The structure of a trigger frame is illustrated, which can be customized to solicit a specific type of frame according to the present disclosure. The frame structure 900 has been proposed in IEEE802.11x as a special control frame called a trigger frame for soliciting and allocating resources for UL multi-user transmission. In addition to common MAC frame fields such as frame control 902, duration 904, receiving unit address (RA) 906, transmitting unit address (TA) 908, and frame check sequence (FCS) 918, the trigger frame also contains the following fields:

[0091] - Common information field 910, used to indicate information common to all STAs assigned RUs by the trigger frame,

[0092] - One or more user information fields 912, ..., 914, used to indicate information specific to a particular user. A broadcast trigger frame carries multiple user information fields, while a unicast trigger frame carries only a single user information field.

[0093] Optionally, the trigger frame may also include a padding field 916 to extend the trigger frame and provide more time for the STA to prepare for the UL multi-user PPDU.

[0094] Fig. 9B The structure of the common information field 910 is illustrated and contains the following subfields:

[0095] -Trigger Type subfield 922, indicating the type of trigger frame. In the first embodiment, the Trigger Type subfield is set to a value of 0 (zero) and indicates a basic trigger frame,

[0096] -Length subfield 924, indicating the length of the solicited UL PPDU.

[0097] - Cascade Information subfield 926, if it is 1, it indicates that the subsequent trigger frame will follow the current trigger frame,

[0098] - Required CS field 928, indicating whether the STA needs to perform physical and virtual carrier sensing before sending a response frame,

[0099] -BW field 930, indicating the channel bandwidth,

[0100] - Subfields CP and LTF type 932, MU MIMO LTF mode 934, number of LTFs 936, STBC 938, LDPC extra symbols 940, AP TX power 942, and packet extension 944 indicate the information necessary for the PHY layer to prepare and send the UL PPDU,

[0101] - Spatial Reuse subfield 946, indicating information on the spatial reuse of the medium,

[0102] - HE-SIGA Reserved subfield 948, indicating how the reserved bit in the SIGA of the UL PPDU should be set,

[0103] - A type-dependent common information subfield 950 indicates information specific to a particular trigger frame type. The current basic trigger frame proposed in IEEE 802.11ax does not contain a type-dependent common information subfield.

[0104] Fig. 9CThe structure of the type-dependent common information field 950 proposed in the first embodiment is illustrated to limit the frame type that the STA indicated in the user information field can include in the UL PPDU after the trigger frame. The basic trigger frame currently does not impose any restrictions on the response frame type that can be included in the UL PPDU. According to the first embodiment, two eight-bit preferred response type subfields 952 are included in the type-dependent common information field 950, and contain the following subfields:

[0105] - A one-bit long Frame Type subfield 954 indicates the frame type solicited in the UL PPDU. A value of 0 indicates a data frame, while a value of 1 indicates a management frame.

[0106] - A four-bit TID / Frame Subtype subfield 956, which indicates the TID of a data frame if the Frame Type subfield 954 indicates a data frame, or a management frame subtype if the Frame Type subfield 954 indicates a management frame. The same frame subtype encoding as the Subtype subfield defined for the Frame Control field in the IEEE 802.11 specification may be used, e.g., 0 for an association request frame, 13 for an action frame, etc.

[0107] - An eight-bit long Subtype Specific subfield 958, which is reserved if the Frame Type subfield 954 indicates a data frame, and indicates further details about the frame type if the Frame Type subfield 954 indicates a management frame. The encoding of the Subtype Specific subfield 958 may be different for different management frames. For example, if the Frame Subtype subfield 956 indicates 13 (i.e., a management action frame), then the Subtype Specific subfield 958 is further divided into a five-bit long Action Category subfield 972 and a three-bit long Action Field subfield 974. The encoding of the Action Category subfield 972 is as follows: Fig.9F 980 in IEEE 802.11, and values ​​0 to 21 are used to specify the action frame category as defined in the IEEE 802.11 specification; for example, 0 indicates a spectrum management action frame, 3 indicates a block ack action frame, etc. The action field subfield 974 specifies the frame format in the action frame category, and an example when the action category indicates a block ack action frame is as follows: Figure 9G The meanings of values ​​0 to 7 are the same as those defined in the relevant parts of the IEEE 802.11 specification; for example, 0 indicates an ADDBA request, 1 indicates an ADDBA response, and so on.

[0108] exist Fig.9D The encoding of the preferred response types is summarized in Table 960.

[0109] <Second Embodiment>

[0110] According to a second embodiment, the AP indicates a TF timeout using one of the control subfields within the Aggregation Control (A Control) subfield of the HE variant HT Control field.

[0111] Fig. 10A The format of the A control subfield of the HE variant HT control field 1000 as defined in IEEE 802.11ax is illustrated. The A control subfield contains a sequence of one or more control subfields 1010, ..., 1020, followed by an optional padding subfield 1030, which is set to a sequence of zeros so that the length of the A control subfield is equal to thirty bits. Each control subfield consists of a four-bit long control ID subfield and a variable-length control information subfield. The control ID subfield indicates the type of information carried in the control information subfield, while the length of the control information subfield is fixed for each value of the unreserved control ID subfield. Control IDs 0 to 3 have been defined in 802.11ax, and their details are as shown in FIG. Fig. 10C As shown in Table 1060 in . Fig. 10B The format of the control subfield 1050 for carrying the TF timeout according to the second embodiment is illustrated. In addition to the control ID subfield 1052, it also carries an eight-bit long TF timeout subfield 1054. The potential encoding of the subfield is detailed in row 1062 of table 1060. Carrying the TF timeout within the A control subfield in the MAC header of the downlink frame can be an efficient way to signal the TF timeout.

[0112] According to a second embodiment, a new trigger type for soliciting management frames is defined for trigger frames. Fig.11A Table 1100 in Detailed Description of the Various Trigger Types Defined in 802.11ax, wherein row 1102 shows an example encoding of a trigger type for soliciting a management frame, as proposed in the second embodiment. When used to solicit a management frame, the Trigger Type subfield 922 will be set to a value indicating a management frame trigger.

[0113] Fig. 11B The structure of two eight-bit long preferred response type subfields 1100 proposed to be included in the type-dependent common information field 950 is illustrated, and is used to further narrow down the specific management frame preferred by the AP and contains a four-bit long frame subtype subfield 1112 and an eight-bit long subtype specific subfield 1114, with the remaining four bits being reserved. The frame subtype subfield 1112 indicates the management frame subtype being solicited, and may use the same frame subtype encoding as the subtype subfield defined for the frame control field in the IEEE 802.11 specification. The encoding of the subtype specific subfield 1114 may be different for different management frames, and may be different for different management frames. Fig.9E. , an example encoding is shown when the frame subtype subfield 1112 indicates a management action frame.

[0114] Fig.11D Table 1140 in shows an example encoding of the Action Field subfield 974 when the Action Category is QoS Action Frame Indication 1. The meanings of values ​​0 to 6 are the same as defined in the relevant parts of the IEEE 802.11 specification; for example, 1 indicates an ADDTS response, 4 indicates a QoS mapping configuration, etc.

[0115] Fig.11E The structure 1150 of one of the user information fields 912, ..., 914 is illustrated and includes the following subfields:

[0116] - AID 12 subfield 1152, carries the AID of the STA to which the user information field is directed,

[0117] - RU allocation subfield 1154, indicating the RU allocated to the STA identified by the user identifier subfield 1152,

[0118] - Coding Type subfield 1156, indicating the code type of the uplink PPDU sent as a response by the STA identified by the User Identifier subfield 1152,

[0119] -MCS subfield 1158, indicating the MCS of the uplink PPDU sent in response by the STA identified by the user identifier subfield 1152,

[0120] -DCM subfield 1160, indicating whether the uplink PPDU sent in response by the STA identified by the User Identifier subfield 1152 will use Dual Carrier Modulation (DCM),

[0121] - SS Allocation subfield 1162, indicating the spatial stream of the uplink PPDU sent in response by the STA identified by the User Identifier subfield 1152,

[0122] - Target RSSI subfield 1164, indicating the expected RSSI of the AP for the uplink PPDU sent in response by the STA identified by the User Identifier subfield 1152,

[0123] - a one-bit reserved field 1165,

[0124] - A type-dependent user information subfield 1166 indicating information specific to the STA identified by the user identifier subfield 1152. According to the second embodiment, when the trigger type subfield 922 is set to a value indicating a management frame trigger, the type-dependent user information subfield 1166 carries additional user-specific information related to the management frame exchange. As an example, when used during the exchange of an ADDTS QoS action frame, it may include a traffic stream ID (TSID) value, or when used during the exchange of a block Ack action frame, it may include a TID value; different user information fields may carry different values.

[0125] <Third Embodiment>

[0126] According to the third embodiment, another method of carrying TF timeout is proposed: Instead of defining a new element, the AP can use an existing element already carried by a management frame to carry TF timeout.

[0127] exist Fig. 12A An example in the case of a Block Ack action frame is illustrated in FIG. 12. The TF timeout is carried in the ADDBA extension element 1200. The element ID 1202 is set as specified in the 802.11 specification; the length field 1204 indicates one eight bit, and the ADDBA capability field 1206 is as specified in the 802.11 specification. Fig. 12B In addition to the existing no-segmentation subfield 1212, the remaining seven bits are currently reserved. According to the third embodiment, some of the reserved bits (e.g., six bits) are used to indicate a TF timeout 1224, while the remaining one bit is reserved. The encoding of the TF timeout is as follows: Fig. 12C As detailed in Table 1230 in: A value of zero indicates that the TF timeout is not set or it is used to reset a previously set TF timeout, while values ​​1 to 63 indicate timeout values ​​of 1 to 63 TUs, respectively. Compared with the first embodiment, the range of TF timeout that can be set by the method proposed in the second embodiment can be shorter, depending on how many bits in the existing elements are available for indicating the TF timeout, but even with a shorter range, the goal of protecting AP transmission can be achieved because in actual implementation, the TF timeout duration will not be very large.

[0128] According to the third embodiment, another variation of the trigger frame is proposed, which is a variation of the trigger frame proposed in the first embodiment. Fig.13A The structure of two eight-bit preferred response type subfields 1300 proposed to be included in the type-dependent common information field 950 according to the third embodiment is illustrated. The preferred response type subfield 1300 contains a two-bit frame type subfield 1310, a four-bit TID / frame subtype subfield 1320, and an eight-bit subtype specific subfield 1330, while the remaining two bits are reserved.

[0129] Although the remaining subfields are the same as those defined in the first embodiment, the encoding of the frame type subfield 1310 is as follows: Fig. 13B 11 specification, and matches the definition of the Type subfield defined for the Frame Control field in the 802.11 specification. If the Frame Type subfield 1310 indicates a data frame, then the TID / Frame Subtype subfield 1320 indicates the TID of the data frame, and if the Frame Type subfield 1310 indicates a management frame, then the TID / Frame Subtype subfield 1320 indicates a management frame subtype, and if the Frame Type subfield 1310 indicates a control frame, then the TID / Frame Subtype subfield 1320 indicates a control frame subtype. If the Frame Type subfield 1310 indicates a management frame, then the Subtype Specific subfield 1330 indicates further details about the frame type, otherwise it is reserved for data and control frames. The encoding of the Subtype Specific subfield 1330 may be different for different management frames, and may be used in different embodiments. Fig.9E . , an example encoding is shown in FIG. 13 when the frame subtype subfield 1320 indicates a management action frame.

[0130] <Fourth Embodiment>

[0131] According to the fourth embodiment, the AP includes one or more flags, called TF flags, in the DL multi-user PPDU that initiates the exchange of multi-user management frames to indicate to the recipient STA that the AP intends to send a trigger frame for allocating RUs to the STA as the next frame after the DL multi-user PPDU. The TF flag may be carried in one of the control subfields of the A control subfield of the HE variant HT control field 1000.

[0132] Fig.14 The structure of the control subfield 1450 is illustrated when the control ID subfield is 0, in which case the control information subfield carries scheduling information for a UL multi-user PPDU that carries an immediate acknowledgement of the frame containing the control subfield. The control subfield 1450 contains the following subfields:

[0133] -UL PPDU length subfield 1452 indicates the length of the uplink response PPDU.

[0134] -RU Allocation subfield 1454 indicates the RU assigned for sending the uplink response PPDU.

[0135] -DL TX Power subfield 1456, indicating the transmit power of the AP.

[0136] -UL target RSSI subfield 1458, indicating the target received power of the AP.

[0137] -UL MCS subfield 1460, indicating the MCS to be used for the uplink response PPDU.

[0138] - The TF flag 1462 proposed in the fourth embodiment indicates the AP's intention to send a trigger frame allocating an RU to send a subsequent uplink response PPDU to the STA as the next frame after the frame containing the control subfield 1450.

[0139] When the TF flag 1462 is set to 1, it indicates a transmission restriction, and the STA that is the recipient of the frame carrying the TF flag 1462 is restricted from sending anything other than an immediate confirmation frame on the medium until it receives a trigger frame allocating RUs from the AP or until the TXOP duration indicated by the frame carrying the TF flag 1462 expires. In other words, according to the fourth embodiment, the TXOP duration indicated by the frame carrying the TF flag 1462 acts as an implicit TF timeout proposed in other embodiments. If the STA fails to receive the trigger frame, the STA can resume normal transmission once the TXOP expires.

[0140] Fig.15 The frame exchange sequence 1500 in the figure illustrates an example of a multi-user management frame exchange according to the fourth embodiment. Take the management frame exchange established by the block Ack as an example. The downlink multi-user PPDU 1510 carries multiple unicast ADDBA request frames 1512, ..., 1516 addressed to STA STA1, ..., STAn. Each ADDBA request frame also carries a control subfield 1450 that allocates the RU for the Ack frame to the ADDBA request frame, where the TF flag 1462 is set to 1. The PPDU 1510 also sets the TXOP duration 1520 to be long enough to cover the time when the AP expects to send a trigger frame 1530, where the trigger frame 1530 solicits an ADDBA response frame from the STA. The TXOP duration 1520 is used to protect the trigger frame 1520 from the influence of a third-party STA. Since the TF flag 1462 is set to 1, the STA is restricted from sending the corresponding single-user ADDBA response frame until the trigger frame 1530 is received.

[0141] Another alternative to carrying the TF flag is to use a bit in the PHY header of the DL multi-user PPDU to initiate the multi-user management frame exchange, such as a bit in the common block field of the HE SIG-B. If this bit is set, the transmission restriction applies to all STAs that are assigned a non-broadcast RU in the SIG-B user field.

[0142] <Radio Communication System>

[0143] Fig.16An example method 1600 implemented by an AP is illustrated to facilitate a multi-user management frame exchange initiated by the AP. The example of a frame exchange case initiated by a STA is also similar and is not described again. At 1610, based on information from an upper layer application, or based on existing data frames in the AP's buffer unit, etc., the AP selects a group of STAs with which the AP intends to initiate a management frame exchange. The AP may also consider other factors, such as the performance of the STAs during the selection of the group, for example, grouping high-performance Class A STAs into one group and grouping lower-performance Class B STAs into another group.

[0144] At 1620, based on similar information, the AP also decides the value to be used for the TF timeout, or if the TF flag method is used, the appropriate TXOP duration to be used. At 1630, the AP constructs a multi-user PPDU to carry a unicast management frame and includes a TF timeout or TF flag. At 1640, after contending for the medium, the AP sends the multi-user PPDU. At 1650, the AP constructs a trigger frame that allocates RUs to the STA to send back the corresponding response management frame, and after waiting for the appropriate amount of time, the AP sends the trigger frame. At 1660, upon receiving the response management frame from the STA, the AP sends a multi-user PPDU carrying the corresponding Ack frame. If any of the STAs fails to send back a response management frame, the AP also includes a broadcast or single / multiple unicast trigger frame in the multi-user PPDU that allocates RUs to each such STA. This step can be repeated as needed until the TXOP duration expires or the AP receives a response management frame from all involved STAs.

[0145] Fig.17 An example method 1700 implemented by a STA is illustrated to participate in a multi-user management frame exchange initiated by an AP. The example of a frame exchange case initiated by a STA is also similar and is not described again. At 1710, the STA receives a multi-user PPDU sent by the AP and extracts a management frame addressed to the STA based on relevant information from the PHY header. At 1720, in addition to processing the received management frame, the STA also extracts either the TF timeout field or the TF flag and starts a timer initialized to the TF timeout duration, or if the TF flag method is used, then starts a timer initialized to the remaining TXOP duration. Although the timer is not zero, the STA avoids sending any frames other than an immediate acknowledgment of the received management frame.

[0146] At 1730, if the STA accepts the request from the AP and waits for the trigger frame, the STA prepares a response management frame. At 1740, upon receiving the trigger frame from the AP, the timer is reset, and the STA sends the prepared response management frame on the RU allocated to the STA through the trigger frame. On the other hand, if the timer expires before the STA receives the trigger frame from the AP, the transmission restriction is removed and the STA can freely contend and send the response management frame in the single-user PPDU format.

[0147] <Access Point Configuration>

[0148] Fig.18 is a block diagram of an example AP 1800, which may be Figure 1 1800. The AP 1800 includes a central processing unit (CPU) 1830 coupled to a memory 1820, an auxiliary storage device 1840, one or more wireless communication interfaces 1850, and other wired communication interfaces 1880. The auxiliary storage device 1840 may be a non-volatile computer-readable storage medium for permanently storing relevant instruction codes, data, etc. At startup, the CPU 1830 may copy the instruction codes and relevant data to the volatile memory 1820 for execution. The instruction codes may be an operating system, user applications, device drivers, execution codes, etc. required for the operation of the AP 1800. The size of the instruction codes and therefore the storage capacity of the auxiliary storage device 1840 and the memory 1820 may be much larger than the storage capacity of the STA 1700.

[0149] STA 1800 may also include a power supply 1810, which may be mains power in most cases, but may also be some kind of high-capacity battery, such as a car battery, in some cases. Wired communication interface 1880 may be an Ethernet interface or a power line interface or a telephone line interface, etc. Wireless communication interface 1850 may include an interface for cellular communication, or an interface for a short-range communication protocol such as Zigbee, or it may be a WLAN interface.

[0150] The wireless interface 1850 may also include a MAC module 1852 and a PHY module 1860. The MAC module 1852 of the AP may be substantially more complex than the MAC module of the STA 1900 and may include many sub-modules. The MAC module 1852 may include a TF timeout calculation unit 1854 responsible for performing step 1620 of method 1600 and other sub-modules. The MAC module 1852 may also store a table 1856 encoding for representing the preferred response type in the trigger frame. The PHY module is responsible for converting MAC module data into a transmission signal / converting MAC module data from a received signal. The wireless interface may also be coupled to one or more antennas 1870 via the PHY module, and the antennas 1870 are responsible for the actual transmission of wireless communication signals on the wireless medium / the actual reception from the wireless medium.

[0151] In a particular embodiment, the operating system includes a real-time operating system (RTOS), the user application includes a web browser or a smart phone application, the device driver includes a WLAN driver, and the execution code may include code that causes method 1600 to be executed when executed by the CPU 1830. Depending on the implementation, the preferred response type encoding table 1856 may represent the preferred response type encoding 960, or it may represent the preferred response type encoding 1130, or it may represent the preferred response type encoding 1340. The preferred response type encoding table 1856 may be stored with default values during manufacturing, but if necessary, the AP1800 may also adjust (tweak) these values according to pre-allocated network conditions and transmit the new table content to the member STAs, for example, during the association process, or the AP 1800 may also choose to announce the new table content in an information element in some periodic frames such as beacon frames.

[0152] The AP 1800 may include many other components not shown for clarity in Fig.18 for the sake of clarity. Only those components most relevant to the present disclosure are shown.

[0153] <STA Configuration>

[0154] Fig.19 is a block diagram of an exemplary STA 1900, which may be any one of the STAs in Figure 1 The STA 1900 includes a central processing unit (CPU) 1930 coupled to a memory 1920, an auxiliary storage device 1940, and one or more wireless communication interfaces 1950.

[0155] The auxiliary storage device 1940 may be a non-volatile computer-readable storage medium for permanently storing relevant instruction codes, data, etc. At startup, the CPU 1930 may copy the instruction codes and relevant data to the volatile memory 1920 for execution. The instruction codes may be an operating system, user applications, device drivers, execution codes, etc. necessary for the operation of the STA 1900. The STA 1900 may also include a power supply 1910, such as a lithium-ion battery or a button battery. The wireless communication interface 1950 may include an interface for cellular communication, or an interface for a short-range communication protocol such as Zigbee, or it may be a WLAN interface.

[0156] The wireless interface 1950 may also include a MAC module 1952 and a PHY module 1960. Among other submodules, if the TF flag method is used, the MAC module 1952 may include a TF timeout timer 1954 to track the transmission restriction period based on either the TF timeout field or the TXOP duration. The MAC module 1952 may maintain a TX restriction flag 1958 to record the transmission restriction status; when the flag is set, the STA avoids sending frames other than immediate confirmation. The MAC module 1952 may also store a table 1956 of bit encodings for indicating preferred response type encodings. The PHY module is responsible for converting MAC module data into transmission signals / converting received signals into MAC module data. The wireless interface may also be coupled to one or more antennas 1970 via the PHY module, which are responsible for the actual transmission of wireless communication signals on the wireless medium / actual reception from the wireless medium.

[0157] In a particular embodiment, the operating system comprises a real-time operating system (RTOS), the user application comprises a web browser or a smart phone application, the device driver comprises a WLAN driver, and the execution code may comprise code that causes the method 1700 to be performed when executed by the CPU 1930. A TF timeout buffer unit 1954 is used in 1720 to track TF timeouts. Depending on the implementation, the preferred response type encoding table 1956 may represent the preferred response type encoding 960, or it may represent the preferred response type encoding 1130, or it may represent the preferred response type encoding 1340. The preferred response type encoding table 1956 may be stored with default values ​​during manufacturing. It is also possible to update the preferred response type encoding table 1956 based on values ​​transmitted by the AP during cooperative processing, or based on values ​​regularly announced by the AP in periodic frames such as beacon frames.

[0158] STA 1900 may include components not shown in the figure for the sake of clarity. Fig.19 There are many other components shown in FIG. Only those components most relevant to the present disclosure are shown.

[0159] According to one aspect of the present invention, a transmission device includes: a transmitting unit that transmits a trigger frame for allocating resources for uplink multi-user UL MU transmission, the trigger frame including a common information field, the common information field including a type subfield indicating one of a plurality of trigger types, the plurality of trigger types including a first trigger type indicating a basic trigger for soliciting any type of response frame from a receiver terminal station, and a second trigger type indicating a specific trigger for soliciting a specific type of UL MU response frame from a plurality of terminal stations; and a receiving unit that receives the specific type of UL MU response frame from the plurality of terminal stations when the type subfield indicates the second trigger type.

[0160] As described above in the transmission device, when the type subfield indicates the second trigger type, the trigger frame includes a feedback type subfield, and the feedback type subfield indicates a feedback type requested from each of the plurality of terminal stations.

[0161] As described above in the transmission device, the specific type of UL MU response frame is one of a plurality of management frame types used for multi-user management frame exchange.

[0162] As described above in the transmission device, the trigger frame includes a user information field for each of the multiple terminal stations, and the user information field includes an RU allocation subfield indicating one or more resource units RU used by a corresponding one of the multiple terminal stations.

[0163] As described above, the trigger frame includes: an AID subfield, the AID subfield carrying a plurality of bits associated with one of the multiple terminal stations; and a user information field for each of the multiple terminal stations, the user information field including an RU allocation subfield indicating one or more resource units RU used by a corresponding one of the multiple terminal stations, and the one or more RUs indicated by the RU allocation subfield are associated with a terminal station indicated by the AID subfield.

[0164] As described above in the transmission device, the trigger frame includes a timeout subfield indicating a transmission restriction duration, during which the plurality of terminal stations are restricted from sending any frames except ACK frames.

[0165] According to another aspect of the present invention, a transmission method includes: sending a trigger frame for allocating resources for uplink multi-user ULMU transmission, the trigger frame including a common information field, the common information field including a type subfield indicating one of a plurality of trigger types, the plurality of trigger types including a first trigger type indicating a basic trigger for soliciting any type of response frame from a recipient terminal station, and a second trigger type indicating a specific trigger for soliciting a specific type of ULMU response frame from a plurality of terminal stations; and when the type subfield indicates the second trigger type, receiving the specific type of UL MU response frame from the plurality of terminal stations.

[0166] As in the transmission method described above, when the type subfield indicates the second trigger type, the trigger frame includes a feedback type subfield, and the feedback type subfield indicates the feedback type requested from each of the plurality of terminal stations.

[0167] As in the transmission method described above, the specific type of UL MU response frame is one of a plurality of management frame types used for multi-user management frame exchange.

[0168] As described above in the transmission method, the trigger frame includes a user information field for each of the multiple terminal stations, and the user information field includes an RU allocation subfield indicating one or more resource units RU used by a corresponding one of the multiple terminal stations.

[0169] As described above in the transmission method, the trigger frame includes: an AID subfield, the AID subfield carries a plurality of bits for associating with one of the multiple terminal stations; and a user information field for each of the multiple terminal stations, the user information field includes an RU allocation subfield indicating one or more resource units RU used by a corresponding one of the multiple terminal stations, and the one or more RUs indicated by the RU allocation subfield are associated with a terminal station indicated by the AID subfield.

[0170] As described above in the transmission method, the trigger frame includes a timeout subfield indicating a transmission restriction duration, during which the plurality of terminal stations are restricted from sending any frames except ACK frames.

[0171] In the aforementioned embodiments, the present disclosure is configured with hardware by way of example, but may also be provided by cooperation of software and hardware.

[0172] In addition, the functional blocks used in the description of the embodiments are generally implemented as LSI devices that are integrated circuits. The functional blocks can be formed as separate chips, or a part or all of the functional blocks can be integrated into a single chip. The term "LSI" is used herein, but the terms "IC", "system LSI", "super LSI" or "ultra LSI" may also be used, depending on the level of integration.

[0173] In addition, circuit integration is not limited to LSI, and can be realized by a dedicated circuit system or a general-purpose processor other than LSI. After LSI is made, a programmable field programmable gate array (FPGA) or a reconfigurable processor that allows the connection and setting of the circuit unit in LSI to be reconfigured can be used.

[0174] If a circuit integration technology that replaces LSI emerges due to semiconductor technology or other technology derived therefrom, such technology can be used to integrate functional blocks. Another possibility is application of biotechnology or the like.

[0175] Industrial Applicability

[0176] The present disclosure may be used to enable the exchange of management frames between multiple wireless devices in an efficient manner.

[0177] Label list

[0178] 100 Wireless Network

[0179] 110, 120, 130, 140, 150, 160, 1900 STA

[0180] 190, 1800 AP

[0181] 1810, 1910 Power

[0182] 1820, 1920 Memory

[0183] 1830, 1930 CPU

[0184] 1840, 1940 Auxiliary storage devices

[0185] 1850, 1950 Wireless Interface

[0186] 1852, 1952 MAC module

[0187] 1854 TF timeout calculation unit

[0188] 1856, 1956 Preferred response type table

[0189] 1860, 1960 PHY Module

[0190] 1870, 1970 Antenna

[0191] 1880 Wired Communication Interface

[0192] 1954 TF timeout timer

[0193] 1958 TX Restricted Sign

Claims

1. A sending device, comprising: a transmitter, transmitting a trigger frame for allocating resources for uplink multi-user (UL) MU transmission, the trigger frame comprising a common information field, the common information field comprising a type subfield indicating one of a plurality of trigger types, wherein the plurality of trigger types comprises a first trigger type; as well as a receiver, receiving data transmitted by the UL MU, In response to the type subfield indicating the first trigger type, the trigger frame includes a first dependency type field, the first dependency type field including information indicating a traffic identifier TID of data to be used for the UL MU transmission, The multiple trigger types include a second trigger type and a third trigger type, the first trigger type indicates a basic trigger, the second trigger type indicates a multi-user block ack request, and the third trigger type indicates a specific trigger for soliciting a specific type of UL MU response frame from multiple terminal stations. wherein, in response to the type subfield indicating the third trigger type, the receiver receives the specific type of UL MU response frames from the plurality of terminal stations, and Wherein, in response to the type subfield indicating the third trigger type, the trigger frame includes a feedback type subfield including a feedback type requested for each of the plurality of terminal stations, and the trigger frame solicits a feedback report.

2. The transmitting device according to claim 1, wherein: The information is a preferred traffic class of data to be used for the UL MU transmission.

3. The transmitting device according to claim 1, wherein: The basic trigger is used to solicit multiple types of response frames from the end stations.

4. The transmitting device according to claim 1, wherein: The specific type of UL MU response frame is one of a plurality of management frame types used for multi-user management frame exchange.

5. The transmitting device according to claim 1, wherein: The trigger frame includes a user information field for each of the plurality of terminal stations, the user information field including an RU allocation subfield indicating one or more resource units RU used by a corresponding one of the plurality of terminal stations.

6. The transmitting device according to claim 1, wherein: The trigger frame includes: an AID subfield, the AID subfield carrying a plurality of bits for associating with one of the plurality of terminal stations; and a user information field for each of the plurality of terminal stations, the user information field including an RU allocation subfield indicating one or more resource units RU used by a corresponding one of the plurality of terminal stations, the corresponding one of the plurality of terminal stations being indicated by the AID subfield.

7. The transmitting device according to claim 1, wherein: The trigger frame includes a timeout subfield indicating a transmission restriction duration, during which the plurality of terminal stations are restricted from transmitting any frames except acknowledgment ACK frames.

8. The transmitting device according to claim 1, wherein: The trigger frame solicits the UL MU response frame from the terminal station after a duration of a short interframe space (SIFS) has passed from an end of the trigger frame.

9. The transmitting device according to claim 1, wherein: In response to the type subfield indicating the third trigger type, the trigger frame includes a second dependency type field including information specific to the third trigger type.

10. The transmitting device according to claim 9, wherein: The feedback type subfield is included in the dependency type field.

11. A sending method, comprising: sending a trigger frame for allocating resources for uplink multi-user (UL) MU transmission, the trigger frame comprising a common information field, the common information field comprising a type subfield indicating one of a plurality of trigger types, wherein the plurality of trigger types comprises a first trigger type; and receiving data transmitted by the UL MU, In response to the type subfield indicating the first trigger type, the trigger frame includes a first dependency type field, the first dependency type field including information indicating a traffic identifier TID of data to be used for the UL MU transmission, The multiple trigger types include a second trigger type and a third trigger type, the first trigger type indicates a basic trigger, the second trigger type indicates a multi-user block ack request, and the third trigger type indicates a specific trigger for soliciting a specific type of UL MU response frame from multiple terminal stations. wherein, in response to the type subfield indicating the third trigger type, receiving the specific type of UL MU response frame from the plurality of terminal stations, and Wherein, in response to the type subfield indicating the third trigger type, the trigger frame includes a feedback type subfield including a feedback type requested for each of the plurality of terminal stations, and the trigger frame solicits a feedback report.

12. A receiving device, comprising: a receiver, receiving a trigger frame for allocating resources for uplink multi-user (UL) MU transmission, the trigger frame comprising a common information field, the common information field comprising a type subfield indicating one of a plurality of trigger types, wherein the plurality of trigger types comprises a first trigger type; and a transmitter, transmitting the UL MU transmission data, In response to the type subfield indicating the first trigger type, the trigger frame includes a first dependency type field, the first dependency type field including information indicating a traffic identifier TID of data to be used for the UL MU transmission, The multiple trigger types include a second trigger type and a third trigger type, the first trigger type indicates a basic trigger, the second trigger type indicates a multi-user block ack request, and the third trigger type indicates a specific trigger for soliciting a specific type of UL MU response frame from multiple terminal stations. wherein, in response to the type subfield indicating the third trigger type, the specific type of UL MU response frame is received from the plurality of terminal stations, and Wherein, in response to the type subfield indicating the third trigger type, the trigger frame includes a feedback type subfield including a feedback type requested for each of the plurality of terminal stations, and the trigger frame solicits a feedback report.

Images