CN111095836A

CN111095836A - Acknowledgement of transmissions in a wireless local area network

Info

Publication number: CN111095836A
Application number: CN201880059415.2A
Authority: CN
Inventors: 褚立文; 张鸿远; 娄蕙苓
Original assignee: NXP USA Inc
Current assignee: NXP USA Inc
Priority date: 2017-07-18
Filing date: 2018-07-18
Publication date: 2020-05-01
Also published as: EP3656072A1; WO2019018575A8; WO2019018575A1

Abstract

A first communication device receives one or more aggregate Media Access Control (MAC) data units from a respective one or more second communication devices. The respective aggregate MAC data unit includes a plurality of MAC data units from respective ones of the one or more second communication devices. The first communication device generating one or more acknowledgement information fields including a first acknowledgement information field corresponding to a particular second communication device, the first acknowledgement information field comprising: i) a length indication indicating a length of an acknowledgement field, and ii) the acknowledgement field indicating the length. The acknowledgement field includes respective acknowledgement information for at least some of the plurality of MAC data units received from the particular second communication device. The first communication device generates an acknowledgment data unit to include the one or more acknowledgment information fields and transmits the acknowledgment data unit to the one or more second communication devices.

Description

Acknowledgement of transmissions in a wireless local area network

Cross Reference to Related Applications

The present disclosure claims the benefit of U.S. provisional patent application No. 62/534,106 entitled Block Acknowledgement (BA) for transmission in Wireless Local Area networks (Block Acknowledgement (BA) of Transmissions in a Wireless Local Area Network) filed on 7, 18, 2017.

Further, the present application is a continuation-in-part application entitled "Acknowledgement of transmission in Wireless Local Area Network (acknowledgements of Transmissions in a Wireless Local Area Network)" filed on 21/2/2017, which claims the benefit of the following U.S. provisional patent applications: united states provisional patent application No. 62/297,236 entitled "acknowledgement of OFDMA a-MPDUs with Multiple TCs (OFDMA a-MPDUs with Multiple TCs)" filed on year 2016, month 2, 19; united states provisional patent application No. 62/298,057 entitled "Super BA Design (Super BA Design)" filed on 22/2/2016; united states provisional patent application No. 62/304,570 entitled "acknowledgement of OFDMA a-MPDUs with Multiple TCs" (filed on 3, 7, 2016); and united states provisional patent application No. 62/323,400 entitled "Super BA Design (Super BA Design)" filed on 2016, 4, 15.

The disclosures of all of the above-referenced patent applications are hereby incorporated by reference in their entirety.

Technical Field

The present disclosure relates generally to communication networks and more particularly to wireless local area networks utilizing Orthogonal Frequency Division Multiplexing (OFDM).

Background

Wireless Local Area Networks (WLANs) have evolved rapidly over the past decade. The development of WLAN standards, such as the Institute of Electrical and Electronics Engineers (IEEE)802.11a, 802.11b, 802.11g, 802.11n, and 802.11ac standards, improves single-user peak data throughput. For example, the IEEE802.11 b standard specifies a single-user peak throughput of 11 megabits per second (Mbps), the IEEE802.11a and 802.11g standards specify a single-user peak throughput of 54Mbps, the IEEE802.11 n standard specifies a single-user peak throughput of 600Mbps, and the IEEE802.11 ac standard specifies a single-user peak throughput in the range exceeding gigabytes per second (Gbps). The IEEE802.11 ax standard supports Downlink (DL) and Uplink (UL) multi-user (MU) transmissions (e.g., Orthogonal Frequency Division Multiple Access (OFDMA) transmissions and multi-user multiple input multiple output (MU-MIMO) transmissions), and provides throughput in excess of four Gbps. Future standards are expected to provide even greater throughput, for example, in the tens of Gbps range.

Disclosure of Invention

In one embodiment, a method for acknowledging data units includes: receiving, at a first communication device, one or more aggregated Media Access Control (MAC) data units from respective one or more second communication devices, respective ones of the one or more aggregated MAC data units comprising a respective set of a plurality of MAC data units from respective ones of the one or more second communication devices; generating, at the first communication device, one or more acknowledgement information fields corresponding to the one or more second communication devices, including generating a first acknowledgement information field corresponding to a particular second communication device of the one or more second communication devices, wherein the first acknowledgement field includes: i) a length indication indicating a length of an acknowledgement field, and ii) the acknowledgement field indicating the length, wherein the acknowledgement field includes respective acknowledgement information for at least some of the plurality of MAC data units received from the particular second communication device, and wherein the length of the acknowledgement field is determined based at least in part on a buffer size previously negotiated in an acknowledgement setup procedure conducted between the first communication device and the particular second communication device; generating, at the first communications device, an acknowledgement data unit to include the one or more acknowledgement information fields; and transmitting the acknowledgment data unit from the first communication device to the one or more second communication devices.

In another embodiment, a first communication device includes a network interface having one or more integrated circuits configured to: receiving one or more aggregate Media Access Control (MAC) data units from respective one or more second communication devices, respective ones of the one or more aggregate MAC data units comprising respective sets of a plurality of MAC data units from respective ones of the one or more second communication devices; generating one or more acknowledgement information fields corresponding to the one or more second communication devices, including generating a first acknowledgement information field corresponding to a particular second communication device of the one or more second communication devices, wherein the first acknowledgement field includes: i) a length indication indicating a length of an acknowledgement field, and ii) the acknowledgement field indicating the length, wherein the acknowledgement field includes respective acknowledgement information for at least some of the plurality of MAC data units received from the particular second communication device, and wherein the length of the acknowledgement field is determined based at least in part on a buffer size previously negotiated in an acknowledgement setup procedure conducted between the first communication device and the particular second communication device; generating an acknowledgement data unit to include at least the first acknowledgement information field; and causing the acknowledgment data unit to be transmitted to the one or more second communication devices.

Drawings

FIG. 1 is a block diagram of an exemplary Wireless Local Area Network (WLAN) according to one embodiment;

FIG. 2A is a block diagram of an exemplary data unit, according to one embodiment;

FIG. 2B is a diagram of an exemplary data portion of the data unit of FIG. 2A, according to one embodiment;

3A-3C are block diagrams of exemplary data units according to embodiments;

fig. 4 is a block diagram of another exemplary transmission sequence in a WLAN according to another embodiment;

FIG. 5 is a block diagram of an exemplary acknowledgment data unit, according to one embodiment;

FIG. 6 is a block diagram of an exemplary control field of an acknowledgment data unit, according to one embodiment;

FIG. 7 is a block diagram of exemplary information fields included in an acknowledgment data unit, according to one embodiment;

FIG. 8 is a block diagram of another exemplary information field included in an acknowledgment data unit in accordance with another embodiment;

FIG. 9 is a block diagram of an exemplary identifier information subfield included in an information field of an acknowledgment data unit, according to one embodiment;

FIG. 10 is a block diagram of an exemplary identifier information subfield included in an information field of an acknowledgment data unit in accordance with another embodiment;

fig. 11 is a flow diagram of an exemplary method for acknowledging data units in a wireless local area network, according to one embodiment;

FIG. 12 is a block diagram of an acknowledgement information field included in an acknowledgement data unit in accordance with another embodiment;

FIG. 13 is a block diagram of a block acknowledgment information field included in an acknowledgment data unit according to another embodiment;

FIG. 14 is a block acknowledgment starting sequence control field included in an acknowledgment data unit according to one embodiment;

FIG. 15 is a table illustrating an exemplary interpretation of values of subfields of an acknowledgement information field according to one embodiment; and

fig. 16 is a flow diagram of an exemplary method for acknowledging data units in a wireless local area network, according to another embodiment.

Detailed Description

In the embodiments described below, a wireless network device, such as an Access Point (AP) of a Wireless Local Area Network (WLAN), communicates with one or more client stations. The AP is configured to communicate with client stations according to at least a first communication protocol. The first communication protocol is sometimes referred to herein as a "Next Generation (NG) WLAN". In some embodiments, different client stations in the vicinity of the AP are configured to operate according to one or more other communication protocols that define operation in the same frequency band as the NG WLAN communication protocol, but generally with lower data throughput. Lower data throughput communication protocols (e.g., IEEE802.11a, IEEE802.11 g, IEEE802.11 n, IEEE802.11 ac, and/or IEEE802.11 ax) are collectively referred to herein as "legacy" communication protocols.

In one embodiment, the AP transmits a data stream to a corresponding client station. For example, an AP transmits a data unit to a client station, the data unit including, for example, an aggregated data unit that aggregates a plurality of higher layer data units (e.g., a plurality of Medium Access Control (MAC) layer data units). Similarly, the respective client stations transmit data streams to the AP. For example, a client station transmits a data unit to an AP, the data unit including, for example, an aggregated data unit that aggregates a plurality of higher layer data units (e.g., a plurality of Medium Access Control (MAC) layer data units). In some embodiments, the AP concurrently (e.g., simultaneously) transmits independent data streams to multiple client stations and/or concurrently (e.g., simultaneously) receives independent data streams transmitted by multiple client stations. For example, in one embodiment, an AP transmits respective aggregated data units of an aggregated higher layer (e.g., MAC) data unit to respective client stations in different Orthogonal Frequency Division Multiplexing (OFDM) subchannels of a downlink Orthogonal Frequency Division Multiple Access (OFDMA) transmission. Similarly, in one embodiment, a plurality of client stations concurrently (e.g., simultaneously) transmit respective aggregate data units of an aggregate higher layer (e.g., MAC) data unit to the AP, in particular, each client station transmitting its aggregate data unit in a different OFDM subchannel of an uplink OFDMA transmission. Additionally or alternatively, the AP transmits the aggregate data units of the respective client stations using different spatial streams of a downlink multi-user multiple-input multiple-output (MU-MIMO) transmission. Similarly, in one embodiment, the respective client stations concurrently (e.g., simultaneously) transmit the aggregate data unit to the AP using different spatial streams within an uplink MU-MIMO transmission to the AP.

In one embodiment, upon receiving transmissions from one or more client stations, the AP acknowledges receipt of the one or more transmissions by transmitting one or more acknowledgment data units to the client stations. For example, in one embodiment, the AP transmits OFDMA acknowledgment data units that include respective acknowledgments intended for different client stations in different OFDM subchannels. In another embodiment, the AP transmits MU-MIMO acknowledgement data units comprising respective acknowledgements for different client stations intended for transmission in different spatial streams. In yet another embodiment, the AP transmits a broadcast acknowledgment data unit (which is broadcast to a plurality of client stations and includes respective acknowledgments for the plurality of client stations) or a multicast acknowledgment data unit (which is multicast to a plurality of client stations and includes respective acknowledgments intended for the plurality of client stations). In one embodiment, the acknowledgment data unit to the one or more client stations comprises a respective variable length acknowledgment field corresponding to a respective client station of the one or more client stations and a respective indication indicating a length of the respective acknowledgment field. In this embodiment, the respective lengths of the acknowledgement fields may be selected based on a respective maximum number of higher layer data units that may be aggregated in a single aggregated data unit from the corresponding one or more client stations. In other embodiments, the AP acknowledges receipt of the simultaneous transmission from one or more client stations in other suitable manners.

In some embodiments, the first communication protocol supports aggregation of a larger maximum number of higher layer data units in a single transmission than the maximum number of higher layer data units that can be aggregated in a single transmission according to conventional communication protocols. Thus, an acknowledgment unit acknowledging the transmission from a communication device (e.g., an AP of a client station) that aggregates a number of higher layer data units in excess of the maximum number supported by the legacy communication protocol will require a length of the acknowledgment field that exceeds the maximum acknowledgment field length defined in the legacy communication protocol. In some embodiments, an acknowledgment unit acknowledging transmission from a communication device (e.g., an AP of a client station) of a higher layer data unit aggregated by a number exceeding a maximum number supported by a legacy communication protocol includes a plurality of acknowledgment fields, wherein respective ones of the plurality of acknowledgment fields acknowledge respective subsets of the higher layer data units. In such embodiments, a greater number of higher layer data units are acknowledged without exceeding the maximum acknowledgement field length defined in conventional communication protocols. These and other techniques described herein enhance the operation of a WLAN in scenarios in which the WLAN includes communication devices that conform to a first communication protocol and communication devices that do not conform to the first communication protocol but conform to a legacy communication protocol. For example, in one embodiment, such techniques allow an AP to transmit a single acknowledgment data unit that includes one or more acknowledgment fields for client stations that conform to a first communication protocol and one or more acknowledgment fields for client stations that do not conform to the first communication protocol but conform to a legacy communication protocol, wherein a maximum length of the respective acknowledgment fields does not exceed a maximum acknowledgment field length supported by the legacy communication protocol.

Fig. 1 is a block diagram of an exemplary Wireless Local Area Network (WLAN)10 according to one embodiment. The AP14 includes a host processor 15 coupled to a network interface 16. In one embodiment, network interface 16 includes one or more Integrated Circuits (ICs) configured to operate as discussed below. The network interface 16 includes a MAC processor 18 and a PHY processor 20. The PHY processor 20 includes a plurality of transceivers 21, and the transceivers 21 are coupled to a plurality of antennas 24. Although three transceivers 21 and three antennas 24 are shown in fig. 1, in other embodiments, the AP14 includes a different number (e.g., 1, 2, 4,5, etc.) of transceivers 21 and antennas 24. In some embodiments, the AP14 includes a greater number of antennas 24 than transceivers 21, and utilizes antenna switching techniques. In one embodiment, MAC processor 18 is implemented on at least a first IC and PHY processor 20 is implemented on at least a second IC. In one embodiment, at least a portion of MAC processor 18 and at least a portion of PHY processor 20 are implemented on a single IC.

In various embodiments, the MAC processor 18 and the PHY processor 20 are configured to operate in accordance with a first communication protocol (e.g., a high efficiency, HE, or 802.11ax communication protocol). In some embodiments, the MAC processor 18 and the PHY processor 20 are also configured to operate in accordance with a second communication protocol (e.g., in accordance with the IEEE802.11 ac standard). In yet another embodiment, the MAC processor 18 and the PHY processor 20 are additionally configured to operate in accordance with a second communication protocol, a third communication protocol, and/or a fourth communication protocol (e.g., in accordance with the IEEE802.11a standard and/or the IEEE802.11 n standard).

The WLAN 10 includes a plurality of client stations 25. Although four client stations 25 are shown in fig. 1, in various scenarios and embodiments, the WLAN 10 includes different numbers (e.g., 1, 2, 3, 5, 6, etc.) of client stations 25. At least one of the client stations 25 (e.g., client station 25-1) is configured to operate in accordance with at least a first communication protocol. In some embodiments, at least one of the client stations 25 is not configured to operate in accordance with a first communication protocol, but is configured to operate in accordance with at least one of a second communication protocol, a third communication protocol, and/or a fourth communication protocol (referred to herein as a "legacy client station").

The client station 25-1 includes a host processor 26 coupled to a network interface 27. In one embodiment, network interface 27 includes one or more ICs configured to operate as discussed below. The network interface 27 includes a MAC processor 28 and a PHY processor 29. The PHY processor 29 includes a plurality of transceivers 30, and the transceivers 30 are coupled to a plurality of antennas 34. Although three transceivers 30 and three antennas 34 are shown in fig. 1, in other embodiments, the client station 25-1 includes a different number (e.g., 1, 2, 4,5, etc.) of transceivers 30 and antennas 34. In some embodiments, the client station 25-1 includes a greater number of antennas 34 than transceivers 30 and utilizes antenna switching techniques. In one embodiment, the MAC processor 28 is implemented on at least a first IC and the PHY processor 29 is implemented on at least a second IC. In one embodiment, at least a portion of MAC processor 28 and at least a portion of PHY processor 29 are implemented on a single IC.

According to one embodiment, the client station 25-4 is a legacy client station, that is, the client station 25-4 is not capable of receiving and fully decoding data units transmitted by the AP14 or another client station 25 according to the first communication protocol. Similarly, according to one embodiment, the legacy client station 25-4 is not capable of transmitting data units according to the first communication protocol. On the other hand, the legacy client station 25-4 is capable of receiving and fully decoding and transmitting data units according to the second communication protocol, the third communication protocol, and/or the fourth communication protocol.

In one embodiment, one or both of the client stations 25-2 and 25-3 have the same or similar structure as the client station 25-1. In one embodiment, the client station 25-4 has a similar structure to the client station 25-1. In these embodiments, client stations 25 that are structurally the same as or similar to client station 25-1 have the same or different numbers of transceivers and antennas. For example, according to one embodiment, the client station 25-2 has only two transceivers and two antennas (not shown).

In various embodiments, the MAC processor 18 and the PHY processor 20 of the AP14 are configured to generate data units that conform to the first communication protocol and have the format described herein. In some embodiments, the MAC processor 18 and the PHY processor 20 are additionally configured to generate data units that conform to the second communication protocol, the third communication protocol, and/or the fourth communication protocol. In one embodiment, the MAC processor 18 is configured to implement MAC layer functions, including MAC layer functions of the first communication protocol. In one embodiment, PHY processor 20 is configured to implement PHY functions, including PHY functions of the first communication protocol. For example, in one embodiment, the MAC processor 18 is configured to generate MAC layer data units (e.g., MPDUs, MAC control frames, etc.) and provide the MAC layer data units to the PHY processor 20. In one embodiment, the PHY processor 20 is configured to receive MAC layer data units from the MAC processor 18 and encapsulate the MAC layer data units to generate PHY data units (e.g., PHY Protocol Data Units (PPDUs)) for transmission via the antenna 24. Similarly, in one embodiment, PHY processor 20 is configured to receive PHY data units received via antenna 24 and extract MAC layer data units encapsulated within the PHY data units. In one embodiment, the PHY processor 20 provides the extracted MAC layer data units to the MAC processor 18, and the MAC processor 18 processes the MAC layer data units.

The transceiver(s) 21 are configured to transmit the generated data units via the antenna(s) 24. Similarly, the transceiver(s) 21 are configured to receive data units via the antenna(s) 24. According to various embodiments, the MAC processor 18 and the PHY processor 20 of the AP14 are configured to process received data units that conform to the first communication protocol and have a format described below, and determine that such data units conform to the first communication protocol.

In various embodiments, the MAC processor 28 and the PHY processor 29 of the client device 25-1 are configured to generate data units that conform to the first communication protocol and have the formats described herein. In some embodiments, the MAC processor 28 and the PHY processor 29 are additionally configured to generate data units that conform to the second communication protocol, the third communication protocol, and/or the fourth communication protocol. In one embodiment, the MAC processor 28 is configured to implement MAC layer functions, including MAC layer functions of the first communication protocol. In one embodiment, PHY processor 29 is configured to implement PHY functions, including PHY functions of the first communication protocol. For example, in one embodiment, the MAC processor 28 is configured to generate MAC layer data units (e.g., MPDUs, MAC control frames, etc.) and provide the MAC layer data units to the PHY processor 29. In one embodiment, PHY processor 29 is configured to receive MAC layer data units from MAC processor 28 and encapsulate the MAC layer data units to generate PHY data units (e.g., PPDUs) for transmission via antenna 34. Similarly, in one embodiment, PHY processor 29 is configured to receive PHY data units received via antenna 34 and extract MAC layer data units encapsulated within the PHY data units. In one embodiment, the PHY processor 29 provides the extracted MAC layer data units to the MAC processor 28, and the MAC processor 28 processes the MAC layer data units.

The transceiver(s) 30 are configured to transmit the generated data units via the antenna(s) 34. Similarly, the transceiver(s) 30 are configured to receive data units via the antenna(s) 34. According to various embodiments, MAC processor 28 and PHY processor 29 of client device 25-1 are configured to process received data units that conform to a first communication protocol and have a format described below, and determine that such data units conform to the first communication protocol.

Fig. 2A is a block diagram of a physical layer (PHY) data unit 200, according to one embodiment, with an AP14 configured to transmit the data unit 200 to one or more client stations 25 (e.g., client station 25-1). In one embodiment, one or more client stations 25 (e.g., client station 25-1) are also configured to transmit the same or similar data units as data unit 200 to AP 14. Data unit 200 conforms to the HE communication protocol and occupies a 20MHz bandwidth. In other embodiments, data units similar to data unit 200 occupy other suitable bandwidths, such as 40MHz, 80MHz, 160MHz, 320MHz, 640MHz, or other suitable bandwidths, for example. The data unit 200 is suitable for a "mixed mode" situation, i.e., a situation where the WLAN 10 includes client stations that conform to the legacy communication protocol but do not conform to the first communication protocol (e.g., legacy client station 25-4). In some embodiments, data unit 200 is used in other situations as well.

In various embodiments and/or scenarios, the data unit 200 is a Downlink (DL) Orthogonal Frequency Division Multiple Access (OFDMA) unit in which separate data streams are transmitted to multiple client stations 25 using respective sets of OFDM tones (and in some cases, respective spatial streams allocated to the client stations 25). Similarly, in various embodiments and/or scenarios, the data unit 200 is an Uplink (UL) OFDMA data unit transmitted by a particular client station 25 (as part of an OFDMA uplink transmission by a plurality of client stations 25), wherein each of the plurality of client stations 25 transmits data using a set of OFDM tones (and, in some cases, using a respective one or more spatial streams allocated to the client stations 25). In one embodiment, available OFDM tones (e.g., OFDM tones not used as DC tones and/or guard tones) are divided into a plurality of Resource Units (RUs), and each of the plurality of RUs is allocated to one or more client stations 25 for transmission of data to or by one or more client stations 25. In one embodiment, the allocation of OFDM tones is performed using a block of basic resource units defined by the first communication protocol. A basic resource unit block is sometimes referred to herein simply as a "basic resource unit". In one embodiment, the base resource unit includes K OFDM tones, where K is an integer greater than zero, and each allocated resource unit includes one or more K-OFDM tone base resource units. In one embodiment, K-26. Thus, in this embodiment, the basic resource unit includes 26 OFDM tones. In the present embodiment, the resource units allocated to the client station 25 or to the multi-user group of client stations 25 comprise a plurality of OFDM tones which are an integer multiple of 26 OFDM tones, e.g., 26 OFDM tones, 52 OFDM tones, 106 OFDM tones, etc. In another embodiment, K is any suitable integer other than 26, and the basic resource unit includes a corresponding number of OFDM tones other than 26.

The data unit 200 includes a preamble 202, the preamble 202 including a legacy short training field (L-STF)205, a legacy long training field (L-LTF)210, a legacy signal field (L-SIG)215, a first HE signal field (HE-SIG-a)220, a second HE signal field (HE-SIG-B)222, a HE short training field (HE-STF)225, and an M HE long training field (HE-LTF) 230. The L-STF 205, L-LTF210, and L-SIG 215 include a legacy preamble portion 242 of the preamble 202. The HE-SIG-a220, HE-SIG-B222, HE-STF 225, and M HE-LTF 230 include the HE preamble portion 244 of the preamble 202. In some embodiments and/or scenarios, data unit 200 also includes data portion 240. Referring briefly to fig. 2B, in one embodiment, the data portion 240 includes a service field 252 and a MAC Protocol Data Unit (MPDU) delimiter 253 (followed by MPDU 254). MPDU 254 includes MAC header 255 and MAC Service Data Unit (MSDU) 256. In some embodiments, the data portion 240 comprises an aggregated MPDU (a-MPDU) comprising a plurality of MPDU delimiter fields 253, each MPDU delimiter field 253 optionally followed by a respective MPDU 254. In some embodiments, each of the one or more MSDUs 256 included in the data portion 240 is an aggregated MSDU (a-MSDU) that aggregates a plurality of MSDUs. In one embodiment, the first communication protocol defines a maximum number of MPDUs and thus a maximum number of MSDUs/A-MSDUs that may be aggregated in a single A-MPDU. In one embodiment, the first communication protocol specifies that up to 256 MPDUs may be aggregated in a single a-MPDU. In another embodiment, the first communication protocol specifies another suitable maximum number of MPDUs that can be aggregated in a single a-MPDU.

In some embodiments, the data portion 240 additionally includes one or more padding portions (not shown), each of the one or more padding portions having one or more padding bits. For example, each of at least some of the one or more MSDUs 256 in the data portion 240 includes (e.g., is accompanied by) a respective padding portion to ensure that each of the at least some MSDUs 256 has a length that is an integer multiple of four octets.

Referring back to FIG. 2A, each of the L-STF 205, L-LTF210, L-SIG 215, HE-SIG-A220, HE-SIG-B222, HE-STF 225, and M HE-LTF 230 includes one or more OFDM symbols. In one embodiment, HE-SIG-a220 and HE-SIG-B222 are each encoded separately to generate a corresponding number of OFDM symbols. As just one example, HE-SIG-a220 includes two OFDM symbols and HE-SIG-B222 includes one OFDM symbol. As another example only, HE-SIG-a220 includes one OFDM symbol and HE-SIG-B includes two OFDM symbols. As yet another example, HE-SIG-a220 includes two OFDM symbols and HE-SIG-B222 includes a variable number of OFDM symbols. In one embodiment where the HE-SIG-B222 includes a variable number of OFDM symbols, a particular number of HE-SIG-B222OFDM symbols in the data unit 200 is indicated in the HE-SIG-a 220. In some embodiments and/or scenarios, HE-SIG-B222 is omitted.

In the embodiment of FIG. 2A, the data unit 200 includes each of an L-STF 205, an L-LTF210, an L-SIG 215, and an HE-SIG-A220. In other embodiments where data units similar to data unit 200 occupy cumulative bandwidths other than 20MHz, each of L-STF 205, L-LTF210, L-SIG 215, and HE-SIG-A220 is repeated in one embodiment over a corresponding number of 20MHz sub-bands of the overall bandwidth of the data unit. For example, the data units occupy 80MHz bandwidth and thus include each (four) of L-STF 205, L-LTF210, L-SIG 215, HE-SIG-A220. In one embodiment where a data unit similar to data unit 200 occupies an accumulated bandwidth other than 20MHz, HE-SIG-B repeats over a corresponding number of 20MHz sub-bands of the entire bandwidth of the data unit. In another embodiment where a data unit similar to data unit 200 occupies an accumulated bandwidth other than 20MHz, HE-SIG-B222 includes different channel-specific portions corresponding to different 20MHz sub-bands of the overall bandwidth of the data unit, and the different channel-specific portions are transmitted in parallel in the corresponding 20MHz sub-bands of the overall bandwidth of data unit 200.

In some embodiments, the modulation of different 20MHz sub-band signals is rotated by different angles. For example, in one embodiment, all OFDM tones within the first subband are rotated by 0 degrees, all OFDM tones within the second subband are rotated by 90 degrees, the third subband is rotated by 180 degrees, and the fourth subband is rotated by 270 degrees. In other embodiments, different suitable rotations are utilized. In at least some embodiments, the different phases of the 20MHz sub-band signals result in a reduction in the peak-to-average power ratio (PAPR) of the OFDM symbols in the data unit 200. In one embodiment, if the data units conforming to the first communication protocol are OFDM data units occupying an accumulated bandwidth (e.g., 20MHz, 40MHz, 80MHz, 160MHz, 320MHz, 640MHz, etc.), the HE-STF, HE-LTF, HE-SIG-B, and HE data portion occupy a corresponding entire bandwidth of the data units.

In one embodiment, HE-SIG-a220 and HE-SIG-B222 generally carry information about the format of data unit 200, such as information needed to properly decode at least a portion of data unit 200 in one embodiment. In one embodiment where the data unit 200 is a multi-user data unit, the HE-SIG-a220 carries information that is typically needed by multiple intended receivers of the data unit 200. In some embodiments, the HE-SIG-a220 additionally includes information for receivers that are not intended receivers of the data unit 200, such as information needed for media protection. On the other hand, in one embodiment, the HE-SIG-B222 carries user-specific information that is needed individually by each intended receiver of the data unit 200. In one embodiment, HE-SIG-a220 includes information needed to properly decode HE-SIG-B222, and HE-SIG-B222 includes information needed to properly decode the data stream in data portion 240 of data unit 200. However, in some embodiments and/or scenarios, the HE-SIG-a field 220 includes information needed to decode the data portion 240, and in at least some such embodiments, the HE-SIG-B222 is omitted from the data unit 200. In at least some embodiments and scenarios in which an AP (e.g., AP14) is the intended recipient of the data unit 200 (i.e., when the data unit 200 is an uplink data unit), the information needed to properly decode the data portion of the data unit 200 is known a priori by the intended recipient of the data unit 200 and need not be included in the preamble of the data unit 200. In some such embodiments, HE-SIG-B222 is omitted from data unit 200.

In some embodiments, the specific information included in HE-SIG-a220 and/or HE-SIG-B222 depends on the transmission mode of the data unit 200. For example, in one embodiment, different information is included in HE-SIG-a220 when data unit 200 is a downlink data unit than is included in HE-SIG-a220 when data unit 200 is an uplink data unit. Additionally or alternatively, in one embodiment, different information is included in HE-SIG-a220 when data unit 200 is a multi-user data unit than is included in HE-SIG-a220 when data unit 200 is a single-user data unit. In another embodiment, different information is included in HE-SIG-B222 when data unit 200 is a downlink data unit than is included in HE-SIG-B222 when data unit 200 is an uplink data unit.

In some embodiments, each of the one or more fields 205-230 is repeated one or more times in the time domain. For example, the HE-SIGA field 220 is repeated one or more times in the time domain to increase transmission robustness and reliability of the HE-SIGA field 220. With continued reference to fig. 2A, in some embodiments, the preamble 202 omits one or

more fields

205 and 230. For example, the preamble 202 omits the HE-SIG-a220 and/or HE-SIG-B222. In some embodiments, preamble 202 includes additional fields not shown in fig. 2A.

Fig. 3A-3C are block diagrams of exemplary PHY data units occupying an 80MHz bandwidth, according to an embodiment. Referring first to fig. 3A, a data unit 300 is generally similar to the data unit 200 of fig. 2A. The data unit 300 includes a preamble portion 302 and a data portion 304. In one embodiment, the preamble portion 302 corresponds to a legacy preamble and, for example, conforms to a preamble format according to a legacy communication protocol (e.g., an IEEE802.11a standard, an IEEE802.11 n standard, or an IEEE802.11 ac standard). In another embodiment, the preamble 302 corresponds to a non-legacy preamble, for example, compliant with the IEEE802.11 ax standard. For example, in one embodiment, the preamble portion 302 includes a preamble, such as the preamble 202 of fig. 2A. At least some of the fields in the preamble portion 302 are duplicated in each 20MHz bandwidth of the data unit 300. For example, preamble portion 302 includes some or all of an L-STF field, an L-LTF field, an L-SIG field, an HE-SIG-A field, an HE-SIG-B field, an HE-STF field, and an HE-LTF field (e.g., L-STF field 205, L-LTF field 210, L-SIG field 215, HE-SIG-A field 220, HE-SIG-B222, HE-STF 225, and HE-LTF 230), respectively, and each of the L-STF field, the L-LTF field, the L-SIG field, and the HE-SIG-A field, the HE-SIG-B field, the HE-STF field, and the HE-LTF field is duplicated in each 20MHz band of data unit 300. In one embodiment, at least some of the fields in the preamble portion 302 are different in different 20MHz bands of the data unit 300. For example, in one embodiment, at least a portion of the HE-SIG-B field (e.g., the HE-SIG-B field 222) is different (e.g., includes information) in different 20MHz bands of the data unit 300.

In one embodiment, data portion 304 of data unit 300 is replicated in each 20MHz band of data unit 300, for example, when preamble portion 302 is a legacy preamble and is replicated in each 20MHz band. In one embodiment, the data portion 304 includes a trigger data unit that triggers uplink OFDMA transmissions by the plurality of client stations 25. In one embodiment, the trigger data unit includes information indicating an allocation of subchannels to be used for uplink OFDMA transmissions in one embodiment. The trigger data unit additionally indicates to the plurality of client stations 25 other transmission parameters, such as which Modulation and Coding Scheme (MCS) each of the plurality of client stations 25 should use, OFDM numerology (e.g., guard interval, tone interval, etc.) each of the plurality of client stations should use, transmission power that each of the plurality of client stations 25 should use, and so forth. In one embodiment, the trigger data unit is a duplicate broadcast data unit transmitted to the plurality of client stations 25 in each 20MHz band of a legacy PHY data unit that generally conforms to a legacy communication protocol (e.g., IEEE802.11a, IEEE802.11 n, IEEE802.11 ac communication protocol). In another embodiment, the trigger data unit is a broadcast data unit occupying an entire 80MHz bandwidth of a non-legacy PHY data unit conforming to a first communication protocol (e.g., HE communication protocol). In yet another embodiment, the data units are triggered to aggregate with data in the downlink a-MPDUs in each sub-channel or each resource unit of the downlink a-MPDUs.

Referring now to FIG. 3B, in one embodiment, a data unit 350 is generally similar to data unit 200 of FIG. 2A. The data unit 350 includes a preamble portion 352 and a data portion 354. The preamble portion 352 includes a legacy portion 356, an HE signal field portion 358, and an HE training field portion 360. In one embodiment, the legacy portion 356 includes an L-STF field, an L-LTF field, and an L-SIG field (e.g., L-STF field 205, L-LTF field 210, L-SIG field 215), respectively. In one embodiment, the HE signal field portion 358 includes one or more HE signal fields, such as HE-SIG-a220 and/or HE-SIG-B222. In one embodiment, the HE signal field portion 358 omits the HE-SIG-B222 in some cases. For example, in one embodiment, HE signal field portion 358 omits HE-SIG-B222 when data unit 300 is an uplink data unit. In one embodiment, the HE training field portion 358 includes HE training fields, such as HE-STF 225 and HE-LTF 230.

In one embodiment, the data portion 354 of the data unit 350 includes a plurality of aggregated MAC protocol data units (A-MPDUs) respectively directed to client stations of the plurality of client stations 25, wherein each A-MPDU comprises one or more MPDUs, wherein each of the one or more MPDUs comprises one or more MAC Service Data Units (MSDUs) and/or aggregated MSDUs (A-MSDUs). In one embodiment, at least some of the a-MPDUs in data portion 354 occupy subchannels that span widths less than 20 MHz. For example, in one embodiment, the a-MPDUs to (or from) STA3 and the a-MPDUs to (or from) STA4 each occupy a sub-channel that spans a width of less than 20 MHz. In one embodiment, the legacy portion 356 and the HE SIG portion 358 of the preamble 352 span multiple data units that collectively occupy a 20MHz bandwidth. On the other hand, in one embodiment, the HE training portion 360 of the preamble 352 includes a respective training field portion that occupies a respective subchannel of the plurality of subchannels in the 20MHz bandwidth.

In another embodiment, at least some of the a-MPDUs in data portion 354 occupy subchannels that span widths greater than 20 MHz. In one embodiment, as just one example, the A-MPDUs in the data portion 354 occupy subchannels that span 40 MHz. For example, in one embodiment, a-MPDUs to (or from) STA2 in fig. 3B span a 40MHz bandwidth. In one embodiment, the legacy portion 356 and the HE SIG portion 358 of the preamble 352 are duplicated in each 20MHz band of the 40MHz bandwidth. On the other hand, in one embodiment, the HE training portion 360 of the preamble 352 spans the entire 40MHz bandwidth.

In one embodiment, the data unit 350 is a downlink OFDMA data unit transmitted by the AP to a plurality of client stations 25. In another embodiment, the respective a-MPDUs in the data portion 354 are transmitted by a plurality of client stations 25 as part of an OFDMA transmission by the plurality of client stations 25. In one embodiment, the uplink data unit transmitted by the client station 25 includes a legacy preamble portion 354 and an HE signal field portion 356. In addition, the uplink data units transmitted by the client station 25 include a portion of the HE training field portion 260 that corresponds to the subchannel allocated by the client station 25 for uplink transmission. Referring briefly to fig. 3C, in one embodiment, the uplink data units 370 are transmitted by the STA 4. The uplink data unit 370 includes a preamble 372. The data unit 370 additionally includes a data portion 374. In one embodiment, the data portion 374 includes data units (e.g., a-MPDUs) in sub-channels allocated to the STAs 3. In one embodiment, the preamble 372 includes the legacy portion 356 and the HE signal portion 358 in one embodiment. The preamble 372 additionally includes a portion of the HE training portion 360 that corresponds to the sub-channel allocated to the STA 4. In the embodiment of fig. 3C, the legacy portion 356 and the HE signal portion 358 are each repeated in multiple 20MHz sub-bands of the bandwidth of the uplink data unit 370. In another embodiment, the legacy portion 356 and the HE signal portion 358 each occupy only one or more 20MHz sub-bands of the data unit 370 that includes the data portion 274. Thus, for example, in one embodiment, the legacy portion 356 and HE signal portion 358 each occupy only the first 20MHz sub-band that includes a-MPDUs from STA 4. Similarly, in one embodiment, HE training portion 360 occupies one or more 20MHz sub-bands of data unit 370 that includes data portion 274. Thus, for example, in one embodiment, HE training portion 360 occupies the entire first 20MHz sub-band that includes data units 370 of a-MPDUs from STA 4.

Fig. 4 is a block diagram of an exemplary transmission sequence 400 in a WLAN (e.g., WLAN 10) according to one embodiment. Transmission sequence 400 includes the transmission of data units 406. In one embodiment, the data unit 406 is a single user data unit that includes data corresponding to a single client station 25. In another embodiment, data unit 406 is a multi-user data unit that includes corresponding data corresponding to a plurality of client stations 25. For example, the data units 406 are MU-MIMO and/or OFDMA data units that include respective data transmitted to or by the respective client stations 25 in respective frequency portions and/or respective spatial streams allocated to the client stations 25. In one embodiment, the data units 406 are downlink data units transmitted by the AP14 to one or more client stations 25. In another embodiment, the data unit 406 is an upstream data unit that includes one or more data units that are simultaneously transmitted by one or more client stations 25 to the AP 14. In one embodiment where the data unit 406 is an upstream data unit comprising one or more upstream data units transmitted simultaneously by one or more client stations 25, the transmission of the one or more data units is triggered by a trigger data unit (not shown in fig. 4) transmitted by the AP14 to the one or more client stations 25 to trigger the transmission of the one or more data units by the one or more client stations 25. In one embodiment, data unit 406 corresponds to data unit 200 of FIG. 2A. In another embodiment, data cell 406 corresponds to data cell 300 of FIG. 3A or data cell 350 of FIG. 3B. In another embodiment, data unit 406 is a suitable data unit other than data unit 200 of FIG. 2A, data unit 300 of FIG. 3A, and data unit 350 of FIG. 3B.

Upon receiving the data unit 406, the receiving device transmits an acknowledgment data unit 410 to acknowledge receipt of the data in the data unit 406. Thus, for example, in one embodiment in which the data unit 406 is a single-user downlink data unit transmitted by the AP14 to a client station 25 (e.g., client station 25-1), the acknowledgment data unit 410 is transmitted by the client station 25-1 to the AP14 to acknowledge receipt of the data unit 406 by the client station 25-1. As another example, in one embodiment where the data unit 406 is a multi-user downlink data unit transmitted by the AP14 to a plurality of client stations 25, the acknowledgment data unit 410 comprises a corresponding acknowledgment data unit transmitted by the plurality of client stations 25. As yet another example, in one embodiment where the data unit 406 is a single-user uplink data unit transmitted by the client station 25-1 to the AP14, the acknowledgment data unit 410 is transmitted by the AP14 to the client station 25-1. As yet another example, in one embodiment in which the data units 406 are multi-user uplink data units that include respective data units transmitted by a plurality of client stations 25, the acknowledgment data units 410 are transmitted by the AP14 to the plurality of client stations 25 and include respective acknowledgment data corresponding to respective ones of the plurality of client stations 25.

In one embodiment, data unit 406 is an a-MPDU that aggregates a plurality of MPDUs (each having one or more MSDUs) and/or a-MSDUs, and acknowledgment data unit 410 is a block acknowledgment (BlockAck) data unit that includes respective acknowledgment information for respective MPDUs of the plurality of MPDUs aggregated in the a-MPDU. Thus, the data units 406 are sometimes referred to herein as a-MPDUs 406, and the acknowledgment data units 410 are sometimes referred to herein as block acknowledgments 410. In one embodiment, block acknowledgement 410 has a variable length. In one embodiment, the particular length of block acknowledgement 410 is determined by the maximum number of MPDUs that block acknowledgement 410 potentially requires acknowledgement. As discussed above with respect to fig. 2B, in one embodiment, the first communication protocol defines a maximum number of MPDUs (e.g., 256 or another suitable maximum number) that may be aggregated into a single a-MPDU. However, in some cases, the number of MPDUs that may potentially be aggregated in a-MPDU406 is less than the maximum number of MPDUs defined by the first communication protocol for a single a-MPDU. For example, if the maximum number of MPDUs supported is aggregated into a-MPDU406, the device transmitting the a-MPDU406 may not have a sufficient amount of buffer memory to buffer block acknowledgement information expected to be received from devices receiving and acknowledging the a-MPDU 406. Thus, in one embodiment, the maximum number of MPDUs that may be aggregated in the a-MPDU406 is less than the maximum supported number of MPDUs.

In one embodiment, the block acknowledgement 410 comprises a bitmap in which respective bits indicate successful or unsuccessful reception of respective ones of a plurality of MPDUs aggregated in the a-MPDU 406. In one embodiment, in at least some scenarios, the maximum number of MPDUs that may be included in a single a-MPDU transmitted from the AP14 to a particular client station 25 (or vice versa) may be less than the maximum number of MPDUs in the single a-MPDU supported by the first communication protocol. For example, in one embodiment, the maximum number of MPDUs that can be included in a single a-MPDU transmitted from the AP14 to a particular client station 25 (or vice versa) is negotiated between the AP14 and the client station 25. Then, in one embodiment, where the negotiated maximum number of MPDUs is less than the supported maximum number of MPDUs, the acknowledgment data units from the client station 25 to the AP14 (or vice versa) include, in at least some cases, a relatively short bitmap to acknowledge the negotiated number of MPDUs. As just one example, in an embodiment in which the first communication protocol supports aggregation of up to 256 MDPUs in a single a-MPDU, but the data unit 406 may include a maximum number of MPDUs that is less than 256 MPDUs (e.g., 128 MPDUs, 64 MPDUs, 32 MPDUs, or another suitable maximum number of MDPUs that is less than 256 MPDUs), the bitmap included in the block acknowledgement 410 includes fewer bits than 256 bits corresponding to the maximum number of MPDUs that may be included in the data unit 406. In one embodiment, the length of the bitmap in the acknowledgment data unit 410 is selected from a plurality of predetermined possible lengths of the bitmap. For example, the length of the bitmap is selected from a plurality of possible bit numbers included in the bitmap, wherein the possible bit numbers are 256 bits, 128 bits, 64 bits, 32 bits.

In one embodiment, the length of the bitmap included in block acknowledgement 410 is determined by the particular number of MPDUs included in a-MPDU406 acknowledged by block acknowledgement 410. For example, in one embodiment where the number of bits of the bitmap in the acknowledgment data unit 410 is selected from a plurality of possible numbers of bits (e.g., 256 bits, 128 bits, 64 bits, 32 bits), the number of bits is selected such that the number of bits is the smallest number of bits in the plurality of possible numbers of bits that is greater than or equal to a particular number of MPDUs included in the a-MPDU406 acknowledged by the acknowledgment data unit 410.

In one embodiment, the negotiation between devices (e.g., between the AP14 and the client station 25) occurs during a block acknowledgment setup procedure (e.g., ADDBA negotiation procedure) between the two devices and prior to data transfer between the devices. In one embodiment, the block acknowledgement setup procedure includes a frame exchange that includes transmission of a request frame (e.g., an ADDBA request) from a first communication device (e.g., AP14) to a second communication device (e.g., client station 25) and subsequent transmission of a response frame (e.g., an ADDBA response) from the second communication device to the first communication device. In one embodiment, the maximum number of MPDUs that can be aggregated into a single a-MPDU is limited by the buffer size at the receiving device or the number of buffers available and/or allocated for receiving block acknowledgements. Thus, in one embodiment, negotiating a buffer size determines the number of MPDUs that can be aggregated into a single a-MPDU for each of a plurality of traffic classes. For example, in one embodiment in which negotiating a buffer size allows 256 MPDUs to be aggregated into a single a-MPDU and the first communication protocol supports 8 traffic classes, the transmitting apparatus may include up to 256 MPDUs for each of the 8 classes. Thus, in this embodiment, a single a-MPDU may include up to 256x 8-2048 MPDUs. In another embodiment, the negotiation buffer size determines the maximum number of MPDUs that can be aggregated into a single a-MPDU, regardless of the traffic class of the MPDU. Thus, for example, in one embodiment where negotiating a buffer size allows 256 MPDUs to be aggregated into a single a-MPDU and the first communication protocol supports 8 traffic classes, the transmitting device may in one embodiment include up to 256 MPDUs in all 8 classes. In yet another embodiment, a first buffer size is negotiated for single TID data units and a second buffer size is negotiated for multi-TID data units.

In one embodiment, the maximum number of MPDUs of the specific traffic class that can be included in a single TID data unit is the same as the number of MPDUs of the specific traffic class that can be included in a multi TID data unit. Thus, in this embodiment, a single buffer size is negotiated in the block acknowledgment setup (e.g., ADDBA) procedure. In one embodiment, each of the request frame (e.g., ADDBA request) and the response frame (e.g., ADDBA response) in the frame exchange performed during the ADDBA procedure includes a single buffer size field for the particular traffic class negotiated during the ADDBA procedure.

In another embodiment, the maximum number of MPDUs of the specific traffic class that can be included in a single TID data unit and the number of MPDUs of the specific traffic class that can be included in a multi TID data unit are not necessarily the same. For example, in one embodiment, each of a request frame (e.g., an ADDBA request) and a response frame (e.g., an ADDBA response) in a frame exchange performed during a block acknowledgment setup (e.g., ADDBA) procedure for a particular traffic class includes a first buffer size field for negotiating a buffer size for a single TID a-MPDU and a second buffer size field for negotiating a buffer size for a multi-TID a-MPDU. In another embodiment, each of the request frame (e.g., ADDBA request) and the response frame (e.g., ADDBA response) in the frame exchange performed during the block acknowledgment setup (e.g., ADDBA) procedure for a particular traffic class includes a buffer size field and a scale factor field. In this embodiment, the buffer size field is used to negotiate a buffer size that defines the maximum number of MPDUs of a particular traffic class that may be included in a single TID a-MPDU, and the scaling factor field is set to a value by which the size indicated in the buffer size field may be scaled to determine the buffer size of the multi-TID a-MPDU and to determine the corresponding maximum number of MPDUs of the particular traffic class that may be included in the multi-TID a-MPDU.

In one embodiment, the maximum a-MPDU length is declared by the receiving device (e.g., AP14 or client station 25). For example, in one embodiment, AP14 andthe client station 25 transmits management data units, such as beacon data units (which are also referred to herein as "beacon frames"), association request data units, reassociation request data units, association response data units, reassociation response data units, probe request data units, probe response data units, or other suitable data units, wherein the management data units include an indication of the maximum length a-MPDUs supported by the device. For example, a maximum a-MPDU length index field is included in the management data unit. In one embodiment, the maximum a-MPDU length index field is included in a first capability element included in the management data unit, wherein the first capability element is defined by a legacy communication protocol. For example, in various embodiments, the first capability element is a VHT capability element defined by the IEEE802.11 ac standard or an HT capability element defined by the IEEE802.11 n standard. The value of the a-MPDU length index field is used at the transmitting apparatus to determine the maximum a-MPDU length supported by the receiving apparatus. In one embodiment, the maximum a-MPDU length supported by the receiving apparatus is 2^{13+ max a-MPDU length index}-1 determining, wherein the maximum a-MPDU length index is the value of the a-MPDU length index field in the first capability element. In one embodiment, the maximum a-MPDU length field in the first capability element comprises three bits and the value maximum a-MPDU length index field in the first capability element is in the range 0 to 7. Thus, the value max a-MPDU length index field in the first capability element specifies up to 2²⁰Maximum a-MPDU length of bytes (i.e. up to 1,048,576 bytes). In other embodiments, the maximum a-MPDU length field in the first capability element comprises less than or greater than three bits, and/or the value maximum a-MPDU length index in the first capability element specifies up to 2 more²⁰Maximum a-MPDU length outside bytes.

In one embodiment, to specify a maximum value greater than may be specified by the maximum a-MPDU length index field in the first capability element (e.g., greater than 2)²⁰Bytes), the receiving apparatus transmits the additional a-MPDU maximum index field, e.g., by including the additional a-MPDU maximum index field in a second capability element of the management frame. In one embodiment, the second capability elementThe element is an HE capability element defined by the first communication protocol. In one embodiment, the maximum a-MPDU length index field in the second capability element comprises three bits. In another embodiment, the maximum a-MPDU length index field in the second capability element comprises less than or greater than three bits. In one embodiment, the maximum a-MPDU length index field in the second capability element is set to identify one of a plurality of predetermined indices, for example, indices among 20, 21 and 22. In one embodiment where the maximum a-MPDU length exponent field in the second capability element includes three bits and the field is used to indicate one of three predetermined exponent values, three values of the three bits (e.g., 0, 1, and 2) are defined to indicate the three predetermined exponent values, respectively, and the remaining values of the three bits (e.g., 3-7) are retained. In another embodiment where the maximum a-MPDU length exponent field in the second capability element includes three bits, a suitable number of values of three bits greater than three values (e.g., 4 values, 5 values, etc.) or less than three values (e.g., 2 values), respectively, are defined to indicate the respective predetermined exponent values, and the remaining values are retained. As a more specific example, four values (e.g., 0, 1, 2, 3) are defined to indicate four predetermined values, respectively, and the remaining values (e.g., 4-7) are retained. In other embodiments, the maximum a-MPDU length exponent field in the second capability element comprises a suitable number of bits greater than three bits (e.g., 4 bits, 5 bits) or less than three bits (e.g., 1 bit, 2 bits), and defines at least some of the respective values for the number of bits greater than three bits or less than three bits, respectively, to indicate the respective predetermined exponent values. In one embodiment, the specific index indicated in the a-MPDU length index field in the second capability element indicates that the maximum a-MPDU length supported by the apparatus is 2^{20+ max a-MPDU length index}-1, wherein the maximum a-MPDU length index is the value of the a-MPDU length index field in the second capability element.

In one embodiment, the transmitting apparatus uses the a-MPDU maximum length index field in the second capability element in combination with the a-MPDU maximum length index field in the first capability element to determine the maximum a-MPDU length supported by the receiving apparatus. For example, if the value of the a-MPDU maximum length index field in the first capability element is less than 7, the transmission apparatus is according to 2¹³ ^{+ max a-MPDU length index}-1 to determine a maximum a-MPDU length supported by the receiving apparatus, wherein the maximum a-MPDU length index is the value of the a-MPDU length index field in the first capability element. In this case, in one embodiment, the a-MPDU length index field in the second capability element is reserved. On the other hand, if the value of the a-MPDU maximum length index field in the first capability element is equal to 7, the transmission apparatus is according to 2^{20+ max a-MPDU length index}-1 to determine a maximum a-MPDU length supported by the receiving apparatus, wherein the maximum a-MPDU length index is the value of the a-MPDU length index field in the second capability element.

Fig. 5 is a block diagram of an exemplary acknowledgment data unit 500 included in an acknowledgment data unit in accordance with one embodiment. In one embodiment, the acknowledgment data unit 500 is included in the acknowledgment data unit 410 of fig. 4. In another embodiment, the acknowledgment data unit 500 is included in a suitable data unit other than the acknowledgment data unit 410 of fig. 4. Similarly, in some embodiments, the acknowledgment data unit 410 of fig. 4 comprises a different acknowledgment data unit than the acknowledgment data unit 500. The acknowledgment data unit 500 includes a plurality of fields 502. In the embodiment shown in fig. 5, the fields 502 include a data unit control field 502-1, a duration/id field 502-2, a first address (e.g., receiver address) field 502-3, a second address (e.g., transmitter address) field 502-4, a block acknowledgement control field 502-5, a block acknowledgement information field 502-6, and a data unit sequence check (FCS) field 502-7. According to an exemplary embodiment, the numbers indicated in fig. 5 above each field 502 indicate the number of octets of bits in the corresponding field 502.

In one embodiment, the first address (address 1) field 502-3 includes an address of an intended receiver of an acknowledgment data unit that includes the control field 500. In one embodiment and/or scenario in which the control field 500 is included in a unicast acknowledgement data unit directed to only one client station 25, the first address field 502-3 includes a unicast address (e.g., a unicast MAC address) corresponding to one client station 25. On the other hand, in one embodiment and/or scenario in which the control field 500 is included in a broadcast acknowledgment data unit directed to a plurality of client stations 25, the first address field 502-3 includes a broadcast address (e.g., a broadcast MAC address) to indicate that the acknowledgment data unit is directed to the plurality of client stations 25.

Fig. 6 is a block diagram illustrating bit allocation of a block acknowledgement control field 600 included in an acknowledgement data unit according to one embodiment. In one embodiment, block acknowledgement control field 600 corresponds to block acknowledgement control field 502-5. Block acknowledgement control field 600 includes a plurality of subfields 602. In the illustrated embodiment, the sub-field 602 includes 16 bits in total. In other embodiments, the subfields 602 collectively include a suitable number of bits other than 16 bits. In the embodiment shown in fig. 6, block acknowledgement control field 600 includes a BA acknowledgement policy subfield 602-1, a multi-TID subfield 602-2, a compressed bitmap subfield 602-3, a retry multicast (GCR) subfield 602-4, a group BA indication subfield 602-5, a reserved subfield 602-6, and a TID information subfield 602-7. According to an exemplary embodiment, the bit allocation for each subfield 602 is shown in fig. 6 above the corresponding subfield 602.

In one embodiment, the group BA indication subfield 602-5 indicates that the acknowledgment data unit that includes the BA control field 600 includes a single acknowledgment for acknowledging a single data unit received from one client station 25 or includes multiple acknowledgments for acknowledging multiple data units received from multiple client stations 25, e.g., as part of a MU-MIMO uplink transmission from multiple client stations 25 or an OFDMA transmission from multiple client stations 25. In one embodiment, in addition to the indication provided by the RA field 502-3 discussed above with respect to FIG. 5, the group BA indication field 602-5 serves as an additional indication that the acknowledgment data unit that includes the BA control field 600 includes a single acknowledgment directed to one client station 25 or multiple acknowledgments directed to multiple client stations 25. In another embodiment, the group BA indication subfield 602-5 is omitted from the BA control field 600 and instead relies on the RA field 502-3 to indicate that the acknowledgment data unit that includes the BA control field 600 includes a single acknowledgment directed to one client station 25 or multiple acknowledgments directed to multiple client stations 25.

Fig. 7 is a block diagram of a block acknowledgement information field 700, according to one embodiment. In one embodiment, block acknowledgement information field 700 corresponds to block acknowledgement information field 502-6 of acknowledgement data unit 500 of fig. 5. The block acknowledgement information field 700 includes a plurality of subfields 702. In the embodiment shown in fig. 7, the sub-fields 702 include a fragment indication sub-field 702-1, a block acknowledgement bitmap length sub-field 702-1, a reserved sub-field 702-2, a sequence number sub-field 702-3, and a block acknowledgement bitmap sub-field 702-4. Together, the fragment indication subfield 702-1, the block acknowledgement bitmap length subfield 702-1, the reserved subfield 702-2, and the sequence number subfield 702-3 form a block acknowledgement starting sequence control field 704.

In one embodiment, the sequence number subfield 702-3 indicates a sequence number corresponding to the first of the acknowledged data units, and each bit of the block acknowledgement bitmap subfield 702-4 acknowledges, in one embodiment, a data unit having a sequence number equal to the sequence number indicated by the sequence number subfield 702-3 plus the index of that bit. Thus, for example, in one embodiment, the first bit (bit index 0) of the acknowledgement bitmap subfield 702-4 acknowledges data units having a sequence number indicated by the sequence number subfield 702-3, the second bit (bit index 1) of the acknowledgement bitmap subfield 702-4 acknowledges data units having a sequence number indicated by the sequence number subfield 702-3 plus 1, and so on. In one embodiment, the value of each bit of block acknowledgement bitmap subfield 702-4 indicates whether the corresponding data unit was successfully received. For example, a value of a logical one (1) of the bits of block acknowledgement bitmap subfield 702-4 indicates that the corresponding data unit was successfully received, and a value of a logical zero (0) of the bits of block acknowledgement bitmap subfield 702-4 indicates that the corresponding data unit was not successfully received (e.g., not received or received in error).

In one embodiment, block acknowledgement bitmap subfield 702-4 has a variable length. In one embodiment, the length of block acknowledgement bitmap subfield 702-4 depends on the maximum length of the A-MPDU acknowledged by block acknowledgement information field 700. For example, in one embodiment, block acknowledgement bitmap subfield 702-4 comprises a number of bits corresponding to the maximum number of MPDUs that may be included in the a-MPDU acknowledged by block acknowledgement information field 700. Block acknowledgement bitmap length subfield 702-1 indicates the length of block acknowledgement bitmap subfield 702-4. In one embodiment, the block acknowledgement bitmap length subfield 702-1 comprises one or more bits set to a value indicating a particular length of a plurality of predetermined lengths. In one embodiment, for example, the bitmap length indication includes two bits to indicate a particular length of four predetermined lengths, e.g., 32 octets, 16 octets, 8 octets and 4 octets (i.e., 256 bits, 128 bits, 64 bits and 32 bits, respectively). In other embodiments, other suitable numbers of multiple predetermined lengths (e.g., two different lengths, eight different lengths, etc.) and/or other values of predetermined lengths are utilized. In one embodiment, a particular length of the predetermined lengths is selected based on a number of MPDUs included in the acknowledged a-MPDU. For example, a minimum length of the predetermined lengths that is greater than or equal to the number of MPDUs included in the acknowledged a-MPDU is selected. In some embodiments, the length of block acknowledgement bitmap subfield 702-4 is less than the buffer size defined during a block acknowledgement negotiation (e.g., an ADDBA negotiation).

Figure 8 is a block diagram of an AID TID block acknowledgement information field 800 included in a block acknowledgement information field of an acknowledgement data unit, according to one embodiment. In one embodiment, the respective one or more AID TID block acknowledgement information fields 800 are included in a block acknowledgement information field of an acknowledgment data unit to acknowledge an a-MPDU including an MPDU corresponding to each of one or more apparatuses (e.g., one or more client stations 25) and/or each of one or more traffic classes. In one embodiment, AID TID block acknowledgement information field 800 is substantially the same as block acknowledgement information field 700 of fig. 7 and includes some or all of the same subfields 702 as block acknowledgement information field 700 of fig. 7. AID TID block acknowledgement information field 800 additionally includes AID TID information subfield 802-1. In one embodiment, AID TID information subfield 802-1 indicates a particular client station and/or a particular traffic class to which AID TID block acknowledgement information element 800 corresponds, and block acknowledgement bitmap subfield 702-4 comprises a bitmap set to indicate successful or unsuccessful reception of one or more MPDUs of the particular client station and/or the particular traffic class. In one embodiment, each AID TID information subfield 802-1 includes 16 bits (i.e., two bytes). In another embodiment, each AID TID information subfield 802-1 includes a suitable number of bits in addition to 16 bits.

Figure 9 is a block diagram of the AID TID block acknowledgement information subfield 900 corresponding to the AID TID block acknowledgement information subfield 802-1 in one embodiment. In one embodiment, the AID TID block acknowledgement subfield 900 is included in a single user acknowledgement data unit used to acknowledge a-MPDUs of a single device (e.g., a single client station 25), where the a-MPDUs may include MPDUs of multiple traffic classes. The AID TID block acknowledgement information element 900 includes reserved bits 902-1 and an acknowledgement/BA subfield 902-2, TID value subfield 902-3. In one embodiment, the acknowledgement/BA subfield 902-2 includes a bit that is set to indicate that the AID TID information field including the AID TID block acknowledgement information subfield 900 includes: i) a single acknowledgment for acknowledging a single data unit of the traffic class to which each TID block acknowledgment information element 900 corresponds, or ii) a block acknowledgment for acknowledging multiple data units of the traffic class to which each TID block acknowledgment information element 900 corresponds. In one embodiment, TID value subfield 902-3 includes four bits. In other embodiments, TID value subfield 902-3 includes other suitable number of bits. In one embodiment, TID value subfield 902-3 is set to a value indicating the traffic class to which each TID block acknowledgement information element 900 corresponds. In one embodiment, when the acknowledgement/BA subfield 902-2 indicates that the AID TID information field includes a single acknowledgement for acknowledging a single data unit of the traffic class, then the AID TID information field omits the sequence number subfield (e.g., the sequence number subfield 702-3 in fig. 7 and 8) and the block acknowledgement bitmap subfield (e.g., the block acknowledgement bitmap subfield 702-4 in fig. 7 and 8). On the other hand, when the acknowledgement/BA subfield 902-2 indicates that the AID TID information field includes block acknowledgements for acknowledging the plurality of data units of the traffic class, then the AID TID information field includes a sequence number subfield (e.g., the sequence number subfield 702-3 in fig. 7 and 8) and a block acknowledgement bitmap subfield (e.g., the block acknowledgement bitmap subfield 702-4 in fig. 7 and 8).

Figure 10 is a block diagram of the AID TID block acknowledgement information subfield 1000 corresponding to the AID TID block acknowledgement information subfield 802-1 in another embodiment. In one embodiment, the AID TID block acknowledgement information subfield 1000 is included in a multi-user acknowledgement data unit for acknowledging respective a-MPDUs of a plurality of apparatuses (e.g., a plurality of client stations 25), wherein each a-MPDU may include MPDUs of a plurality of traffic classes. The AID TID block acknowledgement information subfield 1000 is substantially the same as the AID TID block acknowledgement information subfield 900 of fig. 9 except that at least some of the reserved bits 902-1 in the AID TID block acknowledgement information subfield 900 of fig. 9 are replaced by the device identifier subfield 1002-1 in the AID TID block acknowledgement information subfield 1000. In one embodiment, the device identifier subfield 1002-1 includes 10 bits. In another embodiment, the device identifier subfield 1002-1 includes another suitable number of bits. In one embodiment, the device identifier subfield 1002-1 includes an Association Identifier (AID) of the client station to which the AID TID block acknowledgement information subfield 1000 corresponds. In another embodiment, the device identifier subfield 1002-1 includes a partial AID for the client station to which the AID TID block acknowledgement information subfield 1000 corresponds. In other embodiments, the device identifier subfield 1002-1 includes another suitable identifier for the client station to which the AID TID block acknowledgement information subfield 1000 corresponds.

Fig. 11 is a flow diagram of an exemplary method 1100 for acknowledging data units in a wireless local area network, according to one embodiment. In one embodiment, method 1100 is implemented by a first communication device. In various embodiments, for example, the first communication device is an AP (e.g., AP14) or a client station (e.g., client station 25-1). For example, in one embodiment, the method 1100 is implemented by the MAC processor 18 and/or the PHY processor 20 of the AP 14. As another example, in another embodiment, the method 1100 is implemented by the MAC processor 28 and/or the PHY processor 29 of the client station 25-1. In other embodiments, method 1100 is implemented by other suitable communication devices.

At block 1102, a PHY data unit is received. In one embodiment, the data unit 200 of FIG. 2A is received. In another embodiment, one of the data unit 300 of FIG. 3A, the data unit 350 of FIG. 3B, or the data unit 370 of FIG. 3C is received. In other embodiments, other suitable PHY data units are received. In one embodiment, the PHY data unit includes a plurality of MAC data units aggregated in an aggregate MAC data unit. For example, in one embodiment, the plurality of MAC data units are aggregated in an aggregated MAC data unit included in the data portion of the PHY data unit.

At block 1104, an acknowledgment data unit is generated to acknowledge receipt of the plurality of MAC data units. In one embodiment, the acknowledgment data unit 500 of FIG. 5 is generated. In another embodiment, a suitable acknowledgment data unit other than the acknowledgment data unit 500 of FIG. 5 is generated. In one embodiment, the acknowledgment data unit includes an acknowledgment field of variable length. For example, in one embodiment, the data units comprise variable length bitmaps. In one embodiment, the particular length of the acknowledgement field is determined based at least in part on a maximum number of MAC data units that may be included in the PHY data unit received at block 1102. In one embodiment, the acknowledgment data unit additionally includes a length indication indicating the length of the acknowledgment field.

In some embodiments, a plurality of MAC data units aggregated in an aggregated MAC data unit included in the PHY data unit received at block 1102 correspond to a plurality of traffic classes. For each of the plurality of traffic classes, the acknowledgment data unit generated at block 1104 comprises: (i) a respective length indication indicating a respective length of an acknowledgement field corresponding to the traffic class, and (ii) a respective acknowledgement field of the corresponding length, wherein in some such embodiments the respective acknowledgement field comprises respective acknowledgement information for a plurality of MAC data units of the traffic class.

At block 1106, the acknowledgment data unit is transmitted to the communication device from which the PHY data unit was received at block 1102.

In some embodiments, the first communication protocol supports aggregation of a greater maximum number of MPDUs in a single a-MPDU than the maximum number of MPDUs that may be aggregated in a single a-MPDU according to a conventional communication protocol. In some embodiments, the acknowledgment data unit includes a plurality of AID TID block acknowledgment information fields corresponding to a particular communication device (e.g., a particular client station 25) conforming to the first communication protocol to acknowledge a greater maximum number of MPDUs aggregated in a single a-MPDU according to the first communication protocol. In one embodiment, a plurality of AID TID block acknowledgement information fields corresponding to a particular communication device are used to acknowledge receipt of MPDUs of a particular traffic class in a-MPDUs from the particular communication device. In one embodiment, a plurality of AID TID block acknowledgement information fields included in the acknowledgment data unit are used to acknowledge respective subsets of MPDUs of a particular traffic class received in the a-MPDU from a particular communications apparatus. An acknowledgement data unit including multiple AID TID block acknowledgement information fields is suitable for use in one embodiment, e.g., where the number of MPDUs of a particular traffic class received in an a-MPDU from a particular client station that conform to a first communication protocol exceeds the maximum number of MPDUs that can be acknowledged by a single AID TID block acknowledgement information field (e.g., a single AID TID block acknowledgement information field that conforms to a legacy communication protocol).

Fig. 12 is a block diagram of a block acknowledgment information field 1200 included in an acknowledgment data unit, according to one embodiment. In one embodiment, block acknowledgement information field 1200 corresponds to block acknowledgement information field 502-6 of acknowledgement data unit 500 of fig. 5. In other embodiments, block acknowledgment information field 1200 is included in a suitable acknowledgment data unit other than acknowledgment data unit 500 of fig. 5. In one embodiment, the block acknowledgement information field 1200 is included in a single user data unit used to acknowledge MPDUs received in an a-MPDU from a particular single communication device (e.g., a particular client station 25). According to one embodiment, block acknowledgement information field 1200 includes a plurality of AID TID block acknowledgement information fields 1202 corresponding to a particular single communication device and a particular traffic class. According to one embodiment, AID TID block acknowledgement information field 1202 is used to acknowledge a respective subset of MPDUs received from a particular apparatus and corresponding to a particular traffic class. In one embodiment, each AID TID block acknowledgement information field 1202 is substantially the same as AID TID block acknowledgement information field 800 of fig. 8. In one embodiment, each AID TID block acknowledgement information field 1202 includes a respective AID TID information subfield 1204 corresponding to AID TID information subfield 802-1 of AID TID block acknowledgement information field 800 of fig. 8, a respective block acknowledgement starting sequence control subfield 1206 corresponding to block acknowledgement starting sequence control subfield 704 of AID TID block acknowledgement information field 800 of fig. 8, and a respective block acknowledgement bitmap subfield 1208 corresponding to block acknowledgement bitmap subfield 702-4 of AID TID block acknowledgement information field 800 of fig. 8.

In the illustrated embodiment, block acknowledgement information field 1200 includes a first AID TID block acknowledgement information field 1202-1 and a second AID TID block acknowledgement information field 1202-2. According to one embodiment, the first AID TID block acknowledgement information field 1202-1 and the second AID TID block acknowledgement information field 1202-2 are used to acknowledge respective subsets of MPDUs received from a single device (e.g., a single client station 25) and corresponding to a single traffic class. As just one example, in the illustrated embodiment, first AID TID block acknowledgement information field 1202-1 and second AID TID block acknowledgement information field 1202-2 are used to acknowledge respective subsets of MPDUs received from AID 12 associated client station 25 and corresponding to TID 6 associated traffic classes. Thus, in this embodiment, the respective AID TID information subfields 1204 of the first AID TID block acknowledgement information field 1202-1 and the second AID TID block acknowledgement information field 1202-2 are each set to indicate AID 12 and TID 6. In one embodiment, the respective block acknowledgement sequence control subfield 1206 indicates a respective length of the block acknowledgement bitmap subfield 1208. For example, in one embodiment, the respective block acknowledgement sequence control subfield 1206 includes a respective block acknowledgement bitmap length subfield, such as the block acknowledgement bitmap length subfield 702-2 in fig. 7. In the illustrated embodiment, the respective block acknowledgement bitmap length subfield is set to indicate a respective length of block acknowledgement bitmap subfield 1208 for acknowledging a respective subset of MPDUs received from AID 12 associated client station 25 and corresponding to a TID 6 associated traffic class. In one exemplary embodiment, the first subset of MPDUs acknowledged in the first AID TID block acknowledgement information field 1202-1 comprises 256 MPDUs and the block acknowledgement bitmap length subfield of the block acknowledgement sequence control subfield 1202-1 is set to indicate that the block acknowledgement bitmap subfield 1208-1 comprises 32 bytes to acknowledge the 256 MPDUs. Similarly, in one embodiment where the second subset of MPDUs acknowledged in the second AID TID block acknowledgement information field 1202-2 comprises up to 256 MPDUs, the block acknowledgement bitmap length subfield of the block acknowledgement sequence control subfield 1202-2 is set to indicate that the block acknowledgement bitmap subfield 1208-2 comprises 32 bytes to acknowledge up to 256 MPDUs. On the other hand, in one embodiment where the second subset of MPDUs acknowledged in the second AID TID block acknowledgement information field 1202-2 comprises up to 128 MPDUs, the block acknowledgement bitmap length subfield of the block acknowledgement sequence control subfield 1202-2 is set in one embodiment to indicate that the block acknowledgement bitmap subfield 1208-2 comprises 16 bytes to acknowledge up to 128 MPDUs. In one embodiment, the respective length of the block acknowledgement bitmap subfield 1208 is determined based at least in part on a buffer size (e.g., a total buffer size or a buffer size allocated for a corresponding traffic class) negotiated during a block acknowledgement negotiation (e.g., an ADDBA negotiation) with a particular communication device. For example, in some embodiments, the respective lengths of block acknowledgement bitmap subfields 1208 are determined such that the combined length of block acknowledgement bitmap subfields 1208 does not exceed a buffer size negotiated during a block acknowledgement negotiation (e.g., an ADDBA negotiation) with a particular communication device.

Fig. 13 is a block diagram of a block acknowledgment information field 1300 included in an acknowledgment data unit according to another embodiment. In one embodiment, block acknowledgement information field 1300 corresponds to block acknowledgement information field 502-6 of acknowledgement data unit 5 of fig. 5. In other embodiments, block acknowledgment information field 1300 is included in a suitable acknowledgment data unit other than acknowledgment data unit 500 of fig. 5. In one embodiment, the block acknowledgement information field 1300 is included in a multi-user data unit for acknowledging MPDUs received in respective A-MPDUs from a plurality of communication devices (e.g., a plurality of client stations 25). The block acknowledgement information field 1300 is similar to the block acknowledgement information field 1200 of fig. 2. In one embodiment, block acknowledgement information field 1300 includes a plurality of AID TID block acknowledgement information fields 1202 of block acknowledgement information field 1200 of fig. 12 corresponding to a first communication device for which the number of MPDUs acknowledged exceeds the maximum number of MPDUs that can be acknowledged by a single AID TID block acknowledgement information field. In one embodiment, the block acknowledgement information field 1300 additionally includes an additional AID TID block acknowledgement information field 1302 corresponding to a second communication device (e.g., second client station 25) for which the number of MPDUs acknowledged does not exceed the maximum number of MPDUs that can be acknowledged by a single AID TID block acknowledgement information field.

In one embodiment, the additional AID TID block acknowledgement information field 1302 is substantially the same as AID TID block acknowledgement information field 800 of fig. 8. In one embodiment, AID TID block acknowledgement information field 1302 includes AID TID information subfield 1304 corresponding to AID TID information subfield 802-1 of AID TID block acknowledgement information field 800 of fig. 8, block acknowledgement starting sequence control subfield 1306 corresponding to block acknowledgement starting sequence control subfield 704 of AID TID block acknowledgement information field 800 of fig. 8, and block acknowledgement bitmap subfield 1308 corresponding to block acknowledgement bitmap subfield 702-4 of AID TID block acknowledgement information field 800 of fig. 8. In one embodiment, AID TID information subfield 1304 of AID TID block acknowledgement information field 1302 includes an identifier of a second communications device different from the first communications device indicated in respective AID TID information subfields 1202-1 and 1202-2 of first AID TID block acknowledgement information field 1202-1 and second AID TID block acknowledgement information field 1202-2, and in some embodiments includes a second traffic class different from the first traffic class indicated in respective AID TID information subfields 1202-1202 of first AID TID block acknowledgement information field 1202-1 and second AID TID block acknowledgement information field 1202-2. For example, in the illustrated embodiment, while the corresponding AID TID information subfields 1204 of first AID TID block acknowledgement information field 1202-1 and second AID TID block acknowledgement information field 1202-2 are each set to indicate AID 12 and TID 6, the AID TID information subfield 1304 of AID TID block acknowledgement information field 1302 is set to indicate AID 16 and TID 7. In one embodiment, block acknowledgement starting sequence control subfield 1306 indicates the length of block acknowledgement bitmap subfield 1308. In one embodiment, the respective length of the block acknowledgement bitmap subfield 1308 is determined based at least in part on a buffer size (e.g., a total buffer size or a buffer size allocated for a corresponding traffic class) negotiated during a block acknowledgement negotiation (e.g., an ADDBA negotiation) with the second communication device. For example, in some embodiments, the length of the block acknowledgement bitmap subfield 1308 does not exceed the buffer size negotiated during a block acknowledgement negotiation (e.g., an ADDBA negotiation) with the second communication device.

In some embodiments, the block acknowledgement information field conforming to the first communication protocol is longer than the block information field conforming to the legacy communication protocol. For example, the length of the block acknowledgement bitmap field may be longer than the longest field defined in legacy communication protocols to accommodate a larger maximum number of MPDUs that may be aggregated in a single a-MPDU according to the first communication protocol. In some such embodiments, a single block acknowledgement information field is used to acknowledge MPDUs of an a-MPDU received from a communication device conforming to a first communication protocol even if the number of MPDUs of a particular traffic class acknowledged exceeds the maximum number of MPDUs that can be acknowledged in the longest block acknowledgement information field specified in a legacy communication protocol.

In some such embodiments, the block acknowledgement information field conforming to the first communication protocol includes an additional length indication in addition to the block acknowledgement (e.g., bitmap) length indication defined in the legacy communication protocol. In one embodiment, the combination of the additional length indication with the block acknowledgement length indication defined in the legacy communication protocol is used to indicate a larger acknowledgement field (e.g., bitmap) field length than the maximum block acknowledgement defined in the legacy communication protocol. Fig. 14 is a block diagram of a block acknowledgment starting sequence control field 1400 included in an acknowledgment data unit in accordance with one such embodiment. In one embodiment, the block acknowledgement starting sequence control field 1400 is included in the block acknowledgement information field 502-6 of the acknowledgement data unit 5 of fig. 5. In other embodiments, block acknowledgment information field 1200 is included in a suitable acknowledgment data unit other than acknowledgment data unit 500 of fig. 5. In one embodiment, the block acknowledgement starting sequence control field is similar to the block acknowledgement starting sequence control field 704 of fig. 7, except that the reserved subfield 702-2 of the block acknowledgement starting sequence control field 704 of fig. 7 is redefined as the additional bitmap length subfield 1402-3 in the block acknowledgement starting sequence control field 1400. In one embodiment, the value of the block acknowledgement bitmap subfield 702-4 is interpreted based on the value of the additional bitmap length subfield 1402-3. For example, in one embodiment, the additional bitmap length subfield 1402-3 includes one bit set to indicate that the length of the block acknowledgement bitmap subfield 702-4 indicated in the block acknowledgement bitmap length subfield length 702-2 is a length selected from a first set of predetermined lengths or from a second set of predetermined lengths. For example, in one exemplary embodiment, a first value (e.g., a logical zero) of the additional bitmap length subfield 1402-3 indicates that the length of the block acknowledgement bitmap subfield 702-4 indicated in the block acknowledgement bitmap length subfield length 702-2 is a length selected from a first set of predetermined lengths {4 bytes, 8 bytes, 16 bytes, and 32 bytes }, and a second value (e.g., a logical one) of the additional bitmap length subfield 1402-3 indicates that the length of the block acknowledgement bitmap subfield 702-4 indicated in the block acknowledgement bitmap length subfield length 702-2 is a length selected from a second set of predetermined lengths {48 bytes, 64 bytes, 128 bytes, and 256 bytes }.

Referring briefly to fig. 15, a table 1500 illustrates an exemplary interpretation of the value of the block acknowledgement bitmap subfield 702-4 based on the value of the additional bitmap length subfield 1402-3 and the corresponding maximum number of MDPUs that can be acknowledged in the block acknowledgement bitmap subfield 702-4, according to one embodiment. In other embodiments, the value of the block acknowledgement bitmap subfield 702-4 is interpreted based on the value of the additional bitmap length subfield 1402-3 to indicate other suitable lengths of the block acknowledgement bitmap field 702-4 and other corresponding maximum numbers of MPDUs that may be acknowledged.

Fig. 16 is a flow diagram of an exemplary method 1600 for acknowledging data units in a wireless local area network, according to one embodiment. In one embodiment, method 1100 is implemented by a first communication device. In various embodiments, for example, the first communications device is an AP (e.g., AP14) or a client station (e.g., client station 25-1). For example, in one embodiment, the method 1100 is implemented by the MAC processor 18 and/or the PHY processor 20 of the AP 14. As another example, in another embodiment, the method 1100 is implemented by the MAC processor 28 and/or the PHY processor 29 of the client station 25-1. In other embodiments, method 1100 is implemented by other suitable communication devices.

At block 1602, one or more aggregate MAC data units are received from one or more second communication devices. In one embodiment, the respective one of the one or more aggregated MAC data units comprises a respective set of a plurality of MAC data units from a respective second communication device of the one or more second communication devices. In one embodiment, the received aggregate MAC data unit is included in a PHY data unit (e.g., PHY data unit 200 of fig. 2A) received from the second communication device. In another embodiment, respective ones of the received aggregated MAC data units are included in respective PHY data units (e.g., PHY data units 370 of fig. 3C) received from respective ones of the plurality of second communication devices. In other embodiments, one or more aggregate MAC data units are received in other suitable manners.

At block 1604, one or more acknowledgement information fields corresponding to one or more second communication devices are generated. In one embodiment, generating one or more acknowledgement information fields comprises generating a first acknowledgement information field corresponding to a particular second communication device. For example, in one embodiment, generating one or more acknowledgement information fields includes generating block acknowledgement information field 700 of fig. 7. As another example, in another embodiment, generating one or more acknowledgement information fields includes generating the block acknowledgement information field 800 of fig. 8. As yet another example, in yet another embodiment, generating one or more acknowledgement information fields includes generating AID TID block acknowledgement information field 1202-1 of fig. 12-13. In other embodiments, other suitable first acknowledgement fields are generated. In one embodiment, the first acknowledgement field includes: i) a length indication indicating a length of the acknowledgement field, and ii) an acknowledgement field indicating the length, wherein the acknowledgement field comprises respective acknowledgement information for at least some of the plurality of MAC data units received from the particular second communication device. In one embodiment, the length of the acknowledgement field is determined based at least in part on a buffer size previously negotiated in an acknowledgement setup procedure conducted between the first communication device and the particular second communication device. For example, the particular length of the acknowledgement field is determined based at least in part on a buffer size previously negotiated in an ADDBA negotiation procedure or another suitable acknowledgement setup procedure conducted between the first communication device and the particular second communication device. In one embodiment, the particular length is determined such that the particular length does not exceed an acknowledgement field length required to acknowledge a maximum number of at least some MAC data units determined based on the negotiated buffer size.

At block 1606, an acknowledgment data unit is generated to include the one or more acknowledgment information fields generated at block 1604. In one embodiment, the acknowledgment data unit 500 of FIG. 5 is generated. In another embodiment, a suitable acknowledgment data unit other than the acknowledgment data unit 500 of FIG. 5 is generated.

At block 1606, the acknowledgment data unit generated at block 1604 is transmitted to one or more second communication devices.

In other embodiments, the method includes any suitable combination of one or more of the following features.

Generating the one or more acknowledgement information fields additionally includes generating a second acknowledgement information field corresponding to the particular second communication device, wherein i) the first acknowledgement information field is generated to acknowledge a first subset of the plurality of MAC data units received from the particular second communication device, and ii) the second acknowledgement information is generated to acknowledge a second subset of the plurality of MAC data units received from the particular second communication device.

The first subset of the plurality of MAC data units and the second subset of the plurality of MAC data units comprise MAC data units of a first traffic class.

Generating the acknowledgment data unit includes generating the acknowledgment data unit such that the second acknowledgment information field corresponding to the particular second communication device immediately follows the first acknowledgment information field corresponding to the particular second communication device.

Generating the one or more acknowledgement information fields additionally includes generating a third acknowledgement information field corresponding to the particular second communication device.

A third acknowledgement information field is generated to acknowledge a third subset of the plurality of MAC data units received from the particular second communication device, the third subset of the plurality of MAC data units including MAC data units of a second traffic different from the first traffic class.

Generating the one or more acknowledgement information fields additionally includes generating a third acknowledgement information field corresponding to an additional second communication device of the one or more second communication devices.

A third acknowledgement information field is generated to acknowledge at least some of the plurality of MAC data units received from the further second communication device.

The first acknowledgement information field additionally comprises a further length indication, wherein a value of the length indication is interpreted based on a value of the further length indication.

The length indication is interpreted as: i) indicating a first length (the first length being selected from a first set of predetermined lengths) if the further length indication is set to a first value; or ii) if the further length indication is set to a second value, indicating a second length different from the first length (the second length being selected from a second set of predetermined lengths different from the first set of predetermined lengths).

The acknowledgement field includes a bitmap indicating a length, wherein respective bits of the bitmap indicate acknowledgements of respective ones of at least some of the plurality of MAC data units received from the particular second communication device.

The particular second communication device conforms to a first communication protocol that supports aggregation of a first maximum number of MAC data units of the aggregated MAC data units.

Generating one or more acknowledgement information fields includes generating: i) a single acknowledgement information field corresponding to a further second communication device of the one or more second communication devices, the further second communication device conforming to a second communication protocol supporting aggregation of a second maximum number of MAC data units of the aggregated MAC data units, wherein the second maximum number of MAC data units is less than the first maximum number of MAC data units, and ii) a plurality of acknowledgement information fields corresponding to the particular second communication device, respective acknowledgement fields of the plurality of acknowledgement fields a) conforming to the first communication protocol, and ii) having a maximum length corresponding to the second maximum number of MAC data units supported by the second communication protocol.

In other embodiments, the first communication device includes any suitable combination of one or more of the following features.

The one or more integrated circuits are additionally configured to generate a second acknowledgement information field corresponding to the particular second communication device, wherein i) the first acknowledgement information field is generated to acknowledge a first subset of the plurality of MAC data units received from the particular second communication device, and ii) the second acknowledgement information is generated to acknowledge a second subset of the plurality of MAC data units received from the particular second communication device.

The one or more integrated circuits are configured to generate the acknowledgment data unit such that the second acknowledgment information field corresponding to the particular second communication device immediately follows the first acknowledgment information field corresponding to the particular second communication device.

The one or more integrated circuits are additionally configured to generate a third acknowledgement information field corresponding to the particular second communication device.

The one or more integrated circuits are additionally configured to generate a third acknowledgement information field corresponding to an additional second communication device of the one or more second communication devices.

The one or more integrated circuits are configured to generate the one or more acknowledgement information fields by at least generating: i) a single acknowledgement information field corresponding to a further second communication device of the one or more second communication devices, the further second communication device conforming to a second communication protocol supporting aggregation of a second maximum number of MAC data units of the aggregated MAC data units, wherein the second maximum number of MAC data units is less than the first maximum number of MAC data units, and ii) a plurality of acknowledgement information fields corresponding to the particular second communication device, respective acknowledgement fields of the plurality of acknowledgement fields a) conforming to the first communication protocol, and ii) having a maximum length corresponding to the second maximum number of MAC data units supported by the second communication protocol.

At least some of the various blocks, operations, and techniques described above may be implemented with hardware, a processor executing firmware instructions, a processor executing software instructions, or any combination thereof. When implemented with a processor executing software or firmware instructions, the software or firmware instructions may be stored in any computer-readable memory, such as a magnetic disk, optical disk or other storage medium, RAM or ROM or flash memory, a processor, a hard disk drive, an optical disk drive, a 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 include one or more discrete components, integrated circuits, Application Specific Integrated Circuits (ASICs), and the like.

Although 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.

Claims

1. A method for acknowledging data units, the method comprising:

receiving, at a first communication device, one or more aggregated Media Access Control (MAC) data units from respective one or more second communication devices, respective ones of the one or more aggregated MAC data units comprising a respective set of a plurality of MAC data units from respective ones of the one or more second communication devices;

generating, at the first communication device, one or more acknowledgement information fields corresponding to the one or more second communication devices, including generating a first acknowledgement information field corresponding to a particular second communication device of the one or more second communication devices, wherein the first acknowledgement field includes: i) a length indication indicating a length of an acknowledgement field, and ii) the acknowledgement field indicating the length, wherein the acknowledgement field includes respective acknowledgement information for at least some of the plurality of MAC data units received from the particular second communication device, and wherein the length of the acknowledgement field is determined based at least in part on a buffer size previously negotiated in an acknowledgement setup procedure conducted between the first communication device and the particular second communication device;

generating, at the first communications device, an acknowledgement data unit to include the one or more acknowledgement information fields; and

transmitting the acknowledgment data unit from the first communication device to the one or more second communication devices.

2. The method of claim 1, wherein generating the one or more acknowledgement information fields further comprises: generating a second acknowledgement information field corresponding to the particular second communication device, wherein i) the first acknowledgement information field is generated to acknowledge a first subset of the plurality of MAC data units received from the particular second communication device, and ii) the second acknowledgement information is generated to acknowledge a second subset of the plurality of MAC data units received from the particular second communication device.

3. The method of claim 2, wherein the first subset of the plurality of MAC data units and the second subset of the plurality of MAC data units comprise MAC data units of a first traffic class.

4. The method of claim 2, wherein generating the acknowledgment data unit comprises: generating the acknowledgment data unit such that the second acknowledgment information field corresponding to the particular second communication device immediately follows the first acknowledgment information field corresponding to the particular second communication device.

5. The method of claim 3, wherein generating the one or more acknowledgement information fields further comprises: generating a third acknowledgement information field corresponding to the particular second communication device, wherein the third acknowledgement information field is generated to acknowledge a third subset of the plurality of MAC data units received from the particular second communication device, the third subset of the plurality of MAC data units including MAC data units of a second traffic different from the first traffic class.

6. The method of claim 1, wherein generating the one or more acknowledgement information fields further comprises: generating a third acknowledgement information field corresponding to a further second communication device of the one or more second communication devices, wherein the third acknowledgement information field is generated to acknowledge at least some of the plurality of MAC data units received from the further second communication device.

7. The method of claim 1, the first acknowledgement information field additionally comprising a further length indication, wherein a value of the length indication is interpreted based on a value of the further length indication.

8. The method according to claim 7, wherein the length indication is interpreted as i) indicating a first length if the further length indication is set to a first value, the first length being selected from a first set of predetermined lengths; or ii) if the further length indication is set to a second value, indicating a second length different from the first length, the second length being selected from a second set of predetermined lengths different from the first set of predetermined lengths.

9. The method of claim 1, wherein the acknowledgement field comprises a bitmap of the indicated length, wherein respective bits of the bitmap indicate acknowledgements of respective ones of the at least some of the plurality of MAC data units received from the particular second communication device.

10. The method of claim 1, wherein

The particular second communication device conforms to a first communication protocol that supports aggregation of a first maximum number of MAC data units of the aggregated MAC data units, and

generating the one or more acknowledgement information fields comprises generating

i) A single acknowledgement information field corresponding to a further second communication device of the one or more second communication devices, the further second communication device conforming to a second communication protocol supporting aggregation of a second maximum number of MAC data units of aggregated MAC data units, wherein the second maximum number of MAC data units is less than the first maximum number of MAC data units, and

ii) a plurality of acknowledgement information fields corresponding to the particular second communication device, respective ones of the plurality of acknowledgement fields a) conforming to the first communication protocol, and ii) having a maximum length corresponding to the second maximum number of MAC data units supported by the second communication protocol.

11. A first communications device, comprising:

a network interface having one or more integrated circuits configured to

Receiving one or more aggregated Media Access Control (MAC) data units from respective one or more second communication devices, respective ones of the one or more aggregated MAC data units comprising respective sets of a plurality of MAC data units from respective ones of the one or more second communication devices, generating one or more acknowledgement information fields corresponding to the one or more second communication devices, including generating a first acknowledgement information field corresponding to a particular second communication device of the one or more second communication devices, wherein the first acknowledgement field comprises: i) a length indication indicating a length of an acknowledgement field, and ii) the acknowledgement field indicating the length, wherein the acknowledgement field includes respective acknowledgement information for at least some of the plurality of MAC data units received from the particular second communication device, and wherein the length of the acknowledgement field is determined based at least in part on a buffer size previously negotiated in an acknowledgement setup procedure conducted between the first communication device and the particular second communication device,

generating an acknowledgement data unit to include at least the first acknowledgement information field; and

causing the acknowledgment data unit to be transmitted to the one or more second communication devices.

12. The first communication device of claim 11, wherein the one or more integrated circuits are additionally configured to generate a second acknowledgement information field corresponding to the particular second communication device, wherein i) the corresponding first acknowledgement information field is generated to acknowledge a first subset of the plurality of MAC data units received from the particular second communication device, and ii) the second acknowledgement information is generated to acknowledge a second subset of the plurality of MAC data units received from the particular second communication device.

13. The first communications device of claim 12, wherein said first subset of said plurality of MAC data units and said second subset of said plurality of MAC data units comprise MAC data units of a first traffic class.

14. The first communication device of claim 12, wherein the one or more integrated circuits are configured to generate the acknowledgment data unit such that the second acknowledgment information field corresponding to the particular second communication device immediately follows the first acknowledgment information field corresponding to the particular second communication device.

15. The first communication device of claim 13, wherein the one or more integrated circuits are additionally configured to generate a third acknowledgement information field corresponding to the particular second communication device, wherein the third acknowledgement information field is generated to acknowledge a third subset of the plurality of MAC data units received from the particular second communication device, the third subset of the plurality of MAC data units including MAC data units of a second traffic different from the first traffic class.

16. The first communication device of claim 13, wherein the one or more integrated circuits are additionally configured to generate a third acknowledgement information field corresponding to an additional second communication device of the one or more second communication devices, wherein the third acknowledgement information field is generated to acknowledge at least some of the plurality of MAC data units received from the additional second communication device.

17. The first communication device of claim 11, the first acknowledgement information field additionally comprising a further length indication, wherein a value of the length indication is interpreted based on a value of the further length indication.

18. The first communication device of claim 17, wherein the length indication is interpreted as i) indicating a first length if the further length indication is set to a first value, the first length being selected from a first set of predetermined lengths; or ii) if the further length indication is set to a second value, indicating a second length different from the first length, the second length being selected from a second set of predetermined lengths different from the first set of predetermined lengths.

19. The first communication device of claim 11, wherein the acknowledgement field comprises a bitmap of the indicated length, wherein respective bits of the bitmap indicate acknowledgements of respective ones of the at least some of the plurality of MAC data units received from the particular second communication device.

20. The first communication device of claim 11, wherein

the one or more integrated circuits are configured to generate the one or more acknowledgement information fields by at least generating: