Patent ID: 12212416

DETAILED DESCRIPTION

Techniques for acknowledging communication frames described below are discussed in the context of wireless local area networks (WLANs) that utilize protocols the same as or similar to protocols defined by the 802.11 Standard from the Institute of Electrical and Electronics Engineers (IEEE) merely for explanatory purposes. For example, embodiments of techniques for acknowledging WLAN communication frames that include i) data being conveyed to another device, and ii) quality of service (QoS) information, regarding the data, in a media access control (MAC) header of the communication frame (sometimes referred to herein as “QoS data frames”), are described below. In other embodiments, however, acknowledgment techniques are utilized for other types of communication frames and/or in other types of wireless communication systems such as personal area networks (PANs), mobile communication networks such as cellular networks, metropolitan area networks (MANs), satellite communication networks, etc., in various embodiments.

FIG.1is a block diagram of an example wireless local area network (WLAN)110, according to an embodiment. The WLAN110includes an access point (AP)114that comprises a host processor118coupled to a network interface device122. The network interface122includes a medium access control (MAC) processor126and a physical layer (PHY) processor130. The PHY processor130includes a plurality of transceivers134, and the transceivers134are coupled to a plurality of antennas138. Although three transceivers134and three antennas138are illustrated inFIG.1, the AP114includes other suitable numbers (e.g., 1, 2, 4, 5, etc.) of transceivers134and antennas138in other embodiments. In some embodiments, the AP114includes a higher number of antennas138than transceivers134, and antenna switching techniques are utilized.

The network interface122is implemented using one or more integrated circuits (ICs) configured to operate as discussed below. For example, the MAC processor126may be implemented, at least partially, on a first IC, and the PHY processor130may be implemented, at least partially, on a second IC. As another example, at least a portion of the MAC processor126and at least a portion of the PHY processor130may be implemented on a single IC. For instance, the network interface122may be implemented using a system on a chip (SoC), where the SoC includes at least a portion of the MAC processor126and at least a portion of the PHY processor130.

In an embodiment, the host processor118includes a processor configured to execute machine readable instructions stored in a memory device (not shown) such as a random access memory (RAM), a read-only memory (ROM), a flash memory, etc. In an embodiment, the host processor118may be implemented, at least partially, on a first IC, and the network device122may be implemented, at least partially, on a second IC. As another example, the host processor118and at least a portion of the network interface122may be implemented on a single IC.

In various embodiments, the MAC processor126and/or the PHY processor130of the AP114are configured to generate data units, and process received data units, that conform to a WLAN communication protocol such as a communication protocol conforming to the IEEE 802.11 Standard or another suitable wireless communication protocol. For example, the MAC processor126may be configured to implement MAC layer functions, including MAC layer functions of the WLAN communication protocol, and the PHY processor130may be configured to implement PHY functions, including PHY functions of the WLAN communication protocol. For instance, the MAC processor126may be configured to generate MAC layer data units such as MAC service data units (MSDUs), MAC protocol data units (MPDUs), etc., and provide the MAC layer data units to the PHY processor130. The PHY processor130may be configured to receive MAC layer data units from the MAC processor126and encapsulate the MAC layer data units to generate PHY data units such as PHY protocol data units (PPDUs) for transmission via the antennas138. Similarly, the PHY processor130may be configured to receive PHY data units that were received via the antennas138, and extract MAC layer data units encapsulated within the PHY data units. The PHY processor130may provide the extracted MAC layer data units to the MAC processor126, which processes the MAC layer data units.

In connection with generating one or more radio frequency (RF) signals for transmission, the PHY processor130is configured to process (which may include modulating, filtering, etc.) data corresponding to a PPDU to generate one or more digital baseband signals, and convert the digital baseband signal(s) to one or more analog baseband signals, according to an embodiment. Additionally, the PHY processor130is configured to upconvert the one or more analog baseband signals to one or more RF signals for transmission via the one or more antennas138.

In connection with receiving one or more signals RF signals, the PHY processor130is configured to downconvert the one or more RF signals to one or more analog baseband signals, and to convert the one or more analog baseband signals to one or more digital baseband signals. The PHY processor130is further configured to process (which may include demodulating, filtering, etc.) the one or more digital baseband signals to generate a PPDU.

The PHY processor130includes amplifiers (e.g., a low noise amplifier (LNA), a power amplifier, etc.), a radio frequency (RF) downconverter, an RF upconverter, a plurality of filters, one or more analog-to-digital converters (ADCs), one or more digital-to-analog converters (DACs), one or more discrete Fourier transform (DFT) calculators (e.g., a fast Fourier transform (FFT) calculator), one or more inverse discrete Fourier transform (IDFT) calculators (e.g., an inverse fast Fourier transform (IFFT) calculator), one or more modulators, one or more demodulators, etc.

The PHY processor130is configured to generate one or more RF signals that are provided to the one or more antennas138. The PHY processor130is also configured to receive one or more RF signals from the one or more antennas138.

The MAC processor126is configured to control the PHY processor130to generate one or more RF signals by, for example, providing one or more MAC layer data units (e.g., MPDUs) to the PHY processor130, and optionally providing one or more control signals to the PHY processor130, according to some embodiments. In an embodiment, the MAC processor126includes a processor configured to execute machine readable instructions stored in a memory device (not shown) such as a RAM, a read ROM, a flash memory, etc. In an embodiment, the MAC processor126includes a hardware state machine.

The WLAN110includes a plurality of client stations154. Although three client stations154are illustrated inFIG.1, the WLAN110includes other suitable numbers (e.g., 1, 2, 4, 5, 6, etc.) of client stations154in various embodiments. The client station154-1includes a host processor158coupled to a network interface device162. The network interface162includes a MAC processor166and a PHY processor170. The PHY processor170includes a plurality of transceivers174, and the transceivers174are coupled to a plurality of antennas178. Although three transceivers174and three antennas178are illustrated inFIG.1, the client station154-1includes other suitable numbers (e.g., 1, 2, 4, 5, etc.) of transceivers174and antennas178in other embodiments. In some embodiments, the client station154-1includes a higher number of antennas178than transceivers174, and antenna switching techniques are utilized.

The network interface162is implemented using one or more ICs configured to operate as discussed below. For example, the MAC processor166may be implemented on at least a first IC, and the PHY processor170may be implemented on at least a second IC. As another example, at least a portion of the MAC processor166and at least a portion of the PHY processor170may be implemented on a single IC. For instance, the network interface162may be implemented using an SoC, where the SoC includes at least a portion of the MAC processor166and at least a portion of the PHY processor170.

In an embodiment, the host processor158includes a processor configured to execute machine readable instructions stored in a memory device (not shown) such as a RAM, a ROM, a flash memory, etc. In an embodiment, the host processor158may be implemented, at least partially, on a first IC, and the network device162may be implemented, at least partially, on a second IC. As another example, the host processor158and at least a portion of the network interface162may be implemented on a single IC.

In various embodiments, the MAC processor166and the PHY processor170of the client station154-1are configured to generate data units, and process received data units, that conform to the WLAN communication protocol or another suitable communication protocol. For example, the MAC processor166may be configured to implement MAC layer functions, including MAC layer functions of the WLAN communication protocol, and the PHY processor170may be configured to implement PHY functions, including PHY functions of the WLAN communication protocol. The MAC processor166may be configured to generate MAC layer data units such as MSDUs, MPDUs, etc., and provide the MAC layer data units to the PHY processor170. The PHY processor170may be configured to receive MAC layer data units from the MAC processor166and encapsulate the MAC layer data units to generate PHY data units such as PPDUs for transmission via the antennas178. Similarly, the PHY processor170may be configured to receive PHY data units that were received via the antennas178, and extract MAC layer data units encapsulated within the PHY data units. The PHY processor170may provide the extracted MAC layer data units to the MAC processor166, which processes the MAC layer data units.

The PHY processor170is configured to downconvert one or more RF signals received via the one or more antennas178to one or more baseband analog signals, and convert the analog baseband signal(s) to one or more digital baseband signals, according to an embodiment. The PHY processor170is further configured to process the one or more digital baseband signals to demodulate the one or more digital baseband signals and to generate a PPDU. The PHY processor170includes amplifiers (e.g., an LNA, a power amplifier, etc.), an RF downconverter, an RF upconverter, a plurality of filters, one or more ADCs, one or more DACs, one or more DFT calculators (e.g., an FFT calculator), one or more IDFT calculators (e.g., an IFFT calculator), one or more modulators, one or more demodulators, etc.

The PHY processor170is configured to generate one or more RF signals that are provided to the one or more antennas178. The PHY processor170is also configured to receive one or more RF signals from the one or more antennas178.

The MAC processor166is configured to control the PHY processor170to generate one or more RF signals by, for example, providing one or more MAC layer data units (e.g., MPDUs) to the PHY processor170, and optionally providing one or more control signals to the PHY processor170, according to some embodiments. In an embodiment, the MAC processor166includes a processor configured to execute machine readable instructions stored in a memory device (not shown) such as a RAM, a ROM, a flash memory, etc. In an embodiment, the MAC processor166includes a hardware state machine.

In an embodiment, each of the client stations154-2and154-3has a structure that is the same as or similar to the client station154-1. Each of the client stations154-2and154-3has the same or a different number of transceivers and antennas. For example, the client station154-2and/or the client station154-3each have only two transceivers and two antennas (not shown), according to an embodiment.

PPDUs are sometimes referred to herein as packets. Multiple MPDUs may be aggregated to generate aggregated-MPDUs (A-MPDU) for transmission in a PPDU. Multiple MSDUs may be aggregated to generate aggregated-MSDUs (A-MSDUs) for transmission in an MPDU. MPDUs are sometimes referred to herein as frames.

FIG.2is a diagram of a physical layer (PHY) data unit200that the network interface122(FIG.1) is configured to generate and transmit to one or more client stations154, according to an embodiment. The network interface162(FIG.1) may also be configured to transmit PHY data units the same as or similar to the PHY data unit200to the AP114. The PHY data unit200may occupy a 20 MHz bandwidth or another suitable bandwidth. PHY data units similar to the PHY data unit200occupy other suitable bandwidths such as 40 MHz, 80 MHz, 160 MHz, 320 MHz, 640 MHz, for example, or other suitable bandwidths, in other embodiments.

The PHY data unit200includes a preamble202including a legacy short training field (L-STF)205, a legacy long training field (L-LTF)210, a legacy signal field (L-SIG)215, a repeated L-SIG field (RL-SIG)218, a high efficiency (HE) signal-A field (HE-SIG-A)220, an HE signal-B field (HE-SIG-B)225, an HE short training field (HE-STF)225, and M HE long training fields (HE-LTFs)230, where M is a suitable positive integer. In an embodiment, M generally corresponds to (e.g., is greater than or equal to) a number of spatial streams via which the PHY data unit200will be transmitted. A legacy preamble portion245of the preamble202includes the L-STF205, L-LTF210and L-SIG215. An HE preamble portion250of the preamble202includes the RL-SIG218, the HE-SIG-A220, the HE-SIG-B225, the HE-STF230and the M HE-LTFs235. The PHY data unit200also includes a PHY data portion240and a packet extension (PE) field242. The PHY data portion240includes one or more MPDUs, MSDUs, an aggregate MPDU (A-MPDU), etc. In some scenarios, the PHY data unit200may omit the PHY data portion240. In some embodiments, the PHY data unit200may omit one or more fields corresponding to the preamble202. In some embodiments, the preamble202includes additional fields not illustrated inFIG.2.

Each of the L-STF205, the L-LTF210, the L-SIG215, the RL-SIG218, the HE-SIG-A220, the HE-SIG-B225, the HE-STF230, the M HE-LTFs235, and the data portion240comprises one or more orthogonal frequency division multiplexing (OFDM) symbols. As merely an illustrative example, the HE-SIG-A220comprises two OFDM symbols.

In the illustration ofFIG.2, the PHY data unit200includes one of each of the L-STF205, the L-LTF210, the L-SIG215, the RL-SIG218and the HE-SIG-A220. In some embodiments in which a PHY data unit similar to the PHY data unit200occupies a cumulative bandwidth other than 20 MHz, each of the L-STF205, the L-LTF210, the L-SIG215, the RL-SIG218, and the HE-SIG-A220is repeated over a corresponding number of 20 MHz sub-bands of the whole bandwidth of the PHY data unit, in an embodiment. For example, in an embodiment in which the PHY data unit occupies an 80 MHz bandwidth, the PHY data unit200includes four of each of the L-STF205, the L-LTF210, the L-SIG215, the RL-SIG218, and the HE-SIG-A220.

In an embodiment, the HE-SIG-A220generally carries information about the format of the PHY data unit200, such as information needed to properly decode at least a portion of the PHY data unit200, in an embodiment. In some embodiments, HE-SIG-A220additionally includes information for receivers that are not intended receivers of the PHY data unit200, such as information needed for medium protection, spatial reuse, etc. In an embodiment where the PHY data unit200is a single user (SU) PHY data unit transmitted to/from a single client station, the PHY data unit200does not include an HE-SIG-B field225.

In an embodiment, the PHY data unit200is a multi-user (MU) orthogonal frequency division multiple access (OFDMA) data unit in which independent data streams are transmitted to/from multiple client stations154using respective sets of OFDM tones allocated to the client stations154. For example, in an embodiment, available OFDM tones (e.g., OFDM tones that are not used as DC tone and/or guard tones) are segmented into multiple resource units (RUs), and each of the multiple RUs is allocated to transmissions to one or more client stations154. In an embodiment, the independent data streams in respective allocated RUs are further transmitted using respective spatial streams, allocated to the client stations154, using multiple-input multiple-output (MIMO) techniques. In an embodiment, the PHY data unit200is an MU-MIMO data unit in which independent data streams are transmitted to/from multiple client stations154using respective spatial streams, allocated to the client stations154.

In an embodiment, the HE-SIG-B225is present when the PHY data unit200is an MU data unit (e.g., OFDMA data unit, MU-MIMO data unit). In an embodiment, the HE-SIGB224indicates RU and/or spatial stream allocation configuration for multiple client stations154.

The PE field242is optionally appended to the end of the PHY data unit200to provide a receiver device with additional processing time at the end of reception of the PHY data unit200.

In some embodiments, the data portion240includes a communication frame, such as a QoS data frame, an acknowledgment frame, a BA frame, etc. As discussed above, a QoS data frame is a communication frame that includes i) data being conveyed to another device, and ii) QoS information, regarding the data, in a MAC header of the communication frame. In an embodiment, the QoS information includes a traffic identifier (TID) that indicates a traffic category (TC) or traffic stream (TS) to which the frame belongs. In an embodiment, a TC indicates a relative priority of a frame. In an embodiment, a TS is a set of MSDUs to be delivered subject to a particular set of QoS parameter values.

A first communication device that receives one or more QoS data frames (e.g., one or more MPDUs included in one or more PHY data units such as the data unit200) from a second communication devices may acknowledge the reception of the QoS data frames by transmitting an acknowledgment frame to the second communication device. In an embodiment, the acknowledgment frame may be a block acknowledgment (BA) frame acknowledging the reception of multiple QoS data frames from one or more second communication devices. In an embodiment, the acknowledgment frame may be a multi-station (multi-STA) BA frame acknowledging the reception of multiple QoS data frames transmitted by the second communication device and one or more third communication devices within a MU uplink data unit (e.g., using OFDMA and/or MU-MIMO).

In some embodiments, communication devices negotiate parameters of a BA session prior to participating in the BA session, where a BA frame is employed to acknowledge multiple QoS data frames during the BA session. A communication device that has QoS data frames to transmit and is requesting a BA session is referred to herein as an “originator”, and a communication device that is to receive the QoS data frames and is responding to originator's request for the BA session is referred to herein as a “recipient”. The recipient will store QoS data frames received during the BA session in buffers prior to transmitting a BA frame. Thus, as an example, the originator requests, as part of the negotiation, a number of buffers for the recipient to use during the BA session based on a number of QoS data frames that the originator has to transmit, according to an embodiment. Similarly, the recipient may not have the requested amount of buffers available, and thus the recipient may specify that the recipient is able to utilize a number of buffers during the BA session that is smaller than the requested number, according to an embodiment.

In an embodiment, the recipient indicates which QoS data frames were successfully received during the BA session with a bitmap. In an embodiment, a communication protocol permits the use of different length bitmaps selected from a set of allowable bitmap lengths. Thus, as another example, the originator requests, as part of the negotiation, a bitmap length for the recipient to use during the BA session based on a number of QoS data frames that the originator has to transmit, according to an embodiment. Similarly, the recipient may not be capable of using the requested bitmap length, and thus the recipient may specify that the recipient is able to utilize a bitmap length that is smaller than the requested length, according to an embodiment.

FIG.3is a timing diagram of an example frame exchange300corresponding to a BA session between different communication devices. Originator302and recipient304correspond to respective communication devices in a WLAN (e.g., the AP114or the client station154in the WLAN110). As an example, the originator302corresponds to the client station154-1and the recipient304corresponds to the AP114. As another example, the originator302corresponds to the AP114or the client station154-1, and the recipient304corresponds to the client station154-2. In other embodiments, the originator302and/or the recipient304are other suitable communication devices.

The frame exchange300includes at least a setup portion306and a data transfer and acknowledgment portion308. The setup portion306corresponds to a negotiation of a BA agreement between the originator302and the recipient304. The data transfer and acknowledgment portion308corresponds to transmission of QoS data frames from the originator302and transmission of a BA from the recipient304in accordance with the negotiated BA agreement. The frame exchange may include a plurality of data transfer and acknowledgment portions308.

The originator generates and transmits an add block acknowledgment (ADDBA) request frame310to the recipient to initiate a BA session between the originator302and the recipient304. The ADDBA request frame310corresponds to a request, by the originator302, to participate in a BA procedure with the recipient, and includes information that is used to negotiate the BA agreement between the originator302and the recipient304. For instance, in an embodiment, the ADDBA request frame310includes an indication of a number of buffers requested to be allocated at the recipient304to buffer QoS data frames to be transmitted by the originator302during the data transfer and acknowledgment portion308. In an embodiment, the number of buffers requested is determined based on a number of QoS data frames that the originator302is to transmit during the data transfer and acknowledgment portion308.

In response to reception of the ADDBA request frame310, the recipient generates and transmits an acknowledgment frame315to the originator302acknowledging the reception of the ADDBA request frame310.

The AP114generates and transmits an ADDBA response frame320responding to the ADDBA request frame310. The ADDBA response frame320can either accept or reject the request to participate in the BA session with the originator302, according to an embodiment. If the ADDBA response frame320accepts the request to participate in the BA session, the ADDBA response frame320includes information for negotiating the BA agreement with the originator302. For instance, in an embodiment, the ADDBA response frame320includes an indication of a number of buffers allocated at the recipient304for buffering QoS data frames transmitted by the originator302during the data transfer and acknowledgment portion308.

In an embodiment, the allocated number of buffers indicated in the ADDBA response frame320may be different than the number of buffers indicated in the ADDBA request frame310. In one such embodiment, to account for the difference, the originator302may adjust a number of QoS data frames the originator302will transmit prior to expecting a BA from the recipient304. In an embodiment, the number of QoS data frames to be transmitted prior to expecting a BA from the recipient304is referred to as a “transmission window size”.

In response to the reception of the ADDBA response frame320, the originator302generates and transmits an acknowledgment frame325to the AP114acknowledging the reception of the ADDBA response frame320.

Data transmission from the originator302to the recipient304occurs during the data transfer and acknowledgment portion308. The originator302transmits multiple QoS data frames330(e.g., QoS data frames330-1,330-2. . .330-N) to the recipient304. In an embodiment, the number of QoS data frames330transmitted by the originator302prior to receiving a BA corresponds to the allocated number of buffers at the recipient304. In an embodiment, the one or more QoS data frames330are transmitted by the client station154as an SU transmission from the client station154to the AP114. In another embodiment, the one or more QoS data frames330are transmitted by the client station154as part of an uplink (UL) MU transmission including one or more other data frames (not shown) from one or more of the other client stations154. In an embodiment, the MU transmission is transmitted by the client stations154in response to a trigger frame (not shown) transmitted by the AP114. In an embodiment, the one or more QoS data frames330are transmitted by the AP114as an SU transmission to the client station154. In an embodiment, the one or more QoS data frames330are transmitted by the AP114to the client station154within a downlink MU transmission.

In an embodiment, the QoS data frames330correspond to multiple MPDUs. In various embodiments, the multiple MPDUs330are transmitted in multiple PPDUs or within a single PPDU (e.g., within an A-MPDU in the single PPDU).

Following the reception of the one or more QoS data frames330, the recipient304transmits a BA frame335to the originator302to acknowledge the reception of at least some of the QoS data frames330. The BA frame335indicates whether each of the QoS data frames330was successfully received at the recipient. In an embodiment in which the QoS data frames330are transmitted by the client station154as part of an uplink MU transmission including one or more other data frames from one or more of the other client station154, the BA frame335is a multi-STA BA frame acknowledging the reception of the one or more QoS data frames330and the one or more other QoS data frames. In an embodiment where the one or more QoS data frames330are transmitted by the client station154as part of an SU transmission, the BA frame335is a compressed block acknowledgment (C-BA) frame indicating whether the one or more QoS data frames330were successfully received at the AP114. In an embodiment, the BA frame335is transmitted in response to a block acknowledgment request (BAR) frame (not shown) transmitted by the client station154.

FIG.4Ais a diagram of an example format of a frame400used for negotiating a BA agreement between two communication devices, according to an embodiment. In an embodiment, the frame400corresponds to an MPDU as generated by a MAC processor of a communication device. Referring now toFIG.3, the ADDBA request frame310and/or the ADDBA response frame320have the format400, according to some embodiments. In an embodiment, the frame400is generated by the MAC processor126of the network interface122. In another embodiment, the frame400is generated by the MAC processor166of the network interface162.FIG.4Aindicates example lengths (e.g., in terms of octets) of fields of the frame400. In other embodiments, length(s) one or more of the fields has another suitable number length(s). In some embodiments, one or more of the fields are omitted and/or one or more additional fields are included in the frame400.

The frame400includes a frame control field402, a duration field404, a receiver address (RA) field406, a transmitter address (TA) field408, a basic service set identifier (BSSID) field410, a sequence control field412, a high throughput (HT) control field414, a frame body416, and a frame check sequence (FCS) field418.

The frame control field402includes information that identifies a type of the frame400and/or a function corresponding to the frame400. For instance, in an embodiment corresponding to the IEEE 802.11 Standard, the frame control field includes information that indicates that the frame400is a management frame. The duration field404includes information that indicates a length of a transmit opportunity period (TXOP) during which a particular communication frame exchange will take place, in an embodiment. For instance, in an embodiment wherein the frame400includes an ADDBA request frame310, the duration field404includes an indication of an estimated time required for the transmission of the acknowledgment frame315(including any interframe space between the ADDBA request frame310and the acknowledgment frame315). The RA field406includes an address corresponding to a target recipient (e.g., the recipient304) of the frame400. The TA field408includes an address corresponding to a transmitter (e.g., the originator304) of the frame400. The BSSID field410includes an identifier of a BSS corresponding to the frame400. The sequence control field412includes an identifier assigned to information included in the frame body. For example, in an embodiment, the sequence control field includes a sequence number that is assigned to an MSDU or an A-MSDU included in the frame body416. The HT control field414, if present, may include different types of control information corresponding to the frame400. The frame body416includes one or more frames. For instance, in an embodiment, the frame body416includes the ADDBA request frame310or the ADDBA response frame320as discussed above with reference toFIG.3. The FCS field416includes an error detecting code that enables a receiving device to determine whether the frame400was received without any errors.

FIG.4Bis a diagram of an example format of a frame body portion420of an ADDBA request frame. In an embodiment, the frame body portion420is included in the frame body416(FIG.4A). In an embodiment, the frame body portion420is generated by the MAC processor126of the network interface122. In another embodiment, the frame body portion420is generated by the MAC processor166of the network interface162. In some embodiments, one or more of the fields are omitted and/or one or more additional fields are included in the frame body portion420.

The frame body portion420includes a category field402, a BA action field424, a dialog token field426, a BA parameter set field428, a BA timeout value field430, a BA starting sequence control field432, a groupcast with retries (GCR) group address element434, a multi-band field436, and an ADDBA extension element438.

The category field422includes information that identifies the frame400as a frame corresponding to a BA session. The BA action field424includes information that specifically identifies the frame400as an ADDBA request frame. For example, a value of 0 in the BA action field424as the frame400as an ADDBA request frame. The dialog token field426includes a non-zero value as set by a communication device transmitting the ADDBA request frame and is used to match a response frame (e.g., the ADDBA response frame320as illustrated inFIG.3) to the ADDBA request frame. The BA parameter set field428is used to signal parameters for setting up the BA agreement. The BA timeout value field430includes information indicating a duration after which a BA setup is terminated if no frame exchanges occur. The BA starting sequence control field432includes information indicating an identifier of a first communication frame to be transmitted under the BA agreement. For instance, in an embodiment, the sequence number corresponding to a first communication frame to be transmitted (e.g., a first MSDU of the data frame330-1as described above with reference toFIG.3) under the BA agreement. The GCR group address element434indicates a group address of communication devices for which the BA agreement is being requested. The multi-band field436includes information indicating a frequency band for which the BA agreement is being negotiated and for which the ADDBA request frame applies. The ADDBA extension element438may include other information, such as information regarding whether MSDU fragmentation is allowable under the BA agreement.

FIG.4Cis a diagram of an example format of a frame body portion420of an ADDBA response frame. In an embodiment, the frame body portion420is included in the frame body416(FIG.4A). In an embodiment, the frame body portion440is generated by the MAC processor126of the network interface122. In another embodiment, the frame body portion440is generated by the MAC processor166of the network interface162. In some embodiments, one or more of the fields are omitted and/or one or more additional fields are included in the frame body portion440.

The frame body portion440includes a category field442, a BA action field444, a dialog token field446, a status code field448, a BA parameter set field450, a BA timeout value field452, a GCR group address element454, a multi-band element456, and an ADDBA extension element458.

The category field442includes information that identifies the frame400as a frame corresponding to the BA mechanism. The BA action field444includes information that specifically identifies the frame400as an ADDBA response frame. For example, a value of 1 in the BA action field424identifies the frame400as an ADDBA response frame. The dialog token field446includes a value copied from the dialog token field of a corresponding ADDBA request frame (e.g., the dialog toke field426of the ADDBA request frame) and is used to match the ADDBA response frame to the corresponding ADDBA request frame. The status code field448indicates whether the corresponding ADDBA request frame was successful in negotiating the BA agreement. The BA parameter set field450is used to signal parameters for setting up the BA agreement. The BA timeout value field452includes information indicating a duration after which the BA setup is terminated if no frame exchanges occur. The GCR group address element454indicates the group address of the communication devices for which the BA agreement is being requested. The multi-band element456includes information indicating a frequency band for which the BA agreement is being negotiated and for which the ADDBA response frame applies. The ADDBA extension element458may include other information, such as information regarding whether MSDU fragmentation is allowable under the BA agreement.

FIG.4Dis a diagram of an example format of the BA parameter set field460, in an embodiment, as included in the ADDBA request frame310and the ADDBA response frame320. In an embodiment, the BA parameter set field460corresponds to the BA parameter set field428(FIG.4B) and/or to the BA parameter set field450(FIG.4C).FIG.4Dindicates example lengths (e.g., in terms of bits) of subfields of the BA parameter set field460. In other embodiments, length(s) one or more of the subfields has another suitable number length(s). In some embodiments, one or more of the subfields are omitted and/or one or more additional subfields are included in the BA parameter set field460.

The BA parameter set field460includes an A-MSDU supported subfield462, a BA policy subfield464, a TID subfield466, and a buffer size subfield468.

The A-MSDU subfield462includes a value that indicates whether a communication device (e.g., the AP114or the client station154) supports the transmission and reception of A-MSDUs (e.g., among the QoS data frames330) under the BA agreement. The BA policy subfield464includes a value that indicates an ACK policy (e.g., immediate BA, delayed BA, etc.) corresponding to the QoS data frames330. The TID subfield466includes a value that identifies the traffic category (TC) or traffic stream (TS) corresponding to the negotiated BA agreement regarding the QoS data frames330. When the BA parameter set field460corresponds to the ADDBA request frame310, the buffer size subfield468includes a value that indicates the number of buffers requested to be allocated at the recipient304to buffer the QoS data frames330, corresponding to the TC/TS identified in the TID subfield466, transmitted by the originator302during the data transfer and acknowledgment portion308. The Buffer Size field468in the ADDBA request frame310also specifies a requested BA bitmap length in a C-BA frame. When a value of the Buffer Size field468is no more than 64, the requested BA bitmap length in the C-BA frame is 64; and when the value of the Buffer Size field468is more than 64 but less than 256, the requested BA bitmap length in the C-BA frame is 256, according to an embodiment. When the BA parameter set field460corresponds to the ADDBA response frame320, the buffer size subfield468includes a value that indicates the number of buffers that the recipient304has allocated to buffer the QoS data frames330, corresponding to the TC/TS identified in the TID subfield466, to be transmitted by the originator302during the data transfer and acknowledgment portion308. The Buffer Size field468in the ADDBA response frame320also specifies an allowed BA bitmap length in the C-BA frame. When a value of the Buffer Size field468is no more than 64, the allowed BA bitmap length in C-BA is 256; and when the value of the Buffer Size field468is more than 64 but less than 256, the allowed BA bitmap length in the C-BA frame is 256, according to an embodiment. In prior art systems, the number of data frames330in an A-MPDU soliciting a multi-station BA that may be transmitted in the data transfer and acknowledgment portion308, corresponding to the TC or TS as indicated in the TID subfield466, may be less than the number of buffers allocated at the recipient for an A-MPDU that solicits a C-BA. Accordingly, the allowed BA bitmap in multi-station BA may be less than the allowed BA bitmap in C-BA.

FIG.5is a diagram of an example format of a BAR frame500used for requesting a BA frame from one or more communication devices, according to an embodiment. Referring now toFIG.3, the BAR frame500may be transmitted by the originator302to solicit the BA frame335from the recipient. In an embodiment, the BAR frame500is generated by the MAC processor126of the network interface122. In an embodiment, the BAR frame500is generated by the MAC processor166of the network interface162.FIG.5indicates example lengths (e.g., in terms of octets) of fields of the BAR frame500. In other embodiments, length(s) one or more of the fields has another suitable number length(s). In some embodiments, one or more of the fields are omitted and/or one or more additional fields are included in the BAR frame500.

The BAR frame500includes a frame control field502, a duration field504, an RA field506, a TA field508, a BAR control field412, a BAR information field512, and a frame check sequence (FCS) field514.

The frame control field502includes information that identifies frame500as a BAR frame. For instance, in an embodiment corresponding to the IEEE 802.11 Standard, the frame control field502includes information that indicates that the frame500is a control frame corresponding to a BAR. The duration field504includes information that indicates a length of a TXOP during which a particular frame exchange will take place, in an embodiment. For instance, in an embodiment, the duration field504includes an indication of an estimated time required for the transmission of the BAR frame500and the BA frame (e.g., the BA frame335) that is solicited by the BAR frame500(including any interframe space between the BAR frame500and the BA frame). The RA field506includes an address corresponding to a target recipient (e.g., the recipient304) of the frame500. The TA field508includes an address corresponding to a transmitter (e.g., the originator302) of the frame500. The BAR control field510includes information that identifies a type of the BAR frame500. For instance, the BAR control field510identifies the BAR frame500as corresponding to a compressed-BAR (C-BAR) frame, or a multi-traffic identifier (multi-TID) BAR frame, etc. The BAR information field512indicates identification of data frames for which the BA is being solicited. For instance, in an embodiment, the BAR information field512indicates a sequence number corresponding to a first communication frame among the QoS data frames for which the BA is being solicited. The FCS field514includes an error detecting code that enables a receiving device to determine whether the frame500was received without any errors.

In an embodiment in which the BAR frame500corresponds to a multi-TID BAR frame, the BAR information field512further indicates TIDs corresponding to the QoS data frames330for which the BA is being solicited. In an embodiment in which the BAR frame500corresponds to a multi-TID BAR frame, the BAR frame500indicates TIDs corresponding to access categories (ACs) which have the same or higher priorities as compared to a current primary AC. In some embodiments, the BAR frame500indicates TIDs corresponding to all ACs irrespective of their priorities with respect to the current primary AC.

FIG.6Ais a diagram of an example format of a BA frame600, according to an embodiment. Referring now toFIG.3, the BA frame600may be transmitted by the recipient304to acknowledge transmissions (e.g., the one or more QoS data frames330(FIG.3), etc.) from the originator302. For instance, in an embodiment, the BA frame600corresponds to the BA frame335ofFIG.3. In an embodiment, the BA frame600is generated by the MAC processor126of the network interface122. In an embodiment, the BA frame600is generated by the MAC processor166of the network interface162.FIG.6Aindicates example lengths (e.g., in terms of octets) of fields of the BA frame600. In other embodiments, length(s) one or more of the fields has another suitable number length(s). In some embodiments, one or more of the fields are omitted and/or one or more additional fields are included in the BA frame600.

In an embodiment, the BA frame600is transmitted in response to a BAR frame (such as the BAR frame500). In another embodiment in which a BAR frame is not transmitted, the BA frame600is transmitted in response to reception of the data frames330with respective acknowledgment policy indicators (e.g., in a header portion) that indicate that an immediate acknowledgement or a BA frame is to be transmitted in response to the reception of the data frames.

The BA frame600includes a frame control field602, a duration field604, an RA field606, a TA field608, a BA control field612, a BA information field612, and a frame check sequence (FCS) field614.

The frame control field602includes information that identifies the frame600as a BA frame. For instance, in an embodiment corresponding to the IEEE 802.11 Standard, the frame control field602includes information that indicates that the frame600is a control frame corresponding to a BA frame. The duration field604includes information that indicates a length of a transmit opportunity period (TXOP) during which a particular frame transmission will take place, in an embodiment. For instance, in an embodiment, the duration field604includes an indication of an estimated time required for the transmission of the BA frame600. The RA field606includes an address corresponding to a target recipient (e.g., the originator302) of the frame600. The TA field608includes an address corresponding to a transmitter (e.g., the recipient304) of the frame600. The BA control field610includes information that identifies a BA variant corresponding to BA frame600. For instance, the BA control field610identifies the BA frame600as corresponding to a C-BA frame, a multi-TID BA frame, a multi-STA BA frame, etc. The BA information field612indicates identification of the QoS data frames330for which the BA is being transmitted and further indicates one or more acknowledgment bitmaps corresponding to acknowledgments of the QoS data frames330. The FCS field614includes an error detecting code that enables a receiving device to determine whether the frame600was received without any errors.

FIG.6Bis a diagram of an example format of a BA information field620, in an embodiment. In an embodiment, the BA information field620corresponds to the BA information field612(FIG.6A).FIG.6Bindicates example lengths (e.g., in terms of octets) of fields of the BA information field620. In other embodiments, length(s) one or more of the fields has another suitable number length(s). In some embodiments, one or more of the fields are omitted and/or one or more additional fields are included in the BA information field620.

The BA information field620includes a BA starting sequence control field622and a BA bitmap field624. In an embodiment, the BA information field620corresponds to a C-BA frame indicating whether a plurality of the QoS data frames330were successfully received at the recipient304.

The BA starting sequence control field622indicates identification of the QoS data frames330being acknowledged in the BA bitmap field624. For instance, BA starting sequence control field622indicates a sequence number corresponding to the first QoS data frame330-1(e.g., a sequence number corresponding to an MSDU of the first QoS data frame330-1) among the QoS data frames being acknowledged in the BA bitmap field624. The BA bitmap field624includes an acknowledgment bitmap that indicates whether the QoS data frames330were successfully received at the recipient304. In an embodiment, each bit of the acknowledgement bitmap indicates whether a corresponding QoS data frame330, or a fragment of the QoS data frame330, was successfully received at the recipient304, starting with the first QoS data frame330-1as indicated by the sequence number. For instance, each bit that is equal to 1 in an acknowledgment bitmap acknowledges the successful reception of a single QoS data frame330or a fragment thereof.

FIG.6Cis a diagram of an example format of a BA information field640in an embodiment. In an embodiment, the BA information field640corresponds to the BA information field612(FIG.6A).FIG.6Cindicates example lengths (e.g., in terms of octets) of fields of the BA information field640. In other embodiments, length(s) one or more of the fields has another suitable number length(s). In some embodiments, one or more of the fields are omitted and/or one or more additional fields are included in the BA information field640.

The BA information field640includes an association identifier (AID) TID information field642, a BA starting sequence control field644and a BA bitmap field646. In an embodiment, the BA information field640corresponds to a multi-STA BA frame indicating whether a plurality of the data frames330were successfully received at the recipient304.

The AID TID information field642includes the AID of the originator302and the TID of the QoS data frames330from the originator302being acknowledged in the BA bitmap field646. Contents of the BA sequence control field644and the BA bitmap field646are similar to contents of the BA sequence control field622and the BA bitmap field624, respectively, and are not discussed in detail for reasons of brevity. In an embodiment, the BA information field640is repeated, with each repetition including a corresponding BA bitmap field646acknowledging the reception of a set of QoS data frames corresponding to an AID, TID tuple.

In an embodiment, a communication protocol defines a set of different acknowledgment bitmap lengths that can be used during BA sessions (e.g., included in a BA bitmap field such as the BA bitmap field624). In various embodiments, a length of the acknowledgment bitmap that is to be included in the BA bitmap field (e.g., the BA bitmap field624, BA bitmap field646, etc.) is dependent on the number of buffers allocated at the recipient, as negotiated using ADDBA request and ADDBA response frames (e.g., the ADDBA request frame310, the ADDBA response frame320). For instance, an allocated number buffers falling within a particular range corresponds to a particular acknowledgment bitmap length or a subset of acknowledgment bitmap lengths, according to an embodiment.

As an illustrative example, a set of allowable bitmap lengths that can be negotiated (e.g., as defined by the communication protocol) is 64 bits, or 256 bits. If the allocated number of buffers is negotiated to be less than or equal to 64, the negotiated BA bitmap is 64 bit long and the BA bitmap field646(corresponding to the multi-STA BA frame) is permitted to have a length of 32 bits or 64 bits. As another example, if the allocated number of buffers is negotiated to be greater than 64, the negotiated BA bitmap is 256 bits long and the BA bitmap field646is permitted to be 32 bits long, 64 bits long, 128 bits long, or 256 bits long.

According to some embodiments, the communication protocol defines different sets of supported acknowledgment bitmap lengths for different variants of the BA frame (e.g., C-BA frame, multi-STA BA frame, etc.). In one embodiment of a communication protocol, the requested BA bitmap per the buffer number in an ADDBA Request and the allowed BA bitmap per the buffer number in an ADDBA Response is the bitmap length for a C-BA frame, whereas the bitmap length for a multi-STA BA is 64. In another embodiment of a communication protocol, the requested BA bitmap per the buffer number in an ADDBA Request and the allowed BA bitmap per the buffer number in an ADDBA Response is the bitmap length of a C-BA and the bitmap length of multi-STA BA.

In an embodiment, the set of supported acknowledgment bitmap lengths in the BA bitmap field646limits the number of QoS data frames330that may be transmitted, corresponding to a particular TID, by the originator302prior to expecting a BA frame from the recipient. In other words, the number of QoS data frames330that may be transmitted, corresponding to the particular TID, by the originator302, prior to expecting a BA frame, may not exceed a maximum supported acknowledgment bitmap length from the set of supported acknowledgment bitmap lengths. If the number of transmitted QoS data frames330exceeds the maximum supported acknowledgment bitmap length, it is possible that not all the transmitted QoS data frames330are acknowledged in the BA frame335.

Communication devices operating within the WLAN110may operate according to different versions of a communication protocol. In some embodiments, this may result in inconsistent selection of acknowledgment bitmap lengths across different communication devices operating within the WLAN110, at least when one or more BA frame variants are being used, e.g., when a multi-STA BA is being used. As merely an example, the client station154and the AP114may negotiate an allocated number of buffers at the AP114, and based on the allocated number of buffers, the AP114may select an acknowledgment bitmap length of 256 bits for both C-BA frames and multi-STA BA frames. However, the client station154may operate according to a version of the communication protocol that limits a length of the acknowledgement bitmap to 64 bits for multi-STA BA frames and does not support an acknowledgment bitmap that is 256 bits long for multi-STA BA frames (on the other hand, the version of the communication protocol may support an acknowledgment bitmap that is 256 bits long for C-BA frames), according to an embodiment. If the AP114transmits a multi-STA BA frame with the 256-bit acknowledgment bitmap to the client station154, the client station154may not be able to process the multi-STA BA frame correctly and/or encounter an error during processing of the multi-STA BA frame.

As another example, the client station154and the AP114may negotiate an allocated number of buffers at the AP114to be equal to250. However, the AP114may operate according to a version of the communication protocol that limits a length of the acknowledgement bitmap in multi-STA BA frames to 64 bits (on the other hand, the version of the communication protocol may support an acknowledgment bitmap that is 256 bits long for C-BA frames). However, the client station154may operate according to a version of the communication protocol that can accommodate a bitmap that is up to 256-bit long in both multi-STA BA frames and C-BA frames. Based on this, the client station154may transmit a number of QoS data frames330that exceeds a number of data frames (e.g., 250 frames corresponding to the allocated number of buffers at the AP114) that may be acknowledged in the BA bitmap field646of a multi-STA BA frame. This may result in at least some of the QoS data frames330being unacknowledged.

To ensure compatibility across different communication devices with differing processing capabilities with respect a length of a BA bitmap, information regarding the supported bitmap lengths may be exchanged prior to the data transfer and acknowledgment portion308. In an embodiment, the ADDBA request frame310and the ADDBA response frame320may include additional signaling information that is used to negotiate maximum supported acknowledgment bitmap lengths.

FIG.7Ais a diagram of an example format of an ADDBA extension element700in an embodiment. In an embodiment, the ADDBA extension element700corresponds to the ADDBA extension element438(FIG.4B) and/or to the ADDBA extension element458(FIG.4C).FIG.7Aindicates example lengths (e.g., in terms of octets) of fields of the ADDBA extension element700. In other embodiments, length(s) one or more of the subfields has another suitable number length(s). In some embodiments, one or more of the subfields are omitted and/or one or more additional subfields are included in the ADDBA extension element700.

The ADDBA extension element700includes an element identifier (ID) field702, a length field704, and an ADDBA capabilities field706.

The element ID field702includes a value that identifies the field700as an ADDBA extension element. The length field704specifies a number of octets that follows the length field704. The ADDBA capabilities field706includes other signaling information for negotiating the BA agreement and is described in more detail with reference toFIGS.7B and7C.

FIG.7Bis a diagram of an example format of an ADDBA capabilities field720in an embodiment. In an embodiment, the ADDBA capabilities field720corresponds to the ADDBA capabilities field706(FIG.7A).FIG.7Bindicates example lengths (e.g., in terms of bits) of subfields of the ADDBA capabilities field720. In other embodiments, length(s) one or more of the subfields has another suitable number length(s). In some embodiments, one or more of the subfields are omitted and/or one or more additional subfields are included in the ADDBA capabilities field720.

The ADDBA capabilities field720includes a no fragmentation subfield722, an HE fragmentation operation subfield724, a 256-bit bitmap in multi-STA BA subfield726, and a reserved subfield728.

The no fragmentation subfield722includes a value that is used to indicate whether a fragmented MSDU may be transmitted (for e.g., in the QoS data frames330) under the BA agreement. The HE fragmentation operation subfield724includes a value that indicates a level of dynamic fragmentation that is requested in ADDBA request or is allowed in ADDBA response for fragmented MSDUs under the BA agreement. The 256-bit bitmap in multi-STA BA subfield726indicates whether a 256-bit long acknowledgment bitmap (in a multi-STA BA frame) is requested in ADDBA request or is allowed in ADDBA response at a transmitter of the corresponding ADDBA request frame or the ADDBA response frame. In an embodiment, if the value in the Buffer Size468is more than 64, the BA bitmap length in a C-BA frame will be 256-bits long.

In an embodiment, if the 256-bit bitmap in multi-STA BA subfield726in an ADDBA request is not set to one, the 256-bit bitmap in multi-STA BA subfield726in a corresponding ADDBA response will not be set to one. In an embodiment, if the value in the Buffer Size field (not shown) in the ADDBA request/response frame is no more than 64, the 256-bit bitmap in multi-STA BA subfield726in ADDBA request/response cannot be set to one. In an embodiment, a client station or an AP announces whether the client station/AP supports the reception of 256-bit long acknowledgment bitmap in a multi-STA BA frame in an Extended Capabilities element. In an embodiment, when a peer device announces the peer device supports 256-bit long acknowledgment bitmap, the ADDBA request addressed to the peer STA can have a value one in the 256-bit bitmap in multi-STA BA subfield726.

For instance, if the client station154transmits the ADDBA request frame310(FIG.3) or the ADDBA response frame320(FIG.3) with the corresponding 256-bit bitmap in multi-STA BA subfield726set to 1, the client station154requests or allows, respectively, (e.g., may encode/generate/receive/decode) a 256-bit long acknowledgment bitmap in the BA bitmap field646of the BA information field640of a multi-STA BA frame. Similarly, if the AP114transmits the ADDBA request frame310(FIG.3) or the ADDBA response frame320(FIG.3) with the corresponding 256-bit bitmap in multi-STA BA subfield726set to 1, the AP114requests or allows, respectively, (e.g., may encode/generate/receive/decode) a 256-bit long acknowledgment bitmap in the BA bitmap field646of the BA information field640of a multi-STA BA frame.

If both the originator302and the recipient304set the 256-bit bitmap in multi-STA BA subfield726(e.g., in the ADDBA request/response) to one, the originator302may transmit up to 256 QoS data frames330for the negotiated TID in the data transfer and acknowledgment portion308(e.g., in a multi-TID A-MPDU, a single-TID A-MPDU in a high efficiency (HE) trigger-based (TB) PPDU, or other kinds of A-MPDUs that solicit multi-STA BAs) prior to receiving the multi-STA BA frame335. An HE TB PPDU is an uplink transmission that is triggered by a trigger frame received from another device, such as the AP114. In an embodiment, the number of data frames330that the originator302may transmit may be limited by a number of buffers allocated at the recipient304(e.g., as indicated by the buffer size subfield468).

In an embodiment wherein both the originator302and the recipient304set the 256-bit bitmap in multi-STA BA subfield726(e.g., in the ADDBA request/response) to one and negotiate a BA buffer size more than 64 (but no more than 256) for a TID, the originator302may transmit no more than 256 QoS Data frames for the TID in a multi-TID A-MPDU to the recipient304. Accordingly, the recipient304may generate and transmit the multi-STA BA frame335with acknowledgment bitmaps up to a length of 256 bits in the BA bitmap field646of the BA information field640. In an embodiment, the recipient304may also generate and transmit the multi-STA BA frame335with acknowledgment bitmaps of lengths 32 bits, 64 bits, and/or 128 bits in the BA bitmap field646of the BA information field640. In an embodiment wherein both the originator302and the recipient304set the 256-bit bitmap in multi-STA BA subfield726(e.g., in the ADDBA request/response) to one and negotiate a BA buffer size more than 64 (but no more than 256) for a TID, the originator302may transmit no more than 256 QoS Data frames for the TID in a single-TID A-MPDU in an HE TB PPDU to the recipient AP304. Accordingly, the recipient AP304may generate and transmit the multi-STA BA frame335with acknowledgment bitmaps up to a length of 256 bits in the BA bitmap field646of the BA information field640. In an embodiment, the recipient AP304may also generate and transmit the multi-STA BA frame335with acknowledgment bitmaps of lengths 32 bits, 64 bits, and/or 128 bits in the BA bitmap field646of the BA information field640.

If the originator302transmits an ADDBA request frame310(FIG.3) with the corresponding 256-bit bitmap in multi-STA BA subfield726set to 0, the originator302does not request (e.g., may not receive/decode) a 256-bit long acknowledgment bitmap in the multi-STA BA bitmap field646of the BA information field640and may only support acknowledgment bitmaps that are smaller in length (e.g., 32 bits, 64 bits, and/or 128 bits long). Similarly, if the recipient304transmits an ADDBA response frame320(FIG.3) with the corresponding 256-bit bitmap in multi-STA BA subfield726set to 0, the recipient304does not allow (e.g., may not encode/generate) a 256-bit long acknowledgment bitmap in the BA bitmap field646of the BA information field640in the multi-STA BA frame and may only support acknowledgment bitmaps that are smaller in length (e.g., 32 bits, 64 bits, and/or 128 bits long).

If one or both of the originator302and the recipient304do not set the 256-bit bitmap in multi-STA BA subfield726(e.g., in the ADDBA request/response) to one, the originator302may only transmit a maximum number of QoS data frames330from a TID in a multi-TID A-MPDU or single TID A-MPDU in HE TB PPDU, in the data transfer and acknowledgment portion308, corresponding to a next lower maximum supported length of the acknowledgment bitmap at both the originator302and the recipient304. Accordingly, the originator302adjusts its block acknowledgment transmission window within the data transfer and acknowledgment portion308, in an embodiment. For instance, if one or both of the originator302and the recipient304do not set the 256-bit bitmap in multi-STA BA subfield726(e.g., in the ADDBA request/response) to one, the originator302may transmit up to 64 QoS data frames330prior to expecting the BA frame335, in an embodiment. In an embodiment, the number of data frames330that the originator302may transmit may be limited by a number of buffers allocated at the recipient304(e.g., as indicated by the buffer size subfield468).

In an embodiment wherein one or both the originator302and the recipient304do not support a 256-bit long acknowledgment bitmap in the BA bitmap field646, the recipient304may generate and transmit the BA frame335(e.g., a multi-STA BA frame) with acknowledgment bitmaps up to a maximum length of 64 bits in the BA bitmap field646of the BA information field640.

Subfield728is reserved from use, in an embodiment.

In another embodiment, a maximum length of an acknowledgment bitmap (e.g. the acknowledgment bitmap in the BA bitmap field646) in a multi-STA BA is different from a maximum BA bitmap length in a C-BA may be signaled in the ADDBA request frame310and/or the ADDBA response frame320as a function of a maximum number of buffers defined by the communication protocol and the value in Buffer size subfield468.FIG.7Cis a diagram of an example format of an ADDBA capabilities field740, in an embodiment. In an embodiment, the ADDBA capabilities field740corresponds to the ADDBA capabilities field706(FIG.7A). The ADDBA capabilities field740is similar to the ADDBA capabilities field720, and like-numbered subfields are not discussed in detail for reasons of brevity.

Bitmap scaling factor in multi-STA BA subfield742includes a value that indicates a maximum supported length of the acknowledgment bitmap in multi-STA BAs as a number corresponding to a fraction of the maximum length of the acknowledgment bitmap for C-BAs which is defined by i) the communication protocol and ii) the value in the buffer size element468. For instance, the value may indicate 1, ½, ¼, ⅛, etc. In an embodiment in which the maximum number of buffers announced in the Buffer Size subfield468is more than 64, the maximum number of the acknowledgment bitmap in C-BA is 256. If the communication protocol allows a bitmap length of 256 in multi-STA BAs, a value of 1 in the bitmap scaling factor in multi-STA BA subfield742indicates that the maximum length of the acknowledgment bitmap corresponds to (for example, is equal to) the maximum number of buffers that may be allocated (e.g., 256 bits). A value of 2 in the bitmap scaling factor in multi-STA BA subfield742indicates that the maximum length of the acknowledgment bitmap in multi-STA BAs corresponds to (for example, is equal to) one half of the maximum number of buffers (e.g., 256) that may be allocated (e.g., 256/2=128 bits). A value of 0 indicates that the maximum length of the acknowledgment bitmap in multi-STA BAs is 64. In an embodiment, when the BA bitmap length in C-BA is 64 (e.g., when the value in Buffer Size468is no more than 64), the BA bitmap length in multi-STA BA is also 64, e.g., the bitmap scaling factor in multi-STA BA subfield742has value 0. In an embodiment, a station or an AP announces whether it supports the reception of 256-bit long acknowledgment bitmap in a multi-STA BA frame in the Extended Capabilities element. In an embodiment, when a peer device announces its support of 256-bit long acknowledgment bitmap, the ADDBA request/response addressed to the peer STA can have non-zero value in Bitmap scaling factor in multi-STA BA subfield742.

Based on the corresponding bitmap scaling factor in multi-STA BA subfields742in the ADDBA request frame310and the ADDBA response frame320, the client station154and the AP114negotiate a maximum length of an acknowledgment bitmap to be used in the multi-STA BA. In an embodiment, the negotiated maximum length of the acknowledgment bitmap in the multi-STA BA is set to be a maximum acknowledgment bitmap length that is announced at both the originator302and the recipient304. In an embodiment, the negotiated maximum length of the acknowledgment bitmap in multi-STA BA is set to be a maximum acknowledgment bitmap length that is allowed by the recipient304. In an embodiment, the negotiated maximum length of the acknowledgment bitmap in multi-STA BA is set to be a maximum acknowledgment bitmap length that is requested by the originator302.

The originator302transmits a number of QoS data frames330that is less than or equal to the negotiated maximum length of the acknowledgment bitmap prior to expecting a BA from the recipient304, according to an embodiment. In an embodiment, the originator302adjusts its block acknowledgment transmission window to transmit a number of QoS data frames330that is less than or equal to the negotiated maximum length of the acknowledgment bitmap prior to expecting a BA from the recipient304. The originator302may also adjust its BA transmission window within the data transfer and acknowledgment portion308based on the number of buffers allocated at the recipient304(e.g., as indicated by the buffer size subfield468), in an embodiment.

In an embodiment, the recipient304generates and transmits the BA frame335with an acknowledgment bitmap of a length that is less than or equal to the negotiated maximum length of the acknowledgment bitmap.

In an embodiment, supported acknowledgment bitmap lengths (e.g., a supported length of the acknowledgment bitmap in the BA bitmap field646) may be signaled prior to initiating the frame exchange300corresponding to the BA mechanism. For instance, the client station154and/or the AP114may announce their corresponding maximum supported acknowledgment bitmap lengths in a field of a data unit transmitted prior to initiating the frame exchange300. The maximum supported bitmap length may be included in a field of an extended capabilities element or an HE capabilities element. As merely an example, a 256-bit bitmap support in multi-STA BA frames subfield may be included in one or more of the above elements. A value of 1 in the 256-bit bitmap support in multi-STA BA frames field would indicate that the client station154and/or the AP114support an acknowledgment bitmap in multi-STA BA frames up to 256 bits long. As another example, a BA bitmap length subfield may be included in one or more of the above elements. In an embodiment, if the client station154and the AP114negotiate the BA bitmap length of C-BA is 256 and one of them announces no support of 256 BA bitmap in multi-STA BA, the A-MPDU which solicits multi-STA BA can't have more than 64 QoS Data frames from the related TID (the number of frames also under the restriction of Buffer Size, e.g., if Buffer Size468is 50, the frames in an A-MPDU for the related TID can't be more than 50). In an embodiment, if the client station154and the AP114negotiate the BA bitmap length of C-BA is 256 and they announce the support of 256 BA bitmap in multi-STA BA, the A-MPDU which solicits multi-STA BA can have more than 64 QoS Data frames from the related TID (and the BA bitmap for the related TID can be 256). The BA bitmap length in multi-STA BAs subfield may indicate supported acknowledgement bitmap lengths (e.g., 32 bits, 64 bits, 128 bits, and/or 256 bits). In an embodiment where the supported acknowledgment bitmap lengths are signaled prior to initiating the frame exchange300, the ADDBA request frame310and the ADDBA response frame320do not include the 256-bit bitmap in multi-STA BA subfield726and/or the bitmap scaling factor in multi-STA BA subfield742.

In an embodiment, a communication device selects, for the BA session, an acknowledgment bitmap that is shorter in length than a negotiated maximum length of an acknowledgment bitmap. For instance, with respect to the frame exchange300, if the negotiated maximum length of an acknowledgment bitmap in the BA frame335is 256 bits, and a number of the data frames330to be acknowledged is less than or equal to 64, the recipient304may determine that an acknowledgment bitmap of a length of 64 bits is sufficient to acknowledge reception of the data frames330. In such embodiments, the recipient304may determine a data rate and/or MCS to be used to generate the BA frame based on the negotiated maximum length of the acknowledgment bitmap, i.e., 256 bits.

The recipient304determines a duration of time required for transmission of the BA frame335, if the BA frame335was transmitted at a primary data rate/MCS and included an acknowledgment bitmap that has a length equal to the negotiated maximum length of the acknowledgment bitmap. In an embodiment, the primary data rate/MCS corresponds to a data rate/MCS used for transmission of the data frames330. The recipient then calculates a data rate/MCS required for transmission of the BA frame335with an acknowledgment bitmap that has a length less than the negotiated maximum length of the acknowledgment bitmap that would result in the BA frame335having the same duration of time. In an embodiment, this enables the AP114to reduce its data rate/MCS, thereby improving signal robustness of the transmitted BA frame335. In an embodiment, this also simplifies the design of the recipient304. For instance, the recipient304may simply assume that the remaining duration of the TXOP is long enough for transmission of the BA frame355, if the BA frame335was transmitted at a primary data rate/MCS and included an acknowledgment bitmap that has a length equal to the negotiated maximum length of the acknowledgment bitmap. In an embodiment, the above technique for determining a data rate/MCS required for transmission of a BA frame may be used for BA mechanisms different from those described above with respect toFIG.3.

In an embodiment, a single physical AP, such as the AP114, implements a plurality of virtual APs managing a plurality of basic service sets (BSSs), each BSS including a corresponding virtual AP and an associated set of one or more client stations, such as the client stations154. In one such embodiment, the AP114defines corresponding broadcast RUs for each virtual AP. A broadcast RU corresponding to a virtual AP is allocated for transmission of BA frames (such as the BA frame335) to the set of client stations154associated with the virtual AP. For instance, in an embodiment wherein the AP114implements two virtual APs, two corresponding broadcast RUs are used to transmit respective BA frames to client stations154associated with the corresponding virtual APs.

In an embodiment, the one or more QoS data frames330(FIG.3) are transmitted by the client station154as part of an UL MU transmission including one or more other data frames from one or more of the other client stations154. In another embodiment, the one or more one or more QoS data frames330are transmitted by the AP114as part of a downlink (MU) transmission including one or more other data frames to one or more of the other client stations154. In some embodiments, however, one or more of frames transmitted as part the above MU transmissions are management frames. In at least some such embodiments, the management frames are not aggregated with any other data frames and do not include any acknowledgment policy indication (e.g., in a corresponding MAC header field) to solicit an acknowledgment frame corresponding to the management frame. In such scenarios, when the management frame is i) transmitted to a client station (e.g., the client station154-1) as part of the DL MU transmission with other data frames to other client stations154, and ii) is not aggregated with any data frame in an A-MPDU, the client station154-1is not configured to transmit an acknowledgment frame to acknowledge the reception of the management frame. In some embodiments, the management frame may therefore be configured to include additional information to solicit the acknowledgment frame from the client station154to acknowledge the reception of the management frame.

FIG.8is a timing diagram of an example MU frame exchange800between an AP (such as the AP114) and multiple client stations (such as the client stations154). The frame exchange800is described in the context of the example WLAN110merely for explanatory purposes. In some embodiments, signals illustrated inFIG.8are generated by other suitable communication devices in other suitable types of wireless networks.

The MU frame exchange800includes a downlink (DL) transmission802followed by an UL MU transmission804, which includes acknowledgment frame from multiple client stations154. The DL transmission802corresponds to a HE MU PPDU transmission from a first communication device (e.g., the AP114) to a plurality of second communication devices (e.g., the client stations154). In an embodiment, the HE MU PPDU transmission corresponds to an OFDMA transmission including respective frames806transmitted to respective second communication devices. In an embodiment, the UL MU transmission804corresponds to an UL OFDMA transmission and/or an UL MU-MIMO transmission.

In an embodiment, respective frames806include respective MPDUs/A-MPDUs that are transmitted to respective client stations154in respective RUs. In an embodiment, one or more of the frames (e.g., frame806-1, frame806-3, and frame806-4) include data frames corresponding to the respective client stations154(e.g., STA1, STA3, and STA4). In an embodiment, at least one of the frames806(e.g., a frame806-2) corresponding to a client station154(e.g., STA2) includes a management frame that is not aggregated with any other data frame.

To enable STA2 to acknowledge the reception of the management frame806-2, the management frame806-2may be transmitted with a control field that includes information to trigger STA2 to transmit as part of the UL MU transmission804. In an embodiment, the management frame includes an UL MU response scheduling control field (e.g., in the HT control field414) that includes information to trigger STA2 to transmit as part of the UL MU transmission804. In an embodiment, an uplink multi-user response scheduling (UMRS) control field includes an allocated RU and an MCS to be used by STA2 for transmission, as part of the UL MU transmission804, of an acknowledgment frame to acknowledge the management frame806-2.

In another embodiment, the management frame806-2is aggregated, in an A-MPDU, with a trigger frame that includes information to trigger STA2 to transmit as part of the UL MU transmission804. In an embodiment, the trigger frame includes the allocated RU and the MCS to be used by STA2 to transmit as part of the UL MU transmission804. In an embodiment, the management frame in DL MU PPDU always solicits an acknowledgement through an HE TB PPDU.

The client station154that receives the management frame806-2then transmits an acknowledgment frame, as part of the UL MU transmission804, to acknowledge reception of the management frame806-2. In an embodiment, if the client station154receives the management frame806-2without UMRS, but doesn't receive the Trigger frame, the client station154will not respond with an ACK in an SU PPDU.

FIG.9is a flow diagram of an example method900for performing a block acknowledgment procedure, according to an embodiment. In some embodiments, the client station154(e.g., network interface device162) ofFIG.1is configured to implement the method900. The method900is described in the context of the client station154merely for explanatory purposes and, in other embodiments, the method900is implemented by another suitable device. For instance, in an embodiment, the AP114(e.g., the network interface device122) ofFIG.1is configured to implement the method900.

The method900is implemented in conjunction with the procedures, frame formats, etc., described above in connection with one or more ofFIGS.3,4A-4C,5,6A-6C,7A-7C, andFIG.8, in various embodiments. In other embodiments, the method900is implemented in conjunction with suitable procedures, frame formats, etc., different than those discussed above.

At block904, a first communication device generates (e.g., the originator302generates, the network interface device162generates, the MAC processor166generates, etc.) a first communication frame corresponding to a request to participate in a BA procedure. In an embodiment, the first communication frame is generated to include i) a first field that indicates a number of buffers requested to be allocated at a second communication device for buffering data units to be transmitted by the first communication device, and ii) a second field that indicates a first maximum bitmap length supported by the first communication device. In an embodiment, the first communication frame is an ADDBA request frame420as described above with respect toFIG.4B. In an embodiment, the first communication frame further includes one or more of the fields described with respect toFIGS.7A-7C.

At block908, the first communication device transmits (e.g., the originator302transmits, the network interface device162transmits, the PHY processor170transmits, etc.) the first communication frame to the AP114.

At block912, the first communication device receives (e.g., the originator302receives, the network interface device162receives, the PHY processor170receives, etc.) a second communication frame corresponding to a response to the request to participate in the BA procedure transmitted at bock908. In an embodiment, the second communication frame includes i) a third field indicating a number of buffers allocated at the second communication device for buffering the data units transmitted by the client station154, and ii) a fourth field indicating a second maximum bitmap length supported by the second communication device. In an embodiment, the second communication frame is an ADDBA response frame440as described above with respect toFIG.4C. In an embodiment, the second communication frame further includes one or more of the fields described with respect toFIGS.7A-7C.

At block916, the first communication device performs (e.g., the originator302performs, the network interface device162performs, the PHY processor170performs, the MAC processor166performs etc.) the BA procedure in accordance with the second bitmap length. For instance, in an embodiment, the originator302transmits a number of data frames to the recipient304based on the i) the number of buffers allocated at the recipient304and/or ii) the second maximum bitmap length.

FIG.10is a flow diagram of an example method1000corresponding to a block acknowledgment mechanism, according to an embodiment. In some embodiments, the AP114(e.g., the network interface device122) ofFIG.1is configured to implement the method1000. The method1000is described in the context of the client station154merely for explanatory purposes and, in other embodiments, the method1000is implemented by another suitable device. For instance, in an embodiment, the client station154(e.g., network interface device162) ofFIG.1is configured to implement the method1000.

The method1000is implemented in conjunction with the procedures, frame formats, etc., described above in connection with one or more ofFIGS.3,4A-4C,5,6A-6C,7A-7C, andFIG.8, in various embodiments. In other embodiments, the method1000is implemented in conjunction with suitable procedures, frame formats, etc., different than those discussed above.

At block1004, a first communication device receives (e.g., the recipient304receives, the network interface device122receives, the MAC processor126receives, the PHY processor130receives, etc.) a first communication frame corresponding to a request to participate in a BA procedure. In an embodiment, the first communication frame includes i) a first field indicating a number of buffers requested to be allocated at the first communication device for buffering the data units transmitted by a second communication device, and ii) a fourth field indicating a second maximum bitmap length supported by the second communication device. In an embodiment, the first communication frame is an ADDBA request frame420as described above with respect toFIG.4C. In an embodiment, the first communication frame further includes one or more of the fields described with respect toFIGS.7A-7C.

At block1008, the first communication device generates (e.g., the recipient304generates, the network interface device122generates, the MAC processor126generates, etc.) a second communication frame corresponding to a response to the request to participate in the BA procedure. In an embodiment, the second communication frame includes i) a third field indicating a number of buffers allocated at the first communication device for buffering the data units transmitted by the second communication device, and ii) a fourth field indicating a second maximum bitmap length supported by the first communication device. In an embodiment, the second communication frame is an ADDBA response frame440as described above with respect toFIG.4C. In an embodiment, the second communication frame further includes one or more of the fields described with respect toFIGS.7A-7C.

At block1012, the first communication device transmits (e.g., the recipient304transmits, the network interface device122transmits, the PHY processor130transmits, etc.) the second communication frame to the second communication device.

At block1016, the first communication device performs (e.g., the recipient304performs, the network interface device122performs, the MAC processor126performs, etc.) the BA procedure in accordance with the second maximum bitmap length. For instance, in an embodiment, the first communication device generates a BA frame with a bitmap of a length that is less than or equal to the second maximum bitmap length.

FIG.11is a flow diagram of an example method1100corresponding to a block acknowledgment mechanism, according to an embodiment. In some embodiments, the AP114(e.g., the network interface device122) ofFIG.1is configured to implement the method1100. The method1100is described in the context of the AP114merely for explanatory purposes and, in other embodiments, the method1100is implemented by another suitable device. For instance, in an embodiment, the client station154(e.g., network interface device162) ofFIG.1is configured to implement the method1100.

The method1100is implemented in conjunction with the procedures, frame formats, etc., described above in connection with one or more ofFIGS.3,4A-4C,5,6A-6C,7A-7C, andFIG.8, in various embodiments. In other embodiments, the method1100is implemented in conjunction with suitable procedures, frame formats, etc., different than those discussed above.

At block1104, a first communication device receives (e.g., the recipient304receives, the network interface device122receives, the MAC processor126receives, the PHY processor130receives, etc.) a plurality of QoS data frames from a second communication device. For instance, in an embodiment, the plurality of QoS data frames are the plurality of QoS data frames330corresponding to the BA procedure as described with respect toFIG.3.

At block1104, the first communication device generates (e.g., the recipient304generates, the network interface device122generates, the MAC processor126generates, etc.) a BA frame. The BA frame corresponds to the BA frame335described with respect toFIG.3, andFIGS.6A-6C. The BA frame335is generated according to a data rate and/or an MCS that is selected based on a length of an acknowledgment bitmap included in the BA frame (e.g., the acknowledgment bitmap included in the BA bitmap field624, BA bitmap field646, etc.). For example, when the length of the acknowledgment bitmap is a maximum bitmap length (e.g., a maximum length of an acknowledgment bitmap as negotiated during a setup portion, such as the setup portion306), the BA frame is generated using a first data rate/MCS. On the other hand, when the length of the acknowledgment bitmap is less than the maximum bitmap length, the BA frame is generated using a second data rate/MCS. In an embodiment, the second data rate/MCS is less than the first data rate/MCS. In an embodiment, the first communication device selects the second data rate/MCS such that a duration of the BA frame is approximately equal to (and less than or equal to) a duration of the BA frame if the BA frame included a bitmap having the maximum bitmap length and was generated according to the first data rate/MCS.

At block1108, the first communication device transmits (e.g., the recipient304transmits, the network interface device122transmits, the PHY processor130transmits, etc.) the BA frame to the client station154.

Embodiment 1: A method, comprising: generating, at a first communication device, a first communication frame corresponding to a request to participate in a block acknowledgment procedure, wherein the first communication frame includes: a first field indicating a number of buffers requested to be allocated at a second communication device for buffering data units to be transmitted by the first communication device, and a second field indicating a first maximum bitmap length supported by the first communication device. The method also comprises: transmitting, by the first communication device, the first communication frame to the second communication device; receiving, at the first communication device, a second communication frame corresponding to a response to the first communication frame, wherein the second communication frame includes: a third field indicating a number of buffers allocated at the second communication device for buffering the data units transmitted by the first communication device, and a fourth field indicating a second maximum bitmap length supported by the second communication device. The method further comprises: performing, at the first communication device, the block acknowledgment procedure in accordance with the second maximum bitmap length.

Embodiment 2: The method of Embodiment 1, wherein performing the block acknowledgment procedure in accordance with the second maximum bitmap length comprises: transmitting, by the first communication device, the data units to the second communication device; and receiving, at the first communication device, a block acknowledgment frame including a bitmap of a length that is less than or equal to the second maximum bitmap length, wherein the bitmap indicates whether the data units were successfully received at the second communication device.

Embodiment 3: The method of Embodiment 2, wherein: the data units are transmitted, by the first communication device, as part of a multi-user uplink transmission to the second communication device; and the block acknowledgment frame is a multi-station (multi-STA) block acknowledgement frame to the first communication device and one or more third communication devices in a multi-user downlink transmission.

Embodiment 4: The method of Embodiment 2, wherein: the data units are transmitted, by the first communication device, in a single-user transmission to the second communication device; and the block acknowledgment frame is a compressed block acknowledgement (C-BA) frame.

Embodiment 5: The method of any of Embodiments 1-4, wherein performing the block acknowledgment procedure in accordance with the second maximum bitmap length comprises: setting, at the first communication device, a block acknowledgment transmission window size based on the second maximum bitmap length.

Embodiment 6: The method of any of Embodiments 1-5, wherein: the second field indicates the first maximum bitmap length as a fraction of a maximum number of buffers defined by a communication protocol; and the fourth field indicates the second maximum bitmap length as a fraction of the maximum number of buffers defined by the communication protocol.

Embodiment 7: The method of any of Embodiment 1-6, wherein: performing the block acknowledgment procedure in accordance with the second maximum bitmap length is performed in response to determining that the number of buffers indicated by the third field is greater than a threshold; and the method further comprises: in response to determining that the number of buffers indicated by the third field is less than or equal to the threshold, performing, at the first communication device, the block acknowledgment procedure in accordance with a third maximum bitmap length that corresponds to the threshold.

Embodiment 8: The method of Embodiment 7, further comprising: in response to determining that the number of buffers indicated by the third field is less than or equal to the threshold, not processing, at the first communication device, the fourth field in the second communication frame.

Embodiment 9: An apparatus, comprising: a network interface device associated with a first communication device, wherein the network interface device includes one or more integrated circuit (IC) devices. The one or more IC devices are configured to: generate a first communication frame corresponding to a request to participate in a block acknowledgment procedure, wherein the first communication frame includes: a first field indicating a number of buffers requested to be allocated at a second communication device for buffering data units transmitted by the first communication device, and a second field indicating a first maximum bitmap length supported by the first communication device. The one or more IC devices are further configured to: transmit the first communication frame to the second communication device; and receive a second communication frame corresponding to a response to the first communication frame, wherein the second communication frame includes: a third field indicating a number of buffers allocated at the second communication device for buffering the data units transmitted by the first communication device, and a fourth field indicating a second maximum bitmap length supported by the second communication device. The one or more IC devices are further configured to: perform the block acknowledgment procedure in accordance with the second maximum bitmap length.

Embodiment 10: The apparatus of Embodiment 9, wherein the one or more IC devices are configured to perform the block acknowledgment procedure at least by: transmitting the data units to the second communication device; and receiving a block acknowledgment frame including a bitmap of a length that is less than or equal to the second maximum bitmap length, wherein the bitmap indicates whether the data units were successfully received at the second communication device.

Embodiment 11: The apparatus of Embodiment 10, wherein: the one or more IC devices are configured to transmit the data units are as part of a multi-user uplink transmission to the second communication device by the first communication device and one or more third communication devices; and the block acknowledgment frame is a multi-station (multi-STA) block acknowledgement frame to the first communication device and the one or more third communication devices in a multi-user downlink transmission.

Embodiment 12: The apparatus of Embodiment 10, wherein: the one or more IC devices are configured to transmit the data units in a single-user transmission to the second communication device; and the block acknowledgment frame is a compressed block acknowledgement (C-BA) frame.

Embodiment 13: The apparatus of any of Embodiments 9-12, wherein the one or more IC devices are configured to adjust a block acknowledgment transmission window size based on the second maximum bitmap length.

Embodiment 14: The apparatus of any of Embodiments 9-13, wherein: the second field indicates the first maximum bitmap length as a fraction of a maximum number of buffers defined by a communication protocol; and the fourth field indicates the second maximum bitmap length as a fraction of the maximum number of buffers defined by the communication protocol.

Embodiment 15: The apparatus of any of Embodiments 9-14, wherein the one or more IC devices are configured to: perform the block acknowledgment procedure in accordance with the second maximum bitmap length in response to determining that the number of buffers indicated by the third field is greater than a threshold; and in response to determining that the number of buffers indicated by the third field is less than or equal to the threshold, perform the block acknowledgment procedure in accordance with a third maximum bitmap length that corresponds to the threshold.

Embodiment 16: The apparatus of Embodiment 15, wherein the one or more IC devices are configured to: in response to determining that the number of buffers indicated by the third field is less than or equal to the threshold, not process the fourth field in the second communication frame.

Embodiment 17: A method, comprising: receiving, at a first communication device, a first communication frame corresponding to a request for participating in the block acknowledgment procedure, wherein the first communication frame includes: a first field indicating a number of buffers requested to be allocated at the first communication device for buffering data units transmitted by a second communication device, and a second field indicating a first maximum bitmap length supported by the second communication device. The method also comprises: generating, at the first communication device, a second communication frame corresponding to a response to the first communication frame, wherein the second communication frame includes: a third field indicating a number of buffers allocated at the first communication device for buffering the data units transmitted by the second communication device, and a fourth field indicating a second maximum bitmap length supported by the second communication device. The method further comprises: transmitting, by the first communication device, the second communication frame to the second communication device in response to receiving the first communication frame; and performing, at the first communication device, the block acknowledgment procedure in accordance with the second maximum bitmap length.

Embodiment 18: The method of Embodiment 17, wherein performing the block acknowledgment procedure in accordance with the second maximum bitmap length comprises: receiving, at the first communication device, the data units from the second communication device; generating, at the first communication device, a block acknowledgment frame including a bitmap, wherein the bitmap is of a length that is less than or equal to the second maximum bitmap length, and wherein the bitmap indicates whether the data units were successfully received at the first communication device; and transmitting, by the first communication device, the block acknowledgment frame to the second communication device.

Embodiment 19: The method of Embodiment 18, wherein: the received data units are part of a multi-user uplink transmission by the second communication device and one or more third communication devices; and the block acknowledgment frame is a multi-station (multi-STA) block acknowledgement frame to the second communication device and the one or more third communication devices in a multi-user downlink transmission.

Embodiment 20: The method of Embodiment 18, wherein: the received data units are included in a single-user transmission to the first communication device; and the block acknowledgment frame is a compressed block acknowledgement (C-BA) frame.

Embodiment 21: The method of any of Embodiments 17-20, wherein: the second field indicates the first maximum bitmap length as a fraction of a maximum number of buffers defined by a communication protocol; and the fourth field indicates the second maximum bitmap length as a fraction of the maximum number of buffers defined by the communication protocol.

Embodiment 22: An apparatus, comprising: a network interface device associated with a first communication device, wherein the network interface device includes one or more integrated circuit (IC) devices. The one or more IC devices are configured to: receive a first communication frame corresponding to a request for participating in a block acknowledgment procedure, wherein the first communication frame includes: a first field indicating a number of buffers requested to be allocated at the first communication device for buffering data units transmitted by a second communication device, and a second field indicating a first maximum bitmap length supported by the second communication device. The one or more IC devices are further configured to: generate a second communication frame corresponding to a response to the first communication frame, wherein the second communication frame includes: a third field indicating a number of buffers allocated at the first communication device for buffering the data units transmitted by the second communication device, and a fourth field indicating a second maximum bitmap length supported by the second communication device. The one or more IC devices are further configured to: transmit the second communication frame to the second communication device in response to the first communication frame; and perform the block acknowledgment procedure in accordance with the second maximum bitmap length.

Embodiment 23: The apparatus of Embodiment 22, wherein the one or more IC devices are configured to, as part of performing the block acknowledgment procedure in accordance with the second maximum bitmap length: receive the data units from the second communication device; generate a block acknowledgment frame including a bitmap, wherein the bitmap is of a length that is less than or equal to the second maximum bitmap length, and wherein the bitmap indicates whether the data units were successfully received at the first communication device; and transmit the block acknowledgment frame to the second communication device.

Embodiment 24: The apparatus of Embodiment 23, wherein: the received data units are part of a multi-user uplink transmission by the second communication device and one or more third communication devices; and the block acknowledgment frame is a multi-station (multi-STA) block acknowledgement frame to the second communication device and the one or more third communication devices in a multi-user downlink transmission.

Embodiment 25: The apparatus of Embodiment 23, wherein: the received data units are included in a single-user transmission to the first communication device; and the block acknowledgment frame is a compressed block acknowledgement (C-BA) frame.

Embodiment 26: The apparatus of any of Embodiments 22-25, wherein: the second field indicates the first maximum bitmap length as a fraction of a maximum number of buffers defined by a communication protocol; and the fourth field indicates the second maximum bitmap length as a fraction of the maximum number of buffers defined by the communication protocol.

Embodiment 27: A method, comprising: receiving, at a first communication device, a plurality of QoS data frames from a second communication device; generating, at the first communication device, a block acknowledgment frame having a bitmap, wherein the block acknowledgment frame is for acknowledging at least some of the plurality of QoS data frames. Generating the block acknowledgment frame comprises: in response to the bitmap having a first length corresponding to a maximum bitmap length, generating the block acknowledgment frame according to a first data rate, and in response to the bitmap having a second length that is less than the maximum bitmap length, generating the block acknowledgment frame using a second data rate that is lower than the first data rate. The method also comprises: transmitting, by the first communication device, the block acknowledgment frame to the second communication device.

Embodiment 28: The method of Embodiment 27, wherein: generating the block acknowledgment frame according to the first data rate includes generating the block acknowledgment frame according to a first modulation and coding scheme (MCS); and generating the block acknowledgment frame according to the second data rate includes generating the block acknowledgment frame according to a second MCS.

Embodiment 29: An apparatus, comprising: a network interface device associated with a first communication device, wherein the network interface device includes one or more integrated circuit (IC) devices. The one or more IC devices are configured to: receive a plurality of QoS data frames from a second communication device; generate a block acknowledgment frame having a bit map, wherein the block acknowledgment frame is for acknowledging at least some of the plurality of QoS data frames. Generating the block acknowledgment frame comprises: in response to the bitmap having a maximum bitmap length, generate the block acknowledgment frame according to a first data rate, and in response to the bitmap having a length that is less than the maximum bitmap length, generate the block acknowledgment frame according a second data rate that is less than the first data rate. The one or more IC devices are further configured to transmit the block acknowledgment frame to the second communication device.

Embodiment 30: The apparatus of Embodiment 29, wherein the one or more IC devices are configured to: in response to the bitmap having the maximum bitmap length, generate the block acknowledgment frame according to a first modulation and coding scheme (MCS); and in response to the bitmap having the length that is less than the maximum bitmap length, generating the block acknowledgment frame according to a second MCS.

At least some of the various blocks, operations, and techniques described above may be implemented utilizing hardware, a processor executing firmware instructions, a processor executing software instructions, or any combination thereof. When implemented utilizing a processor executing software or firmware instructions, the software or firmware instructions may be stored in any computer readable memory such as on a magnetic disk, an optical disk, or other storage medium, in a RAM or ROM or flash memory, processor, hard disk drive, optical disk drive, tape drive, etc. The software or firmware instructions may include machine readable instructions that, when executed by one or more processors, cause the one or more processors to perform various acts.

When implemented in hardware, the hardware may comprise one or more of discrete components, an integrated circuit, an application-specific integrated circuit (ASIC), a programmable logic device (PLD), etc.

While the present invention has been described with reference to specific examples, which are intended to be illustrative only and not to be limiting of the invention, changes, additions and/or deletions may be made to the disclosed embodiments without departing from the scope of the invention.