COMMUNICATION DEVICE, COMMUNICATION METHOD, AND INTEGRATED CIRCUIT

Abstract

To enable efficient multi-user management frame exchange.SOLUTION: A communication apparatus of the present disclosure comprises: a transmitter that transmits a trigger frame for allocating resources for Uplink Multi User transmission, where the trigger frame comprises a common information field that includes a type subfield indicating one of a plurality of trigger types and the plurality of trigger types include a first trigger type; and a receiver that receives data of the Uplink Multi User transmission, where the trigger frame comprises a type dependent field that includes information indicating a traffic identifier to be used for the data of the Uplink Multi User transmission when the type subfield indicates the first trigger type.SELECTED DRAWING: Figure 18

Description

[Technical field]

[0001] The present disclosure generally relates to a transmitting apparatus and a transmitting method for exchanging multi-user management frames. [Background technology]

[0002] The Institute of Electrical and Electronics Engineers (IEEE) 802.11 Working Group is currently working on standardizing next-generation Wireless Local Area Network (WLAN) technologies under the 802.11ax Task Group. The Task Group is primarily focused on improving spectral efficiency to increase system throughput / area in high density environments of Access Points (APs) and / or terminal stations (hereafter referred to as "non-AP STAs" or simply STAs). Devices based on the IEEE 802.11ax standard are generally referred to as High Efficiency (HE) devices. Among the various proposed technologies, Orthogonal Frequency-Division Multiple Access (OFDMA) and uplink multi-user transmission are two key technologies that the IEEE 802.11ax Task Group has adopted to achieve its throughput improvement goal. FIG. 1 shows an example 802.11ax WLAN network 100 with an AP 190 and several STAs associated with the AP 190.

[0003] The IEEE 802.11 standard defines various types of frames that may be exchanged within an IEEE 802.11 based wireless network. Management frames are used to enable and maintain radio communication within a wireless network. These frames are generated within the Medium Access Control (MAC) layer of an IEEE 802.11 device and are usually transmitted with a more robust Modulation and Coding Scheme (MCS) to ensure proper reception. Some management frames are broadcast by an Access Point (AP) within a Basic Service Set (BSS). Broadcast management frames include, for example, Beacon frames to advertise the existence of a BSS as well as various attributes such as the wireless channel on which the BSS is operating, the Service Set Identifier (SSID) of the BSS, etc. STAs within communication range of an AP can use the information obtained from the Beacon frames to join the BSS for the first time if they have not already joined the BSS, or to update their records of the BSS if they have already joined the BSS. However, the majority of management frames are used in a unicast manner (ie, addressed to a specific STA or AP).

[0004] In some cases, the AP may send a management frame to a specific STA to request a specific action (e.g., perform a Disassociate frame to request the STA to leave the BSS). In most cases, however, there is an exchange of relevant management frames between the AP and the STA. As an example, an Association Request frame is sent from 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 Acknowledgment (ADDBA) Request is sent from the AP to the STA, and the STA sends an ADDBA Response frame back to the AP to set up the Block Acknowledgment (Ack) mechanism between the two devices. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] IEEE802.11-15 / 0132r17, Specification Framework for TGax, May 2015 [Non-Patent Document 2] IEEE802.11-16 / 0024r1, Proposed TGax draft specification [Non-Patent Document 3] IEEE Std 802.11-2012 Summary of the Invention [Problem to be solved by the invention]

[0006] In the downlink (DL), multi-user transmission using Multi-user Multiple Input Multiple Output (MU-MIMO) is possible, and Orthogonal Frequency Division Multiple Access (OFDMA) can be used in both the downlink and uplink (UL), but efficient management frame exchange in multi-user transmission is difficult. [Means for solving the problem]

[0007] A non-limiting embodiment of the present disclosure provides a transmitting device having a transmitter unit that transmits a Trigger frame for allocating resources for uplink multi-user (UL MU) transmission, the Trigger frame including a 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 used to request a response frame of any type from a receiving terminal station and a second trigger type indicating a particular trigger used to request a UL MU response frame of a particular type from the plurality of terminal stations, and a receiving unit that receives a UL MU response frame of a particular type from the plurality of terminal stations when the type subfield indicates the second trigger type.

[0008] These general and specific aspects can be implemented using devices, systems, methods, and computer programs, as well as any combination of devices, systems, methods, and computer programs. Effect of the Invention

[0009] The methods described in this disclosure allow for efficient multi-user management frame exchange.

[0010] Further benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. Benefits and / or advantages may be obtained individually from the various embodiments and features of the specification and drawings. It is not necessary that all of the various embodiments and features of the specification and drawings be provided in order to obtain one or more of such benefits and / or advantages. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram of a particular embodiment of a system utilizing multi-user management frame switching. [Diagram 2] FIG. 1 illustrates an example frame exchange sequence including setup and teardown of the Block Ack mechanism. [Diagram 3] A diagram of an example frame exchange sequence for Block Ack configuration between an AP and multiple STAs. [Figure 4A] 13 shows the configuration of an element used to carry a “TF Timeout” field used in the first embodiment. [Figure 4B] 13 is a table showing the meaning of a "TF Timeout" field in the first embodiment. [Diagram 5] 1 is a diagram of an example multi-user management frame exchange initiated by an AP according to the present disclosure. [Figure 6] 1 is a diagram of another example multi-user management frame exchange initiated by an AP according to the present disclosure. [Figure 7] 11 is a diagram of another example multi-user management frame exchange initiated by a STA according to the present disclosure. [Figure 8] 4 is a diagram of another example multi-user management frame exchange initiated by a STA according to the present disclosure. [Figure 9A] 4 shows a structure of a Trigger frame according to the first embodiment. [Figure 9B] 4 shows a structure of a Common Info field according to the first embodiment. [Figure 9C] 1 shows a structure of a Type-dependent Common Info field according to the first embodiment. [Figure 9D] 3 shows a table illustrating some frame types according to the first embodiment. [Figure 9E] 4 shows a structure of a Subtype Specific subfield according to the first embodiment. [Figure 9F] 13 shows a table for explaining an Action Category sub-field according to the first embodiment. [Figure 9G] 1 shows a table for explaining Action Field sub-fields according to the first embodiment. [Figure 10A] 13 shows the structure of an HE Variant Aggregated Control (A-Control) subfield used to carry the “TF Timeout” field used in the second embodiment. [Figure 10B] 13 shows the format of a Control sub-field according to the second embodiment. [Figure 10C] 13 shows a table illustrating Control ID subfield values ​​according to the second embodiment. [Figure 11A] 13 shows a table illustrating various trigger types according to the second embodiment. [Figure 11B] 13 shows a format of a Preferred Response Type subfield according to the second embodiment. [Figure 11C] 13 shows a table for explaining Frame Subtypes according to the second embodiment. [Figure 11D] 13 shows a table illustrating various Action Field values ​​according to the second embodiment. [Figure 11E] 13 shows the format of a User Info field according to the second embodiment. [Figure 12A] 13 shows the format of an ADDBA Extension element field according to the third embodiment. [Figure 12B] 13 shows the format of an ADDBA Capabilities field according to the third embodiment. [Figure 12C] 13 shows a table illustrating various TF Timeout values ​​according to the third embodiment. [Figure 13A] 13 shows a structure of a Preferred Response Type sub-field according to the third embodiment. [Figure 13B] 13 shows a table illustrating various Frame Type values ​​according to the third embodiment. [Figure 14] FIG. 13 is a diagram of a UL MU response scheduling Control subfield structure used to carry a TF Timeout used in the fourth embodiment. [Figure 15] FIG. 13 is a diagram of an exemplary multi-user management frame exchange initiated by an AP according to a fourth embodiment. [Figure 16] 4 is a flowchart of operations performed by an AP to initiate a multi-user management frame exchange in accordance with the present disclosure. [Figure 17] 4 is a flowchart of operations performed by a STA to participate in an AP-initiated multi-user management frame exchange according to the present disclosure. [Figure 18] FIG. 2 is a block diagram of an example AP. [Figure 19] 1 is a block diagram of an exemplary STA. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] The present disclosure can be better understood with the aid of the following figures and embodiments: The embodiments described herein are merely exemplary in nature and are used to illustrate some of the possible applications and uses of the present disclosure, and should not be construed as limiting the present disclosure with respect to alternative embodiments not expressly described herein.

[0013] 2 shows an example sequence 200 of frame exchanges between two 802.11 devices, including an exchange of management frames to negotiate Block Ack parameters. In an infrastructure BSS, one of the 802.11 devices is an AP and the other is an 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 with the IEEE 802.11e amendment that allows an 802.11 device to burst frames to another 802.11 device without requiring an immediate Ack frame in return for every received frame.

[0014] The 802.11 device that initiates a burst transmission is called the Originator, while the receiving 802.11 device is called the Recipient. After completing a burst transmission, the Originator can request a Block Ack, which contains a bitmap of the received frames, by sending a Block Ack Request frame to the Recipient. This exchange is shown in phase 220 of Figure 2. The IEEE 802.11n amendment further enhances this feature by allowing bursts of data to be aggregated into a single Management Protocol Data Unit (MPDU), called A-MPDU. Although Block Ack is a useful feature, it requires both the Originator and the Recipient to provide additional resources to make it available. Not only does the Recipient need to reserve additional buffers to receive the burst of frames, but it also needs to keep a scoreboard that records how well the frames are received. Similarly, the Originator needs to keep a record of the frames it has sent. This preparation is done in the Block Ack Setup phase 210. In this phase, the two 802.11 devices can negotiate buffer sizes, Traffic Identifiers (TIDs) for associated frames, negotiation lifetime, etc. Once the Data Exchange phase is complete, either party may tear down the Block Ack negotiation in the Teardown phase 230.

[0015] As explained above, most of the management frame exchanges are between two 802.11 devices, typically an AP and a STA. As an example, the details of the management frame exchange included in the Block Ack Setup phase 210 are shown in FIG. 3. In this example, the AP is the Originator and the STA is the Recipient. Before the AP can use the Block Ack function, the AP that wants to use the Block Ack function must configure the Block Ack function for each STA. Frame exchange sequences 300, 310, and 320 are initiated by the AP to configure the Block Ack function with STA1, STA2, and STAn, respectively. Each sequence includes an exchange of ADDBA Block Ack Action Management frames between the AP and each STA. For example, in sequence 300, the AP initiates the exchange by contending for the wireless medium. This contention is represented in the figures by symbol 302 throughout this disclosure.

[0016] If the AP wins the contention, it sends a uniquely addressed ADDBA Request frame 304 towards STA1. Upon receiving the ADDBA Request frame 304, STA1 replies to the AP with an Ack frame 306 after a Short Interframe Space (SIFS) time from the end of the ADDBA Request frame. The transmission of the Ack frame does not require contention on the wireless medium. After processing the ADDBA Request frame and accepting the request, the STA replies with an ADDBA Response frame 308 after acquiring the wireless medium through contention. The AP acknowledges the reception of the ADDBA frame by sending an Ack frame. If the STA uses the Block Ack feature, a similar frame exchange is required in the reverse direction, i.e. initiated by the STA. It is obvious that this Setup process can take a lot of time if many STAs are involved.

[0017] Although multi-user transmissions are possible in the downlink (DL) using MU-MIMO and in both DL and uplink (UL) using Orthogonal Frequency Division Multiple Access (OFDMA) during management frame exchange, there are some issues that prevent efficient multi-user communication, especially in the UL direction. These issues can be summarized as the following two problems: 1) Most management frames are transmitted using AC_VO, which is the highest Access Category (AC) of Enhanced Distributed Channel Access (EDCA). When an AP transmits multiple management frames to multiple STAs in a DL multi-user PHY Protocol Data Unit (PPDU), the STAs that successfully receive the frames will attempt to send their respective response management frames back to the AP as soon as they are ready to reply. At the same time, to request multiple response management frames from the STAs in a multi-user manner, the AP will attempt to transmit a basic variant of a newly defined control frame called a Trigger frame.

[0018] The Basic Trigger frame includes information such as resource unit (RU) allocation, PPDU length, and MCS used for UL transmission. Upon receiving the Trigger frame, the STAs that have been assigned RUs in the Trigger frame can reply with their respective UL frames in a UL multi-user PPDU. This results in contention for the wireless medium between the STAs' response management frames and with the AP's Trigger frame. If the Trigger frame does not have access to the medium or its transmission is delayed, the STA cannot utilize multi-user transmission for the UL frame. 2) The Basic variant of the Trigger frame does not specify the frame types that the STAs can reply with in the UL multi-user PPDU. This can lead to a situation where some STAs reply with frames other than response management frames, requiring the AP to send one or more Trigger frames to those STAs. Both of these factors can lead to inefficiencies as well as delays in replying to response frames, which can require some of the request frames to be reissued due to timeouts.

[0019] Although the techniques described in this disclosure are applicable to many wireless communication systems, by way of example, the remainder of this disclosure will be described in terms of the IEEE 802.11 WLAN system and its associated terminology, which should not be construed as limiting the disclosure with respect to alternative wireless communication systems.

[0020] Referring again to FIG. 1, the exemplary wireless network 100 may include an AP 190 and many associated STAs. STA2 120 and STA6 160 represent a device class with high processing capabilities, high QoS requirements, and relatively low power saving requirements. STA1 110 and STA4 140 represent another device class that may have high processing capabilities and possibly high QoS requirements, but are 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 are more sensitive to power consumption. In IEEE 802.11ax terminology, STA1 110, STA2 120, STA4 140, and STA6 160 are considered Class A devices, which are high-performance devices, and STA3 130 and STA5 150 are considered Class B devices, which are low-capability devices.

[0021] A fundamental challenge in any wireless communication is the fact that a wireless transceiver can only be in a transmitting or receiving state at any given time. Even if a wireless device contains multiple transceivers, the transmitting signal is several times stronger than the receiving signal, so a transceiver cannot receive a signal at a particular frequency while transmitting at the same frequency. For this reason, virtually all wireless devices operate in half-duplex communication. This fact leads to the next challenge: the transmitter cannot detect by itself any collisions that may occur in the transmitted signals.

[0022] IEEE 802.11 eliminates this problem by using acknowledgements from the receiving device. If requested by the sender, the receiver sends back some acknowledgement frame (Ack / Block Ack, etc.) to acknowledge successful reception of the sender's frame. If the sender does not receive any acknowledgement for its transmission, it assumes that the transmission has failed and may proceed to perform recovery actions such as retransmitting the frame. As for precautionary measures, IEEE 802.11 uses Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) as the primary channel access mechanism. Collision avoidance is achieved by using random backoff, while CSMA involves the use of physical and virtual Channel Sense (CS) mechanisms. The physical CS mechanism is provided by the PHY layer and involves actual sensing of the wireless medium (preamble detection and / or energy detection). The virtual CS mechanism is provided by the MAC layer and utilizes the Network Allocation Vector (NAV). NAV maintains a prediction of future traffic on the medium based on time information signaled in most IEEE 802.11 frames. This time may be included in the MAC header and / or may be obtained from the Transmit Opportunity (TXOP) time in the PHY header, if present. If either the physical or virtual CS indicates that the medium is busy, the device cannot transmit any signal other than a few specific frames, such as Ack or Block Ack frames. NAV is useful to protect the device's transmissions from third-party devices that are within its range, but is not designed to prevent contention from STAs that are recipients of the frame that sets the NAV.

[0023] Multi-user transmission is a technique introduced in the IEEE 802.11ac amendment using MU-MIMO, but only for the downlink. The AP can transmit different unicast frames addressed to different STAs using different spatial streams. However, this feature was not introduced in the uplink direction because it requires additional antennas and other complexities. As explained earlier, multi-user transmission using OFDMA in both the downlink and uplink directions is a key technique adopted by the IEEE 802.11ax task group to achieve its throughput improvement goal. In the downlink direction, multi-user transmission is relatively straightforward since the AP transmits all multi-user frames. The DL multi-user PPDU consists of a wide channel PHY header that carries information about the narrowband channel (known as resource unit or RU) on which the individual PHY service data units (PSDUs) are carried. In theory, up to 37 independent transmissions can be carried in a multi-user PPDU to 37 separate STAs within one 20 MHz channel.

[0024] Transmission in the uplink direction is more complex because time synchronization between transmissions from multiple STAs is required and also because transmissions from different STAs need not interfere with each other, i.e., each STA needs to be assigned a unique RU. This is achieved in IEEE 802.11ax through a special control frame called a Trigger frame transmitted by the AP. The Trigger frame contains information used in UL transmission, such as Resource Unit (RU) allocation, PPDU length, MCS, etc. Upon receiving the Trigger frame, the STAs that have been assigned RUs in the Trigger frame can transmit their respective UL frames in a UL multi-user PPDU SIFS after the end of the Trigger frame without contention for the wireless medium. Apart from the Basic Trigger frame, which can be used to request any type of frame, various variants of the Trigger frame are defined to request specific types of frames. For example, the Multi-user Request To Send (MU-RTS) variant is used to request Clear To Send (CTS) frames from multiple STAs, the Multi-User Block Ack Request (MU-BAR) is used to request Block Ack frames from multiple STAs, etc.

[0025] Based on the above findings, the inventors of the present application have arrived at the present disclosure. A method is disclosed that allows efficient and timely exchange of multi-user management frames. According to one aspect of the present disclosure, the AP indicates in a DL PPDU carrying one or more frames a time during which a receiving STA addressed in a frame contained in the DL PPDU cannot transmit any frame other than an immediate acknowledgement to the immediately preceding DL PPDU until it receives another frame giving an explicit permission to retransmit. This can be seen as the transmitter protecting transmissions that may be made from one or more STAs that are recipients of earlier transmissions. Protection from third party STAs can be ensured by using conventional NAV protection mechanisms. This allows the AP to transmit a Trigger frame requesting a UL multi-user PPDU in a timely manner.

[0026] A second aspect of the present disclosure involves customizing the Trigger frame to restrict the frame types requested in the UL PPDU to those desired by the AP. In the case of a multi-user management frame exchange, this can be done by using a specific Trigger frame type in the Trigger frame, or a new variant of the Basic Trigger frame to indicate the exact management frame type, subtype and other details, allowing the addressed STA to clearly identify the exact management frame type desired by the AP to be included in the UL PPDU.

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

[0028] First Embodiment As mentioned above, one of the challenges of a multi-user management frame exchange is the fact that if an AP initiates the exchange by transmitting a DL multi-user PPDU containing management request frames addressed to multiple STAs, the corresponding single-user management response / indication frames from each STA may contend for the medium with the AP's Trigger frame, causing delays in the transmission of the Trigger frame. Since an UL multi-user PPDU carrying multiple management response frames cannot be transmitted without receiving a Trigger frame from the AP, disruptions to the multi-user management frame exchange occur.

[0029] Including a longer TXOP time in the DL PPDU allows the AP initiating the frame exchange to attempt to protect subsequent response frames from the STAs, thereby setting the NAV of the third party STAs. Alternatively, the AP can use protection mechanisms such as exchanging Multi-user RTS (MU-RTS) and CTS frames before the management frame exchange. However, since the NAV setting rule is not applied to the STAs, the problem of delayed Trigger frames due to contention from the STAs that are the recipients of the DL PPDU is not solved. The AP can attempt to avoid the above contention from the STAs that are the recipients of the DL PPDU by sending a Trigger frame SIFS (Short Interframe Space) after the end of the UL PPDU that carries the STAs' Ack frame to the DL PPDU. This prevents the STAs' single-user management response / notification frames from contending for the medium. However, this method may not always work, since the STAs may not be able to prepare their management response / notification frames within this time. This can be due to several factors, e.g. the processing power of the STA, the nature of the management frames exchanged, or if the STA is busy with other operations when the management request frame is received, etc. This not only leads to RUs in the UL PPDU going unused, resulting in an inefficient use of the medium, but in extreme cases a third party STA may perceive the medium as idle and transmit, resulting in collisions at the AP.

[0030] To solve this problem, a new protection mechanism is introduced in this disclosure. It involves the AP including in the downlink unicast frame a time representing a Trigger Frame Timeout, referred to herein as TF Timeout. The inclusion of TF Timeout in a frame indicates the AP's intention to transmit, as the next downlink frame, a Trigger frame within the timeout period that assigns an RU to the receiving STA for transmitting an uplink frame. The TF Timeout may be carried as a separate field in a new element defined for the express purpose of carrying the TF Timeout, or it may be carried in an existing element.

[0031] 4A shows the configuration of an element 400 that carries a TF Timeout time according to the first embodiment. 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 one octet long, and is defined by the IEEE 802.11 standard. The length field 420 is also one octet long and specifies the number of octets after the length field. In this example, the length field indicates one octet.

[0032] The TF Timeout field 430 is also one octet long, and its encoding is as shown in table 450 in Figure 4B. When TF Timeout is set to 0, it indicates that the Timeout is not set, and when a non-zero value is set in TF Timeout, the TF Timeout is reset. When a non-zero value is set, the TF Timeout indicates a timeout period in Time Units (TU, 1TU = 1024 μs).

[0033] Figure 5 illustrates an example multi-user management frame exchange 500 enabled by this disclosure. The frame exchange sequence in this example is a multi-user version of the Block Ack setup process described in Figure 3, and involves an exchange of ADDBA Request frames from the AP (Originator) and ADDBA Response frames from the STAs (Recipients). The frame exchange is initiated by the AP acquiring the medium through medium contention and transmitting an OFDMA DL multi-user PPDU 502 carrying one or more unicast ADDBA Request frames 504, 506, ..., 508 addressed to STA1, STA2, ..., STAn. "X, ..., Y" 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 by the multi-user PPDU.

[0034] According to the first embodiment, each of the ADDBA Request frames 504, 506, ..., 508 also carries an element 400 including a TF Timeout field 430. The TF Timeout field 430 indicates a time, as visualized by 518, during which the STAs (STA1, STA2, ..., STAn) with an address matching the Receiver Address field of each ADDBA Request frame 504, 506, ..., 508 cannot transmit frames other than an immediate acknowledgement to the immediately preceding DL PPDU until they receive a Trigger frame 510 that allocates an RU for the respective UL frame transmission. To determine the appropriate value to be used for the TF Timeout time, the AP considers several factors, such as the type of management frames being exchanged or the processing capabilities of the STAs. For example, the AP may set a longer TF Timeout time for the exchange of ADDTS management frames, since ADDTS frames contain many parameters and STAs may need more time to prepare the ADDTS frames. Similarly, the AP may set a shorter TF Timeout time if all STAs involved in the exchange are higher capability Class A devices, and a longer TF Timeout time if the STAs are lower capability Class B devices.

[0035] The AP's TF Timeout time may be selected based on the AP's experience with previous Block Ack Setups with STAs. For example, if a previous Block Ack Setup with a STA fails because the STA cannot transmit an ADDBA Response frame on time, the AP may select a longer TF Timeout time for such STA in a subsequent Block Ack Setup. The TF Timeout time of a group of STAs participating in the same frame exchange should have the same value. The calculation of the TF Timeout time may be performed by a dedicated module 1854 in the MAC layer of the AP, or may be implemented as a software function in the MAC. A STA that receives the TF Timeout time may implement a separate timer (TF Timeout Timer 1954) in the MAC layer to count down this time, and may set a TX Restriction Flag 1958 that restricts any transmission while the timer value is non-zero. Upon receiving a valid Trigger frame from the AP and allocating an RU for UL frame transmission to the STA, the TF Timeout Timer 1954 is reset to zero and the TX Restriction Flag 1958 is cleared.

[0036] After receiving an Ack frame for the ADDBA Request frame, the AP transmits a Trigger frame 510 to the STA that returned the Ack frame to request the STA to return an ADDBA response frame. Apart from the other information mentioned above, the Trigger frame 510 includes information for restricting the frame type that the STA can transmit in the immediately following UL PPDU to an ADDBA Response frame. In the exemplary sequence 500, the Trigger frame 510 assigns RUs 512, 514, ..., 516 to STA1, STA2, ..., STAn, respectively. The Trigger frame may be transmitted as a broadcast Trigger frame in a Single user PPDU format or as multiple unicast Trigger frames in a Multi-user PPDU format.

[0037] If the AP is confident that the STA will be able to prepare an ADDBA Response frame in time, the AP may contend for the medium and attempt to transmit a Trigger frame 510 immediately after receiving an Ack frame from the STA. Alternatively, it may choose to attempt the transmission a little later to give the STA more time to prepare the ADDBA Response frame, but this comes with the risk that a third party STA will preempt the transmission of the Trigger frame. This risk is 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 time used in the MU-RTS / CTS exchange or the first downlink MU PPDU to protect the multi-user management frame exchange depends on the TF Timeout time. Ideally, a TXOP time covering the entire management frame exchange is desirable to protect the management frame exchange from third party STAs, but if the TF Timeout time is relatively long, such protection is undesirable as it may be perceived as unfair by third party terminals.

[0038] A more reasonable approach is to set the TXOP time just long enough to protect the Trigger frame 510 where the AP requests a response management frame, which starts the next TXOP with a TXOP time long enough to protect the next frame exchange. A more conservative approach is to set the TXOP time only until the downlink MU PPDU 502 is acknowledged by an Ack frame, in which case there is no protection against third party STAs. How the AP or STAs involved in the management frame exchange contend for the medium to transmit a Trigger frame or a single user response management frame may also depend on the length of the TXOP time. Within the TXOP time, contention involves only sensing the medium for a fixed time, e.g., PIFS, without performing random backoffs, while outside the TXOP time, medium contention also involves random backoffs.

[0039] Upon receiving the Trigger frame 510, each STA (STA1, STA2, ..., STAn) transmits a UL multi-user PPDU 520, with its PHY header occupying the full bandwidth and each ADDBA Response frame 522, 524, ..., 526 occupying a smaller bandwidth in its assigned RU 512, 514, ..., 516. Upon receiving the UL multi-user PPDU 520, the AP completes the frame exchange by transmitting an acknowledgement frame 530 in a separate RU as a DL multi-user PPDU carrying individual Ack frames 532, 543, ..., 536.

[0040] 6 illustrates a frame exchange sequence 600 that is very similar to frame exchange sequence 500, but illustrates an example where one or more STAs are unable to prepare the requested management frame in time, i.e., an ADDBA Response frame in this example. Here, STA1 is unable to send back an ADDBA Response frame and the RU assigned to STA1 is empty, as shown at 612. In such a case, the AP makes an educated assumption that STA1 will attempt to send an ADDBA Response frame after a certain time, using experience that STA1 has previously acknowledged an ADDBA Request frame.

[0041] To avoid EDCA channel access inefficiencies, the AP transmits another Trigger frame 622 to STA1 in the same DL multi-user PPDU that carries Ack frames 624,...,626 to STAs2,...,STAn, with each Ack frame occupying one RU. Because the Trigger frame 622 is longer than the Ack frame, the AP can allocate larger RUs for the Trigger frame compared to the RUs carrying the Ack frame to minimize padding. Furthermore, because the Trigger frame 622 allocates RUs only for one STA, namely STA1, the AP is likely to allocate the largest RU in its frequency band, e.g., 242 tone RUs in a 20 MHz operating band. This is considered a special use of the Trigger frame because the requested uplink PPDU carries PSDUs from a single user, rather than the more common case of multiple PSDUs from multiple users.

[0042] If the AP and STAs have implemented Block Ack configuration for management frame exchanges other than ADDBA frame exchanges, the AP can also acknowledge ADDBA Request frames from STAs2, ..., STAn using a single Multi-STA Block Ack variant frame instead of individual Ack frames 624, ..., 626. This also helps to balance the RU size between the Trigger frame 622 and the Ack frame. SIFS time after the end of the Trigger frame 620, STA1 sends an ADDBA Response frame 630 back to the AP in the RU assigned by the Trigger frame 622. Finally, the AP finishes the frame exchange by sending an Ack frame 640. In this example, only STA1 fails to send the ADDBA Response frame initially, but many other scenarios can occur, such as other STAs also failing to send their respective ADDBA Response frames, or STAs failing to send ADDBA Response times even after the second or subsequent Trigger frames. It is clear to those skilled in the art that the recovery operation described here, i.e., sending another Trigger frame in the same PPDU as the Ack frame, also works to recover the frame exchange sequence. The AP may repeat the process until the number of STAs that fail to send ADDBA Response frames is less than a preset value or the recovery attempt exceeds a timeout period predetermined by the AP for a multi-user frame exchange sequence.

[0043] FIG. 7 shows another exemplary multi-user management frame exchange sequence 700 used to set up a Block Ack mechanism between STA1, STA2, ..., STAn (Originator) and the AP (Recipient) with which the STAs are associated. In the single-user case, the STA initiates the 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 aggregate the ADDBA Response frames in the DL multi-user PPDU. However, a more efficient method would be to synchronize the ADDBA Requests from the STAs.

[0044] The AP is assumed to have sufficient information about the STAs most likely to request Block Ack configuration. The AP can collect such information in advance by passively collecting unsolicited Buffer Status Reports from the STAs. Alternatively, the AP can actively poll the STAs for Buffer Status Reports using a Buffer Status Report Poll (BSRP) variant Trigger frame. STAs that exhibit buffer loads above a certain threshold may be considered as candidates for multi-user Block Ack configuration. The AP can also use information on existing Traffic Streams (TS) that the STAs have set up with the AP to determine candidate STAs for multi-user Block Ack configuration. The AP initiates the frame exchange sequence by sending a Trigger frame 710 requesting ADDBA Request frames from the candidate STAs (STA1, STA2, ..., STAn).

[0045] Upon receiving the Trigger frame 710, each addressed STA prepares its respective ADDBA Request frame 722, 724, ..., 726 and transmits them on its assigned RU in a UL multi-user PPDU 720. The AP acknowledges the reception of the UL multi-user PPDU 720 by transmitting a DL multi-user PPDU 730 carrying a respective Ack frame. After preparing all ADDBA Response frames, the AP contends for the medium and, upon winning the medium, transmits a DL multi-user PPDU 740 carrying an ADDBA Response frame to the STA. Finally, the frame exchange sequence is completed by the STA by transmitting a UL multi-user PPDU carrying the respective Ack frame.

[0046] FIG. 8 shows another management frame exchange sequence 800 that is very similar to the frame exchange sequence 700. The AP starts the frame exchange sequence by transmitting a Trigger frame 810 that requests ADDBA Request frames from the candidate STAs (STA1, STA2, ..., STAn). Upon receiving the Trigger frame, each addressed STA prepares its ADDBA Request frame and transmits them in its assigned RU in a UL multi-user PPDU 820. In this example, the AP is fast enough to prepare the ADDBA Response frame within a SIFS time upon receiving the ADDBA Request frame. To avoid the inefficiency of EDCA contention, for each STA, the AP aggregates the ADDBA Request frame's Ack frame and each ADDBA Response frame and transmits them in a DL multi-user PPDU 830 SIFS after the end of the UL PPDU 820. Finally, the frame exchange sequence is completed by the STAs by transmitting a UL multi-user PPDU carrying each Ack frame. In this example, it is assumed that the AP sets a TXOP time in the Trigger frame 810 long enough to complete the entire frame exchange sequence 800.

[0047] 9A illustrates the structure of a Trigger frame that can be customized to request a specific type of frame according to this disclosure. The frame structure 900 is proposed in IEEE 802.11ax as a special control frame called the Trigger frame used for UL multi-user transmission request and resource allocation. Besides common MAC frame fields such as Frame Control 902, Duration 904, Receiver Address (RA) 906, Transmitter Address (TA) 908, and Frame Check Sequence (FCS) 918, the Trigger frame also includes the following fields: A Common Info field 910 used to indicate common information for all STAs that have been assigned an RU by the Trigger frame; · One or more User Info fields 912,...,914 that are used to indicate information specific to a particular user. A broadcast Trigger frame carries multiple User Info fields, whereas a unicast Trigger frame carries only a single User Info field. Optionally, the Trigger frame may include a Padding field 916 to extend the Trigger frame and provide more time for the STA to prepare the UL multi-user PPDU.

[0048] FIG. 9B shows the structure of the Common Info field 910, which includes the following subfields: The Trigger Type subfield 922 indicates the type of the Trigger frame. In the first embodiment, the Trigger Type subfield is set to the value 0 (zero), indicating a Basic Trigger frame. · The Length subfield 924 indicates the length of the requested UL PPDU. A Cascade Information subfield 926, if set to 1, indicates that the next Trigger frame follows the current Trigger frame. The CS Required field 928 indicates whether the STA must perform physical and virtual carrier sensing before transmitting a response frame. The BW field 930 indicates the channel bandwidth; Subfields CP and LT Type932, MU MIMO LTF mode934, # of LTF936, STBC938, LDPC Extra Symbol940, AP TX Power942 and Packet Extension944 indicate the information required by the PHY layer to prepare and transmit the UL PPDU. The Spatial Reuse subfield 946 indicates information for the spatial reuse of the medium. A HE-SIGA Reserved subfield 948 indicating how the reserved bits in the SIGA of the UL PPDU should be set; The Type-dependent common info subfield 950 indicates information specific to a particular Trigger frame type. The current Basic Trigger frame proposed in IEEE 802.11ax does not include the Type-dependent common info subfield.

[0049] 9C shows the structure of the Type-dependent Common Info field 950 proposed in the first embodiment, where the STAs indicated in the User Info field restrict the frame types that may be included in the UL PPDU following the Trigger frame. The Basic Trigger frame currently imposes no restrictions on the response frame types that may be included in the UL PPDU. According to the first embodiment, a Preferred Response Type subfield 952, two octets long, is included in the Type-dependent Common Info field 950 and contains the following subfields: · The 1-bit Frame Type subfield 954 indicates the frame type requested in the UL PPDU: a value of 0 indicates a Data frame and a value of 1 indicates a Management frame. The 4-bit TID / Frame Subtype subfield 956 indicates the TID of a Data frame if the Frame Type subfield 954 indicates a Data frame, and indicates the Management frame Subtype if the Frame Type subfield 954 indicates a Management frame. The same frame subtype coding as the Subtype subfield defined for the Frame Control field of the IEEE 802.11 standard is used, e.g., 0 indicates an Association Request frame and 13 indicates an Action frame. · The 1 octet long Subtype Specific subfield 958 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 differ for different management frames. For example, if the Frame Subtype subfield 956 is 13, indicating a Management Action frame, the Subtype Specific subfield 958 is further divided into a 5-bit long Action Category subfield 972 and a 3-bit long Action Field subfield 974. The encoding of the Action Category subfield 972 is detailed in table 980 of FIG. 9F, where values ​​0-21 are used to specify the Action frame Category defined in the IEEE 802.11 standard. For example, 0 indicates a Spectrum Management Action frame and 3 indicates a Block Ack Action frame. The Action Field subfield 974 specifies the frame format within the Action frame category, and an example when the Action Category indicates a Block Ack Action frame is detailed in table 990 in Figure 9G. The meanings of the values ​​0 to 7 are the same as those defined in the relevant sections of the IEEE 802.11 standard, e.g., 0 indicates an ADDBA Request and 1 indicates an ADDBA Response.

[0050] The encoding of the Preferred Response Type is summarized in table 960 of Figure 9D.

[0051] <Second embodiment> According to the second embodiment, the AP indicates the TF Timeout using one of the Control subfields in the Aggregated Control (A-Control) subfield of the HE Variant HT Control field.

[0052] FIG. 10A shows the format of the A-Control subfield of the HE Variant HT Control field 1000 defined in IEEE 802.11ax. The A-Control subfield includes a sequence of one or more Control subfields 1010, ..., 1020, followed by an optional Padding subfield 1030 padded with zeros to make the length of the A-Control subfield 30 bits. Each Control subfield consists of a 4-bit 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, and the length of the Control Information subfield is determined for each value of the Control ID subfield other than the reserved one. Control IDs 0 to 3 are defined in 802.11ax, and are shown in detail in table 1060 of FIG. 10C. FIG. 10B shows the format of a Control subfield 1050 used to carry a TF Timeout according to the second embodiment. In addition to the Control ID subfield 1052, a TF Timeout subfield 1054 of 8 bits is carried. The possible encodings of the subfield are as detailed in row 1062 of table 1060. Carrying the TF Timeout in the A-Control subfield in the MAC header of the downlink frame can be an efficient way to convey the TF Timeout.

[0053] According to the second embodiment, a new Trigger Type is defined for a Trigger frame used to request a Management frame. Table 1100 in Fig. 11A details an example of the encoding of the Trigger Type used to request a Management frame proposed in the second embodiment in row 1102, along with various Trigger Types defined in 802.11ax. When used to request a Management frame, the Trigger Type subfield 922 is set to a value indicating a Management frame Trigger.

[0054] Figure 11B shows the structure of the 2-octet long Preferred Response Type subfield 1100 proposed to be included in the Type-Dependent Common Info field 950, which is used to further narrow down the specific Management frame desired by the AP and includes a 4-bit long Frame Subtype subfield 1112 and an 8-bit long Subtype Specific subfield 1114, with the remaining 4 bits being reserved. The Frame Subtype subfield 1112 indicates the requested Management frame Subtype and can use the same frame subtype encoding as the Subtype subfield defined for the Frame Control field of the IEEE 802.11 standard. The encoding of the Subtype Specific subfield 1114 is different for each Management frame, and an example encoding when the Frame Subtype subfield 1112 indicates a Management Action frame is shown in Figure 9E.

[0055] Table 1140 in Figure 11D shows an example of encoding the Action Field subfield 974 when the Action Category indicates 1, which is a QoS Action frame. The meanings of the values ​​0 to 6 are the same as those defined in the relevant sections of the IEEE 802.11 standard, for example, 1 indicates ADDTS Response and 4 indicates QoS Map configure.

[0056] FIG. 11E shows a structure 1150 of one of the User Info fields 912, . . . , 914, which includes the following subfields: AID12 subfield 1152, which carries the AID of the STA for which the User Info field is intended; · RU Allocation subfield 1154 indicating the RUs allocated to the STA identified by the User Identifier subfield 1152; A coding Type subfield 1156 indicating the coding type of the uplink PPDU to be sent in response by the STA identified by the User Identifier subfield 1152; · an MCS subfield 1158 indicating the MCS of the uplink PPDU sent in response by the STA identified by the User Identifier subfield 1152; A Dual Carrier Modulation (DCM) subfield 1160 indicating whether DCM is used by the uplink PPDU sent in response by the STA identified by the User Identifier subfield 1152; An SS Allocation subfield 1162 indicating the spatial stream of the uplink PPDU to be sent in response by the STA identified by the User Identifier subfield 1152; · A Target RSSI subfield 1164 indicating the expected RSSI of the AP for an uplink PPDU sent in response by the STA identified by the User Identifier subfield 1152; · 1-bit reserved field 1165, · A Type dependent User Info subfield 1166 indicating information specific to the STA identified by the User Identifier subfield 1152. According to the second embodiment, if the Trigger Type subfield 922 is set to a value indicating Management frame Trigger, the Type dependent User Info subfield 1166 carries additional user specific information related to the Management frame exchange. As an example, it may contain a Traffic Stream ID (TSID) value if used during an exchange of ADDTS QoS Action frames, or a TID value if used during an exchange of Block Ack Action frames. Different User Info fields may carry different values.

[0057] <Third embodiment> According to the third embodiment, another method for carrying the TF Timeout is proposed: instead of defining a new element, the AP may use an existing element carried by the management frame to carry the TF Timeout.

[0058] An example for the case of a Block Ack Action frame is shown in FIG. 12A. The TF Timeout is carried in an ADDBA Extension element 1200. The Element ID 1202 is set as specified in the 802.11 standard. The Length field 1204 indicates one octet, and the ADDBA Capabilities field 1206 is customized as shown in FIG. 12B. The remaining 7 bits, other than the existing No-Fragmentation subfield 1212, are currently reserved. According to the third embodiment, some of the reserved bits, for example 6 bits, are used to indicate the TF Timeout 1224, and the remaining 1 bit is reserved. The encoding of the TF Timeout is as detailed in table 1230 of FIG. 12C. A zero value indicates that the TF Timeout is not set or is used to reset a previously set TF Timeout. And the values ​​1 to 63 indicate timeout values ​​of 1 to 63 TU, respectively. Compared with the first embodiment, the TF Timeout range that can be set by the method proposed in the second embodiment may be shorter depending on the number of bits available in the existing element to indicate the TF Timeout, but the TF Timeout time is not expected to be very long in practical implementation, so the goal of protecting the transmission of the AP can be achieved.

[0059] The third embodiment proposes another variant of the Trigger frame, which is a variant of the Trigger frame proposed in the first embodiment. Figure 13A shows the structure of a 2-octet long Preferred Response Type subfield 1300 proposed by the third embodiment to be included in the Type-Dependent Common Info field 950. The Preferred Response Type subfield 1300 includes a 2-bit Frame Type subfield 1310, a 4-bit TID / Frame Subtype subfield 1320, and an 8-bit Subtype Specific subfield 1330, with the remaining 2 bits being reserved.

[0060] The remaining subfields are the same as those defined in the first embodiment, but the encoding of the Frame Type subfield 1310 is detailed in table 1340 of FIG. 13B and matches the definition of the Type subfield defined for the Frame Control field of the 802.11 standard. The TID / Frame Subtype subfield 1320 indicates the TID of the Data frame if the Frame Type subfield 1310 indicates a Data frame, indicates the Management frame Subtype if the Frame Type subfield 1310 indicates a Management frame, and indicates the Control frame Subtype if the Frame Type subfield 1310 indicates a Control frame. The Subtype Specific subfield 1330 indicates further details about the frame type if the Frame Type subfield 1310 indicates a Management frame, and is otherwise reserved for Data and Control frames. The encoding of the Subtype Specific subfield 1330 is different for each Management frame, and an example encoding when the Frame Subtype subfield 1320 indicates a Management Action frame is shown in FIG. 9E.

[0061] <Fourth embodiment> According to a fourth embodiment, the AP includes in the DL multi-user PPDU initiating the multi-user management frame exchange one or more flags, called TF Flags, that indicate to the receiving STAs that the AP intends to transmit a Trigger frame allocating RUs to the STAs as the next frame following the DL multi-user PPDU. The TF Flags may be carried in one of the Control subfields of the A-Control subfield of the HE Variant HT Control field 1000.

[0062] 14 shows the structure of the Control subfield 1450 when the Control ID subfield is 0, in which case the Control information subfield carries scheduling information for an UL multi-user PPDU carrying an immediate acknowledgment for the frame containing the Control subfield. The Control subfield 1450 includes the following subfields: · UL PPDU Length subfield 1452 indicating the length of the uplink response PPDU. · RU Allocation subfield 1454 indicating the RUs allocated for transmitting the uplink response PPDU. · DL TX Power subfield 1456 indicating the transmit power of the AP. ·UL Target RSSI subfield 1458 indicating the target receive power of the AP. · UL MCS subfield 1460 indicating the MCS used for the uplink response PPDU. · TF Flag 1462 as proposed in the fourth embodiment, indicating the AP's intention to transmit a Trigger frame for allocating RUs to STAs and transmitting a subsequent uplink response PPDU as the next frame following the frame containing the Control subfield 1450.

[0063] When the TF flag 1462 is set to 1, it represents a transmission restriction, and the STA that is the recipient of the frame carrying the TF flag 1462 is restricted from transmitting on the medium, except for an immediate acknowledgement frame, until it receives a Trigger frame that allocates an RU from the AP, or until the TXOP time indicated by the frame carrying the TF flag 1462 expires. In other words, according to the fourth embodiment, the TXOP time indicated by the frame carrying the TF flag 1462 functions as an implicit TF Timeout proposed in other embodiments. If the STA fails to receive a Trigger frame, it can resume normal transmission when the TXOP expires.

[0064] A frame exchange sequence 1500 in FIG. 15 shows an example of a multi-user management frame exchange according to the fourth embodiment. A management frame exchange for Block Ack Setup will be taken as an example. A downlink multi-user PPDU 1510 carries multiple unicast ADDBA Request frames 1512, ..., 1516 addressed to STAs (STA1, ..., STAn). Each ADDBA Request frame also carries a Control subfield 1450 that assigns an RU of an Ack frame for the ADDBA Request frame with the TF Flag 1462 set to 1. The PPDU 1510 also sets a TXOP Time 1520 that is long enough to cover the time that the AP is expected to transmit a Trigger frame 1530 requesting an ADDBA Response frame from the STA. The TXOP Time 1520 serves as a protection for the Trigger frame 1520 from a third party STA. Since the TF Flag 1462 is set to 1, the STAs are restricted from transmitting their own single-user ADDBA Response frames until the Trigger frame 1530 is received.

[0065] Another alternative way to carry the TF Flag is to use a bit in the PHY header of the DL multi-user PPDU that initiates the multi-user management frame exchange, for example a bit in the common block field of the HE SIG-B. If the bit is set, the transmission limit applies to all STAs that have a non-broadcast RU assigned to the SIG-B user field.

[0066] <Wireless communication system> FIG. 16 illustrates an exemplary method 1600 implemented by an AP to facilitate AP-initiated multi-user Management frame exchange. An example for STA-initiated frame exchange is similar and therefore not described. At 1610, based on information from an upper layer application or based on Data frames in the AP's buffer, the AP selects a group of STAs with which the AP will initiate a Management frame exchange. The AP may also consider other factors such as STA capabilities during group selection. For example, class A STAs with high capabilities may be grouped together in one group and class B STAs with low capabilities may be grouped together in another group.

[0067] Based on similar information, at 1620, the AP also determines the value to be used for TF Timeout, or the appropriate TXOP time to be used if the TF Flag method is used. At 1630, the AP constructs a multi-user PPDU to carry the unicast management frame, and the multi-user PPDU includes the TF Timeout or TF Flag. At 1640, after contending for the medium, the AP transmits the multi-user PPDU. At 1650, the AP constructs a Trigger frame that assigns RUs to the STAs for returning each response management frame, and transmits the Trigger frame after waiting an appropriate time. At 1660, upon receiving the response management frames from the STAs, the AP transmits a multi-user PPDU carrying each Ack frame. If any of the STAs fail to return a response management frame, the AP also includes in the multi-user PPDU a broadcast or single / multiple unicast Trigger frame that assigns RUs for each such STA. This step can be repeated as necessary until the TXOP time expires or until the AP receives response management frames from all associated STAs.

[0068] FIG. 17 shows an exemplary method 1700 implemented by a STA to participate in a multi-user Management frame exchange initiated by an AP. The example for the case of a frame exchange initiated by an STA is similar and therefore will not be described. At 1710, the STA receives a multi-user PPDU transmitted by an AP and extracts a management frame addressed to the STA based on the relevant information from the PHY header. At 1720, the STA extracts either the TF Timeout field or the TF Flag apart from processing the received management frame and starts a timer initialized to the TF Timeout time or the remaining TXOP time if the TF Flag method is used. While the timer is non-zero, the STA refrains from transmitting frames other than immediate acknowledgment responses to received management frames.

[0069] At 1730, if the STA accepts the request from the AP and waits for a Trigger frame, it prepares a response management frame. At 1740, upon receiving the Trigger frame from the AP, the timer is reset and the STA transmits the prepared response management frame in the RU assigned to the STA by 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 lifted and the STA is free to contend and transmit the response management frame in single-user PPDU format.

[0070] <Access point configuration> FIG. 18 is a block diagram of an exemplary AP 1800, which may be the AP 190 of FIG. 1. The AP 1800 includes a central processing unit (CPU) 1830 coupled to a memory 1820, a secondary storage 1840, one or more wireless communication interfaces 1850, and other wired communication interfaces 1880. The secondary storage 1840 may be a non-volatile computer-readable storage medium used to persistently store associated instruction code, data, and the like. Upon startup, the CPU 1830 may copy instruction code and associated data to the volatile memory 1820 for execution. The instruction code may be an operating system, user applications, device drivers, executable code, and the like required for the operation of the AP 1800. The size of the instruction code, and therefore the storage capacity of both the secondary storage 1840 and the memory 1820, may be significantly larger than the storage capacity of the STA 1700.

[0071] The STA 1800 may include a power source 1810, which in many cases may be a mains power supply, but in some cases may be a large capacity battery such as a vehicle battery. The wired communication interface 1880 may be an Ethernet interface, a power line interface, a telephone line interface, or the like. The wireless communication interface 1850 may include an interface for cellular communication, an interface for a short-range communication protocol such as Zigbee, or may be a WLAN interface.

[0072] The wireless interface 1850 may further include a MAC module 1852 and a PHY module 1860. The MAC module 1852 of the AP may be significantly more complex than the MAC module of the STA 1900 and may include many sub-modules. Among other sub-modules, the MAC module 1852 may include a TF Timeout calculation unit 1854 responsible for performing step 1620 of the method 1600. The MAC module 1852 may also store a table 1856 of encodings used to represent the Preferred Response Type in the Trigger frame. The PHY module is responsible for converting between the MAC module data and the transmitted / received signals. The wireless interface may also be coupled, via the PHY module, to one or more antennas 1870 responsible for the actual transmission / reception of wireless communication signals on / from the wireless medium.

[0073] In certain embodiments, the operating system comprises a real-time operating system (RTOS), the user application comprises a web browser or a smartphone application, the device driver comprises a WLAN driver, and the executable code is executed by the CPU 1830 to cause the method 1600 to be executed. Depending on the embodiment, the encoding table 1856 of the Preferred Response Type can represent the encoding 960 of the Preferred Response Type, the encoding 1130 of the Preferred Response Type, or the encoding 1340 of the Preferred Response Type. The encoding table 1856 of the Preferred Response Type may be stored with default values at the time of manufacture, but the AP 1800 may fine-tune them according to the current network conditions as needed, for example, by notifying the member STAs of the contents of the new table during the association process. Alternatively, the AP 1800 may choose to advertise the new table contents in information elements within some periodic frames such as Beacon frames.

[0074] The AP 1800 may comprise many other components not shown in FIG. 18 for clarity. Only the components most relevant to the present disclosure are shown.

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

[0076] The secondary storage 1940 may be a non-volatile computer-readable storage medium used to persistently store associated instruction code, data, and the like. Upon startup, the CPU 1930 may copy instruction code and associated data to the volatile memory 1920 for execution. The instruction code may be an operating system, user applications, device drivers, executable code, and the like required for operation of the STA 1900. The STA 1900 may also include a power source 1910, such as a lithium-ion battery or a coin cell 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 may be a WLAN interface.

[0077] The air interface 1950 may further include a MAC module 1952 and a PHY module 1960. Among other sub-modules, the MAC module 1952 may comprise a TF Timeout timer 1954 that tracks the transmission restriction period based on either the TF Timeout field or the TXOP time if the TF Flag method is used. The MAC module 1952 may maintain a TX Restriction Flag 1958 that records the transmission restriction state, and if the flag is set, the STA refrains from transmitting frames other than immediate acknowledgments. The MAC module 1952 may also store a table 1956 of bit encodings used to represent the encoding of the Preferred Response Type. The PHY module is responsible for the conversion between the MAC module data and the transmitted / received signals. The air interface may also be coupled to one or more antennas 1970 that are responsible for the actual transmission / reception of wireless communication signals on / from the wireless medium via the PHY module.

[0078] In a particular embodiment, the operating system comprises a real-time operating system (RTOS), the user application comprises a web browser or smartphone app, the device driver comprises a WLAN driver, and the executable code executed by the CPU 1930 to execute the method 1700. A TF Timeout timer 1954 is used 1720 to track a TF Timeout. Depending on the embodiment, the Preferred Response Type Encoding Table 1956 can represent the Preferred Response Type Encoding 960, the Preferred Response Type Encoding 1130, or the Preferred Response Type Encoding 1340. The Preferred Response Type Encoding Table 1956 may be stored with default values ​​at the time of manufacture. The Preferred Response Type Encoding Table 1956 may also be updated according to values ​​signaled by the AP during the association process or based on values ​​periodically advertised by the AP in periodic frames such as Beacon frames.

[0079] The STA 1900 may comprise many other components that are not shown in Figure 19 for clarity. Only the components most relevant to the present disclosure are shown.

[0080] In the above-described embodiment, the present disclosure is configured using hardware as an example, but may be realized using software that cooperates with hardware.

[0081] Furthermore, the functional blocks used in the description of this embodiment are typically realized as LSI devices, which are integrated circuits. The functional blocks may be formed as individual chips, or some or all of the functional blocks may be integrated into a single chip. Although the term "LSI" is used here, the terms "IC," "system LSI," "super LSI," and "ultra LSI" can also be used depending on the degree of integration.

[0082] Furthermore, the integration of circuits is not limited to LSI, and may be realized by dedicated circuits other than LSI or general-purpose processors. After the LSI is manufactured, a programmable FPGA (Field Programmable Gate Array) or a reconfigurable processor that allows the connection and settings of the LSI circuit cells to be reconfigured may also be used.

[0083] If a replacement for LSI appears as a result of advances in semiconductor technology or other technologies derived from it, such a technology could be used to integrate functional blocks. Another possibility is applications such as biotechnology. [Industrial Applicability]

[0084] The present disclosure can be used to enable the exchange of management frames between multiple wireless devices in an efficient manner. [Explanation of symbols]

[0085] 100 Wireless Network 110,120,130,140,150,160,1900 STAs 190,1800 AP 1810,1910 Power supply 1820,1920 memory 1830,1930 CPU 1840,1940 Secondary storage device 1850,1950 Wireless Interface 1852,1952 MAC Module 1854 TF Timeout calculation part 1856,1956 Preferred Response Type Table 1860,1960 PHY Module 1870,1970 Antenna 1880 Wired Communication Interface 1954 TF Timeout timer 1958 TX Restriction Flag

Claims

1. a circuit for generating a trigger frame for requesting an uplink multi-user transmission and allocating resources for the uplink multi-user transmission, the trigger frame including a 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 and a second trigger type, the first trigger type indicating a basic trigger and the second trigger type indicating a multi-user block ack request; an antenna for transmitting the trigger frame and for receiving data of the uplink multi-user transmission; When the type subfield indicates the first trigger type, the trigger frame includes a type-dependent field including information indicating a traffic identifier that identifies a desired type of the data of the requested uplink multi-user transmission. Communications equipment.

2. the basic trigger does not impose any restrictions on the type of uplink multi-user transmission requested; The communication device according to claim 1 .

3. A communication method for a communication device, comprising: generating a trigger frame for requesting an uplink multi-user transmission and allocating resources for the uplink multi-user transmission, the trigger frame including a 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 and a second trigger type, the first trigger type indicating a basic trigger and the second trigger type indicating a multi-user block ack request; transmitting the trigger frame; receiving data of the uplink multi-user transmission; When the type subfield indicates the first trigger type, the trigger frame includes a type-dependent field including information indicating a traffic identifier that identifies a desired type of the data of the requested uplink multi-user transmission. Communication methods.

4. generating a trigger frame for requesting an uplink multi-user transmission and allocating resources for the uplink multi-user transmission, the trigger frame including a 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 and a second trigger type, the first trigger type indicating a basic trigger and the second trigger type indicating a multi-user block ack request; transmitting the trigger frame; receiving data of the uplink multi-user transmission; and When the type subfield indicates the first trigger type, the trigger frame includes a type-dependent field including information indicating a traffic identifier that identifies a desired type of the data of the requested uplink multi-user transmission. Integrated circuits.

Images