Mpdu-based early acknowledgment indication
Patent Information
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- KONINKLIJKE PHILIPS NV
- Filing Date
- 2024-08-22
- Publication Date
- 2026-07-01
AI Technical Summary
Existing wireless communication systems face delays in acknowledging erroneous MPDUs, leading to inefficient retransmissions and increased signaling overhead.
Implementing an MPDU-based early acknowledgment procedure that allows for immediate acknowledgment of erroneous MPDUs, using indications within the PPDU to solicit early acknowledgments, particularly for high-priority or latency-sensitive traffic.
This approach reduces channel access delay, minimizes signaling overhead, and ensures timely retransmissions of erroneous MPDUs, thereby enhancing the efficiency and reliability of wireless communication systems.
Smart Images

Figure US2024043319_06032025_PF_FP_ABST
Abstract
Description
TITLEMPDU-based Early Acknowledgment IndicationCROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 534,600, filed August 25, 2023, which is hereby incorporated by reference in its entirety.BRIEF DESCRIPTION OF THE DRAWINGS
[0002] Examples of several of the various embodiments of the present disclosure are described herein with reference to the drawings.
[0003] FIG. 1 illustrates example wireless communication networks in which embodiments of the present disclosure may be implemented.
[0004] FIG. 2 is a block diagram illustrating example implementations of a station (STA) and an access point (AP).
[0005] FIG. 3 illustrates an example of a Medium Access Control (MAC) frame format.
[0006] FIG. 4 illustrates an example of a Quality of Service (QoS) null frame indicating buffer status information.
[0007] FIG. 5 illustrates an example format of a physical layer (PHY) protocol data unit (PPDU).
[0008] FIG. 6 is an example that illustrates a cross-link acknowledgment procedure.
[0009] FIG. 7 is an example that illustrates an MPDU-based acknowledgment procedure.
[0010] FIG. 8 illustrates an example process according to an embodiment.
[0011] FIG. 9 is an example that illustrates an MPDU-based acknowledgment procedure according to an embodiment.
[0012] FIGs. 10A-B illustrate example PHY headers which may be used for signaling early acknowledgment indications according to embodiments.
[0013] FIGs. 11A-B illustrate example Aggregated Control (A-Control) fields which may be used for signaling early acknowledgment indications according to embodiments.
[0014] FIG. 12 illustrates an early acknowledgment indication signaling method according to an embodiment.
[0015] FIG. 13 is an example that illustrates another MPDU-based acknowledgment procedure according to an embodiment.
[0016] FIG. 14 illustrates an example process according to an embodiment.
[0017] FIG. 15 illustrates an example process according to an embodiment.
[0018] FIG. 16 illustrates an example process according to an embodiment.
[0019] FIG. 17 illustrates an example process according to an embodiment.DETAILED DESCRIPTION
[0020] In the present disclosure, various embodiments are presented as examples of how the disclosed techniques may be implemented and / or how the disclosed techniques may be practiced in environments and scenarios. It will be apparent to persons skilled in the relevant art that various changes in form and detail can be made therein without departing from the scope. After reading the description, it will be apparent to one skilled in the relevant art how to implement alternative embodiments. The present embodiments may not be limited by any of the described exemplaryembodiments. The embodiments of the present disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments may be combined to create further embodiments within the scope of the disclosure Any figures which highlight the functionality and advantages, are presented for example purposes only. The disclosed architecture is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown. For example, the actions listed in any flowchart may be re-ordered or only optionally used in some embodiments.
[0021] Embodiments may be configured to operate as needed. The disclosed mechanism may be performed when certain criteria are met, for example, in a station, an access point, a radio environment, a network, a combination of the above, and / or the like. Example criteria may be based, at least in part, on for example, wireless device or network node configurations, traffic load, initial system set up, packet sizes, traffic characteristics, a combination of the above, and / or the like. When the one or more criteria are met, various example embodiments may be applied. Therefore, it may be possible to implement example embodiments that selectively implement disclosed protocols.
[0022] In this disclosure, “a” and “an” and similar phrases are to be interpreted as “at least one” and “one or more.” Similarly, any term that ends with the suffix “(s)” is to be interpreted as “at least one” and “one or more.” In this disclosure, the term “may” is to be interpreted as “may, for example.” In other words, the term “may” is indicative that the phrase following the term “may” is an example of one of a multitude of suitable possibilities that may, or may not, be employed by one or more of the various embodiments. The terms “comprises” and “consists of”, as used herein, enumerate one or more components of the element being described. The term “comprises” is interchangeable with “includes” and does not exclude unenumerated components from being included in the element being described. By contrast, “consists of’ provides a complete enumeration of the one or more components of the element being described. The term “based on”, as used herein, may be interpreted as “based at least in part on” rather than, for example, “based solely on” The term “and / or” as used herein represents any possible combination of enumerated elements. For example, “A, B, and / or C” may represent A; B; C; A and B; A and C; B and C; or A, B, and C.
[0023] If A and B are sets and every element of A is an element of B, A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {STA1 , STA2) are: {STA1}, {STA2}, and {STA1, STA2). The phrase “based on” (or equally “based at least on”) is indicative that the phrase following the term “based on” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “in response to” (or equally “in response at least to”) is indicative that the phrase following the phrase “in response to” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “depending on” (or equally “depending at least to”) is indicative that the phrase following the phrase “depending on” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “employi ng / using” (or equally “employing / using at least”) is indicative that the phrase following the phrase “employing / using” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments.
[0024] The term configured may relate to the capacity of a device whether the device is in an operational or non- operational state. Configured may refer to specific settings in a device that effect the operational characteristics of the device whether the device is in an operational or non-operational state. In other words, the hardware, software, firmware, registers, memory values, and / or the like may be “configured” within a device, whether the device is in an operational or nonoperational state, to provide the device with specific characteristics. Terms such as “a control message to cause in a device” may mean that a control message has parameters that may be used to configure specific characteristics or may be used to implement certain actions in the device, whether the device is in an operational or non-operational state.
[0025] In this disclosure, parameters (or equally called, fields, or Information elements: lEs) may comprise one or more information objects, and an information object may comprise one or more other objects. For example, if parameter (IE) N comprises parameter (IE) M, and parameter (IE) M comprises parameter (IE) K, and parameter (IE) K comprises parameter (information element) J. Then, for example, N comprises K, and N comprises J. In an example embodiment, when one or more messages / frames comprise a plurality of parameters, it implies that a parameter in the plurality of parameters is in at least one of the one or more messages / frames but does not have to be in each of the one or more messages / frames.
[0026] Many features presented are described as being optional through the use of “may" or the use of parentheses. For the sake of brevity and legibility, the present disclosure does not explicitly recite each and every permutation that may be obtained by choosing from the set of optional features. The present disclosure is to be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional features may be embodied in seven ways, namely with just one of the three possible features, with any two of the three possible features or with three of the three possible features.
[0027] Many of the elements described in the disclosed embodiments may be implemented as modules. A module is defined here as an element that performs a defined function and has a defined interface to other elements. The modules described in this disclosure may be implemented in hardware, software in combination with hardware, firmware, wetware (e.g. hardware with a biological element) or a combination thereof, which may be behavioral ly equivalent. For example, modules may be implemented as a software routine written in a computer language configured to be executed by a hardware machine (such as C, C++, Fortran, Java, Basic, Matlab or the like) or a modeling / simulation program such as Simulink, Stateflow, GNU Octave, or LabVIEWMathScript. It may be possible to implement modules using physical hardware that incorporates discrete or programmable analog, digital and / or quantum hardware. Examples of programmable hardware comprise: computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs); field programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers and microprocessors are programmed using languages such as assembly, C, C++ or the like. FPGAs, ASICs and CPLDs are often programmed using hardware description languages (HDL) such as VHSIC hardware description language (VHDL) or Verilog that configure connections between internal hardware modules with lesser functionality on a programmable device. The mentioned technologies are often used in combination to achieve the result of a functional module.
[0028] FIG. 1 illustrates example wireless communication networks in which embodiments of the present disclosure may be implemented.
[0029] As shown in FIG. 1, the example wireless communication networks may include an Institute of Electrical and Electronic Engineers (IEEE) 802.11 (WLAN) infra-structure network 102. WLAN infra-structure network 102 may include one or more basic service sets (BSSs) 110 and 120 and a distribution system (DS) 130.
[0030] BSS 110-1 and 110-2 each includes a set of an access point (AP or AP STA) and at least one station (STA or non-AP STA). For example, BSS 110-1 includes an AP 104-1 and a STA 106-1, and BSS 110-2 includes an AP 104-2 and STAs 106-2 and 106-3. The AP and the at least one STA in a BSS perform an association procedure to communicate with each other.
[0031] DS 130 may be configured to connect BSS 110-1 and BSS 110-2. As such, DS 130 may enable an extended service set (ESS) 150. Within ESS 150, APs 104-1 and 104-2 are connected via DS 130 and may have the same service set identification (SSID).
[0032] WLAN infra-structure network 102 may be coupled to one or more external networks. For example, as shown in FIG. 1, WLAN infra-structure network 102 may be connected to another network 108 (e.g., 802.X) via a portal 140. Portal 140 may function as a bridge connecting DS 130 of WLAN infra-structure network 102 with the other network 108.
[0033] The example wireless communication networks illustrated in FIG. 1 may further include one or more ad-hoc networks or independent BSSs (IBSSs). An ad-hoc network or IBSS is a network that includes a plurality of STAs that are within communication range of each other. The plurality of STAs are configured so that they may communicate with each other using direct peer-to-peer communication (i.e., not via an AP).
[0034] For example, in FIG. 1, STAs 106-4, 106-5, and 106-6 may be configured to form a first IBSS 112-1. Similarly, STAs 106-7 and 106-8 may be configured to form a second IBSS 112-2. Since an IBSS does not include an AP, it does not include a centralized management entity. Rather, STAs within an IBSS are managed in a distributed manner. STAs forming an IBSS may be fixed or mobile.
[0035] A STA as a predetermined functional medium may include a medium access control (MAC) layer that complies with an IEEE 802.11 standard. A physical layer interface for a radio medium may be used among the APs and the non- AP stations (STAs). The STA may also be referred to using various other terms, including mobile terminal, wireless device, wireless transmit / receive unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or user. For example, the term “user" maybe used to denote a STA participating in uplink Multi-user Multiple Input, Multiple Output (MU MIMO) and / or uplink Orthogonal Frequency Division Multiple Access (OFDMA) transmission.
[0036] A physical layer (PHY) protocol data unit (PPDU) may be a composite structure that includes a PHY preamble, PHY header and a payload in the form of a PHY service data unit (PSDU). For example, the PPDU may include a PHY preamble and header and / or one or more MAC protocol data units (MPDUs). The information provided in the PHY preamble may be used by a receiving device to decode the subsequent data in the PSDU. In instances in which PPDUs are transmitted over a bonded channel (channel formed through channel bonding), the preamble fields may be duplicated and transmitted in each of the multiple component channels. The PHY preamble may include both a legacy portion (or"legacy preamble”) and a non-legacy portion (or “non-legacy preamble”). The legacy preamble may be used for packet detection, automatic gain control and channel estimation, among other uses. The legacy preamble also may generally be used to maintain compatibility with legacy devices. The format of, coding of, and information provided in the non- legacy portion of the preamble is based on the particular IEEE 802.11 protocol to be used to transmit the payload.
[0037] A frequency band may include one or more sub-bands or frequency channels. For example, PPDUs conforming to the IEEE 802.11n, 802.11ac, 802.11 ax and / or 802.11 be standard amendments may be transmitted over the 2.4 GHz, 5 GHz, and / or 6 GHz bands, each of which may be divided into multiple 20 MHz channels. The PPDUs may be transmitted over a physical channel having a minimum bandwidth of 20 MHz. Larger channels may be formed through channel bonding. For example, PPDUs may be transmitted over physical channels having bandwidths of 40 MHz, 80 MHz, 160 MHz, or 320 MHz by bonding together multiple 20 MHz channels.
[0038] FIG. 2 is a block diagram illustrating example implementations of a STA 210 and an AP 260. As shown in FIG. 2, STA 210 may include at least one processor 220, a memory 230, and at least one transceiver 240. AP 260 may include at least one processor 270, a memory 280, and at least one transceiver 290. Processor 220 / 270 may be operatively connected to memory 230 / 280 and / or to transceiver 240 / 290.
[0039] Processor 220 / 270 may implement functions of the PHY layer, the MAC layer, and / or the logical link control (LLC) layer of the corresponding device (STA 210 or AP 260). Processor 220 / 270 may include one or more processors and / or one or more controllers. The one or more processors and / or one or more controllers may comprise, for example, a general-purpose processor, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a logic circuit, or a chipset, for example.
[0040] Memory 230 / 280 may include a read-only memory (ROM), a random-access memory (RAM), a flash memory, a memory card, a storage medium, and / or other storage unit. Memory 230 / 280 may comprise one or more non-transi tory computer readable mediums. Memory 230 / 280 may store computer program instructions or code that may be executed by processor 220 / 270 to carry out one or more of the operations / embodiments discussed in the present application. Memory 230 / 280 may be implemented (or positioned) within processor 220 / 270 or external to processor 220 / 270. Memory 230 / 280 may be operatively connected to processor 220 / 270 via various means known in the art.
[0041] Transceiver 240 / 290 may be configured to transmit / receive radio signals. In an embodiment, transceiver 240 / 290 may implement a PHY layer of the corresponding device (STA 210 or AP 260). In an embodiment, STA 210 and / or AP 260 may be a multi-link device (MLD), that is a device capable of operating over multiple links as defined by the IEEE 802.11 standard. As such, STA 210 and / or AP 260 may each implement multiple PHY layers. The multiple PHY layers may be implemented using one or more of transceivers 240 / 290.
[0042] FIG. 3 illustrates an example format of a MAC frame. In operation, a STA may construct a subset of MAC frames for transmission and may decode a subset of received MAC frames upon validation. The particular subsets of frames that a STA may construct and / or decode may be determined by the functions supported by the STA. A STA may validate a received MAC frame using the frame check sequence (FCS) contained in the frame and may interpret certain fields from the MAC headers of all frames.
[0043] As shown in FIG. 3, a MAC frame includes a MAC header, a variable length frame body, and a frame check sequence (FCS).
[0044] The MAC header includes a frame control field, an optional duration / ID field, address fields, an optional sequence control field, an optional QoS control field, and an optional HT control field.
[0045] The frame control fields include the following subfields: protocol version, type, subtype, To DS, From DS, more fragments, retry, power management, more data, protected frame, and +HTC.
[0046] The protocol version subfield is invariant in size and placement across all revisions of the IEEE 802.11 standard. The value of the protocol version subfield is 0 for MAC frames.
[0047] The type and subtype subfields together identify the function of the MAC frame. There are three frame types: control, data, and management. Each of the frame types has several defined subtypes. Bits within the subtype subfield are used to indicate a specific modification of the basic data frame (subtype 0). For example, in data frames, the most significant bit (MSB) of the subtype subfield, bit 7 (B7) of the frame control field, is defined as the QoS subfield. When the QoS subfield is set to 1, it indicates a QoS subtype data frame, which is a data frame that contains a QoS control field in its MAC header. The second MSB of the subtype field, bit 6 (B6) of the frame control field, when set to 1 in data subtypes, indicates a data frame that contain no frame body field.
[0048] The To DS subfield indicates whether a data frame is destined to the distribution system (DS). The From DS subfield indicates whether a data frame originates from the DS.
[0049] The more fragments subfield is set to 1 in all data or management frames that have another fragment to follow of the MAC service data unit (MSDU) or MAC management protocol data unit (MMPDU) carried by the MAC frame. It is set to 0 in all other frames in which the more fragments subfield is present.
[0050] The retry subfield is set to 1 in any data or management frame that is a retransmission of an earlier frame. It is set to 0 in all other frames in which the retry subfield is present. A receiving STA uses this indication to aid it in the process of eliminating duplicate frames. These rules do not apply for frames sent by a STA under a block agreement.
[0051] The power management subfield is used to indicate the power management mode of a STA.
[0052] The More Data subfield indicates to a STA in power save (PS) mode that bufferable units (Bus) are buffered for that STA at the AP. The more data subfield is valid in individually addressed data or management frames transmitted by an AP to a STA in PS mode. The more data subfield is set to 1 to indicate that at least one additional buffered BU is present for the STA.
[0053] The protected frame subfield is set to 1 if the frame body field contains information that has been processed by a cryptographic encapsulation algorithm
[0054] The +HTC subfield indicates that the MAC frame contains an HT control field.
[0055] The duration / ID field of the MAC header indicates various contents depending on frame type and subtype and the QoS capabilities of the sending STA. For example, in control frames of the power save poll (PS-Poll) subtype, the duration / ID field carries an association identifier (AID) of the STA that transmitted the frame in the 14 least significant bits (LSB), and the 2 most significant bits (MSB) are both set to 1 . In otherframes sent by STAs, the duration / ID field containsa duration value (in microseconds) which is used by a recipient to update a network allocation vector (NAV). The NAV is a counter that it indicates to a STA an amount of time during which it must defer from accessing the shared medium.
[0056] There can be up to four address fields in the MAC frame format. These fields are used to indicate the basic service set identifier (BSSID), source address (SA), destination address (DA), transmitting address (TA), and receiving address (RA). Certain frames might not contain some of the address fields. Certain address field usage may be specified by the relative position of the address field (1-4) within the MAC header, independent of the type of address present in that field. Specifically, the address 1 field always identifies the intended receiver(s) of the frame, and the address 2 field, where present, always identifies the transmitter of the frame.
[0057] The sequence control field includes two subfields, a sequence number subfield and a fragment number subfield. The sequence number subfield in data frames indicates the sequence number of the MSDU (if not in an Aggregated MSDU (A-MSDU)) or A-MSDU. The sequence number subfield in management frames indicates the sequence number of the frame. The fragment number subfield indicates the number of each fragment of an MSDU or MMPDU. The fragment number is set to 0 in the first or only fragment of an MSDU or MMPDU and is incremented by one for each successive fragment of that MSDU or MMPDU. The fragment number is set to 0 in a MAC protocol data unit (MPDU) containing an A-MSDU, or in an MPDU containing an MSDU or MMPDU that is not fragmented. The fragment number remains constant in all retransmissions of the fragment.
[0058] The QoS control field identifies the traffic category (TC) or traffic stream (TS) to which the MAC frame belongs. The QoS control field may also indicate various other QoS related, A-MSDU related, and mesh-related information about the frame. This information can vary by frame type, frame subtype, and type of transmitting STA. The QoS control field is present in all data frames in which the QoS subfield of the subtype subfield is equal to 1.
[0059] The HT control field is present in QoS data, QoS null, and management frames as determined by the +HTC subfield of the frame control field.
[0060] The frame body field is a variable length field that contains information specific to individual frame types and subtypes. It may include one or more MSDUs or MMPDUs. The minimum length of the frame body is 0 octets.
[0061] The FCS field contains a 32-bit Cyclic Redundancy Check (CRC) code. The FCS field value is calculated over all of the fields of the MAC header and the frame body field.
[0062] FIG. 4 illustrates an example of a QoS null frame indicating buffer status information. A QoS null frame refers to a QoS data frame with an empty frame body. A QoS null frame includes a QoS control field and an optional HT control field which may contain a buffer status report (BSR) control subfield. A QoS null frame indicating buffer status information may be transmitted by a STA to an AP.
[0063] The QoS control field may include a traffic identifier (TID) subfield, an ack policy indicator subfield, and a queue size subfield (or a transmission opportunity (TXOP) duration requested subfield).
[0064] The TID subfield identifies the TC or TS of traffic for which a TXOP is being requested, through the setting of the TXOP duration requested or queue size subfield. The encoding of the TID subfield depends on the access policy(e.g., Allowed value 0 to 7 for enhanced distributed channel access (EDCA) access policy to identify user priority for either TC or TS).
[0065] The ack policy indicator subfield, together with other information, identifies the acknowledgment policy followed upon delivery of the MPDU (e.g., normal ack, implicit block ack request, no ack, block ack, etc.)
[0066] The queue size subfield is an 8-bit field that indicates the amount of buffered traffic for a given TC or TS at the STA for transmission to the AP identified by the receiver address of the frame containing the subfield. The queue size subfield is present in QoS null frames sent by a STA when bit 4 of the QoS control field is set to 1. The AP may use information contained in the queue size subfield to determine t TXOP duration assigned to the STA or to determine the uplink (UL) resources assigned to the STA.
[0067] In a frame sent by or to a non-High Efficiency (non-HE) STA, the following rules may apply to the queue size value:The queue size value is the approximate total size, rounded up to the nearest multiple of 256 octets and expressed in units of 256 octets, of all MSDUs and A-MSDUs buffered at the STA (excluding the MSDU or A-MSDU contained in the present QoS Data frame) in the delivery queue used for MSDUs and A-MSDUs with TID values equal to the value indicated in the TID subfield of the QoS Control field.A queue size value of 0 is used solely to indicate the absence of any buffered traffic in the queue used for the specified TID.A queue size value of 254 is used for all sizes greater than 64768 octets.A queue size value of 255 is used to indicate an unspecified or unknown size.
[0068] In a frame sent by an HE STA to an HE AP, the following rules may apply to the queue size value.
[0069] The queue size value, QS, is the approximate total size in octets, of all MSDUs and A-MSDUs buffered at the STA (including the MSDUs or A-MSDUs contained in the same PSDU as the frame containing the queue size subfield) in the delivery queue used for MSDUs and A-MSDUs with TID values equal to the value indicated in the TID subfield of the QoS control field.
[0070] The queue size subfield includes a scaling factor subfield in bits B14-B15 of the QoS control field and an unsealed value, UV, in bits B8 B13 of the QoS control field. The scaling factor subfield provides the scaling factor, on .
[0071] A STA obtains the queue size, QS, from a received QoS control field, which contains a scaling factor, SF, and an unsealed value, UV, as follows:QS =16 *UV, if SF is equal to O;1024 + 256 x W, if SF is equal to 1;17408 + 2048 x W, if SF is equal to 2;148480 + 32768 x UV, if SF is equal to 3 and UV is less than 62;> 2 147328, if SF equal to is 3 and UV is equal to 62;Unspecified or Unknown, if SF is equal to 3 and UV is equal to 63.
[0072] The TXOP duration requested subfield, which may be included instead of the queue size subfield, indicates the duration, in units of 32 microseconds (us), that the sending STA determines it needs for its next TXOP for the specified TID. The TXOP duration requested subfield is set to 0 to indicate that no TXOP is requested for the specified TID in the current service period (SP). The TXOP duration requested subfield is set to a nonzero value to indicate a requested TXOP duration in the range of 32 us to 8160 us in increments of 32 us.
[0073] The HT control field may include a BSR control subfield which may contain buffer status information used for uplink (UL) multi-user (MU) operation. The BSR control subfield may be formed from an access category index (ACI) bitmap subfield, a delta TID subfield, an ACI high subfield, a scaling factor subfield, a queue size high subfield, and a queue size all subfield of the HT control field.
[0074] The ACI bitmap subfield indicates the access categories for which buffer status is reported (e.g ., B0: best effort (AC_BE), B1: background (AC_BK), B2: video (AC_VI), B3: voice (AC_VO), etc.). Each bitof the ACI bitmap subfield is set to 1 to indicate that the buffer status of the corresponding AC is included in the queue size all subfield, and set to 0 otherwise, except that if the ACI bitmap subfield is 0 and the delta TID subfield is 3, then the buffer status of all 8 TIDs is included.
[0075] The delta Tl D subfield, together with the values of the ACI bitmap subfield, indicate the number of Tl Ds for which the STA is reporting the buffer status.
[0076] The ACI high subfield indicates the ACI of the AC for which the BSR is indicated in the queue size high subfield. The ACI to AC mapping is defined as ACI value 0 mapping to AC_BE, ACI value 1 mapping to AC_BK, ACI value 2 mapping to AC_VI, and ACI value 3 mapping to AC_VO.
[0077] The scaling factor subfield indicates the unit SF, in octets, of the queue size high and queue size all subfields.
[0078] The queue size high subfield indicates the amount of buffered traffic, in units of SF octets, for the AC identified by the ACI high subfield, that is intended for the STA identified by the receiver address of the frame containing the BSR control subfield.
[0079] The queue size all subfield indicates the amount of buffered traffic, in units of SF octets, for all Acs identified by the ACI Bitmap subfield, that is intended for the STA identified by the receiver address of the frame containing the BSR control subfield.
[0080] The queue size values in the queue size high and queue size all subfields are the total sizes, rounded up to the nearest multiple of SF octets, of all MSDUs and A-MSDUs buffered at the STA (including the MSDUs or A-MSDUs contained in the same PSDU as the frame containing the BSR control subfield) in delivery queues used for MSDUs and A-MSDUs associated with AC(s) that are specified in the ACI high and ACI bitmap subfields, respectively.
[0081] A queue size value of 254 in the queue size high and queue size all subfields indicates that the amount of buffered traffic is greater than 254 x SF octets. A queue size value of 255 in the queue size high and queue size all subfields indicates that the amount of buffered traffic is an unspecified or unknown size. The queue size value of QoSdata frames containing fragments may remain constant even if the amount of queued traffic changes as successive fragments are transmitted.
[0082] MAC service provides peer entities with the ability to exchange MSDUs. To support this service, a local MAC uses the underlying PHY-level service to transport the MSDUs to a peer MAC entity. Such asynchronous MSDU transport is performed on a connectionless basis.
[0083] FIG. 5 illustrates an example format of a PPDU. As shown, the PPDU may include a PHY preamble, a PHY header, a PSDU, and tail and padding bits.
[0084] The PSDU may include one or more MPDUs, such as a QoS data frame, an MMPDU, a MAC control frame, or a QoS null frame. In the case of an MPDU carrying a QoS data frame, the frame body of the MPDU may include a MSDU or an A-MSDU.
[0085] By default, MSDU transport is on a best-effort basis. That is, there is no guarantee that a transmitted MSDU will be delivered successfully. However, the QoS facility uses a traffic identifier (TID) to specify differentiated services on a per-MSDU basis.
[0086] A STA may differentiate MSDU delivery according to designated traffic category (TC) or traffic stream (TS) of individual MSDUs. The MAC sublayer entities determine a user priority (UP) for an MSDU based on a TID value provided with the MSDU. The QoS facility supports eight UP values. The UP values range from 0 to 7 and form an ordered sequence of priorities, with 1 being the lowest value, 7 the highest value, and 0 falling between 2 and 3.
[0087] An MSDU with a particular UP is said to belong to a traffic category with that UP. The UP may be provided with each MSDU at the medium access control service access point (MAC SAP) directly in a UP parameter. An aggregate MPDU (A-MPDU) may include MPDUs with different TID values.
[0088] A STA may deliver buffer status reports (BSRs) to assist an AP in allocating UL MU resources The STA may either implicitly deliver BSRs in the QoS control field or BSR control subfield of any frame transmitted to the AP (unsolicited BSR) or explicitly deliver BSRs in a frame sent to the AP in response to a BSRP Trigger frame (solicited BSR).
[0089] The buffer status reported in the QoS control field includes a queue size value for a given TID. The buffer status reported in the BSR control field includes an ACI bitmap, delta TID, a high priority AC, and two queue sizes.
[0090] A STA may report buffer status to the AP, in the QoS control field, of transmitted QoS null frames and QoS data frames and, in the BSR control subfield (if present), of transmitted QoS null frames, QoS data frames, and management frames as defined below.
[0091] The STA may report the queue size for a given TID in the queue size subfield of the QoS control field of transmitted QoS data frames or QoS null frames; the STA may set the queue size subfield to 255 to indicate an unknown / unspecified queue size for that TID. The STA may aggregate multiple QoS data frames or QoS null frames in an A-MPDU to report the queue size for different TIDs.
[0092] The STA may report buffer status in the BSR control subfield of transmitted frames if the AP has indicated its support for receiving the BSR control subfield.
[0093] A High-Efficiency (HE) STA may report the queue size for a preferred AC, indicated by the ACI high subfield, in the queue size high subfield of the BSR control subfield. The STA may set the queue size high subfield to 255 to indicate an unknown / unspecified queue size for that AC
[0094] A HE STA may report the queue size for ACs indicated by the ACI bitmap subfield in the queue size all subfield of the BSR control subfield. The STA may set the queue size all subfield to 255 to indicate an unknown / unspecified BSR for those ACs.
[0095] Current and future IEEE 802.11 standards are designed to operate at different frequency bands, such as sub- 1 GHz, TV Whitespace (TVWS), 2.4 GHz, 5 GHz, 6 GHz, 45 GHz (China mmWave), 60 GHz, and Infrared. During the development of the IEEE 802.11 be standard amendment, multi-link operation (MLO) was developed for the sub-7 GHz bands (2.4 GHz, 5 GHz, and 6 GHz bands), allowing an AP conforming to the IEEE 802.11be standard amendment to support more than one sub-7 GHz band. It is envisioned that next generation systems will support MLO over more bands, including '‘lightly” licensed bands.
[0096] According to the existing IEEE 802.11 standard, a STA may respond to a PPDU via the same link on which the STA receives the PPDU. For example, in response to a PPDU received via a first link from another STA, the STA may transmit a BlockAck (BA) frame via the first link to the other STA. Other STAs wishing to use the first link may need to wait for the first STA to transmit the BA frame before they may access the first link.
[0097] To enhance channel access delay, it has been proposed that a STA use a separate link to transmit an acknowledgement frame in response to a received PPDU. For example, where the PPDU transmission occurs over a 2.4 GHz link, the acknowledgement frame for the PPDU transmission may be transmitted over a 5 GHz link. Such an acknowledgment frame may be referred to as a cross-link acknowledgement (XACK) frame. FIG. 6 illustrates an example 600 of such operation. As shown in FIG. 6, example 600 includes a STA 602 and a STA 604. STAs 602 and 604 may be communicatively coupled by a first link and a second link. The first and second link may correspond to different frequency bands (e.g ., 2.4 GHz, 5 GHz, 60 GHz, etc.). STAs 702 and 704 may each be a STA or an AP.
[0098] In an example, STA 602 may transmit a PPDU 606 to STA 604 via the first link. On receiving PPDU 606, STA 604 may transmit a BA frame 608 via the second link instead of the first link. Another STA (not shown in FIG. 6) may access the first link after the transmission of PPDU 606.
[0099] In an example, STA 604 may receive a part of PPDU 606 in error. According to existing operation, STA 604 must wait until an end of reception of PPDU 606 before it may transmit BA frame 608 to STA 602 on a second link. As a result, STA 602 must wait until the end of transmission of PPDU 606 before it may re-transmit PPDU 606 (or a portion thereof) as PPDU 610 due to the erroneous reception. Such operation may result in an unnecessary delay for STA 604 to receive PPDU 606.
[0100] To remedy this problem, an MPDU-based acknowledgment procedure has been proposed. According to such a procedure, in receiving a PPDU comprising an A-MPDU (multiple MPDUs), a STA may transmit an acknowledgment for an MPDU received in error without waiting for an end of reception of the PPDU. FIG. 7 is an example 700 that illustrates such an MPDU-based acknowledgment procedure. As shown in FIG. 7, example 700 includes a STA 702 and a STA704. STAs 702 and 704 may be communicatively coupled by a first link and a second link. The first and second link may correspond to different frequency bands (e.g . , 2.4 GHz, 5 GHz, 60 GHz, etc.). STAs 702 and 704 may each be a STA or an AP.
[0101] Example 700 may begin with STA 702 transmitting a PPDU 712 to STA 704 via the first link. PPDU 712 may include a preamble (not shown in FIG.7), a PHY header 706, and a data field 718. STA 704 may receive PPDU 712 over the first link and may first decode PHY header 706 of PPDU 712.
[0102] As STA 704 receives data field 708 of PPDU 712, STA 704 may be configured to determine whether an error is present in each received MPDU of data field 708 of PPDU 712. When an error is detected in an MPDU, STA 704 may be configured to transmit an XACK frame on the second link indicating the error in the MPDU to STA 702. For example, as shown in FIG. 7, STA 704 may detect an error in an nth MPDU 710 of data field 708 of PPDU 712. As such, STA 704 transmits an XACK frame 714 on the second link to STA 702. On receiving XACK frame 714, STA 702 decodes XACK frame 714 and determines that XACK frame 714 indicates an error in the nth MPDU of PPDU 712. In an implementation, STA 702 records the error and continues its transmission of PPDU 712.
[0103] In an implementation, on decoding the last MPDU of PPDU 712, STA 704 may be configured to acknowledge PPDU 712 by sending an acknowledgment on the first or second link. In example 700, STA 704 acknowledges PPDU 712 by transmitting an ACK frame 716 on the first link. ACK frame 716 may indicate the error in the nth MPDU of PPDU 712.
[0104] In an implementation, when STA 702 terminates its transmission of PPDU 712, STA 702 may continue to monitor the first link or the second link for an acknowledgment of PPDU 712. The link that STA 702 monitors for the acknowledgment of PPDU 712 depends on the ACK policy used. In example 700, STA 702 may receive ACK frame 716 on the first link.
[0105] As shown in example 700, the MPDU-based acknowledgement procedure of FIG. 7 results in a transmitting STA receiving an early acknowledgement for an MPDU received in error by the receiving STA. While that may assist the transmitting STA to quickly re-transmit the erroneous MPDU, it may result in an increased signaling overhead when multiple MPDUs are received in error by the receiving STA. Further, as the receiving STA may need to contend for channel access to transmit an XACK frame comprising an early acknowledgment for an MPDU, the receiving STA may not be able to acknowledge, in a timely manner, a large number of MPDUs received in error. The benefits of MPDU- based acknowledgement may thus be lost.
[0106] Embodiments of the present disclosure, as further discussed below, address the above-described problem. In a first aspect, a PPDU may include an indication of whether an early acknowledgement is solicited for an MPDU of the PPDU. The indication may be provided in a PHY portion or in a MAC portion of the PPDU. A STA receiving the PPDU may transmit an acknowledgment of the MPDU based on the indication. In an embodiment, the STA receiving the PPDU may transmit the acknowledgement based on the indication indicating that an early acknowledgment is solicited for the MPDU. In an embodiment, the indication may indicate that an early acknowledgment is solicited for the MPDU based on the MPDU belonging to a first traffic category. In another aspect, a STA may transmit an acknowledgment request for atransmitted MPDU before an end of transmission of the PPDU carrying the MPDU. The receiving STA may transmit an acknowledgement for the MPDU in response to the acknowledgement request. In an embodiment, the acknowledgement request is based on the MPDU belonging to the first traffic category. In an embodiment, the first traffic category may include low latency or latency sensitive traffic. In another embodiment, the first traffic category may comprise traffic associated with a pre-determined traffic identifier (TID). As such, MPDU-based early acknowledgments may be limited to a smaller number of higher priority / urgency MPDUs, significantly reducing signaling overhead for the acknowledgments.
[0107] FIG. 8 illustrates an example process 800 according to an embodiment. Process 800 may be performed by a first STA (e.g . , STA or AP) receiving a PPDU from a second STA (e.g ., STA or AP). The first STA and the second STA may be communicatively coupled by a plurality of links (e.g., 2.4 GHz, 5 GHz, 60 GHz, etc.).
[0108] As shown in FIG. 8, process 800 begins in step 802, which includes starting to receive a first PPDU on a first link of the plurality of links and decoding a next MPDU in the first PPDU. In a first iteration of process 800, the next MPDU corresponds to a first occurring MPDU in the first PPDU being received. The next MPDU may be decoded based on information obtained from the PHY header of the first PPDU.
[0109] Next, step 804 includes determining whether an error has been detected in the decoded MPDU. The error may be detected based on a frame check sequence at the end of the MPDU. If the answer in step 804 is no, process 800 proceeds to step 810, which includes recording the reception status of the MPDU. Otherwise, if the answer in step 804 is yes, process 800 transitions to step 806, which includes checking an early acknowledgement indication for the MPDU. The early acknowledgment indication indicates whether an early acknowledgment is solicited for the MPDU. As used herein, an early acknowledgment for an MPDU refers to an acknowledgement that is sent by the receiving STA before an end of reception of the PPDU carrying the MPDU In an embodiment, the early acknowledgement may be carried in a PHY portion or in a MAC portion of the PPDU. In an embodiment, the PHY portion may comprise a PHY header of the PPDU. In an embodiment, the MAC portion may comprise a MAC header or a frame body of a first occurring MPDU of the PPDU, a MAC header of the MPDU, or in a delimiter of the MPDU.
[0110] If the early acknowledgement indication indicates that an early acknowledgment is not solicited for the MPDU, process 800 transitions to step 810 described above. Otherwise, if the early acknowledgement indication indicates that an early acknowledgment is solicited for the MPDU, process 800 transitions to step 808, which includes the first STA transmitting a second PPDU comprising an acknowledgement for the MPDU, before transitioning to step 810 described above. The acknowledgment for the MPDU comprises the reception status of the MPDU. In an embodiment, step 808 may be conditioned on the MPDU being received in error. That is, the second PPDU may be transmitted only when the MPDU is received in error, despite the early acknowledgment indication indicating that an early acknowledgment is solicited for the MPDU.
[0111] Subsequently, process 800 transitions to step 812, which includes determining whether a last MPDU in the first PPDU has been decoded. The last MPDU corresponds to a last occurring MPDU in the first PPDU. If the answer is no, process 800 returns to step 802. Otherwise, process 800 proceeds to step 814, which includes transmitting anacknowledgment frame according to the acknowledgment policy in use. For example, the acknowledgment policy may include the acknowledgment frame comprising the reception status of all MPDUs of the first PPDU or of only those MPDUs that were not acknowledged by an early acknowledgment. The sending of an ACK frame in step 814 corresponds to the PPDU being entirely received by the first STA.
[0112] FIG. 9 is an example 900 that illustrates an MPDU-based early acknowledgment procedure according to an embodiment. As shown in FIG. 9, example 900 includes a STA 902 and a STA 904. STAs 902 and 904 may be communicatively coupled by a first link and a second link. The first and second link may correspond to different frequency bands (e.g., 2.4 GHz, 5 GHz, 60 GHz, etc.). STAs 902 and 904 may each be a STA or an AP.
[0113] Example 900 may begin with STA 902 transmitting a PPDU 918 to STA 904 via the first link. PPDU 918 may include a preamble (not shown in FIG. 9), a PHY portion 906, and a MAC portion 908. PHY portion 906 may comprise a PHY header of PPDU 918. MAC portion 908 may comprise a plurality of MPDUs. Each MPDU may comprise a MAC header and a payload (or data field). STA 904 may receive PPDU 918 over the first link and may first decode the PHY header of PPDU 918.
[0114] In an embodiment, PPDU 918 may comprise an early acknowledgement indication for each MPDU of the plurality of MPDUs comprised in MAC portion 908. In an embodiment, the early acknowledgement for an MPDU may be carried in PHY portion 906 or in MAC portion 908 of PPDU 918.
[0115] In an embodiment, as STA 904 receives an MPDU of PPDU 918, STA 904 may check the early acknowledgment indication for the MPDU to determine whether an early acknowledgment is solicited for the MPDU. In an embodiment, STA 904 may decode a MAC header of the MPDU to determine a traffic category for the MPDU (e.g., Tl D). In an example, STA 904 may check whether the MPDU belongs to a first traffic category (e.g., low latency or latency sensitive traffic). In an embodiment, STA 904 may be configured to determine whether an error is present in the MPDU. The STA may determine that an error is present in the MPDU based on a failure of an FCS performed on the MPDU.
[0116] In an embodiment, when the early indication for the MPDU indicates that an early acknowledgment is solicited for the MPDU, STA 904 may be configured to transmit a PPDU comprising an acknowledgment of the MPDU without waiting for an end of reception of PPDU 918. In an embodiment, the PPDU comprising the acknowledgement of the MPDU may be transmitted on the condition that an error is detected in the MPDU. In an embodiment, STA 904 may be configured to transmit the PPDU comprising the acknowledgement on the further condition that the MPDU belongs to the first traffic category or to a particular TID. In an embodiment, the PPDU comprising the acknowledgment of the MPDU may be transmitted on the first link or on the second link.
[0117] In example 900, PPDU 918 may include an nth MPDU 910 and an (n+1)th MPDU 912. In an example, MPDU 910 may belong to a first traffic category (e.g., low latency or latency sensitive traffic). In an example, MPDU 912 may belong to a second traffic category (e.g., best effort). The early acknowledgment indication may be set to 1 for MPDU 910 indicating that an early acknowledgment is solicited for MPDU 910. The early acknowledgment indication may be set to 0 for MPDU 912 indicating that an early acknowledgment is not solicited for MPDU 912. In example 900, STA 904 may detect an error in each of MPDU 910 and MPDU 912. Based on the early acknowledgment indication for MPDU 910being set to 1 and MPDU 910 being received in error, STA 904 may transmit to STA 902 an XACK frame 914 on the second link comprising the reception status of MPDU 910. In contrast, based on the early acknowledgment indication for MPDU 912 being set to 0 (and despite MPDU 912 being received in error), STA 904 may not transmit to STA 902 an early acknowledgment comprising the reception status of MPDU 912. Instead, STA 904 may record the reception status of MPDU 912 and may continue its reception of PPDU 918.
[0118] In an implementation, on decoding the last MPDU of PPDU 918, STA 904 may be configured to acknowledge PPDU 918 by sending an acknowledgment frame on the first or second link. In example 900, STA 904 acknowledges PPDU 918 by transmitting an acknowledgment frame 916 on the first link. Acknowledgment frame 916 may indicate the reception status of both MPDU 910 and MPDU 912. Acknowledgment frame 916 may comprise a BA frame. In an implementation, when STA 902 terminates its transmission of PPDU 918, STA 902 may continue to monitor the first link or the second link for an acknowledgment of PPDU 918. The link that STA 902 monitors for the acknowledgment of PPDU 918 depends on the ACK policy used. In example 900, STA 902 may receive acknowledgment frame 916 on the first link.
[0119] FIGs. 10A-B illustrate example PHY headers 1000A and 1000B which may be used for signaling early acknowledgment indications according to embodiments. PHY headers 1000A and 1000B may be used in an Ultra High Reliability (UHR) PPDU which may be used by devices conforming to the IEEE 802.11 bn standard amendment.
[0120] As shown in FIG. 10A, PHY header 1000A includes an non-HT Short Training field (L-STF), a non-HT Long Training field (L-LTF), a non-High-Throughput (non-HT) Signal field (L-SIG), a non-HT Repeated Signal field (RL-SIG), a Universal Signal field (U-SIG), a UHR Signal Field (UHR-SIG), an UHR Short Training Field (UHR-STF) field, and one or more UHR Long Training field (UHR-LTF).
[0121] The L-STF is used by a receiver of PHY header 1000A to synchronize with the carrier frequency and frame timing of a transmitter of PHY header 1000A and to adjust the receiver signal gain.
[0122] The L-LTF is used by the receiver of PHY header 1000A to estimate channel coefficients in order to equalize the channel response (e.g., amplitude and phase distortion) in both Signal fields (L-SIG, RL-SIG, U-SIG, UHR-SIG) of PHY header 1000A.
[0123] The L-SIG and RL-SIG contain parameters needed to demodulate the data field or payload of the PPDU. The L-SIG may be equalized using the channel coefficients estimated using the L-LTF and demodulated to obtain the demodulation parameters of the data field.
[0124] The U-SIG ensures backward and forward compatibility of PHY header 1000A. The U-SIG was introduced in the IEEE 802.11be standard and is present in all PHY headers starting with the 802.11 be standard. Due to its presence in PHY header 1000A, PHY header 1000A can be decoded, at least in part, by pre-UHR devices (e.g., 802.11 be devices), UHR devices, and post-UHR devices.
[0125] The UHR-SIG contains indications per STA of RU allocations. A receiving STA may use the indications in the UHR-SIG to locate its payload in the data field of the PPDU. In an embodiment, the UHR-SIG may be configured to include an early acknowledgment (EA) indication bitmap. The EA indication bitmap indicates for each MPDU of the PPDU whether an early acknowledgment is solicited for the MPDU. For example, the EA indication bitmap may be 32, 64, 128,or 256 bits long. In another embodiment, the EA indication bitmap may be of a variable size. In another embodiment, the UHR-SIG maybe configured to include an indication regarding the presence of an EA indication bitmap. The EA indication bitmap may be carried in another field of PHY header 1000A For example, PHY header 1000A may comprise a UHR- SIG-A field (not shown in FIG. 10A) that includes the EA indication bitmap.
[0126] The UHR-STF and the one or more UHR-LTFs are used by the receiver of the PPDU to estimate channel coefficients in order to equalize the channel response (e.g ., amplitude and phase distortion) in the data field of the PPDU.
[0127] PHY header 1000B illustrated in FIG. 10B is similar to PHY header 1000A described above. In an embodiment, the UHR-SIG of PHY header 1000B may be configured to include an EA indication flag, a first MPDU number field, and a last MPDU number field. The EA indication flag may be set to 1 or 0 to indicate whether early acknowledgment is enabled or disabled. When early acknowledgment is enabled, the first MPDU number field and the last MPDU number field indicate a range of MPDUs for which early acknowledgment is solicited. The first MPDU number field may indicate the sequence number of the first MPDU in the range The last MPDU number field may indicate the sequence number of the last MPDU number in the range. In an embodiment, the first MPDU number field and the last MPDU number field may be set to the same value to solicit an early acknowledgment for a single MPDU of the PPDU.
[0128] FIGs. 11 A-B illustrate example Aggregated Control (A-Control) fields 1100A and 110B which may be used for signaling early acknowledgment indications according to embodiments. A-Control fields 1100A and 1100B may be used in a UHR PPDU which may be used by devices conforming to the IEEE 802.11bn standard amendment. In an embodiment, A-Control field 1100A or 1100B may be carried in a first occurring MPDU of the PPDU. The first occurring MPDU may be a MAC management protocol data unit (MMPDU) or an action frame. In an embodiment, A-Control field 1100A or 1100B may be carried in the MAC header of the first occurring MPDU. For example, A-Control field 1100A or 1100B maybe carried in an HT Control field of the MAC header of the first occurring MPDU. In another embodiment, A- Control field 1100A or 1100B may be carried in the data field or payload of the first occurring MPDU.
[0129] As shown in FIG. 11A, A-Control field 1100A may include a control ID subfield and an EA indication bitmap subfield. The control ID subfield identifies A-Control field 1100A as an EA indication A-Control field; that is, as an A- Control field that carries early acknowledgment indications. The EA indication bitmap subfield includes an EA indication bitmap that indicates for each MPDU of the PPDU whether an early acknowledgment is solicited for the MPDU. For example, the EA indication bitmap may be 32, 64, 128, or 256 bits long. In another embodiment, the EA indication bitmap may be of a variable size.
[0130] As shown in FIG. 11 B, A-Control field 1100B may include a control ID subfield, a first MPDU number subfield, and a last MPDU number subfield. The control ID subfield identifies A-Control field 1100A as an EA indication A-Control field; that is, as an A-Control field that carries early acknowledgment indications. The first MPDU number subfield and the last MPDU number subfield indicate a range of MPDUs for which early acknowledgment is solicited. The first MPDU number subfield may indicate the sequence number of the first MPDU in the range. The last MPDU number subfield may indicate the sequence number of the last MPDU number in the range. In an embodiment, the first MPDU number subfieldand the last MPDU number subfield may be set to the same value to solicit an early acknowledgment for a single MPDU of the PPDU.
[0131] FIG. 12 illustrates an early acknowledgment indication signaling method according to an embodiment The early acknowledgment indication signaling method is illustrated with respect to an example MAC portion 1200 of a PPDU. The PPDU maybe a UHR PPDU. As shown, MAC portion 1200 may comprise a plurality of MPDUs (MPDU 1, MPDU 2, .... MPDU n) each preceded by a respective MPDU delimiter. An MPDU may comprise a MAC header, a frame body, and an FCS. An MPDU delimiter may comprise an end of frame (EOF) field, a Reserved field, an MPDU length field, a CRC field, and a delimiter signature field.
[0132] In an embodiment, an early acknowledgment indication for each MPDU is carried in the respective MPDU delimiter preceding the MPDU. In an embodiment, the early acknowledgment indication for the MPDU may be carried in the Reserved field of the MPDU delimiter. In another embodiment, the early acknowledgment indication for the MPDU may be carried in the delimiter signature field of the MPDU delimiter.
[0133] FIG. 13 is an example that illustrates another MPDU-based acknowledgment procedure according to an embodiment. As shown in FIG. 13, example 1300 includes a STA 1302 and a STA 1304. STAs 1302 and 1304 may be communicatively coupled by a first link and a second link. The first and second link may correspond to different frequency bands (e.g., 2.4 GHz, 5 GHz, 60 GHz, etc.). STAs 1302 and 1304 may each be a STA or an AP.
[0134] Example 1300 may begin with STA 1302 transmitting a PPDU 1318 to STA 1304 via the first link. PPDU 1318 may include a preamble (not shown in FIG. 13), a PHY portion 1306, and a MAC portion 1308. PHY portion 1306 may comprise a PHY header of PPDU 1318. MAC portion 1308 may comprise a plurality of MPDUs. Each MPDU may comprise a MAC header and a payload (or data field). STA 1304 may receive PPDU 1318 over the first link and may first decode the PHY header of PPDU 1318.
[0135] In an embodiment, after STA 1302 transmits an MPDU of PPDU 1318 via the first link, STA 1302 may be configured to transmit to STA 1304, via the first link or the second link, an acknowledgment request for the MPDU. The acknowledgment request requests that STA 1304 transmit an acknowledgment for the MPDU. In an embodiment, the acknowledgment request includes a sequence number of the MPDU. In an embodiment, STA 1302 may be configured to transmit the acknowledgment request for the MPDU before an end of transmission of PPDU 1318 so as to receive an early acknowledgment for the MPDU (e.g., before an end of transmission of the PPDU). In an embodiment, STA 1302 may be configured to transmit an acknowledgment request for an MPDU based on the MPDU belonging to a first traffic category. In an embodiment, the first traffic category may include low latency or latency sensitive traffic. In another embodiment, the first traffic category may comprise traffic associated with a pre-determined TID.
[0136] In an embodiment, on receiving an acknowledgment request for an MPDU, STA 1304 may be configured to transmit an acknowledgment frame for the MPDU without waiting for an end of reception of the PPDU. In another embodiment, STA 1304 may be configured to transmit the acknowledgement frame on the further condition that the MPDU is received in error. In an embodiment, STA 1304 may be configured to determine whether an error is present in the MPDU. The STA may determine that an error is present in the MPDU based on a failure of an FCS performed on theMPDU. In an embodiment, STA 1304 may decode a MAC header of the MPDU to determine a traffic category for the MPDU (e.g., TID). In an example, STA 1304 may check whether the MPDU belongs to a first traffic category (e.g., low latency or latency sensitive traffic). In an embodiment, STA 1304 may be configured to transmit the acknowledgement frame on the further condition that the MPDU belongs to the first traffic category or to a particular TID.
[0137] In example 1300, after transmitting an nth MPDU 1310 via the first link, STA 1302 may transmit a BlockAckReq (BAR) frame 1320 for MPDU 1310 via the second link. MPDU 1310 may belong to the first traffic category or to a particular TID. STA 1304 may respond to BAR frame 1320 by transmitting an XACK frame 1314 via the second link. In an embodiment, STA 1304 may transmit XACK frame 1314 on condition of MPDU 1310 being received in error. Alternatively, XACK frame 1314 may be transmitted by STA 1304 regardless of the reception status of MPDU 1310.
[0138] In an embodiment, the acknowledgment request may be for a plurality of MPDUs. As such, the acknowledgment request may include the sequence number of each MPDU of the plurality of MPDUs. Forexample, in example 1300, BAR frame 1320 may be transmitted after the transmission of an (n+1)th MPDU 1312 and may solicit an acknowledgment for both MPDUs 1310 and 1312. In response, STA 1304 may include the reception status of both MPDUs 1310 and 1312 in XACK frame 1314.
[0139] In an implementation, on decoding the last MPDU of PPDU 1318, STA 1304 maybe configured to acknowledge PPDU 1318 by sending an acknowledgment frame on the first or second link. In example 1300, STA 1304 acknowledges PPDU 1318 by transmitting an acknowledgment frame 1316 on the first link. Acknowledgment frame 1316 may indicate the reception status of both MPDU 1310 and MPDU 1312. Acknowledgment frame 1316 may comprise a BA frame. In an implementation, when STA 1302 terminates its transmission of PPDU 1318, STA 1302 may continue to monitor the first link or the second link for an acknowledgment of PPDU 1318. The link that STA 1302 monitors for the acknowledgment of PPDU 1318 depends on the ACK policy used. In example 1300, STA 1302 may receive acknowledgment frame 1316 on the first link.
[0140] FIG. 14 illustrates an example process 1400 according to an embodiment. Example process 1400 is provided for the purpose of illustration only and is not limiting embodiments. Process 1400 may be performed by a first STA (e.g., non-AP STA or AP STA) in communication with a second STA (e.g., STA or AP). The first STA and the second STA may be communicatively coupled by a first link and a second link (e.g., 2.4 GHz, 5 GHz, 6 GHz, 60 GHz, etc.). As shown in FIG. 14, process 1400 includes steps 1402 and 1404.
[0141] Step 1402 includes receiving, by the first STA from the second STA, a first MPDU of a first PPDU, the first PPDU comprising a first indication of whether an early acknowledgment is solicited for the first MPDU. In an embodiment, the first indication is comprised in a PHY header of the first PPDU. For example, the first indication may be comprised in a U-SIG or in a UHR-SIG of the PHY header of the first PPDU. In another embodiment, the first indication is comprised in MAC header of the first MPDU. For example, the first indication may be comprised in an A-Control field of the MAC header of the first MPDU. In a further embodiment, the first indication is comprised in a delimiter of the first MPDU.
[0142] In an embodiment, the first indication may be comprised in a bitmap. The bitmap may be carried in a PHY portion or in a MAC portion of the first PPDU. In an embodiment, the bitmap is carried in the MAC portion of a first occurring MPDU of the first PPDU.
[0143] In an embodiment, the first PPDU further comprises a second MPDU. The first PPDU may comprise a second indication of whether an early acknowledgement is solicited for the second MPDU.
[0144] Step 1404 includes, based on the first indication, transmitting, by the first STA to the second STA and without waiting for an end of reception of the first PPDU, a second PPDU comprising an acknowledgement of the first MPDU. In an embodiment, the acknowledgement comprises a positive acknowledgment or a negative acknowledgment.
[0145] In an embodiment, transmitting the second PPDU is based on the indication indicating that an early acknowledgment is solicited for the first MPDU. In an embodiment, transmitting the second PPDU is further based on the acknowledgement comprising a negative acknowledgement.
[0146] In an embodiment, transmitting the second PPDU is further based on the first MPDU belonging to a first traffic category. The first traffic category may comprise low latency traffic or latency sensitive traffic or traffic associated with a pre-determined TID.
[0147] In an embodiment, where the first indication indicates that an early acknowledgment is not solicited for the first MPDU, process 1400 may further comprise transmitting a third PPDU comprising an acknowledgement of the first MPDU after receiving the first PPDU.
[0148] In an embodiment, the first PPDU is received via a first link and the second PPDU is transmitted via a second link.
[0149] FIG. 15 illustrates an example process 1500 according to an embodiment. Example process 1500 is provided for the purpose of illustration only and is not limiting embodiments. Process 1500 may be performed by a first STA (e.g., non-AP STA or AP STA) in communication with a second STA (e.g., STA or AP). The first STA and the second STA may be communicatively coupled by a first link and a second link (e.g., 2.4 GHz, 5 GHz, 6 GHz, 60 GHz, etc.).
[0150] As shown in FIG. 15, process 1500 includes step 1502, which includes transmitting, by a first STA to a second STA, a first PPDU comprising: a first medium access control MPDU and a second MPDU; a first indication of whether an early acknowledgement is solicited for the first MPDU; and a second indication of whether an early acknowledgement is solicited for the second MPDU.
[0151] In an embodiment, the first / second indication is comprised in a PHY header of the first PPDU. For example, the first / second indication may be comprised in a U-SIG or in a UHR-SIG of the PHY header of the first PPDU. In another embodiment, the first / second indication is comprised in MAC header of the first / second MPDU. For example, the first indication / second may be comprised in an A-Control field of the MAC header of the first / second MPDU. In a further embodiment, the first / second indication is comprised in a delimiter of the first / second MPDU.
[0152] In an embodiment, the first / second indication may be comprised in a bitmap. The bitmap may be carried in a PHY portion or in a MAC portion of the first PPDU. In an embodiment, the bitmap is carried in the MAC portion of a first occurring MPDU of the first PPDU.
[0153] In an embodiment, process 1500 may further comprise receiving, by the first STA from the second STA and before an end of transmission of the first PPDU, a second PPDU comprising an acknowledgment of the first MPDU and / or the second MPDU. The acknowledgement may comprise a negative acknowledgement or a positive acknowledgement for the first MPDU and / or the second MPDU.
[0154] In an embodiment, receiving the second PPDU is based on the first indication indicating that an early acknowledgment is solicited for the first MPDU and / or the second indication indicating that an early acknowledgment is solicited for the second MPDU.
[0155] In an embodiment, receiving the second PPDU is further based on the acknowledgement for the first MPDU and / or the second MPDU comprising a negative acknowledgement.
[0156] In an embodiment, receiving the second PPDU is further based on the first MPDU and / or the second MPDU belonging to a first traffic category. The first traffic category may comprise low latency traffic or latency sensitive traffic or traffic associated with a pre-determined TID.
[0157] In an embodiment, wherein the first indication indicates that an early acknowledgment is not solicited for the first MPDU and / or the second MPDU, process 1500 may further comprise receiving a third PPDU comprising an acknowledgement of the first MPDU and / or second MPDU after receiving the first PPDU.
[0158] In an embodiment, the first PPDU is transmitted via a first link and the second PPDU is received via a second link.
[0159] FIG. 16 illustrates an example process according to an embodiment. FIG. 16 illustrates an example process 1600 according to an embodiment. Example process 1600 is provided for the purpose of illustration only and is not limiting embodiments. Process 1600 may be performed by a first STA (e.g., non-AP STA or AP STA) in communication with a second STA (e.g., STA or AP). The first STA and the second STA may be communicatively coupled by a first link and a second link (e.g., 2.4 GHz, 5 GHz, 6 GHz, 60 GHz, etc.). As shown in FIG. 16, process 1600 includes steps 1602 and 1604.
[0160] Step 1602 includes transmitting, by the first STA to the second STA and via the first link, a first MPDU of a first PPDU.
[0161] Step 1604 includes, before an end of transmission of the first PPDU, transmitting, by the first STA to the second STA and via the second link, an acknowledgment request for the first MPDU.
[0162] In an embodiment, transmitting the acknowledgement request is based on the first MPDU belonging to a first traffic category. The first traffic category may comprise low latency traffic or latency sensitive traffic or traffic associated with a pre-determined TID.
[0163] In an embodiment, the acknowledgment request comprises a sequence number of the first MPDU.
[0164] In an embodiment, the acknowledgment request is further for a second MPDU of the first PPDU. In an embodiment, the acknowledgment request comprises a sequence number of the second MPDU.
[0165] In an embodiment, transmitting the acknowledgement request comprises transmitting the acknowledgement request after transmission of the second MPDU.
[0166] In an embodiment, process 1600 further comprises receiving, by the first STA from the second STA and via the second link, a second PPDU comprising an acknowledgment for the first MPDU. In an embodiment, the second PPDU is received before the end of transmission of the first PPDU. In an embodiment, receiving the second PPDU is based on the acknowledgement for the first MPDU comprising a negative acknowledgement.
[0167] FIG. 17 illustrates an example process according to an embodiment. FIG. 17 illustrates an example process 1700 according to an embodiment. Example process 1700 is providedfor the purpose of illustration only and is not limiting embodiments. Process 1700 may be performed by a first STA (e.g., non-AP STA or AP STA) in communication with a second STA (e.g., STA or AP). The first STA and the second STA may be communicatively coupled by a first link and a second link (e.g., 2.4 GHz, 5 GHz, 6 GHz, 60 GHz, etc.). As shown in FIG. 17, process 1700 includes steps 1702, 1704 and 1706.
[0168] Step 1702 includes receiving, by the first station STA from the second STA and via the first link, a first MPDU of a first PPDU.
[0169] Step 1704 includes, before an end of reception of the first PPDU, receiving, by the first STA from the second STA and via the second link, an acknowledgment request for the first MPDU.
[0170] In an embodiment, the acknowledgment request comprises a sequence number of the first MPDU.
[0171] In an embodiment, the acknowledgment request is further for a second MPDU of the first PPDU. In an embodiment, the acknowledgment request comprises a sequence number of the second MPDU.
[0172] In an embodiment, receiving the acknowledgement request comprises receiving the acknowledgement request after reception of the second MPDU.
[0173] Step 1706 includes, based on the acknowledgment request, transmitting, by the first STA to the second STA and without waiting for an end of reception of the first PPDU, a second PPDU comprising an acknowledgement of the first MPDU. In an embodiment, transmitting the second PPDU is based on the acknowledgement for the first MPDU comprising a negative acknowledgement.
Claims
CLAIMS1. A method comprising: receiving, by a first station (STA) from a second STA, a first medium access control (MAC) protocol data unit (MPDU) of a first physical layer (PHY) protocol data unit (PPDU), the first PPDU comprising a first indication of whether an early acknowledgement is solicited for the first MPDU; and based on the first indication indicating that an early acknowledgement is solicited for the first MPDU, transmitting, by the first STA to the second STA and without waiting for an end of reception of the first PPDU, a second PPDU comprising an acknowledgement of the first MPDU.
2. A method comprising: receiving, by a first station (STA) from a second STA, a first medium access control (MAC) protocol data unit (MPDU) of a first physical layer (PHY) protocol data unit (PPDU), the first PPDU comprising a first indication of whether an early acknowledgement is solicited for the first MPDU; and based on the first indication, transmitting, by the first STA to the second STA and without waiting for an end of reception of the first PPDU, a second PPDU comprising an acknowledgement of the first MPDU.
3. The method of claim 2, wherein the first PPDU comprises a second MPDU, and wherein the first PPDU comprises a second indication of whether an early acknowledgement is solicited for the second MPDU.
4. The method of any of claims 2-3, wherein the acknowledgement comprises a positive acknowledgment or a negative acknowledgment.
5. The method of any of claims 2-4, wherein the first indication is comprised in a physical layer (PHY) header of the first PPDU.
6. The method of claim 5, wherein the first indication is comprised in a universal signal field (U-SIG) or in an Ultra High Reliability signal field (UHR-SIG) of the PHY header.
7. The method of any of claims 2-4, wherein the first indication is comprised in a medium access control (MAC) header of the first MPDU.
8. The method of claim 7, wherein the first indication is comprised in an Aggregated Control (A-Control) field of the MAC header of the first MPDU.
9. The method of any of claims 2-4, wherein the first indication is comprised in a delimiter of the first MPDU.
10. The method of any of claims 2-9, wherein transmitting the second PPDU is based on the indication indicating that an early acknowledgment is solicited for the first MPDU.
11. The method of claim 10, wherein transmitting the second PPDU is further based on the acknowledgement comprising a negative acknowledgement.
12. The method of claim 10, wherein the acknowledgement comprises a negative acknowledgement or a positive acknowledgement.
13. The method of any of claims 10-12, wherein transmitting the second PPDU is further based on the first MPDU belonging to a first traffic category.
14. The method of claim 13, wherein the first traffic category comprises low latency traffic or latency sensitive traffic.
15. The method of claim 13, wherein the first traffic category comprises traffic associated with a pre-determined traffic identifier (TID).
16. The method of any of claims 2-15, wherein the first indication indicates that an early acknowledgment is not solicited for the first MPDU, the method further comprising transmitting a third PPDU comprising an acknowledgement of the first MPDU after receiving the first PPDU.
17. The method of any of claims 2-16, wherein the first PPDU is received via a first link and the second PPDU is transmitted via a second link.
18. A method comprising: transmitting, by a first station (STA) to a second STA, a first medium access control (MAC) protocol data unit (MPDU) of a first physical layer (PHY) protocol data unit (PPDU), the first PPDU comprising a first indication of whether an early acknowledgement is solicited for the first MPDU; and based on the first indication indicating that an early acknowledgement is solicited for the first MPDU, receiving, by the first STA from the second STA and before an end of transmission of the first PPDU, a second PPDU comprising an acknowledgement of the first MPDU.
19. A method comprising: transmitting, by a first station (STA) to a second STA, a first physical layer (PHY) protocol data unit (PPDU), comprising: a first medium access control (MAC) protocol data unit (MPDU) and a second MPDU; a first indication of whether an early acknowledgement is solicited for the first MPDU; and a second indication of whether an early acknowledgement is solicited for the second MPDU.
20. The method of claim 19, wherein the first indication is comprised in a physical layer (PHY) header of the first PPDU.
21. The method of claim 20, wherein the first indication is comprised in a universal signal field (U-SIG) or in an Ultra High Reliability signal field (UHR-SIG) of the PHY header.
22. The method of claim 19, wherein the first indication is comprised in a medium access control (MAC) header of the first MPDU.
23. The method of claim 22, wherein the first indication is comprised in an Aggregated Control (A-Control) field of the MAC header of the first MPDU.
24. The method of claim 19, wherein the first indication is comprised in a delimiter of the first MPDU.
25. The method of any of claims 19-24, further comprising receiving, by the first STA from the second STA and before an end of transmission of the first PPDU, a second PPDU comprising an acknowledgment of the first MPDU.
26. The method of claim 25, wherein the first PPDU is transmitted via a first link and the second PPDU is received via a second link.
27. The method of any of claims 25-26, wherein receiving the second PPDU is based on the first indication indicating that an early acknowledgment is solicited for the first MPDU.
28. The method of claim 27, wherein receiving the second PPDU is further based on the acknowledgement comprising a negative acknowledgement.
29. The method of claim 27, wherein the acknowledgement comprises a negative acknowledgement or a positive acknowledgement.
30. The method of any of claims 25-29, wherein receiving the second PPDU is further based on the first MPDU belonging to a first traffic category.
31. The method of claim 30, wherein the first traffic category comprises low latency traffic or latency sensitive traffic.
32. The method of claim 30, wherein the first traffic category comprises traffic associated with a pre-determined traffic identifier (TID).
33. The method of any of claims 19-32, wherein the first indication indicates that an early acknowledgment is not solicited for the first MPDU, the method further comprising receiving a third PPDU comprising an acknowledgement of the first MPDU after receiving the first PPDU.
34. The method of any of claims 19-33, wherein the first PPDU comprises a bitmap comprising the first indication and the second indication.
35. The method of claim 34, wherein the bitmap is comprised in a physical layer (PHY) portion or in a medium access control (MAC) portion of the first PPDU.
36. The method of claim 35, wherein the MAC portion of the first PPDU comprises a MAC header of a first occurring MPDU of the first PPDU.
37. A method comprising: transmitting, by a first station (STA) to a second STA and via a first link, a first medium access control (MAC) protocol data unit (MPDU) of a first physical layer (PHY) protocol data unit (PPDU); and before an end of transmission of the first PPDU, transmitting, by the first STA to the second STA and via a second link, an acknowledgment request for the first MPDU.
38. The method of claim 37, wherein transmitting the acknowledgement request is based on the first MPDU belonging to a first traffic category.
39. The method of any of claims 37-38, wherein the acknowledgment request comprises a sequence number of the first MPDU.
40. The method of any of claims 37-39, wherein the acknowledgment request is further for a second MPDU of the first PPDU.
41. The method of claim 40, wherein the acknowledgment request comprises a sequence number of the second MPDU.
42. The method of any of claims 40-41, wherein transmitting the acknowledgement request comprises transmitting the acknowledgement request after transmission of the second MPDU.
43. The method of any of claims 37-42, further comprising receiving, by the first STA from the second STA and via the second link, a second PPDU comprising an acknowledgment for the first MPDU.
44. The method of claim 43, wherein the second PPDU is received before the end of transmission of the first PPDU.
45. The method of any of claims 43-44, wherein receiving the second PPDU is based on the acknowledgement for the first MPDU comprising a negative acknowledgement.
46. A method comprising: receiving, by a first station (STA) from a second STA and via a first link, a first medium access control (MAC) protocol data unit (MPDU) of a first physical layer (PHY) protocol data unit (PPDU); before an end of reception of the first PPDU, receiving, by the first STA from the second STA and via a second link, an acknowledgment request for the first MPDU; and based on the acknowledgment request, transmitting, by the first STA to the second STA and without waiting for an end of reception of the first PPDU, a second PPDU comprising an acknowledgement of the first MPDU47. The method of claim 46, wherein the acknowledgment request comprises a sequence number of the first MPDU.
48. The method of any of claims 46-47, wherein the acknowledgment request is further for a second MPDU of the first PPDU.
49. The method of claim 48, wherein the acknowledgment request comprises a sequence number of the second MPDU.
50. The method of any of claims 48-49, wherein receiving the acknowledgement request comprises receiving the acknowledgement request after reception of the second MPDU.
51. The method of any of claims 46-50, wherein transmitting the second PPDU is based on the acknowledgement ofthe first MPDU comprising a negative acknowledgment.
52. A device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the device to perform a method according to any of claims 1-51.
53. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method according to any of claims 1-51 .