Patent Description:
Certain aspects of the present disclosure generally relate to wireless communications and, more particularly, to using a shortened block acknowledgement (BlockAck) frame capable of acknowledging fragments.

Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks.

In order to address the issue of increasing bandwidth requirements that are demanded for wireless communications systems, different schemes are being developed. Once such scheme allows multiple user terminals to communicate with a single access point by sharing the channel resources while achieving high data throughputs. Multiple Input Multiple Output (MIMO) technology represents one such approach that has emerged as a popular technique for communication systems, as for example described in <CIT>, <CIT>, and <CIT>. MIMO technology has been adopted in several wireless communications standards such as the Institute of Electrical and Electronics Engineers (IEEE) <NUM> standard. The IEEE <NUM> denotes a set of Wireless Local Area Network (WLAN) air interface standards developed by the IEEE <NUM> committee for short-range communications (e.g., tens of meters to a few hundred meters). Another scheme to achieve greater throughput is HEW (High Efficiency WiFi or High Efficiency WLAN) being developed by the IEEE <NUM>. 11ax task force. The goal of this scheme is to achieve a throughput 4x that of IEEE <NUM>.

Aspects of the present disclosure provide techniques for allowing data units to be sent as multiple fragments that may be collectively or separately acknowledged. As will be described in greater detail below, such fragmentation may result in efficient use of uplink and downlink resources. In some cases, fragmentation parameters may be negotiated to achieve certain objectives, such as reducing the amount of memory and processing resources used by both originating and receiving devices to process fragmented transmissions.

Rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the.

Although particular aspects are described herein, many variations and permutations of these aspects fall within the scope of the disclosure. Although some benefits and advantages of the preferred aspects are mentioned, the scope of the disclosure is not intended to be limited to particular benefits, uses, or objectives. Rather, aspects of the disclosure are intended to be broadly applicable to different wireless technologies, system configurations, networks, and transmission protocols, some of which are illustrated by way of example in the figures and in the following description of the preferred aspects. The detailed description and drawings are merely illustrative of the disclosure rather than limiting, the scope of the disclosure being defined by the appended claims.

The techniques described herein may be used for various broadband wireless communication systems, including communication systems that are based on an orthogonal multiplexing scheme. Examples of such communication systems include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) system. An SDMA system may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots, each time slot being assigned to different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers. In general, modulation symbols are sent in the frequency domain with OFDM and in the time domain with SC-FDMA.

The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of wired or wireless apparatuses (e.g., nodes). In some aspects, a wireless node implemented in accordance with the teachings herein may comprise an access point or an access terminal.

An access point ("AP") may comprise, be implemented as, or known as a Node B, Radio Network Controller ("RNC"), evolved Node B (eNB), Base Station Controller ("BSC"), Base Transceiver Station ("BTS"), Base Station ("BS"), Transceiver Function ("TF"), Radio Router, Radio Transceiver, Basic Service Set ("BSS"), Extended Service Set ("ESS"), Radio Base Station ("RBS"), or some other terminology.

An access terminal ("AT") may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, user equipment (UE), a user station, or some other terminology. In some implementations, an access terminal may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol ("SIP") phone, a wireless local loop ("WLL") station, a personal digital assistant ("PDA"), a handheld device having wireless connection capability, a Station ("STA"), or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or smart phone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device that is configured to communicate via a wireless or wired medium. In some aspects, the AT may be a wireless node. Such wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link.

<FIG> illustrates a wireless communications system <NUM> in which aspects of the disclosure may be performed. For example, a user terminal <NUM> (or a processing system therein) may receive a plurality of protocol data units (PDUs), determine whether each of the PDUs was successfully received (e.g., from the access point <NUM>) and whether each of the PDUs is associated with a non-fragmented service data unit (SDU) or a fragmented SDU; and output for transmission a shortened block acknowledgment (BlockAck) frame comprising a bitmap field indicating a receive status for the non-fragmented and fragmented SDUs based on the determination.

The system <NUM> may be, for example, a multiple-access multiple-input multiple-output (MIMO) system with access points and user terminals. For simplicity, only one access point <NUM> is shown in <FIG>. An access point is generally a fixed station that communicates with the user terminals and may also be referred to as a base station or some other terminology. A user terminal may be fixed or mobile and may also be referred to as a mobile station, a wireless device, or some other terminology. Access point <NUM> may communicate with one or more user terminals <NUM> at any given moment on the downlink and uplink. The downlink (i.e., forward link) is the communication link from the access point to the user terminals, and the uplink (i.e., reverse link) is the communication link from the user terminals to the access point. A user terminal may also communicate peer-to-peer with another user terminal.

A system controller <NUM> may provide coordination and control for these APs and/or other systems. The APs may be managed by the system controller <NUM>, for example, which may handle adjustments to radio frequency power, channels, authentication, and security. The system controller <NUM> may communicate with the APs via a backhaul. The APs may also communicate with one another, e.g., directly or indirectly via a wireless or wireline backhaul.

While portions of the following disclosure will describe user terminals <NUM> capable of communicating via Spatial Division Multiple Access (SDMA), for certain aspects, the user terminals <NUM> may also include some user terminals that do not support SDMA. Thus, for such aspects, an AP <NUM> may be configured to communicate with both SDMA and non-SDMA user terminals. This approach may conveniently allow older versions of user terminals ("legacy" stations) to remain deployed in an enterprise, extending their useful lifetime, while allowing newer SDMA user terminals to be introduced as deemed appropriate.

The system <NUM> employs multiple transmit and multiple receive antennas for data transmission on the downlink and uplink. The access point <NUM> is equipped with Nap antennas and represents the multiple-input (MI) for downlink transmissions and the multiple-output (MO) for uplink transmissions. A set of K selected user terminals <NUM> collectively represents the multiple-output for downlink transmissions and the multiple-input for uplink transmissions. For pure SDMA, it is desired to have Nap ≥ K ≥ <NUM> if the data symbol streams for the K user terminals are not multiplexed in code, frequency or time by some means. K may be greater than Nap if the data symbol streams can be multiplexed using TDMA technique, different code channels with CDMA, disjoint sets of subbands with OFDM, and so on. Each selected user terminal transmits user-specific data to and/or receives user-specific data from the access point. In general, each selected user terminal may be equipped with one or multiple antennas (i.e., Nut ≥ <NUM>). The K selected user terminals can have the same or different number of antennas.

The system <NUM> may be a time division duplex (TDD) system or a frequency division duplex (FDD) system. For a TDD system, the downlink and uplink share the same frequency band. For an FDD system, the downlink and uplink use different frequency bands. The system <NUM> may also utilize a single carrier or multiple carriers for transmission. Each user terminal may be equipped with a single antenna (e.g., in order to keep costs down) or multiple antennas (e.g., where the additional cost can be supported). The system <NUM> may also be a TDMA system if the user terminals <NUM> share the same frequency channel by dividing transmission/reception into different time slots, each time slot being assigned to different user terminal <NUM>.

<FIG> illustrates a block diagram of a system <NUM> in which aspects of the present disclosure may be performed. For example, the access point <NUM> (or a processing system therein) may output a plurality of PDUs for transmission, wherein each of the PDUs is associated with a non-fragmented SDU or a fragmented SDU; receive a shortened BlockAck frame comprising a bitmap field (e.g., a Block Ack bitmap field) indicating a receive status for the non-fragmented and fragmented SDUs; and process the bitmap field in the shortened BlockAck frame to determine whether the non-fragmented and fragmented SDUs were successfully received.

The system <NUM> may be, for example, a MIMO system with access point <NUM> and two user terminals <NUM> and 120x. The access point <NUM> is equipped with Nap antennas 224a through 224ap. User terminal <NUM> is equipped with Nut,m antennas 252ma through 252mu, and user terminal 120x is equipped with Nut,x antennas 252xa through 252xu. The access point <NUM> is a transmitting entity for the downlink and a receiving entity for the uplink. Each user terminal <NUM> is a transmitting entity for the uplink and a receiving entity for the downlink. As used herein, a "transmitting entity" is an independently operated apparatus or device (e.g., an AP or STA) capable of transmitting data via a wireless channel, and a "receiving entity" is an independently operated apparatus or device (e.g., an AP or STA) capable of receiving data via a wireless channel. In the following description, the subscript "dn" denotes the downlink, the subscript "up" denotes the uplink, Nup user terminals are selected for simultaneous transmission on the uplink, Ndn user terminals are selected for simultaneous transmission on the downlink, Nup may or may not be equal to Ndn, and Nup and Ndn may be static values or can change for each scheduling interval. The beam-steering or some other spatial processing technique may be used at the access point and user terminal.

On the uplink, at each user terminal <NUM> selected for uplink transmission, a transmit (TX) data processor <NUM> receives traffic data from a data source <NUM> and control data from a controller <NUM>. The controller <NUM> may be coupled with a memory <NUM>. TX data processor <NUM> processes (e.g., encodes, interleaves, and modulates) the traffic data for the user terminal based on the coding and modulation schemes associated with the rate selected for the user terminal and provides a data symbol stream. A TX spatial processor <NUM> performs spatial processing on the data symbol stream and provides Nut,m transmit symbol streams for the Nut,m antennas. Each transmitter unit (TMTR) <NUM> receives and processes (e.g., converts to analog, amplifies, filters, and frequency upconverts) a respective transmit symbol stream to generate an uplink signal. Nut,m transmitter units <NUM> provide Nut,m uplink signals for transmission from Nut,m antennas <NUM> to the access point.

Nup user terminals may be scheduled for simultaneous transmission on the uplink. Each of these user terminals performs spatial processing on its data symbol stream and transmits its set of transmit symbol streams on the uplink to the access point.

At access point <NUM>, Nap antennas 224a through 224ap receive the uplink signals from all Nup user terminals transmitting on the uplink. Each antenna <NUM> provides a received signal to a respective receiver unit (RCVR) <NUM>. Each receiver unit <NUM> performs processing complementary to that performed by transmitter unit <NUM> and provides a received symbol stream. An RX spatial processor <NUM> performs receiver spatial processing on the Nap received symbol streams from Nap receiver units <NUM> and provides Nup recovered uplink data symbol streams. The receiver spatial processing is performed in accordance with the channel correlation matrix inversion (CCMI), minimum mean square error (MMSE), soft interference cancellation (SIC), or some other technique. Each recovered uplink data symbol stream is an estimate of a data symbol stream transmitted by a respective user terminal. An RX data processor <NUM> processes (e.g., demodulates, deinterleaves, and decodes) each recovered uplink data symbol stream in accordance with the rate used for that stream to obtain decoded data. The decoded data for each user terminal may be provided to a data sink <NUM> for storage and/or a controller <NUM> for further processing. The controller <NUM> may be coupled with a memory <NUM>.

On the downlink, at access point <NUM>, a TX data processor <NUM> receives traffic data from a data source <NUM> for Ndn user terminals scheduled for downlink transmission, control data from a controller <NUM>, and possibly other data from a scheduler <NUM>. The various types of data may be sent on different transport channels. TX data processor <NUM> processes (e.g., encodes, interleaves, and modulates) the traffic data for each user terminal based on the rate selected for that user terminal. TX data processor <NUM> provides Ndn downlink data symbol streams for the Ndn user terminals. A TX spatial processor <NUM> performs spatial processing (such as a precoding or beamforming, as described in the present disclosure) on the Ndn downlink data symbol streams, and provides Nap transmit symbol streams for the Nap antennas. Each transmitter unit <NUM> receives and processes a respective transmit symbol stream to generate a downlink signal. Nap transmitter units <NUM> providing Nap downlink signals for transmission from Nap antennas <NUM> to the user terminals. The decoded data for each user terminal may be provided to a data sink <NUM> for storage and/or a controller <NUM> for further processing.

At each user terminal <NUM>, Nut,m antennas <NUM> receive the Nap downlink signals from access point <NUM>. Each receiver unit <NUM> processes a received signal from an associated antenna <NUM> and provides a received symbol stream. An RX spatial processor <NUM> performs receiver spatial processing on Nut,m received symbol streams from Nut,m receiver units <NUM> and provides a recovered downlink data symbol stream for the user terminal. The receiver spatial processing is performed in accordance with the CCMI, MMSE or some other technique. An RX data processor <NUM> processes (e.g., demodulates, deinterleaves and decodes) the recovered downlink data symbol stream to obtain decoded data for the user terminal.

At each user terminal <NUM>, a channel estimator <NUM> estimates the downlink channel response and provides downlink channel estimates, which may include channel gain estimates, SNR estimates, noise variance and so on. Similarly, at access point <NUM>, a channel estimator <NUM> estimates the uplink channel response and provides uplink channel estimates. Controller <NUM> for each user terminal typically derives the spatial filter matrix for the user terminal based on the downlink channel response matrix Hdn,m for that user terminal. Controller <NUM> derives the spatial filter matrix for the access point based on the effective uplink channel response matrix Hup,eff. Controller <NUM> for each user terminal may send feedback information (e.g., the downlink and/or uplink eigenvectors, eigenvalues, SNR estimates, and so on) to the access point. Controllers <NUM> and <NUM> also control the operation of various processing units at access point <NUM> and user terminal <NUM>, respectively.

<FIG> illustrates various components that may be utilized in a wireless device <NUM> that may be employed within the system <NUM>. The wireless device <NUM> is an example of a device that may be configured to implement the various methods described herein. For example, the wireless device may implement operations <NUM> or <NUM> illustrated in <FIG> and <FIG>, respectively. The wireless device <NUM> may be an access point <NUM> or a user terminal <NUM>.

The wireless device <NUM> may include a processor <NUM> which controls operation of the wireless device <NUM>. The processor <NUM> may also be referred to as a central processing unit (CPU). Memory <NUM>, which may include both read-only memory (ROM) and random access memory (RAM), provides instructions and data to the processor <NUM>. A portion of the memory <NUM> may also include non-volatile random access memory (NVRAM). The instructions in the memory <NUM> may be executable to implement the methods described herein.

The wireless device <NUM> may also include a housing <NUM> that may include a transmitter <NUM> and a receiver <NUM> to allow transmission and reception of data between the wireless device <NUM> and a remote node. The transmitter <NUM> and receiver <NUM> may be combined into a transceiver <NUM>. A single or a plurality of transmit antennas <NUM> may be attached to the housing <NUM> and electrically coupled to the transceiver <NUM>. The wireless device <NUM> may also include (not shown) multiple transmitters, multiple receivers, and multiple transceivers.

The wireless device <NUM> may also include a signal detector <NUM> that may be used in an effort to detect and quantify the level of signals received by the transceiver <NUM>. The signal detector <NUM> may detect such signals as total energy, energy per subcarrier per symbol, power spectral density and other signals. The wireless device <NUM> may also include a digital signal processor (DSP) <NUM> for use in processing signals.

The various components of the wireless device <NUM> may be coupled together by a bus system <NUM>, which may include a power bus, a control signal bus, and a status signal bus in addition to a data bus.

As noted above, aspects of the present disclosure provide techniques for sending data units using fragmentation, which may result in efficient use of uplink and downlink resources. As used herein, the term fragmentation generally refers to the process of partitioning a data unit, such as a MAC service data unit (MSDU) or MAC management protocol data unit (MMPDU), into smaller data units (e.g., MPDUs) for transmission.

In some cases, the fragment length may be the same for all fragments except for the last, which may be smaller than the others to just accommodate a remaining portion. Additionally, the length of each fragment (except for the last fragment), may be an even number of octets. The length of each fragment may be limited to never exceed a certain fragmentation threshold (e.g., with the threshold specified by a parameter dot11FragmentationThreshold in IEEE <NUM>). In some cases, for example, if security encapsulation is invoked, the fragment length may exceed this threshold due to encapsulation overhead. Once a fragment is transmitted for the first time, the frame body content and length may be fixed until the fragment is successfully delivered to a recipient station (STA).

Defragmentation generally refers to the process of reassembling an MSDU/MMPDU from its constituent fragments. Reassembly is generally performed by combining fragments in order of fragment number (FN) subfield. A mechanism may be utilized to identify a last fragment. For example, a fragment with the More Fragments bit equal to <NUM> indicates the last fragment for this particular MSDU/MMPDU, based on its sequence number (SN).

In certain wireless communications systems, such as IEEE <NUM>. 11ax (also known as high efficiency wireless (HEW) or high efficiency wireless local area network (WLAN)), data rates of <NUM> kbps and lower are being proposed (e.g., MCS0 in <NUM>), which suggests the use of fragmentation. In multi-user (MU) operation, where an AP communicates with multiple STAs, the AP may allocate resources by sending a trigger frame that provides the resource allocations per-STA for the rest of the granted transmission opportunity (TXOP).

In an effort to fully use the allocated resource, the STA may fragment the MSDU on-the-fly. The fragment length and the number of fragments may be determined once the STA knows the allocated resource for its current transmission. The fragmentation threshold (that controls the length of fragments) may be changed dynamically every MSDU to fully use the granted TXOP. In certain embodiments, the fragmentation threshold may control the length of each fragment of the same MSDU. The first fragment may be transmitted during the allocated resource in the granted TXOP. The remaining n-<NUM> fragments may be queued for transmission in subsequent TXOPs. This baseline method generates multiple fragments, each of which are carried in an MPDU. The lower the payload of the fragment, the larger the number of fragments (i.e., the higher the impact of the PHY/MAC/security overhead).

To remove some of the PHY overhead, it may be useful to allow aggregated MPDU (A-MPDU) aggregation of fragments (with other fragments or full MPDUs), although this adds some overhead from A-MPDU delimiters and padding. As an example, such aggregation of fragments may be performed in an effort to efficiently fill a low data rate allocation (e.g., efficiently filling an allocation may entail <NUM> bytes of data: a 1500B non-fragmented MSDU plus a 500B fragment of another, fragmented MSDU). As another example, A-MPDU aggregation of fragments may be done to efficiently transmit the remaining fragment of an MSDU in a subsequent transmit opportunity (TXOP). Retransmission in a subsequent TXOP may entail fragment aggregation. Once a packet has been fragmented and transmitted, it should be retransmitted in the same manner; otherwise, reassembly (defragmentation) is complicated. For certain aspects, an A-MPDU may contain non-fragmented MSDUs and at most one fragment of an MSDU (i.e., an A-MSDU cannot contain more than one fragment of the same MSDU).

<FIG> illustrates an example aggregation of fragment MPDUs in an A-MPDU <NUM>, in accordance with certain aspects of the present disclosure. In the illustrated example, MSDUs <NUM> with sequence numbers <NUM> and <NUM> (SN=<NUM> and SN=<NUM>) are unfragmented, while MSDU <NUM> with sequence number <NUM> (SN=<NUM>) is fragmented, with three fragments shown, with fragment numbers <NUM>, <NUM>, and <NUM> (FN=<NUM>, FN=<NUM>, and FN=<NUM>). As illustrated, a more fragment flag (MF) may be set to <NUM> in the first two fragments to indicate there are more fragments to come, while MF is set to <NUM> in the third fragment, indicating the last fragment.

Such fragment aggregation may be allowed without changing the basics of the immediate BlockAck procedure (e.g., each MSDU <NUM> may occupy one location of the BlockAck buffer and fragment MPDUs occupy independent buffers) and the fragmentation/defragmentation procedure. However, the basic BlockAck frame, capable of acknowledging up to <NUM> MSDUs having up to <NUM> fragments each, has a bitmap field with a length of <NUM> octets. A compressed BlockAck may be used that acknowledges up to <NUM> MSDUs and has a bitmap field with a length of only <NUM> octets. While shorter than a normal BlockAck frame (e.g., defined by a standard), this type of compressed BlockAck frame does not acknowledge fragmented MSDUs or fragments thereof.

To address this, aspects of the present disclosure provide a BlockAck frame capable of acknowledging fragmented and non-fragmented MSDUs, but having a reduced size compared to a basic BlockAck frame. In some cases, shortened or "compressed" BlockAck frame may reduce overhead and be capable of acknowledging fragmented MSDUs without significant changes in signaling of the basic BlockAck frame.

In some cases, a recipient may select a type of Block Ack Frame on a per A-MPDU basis. After receiving an A-MPDU, according to this option, the recipient may generate a BlockAck frame that is either a modified version of the compressed BlockAck frame (one type of shortened BlockAck frame) or a basic BlockAck Frame. The shortened BlockAck frame (labeled "Compressed BlockAck*" in <FIG>) may have the same length as a compressed BlockAck (<NUM> octets with an <NUM>-octet bitmap). However, each bit in the shortened frame's bitmap may indicate the receive status of a non-fragment (A-)MSDU and one of the following: (<NUM>) the first fragment of the fragmented MSDU; (<NUM>) all the fragments of the MSDU; or (<NUM>) the sole fragment of the MSDU that is contained in the A-MPDU that elicited the BlockAck frame. If a basic BlockAck frame is selected instead, this frame has a length of <NUM> octets and a bitmap having a length of <NUM> octets. Each bit in the basic frame's bitmap indicates the receive status of each MPDU (fragment or non-fragment) within the receive block acknowledgment window.

In some cases, the originator may receive a shortened BlockAck frame with partial information, which may occur when: (<NUM>) there is no receive status indication for fragments other than the first fragment of a given sequence number (SN); (<NUM>) there is an unsuccessful receive status indication for at least one of the fragments of a given SN (i.e., bit set to <NUM> for the SN); or (<NUM>) there is no receive status for the sole fragment contained in the A-MPDU that elicited the BlockAck frame. If the originator receives a shortened BlockAck frame with partial information, then the originator may either solicit a basic BlockAck frame by sending a block acknowledgement request (BAR) frame or retransmit all the fragments of the MSDU that had an unsuccessful receive status.

One disadvantage with a recipient selecting the type of Block Ack frame is that a basic BlockAck frame may be generated as a response in certain situations. The frequency of this happening may depend on the number of fragments included in an A-MPDU. Rather than use either a modified version of the compressed BlockAck frame (<NUM> octets) or the basic BlockAck frame (<NUM> octets), other options are described below for a shortened BlockAck frame having a reduced length compared to the basic BlockAck frame, but whose information content is not as limited as the modified version of the compressed BlockAck frame.

As illustrated in <FIG>, in some cases, a shortened BlockAck frame <NUM> having a variable-length bitmap field <NUM> may be used. This bitmap size may be dependent on a number of fragments and may be variable, for example, between <NUM> and <NUM> octets, for example. The shortened BlockAck frame may be used, for example, to acknowledge <NUM> (A-)MSDUs and fragments up to the Fragment Number (FN) subfield in the Block Ack Starting Sequence Control (SSC) field <NUM> in the shortened BlockAck frame. <FIG> illustrates how an originator and recipient may track or "keep score" of which MSDUs/fragments have been successfully acknowledged. As will be described in greater detail below, in some cases, parameter may be negotiated to limit the memory overhead required for such tracking. For example, an originator and recipient may negotiate a maximum number of fragmented transmissions that may be handled concurrently and/or a timer value used to flush fragments (if not all fragments of a fragmented transmission are successfully received, even successfully received fragments may be discarded).

The value of a Fragment Number subfield in the Block Ack SSC field may indicate the number of fragments per sequence number (SN) contained in the BlockAck bitmap field. When FN = <NUM>, non-fragmented MSDUs and the first fragment of fragmented MSDUs may be acknowledged by the shortened BlockAck frame. For other aspects, when FN = <NUM>, at most one fragment of each fragmented MSDU that is contained in the A-MPDU that elicited the shortened BlockAck frame (or contained in the A-MPDU that was transmitted between two A-MPDUs that elicited shortened BlockAck frames) and non-fragmented MSDUs may be acknowledged by the shortened BlockAck frame. If up to <NUM> MSDUs may be acknowledged, this leads to a BlockAck bitmap field having a length of <NUM> octets, which is the same length as the BlockAck bitmap field in a compressed BlockAck frame. When FN = N, non-fragment MSDUs and up to N+<NUM> fragments of fragmented MSDUs may be acknowledged, leading to a bitmap field length of <NUM>*(N+<NUM>) octets. In the worst case (e.g., where <NUM> MSDUs have <NUM> fragments), the "shortened" BlockAck frame having a variable-length bitmap field may be the same length as a basic BlockAck frame (<NUM> Octets, with a bitmap field length of <NUM> octets).

As illustrated in <FIG>, in some cases, a shortened BlockAck frame <NUM> having a fixed (e.g., constant-length) bitmap field may be used for fragment-dependent signaling. In some cases, the length of the bitmap field for the shortened BlockAck frame may be <NUM> octets, and the length of the shortened BlockAck frame may be the same as that of a compressed BlockAck frame (<NUM> octets).

Similar to the case described above with reference to <FIG>, a value of the Fragment Number subfield in the Block Ack SSC field may indicate the number of fragments per SN contained in the BlockAck bitmap field. When FN = <NUM>, non-fragmented MSDUs and the first fragment of fragmented MSDUs may be acknowledged by the shortened BlockAck frame. For other aspects, when FN = <NUM>, at most one fragment of each fragmented MSDU that is contained in the A-MPDU that elicited the shortened BlockAck frame (or contained in the A-MPDU that was transmitted between two A-MPDUs that elicited shortened BlockAck frames) and non-fragmented MSDUs may be acknowledged by the shortened BlockAck frame. With a bitmap field having a length of <NUM> octets, for example, up to <NUM> (A-)MSDUs may be acknowledged. When FN = N, non-fragment MSDUs and up to N+<NUM> fragments of fragmented MSDUs may be acknowledged.

With a constant-length bitmap field, however, the shortened BlockAck frame may acknowledge up to ceil(M/(N+<NUM>)) (A-)MSDUs, where M is the fixed bitmap length in bits (e.g., M= <NUM> bits = <NUM> octets). In other words, the number of MSDUs that may be acknowledged by each shortened BlockAck frame with a constant-length bitmap field varies according to the FN. In some cases, only a portion of the fragments of the last MSDU may be acknowledged.

In some cases, for this option (i.e., at least one MSDU in the A-MPDU is fragmented in <NUM> fragments) only up to <NUM> MSDUs can be acknowledged (if M = <NUM>). If the number of fragments is lower, then more MSDUs can be acknowledged.

Note that while the description above refers to the use of a Fragment Number subfield (FN) in the Block Ack SSC field, a person having ordinary skill in the art will realize that any such field or subfield that is contained in the BlockAck frame itself may be used to provide the above-described signaling (e.g., the traffic identifier information (TID_INFO) subfield in the BA control field). For example, the shortened BlockAck frame may be defined as a multi-fragment BlockAck frame.

As will be described in greater detail below, a particular variant of a BlockAck frame may be distinguished from the other frame formats, for example, by using a reserved combination of the Multi-TID, Compressed Bitmap, and Group Cast Retries (GCR) subfields of the BA Control field.

For certain aspects, the TID_INFO field for a Multi-Fragment BlockAck frame may indicate the number of MSDUs that can be acknowledged with the frame (e.g., in units of <NUM> or <NUM>, etc.), making it possible to dynamically vary the BlockAck bitmap field as a function of the MSDUs that can be acknowledged. For example, if the TID_INFO is <NUM> and the FN is <NUM>, then the bitmap field may be <NUM> octet in length and carries acknowledgement information for <NUM> MSDUs and the first fragment of the MDSUs.

<FIG> is a flow diagram of example operations <NUM> for outputting a shortened BlockAck frame for transmission, in accordance with certain aspects of the present disclosure. The operations <NUM> may be performed, for example, by an apparatus (e.g., AP <NUM>, user terminal <NUM>, or wireless device <NUM>, or a processing system therein).

The operations <NUM> begin, at block <NUM>, with the apparatus receiving a plurality of protocol data units (PDUs) (e.g., from another apparatus, which may be a user terminal <NUM> or AP <NUM>). The plurality of PDUs may comprise a plurality of media access control (MAC) protocol data units (MPDUs). The plurality of MPDUs may comprise an aggregated MPDU (A-MPDU), for example.

At block <NUM>, the apparatus determines whether each of the PDUs was successfully received. The apparatus also determines whether each of the PDUs is associated with a non-fragmented service data unit (SDU) or a fragmented SDU at block <NUM>. For certain aspects, at least one of the PDUs comprises a fragment of one of the fragmented SDUs.

At block <NUM>, the apparatus outputs a shortened block acknowledgment (BlockAck) frame for transmission. The shortened BlockAck frame includes a bitmap field indicating a receive status for the non-fragmented and fragmented SDUs based on the determination at block <NUM>. In other words, the bits in the bitmap field are populated according to the determination at block <NUM> (e.g., a logic "<NUM>" may indicate that an SDU or a fragment thereof was successfully received, whereas a logic "<NUM>" may indicate the SDU or fragment thereof was not successfully received). For certain aspects, the non-fragmented and fragmented SDUs include non-fragmented and fragmented MAC service data units (MSDUs).

According to certain aspects, the operations <NUM> may further involve the apparatus receiving a block acknowledgement request after outputting the shortened BlockAck frame for transmission at block <NUM>. In this case, the apparatus may output for transmission a basic BlockAck frame in response to the block acknowledgement request. A bitmap field in the basic BlockAck frame may indicate the receive status for the non-fragmented SDUs and each fragment of the fragmented SDUs based on the determination at block <NUM>.

According to certain aspects, the operations <NUM> may further involve the apparatus selecting the shortened BlockAck frame over a basic BlockAck frame before the outputting at block <NUM>.

According to certain aspects, the operations <NUM> further involve the apparatus outputting for transmission another shortened BlockAck frame before the receiving at block <NUM>. In this case, the plurality of PDUs may comprise an A-MPDU, the non-fragmented and fragmented SDUs include non-fragmented and fragmented MSDUs, and the A-MPDU may include at most one fragment for each of the fragmented MSDUs.

<FIG> is a flow diagram of example operations <NUM> for using a shortened BlockAck frame for acknowledging fragmented and non-fragmented service data units (SDUs) (e.g., MSDUs), in accordance with certain aspects of the present disclosure. The operations <NUM> may be performed, for example, by an apparatus (e.g., AP <NUM>, wireless device <NUM>, or user terminal <NUM>, or a processing system therein).

The operations <NUM> begin, at block <NUM>, with the apparatus outputting a plurality of protocol data units (PDUs) for transmission. Each of the PDUs is associated with a non-fragmented SDU or a fragmented SDU. For certain aspects, at least one of the PDUs is a fragment of one of the fragmented SDUs. The plurality of PDUs may comprise a plurality of media access control (MAC) protocol data units (MPDUs). The plurality of MPDUs may comprise an aggregated MPDU (A-MPDU), for example.

At block <NUM>, the apparatus receives a shortened block acknowledgment (BlockAck) frame comprising a bitmap field indicating a receive status for the non-fragmented and fragmented SDUs. The apparatus processes the bitmap field in the shortened BlockAck frame, at block <NUM>, to determine whether the non-fragmented and fragmented SDUs were successfully received.

This particular variant of a BlockAck frame may be distinguished from the other frame formats, for example, by using a reserved combination of the Multi-TID, Compressed Bitmap, and Group Cast Retries (GCR) subfields of the BA Control field. As an example, the settings in the <NUM>th row of table <NUM> in <FIG> may be used to indicate that the frame is a multi-fragment BlockAck frame. For example a Multi-Fragment BlockAck frame may be identified by setting the Multi-TID, Compressed Bitmap, and GCR values to all <NUM>, and the FN described above may, for example, either be indicated in the TID_INFO field of the BA Control field or in the FN subfield of the BlockAck SSC field.

According to certain aspects, the operations <NUM> may further involve the apparatus outputting a block acknowledgement request for transmission. This request may be output after the processing at block <NUM>, for example, where the processing indicated that at least one of the non-fragmented and fragmented SDUs was not successfully received. The apparatus may also receive a basic BlockAck frame in response to the block acknowledgement request. The bitmap field in the basic BlockAck frame may indicate the receive status for each of the non-fragmented SDUs and each fragment of the fragmented SDUs.

According to certain aspects, after the processing at block <NUM> (which indicated that at least one of the fragmented SDUs was not successfully received, for example), the operations <NUM> may further involve the apparatus outputting for retransmission fragments of the at least one of the fragmented SDUs.

As noted above, the bitmap field in the shortened BlockAck frame has a shorter length than a bitmap field in a basic BlockAck frame. In other words, the bitmap field in the shortened BlockAck frame may have a length less than <NUM> octets.

As described with reference to <FIG>, the bitmap field in the shortened BlockAck frame has a fixed length (e.g., <NUM> octets). In this case, a number of the non-fragmented and fragmented SDUs that can be acknowledged by the bitmap field in the shortened BlockAck frame may be variable. For example, the number of the non-fragmented and fragmented SDUs may be up to ceil(M/(N+<NUM>)), where M is the fixed length in bits and where the bitmap field in the shortened BlockAck frame can indicate the receive status for up to N+<NUM> fragments for the fragmented SDUs. The shortened BlockAck frame may include a starting sequence control (SSC) field, and N may be a fragment number (FN) indicated by the SSC field.

In certain embodiments, both N and M can be signaled in the BlockAck frame itself. In such embodiments, any reserved field that precedes the BlockAck Bitmap field can be used for this purpose. In one example, the Fragment Number subfield can be used to signal these values, wherein <NUM> or more bits of the Fragment Number indicate the length of the BlockAck Bitmap field (which could take values that are multiples of an octet (e.g., <NUM> Octets, <NUM> octets, <NUM> Octets <NUM> octets representing the value of M in bytes). In some cases, <NUM> or more of the remaining bits of the Fragment Number could represent the value of N or a function of N (e.g., those remaining bits could indicate values of <NUM>, <NUM>, <NUM>, <NUM> fragments). Any of the bits of the Fragment Number can be used for this purpose. As an example, the <NUM> MSBs of the Fragment Number field can indicate the value of the BlockAck Bitmap and the <NUM> LSBs of the Fragment Number can indicate the value of the Fragment Number. In this example, a value of the <NUM> MSBs equal to <NUM> could indicate a BlockAck Bitmap field size of <NUM> bytes (to be backward compatible with previous versions of the standard), a value equal to <NUM> could indicate <NUM> Octets, a value of <NUM> could indicate <NUM> Octets, and a value of <NUM> could indicate for example <NUM> Octets. Similarly, a value of the <NUM> LSBs equal to <NUM> could indicate no fragments (to be backward compatible as previously mentioned), for example, while a value of <NUM> could indicate <NUM> fragments, a value of <NUM> could indicate <NUM> fragments, and a value of <NUM> could indicate <NUM> fragments. In general, any combination of the values of the Fragment Number subfield can be used to indicate the size of the BlockAck Bitmap length and/or the number of fragments that are being acknowledged, as well.

As described with reference to <FIG>, the bitmap field in the shortened BlockAck frame has a variable length. In this case, the variable length may be indicated by an FN in the shortened BlockAck frame. The shortened BlockAck frame may include an SSC field, and the FN may be indicated by the SSC field. For certain aspects, the FN = <NUM>, and each bit in the bitmap field in the shortened BlockAck frame may indicate the receive status for one of the non-fragmented SDUs or the first fragment of one of the fragmented SDUs. The bitmap field in the shortened BlockAck frame may have a length of <NUM> octets, for example. For certain aspects, the FN is a positive integer, and each bit in the bitmap field in the shortened BlockAck frame may indicate the receive status for one of the non-fragmented SDUs or each fragment of one of the fragmented SDUs. In this case, the FN = N, and the bitmap field in the shortened BlockAck frame may have a length of up to <NUM>*(N+<NUM>) octets, for example.

According to certain aspects, each bit in the bitmap field in the shortened BlockAck frame may indicate the receive status for one of the non-fragmented SDUs or the first fragment of one of the fragmented SDUs. For other aspects, each bit in the bitmap field in the shortened BlockAck frame may indicate the receive status for one of the non-fragmented SDUs or collectively all fragments of one of the fragmented SDUs.

As noted above, in some cases, a particular variant of a BlockAck frame may be distinguished from other frame formats by using a reserved combination of various fields, such as the Multi-TID, Compressed Bitmap, and Group Cast Retries (GCR) subfields of the BA Control field.

Referring to <FIG>, as an example, the settings in the <NUM>th row of table <NUM> may be used to indicate that the frame is a multi-fragment BlockAck frame. As illustrated, a Multi-Fragment BlockAck frame may be identified by setting the Multi-TID, Compressed Bitmap, and GCR values to all <NUM>, and the FN described above may, for example, either be indicated in the TID_INFO field of the BA Control field or in the FN subfield of the BlockAck SSC field.

As illustrated in the example exchange <NUM> of <FIG>, the techniques for fragmentation presented herein may provide an efficient way of using allocated resources in MU transmissions <NUM> initiated by a trigger frame <NUM> sent by an AP. Such fragmentation may provide a means of providing feedback via a compressed Block Ack frame <NUM> (in effect, closing the UL link) for limited range devices. In some cases, a block acknowledgement (Block Ack) protocol may also be provided that allows fragments to be carried in A-MPDUs when sent in MU mode. Such a protocol may help simplify the generation of fragments at an originating device, while reducing memory requirements at both the recipient and originating devices (e.g., by limiting the amount of memory required to keep track of which data units/fragments have been received). In some cases, compressed BlockAck frames <NUM> may be used to acknowledge received fragments sent in an A-MPDU (which may be considered a form of an enhanced HT-Immediate Block Ack protocol).

As noted above, in some cases, STAs may negotiate fragmentation during BA setup. In other words, fragmentation-related parameters may be exchanged during a fragment-enabled BA session. In some cases, this negotiation may be performed during association (when a station associates with an AP). Regarding fragment generation at the originator, fragments may be carried in A-MPDUs under various restrictions specified by the recipient. These restrictions may include, for example, a maximum number (Max #) of concurrent fragmented MSDU/MMPDUs and a maximum number of fragments per MSDU/MMPDU. In some cases, only one fragment per MSDU shall be carried in an A-MPDU. In some cases, there may be no restriction (or dependency) to the length of the fragments.

Fragment acknowledgement at the recipient may be as follows. The recipient may keep full-state information for fragmented MSDU/MMPDUs for the duration of the receive timer. It may be noted that, in some cases, fragmented MSDUs may be discarded after the receive timer has expired and the MSDU may be considered as having not been successfully received even if some fragments were successfully received. The recipient may respond with a compressed BA, in response to an eliciting A-MPDU that contains fragments. In the compressed BA, each bit in the BA Bitmap indicates the receipt status of either a fragment of the MSDU or the full MSDU. According to certain aspects, A-MSDUs may be carried, without fragmentation, within a single QoS data frame.

A STA may be configured to support concurrent reception of fragments of some number of transmissions, for example, at least <NUM> MSDUs or MMPDUs. In some cases, however, a STA receiving more than three fragmented frames may experience a significant increase in the number of frames discarded. Therefore, the STA may be configured to maintain a Receive Timer for each MSDU/MMPDU being received (e.g., min. <NUM>), and fragments may be discarded if the timer exceeds a specified value (e.g., a dotl 1MaxReceiveLifetime).

As noted above, there-may be tradeoffs to consider when deciding whether or not to use fragmentation. For example, in some cases, fragments may not be allowed to be sent in A-MPDUs, except when VHT Single MPDUs. Further, in such an exceptional case, fragments may only be allowed for those TIDs for which an HT-immediate or HT-delayed Block Ack session is not configured. Fragmentation may be beneficial because it may increase reliability when channel characteristics/OBSS activity limit reception reliability, may increase medium efficiency in consideration of the available duration of granted TXOPs, and may allow efficient use of the allocated resources in an MU transmission. However, in some cases, fragmentation may lead to an increased number of MSDUs being discarded. For example, an MSDU may be dropped when the receive MSDU timer expires, even if only one fragment is missing. This may lead to increased memory requirements at the transmitter and receiver as the transmitter and receiver needs to keep track of the payload contents and length for each fragment and partial-state operation during the Block Ack session may not be employed by the receiver. Fragmentation may also lead to an increase in overhead, as each fragment may require its own A-MPDU/MAC/Security headers (e.g., fragmenting <NUM> Bytes in <NUM> fragments could add at least <NUM> Bytes of overhead).

In some cases, devices may negotiate the use of fragmentation during a block acknowledgement (BA) setup procedure. In such cases, an Add Block Acknowledgement (ADDBA) Extension IE in an ADDBA Request and/or response may indicate the use of fragmentation. For example, in such case, an originator may set a No-Fragmentation field in ADDBA Extension element of ADDBA Request to indicate certain parameters.

<FIG> illustrates an example of such an ADDBA Extension element format <NUM> that may be included in an ADDBA request or response. As illustrated, the format <NUM> may have a Fragmentation/No-Fragmentation Field <NUM>. In some cases, this field may be set to a value to indicate whether or not an apparatus intends to transmit fragments (e.g., <NUM> to indicate it intends to transmit fragments, and to <NUM> to indicate it does not intend to transmit fragments).

In some cases, the recipient (or originator) may additionally specify (e.g., as part of a negotiation) various other fragmentation parameters. For example, a recipient may specify a maximum number of fragmented MSDUs (F-MSDUs) that can be supported concurrently (with fragments for each tracked concurrently). As illustrated, this value may be specified in a field <NUM> (e.g., represented as <NUM> bits) containing the maximum number of concurrent fragmented MSDU/MMPDUs that are supported. This parameter may determine how many bits in the BA Bitmap will be maintained at full state by the receiver. The recipient may also specify the receive timer (e.g., represented as <NUM> bits in a field <NUM> of a response) that represents a period after which fragments are discarded (e.g., further attempts to reassemble a fragmented MMPDU or MSDU are terminated). This parameter may help control memory overhead, by limiting how long full state is maintained for a given fragmented MSDU. In some cases, a dynamic fragmentation field (e.g., represented by a single bit in a field of the response) may indicate the dynamic fragmentation mode (e.g., "<NUM>" to indicate support for up to <NUM> dynamic length fragments per MSDU/MMPDU, or "<NUM>" to indicate support for up to <NUM> dynamic length fragments per MSDU/MMPDU).

In some cases, various other parameters related to fragmentation may also be negotiated. As an example, a (receiving) device may indicate allowance (of an originator) to fragment A-MSDUs. For example, during negotiation, a receiving device may use a bit to indicate whether the receiving device supports reception of fragmented A-MSDUs. In some cases, a receiving device may also specify a minimum length of fragments during negotiation. In such cases, all fragments but for a last fragment may be required to be at least the specified minimum length.

In some cases, what may be considered a relatively simplified version of a fragmentation mechanism may also be used. In this case, peer STAs may use a baseline fragmentation mechanism and may negotiate a baseline Block Ack mechanism where the negotiation parameters described above are to be applied.

In some cases, a transmitter may be allowed to aggregate at most one fragment in an A-MPDU. In such cases, on the receiver side, upon reception of an A-MPDU that contains a single MPDU that solicits a response, the receiving device may respond with an Ack frame (regardless of whether the MPDU contains a fragment or a full MSDU). On the other hand, upon reception of an A-MPDU containing more than one MPDU that solicits a response, the receiving device may respond with a BlockAck frame, wherein the BlockAck frame could be a compressed BlockAck, a multi-TID BlockAck, multi-STA BlockAck or a GCR BlockAck frame that additionally contains an indication for indicating the receipt status of the fragment included in the soliciting PPDU. For example, the receiving device may set a bit in the BlockAck frame for a fragment contained in the A-MPDU that is received successfully. Any reserved bit which is currently unused may be used for this purpose (e.g., an unused bit of a Fragment Number may be used for this purpose).

In certain embodiments the transmitter may include more than one fragment in an A-MPDU, in which case the recipient may respond with a control response frame that acknowledges the multiple fragments according to the teachings herein.

Upon reception of a BlockAck Request (BAR), a receiving device may respond with the appropriate response frame. For example, the receiving device may respond with a compressed BlockAck if no fragments have been received for a corresponding BlockAck window. In some cases, the BAR itself may indicate that it solicits a compressed BlockAck. In some cases, the receiving device may respond with a basic (not compressed) BlockAck, for example, if at least one fragment is received (or the BAR itself specifies a basic BlockAck is solicited).

As noted above, during a fragment-enabled BA session, the originator may fragment MSDUs and carry them in an A-MPDU. The recipient may respond acknowledging the A-MPDU with a shortest BA (e.g., the shortest BA frame may be the C-BlockAck frame). For efficient use of allocated UL/DL resources, in some cases, one fragment in an A-MPDU may be enough.

There may be trade-offs when allowing more than one fragment per A-MPDU. For example, while more than one fragment per A-MPDU may provide flexibility to fragment any MSDU in any number of fragment per-TID, doing so may increase processing overhead. For example, both recipient and originator may need to maintain a Receive Timer for each MSDU (e.g., during which all fragments need to be successfully received or they are flushed). In addition, the recipient may need to store the payload for each fragment of each MSDU that is fragmented as fragments are not delivered to upper layers but stored locally until MSDU is derived. This approach may also increase the likelihood of discarded MSDUs due to receive timer expiration (e.g., even if only one fragment is missing) and result in increased implementation complexity due to additional fragmentation/defragmentation procedures, as well as increased overhead as each added fragment requires its own MPDU delimiter/MAC/security headers.

As illustrated in the example exchange <NUM> of <FIG>, in some cases, an originator may decide to use fragmentation "on-the-fly" whenever it determines fragmentation will result in efficient use of resources. In the illustrated example, two MSDUs <NUM> may not be fragmented (Data <NUM> and Data <NUM>) while a third may be fragmented (e.g., in up to <NUM> fragments for Dyn. = <NUM> or up to <NUM> fragments for Dyn. The first fragment <NUM> (of Data <NUM> labeled Frag <NUM>) may be used to efficiently fill the allocated resource. In either case, there may be no length restriction for any of the fragments. As noted above, in some cases, only one fragment of an MSDU/MMPDU may be transmitted in the A-MPDU.

The rest of the fragments of the frame may be scheduled for transmission in successive TXOPs. The Recipient may respond (using resources of an UL allocation) to an eliciting frame that contains a fragment with either of the following: an Ack frame if the fragment is carried in a (VHT Single) MPDU or a compressed BlockAck frame if the fragment is carried in an A-MPDU. Each bit in a bitmap <NUM> may acknowledge receipt status of non-fragment MSDUs or of the fragment of the MSDU that is carried in the eliciting A-MPDU. As illustrated, the AP may send an ACK frame <NUM> acknowledging receipt of the BlockAck frame <NUM>.

Fragmentation in this manner may be beneficial as an Originator may efficiently fill the allocated resources using the first fragment to fill resource that cannot be filled with full MSDU/MMPDU. Further, a receiver may not need significant memory to support fragmentation (as only a limited amount of resources are required to store fragments and the number of concurrently supported fragmented transmissions may be limited).

In some cases, an MSDU may be fragmented in <NUM> parts, and delivered in order which may be easily processed by receiver. For example, the payload of the first fragment is stored in the same buffer location of the MSDU. Upon reception of the second fragment, the MSDU may be immediately constructed. Once constructed, the MSDU may be sent to higher layer and the memory may be released for other MSDUs. This may also reduce the number of discarded frames due to fragmentation is reduced as: <NUM> fragments are expected to be exchanged in a few TXOPs (e.g., <NUM> or more). This approach may make it easier for the originator to make sure that Receive Timer does not expire. The use of <NUM> fragments may also reduce overhead due to fragmentation, which generally increases with the number of fragments (with <NUM> fragments this overhead is minimal).

<FIG> illustrate example exchanges 1300A and 1300B using fragmentation with <NUM>-fragment BA exchanges, in accordance with aspects of the present disclosure. As illustrated in <FIG>, MSDUs <NUM> may not be fragmented (Data <NUM> and Data <NUM>), while an MSDU for Data <NUM> may be fragmented. In this example, when reception of a first fragment (a first fragment of Data3 labeled Frag <NUM>) is not acknowledged (e.g., is negatively acknowledged in a compressed BA frame), the transmitter will transmit the FULL original MPDU (Data <NUM>) in the next TXOP. In some cases, a RETRY bit may NOT be set for the full MPDU transmission (or re-transmission), even if only a fragment of the MPDU was previously transmitted. As illustrated in <FIG>, if the entire MPDU (for Data <NUM>) does NOT entirely fit in the TXOP, the transmitter may be allowed to re-fragment the MPDU (with the first fragment of the re-fragmented MPDU labeled as Frag <NUM>') and determine a new boundary between the two fragments (again, the RETRY bit may not be set).

<FIG> illustrate other example exchanges 1400A and 1400B using fragmentation with <NUM>-fragment BA exchanges, in accordance with aspects of the present disclosure. As illustrated in <FIG>, after a first transmission, a BA is not successfully received (e.g., it may be corrupted). In case of a re-transmission where again MPDU for Data3 needs to be fragmented, the first fragment (Frag <NUM>) may be allowed to be resized (with the resized fragment labeled as Frag <NUM>') to make it smaller or larger, which may help manage varying TXOP times. On the other hand, as illustrated in <FIG>, if there is enough time in the TXOP, MPDU <NUM> may not need to be fragmented at all (and the entire MPDU for Data <NUM> may be sent unfragmented).

As presented herein, fragmentation may be enabled for MU operation using BA negotiation procedure between originator and recipient. This approach may enable the recipient to signal its capabilities to the transmitter and signal various parameters (e.g., signaling Receive Timer for minimizing # of frames discarded due to fragmentation, Max # of F-MSDUs for which full state BA score is maintained, and Dynamic-length fragmentation selection). This approach may help increase flexibility of fragmentation, by allowing fragments to have dynamic lengths and carried in A-MPDUs, while still using existing compressed BlockAck frames to acknowledge frames during the fragment enabled BlockAck session.

For example, operations <NUM> and <NUM> illustrated in <FIG> and <FIG> correspond to means 700A and 800A illustrated in <FIG> and <FIG>, respectively.

For example, means for transmitting may comprise a transmitter (e.g., the transmitter unit <NUM>) and/or the antenna(s) <NUM> of the access point <NUM> illustrated in <FIG>, a transmitter (e.g., the transmitter unit <NUM>) and/or the antenna(s) <NUM> of the user terminal <NUM> portrayed in <FIG>, or the transmitter <NUM> and/or antenna(s) <NUM> depicted in <FIG>. Means for receiving may comprise a receiver (e.g., the receiver unit <NUM>) and/or the antenna(s) <NUM> of the access point <NUM> illustrated in <FIG>, a receiver (e.g., the receiver unit <NUM>) and/or the antenna(s) <NUM> of the user terminal <NUM> shown in <FIG>, or the receiver <NUM> and/or antenna(s) <NUM> depicted in <FIG>. Means for processing, means for generating, means for outputting, and/or means for determining may comprise a processing system, which may include one or more processors (e.g., capable of implementing the algorithm or operations <NUM> and <NUM>), such as the RX data processor <NUM>, the TX data processor <NUM>, and/or the controller <NUM> of the access point <NUM> illustrated in <FIG>, the RX data processor <NUM>, the TX data processor <NUM>, and/or the controller <NUM> of the user terminal <NUM> illustrated in <FIG> or the processor <NUM> and/or the DSP <NUM> portrayed in <FIG>.

In some case, rather than actually transmitting a packet (or frame), a device may have an interface to output a packet for transmission. For example, a processor may output a packet, via a bus interface, to an RF front end for transmission. Similarly, rather than actually receiving a packet (or frame), a device may have an interface to obtain a packet received from another device. For example, a processor may obtain (or receive) a packet, via a bus interface, from an RF front end for reception.

According to certain aspects, such means may be implemented by processing systems configured to perform the corresponding functions by implementing various algorithms (e.g., in hardware or by executing software instructions). These algorithms may include, for example, an algorithm for receiving a plurality of PDUs, an algorithm for determining whether each of the PDUs was successfully received and whether each of the PDUs is associated with a non-fragmented SDU or a fragmented SDU, and an algorithm for outputting for transmission a shortened BlockAck frame comprising a bitmap field indicating a receive status for the non-fragmented and fragmented SDUs based on the determination. As another example, these algorithms may include an algorithm for outputting a plurality of PDUs for transmission, wherein each of the PDUs is associated with a non-fragmented SDU or a fragmented SDU; an algorithm for receiving a shortened BlockAck frame comprising a bitmap field indicating a receive status for the non-fragmented and fragmented SDUs; and an algorithm for processing the bitmap field in the shortened BlockAck frame to determine whether the non-fragmented and fragmented SDUs were successfully received.

Furthermore, "determining" may include resolving, selecting, choosing, establishing and the like.

The steps of a method or algorithm described in connection with the present disclosure may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in any form of storage medium that is known in the art. Some examples of storage media that may be used include random access memory (RAM), read only memory (ROM), flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM and so forth. A storage medium may be coupled to a processor such that the processor can read information from, and write information to, the storage medium.

The functions described may be implemented in hardware, software, firmware, or any combination thereof.

The processor may be responsible for managing the bus and general processing, including the execution of software stored on the machine-readable media. Machine-readable media may include, by way of example, RAM (Random Access Memory), flash memory, ROM (Read Only Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), registers, magnetic disks, optical disks, hard drives, or any other suitable storage medium, or any combination thereof. The computer-program product may comprise packaging materials.

In a hardware implementation, the machine-readable media may be part of the processing system separate from the processor. However, as those skilled in the art will readily appreciate, the machine-readable media, or any portion thereof, may be external to the processing system. By way of example, the machine-readable media may include a transmission line, a carrier wave modulated by data, and/or a computer-readable storage medium with instructions stored thereon separate from the wireless node, all of which may be accessed by the processor through the bus interface.

The processing system may be configured as a general-purpose processing system with one or more microprocessors providing the processor functionality and external memory providing at least a portion of the machine-readable media, all linked together with other supporting circuitry through an external bus architecture. Alternatively, the processing system may be implemented with an ASIC (Application Specific Integrated Circuit) with the processor, the bus interface, the user interface in the case of an access terminal), supporting circuitry, and at least a portion of the machine-readable media integrated into a single chip, or with one or more FPGAs (Field Programmable Gate Arrays), PLDs (Programmable Logic Devices), controllers, state machines, gated logic, discrete hardware components, or any other suitable circuitry, or any combination of circuits that can perform the various functionality described throughout this disclosure.

The machine-readable media may comprise a number of software modules.

A storage medium may be any available medium that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.

Claim 1:
An apparatus for wireless communications, comprising:
means configured for receiving (702A) a plurality of protocol data units, PDUs,
means configured for determining (704A) whether each of the PDUs was successfully received and whether each of the PDUs carries a non-fragmented service data unit, SDU, or a fragmented SDU, wherein at least one of the PDUs comprises at least one fragmented SDU; and
means configured for outputting (706A) for transmission a multi-fragment block acknowledgment, BlockAck, frame (<NUM>), wherein the multi-fragment BlockAck frame (<NUM>) is shorter than a basic BlockACK frame of <NUM> octets, the multi-fragment BlockAck frame (<NUM>) comprising a starting sequence control, SSC, field (<NUM>) and a bitmap field (<NUM>) indicating a receive status for any non-fragmented SDUs and the at least one fragmented SDU based on the determination, wherein the bitmap field (<NUM>) in the multi-fragment BlockAck frame (<NUM>) has a variable length, and wherein the variable length is indicated by a value of one or more most significant bits of a fragment number, FN, in the multi-fragment BlockAck frame (<NUM>), wherein the value of the FN is indicated in the SSC field (<NUM>) by one or more least significant bits of the FN.