Frame length indication for low density parity check

Abstract

A first station (STA) transmits, to a second STA, a first frame indicating a first length of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU) to be transmitted by the first STA to the second STA after the first frame. The first STA receives, from the second STA, a second frame in response to the first frame. The first STA transmits, to the second STA, the PPDU, wherein a second length of pre-forward error correction (FEC) padding bits of the PPDU is based on the first length of the PSDU.

Description

Docket No.: 24-3043PCT TITLE Frame Length Indication for Low Density Parity Check CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No.63 / 696,486, filed September 19, 2024, 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 a non-High Throughput (non-HT) Physical Layer Protocol Data Unit (PPDU), a High Throughput (HT) mixed PPDU, and a Very High Throughput (VHT) PPDU.

[0006] FIG.4 illustrates a High Efficiency (HE) Single User (SU) PPDU, an HE Multi-User (MU) PPDU, and an HE Extended Range (ER) SU PPDU.

[0007] FIG.5 illustrates an Extremely High Throughput (EHT) Multi-user (MU) PPDU.

[0008] FIG.6 illustrates an example trigger frame.

[0009] FIG.7 illustrates an example multi-user request to send (MU-RTS) trigger frame.

[0010] FIG.8 illustrates an example common info field.

[0011] FIG.9 illustrates an example data frame which may be used as a quality of service (QoS) null frame.

[0012] FIG.10 illustrates an example of a power save mode.

[0013] FIG.11 illustrates an example of a Dynamic Subband Operation (DSO).

[0014] FIG.12 is an example that illustrates an initial control frame (ICF) / initial control response (ICR) procedure.

[0015] FIG.13 illustrates an example of low density parity check (LDPC) PPDU encoding.

[0016] FIG.14 illustrates an example of pre-forward error correction (pre-FEC) padding.

[0017] FIG.15 illustrates physical layer service data unit (PSDU) and PPDU length signaling across IEEE 802.11 amendments.

[0018] FIG.16 highlights a problem that may arise in PSDU length signaling for a PPDU.

[0019] FIG.17 illustrates an example operation according to an embodiment.

[0020] FIG.18 illustrates a further example operation, according to an embodiment.

[0021] FIG.19 illustrates another further example operation, according to an embodiment.

[0022] FIG.20 illustrates an additional further example operation, according to an embodiment.

[0023] FIG.21 illustrates an example process according to an embodiment of the present disclosure.Docket No.: 24-3043PCT

[0024] FIG.22 illustrates an example process according to an embodiment of the present disclosure.

[0025] FIG.23 illustrates an example process according to an embodiment of the present disclosure.

[0026] FIG.24 illustrates an example process according to an embodiment of the present disclosure.

[0027] FIG.25 illustrates an example multi-AP operation procedure.

[0028] FIG.26 illustrates an example multi-AP sounding phase.

[0029] FIG.27 illustrates an example multi-AP downlink data transmission phase.

[0030] FIG.28 illustrates an example multi-AP uplink data transmission phase. DETAILED DESCRIPTION

[0031] 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 exemplary embodiments. 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.

[0032] 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.

[0033] 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 aDocket No.: 24-3043PCT 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.

[0034] 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 “employing / 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.

[0035] 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.

[0036] In this disclosure, parameters (or equally called, fields, or Information elements: IEs) 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.

[0037] 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 disclosureDocket No.: 24-3043PCT 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.

[0038] 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 behaviorally 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.

[0039] FIG.1 illustrates example wireless communication networks in which embodiments of the present disclosure may be implemented.

[0040] 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.

[0041] 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.

[0042] 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 130and may have the same service set identification (SSID).

[0043] 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.,Docket No.: 24-3043PCT 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.

[0044] 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).

[0045] 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.

[0046] 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” may be 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.

[0047] A physical layer (PHY) protocol data unit (PPDU) may be a composite structure that includes a PHY preamble and a payload in the form of a PLCP service data unit (PSDU). For example, the PSDU may include a PHY Convergence Protocol (PLCP) 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.

[0048] 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.11ax and / or 802.11be 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 transmittedDocket No.: 24-3043PCT over physical channels having bandwidths of 40 MHz, 80 MHz, 160 MHz, or 520 MHz by bonding together multiple 20 MHz channels.

[0049] 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.

[0050] 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.

[0051] 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-transitory 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.

[0052] 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.

[0053] FIG.3 illustrates a non-High Throughput (non-HT) PPDU 310, a High Throughput (HT) mixed mode PPDU 320, and a Very High Throughput (VHT) PPDU 330.

[0054] Non-HT PPDU 310 may be used by STAs conforming to the IEEE 802.11a standard amendment. As shown in FIG.3, non-HT PPDU 310 includes a non-HT Short Training field (L-STF), a non-HT Long Training field (L-LTF), a non-HT Signal field (L-SIG), and a Data field. The L-STF, L-LTF, and L-SIG form a 20 µs preamble of non-HT PPDU 310.

[0055] The L-STF may be used by a receiver of non-HT PPDU 310 to synchronize with the carrier frequency and frame timing of a transmitter of non-HT PPDU 310 and to adjust the receiver signal gain. The L-LTF may be used by the receiver of non-HT PPDU 310 to estimate channel coefficients in order to equalize the channel response (e.g., amplitude and phase distortion) in both the L-SIG and the Data fields of non-HT PPDU 310.Docket No.: 24-3043PCT

[0056] The L-SIG contains parameters needed to demodulate the Data field, which contains a payload of non-HT PPDU 310. 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. The Data Field includes one or more symbols each having a duration of 4 µs, where 3.2 µs carry symbol information and 0.8 µs carry a Guard Interval (GI).

[0057] For non-HT PPDUs, the only supported bandwidth is 20MHz, which is divided into 64 subcarriers. As such, non-HT PPDU 310 may be encoded using a subcarrier spacing of 20MHz / 64 or 312.5kHz.

[0058] HT mixed mode PPDU 320 may be used by STAs conforming to the IEEE 802.11n standard amendment. HT mixed mode PPDU 320 can support MIMO to up to 4 spatial streams, which enhances spectral efficiency four folds. HT mixed mode PPDU 320 has a minimum preamble duration of 35.6 µs, which may increase depending on the number of spatial streams carried by the PPDU.

[0059] As shown in FIG.3, HT mixed mode PPDU 320 includes an L-STF, an L-LTF, an L-SIG, an HT Signal field (HT-SIG) field, an HT Short Training field (HT-STF) field, one or more HT Long Training field (HT- LTF), and a data field. The HT-LTF and data fields include of one or more symbols each having a duration of 3.6 µs or 4 µs. In both cases, 3.2 µs carry symbol information while the remaining 0.4 µs or 0.8 µs carry a GI. The 0.4 µs long GI is called short GI while the 0.8 µs long GI is called regular or normal GI.

[0060] For HT mixed mode PPDUs, two bandwidths, 20 MHz and 140 MHz, may be supported. When the PPDU bandwidth is 20MHz, the band is divided into 64 subcarriers. When the PPDU bandwidth is 140 MHz, the band is divided into 128 subcarriers. In both cases, subcarrier spacing of 312.5 kHz is maintained.

[0061] VHT PPDU 330 may be used by STAs conforming to the IEEE 802.11ac standard amendment. VHT PPDU 330 can support MIMO transmission to up to 8 spatial streams, which enhances spectral efficiency eight folds. VHT PPDU 330 has a minimum preamble duration of 39.6 µs, which may increase depending on the number of spatial streams carried by VHT PPDU 330.

[0062] As shown in FIG.3, VHT PPDU 330 includes an L-STF, an L-LTF, an L-SIG, a VHT Signal A field (VHT-SIG-A), a VHT Short Training field (VHT-STF), one or more VHT Long Training field (VHT-LTF), a VHT Signal B field (VHT-SIG-B), and a Data field. The VHT-LTF and Data fields of VHT PPDU 330 include one or more symbols each having a duration of 3.6 µs or 4 µs. In both cases, 3.2 µs carry symbol information while the remaining 0.4 µs or 0.8 µs carry of the GI. The 0.4 µs long GI is called the Short GI while the 0.8µs long is called regular or normal GI.

[0063] For VHT PPDUs, four bandwidths, 20 MHz, 40 MHz, 80 MHz, and 160 MHz, may be supported. When the PPDU bandwidth is 20MHz, the band is divided into 64 subcarriers. When the PPDU bandwidth is 40 MHz, the band is divided into 128 subcarriers. When the PPDU bandwidth is 80MHz, the band is divided into 256 subcarriers. When the PPDU bandwidth is 160 MHz, the band is divided into two 256-subcarrier 80MHz bands. In all cases, a subcarrier spacing of 312.5 kHz is maintained.Docket No.: 24-3043PCT

[0064] FIG.4 illustrates a High Efficiency (HE) Single User (SU) PPDU 410, an HE Multi-User (MU) PPDU 420, and an HE Extended Range (ER) SU PPDU 430. HE SU PPDU 410, HE MU PPDU 420, and HE ER SU PPDU 430 may be used by STAs conforming to the IEEE 802.11ax standard amendment.

[0065] HE SU PPDU 410 supports higher spectral efficiency compared to VHT PPDU 330 due to increased subcarrier spacing and higher order modulation support. HE SU PPDU 410 has a minimum preamble duration of 44 µs.

[0066] As shown in FIG.4, HE SU PPDU 410 includes an L-STF, an L-LTF, an L-SIG, a Repeated L-SIG (RL-SIG), an HE Signal A field (HE-SIG-A), an HE Short Training field (HE-STF) field, one or more HE Long Training field (HE-LTF), a Data field, and a PE field.

[0067] Similar to HE SU PPDU 410, HE MU PPDU 420 supports higher spectral efficiency compared to VHT PPDU 330. HE MU PPDU 420 also supports OFDMA. Due to denser subcarrier spacing (as in HE SU PPDU 410), HE MU PPDU 420 allows for payloads of multiple users to be multiplexed in the frequency domain in the Data field. HE MU PPDU 420 supports multiplexing the payload of up to 9 users in a single 20 MHz band. HE MU PPDU 420 has a minimum preamble duration of 47.2 µs, which may increase depending on the number of spatial streams carried by HE MU PPDU 420.

[0068] As shown in FIG.4, HE MU PPDU 420 includes an L-STF, an L-LTF, an L-SIG, an RL-SIG, an HE- SIG-A, an HE Signal B Field (HE-SIG-B), an HE-STF field, one or more HE-LTF field, a Data field, and a PE field. It is noted that compared to HE SU PPDU 410, HE MU PPDU 420 further includes HE-SIG-B. HE-SIG- B contains indications per STA of RU allocations. A STA may use the indications in HE-SIG-B to locate its payload in HE MU PPDU 420.

[0069] For HE SU PPDU 410 and HE MU PPDU 420, the GI portion of the HE-LTF and Data field may be one of one of 0.8 µs, 1.6 µs, and 3.2 µs. An AP or STA may use a suitable GI duration depending on the channel conditions or capability of the target STA or AP.

[0070] For both HE SU PPDU 410 and HE MU PPDU 420, the information portion of the HE-LTF may be one of 3.2 µs, 6.4 µs, or 12.8 µs. Depending on the information portion duration, a subcarrier spacing of the HE-LTF may be one of: 312.5kHz if the information potion is 3.2 µs, 156.25kHz if the information portion is 6.4 µs, and 78.125kHz if the information portion is 12.8 µs. Unlike the HE-LTF, the information portion of the Data field for both HE SU PPDU 410 and HE MU PPDU 420 is always 12.8 µs. Hence, a subcarrier spacing of the Data field is always 78.125kHz corresponding to the duration of the information portion being 12.8 µs. When a 3.2 µs or 6.4 µs long HE-LTF is used by a transmitting STA to transmit HE SU PPDU 410 or HE MU PPDU 420, a receiving STA is required to interpolate the channel estimates to a subcarrier spacing resolution of 78.125kHz to match the subcarrier spacing of the Data field.

[0071] As shown in FIG.4, HE ER SU PPDU 430 includes an L-STF, an L-LTF, an L-SIG, an RL-SIG, an HE-SIG-A, an HE-STF, one or more HE-LTF, a Data field, and a PE field. It is noted that compared to HE SU PPDU 410, HE ER SU PPDU 430 has an HE-SIG-A that is duplicated in the time domain (16 µs longDocket No.: 24-3043PCT instead of 8 µs long in HE SU PPDU 410). As such, both L-SIG (duplicated using RL-SIG) and HE-SIG-A are sent in duplicates, which allows a receiving STA to combine the two copies to increase the energy of the received signal. This results in an extended range of reception and increases transmission reliability between the transmitting STA and the receiving STA.

[0072] FIG.5 illustrates an Extremely High Throughput (EHT) Multi-user (MU) PPDU 500. EHT MU PPDU 500 may be used by STAs conforming to the IEEE 802.11be standard amendment. EHT MU PPDU 500 supports OFDMA up to a bandwidth of 320MHz. EHT MU PPDU 500 can improve spectral efficiency due to support of a higher order modulation compared to other PPDUs (e.g., HE SU PPDU 410 and HE MU PPDU 420) while supporting the same number of spatial streams. EHT MU PPDU 500 has a minimum preamble duration of 47.2 µs, which may increase depending on the number of spatial streams carried by EHT MU PPDU 500.

[0073] As shown in FIG.5, EHT MU PPDU 500 includes an L-STF, an L-LTF, an L-SIG, an RL-SIG, a Universal Signal field (U-SIG), an EHT Signal field (EHT-SIG), an EHT Short Training Field (EHT-STF), one or more EHT Long Training fields (EHT-LTF), a Data field, and a PE field. It is noted that according to the IEEE 802.11be standard amendment, EHT MU PPDU 500 may be used by a transmitting STA for both SU and MU transmissions.

[0074] The U-SIG is intended to ensure forward compatibility of EHT MU PPDU 500. This means that any future PPDUs that are backward compatible to IEEE 802.11be will contain the same U-SIG field and interpretation. Because of this, IEEE 802.11be STAs will be able to understand at least in part a PPDU developed in a future amendment.

[0075] The EHT-SIG contains indications per STA of resource unit (RU) allocations. A STA may use the indications in the EHT-SIG to locate its payload in EHT MU PPDU 500.

[0076] The GI portion of the EHT-LTF and Data fields of EHT MU PPDU 500 may be one of: 0.8 µs, 1.6 µs, or 3.2 µs. An AP or STA may use a suitable GI duration depending on the channel conditions or capability of the target STA or AP.

[0077] The information portion of the EHT-LTF may be one of 3.2 µs, 6.4 µs, or 12.8 µs. Depending on the information portion duration, a subcarrier spacing of the EHT-LTF may be one of: 312.5kHz if the information potion is 3.2 µs, 156.25kHz if the information portion is 6.4 µs, or 78.125kHz if the information portion is 12.8 µs. The information portion of the Data field of EHT MU PPDU 500 is always 12.8 µs. Hence, a subcarrier spacing of the Data field is always 78.125kHz corresponding to the duration of the information portion being 12.8 µs. When a 3.2 µs long or a 6.4 µs long EHT-LTF is used by a transmitting STA to transmit EHT MU PPDU 500, a receiving STA is required to interpolate the channel estimates to a subcarrier spacing resolution of 78.125kHz to match the Data field subcarrier spacing.

[0078] FIG.6 illustrates an example trigger frame 600. Trigger frame 600 may correspond to a basic trigger frame as defined in the existing IEEE 802.11ax standard amendment. Trigger frame 600 may be used by anDocket No.: 24-3043PCT AP to allocate resources for and solicit one or more TB PPDU transmissions from one or more STAs. Trigger frame 600 may also carry other information required by a responding STA to transmit a TB PPDU to the AP.

[0079] As shown in FIG.6, trigger frame 600 includes a Frame Control field, a Duration field, a receiver address (RA) field, a transmitter address (TA) field, a Common Info field, a User List Info field, a Padding field, and an FCS field.

[0080] The Frame Control field includes the following subfields: protocol version, type, subtype, To DS, From DS, more fragments, retry, power management, more data, protected frame, and +HTC.

[0081] The Duration field 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 field carries an association identifier (AID) of the STA that transmitted the frame in the 16 least significant bits (LSB), and the 2 most significant bits (MSB) are both set to 1. In other frames sent by STAs, the Duration field contains a duration value (in microseconds) which is used by a recipient to update a network allocation vector (NAV).

[0082] The RA field is the address of the STA that is intended to receive the incoming transmission from the transmitting station. The TA field is the address of the STA transmitting trigger frame 600 if trigger frame 600 is addressed to STAs that belong to a single BSS. The TA field is the transmitted BSSID if the trigger frame 600 is addressed to STAs from at least two different BSSs of the multiple BSSID set.

[0083] The common info field may have a format as illustrated by common info field 800 described further below. The common info field specifies a trigger frame type of trigger frame 600, a transmit power of trigger frame 600 in dBm, and several key parameters of a TB PPDU that is transmitted by a STA in response to trigger frame 600. The trigger frame type of a trigger frame used by an AP to receive QoS data using UL MU operation is referred to as a basic trigger frame.

[0084] The User List Info field contains a User Info field per STA addressed in trigger frame 600. The per STA User Info field includes, among others, an AID subfield, an RU Allocation subfield, a Spatial Stream (SS) Allocation subfield, an MCS subfield to be used by a STA in a TB PPDU transmitted in response to trigger frame 600, and a Trigger Dependent User Info subfield. The Trigger Dependent User Info subfield can be used by an AP to specify a preferred access category (AC) per STA. The preferred AC sets the minimum priority AC traffic that can be sent by a participating STA. The AP determines the list of participating STAs, along with the BW, MCS, RU allocation, SS allocation, Tx power, preferred AC, and maximum duration of the TB PPDU per participating STA.

[0085] The Padding field is optionally present in trigger frame 600 to extend the frame length to give recipient STAs enough time to prepare a response for transmission one SIFS (short interframe spacing) after the frame is received. The Padding field, if present, is at least two octets in length and is set to all 1s.

[0086] The FCS field is used by a STA to validate a received frame and to interpret certain fields from the MAC headers of a frame.Docket No.: 24-3043PCT

[0087] FIG.7 illustrates an example multi-user request to send (MU-RTS) trigger frame 700. MU-RTS trigger frame 700 may be used by an AP to solicit simultaneous CTS frames from multiple STAs to transmit a downlink (DL) MU PPDU to the multiple STAs. As shown in FIG.7, MU-RTS trigger frame 700 may comprise a frame control field, a duration field, an RA field, a TA field, a common info field, one or more user info fields, a padding field, and an FCS field. The frame control, TA, RA, padding, and FCS fields may be similar to the corresponding fields of trigger frame 600 described above. The common info field may have a format as illustrated by common info field 800 described further below. The duration field may be set to the time, in microseconds, required to transmit the DL MU PPDU, plus the time required to transmit one CTS frame, one ACK frame (if required), and three SIFS periods.

[0088] The one or more user info fields correspond respectively to the one or more STAs solicited by MU- RTS trigger frame 700. As shown in FIG.7, a user info field may comprise an AID12 subfield, an RU allocation subfield, reserved bits, and a PS 160 subfield. The AID12 subfield comprises an association identifier of the STA to which the user info field is addressed. The RU allocation subfield indicates a channel on which the solicited STA is to transmit the CTS frame. In an example, this may include a primary 20 MHz channel, a primary 40 MHz, a primary 80 MHz channel, a primary 160 MHz, an 80+80 Mhz channel, or a 320 MHz channel.

[0089] FIG.8 illustrates an example Common Info field 800. Common Info field 800 may be an embodiment of the Common Info field of trigger frame 600 or MU-RTS trigger frame 700, for example. As shown in FIG. 8, Common Info field 800 may include a Trigger Type subfield, a UL Length subfield, a More TF subfield, a CS required subfield, a UL BW subfield, a GI and HE / EHT-LTF Type / Triggered TXS Mode subfield, a first Reserved subfield, a Number of HE / EHT-LTF Symbols subfield, a second Reserved subfield, an LDPC Extra Symbol Segment subfield, an AP Tx Power subfield, a Pre-FEC Padding Factor subfield, a PE Disambiguity subfield, an UL Spatial Reuse subfield, a third Reserved subfield, an HE / EHT P180 subfield, a Special User Info Field Flag subfield, an EHT Reserved subfield, a fourth Reserved subfield, and a Trigger Dependent Common Info subfield. The Trigger Type subfield, UL Length subfield, More TF subfield, CS required subfield, UL BW subfield, GI and HE-LTF Type / Triggered TXS Mode subfield, first Reserved subfield, Number of HE / EHT-LTF Symbols subfield, second Reserved subfield, LDPC Extra Symbol Segment subfield, AP Tx Power subfield, Pre-FEC Padding Factor subfield, PE Disambiguity subfield, UL Spatial Reuse subfield, third Reserved subfield, HE / EHT P180 subfield, Special User Info Field Flag subfield, EHT Reserved subfield, fourth Reserved subfield, and Trigger Dependent Common Info subfield may have the same content and interpretation as corresponding subfields of an EHT variant Common Info field defined in the IEEE 802.11be draft amendment (“IEEE P802.11be / D3.1, March 2023”).

[0090] FIG.9 illustrates an example data frame 900 which may be used as a QoS null frame. A QoS null frame refers to a QoS data frame with an empty frame body. QoS null frame includes a QoS control field andDocket No.: 24-3043PCT 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.

[0091] The QoS control field may include a traffic identifier (TID) subfield, an acknowledgment (Ack) policy indicator subfield, and a queue size subfield (or a transmission opportunity (TXOP) duration requested subfield).

[0092] 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).

[0093] The ack policy indicator subfield, together with other information, identifies the Ack policy followed upon delivery of the MPDU (e.g., normal Ack, implicit block Ack request, no Ack, block Ack, etc.)

[0094] 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 the TXOP duration assigned to the STA or to determine the uplink (UL) resources assigned to the STA.

[0095] In a frame sent by or to a non-high efficiency (non-HE) STA, the following rules may apply to the queue size value:

[0096] 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.

[0097] 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.

[0098] A queue size value of 254 is used for all sizes greater than 64768 octets.

[0099] A queue size value of 255 is used to indicate an unspecified or unknown size.

[0100] In a frame sent by an HE STA to an HE AP, the following rules may apply to the queue size value.

[0101] 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.

[0102] The queue size subfield includes a scaling factor subfield in bits B14–B15 of the QoS control field and an unscaled value, UV, in bits B8–B13 of the QoS control field. The scaling factor subfield provides the scaling factor, SF.Docket No.: 24-3043PCT

[0103] A STA obtains the queue size, QS, from a received QoS control field, which contains a scaling factor, SF, and an unscaled value, UV, as follows:

[0104] QS =

[0105] 16 ×UV, if SF is equal to 0;

[0106] 1024 + 256 × UV, if SF is equal to 1;

[0107] 17408 + 2048 × UV, if SF is equal to 2;

[0108] 148480 + 32768 × UV, if SF is equal to 3 and UV is less than 62;

[0109] > 2147328, if SF equal to is 3 and UV is equal to 62;

[0110] Unspecified or Unknown, if SF is equal to 3 and UV is equal to 63.

[0111] 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.

[0112] The HT control field may include an aggregated control (A-Control) subfield. The A-Control subfield may include a control list subfield including one or more control subfields. A control subfield (of the one or more control subfields) may be a length indication control subfield, as discussed below in connection with FIG.18. For example, the control subfield may indicate a next PSDU length for a subsequent data frame. Alternatively, or in addition, the control subfield may be a padding indicator subfield, as discussed below in connection with FIG.20. For example, the control subfield may include a next padding boundary indicator for granular pre-FEC padding.

[0113] FIG.10 illustrates an example 1000 of a power save (PS) mode. As shown in FIG.10, example 1000 includes STAs 1002 and 1004. STAs 1002 and 1004 may each be an AP STA or a non-AP STA. It is assumed that STA 1004 implements the PS mode illustrated in FIG.10, which may be denoted as a dynamic PS mode or a low power listening (LPL) mode.

[0114] In an implementation, a STA (AP STA or non-AP STA) implementing the PS mode illustrated in FIG. 10 may be in a first power state of the PS mode or in a second power state of the PS mode. The first power state may be referred to as a lower power receive state or a listen / listening state. The second power state may be referred to as a high power receive state or an awake state. While in the first power state, the STA is capable of receiving PPDUs of a first category. While in the second power state, the STA is capable of receiving PPDUs of the first category and PPDUs of a second category. In an implementation, the STA is not capable of receiving PPDUs of the second category during the first power state. In an implementation, the STA is capable of receiving PPDUs of only the first category during the first power state.Docket No.: 24-3043PCT

[0115] In an implementation, the first category may include PPDUs having a non-HT PPDU format such as non-HT PPDU 310 described above. In another implementation, the first category may include, additionally or alternatively, PPDUs having a data rate that is less than or equal to 24 Mbps, a bandwidth of 20 MHz, and / or a single spatial stream. The second category may include PPDUs having a format other than the non- HT PPDU format. For example, the second category may include PPDUs having a high throughput (HT) format such as HT mixed mode PPDU 320, a VHT format such as VHT PPDU 330, an HE PPDU such as HE SU PPDU 410, HE MU PPDU 420, or HE ER SU PPDU 430, an EHT PPDU such as EHT MU PPDU 500, an ultra-high reliability (UHR) PPDU, or a physical layer version identifier field. Additionally, or alternatively, the second category may include PPDUs having a data rate that is greater than 24 Mbps, a bandwidth greater than 20 MHz, and / or a plurality of spatial streams.

[0116] The STA may transition between the first power state and the second power state of the PS mode. In an implementation, to reduce the power consumption of the STA, the first power state may correspond to a default state of the PS mode. As such, the STA may operate in the first power state and may transition to the second power state as needed.

[0117] In an implementation, as illustrated in example 1000, the STA may transition from the first power state to the second power state in response to being solicited by another STA. For example, as shown in FIG.10, STA 1004, which implements the PS mode, may operate in the first power state and may transition to the second power state in response to a solicitation from STA 1002. Specifically, STA 1002 may transmit an initial control frame (ICF) 1006 to STA 1004 requesting that STA 1004 transition from the first power state to the second power state of the PS mode. STA 1002 may request that STA 1004 transition from the first power state to the second power state in order to transmit to STA 1004 a PPDU 1010 of the second category that STA 1004 is not capable of receiving during the first power state (e.g., an EHT PPDU, a PPDU having a bandwidth greater than 20 MHz, and / or a PPDU having multiple spatial streams). In an implementation, ICF 1006 may be a request to send (RTS) frame, a multi-user RTS (MU-RTS) frame, or a BlockAck Request (BAR) frame. ICF 1006 may be carried in a PPDU of the first category. In an implementation, ICF 1006 may be carried in a PPDU using a non-HT duplicate format with a bandwidth of 40 MHz, 80 MHz, 160 MHz or 320 MHz. In an implementation, ICF 1006 may include signaling indicating the PPDU bandwidth.

[0118] On receiving ICF 1006, STA 1004 initiates a transition from the first power state to the second power state. For example, on receiving ICF 1006, STA 1004 may enable / power on receiver capabilities needed to receive the PPDU of the second category that STA 1002 wishes to transmit to STA 1004. The transition from the first power state to the second power state may be associated with a state transition duration. The state transition duration may depend on the processing capabilities of STA 1004. In an implementation, STA 1002 may include padding in ICF 1006 to allow STA 1004 to transition from the first power state to the second power state in a timely manner. Hence, as shown in FIG.10, STA 1004 may start the state transition before the reception of ICF 1006 is completed (i.e. without decoding the padding information).Docket No.: 24-3043PCT

[0119] In an implementation, STA 1004 responds to ICF 1006 by transmitting an initial control response (ICR) 1008 to STA 1002. ICR 1008 informs STA 1002 that STA 1004 is transitioning from the first power state to the second power state. In an implementation, as shown in FIG.10, STA 1004 may transmit ICR 1008 while transitioning from the first power state to the second power state. In an implementation, STA 1004 may transmit ICR 1008 after completing the transition from the first power state to the second power state. Completing the transition before transmitting ICR 1008 may enable STA 1004 to perform clear channel assessment over a bandwidth that is higher than 20 MHz. This may enable STA 1004 to transmit ICR 1008 on idle channels with bandwidths higher than 20 MHz, which improves hidden node protection due to the transmission of ICR 1008. In another implementation, STA 1004 may transmit ICR 1008 before completing the transition to the second power state. In such an implementation, STA 1004 may only be able to transmit ICR 1008 using a bandwidth of 20 MHz. ICR 1008 may be carried in a PPDU of the first category or the second category. In an implementation, STA 1004 transmits ICR 1008 a short interframe space (SIFS) after receiving ICF 1006.

[0120] On receiving ICR 1008, STA 1002 initiates transmission of PPDU 1010. In an implementation, STA 1002 transmits PPDU 1010 a SIFS after receiving ICR 1008. In an implementation, STA 1002 may begin transmitting PPDU 1010 while STA 1004 is still transitioning from the first power state to the second power state. PPDU 1010 may thus include a first PPDU part 1014 of the first category and a second PPDU part 1016 of the second category. In another implementation, STA 1002 may begin transmitting PPDU 1010 after STA 1004 has transitioned to the second power state. PPDU 1010 may thus be entirely of the second category.

[0121] After receiving PPDU 1010, STA 1004 may transmit a BA frame 1012 to STA 1002. In an implementation, STA 1004 may return to the first power state after receiving PPDU 1010. STA 1004 may transmit BA frame 1012 while in the second power state or after returning to the first power state.

[0122] FIG.11 illustrates an example 1100 of a Dynamic Subband Operation (DSO). As shown in FIG.11, example 1100 includes an AP 1110, a STA 1115, and a STA 1117. In an example, AP 1110 may operate over a plurality of channels, including a primary channel (PCH) 1122 and a secondary channel (SCH) 1120. In an example, AP 1110 supports a coordinated R-TWT operation (e.g., Level 2). In example 1100, AP 1110 supports a bandwidth up to 320 MHz, while STA 1115 and STA 1117 support a bandwidth up to160 MHz.

[0123] In example 1100, AP 1110 has DSO capabilities which enable AP 1110 to utilize available bandwidth in a dynamic manner on a per-TXOP basis whenever AP 1110 wins channel access to the bandwidth.

[0124] In example 1100, STA 1115 may support DSO and may be referred to as a “DSO STA.” As a DSO STA, STA 1115 may switch channel of operations from a primary channel to a secondary channel after receiving from an AP an initial control frame (ICF) that indicates the switch from the primary channel to the secondary channel. As a DSO STA, STA 1115 may respond to the ICF with an initial control ICR response (ICR) frame via the secondary channel to inform the AP of the switch to the secondary channel. In exampleDocket No.: 24-3043PCT 1100, STA 1117 may not support DSO and may be referred to as a “non-DSO STA.” As such, STA 1117 may not respond to an ICF from an AP indicating a switch from the primary channel to the secondary channel.

[0125] Example 1100 begins with AP 1110 transmitting an ICF 1170 over PCH 1122 and SCH 1120. ICF 1170 may indicate a switch from PCH 1122 to SCH 1120. On receiving ICF 1170, STA 1115 switches its channel of operation from PCH 1122 to SCH 1120. STA 1115 may respond to ICF 1170 with an initial control response (ICR) frame 1171 via SCH 1120 to inform AP 1110 that STA 1115 successfully switched to SCH 1120.

[0126] After receiving ICF 1170, STA 1117 may transmit an ICR frame 1172 on PCH 1122, to inform AP 1110 that STA 1117 is able to receive a DL frame on PCH 1122, e.g., PCH 1122 is not busy from the perspective of STA 1117.

[0127] Continuing example 1100, after receiving ICR frames 1171 and 1172 from STA 1115 and STA 1117 respectively, AP 1110 may transmit a DL frame 1150 to both of STAs 1115 and 1117. As shown in FIG.11, DL frame 1150 may comprise data 1160 for STA 1115 on SCH 1120 and data 1165 for STA 1117 on PCH 1122. In an implementation, AP 1110 may transmit DL frame 1150 by using an OFDMA PPDU (i.e., a PPDU format in which data 1160 and data 1165 are transmitted via distinct resource units within the PPDU), a frequency domain aggregated physical layer PPDU (A-PPDU) (i.e. a PPDU format in which data 1160 and data 1165 are transmitted using distinct PPDUs which may or may not have the same PPDU format on SCH 1120 and PCH 1122 respectively), or a Frequency Division Multiple Access (FDMA) PPDU (i.e. a PPDU format in which data 1160 and data 1165 are transmitted via distinct frequency subchannels).

[0128] In response to data 1160, STA 1115 may transmit a BA frame 1118 while still on SCH 1120 before returning to PCH 1122. In an alternative or additional example, AP 1110 may not solicit a BA frame from STA 1115. With no BA frame solicited, STA 1115 may return to PCH 1122 after receiving data 1160. In response to data 1165, STA 1117 may transmit a BA frame 1119 on PCH 1122. In an alternative or additional example, AP 1110 may not solicit a BA frame from STA 1117.

[0129] FIG.12 is an example 1200 that illustrates an ICF / ICR procedure. As shown in FIG.12, example 1200 may include an AP 1202 and STAs 1204 and 1206. STAs 1204 and 1206 may be associated with AP 1202. For the purpose of illustration, example 1200 also illustrates STAs of an overlapping basic service set (OBSS) relative to the BSS of AP 1202 (OBSS STAs). The OBSS STAs, as shown in FIG.12, may be hidden from AP 1202 (outside of the communication range of AP 1202) or exposed to AP 1202 (within the communication range of AP 1202).

[0130] In example 1200, AP 1202 wishes to transmit a downlink (DL) multi-user (MU) PPDU 1214 to STAs 1204 and 1206. DL MU PPDU 1214 may comprise data for each of STAs 1204 and 1206. DL MU PPDU 1214 may occupy a plurality of channels (e.g., 20 MHz channels). Each channel of the plurality of channels may carry the data for a respective STA (e.g., STA 1204, STA 1206) served by DL MU PPDU 1214.Docket No.: 24-3043PCT

[0131] As shown in FIG.12, to protect the transmission of DL MU PPDU 1214 to STAs 1204 and 1206 from interference by OBSS STAs hidden from AP 1202, AP 1202 may use an ICF / ICR procedure to initiate a TXOP and for TXOP protection (e.g., to protect the TXOP frame exchange sequence). AP 1202 may initiate the TXOP by transmitting a ICF trigger frame 1208 that solicits simultaneous ICR frame transmissions from STAs 1204 and 1206.

[0132] ICF trigger frame 1208 may comprise a frame control field, a duration field, an RA field, a TA field, a common info field, one or more user info fields, a padding field, and an FCS field. The frame control, TA, RA, padding, and FCS fields may be similar to the corresponding fields of trigger frame 600 described above. The common info field may have a format as illustrated by common info field 800 described above. The duration field may be set to the time, in microseconds, required to transmit DL MU PPDU 1214, plus the time required to transmit one ICR frame, one ACK frame (if required), and three SIFS periods.

[0133] The one or more user info fields correspond respectively to the one or more STAs solicited by the ICF trigger frame. In example 1200, ICF trigger frame 1208 may comprise a user info field for each of STAs 1204 and 1206 indicating that an ICR frame is solicited from each of STAs 1204 and 1206. For example, the ICF trigger frame 1208 can be a MU-RTS trigger frame as illustrated in FIG.7. A user info field may comprise an AID12 subfield, an RU allocation subfield, reserved bits, and a PS 160 subfield. The AID12 subfield comprises an association identifier of the STA to which the user info field is addressed. The RU allocation subfield indicates a channel on which the solicited STA is to transmit the CTS frame. In an example, this may include a primary 20 MHz channel, a primary 40 MHz, a primary 80 MHz channel, a primary 160 MHz, an 80+80 Mhz channel, or a 320 MHz channel.

[0134] AP 1202 may send ICF frame 1208 in a PPDU that occupies one or more channels (e.g., 20 MHz channels). In an example, for each channel occupied by the PPDU that carries ICF trigger frame 1208, AP 1202 may request at least one non-AP STA to send a ICR frame that occupies that channel. In an example, AP 1202 may not request that a non-AP STA send a ICR frame that occupies a channel that is not occupied by the PPDU carrying ICF trigger frame 1208.

[0135] After transmitting ICF trigger frame 1208, AP 1202 may wait for a CTSTimeout interval of aSIFSTime + aSlotTime + aRxPHYStartDelay that begins when a MAC layer of AP 1202 receives a PHYTXEND.confirm primitive for transmitted ICF trigger frame 1208. If the MAC layer does not receive a PHY- RXEARLYSIG.indication or a PHY-RXSTART.indication primitive during the CTSTimeout interval, AP 1202 may conclude that the transmission of ICF trigger frame 1208 has failed, and, if ICF trigger frame 1208 initiated a TXOP, AP 1202 may invoke its backoff procedure. If the MAC layer receives a PHY- RXEARLYSIG.indication or a PHY-RXSTART.indication primitive during the CTSTimeout interval, then the MAC layer may wait for the corresponding PHY-RXEND.indication primitive to determine whether transmission of ICF trigger frame 1208 was successful. The receipt of a ICR frame from any non-AP STA addressed by ICF trigger frame 1208 before the PHY-RXEND.indication primitive shall be interpreted as theDocket No.: 24-3043PCT successful transmission of ICF trigger frame 1208, permitting the frame exchange sequence to continue. The receipt of any other type of frame shall be interpreted as a failure of the transmission of ICF trigger frame 1208. AP 1202 may process the received frame and, if ICF trigger frame 1208 initiated a TXOP, AP 1202 shall invoke its backoff procedure at the PHY-RXEND.indication primitive.

[0136] In example 1200, on receiving ICF trigger frame 1208, STAs 1204 and 1206 respond by transmitting respectively ICR frames 1210 and 1212 to AP 1202. In an example, STAs 1204 and 1206 begin the transmission of ICR frames 1210 and 1212, respectively, at the SIFS time boundary after an end of a received PPDU comprising ICF trigger frame 1208. In an example, STA 1204 (or STA 1206) responds to ICF trigger frame 1208 with a ICR frame when the following conditions are met: ICF trigger frame 1208 comprises a user info field addressed to the STA (the AID12 subfield of the user info field is equal to the 12 LSBs of the AID of the STA) and ICF trigger frame 1208 is sent by an AP with which the STA is associated; and the UL MU CS condition indicates that the medium is idle as described in section 26.5.2.5 (UL MU CS mechanism) of the IEEE 802.11 standard (“IEEE P802.11-REVme™ / D3.0, April 2023”). Otherwise, if one of the conditions is not met, STA 1204 (or STA 1206) does not send a ICR frame to AP 1202.

[0137] In an example, STAs 1204 and 1206 may set an RA field of respectively ICR frames 1210 and 1212 to a TA obtained from the TA field of ICF trigger frame 1208. In an example, STAs 1204 and 1206 may set a duration field of respectively ICR frames 1210 and 1212 based on the duration field of ICF trigger frame 1208, namely as equal to the value of the duration field of ICF trigger frame 1208, adjusted by subtracting the time required to transmit respectively ICR frames 1210 and 1212 and one SIFS period.

[0138] OBSS STAs exposed to AP 1202 may receive ICF trigger frame 1208 due to being within the communication range of AP 1202. In an example, as shown in FIG.12, on receiving ICF trigger frame 1208, OBSS STAs exposed to AP 1202 set their respective NAVs based on the duration field of ICF trigger frame 1208. As such, the OBSS STAs exposed to AP 1202 may not access the wireless medium for the duration of the TXOP initiated by AP 1202.

[0139] OBSS STAs hidden from AP 1202 do not receive ICF trigger frame 1208 due to being outside the communication range of AP 1202. However, in an example, as shown in FIG.12, some of the OBSS STAs hidden from AP 1202 may receive ICR frame 1210 and / or ICR frame 1212 and may set their respective NAVs based on the duration field of ICR frame 1210 and / or ICR frame 1212. As such, some of the OBSS STAs hidden from AP 1202 may also not access the wireless medium for the duration of the TXOP initiated by AP 1202.

[0140] On receiving ICR frame 1210 and / or ICR frame 1212, AP 1202 may wait one SIFS period before transmitting DL MU PPDU 1214. On receiving DL MU PPDU 1214, STAs 1204 and 1206 may respond by transmitting respective BlockAck (BA) frames 1216 and 1218 to AP 1202.

[0141] When a large PPDU (e.g., greater than 2 milliseconds (it is noted that the maximum PPDU duration is 5.484 milliseconds according to the existing 802.11 standard)) is transmitted in a TXOP, other availableDocket No.: 24-3043PCT downlink and / or uplink traffic may incur large delays before it may be transmitted over the wireless medium. To solve this potential problem, a technique called pre-emption has been proposed. According to this technique, a large PPDU may be broken up into multiple short PPDUs (e.g., shorter than 2 milliseconds) that are transmitted successively during the TXOP. A PPDU comprising other downlink and / or uplink traffic may be allowed to be transmitted over the wireless medium in place of (“pre-empt”) one or more of the short PPDUs. The PPDU may be referred to as a “pre-empting PPDU” and the one or more of the short PPDUs may be referred to as “pre-empted PPDUs.” The pre-empted PPDUs may be transmitted after the pre- empting PPDU has been transmitted.

[0142] FIG.13 illustrates an example 1300 of low density parity check (LDPC) PPDU encoding. As shown in FIG.13, example 1300 illustrates LDPC encoding to fit data bits 1302 to fixed length LDPC codewords and a fixed length number of OFDM symbols. As discussed below, data bits 1302 are combined with a number of shortening bits 1304 and parity bits 1306 for LDPC encoding. The shortening bits 1304 are then discarded, and a portion of the parity bits 1306 are punctured and also discarded. The data bits 1302 and remaining parity bits 1308 are then repeated, using repeat bits 1310, to create the fixed length number of OFDM symbols. As illustrated, in example 1300 outlined arrows indicate encoding procedure steps, while solid arrows indicate a direction of puncturing and padding with repeated bits.

[0143] In further detail, in an example LDCP PPDU encoding involves a series of steps, performed in sequence. First, an encoder may compute the number of available bits, Navbits, in a minimum number of OFDMA symbols in which the data field of a PPDU may fit. For example, Navbits may be calculated using anequation ^^^^^^^ = ^^^^^ ∗ ^^^^^ ∗ ^ ^^^^^^^^^∗^∗^^^^^^ where mSTBC is 2 if space-time block coding(STBC) is usedlength field in a HT-SIG field, NCBPSis a number of coded bits per symbol, and Npld is a number of bits in a PSDU service field. Npld may be calculated using anequation: ^^^^ = !"#$ℎ ∗ 8 + 16. This is merely an example, and the encoder may compute the numberof available bits using any suitable technique.

[0144] Second, an encoder may compute an integer number of LDPC codewords to be transmitted, NCW, and a length of codewords to be used, LLDPC. For example, the encoder may use the table below of PPDU encoding parameters to compute NCWand LLDPC: Range of NavbitsNumber of LDPC LDPC Codeword Length (LLDPC)Docket No.: 24-3043PCT 1944 < Navbits ≤ 2592 2 1944, if Navbits ≥ Npld + 2916 * (1-R) 1296, otherwise Thi to be tran

[0145] Third, an encoder may compute the number of shortening bits 1304, Nshrt, to be padded to the Npld data bits 1302 before encoding. For example, the encoder may use the equation: ^^*+^=max,0, .^^ / ∗ 012^^ ∗ (3 − ^^^^5. In this example, when Nshrt = 0, shortening is not performed. WhenNshrt> 0, shortening bits 1304 may be equally distributed over all NCWcodewords with the first Nshrtmod NCWcodewords shortened 1 bit more than the remaining codwords. A variable Nspcw may be defined as equal to⌊^^*+^⁄ ^^ / ⌋ , such that when Nshrt > 0, shortening may be performed by setting information bits9:;^<^=>;1, ... , 9:;1 to 0 in the first Nshrt mod NCW codewords, and setting information bits9:;^<^=> , ... ,0 in the remaining codewords. For all values of Nshrt, the encoder may encode each ofthe NCWcodewords using suitable LDPC encoding techniques. When Nshrt> 0, the shortening bits 1304 may be discarded after encoding. This is merely an example, and the encoder may compute the number of shortening bits using any suitable technique.

[0146] Fourth, an encoder may compute a number of bits to be punctured, Npunc, from the codewords afterencoding. For example, the encoder may use the equation: ^^@AB = max.0, .^^ / ∗ 012^^3 − ^^^^^^^ −^^*+^3. In this example, if Npunc > 0.1*NCW*LLDPC*(1-R), and Nshrt < 1.2*Npunc* ^1;^ is true, or if Npunc >0.3*NCW*LLDPC*(1-R) is true, then the encoder may increment Navbits and recompute Npunc using the following two equations (e.g., using the following two equations once): ^^^^^^^ = ^^^^^^^ + ^^^^^ ∗ ^^^^^^^@AB = max.0, .^^ / ∗ 012^^3 − ^^^^^^^ − ^^*+^3.The punctured bits may be equally distributed over all NCWcodewords with the first Npuncmod NCWcodewordspunctured 1 bit more than the remaining codewords. A variable Nppcw may be defined as C^^@AB⁄ ^^ / D.When Nppcw > 0, puncturing may be performed by discarding parity bits EA;:;^^^=>;1, ... , EA;:;1 of thefirst Npunc mod NCW codewords and discarding parity bits EA;:;^^^=> , ... , EA;:;1 of the remainingcodewords after encoding. A number of OFDM symbols to be transmitted in a PPDU may be computed usingan equation: ^^FG = ^^^^^^^⁄ ^^^^^ . This is merely an example, and the encoder may compute a numberof bits to be punctured using any suitable technique.

[0147] Fifth, an encoder may compute a number of coded bits to be repeated as repeat bits 1310, Nrep. Forexample, the encoder may use the equation: ^+H^ = max,0, ^^^^^^^ − ^^ / ∗ 012^^ ∗ .1 − (3 −Docket No.: 24-3043PCT ^^^^5. The number of coded bits to be repeated as repeat bits 1310 may be equally distributed over all NCWcodewords with one or more bits repeated for the first Nrepmod NCWcodewords as compared with the remaining codewords (e.g., when puncturing occurs, coded bits may be not repeated, and vice versa). The coded bits to be repeated for any codeword may be copied only from that codeword itself, starting from information bit i0and continuing sequentially through the information bits and, when necessary, into the parity bits 1308, until the required number of repeated bits is obtained for that codeword. In this example the repeated bits may be copied from the codeword after the shortening bits have been removed. If, for a codeword, the required number of repeated bits are not obtained in this manner (i.e., repeating the codeword once), the procedure may be repeated until the required number is achieved. These repeat bits 1310 may then be concatenated to the codeword, after the parity bits 1308 in their same order. This is merely an example, and the encoder may compute a number of coded bits to be repeated using any suitable technique.

[0148] Sixth, an encoder may, for each of the NCWcodewords, process data using a number of shortening bits per codeword. For example, the number of shortening bits per codeword may be computed as described above for the third step. Further, the encoder may puncture or repeat bits per codeword (e.g., as computed using the techniques described above in relation to the fourth and fifth steps). This is illustrated in example 1300.

[0149] Finally, an encoder may aggregate all codewords and parse. For example, an encoder may take a succession of LDPC codewords resulting from the steps described above, and convert these codewords into a bitstream in sequential fashion. Within each codeword, the encoder may order a bit i0first. Further, the encoder may parse the encoded data stream into spatial streams using parsing rules for a binary convolutional code (BCC) encoder, bypassing a frequency interleaver.

[0150] FIG.14 illustrates an example 1400 of pre-forward error correction (pre-FEC) padding. Pre-FEC padding may be implemented in the PHY layer of a STA that initiates a transmission of a PPDU. Prior to the steps illustrated in example 1400, a MAC layer of the STA may issue a PHY-transmit start (TXSTART) request primitive to the PHY layer to transmit a PSDU. The PHY-TXSTART request primitive may include a transmit vector (e.g., TXVECTOR) parameter that includes the length of the PSDU (e.g., APEP_LENGTH). As shown in FIG.14, example 1400 illustrates a two step padding process for a PPDU (e.g., an HE PPDU, or an EHT PPDU). A first step includes pre-FEC padding, in which information bits (e.g. service field bits and PSDU bits) are combined with pre-FEC padding bits and provided to a scrambler, prior to FEC. A second step includes post-FEC padding, in which post-FEC padding bits are combined with FEC output bits (e.g., FEC encoded bits). For example, as illustrated NCBPSis a number of coded bits per OFDM symbol and NCBPS.LAST is a number of bits in a last OFDM symbol (e.g., for transmission). Post-FEC padding may add padding bits to create NCBPStotal bits, from NCBPS.LASTbits in the last OFDM symbol.

[0151] As illustrated, pre-FEC padding (e.g., pre-FEC MAC padding, pre-FEC PHY padding, or both) is applied before conducting FEC coding, such that after scrambling and FEC a coded symbol (e.g., a PSDU +Docket No.: 24-3043PCT padding) ends at one of four padding boundaries (e.g., illustrated as a=1, 2, 3, 4). For example, four pre-FEC padding boundaries partition the last one (e.g., in the case of non-STBC) or two (e.g., in the case of STBC) OFDM symbols of a PPDU (e.g., a HE PPDU) into four symbol segments. The pre-FEC padding may pad toward one of the four possible boundaries (e.g., a=1, 2, 3, 4). The four pre-FEC padding boundaries are represented by a pre-FEC padding factor parameter a, and are approximately 1 / 4 of the NCBPS (e.g., for a=1), 1 / 2 of the NCBPS(e.g., for a=2), 3 / 4 of the NCBPS(e.g., for a=3), and NCBPS(e.g., for a=4).

[0152] In an example, the coded symbol may be transmitted to a receiver. The receiver may determine which coded bits it needs to decode (e.g., to decode the data among the padding bits) based on the number of OFDM symbols and the padding boundary. That is, the receiver may not need to know the total number of data bits in the PPDU. Instead, the receiver may identify the number of OFDM symbols (e.g., signaled in a L-STF as discussed above in relation to FIGS.4-5) and the padding boundary (e.g., in a HE-SIG-A for 802.11ax PPDUs, as discussed above in relation to FIG. 4, or in a EHT-SIG for 802.11be PPDUs, as discussed above in relation to FIG.5), and may use that to determine which bits to decode. By using pre- FEC padding, HE PPDUs (e.g., 802.11ax PPDUs) and EHT PPDUs (e.g., 802.11bn PPDUs) need not signal a PSDU length in their preambles.

[0153] While example 1400 illustrates pre-FEC padding using four possible padding boundaries (e.g., a=1, 2, 3, 4), this is merely an example. Alternatively, or in addition, pre-FEC padding may instead use a flexible (e.g., higher granularity) padding factor. For example, the padding boundaries may be changed from 1 / 4, 1 / 2, 3 / 4, and 1, to N higher granularity boundaries (e.g., 8 boundaries, 16 boundaries, 32 boundaries, or any other suitable number of boundaries). This may reduce the number of bits used for pre-FEC padding by providing higher granularity boundaries, and may introduce performance gains, but may require additional changes, including transmitting to a receiver sufficient information to identify the padding factor. This is discussed further, below, with regard to FIGS.19-20.

[0154] FIG.15 illustrates a table 1500 describing PSDU and PPDU length signaling across IEEE 802.11 amendments. The table 1500 includes rows corresponding to IEEE 802.11 amendments from 802.11a through 802.11be, and illustrating whether each amendment of 802.11 describes PSDU length signaling, PPDU length signaling, or both.

[0155] Starting with PSDU length signaling, in one example a transmitting STA may signal to a receiving STA PSDU length to allow the receiver to identify which received bits to decode (e.g., to identify data bits among padding bits). IEEE 802.11a, 802.11n, and 802.11ac amendments each include this PSDU length signaling. In the IEEE 802.11a amendment the PSDU length may be signaled using a LENGTH field in a L- SIG. The L-SIG is discussed further, above, in relation to FIG.3. In the IEEE 802.11n amendment the PSDU length may be signaled using a HT-LENGTH field in a HT-SIG. The HT-SIG is discussed further, above, in relation to FIG. 3. In the IEEE 802.11ac amendment the PSDU length may be signaled using a APEP_LENGTH field in a VHT-SIG-B. The VHT-SIG-B is discussed further, above, in relation to FIG.3.Docket No.: 24-3043PCT

[0156] Alternatively, or in addition, pre-FEC padding may be used to allow a receiver to identify data bits for decoding, without signaling a PSDU length. For example, as discussed above in relation to FIG.14, a receiver may determine which coded bits the receiver needs to decode (e.g., to decode the data among the padding bits) based on the number of OFDM symbols and the padding boundary. IEEE 802.11ax and 802.11be amendments apply pre-FEC padding before LDPC encoding, and do not describe PSDU length signaling. IEEE 802.11ac amendment also applies pre-FEC padding before LDPC encoding, making PSDU length signaling potentially unnecessary, but includes optional PSDU length signaling. IEEE 802.11n amendment does not apply pre-FEC padding before LDPC encoding, and instead signals the actual PSDU length in the HT-SIG field. In the IEEE 802.11n amendment, instead of pre-FEC padding a transmitter may perform coded bit repetition, which can improve performance.

[0157] As to PPDU length signaling, in the IEEE 802.11a amendment the PPDU length is the same as the PSDU length. In IEEE 802.11n, 802.11ac, 802.11ax, and 802.11be amendments the PPDU length may be signaled using a LENGTH field in a L-SIG.

[0158] FIG.16 highlights a problem that may arise in PSDU length signaling for a PPDU. Specifically, FIG. 16 illustrates a table 1600 describing needed preamble bits, and extra overhead, for PSDU length signaling for a PPDU. The table 1600 includes rows corresponding to various number of users in a PPDU, from 1 to 32, and corresponding needed bits in a preamble to signal PSDU length and extra overhead (e.g., in µs) for the respective number of users.

[0159] As discussed above in relation to FIGS.14-15, in one example a transmitting STA may signal to a receiving STA PSDU length to allow the receiving STA to identify which received bits to decode (e.g., to identify data bits among padding bits). IEEE 802.11a, 802.11n, and 802.11ac amendments each include this PSDU length signaling. While this existing PSDU length signaling may be suitable for older implementations (e.g., a legacy SU environment), explicitly signaling PSDU length in future environments (e.g., a future MU environment) may result in high preamble overhead and complexity, and poor performance.

[0160] In an example, the overhead needed for explicitly signaling PSDU length may increase linearly with the number of STAs for a given PPDU. For example, assume a PSDU length indication requires a maximum of 24 bits and a modulation and coding scheme (MCS) MCS0 is used. As illustrated in table 1600, for SU transmission (e.g., one user for a PPDU), the preamble includes the 24 bits to signal the PSDU length indication. One symbol, requiring an extra 4µs of overhead, is required to carry the extra signaling.

[0161] As to four STA MU transmission, however, 96 bits are required in the preamble (e.g., 24 bits per STA) and two symbols are required, creating an extra 8µs of overhead. For eight STA MU transmission, 192 bits are required in the preamble (e.g., 24 bits per STA) and four symbols are required, creating an extra 16µs of overhead. For 16 STA MU transmission, 384 bits are required in the preamble and eight symbols are required, creating an extra 32µs of overhead. For 32 STA MU transmission, 768 bits are required in the preamble and 15 symbols are required, creating an extra 60µs of overhead.Docket No.: 24-3043PCT

[0162] Thus, while existing techniques for explicit signaling of PSDU length may be suitable for an SU environment, they create significant problems in an MU environment. High preamble overhead and complexity can have a negative effect on performance and efficiency.

[0163] Embodiments of the present disclosure, as further described below, address the above-described problem associated with existing technologies. In an aspect, a first station (STA) transmits to a second STA a first frame indicating a first length of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU) to be transmitted by the first STA to the second STA after the first frame. The first STA receives, from the second STA, a second frame in response to the first frame. The first STA transmits, to the second STA, the PPDU, wherein a second length of pre-forward error correction (FEC) padding bits of the PPDU is based on the first length of the PSDU. As described further below, this facilitates improved PSDU length signaling (e.g., for MU environment). For example, an additional frame may be used to explicitly signal PSDU length, reducing preamble complexity for the PPDU and overhead in PPDU transmissions. As another example, an additional frame may be used to signal granular pre-FEC padding, which may improve pre-FEC padding and implicitly signal PSDU length without requiring explicit length signaling, reducing preamble complexity and overhead in PPDU transmission.

[0164] FIG.17 illustrates an example 1700 of an example operation according to an embodiment. As shown in FIG.17, example 1700 includes an STA 1710 and another STA 1720. STAs 1710 and 1720 may each be an AP STA or a non-AP STA. As illustrated, example 1700 may begin with STA 1710 transmitting a frame 1712 to STA 1720. Frame 1712 may include a PSDU. In an embodiment, frame 1712 is a data frame sent by STA 1710 without a prior ICF-ICR exchange. In an example, a data frame may be sent without a prior ICF-ICR exchange when such an exchange is not required to complete the transmission (e.g., a dynamic subband operation (DSO)requires an ICF-ICR exchange to complete the transmission) or is not desired (e.g., transmit opportunity (TXOP) protection of short data frames). For example, STA 1710 may encode data frame 1712 using pre-FEC padding as described above in relation to FIG.14 (e.g., using techniques described in relation to 802.11ax and 802.11be). In an embodiment, data frame 1712 does not explicitly signal the length of the PSDU. Instead, STA 1720 uses implicit signaling of PSDU length from the pre-FEC padding to identify which received bits to decode (e.g., to identify data bits among padding bits).

[0165] In an embodiment, STA 1710 may then transmit an ICF 1714 (e.g., an ICF as described above in relation to FIGS.10-12) to STA 1720. ICF 1714 indicates a length of a next PSDU (hereinafter, next PSDU length) for a subsequent data transmission (e.g., a PPDU transmission following ICF 1714) from STA 1710 to STA 1720. The subsequent data transmission may include a PPDU that includes the next PSDU. Further, ICF 1714 may indicate to STA 1720 that the subsequent data transmission will not include pre-FEC padding. STA 1720 may use the explicit signaling of the next PSDU length in ICF 1714 to identify which received bits of the subsequent data transmission to decode (e.g., to identify data bits among padding bits). In an embodiment, in addition to using ICF 1714 to signal the next PSDU length, STA 1710 may use ICF 1714 forDocket No.: 24-3043PCT another operation. This is discussed further, above, in relation to FIGS.10-12. For example, STA 1710 may transmit ICF 1714 to STA 1720 for a power save (PS) operation, for DSO, or for TXOP protection (e.g., NAV protection). As another example, STA 1710 may transmit frame 1714 as a coordinated beamforming (Co- BF) Trigger frame or a coordinated spatial reuse (Co-SR) Trigger frame, as discussed further below in relation to FIGS.27-28, and may indicate a length of a subsequent data transmission (e.g., a length of a PPDU for the Co-BF transmission or Co-SR transmission). In an embodiment, frame 1714 may correspond to multi-AP trigger frame 2710 illustrated in FIG.27 or multi-AP trigger frame 2812 illustrated in FIG.28. For example, frame 1714 may correspond to a Co-BF Trigger frame and frame 1716 may correspond to a Co-BF data transmission. Frame 1714 may indicate a length of the Co-BF data transmission (e.g., frame 1714 may indicate a length of a PPDU carrying frame 1716). As another example, frame 1714 may correspond to a Co- SR Trigger frame and frame 1716 may correspond to a Co-SR data transmission. Frame 1714 may indicate a length of the Co-SR data transmission (e.g., frame 1714 may indicate a length of a PPDU carrying frame 1716). In an embodiment, STA 1720 may not transmit ICR 1722 (e.g., as illustrated in FIGS.27-28).

[0166] In an embodiment, when ICF 1714 comprises an MU-RTS frame, the next PSDU length may be indicated in a user info field (e.g., as discussed above in relation to FIG.7). A user info field of a MU-RTS may only have 19 reserved bits, and so, in an embodiment, any remaining bits needed to signal PSDU length (e.g., an additional four bits) may be signaled in a common info field or in another user info field associated to STA 1720.

[0167] In an embodiment, STA 1720 responds with an ICR 1722 acknowledging ICF 1714. In an embodiment, ICR 1722 may either accept, or reject, receiving the subsequent data transmission without pre- FEC padding. For example, assume ICR 1722 accepts receiving a next frame without pre-FEC padding. After receiving ICR 1722 indicating acceptance, STA 1710 transmits a frame 1716 to STA 1720. Frame 1716 may correspond to the subsequent data transmission. In an embodiment, frame 1716 has a PSDU length corresponding to the next PSDU length indicated in ICF 1714. In an embodiment, frame 1716 does not include pre-FEC padding (e.g., based on STA 1710 receiving ICR 1722 indicating acceptance of data transmission without pre-FEC padding). STA 1720 responds by transmitting a BlockAck (BA) 1724 to STA 1710.

[0168] As discussed, in one embodiment, STA 1710 encodes frame 1716 without pre-FEC padding based on receiving ICR 1722 (e.g., receiving an acceptance in ICR 1722). Alternatively, or in addition, STA 1710 encodes frame 1716 without pre-FEC padding based on transmitting ICF 1714. For example, STA 1710 may encode frame 1716 without pre-FEC padding based on transmission of ICF 1714 (e.g., successful transmission of ICF 1714), based on receipt of ICR 1722 (e.g., receipt of an acceptance in ICR 1722), or both. Further, in another example, STA 1710 may transmit frame 1716 with pre-FEC padding, based on transmission of ICF 1714 (e.g., an unsuccessful transmission of ICF 1714), based on receipt of ICR 1722 (e.g., receipt of a rejection in ICRM 1722), or both.Docket No.: 24-3043PCT

[0169] While example 1700 illustrates a default data frame (e.g., frame 1712) using pre-FEC padding, and using an ICF (e.g., ICF 1714) to signal PSDU length and that a subsequent data frame (e.g., frame 1716) does not include pre-FEC padding, this is merely an example. Alternatively, or in addition, all data frames may use explicit PSDU length signaling, with none using pre-FEC padding. As another alternative, or addition, granular pre-FEC padding factor may be explicitly signaled instead of the PSDU length. In this case, pre- FEC padding may be used to implicitly signal PSDU length for all data frames (e.g., granular pre-FEC padding as discussed below in relation to FIGS.19-20). Further, an ICF is merely one example of a frame that can be used to signal PSDU length. As discussed further, below, in relation to FIG.18, any suitable frame may be used.

[0170] FIG.18 illustrates an example 1800 of a further example operation according to an embodiment. As shown in FIG.18, example 1800 includes an STA 1810 and another STA 1820. STAs 1810 and 1820 may each be an AP STA or a non-AP STA. As illustrated, example 1800 may begin with STA 1810 transmitting a frame 1812 to STA 1820. Frame 1812 may include a PSDU. In an embodiment, frame 1812 is a data frame sent by STA 1810 without a prior ICF-ICR exchange. In an example, a data frame may be sent without a prior ICF-ICR exchange when such an exchange is not required to complete the transmission (e.g. DSO requires an ICF-ICR exchange to complete the transmission) or is not desired (e.g. TXOP protection of short data frames). For example, STA 1810 may encode data frame 1812 using pre-FEC padding as described above in relation to FIG.14 (e.g., using techniques described in relation to 802.11ax and 802.11be). In an embodiment data frame 1812 does not explicitly signal the length of the PSDU. Instead, STA 1820 uses implicit signaling of PSDU length from the pre-FEC padding to identify which received bits to decode (e.g., to identify data bits among padding bits).

[0171] In an embodiment, STA 1810 may then transmit a frame 1814 to STA 1820. In an example, frame 1814 is a short frame (e.g., shorter than a threshold value). Frame 1814 indicates the next PSDU length for a subsequent data transmission (e.g., a PPDU transmission following frame 1814) from STA 1810 to STA 1820. The subsequent data transmission may include a PPDU that includes the next PSDU. Further, frame 1814 may indicate to STA 1820 that the subsequent data transmission will not include pre-FEC padding. STA 1820 may use the explicit signaling of the next PSDU length in frame 1814 to identify which received bits of the subsequent data transmission to decode (e.g., to identify data bits among padding bits). In an embodiment, in addition using frame 1814 to signal the next PSDU length, STA 1810 may use frame 1814 for another operation. For example, STA 1810 may transmit a short frame 1814 (e.g., shorter than a threshold value), prior to a longer data frame 1816 (e.g., longer than a threshold value), for collision detection.

[0172] In an embodiment, frame 1814 may be a short frame (e.g., a QoS data frame or a QoS null frame as discussed above in relation to FIG.9) with next PSDU length indicated in an HT control field. For example, a HT control field may use up to 26 bits, which may be used to signal PSDU length. As another example, frame 1814 may be a Co-BF Trigger frame or a Co-SR Trigger frame, as discussed further below in relationDocket No.: 24-3043PCT to FIGS.27-28, and may indicate a length of a subsequent data transmission (e.g., a length of a PPDU for the Co-BF transmission or Co-SR transmission). In an embodiment, frame 1814 may correspond to multi-AP trigger frame 2710 illustrated in FIG.27 or multi-AP trigger frame 2812 illustrated in FIG.28. For example, frame 1814 may correspond to a Co-BF Trigger frame and frame 1816 may correspond to a Co-BF data transmission. Frame 1814 may indicate a length of the Co-BF data transmission (e.g., frame 1814 may indicate a length of a PPDU carrying frame 1816). As another example, frame 1814 may correspond to a Co- SR Trigger frame and frame 1816 may correspond to a Co-SR data transmission. Frame 1714 may indicate a length of the Co-SR data transmission (e.g., frame 1814 may indicate a length of a PPDU carrying frame 1816). In an embodiment, STA 1820 may not transmit BA 1822 (e.g., as illustrated in FIGS.27-28).

[0173] In an embodiment, STA 1820 responds with a BA 1822 acknowledging frame 1814. In an embodiment, BA 1822 may either accept, or reject, receiving the subsequent data transmission without pre- FEC padding. For example, assume BA 1822 accepts receiving a next frame without pre-FEC padding. After receiving BA 1822 indicating acceptance, STA 1810 transmits a frame 1816 to STA 1820. Frame 1816 may correspond to the subsequent data transmission. In an embodiment, frame 1816 has a PSDU length corresponding to the next PSDU length indicated in frame 1814. In an embodiment, frame 1814 does not include pre-FEC padding. STA 1820 responds by transmitting BA 1824 to STA 1810. As discussed, in one embodiment STA 1810 encodes frame 1816 without pre-FEC padding based on receiving BA 1822 (e.g., receiving an acceptance in BA 1822). Alternatively, or in addition, STA 1810 encodes frame 1816 without pre-FEC padding based on transmitting frame 1814. For example, STA 1810 may encode frame 1816 without pre-FEC padding based on transmission of frame 1814 (e.g., successful transmission of frame 1814), based on receipt of BA 1822 (e.g., receipt of an acceptance in BA 1822), or both. Further, in another example, STA 1810 may transmit frame 1816 with pre-FEC padding, based on transmission of frame 1814 (e.g., an unsuccessful transmission of frame 1814), based on receipt of BA 1822 (e.g., receipt of a rejection in BA 1822), or both.

[0174] While example 1800 illustrates a default data frame (e.g., frame 1812) using pre-FEC padding, and using another frame (e.g., a frame 1814) to signal PSDU length and that a subsequent data frame (e.g., frame 1816) does not include pre-FEC padding, this is merely an example. Alternatively, or in addition, all data frames may use explicit PSDU length signaling, with none using pre-FEC padding. As another alternative, or addition, granular pre-FEC padding factor may be explicitly signaled instead of the PSDU length. In this case, pre-FEC padding may be used to implicitly signal PSDU length for all data frames (e.g., improved pre-FEC padding as discussed below in relation to FIGS.19-20). Further, a QoS data frame or a QoS null frame as illustrated in FIG.9 is merely one example of a frame 1814 that can be used to signal PSDU length. Any suitable frame may be used.

[0175] FIG. 19 illustrates an example 1900 of another further example operation according to an embodiment. As shown in FIG.19, example 1900 includes an STA 1910 and another STA 1920. STAs 1910Docket No.: 24-3043PCT and 1920 may each be an AP STA or a non-AP STA. As illustrated, example 1900 may begin with STA 1910 transmitting a frame 1912 to STA 1920. Frame 1912 may include a PSDU. In an embodiment, frame 1912 is a data frame sent by STA 1910 without a prior ICF-ICR exchange. In an example, a data frame may be sent without a prior ICF-ICR exchange when it is not required to complete the transmission (e.g. DSO requires an ICF-ICR to complete the transmission) or is not desired (e.g. TXOP protection of short data frames). For example, STA 1910 may encode data frame 1912 using pre-FEC padding as described above in relation to FIG.14 (e.g., using techniques described in relation to 802.11ax and 802.11be). In an embodiment data frame 1912 does not explicitly signal the length of the PSDU. Instead, STA 1920 uses implicit signaling of PSDU length from the pre-FEC padding to identify which received bits to decode (e.g., to identify data bits among padding bits).

[0176] STA 1910 may then transmit an ICF 1914 (e.g., an ICF as described above in relation to FIGS.10- 12) to STA 1920. In an embodiment, ICF 1914 includes a next padding boundary indicator for a subsequent data transmission (e.g., a PPDU transmission following ICF 1914) from STA 1910 to STA 1920. The subsequent data transmission may include a PPDU that includes the next PSDU. As discussed above in relation to FIG.14, in one example pre-FEC padding includes four padding boundaries in all circumstances. Alternatively, or in addition, STA 1910 may use N padding boundaries and may indicate the number of padding boundaries using ICF 1914. For example, instead of four padding boundaries as illustrated in FIG. 14, STA 1910 may use eight padding boundaries, 16 padding boundaries, 32 padding boundaries, or any other suitable number of padding boundaries. ICF 1914 may indicate the number of padding boundaries used. Indicating the number of padding boundaries is merely one example, and ICF 1914 may signal a next padding boundary indicator using any suitable technique (e.g., identifying a padding boundary using any suitable indication). In an embodiment, in addition to using ICF 1914 to signal the next padding boundary indicator, STA 1910 may use ICF 1914 for another operation. This is discussed further, above, in relation to FIGS.10-12. For example, STA 1910 may transmit ICF 1914 to STA 1920 for a power save (PS) operation, for a dynamic subband operation (DSO), or for transmit opportunity (TXOP) protection (e.g., NAV protection).

[0177] In an embodiment, when ICF 1914 comprises an MU-RTS frame, the next padding boundary indicator may be indicated in a user info field (e.g., as discussed above in relation to FIG.7). A user info field of a MU-RTS may have 19 reserved bits, and so, in an embodiment, up to 19 bits in the user info field of the MU-RTS may be used to indicate a number of padding boundaries. Should additional bits be needed, any remaining bits may be signaled in a common info field or in another user info field associated to STA 1920.

[0178] In an embodiment, STA 1920 responds with an ICR 1922 acknowledging ICF 1914. In an embodiment, ICR 1922 may either accept, or reject, receiving the subsequent data transmission with a number of pre-FEC padding boundaries indicated in ICF 1914. For example, assume ICR 1922 accepts receiving a next frame with a number of pre-FEC padding boundaries indicated in ICF 1914. After receiving ICR 1922, STA 1910 transmits a frame 1916 to STA 1920. Frame 1916 may correspond to the subsequentDocket No.: 24-3043PCT data transmission. In an embodiment, frame 1916 is encoded using the pre-FEC boundaries indicated by ICF 1914. STA 1920 responds by transmitting a BA 1924 to STA 1910.

[0179] While example 1900 illustrates a data frame (e.g., frame 1912) using set boundaries for pre-FEC padding (e.g., four boundary pre-FEC padding) and using an ICF (e.g., ICF 1914) to signal a next padding boundary indicator, this is merely an example. Alternatively, or in addition, all data frames may use a padding boundary indicator for pre-FEC padding with none using set boundaries. Further, an ICF is merely one example of a frame that can be used to signal a padding boundary indicator. Any suitable frame may be used. Additionally, in one example a next padding boundary indicator may indicate the number of padding boundaries for a next data frame. This is also merely an example, and a padding boundary indicator (e.g., included in ICF 1914) may indicate padding boundaries for all subsequent data frames, or any suitable subset of subsequent data frames (e.g., a given number of subsequent data frames, data frames transmitted over a given time period, or any other suitable subset of subsequent data frames).

[0180] FIG.20 illustrates an example 2000 of an additional further example operation. As shown in FIG.20, example 2000 includes an STA 2010 and another STA 2020. STAs 2010 and 2020 may each be an AP STA or a non-AP STA. As illustrated, example 2000 may begin with STA 2010 transmitting a frame 2012 to STA 2020. Frame 2012 may include a PSDU. In an embodiment, frame 2012 is a data frame sent by STA 2010 without a prior ICF-ICR exchange. In an example, a data frame may be sent without a prior ICF-ICR exchange when it is not required to complete the transmission (e.g. DSO requires an ICF-ICR exchange to complete the transmission) or is not desired (e.g. TXOP protection of short data frames). For example, STA 2010 may encode data frame 2012 using pre-FEC padding as described above in relation to FIG. 14 (e.g., using techniques described in relation to 802.11ax and 802.11be). In an embodiment data frame 2012 does not explicitly signal the length of the PSDU. Instead, STA 2020 uses implicit signaling of PSDU length from the pre-FEC padding to identify which received bits to decode (e.g., to identify data bits among padding bits).

[0181] STA 2010 may then transmit a frame 2014 to STA 2020. In an example, frame 2014 is a short frame (e.g., shorter than a threshold value). In an embodiment, frame 2014 includes a next padding boundary indicator for a subsequent data transmission (e.g., a PPDU transmission following frame 2014) from STA 2010 to STA 2020. The subsequent data transmission may include a PPDU that includes the next PSDU. As discussed above in relation to FIG.14, in one example pre-FEC padding includes four padding boundaries in all circumstances. Alternatively, or in addition, STA 2010 may use N padding boundaries and may indicate the number of padding boundaries using frame 2014. For example, instead of four padding boundaries as illustrated in FIG.14, STA 2010 may use eight padding boundaries, 16 padding boundaries, 32 padding boundaries, or any other suitable number of padding boundaries. The frame 2014 may indicate the number of padding boundaries used. Indicating the number of padding boundaries is merely one example, and the frame 2014 may signal a next padding boundary indicator using any suitable technique (e.g., identifying a padding boundary using any suitable indication). In an embodiment, in addition to using frame 2014 to signalDocket No.: 24-3043PCT a next padding boundary indicator), STA 2010 may use frame 2014 for another operation. For example, STA 2010 may transmit a short frame 2014 (e.g., shorter than a threshold value), prior to a longer data frame 2016 (e.g., longer than a threshold value), for collision detection.

[0182] In an embodiment, frame 1814 may be a short frame (e.g., a QoS data frame or a QoS null frame as discussed above in relation to FIG.9) and the next padding boundary indicator may be indicated in a HT control field. For example, a HT control field may use up to 26 bits, which may be used to signal a next padding boundary indicator.

[0183] In an embodiment, STA 2020 responds with a BA 2022 acknowledging frame 2014. In an embodiment, BA 2022 may either accept, or reject, receiving the subsequent data transmission with a number of pre-FEC padding boundaries indicated in frame 2014. For example, assume BA 2022 accepts receiving a next frame with a number of pre-FEC padding boundaries indicated in frame 2014. After receiving BA 2022 indicating acceptance, STA 2010 transmits a frame 2016 to STA 2020. Frame 2016 may correspond to the subsequent data transmission. In an embodiment, frame 2016 is encoded using the pre-FEC boundaries indicated by frame 2014. STA 2020 responds by transmitting a BA 2024 to STA 2010.

[0184] While example 2000 illustrates a data frame (e.g., frame 2012) using set boundaries for pre-FEC padding (e.g., four boundary pre-FEC padding) and using a short frame (e.g., frame 2014) to signal a next padding boundary indicator, this is merely an example. Alternatively, or in addition, all data frames may use a padding boundary indicator for pre-FEC padding with none using set boundaries. Further, a QoS data frame or a QoS null frame as illustrated in FIG.9 is merely one example of a frame 1814 that can be used to signal a padding boundary indicator. Any suitable frame may be used. Additionally, in one example a next padding boundary indicator may indicate the number of padding boundaries for a next data frame. This is also merely an example, and a padding boundary indicator (e.g., included in frame 2014) may indicate padding boundaries for all subsequent data frames, or any suitable subset of subsequent data frames (e.g., a given number of subsequent data frames, data frames transmitted over a given time period, or any other suitable subset of subsequent data frames).

[0185] As would be understood by a person of skill in the art based on the teachings herein, the embodiments as described by the above examples may be readily extended to implementations including more than one STA.

[0186] As would be understood by a person of skill in the art based on the teachings herein, the embodiments as described by the above examples may be readily extended to implementations including more than one AP.

[0187] As would be understood by a person of skill in the art based on the teachings herein, the embodiments as described by the above examples may be readily extended to scenarios in which any of the APs or any of the STAs may comprise a MLD, comprising at least one affiliated AP or affiliated STA.Docket No.: 24-3043PCT

[0188] FIG.21 illustrates an example process 2100 according to an embodiment of the present disclosure. Example process 2100 may be performed by a suitable STA, such as STA 1710 illustrated in FIG.17, STA 1810 illustrated in FIG.18, STA 1910 illustrated in FIG.19, or STA 2010 illustrated in FIG.20. As shown in FIG.21, process 2100 may include steps 2102 and 2104.

[0189] Step 2102 includes transmitting, by a first station (STA) to a second STA, a first frame including an indication of a first length of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU). In an embodiment the first STA includes any suitable STA, including STA 1710 illustrated in FIG. 17, STA 1810 illustrated in FIG.18, STA 1910 illustrated in FIG.19, or STA 2010 illustrated in FIG.20. Further, in an embodiment, the second STA includes any other suitable STA, including STA 1720 illustrated in FIG.17, STA 1820 illustrated in FIG.18, STA 1920 illustrated in FIG.19, or STA 2020 illustrated in FIG. 20.

[0190] Step 2104 includes transmitting, by the first STA to the second STA, the PPDU after transmitting the first frame.

[0191] In an embodiment, the first frame comprises an initial control frame (ICF).

[0192] In an embodiment, the ICF initiates a power save (PS) operation, dynamic subband operation (DSO), or a transmit opportunity (TXOP) protection.

[0193] In an embodiment, the indication of the first length is provided in a user info field of the first frame.

[0194] In an embodiment, the indication of the first length is provided in a common info field of the first frame.

[0195] In an embodiment, the first frame comprises a quality of service (QoS) data frame or a QoS Null frame.

[0196] In an embodiment, the indication of the first length is provided in a high throughput (HT) control field of the first frame.

[0197] In an embodiment, transmitting the PPDU comprises encoding the PSDU using a low density parity check (LDPC) code.

[0198] In an embodiment, the process 2100 further includes receiving, by the first STA from the second STA, a second frame in response to the first frame.

[0199] In an embodiment, transmitting the PPDU comprises encoding the PSDU of the PPDU without pre- forward error correction (pre-FEC) padding.

[0200] In an embodiment, encoding the PSDU of the PPDU without pre-FEC padding is based on the first frame comprising the indication of the first length.

[0201] In an embodiment, encoding the PSDU of the PPDU without pre-FEC padding is based on receiving the second frame.

[0202] In an embodiment, the second frame indicates acceptance of encoding without pre-FEC padding.Docket No.: 24-3043PCT

[0203] In an embodiment, encoding the PSDU of the PPDU without pre-FEC padding comprises repeating of one or more coded bits of the PSDU.

[0204] In an embodiment, transmitting the PPDU comprises encoding the PSDU of the PPDU with pre-FEC padding.

[0205] In an embodiment, encoding the PSDU of the PPDU with pre-FEC padding is based on the transmitting of the first frame comprising the indication of the first length.

[0206] In an embodiment, encoding the PSDU of the PPDU with pre-FEC padding is based on receiving the second frame.

[0207] In an embodiment, the second frame indicates rejection of encoding without pre-FEC padding.

[0208] In an embodiment, the first length comprises a length of a medium access layer protocol data unit (MPDU) or an aggregate MPDU (A-MPDU) carried in the PSDU.

[0209] In an embodiment, process 2100 further comprises issuing, by a medium access control (MAC) layer of the first STA, a physical layer (PHY)-transmit start request (TXSTART) primitive to a PHY layer of the first STA to transmit the PSDU.

[0210] In an embodiment, the PHY-TXSTART request primitive comprises the first length.

[0211] In an embodiment, process 2100 further comprises encoding the PSDU using a first number of bits comprising a second length of the PSDU.

[0212] In an embodiment, the second length comprises the first length multiplied by 8 plus 16.

[0213] In an embodiment, encoding the PSDU using the first number of bits comprising the second length of the PSDU is based on transmitting the first frame comprising the indication of the first length

[0214] In an embodiment, encoding the PSDU using the first number of bits comprising the second length of the PSDU is based on receiving a response to the first frame.

[0215] In an embodiment, the PSDU comprises a medium access layer protocol data unit (MPDU) or an aggregate medium access layer protocol data unit (A-MPDU).

[0216] In an embodiment, the first length of the PSDU comprises a length of an aggregate medium access layer protocol data unit (A-MPDU) pre-end of frame (EOF) padding (APEP) carried in the PSDU.

[0217] In an embodiment, the PPDU is an ultra high reliability (UHR) PPDU.

[0218] In an embodiment, transmitting the PPDU comprises encoding the PSDU of the PPDU with pre-FEC padding using up to N padding boundaries.

[0219] In an embodiment, the first length comprises an indication relating to the N padding boundaries.

[0220] In an embodiment, N is greater than 4

[0221] FIG.22 illustrates an example process 2200 according to an embodiment of the present disclosure. Example process 2200 may be performed by a suitable STA, such as STA 1710 illustrated in FIG.17, STA 1810 illustrated in FIG.18, STA 1910 illustrated in FIG.19, or STA 2010 illustrated in FIG.20. As shown in FIG.22, process 2200 may include steps 2202 and 2204.Docket No.: 24-3043PCT

[0222] Step 2202 includes transmitting, by a first station (STA) to a second STA, a first frame including an indication of a first padding boundary of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU). In an embodiment the first STA includes any suitable STA, including STA 1710 illustrated in FIG.17, STA 1810 illustrated in FIG.18, STA 1910 illustrated in FIG.19, or STA 2010 illustrated in FIG. 20. Further, in an embodiment, the second STA includes any other suitable STA, including STA 1720 illustrated in FIG.17, STA 1820 illustrated in FIG.18, STA 1920 illustrated in FIG.19, or STA 2020 illustrated in FIG.20.

[0223] Step 2204 includes transmitting, by the first STA to the second STA, the PPDU after transmitting the first frame.

[0224] In an embodiment, the first padding boundary comprises 1 up to N padding boundaries of a last orthogonal frequency division multiplexing (OFDM) symbol of the PPDU.

[0225] In an embodiment, N is greater than 4.

[0226] In an embodiment, N being greater than 4 is based on the transmitting of the first frame comprising the indication of the first padding boundary.

[0227] In an embodiment, the process 2200 further includes receiving a response to the first frame, wherein N being greater than 4 is based on the receiving of the response of the first frame.

[0228] In an embodiment, the first frame comprises an initial control frame (ICF).

[0229] In an embodiment, the first frame comprises a quality of service (QoS) data frame or a QoS Null frame.

[0230] FIG.23 illustrates an example process 2300 according to an embodiment of the present disclosure. Example process 2300 may be performed by a suitable STA, such as STA 1720 illustrated in FIG.17, STA 1820 illustrated in FIG.18, STA 1920 illustrated in FIG.19, or STA 2020 illustrated in FIG.20. As shown in FIG.23, process 2300 may include steps 2302 and 2304.

[0231] Step 2302 includes receiving, by a first station (STA) from a second STA, a first frame comprising an indication of a first length of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU). In an embodiment the first STA includes any suitable STA, including STA 1720 illustrated in FIG.17, STA 1820 illustrated in FIG.18, STA 1920 illustrated in FIG.19, or STA 2020 illustrated in FIG.20. Further, in an embodiment, the second STA includes any other suitable STA, including STA 1710 illustrated in FIG.17, STA 1810 illustrated in FIG.18, STA 1910 illustrated in FIG.19, or STA 2010 illustrated in FIG. 20.

[0232] Step 2304 includes receiving, by the first STA from the second STA, the PPDU after receiving the first frame.

[0233] In an embodiment, the first frame comprises an initial control frame (ICF).

[0234] In an embodiment, the ICF initiates a power save (PS) operation, dynamic subband operation (DSO), or a transmit opportunity (TXOP) protection.Docket No.: 24-3043PCT

[0235] In an embodiment, the indication of the first length is provided in a user info field of the first frame.

[0236] In an embodiment, the indication of the first length is provided in a common info field of the first frame.

[0237] In an embodiment, the first frame comprises a quality of service (QoS) data frame or a QoS Null frame.

[0238] In an embodiment, the indication of the first length is provided in a high throughput (HT) control field of the first frame.

[0239] In an embodiment, the PSDU of the PPDU is encoded using a low density parity check (LDPC) code.

[0240] In an embodiment, the process 2300 further includes transmitting, by the first STA to the second STA, a second frame in response to the first frame.

[0241] In an embodiment, the PSDU of the PPDU is encoded without pre-forward error correction (pre-FEC) padding.

[0242] In an embodiment, encoding the PSDU of the PPDU without pre-FEC padding is based on the first frame comprising the indication of the first length.

[0243] In an embodiment, encoding the PSDU of the PPDU without pre-FEC padding is based on the second STA receiving the second frame.

[0244] In an embodiment, the second frame indicates acceptance of encoding without pre-FEC padding.

[0245] In an embodiment, encoding the PSDU of the PPDU without pre-FEC padding comprises repeating of one or more coded bits of the PSDU.

[0246] In an embodiment, the PSDU of the PPDU is encoded with pre-FEC padding.

[0247] In an embodiment, encoding the PSDU of the PPDU with pre-FEC padding is based on transmission by the second STA of the first frame comprising the indication of the first length.

[0248] In an embodiment, encoding the PSDU of the PPDU with pre-FEC padding is based on the second STA receiving the second frame.

[0249] In an embodiment, the second frame indicates rejection of encoding without pre-FEC padding.

[0250] In an embodiment, the first length comprises a length of a medium access layer protocol data unit (MPDU) or an aggregate MPDU (A-MPDU) carried in the PSDU.

[0251] In an embodiment, process 2300 further comprises issuing, by a medium access control (MAC) layer of the second STA, a physical layer (PHY)-transmit start request (TXSTART) primitive to a PHY layer of the second STA to transmit the PSDU.

[0252] In an embodiment, the PHY-TXSTART request primitive comprises the first length.

[0253] In an embodiment, the PSDU is encoded using a first number of bits that comprises a second length of the PSDU.

[0254] In an embodiment, the second length comprises the first length multiplied by 8 plus 16.Docket No.: 24-3043PCT

[0255] In an embodiment, encoding the PSDU using the first number of bits comprising the second length of the PSDU is based on the second STA transmitting the first frame comprising the indication of the first length.

[0256] In an embodiment, encoding the PSDU using the first number of bits comprising the second length of the PSDU is based on the second STA receiving a response to the first frame.

[0257] In an embodiment, the PSDU comprises a medium access layer protocol data unit (MPDU) or an aggregate medium access layer protocol data unit (A-MPDU).

[0258] In an embodiment, the first length of the PSDU comprises a length of an aggregate medium access layer protocol data unit (A-MPDU) pre-end of frame (EOF) padding (APEP) carried in the PSDU.

[0259] In an embodiment, the PPDU is an ultra high reliability (UHR) PPDU.

[0260] In an embodiment, the PSDU of the PPDU is encoded with pre-FEC padding using up to N padding boundaries.

[0261] In an embodiment, the first length comprises an indication relating to the N padding boundaries.

[0262] In an embodiment, N is greater than 4

[0263] FIG.24 illustrates an example process 2400 according to an embodiment of the present disclosure. Example process 2400 may be performed by a suitable STA, such as STA 1720 illustrated in FIG.17, STA 1820 illustrated in FIG.18, STA 1920 illustrated in FIG.19, or STA 2020 illustrated in FIG.20. As shown in FIG.24, process 2400 may include steps 2402 and 2404.

[0264] Step 2402 includes receiving, by a first station (STA) from a second STA, a first frame comprising an indication of a first padding boundary of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU). In an embodiment the first STA includes any suitable STA, including STA 1720 illustrated in FIG.17, STA 1820 illustrated in FIG.18, STA 1920 illustrated in FIG.19, or STA 2020 illustrated in FIG.20. Further, in an embodiment, the second STA includes any other suitable STA, including STA 1710 illustrated in FIG.17, STA 1810 illustrated in FIG.18, STA 1910 illustrated in FIG.19, or STA 2010 illustrated in FIG.20.

[0265] Step 2404 includes receiving, by the first STA from the second STA, the PPDU after receiving the first frame.

[0266] In an embodiment, the first padding boundary comprises 1 up to N padding boundaries of a last orthogonal frequency division multiplexing (OFDM) symbol of the PPDU.

[0267] In an embodiment, N is greater than 4.

[0268] In an embodiment, N being greater than 4 is based on the second STA transmitting the first frame comprising the indication of the first padding boundary.

[0269] In an embodiment, the process 2400 further includes transmitting, from the first STA to the second STA, a response to the first frame, wherein N being greater than 4 is based on the second STA receiving the response to the first frame.Docket No.: 24-3043PCT

[0270] In an embodiment, the first frame comprises an initial control frame (ICF).

[0271] In an embodiment, the first frame comprises a quality of service (QoS) data frame or a QoS Null frame.

[0272] FIG.25 illustrates an example 2500 of a multi-AP operation procedure. In example 2500, the multi- AP operation procedure is illustrated with respect to a multi-AP network that includes APs 2502 and 2504 and STAs 2506 and 2508. In an example, APs 2502 and 2504 may form a multi-AP group. AP 2502 may be the master AP and AP 2504 may be a slave AP of the multi-AP group. For example, AP 2502 may obtain a TXOP making it the master AP of the multi-AP group. Alternatively, AP 2502 may be designated as the master AP by a multi-AP controller.

[0273] As shown in FIG.25, the multi-AP operation procedure may include a series of phases in time, each of which may contain a plurality of frame exchanges within the multi-AP network. Specifically, the multi-AP operation procedure may include a multi-AP selection phase 2510, a multi-AP data sharing phase 2512, a multi-AP sounding phase 2514, and a multi-AP data transmission phase 2516.

[0274] A multi-AP network may carry out a multi-AP operation based on a specific multi-AP transmission scheme. The multi-AP transmission scheme may be chosen by the master AP based on the capabilities of the slave APs in a multi-AP group. Prior to a multi-AP operation, a slave AP may inform the master AP of capability information related to the slave AP, including the capabilities of supporting one or more multi-AP transmission schemes. The slave AP may also inform the master AP of BSS information of the BSS of the slave AP and of link quality information for STAs associated with the slave AP. The master AP may receive information related to all available slave APs. The information related to slave APs may include capability information, BSS information, and link quality information. Based on the information provided by available slave APs, the master AP may determine during a multi-AP selection phase the slave APs to be designated for a multi-AP transmission and a specific multi-AP transmission scheme to be used during the multi-AP transmission.

[0275] Multi-AP selection phase 2510 may include procedures for soliciting, selecting, or designating slave AP(s) for a multi-AP group by a master AP. As seen in FIG.25, the multi-AP selection phase may include transmissions of frame 2518 from AP 2502 and frame 2520 from AP 2504. AP 2502 may transmit frame 2518 to solicit information regarding the buffer status of AP 2504. In response, AP 2504 may transmit frame 2520 to inform AP 2502 of its and its associated STAs buffer status and / or whether it intends to join multi-AP operation. Multi-AP selection phase 2510 may also be used to exchange information related to multi-AP operation, including BSS information of APs and link quality information between each AP and its associated STAs, for example. The BSS information of an AP may include a BSS ID of the BSS of the AP, identifiers and / or capabilities of STAs belonging to the BSS, information regarding sounding capabilities of the STAs, information regarding MIMO capabilities of the AP, etc. Link quality information may include received signalDocket No.: 24-3043PCT strength indicator (RSSI), signal-to-noise ratio (SNR), signal-to-interference-plus-noise-ratio (SINR), channel state information (CSI), channel quality indicator (CQI).

[0276] Multi-AP data sharing phase 2512 may include procedures for sharing data frames to be transmitted by APs to associated STAs among the master AP and selected slave AP(s) via direct connections between APs. Phase 2512 may be optional for some multi-AP data transmission schemes. For example, phase 2512 may be required for JT / JR as data frames may be exchanged between APs before or after multi-AP data transmission phase 2516.

[0277] Multi-AP data sharing phase 2512 may be performed using a wired backhaul, an in-channel wireless backhaul, or an off-channel wireless backhaul. In some cases, multi-AP data sharing phase 2512 may be performed over an in-channel backhaul, e.g., using the same wireless channel used to transmit / receive data to / from STAs. For example, as shown in FIG.25, in phase 2512, AP 2502 may transmit a frame 2522, which may be received by AP 2504. Frame 2522 may include MPDUs that AP 2502 wishes to transmit to associated STAs using a multi-AP operation. Similarly, AP 2504 may transmit a frame 2524, which may be received by AP 2502. Frame 2524 may include MPDUs that AP 2504 wishes to transmit to associated STAs using a multi-AP operation.

[0278] Multi-AP sounding phase 2514 may include procedures for multi-AP channel sounding, including channel estimation and feedback of channel estimates among the master AP, candidate slave AP(s), and associated STAs. Phase 2514 may be optional for some multi-AP transmission schemes, such as COFDMA, CDTMA, and CSR. For example, phase 2514 may be performed by the master AP to aid in resource unit allocation when orchestrating a COFDMA transmission.

[0279] Multi-AP data transmission phase 2516 may include exchange of data frames between the master AP, slave AP(s), and their associated STAs based on multi-AP transmission scheme(s) determined by the master AP. Depending on the multi-AP transmission scheme(s) to be used, phase 2516 may include optional synchronization between APs of the multi-AP group, before exchange of data frames between APs and STAs within the multi-AP group.

[0280] The order of phases 2510, 2512, 2514 and 2516 may be different than shown in FIG.25. For example, in COFDMA, phase 2516 may occur immediately after phase 2510, whereas, in JT / JR, phase 2512 may occur after phase 2510. Further, as mentioned above, some phases may be optional and may or may not be present. For example, phase 2514 may not be required for COFDMA but may be required for JT / JR.

[0281] FIG.26 illustrates an example multi-AP sounding phase 2600. Example multi-AP sounding phase 2600 may be an example of multi-AP sounding phase 2514. As shown in FIG.26, example multi-AP sounding phase 2600 may include a master AP 2602 and a slave AP 2604 of a multi-AP group. Example multi-AP sounding phase 2600 may further include a STA 2606 associated with AP 2602 and a STA 2608 associated with AP 2604.Docket No.: 24-3043PCT

[0282] As shown in FIG.26, multi-AP sounding phase 2600 may include frame exchanges to allow AP 2602 (the master AP) to acquire channel state information (CSI) of channels in the multi-AP group. In an implementation, phase 2600 may include a first subphase 2610 and a second subphase 2612.

[0283] During the first subphase 2610, APs may initiate channel sounding and STAs may estimate channel state information (CSI). For example, AP 2602 may transmit a frame 2614 to AP 2604 (the slave AP) to trigger multi-AP sounding. Frame 2614 may comprise a multi-AP trigger frame. Subsequently, APs 2602 and 2604 may transmit respectively announcement frames 2616-1 and 2616-2 to their respective associated STAs 2606 and 2608 to announce the transmission of sounding frames. Frames 2616-1 and 2616-2 may comprise multi-AP null data packet announcement (NDPA) frames. Frames 2616-1 and 2616-2 may be transmitted simultaneously. Next, APs 2602 and 2604 may transmit respectively frames 2618-1 and 2618-2 to STAs 2606 and 2608 respectively. Frames 2618-1 and 2618-2 may comprise multi-AP null data packet (NDP) frames. STAs 2606 and 2608 receive frames 2618-1 and 2618-2 respectively and perform channel estimation of the channels from AP 2602 to STA 2606 and from AP 2604 to STA 2608, respectively.

[0284] During the second subphase 2612, APs may initiate a procedure for STAs to feed back channel estimates to the APs. For example, AP 2602 may transmit a frame 2620 to trigger STAs 2606 and 2608 to transmit their channel estimates to APs 2602 and 2604 respectively. Frame 2620 may comprise a multi-AP trigger frame. In response, STAs 2606 and 2608 may transmit respectively frames 2622 and 2624 including feedback of channel estimates to APs 2602 and 2604 respectively. Frames 2622 and 2624 may comprise NDP feedback frames. The feedback of channel estimates may include NDP feedback, CSI-related information, a beamforming report (BFR), or a channel quality indication (CQI) report.

[0285] FIG.27 illustrates an example multi-AP downlink data transmission phase 2700. Example multi-AP downlink data transmission phase 2700 may be an example of multi-AP data transmission phase 2516. As shown in FIG.8, example multi-AP downlink data transmission phase 2700 may include a master AP 2702 and a slave AP 2704 of a multi-AP group. Example multi-AP downlink data transmission phase 2700 may further include a STA 2706 associated with AP 2702, and a STA 2708 associated with AP 2704.

[0286] As shown in FIG.27, multi-AP downlink data transmission phase 2700 may include frame exchanges to enable master AP 2702 to coordinate with slave AP 2704 to perform specific multi-AP transmission schemes with their associated STAs 2706 and 2708 respectively. The multi-AP transmission schemes may include COFDMA, CTDMA, CSR, CBF, JT / JR, or a combination of two or more of the aforementioned schemes.

[0287] As shown in FIG.27, master AP 2702 may begin phase 2700 by transmitting a frame 2710 to AP 2704. Frame 2710 may include information related to AP 2704 (e.g., an identifier of AP 2704), synchronization information, information related to a specific multi-AP transmission scheme to be used, and / or information related to a resource unit (RU) for use by AP 2704 to acknowledge frame 2710. Frame 2710 may comprise a control frame. For example, frame 2710 may comprise a multi-AP trigger frame.Docket No.: 24-3043PCT

[0288] In an example, frame 2710 may be a Co-BF Trigger frame. A Co-BF Trigger frame may be used to ensure time and frequency synchronization between two data PPDUs (e.g., PPDUs carrying data frames 2712 and 2714, discussed below) and to convey the information needed to construct a common preamble for the two data PPDUs. The Co-BF Trigger frame may indicate the length of the data PPDUs (e.g., the PPDUs carrying data frames 2712 and 2714, discussed below). For example, the Co-BF Trigger frame may include a value to be set in the length field in the L-SIG field of the PPDU(s) of the Co-BF transmission. The Co-BF Trigger frame may also include the PHY version of the Co-BF transmission, the bandwidth of the Co- BF transmission, and the puncturing pattern of the Co-BF transmission.

[0289] The Co-BF Trigger frame may include the BSS color of the Co-BF coordinating AP (e.g., AP 2702) and the BSS color of the Co-BF coordinated AP (e.g., AP 2704). The Co-BF Trigger frame may include the TXOP duration to be set in the TXOP field in the U-SIG of the Co-BF transmission and the number of UHR- SIG symbols of the Co-BF transmission. The Co-BF Trigger frame may further include the GI and the LTF size of the Co-BF transmission and the number of UHR-LTF symbols of the Co-BF transmission.

[0290] The Co-BF Trigger frame may include the total number of recipient STAs of the Co-BF transmission (e.g., two), the STA ID of each recipient STA (e.g., STA 2706 and STA 2708) of the Co-BF transmission, and an indication of which BSS each recipient STA of the Co-BF transmission belongs to, where the BSS is identified by the BSS color. The Co-BF Trigger frame may also include the MCS of each recipient STA of the Co-BF transmission, the spatial configuration of each recipient STA of the Co-BF transmission, and whether 2xLDPC will be used for each recipient STA of the Co-BF transmission.

[0291] In another example, frame 2710 may be a Co-SR Trigger frame. The Co-SR Trigger frame may indicate the length of the data PPDUs (e.g., the PPDUs carrying data frames 2712 and 2714, discussed below). For example, a Co-SR Trigger frame may include the duration of the data PPDU transmitted by the Co-SR coordinating AP (e.g., the PPDU carrying data frame 2712 transmitted by AP 2702) and the duration of the data PPDU transmitted by the Co-SR coordinated AP (e.g., the PPDU carrying data frame 2714 transmitted by AP 2704), with both durations being the same. The Co-SR Trigger frame may include the transmit power limit of the Co-SR coordinated AP, where the value of the transmit power limit may not be lower than the value indicated by the Co-SR coordinated AP in a MAPC negotiation request frame or MAPC negotiation response frame during a MAPC agreement establishment procedure as defined in the Co-SR negotiation process. The Co-SR Trigger frame may also include the transmit power of the Co-SR coordinating AP. The Co-SR Trigger frame may further include the PHY version of the data PPDU transmitted by the Co- SR coordinating AP and the PHY version of the data PPDU transmitted by the Co-SR coordinated AP.

[0292] Slave AP 2704 may receive frame 2710 and may use the synchronization information to synchronize with master AP 2702. Subsequently, APs 2702 and 2704 may perform data transmission to their associated STAs 2706 and 2708 respectively. Specifically, AP 2702 may transmit a data frame 2712 to its associated STA 2706, and AP 2704 may transmit a data frame 2714 to its associated STA 2708. Depending on theDocket No.: 24-3043PCT multi-AP transmission scheme being used, APs 2702 and 2704 may transmit frames 2712 and 2714 respectively to STAs in different BSSs. For example, when the multi-AP transmission scheme is JT / JR, AP 2702 may also transmit frame 2712 to STA 2708 associated with slave AP 2704, and AP 2704 may also transmit frame 2714 to STA 2708 associated with AP 2704. The resources for transmitting and receiving frames 2712 and 2714 may depend on the specific multi-AP transmission scheme adopted.

[0293] STAs 2706 and 2708 may acknowledge frames 2712 and 2714 respectively. For example, STA 2706 may transmit a frame 2716 to AP 2702, and STA 2708 may transmit a frame 2718 to AP 2704. Frames 2716 and 2718 may comprise block ack (BA) frames. STAs 2706 and 2708 may also transmit frames 2716 and 2718 to APs in different BSSs, when required by the used multi-AP transmission scheme. For example, when the multi-AP transmission scheme is JT / JR, STA 2706 may also transmit frame 2716 to AP 2704, and STA 2708 may also transmit frame 2718 to AP 2702. The resources for transmitting and receiving frames 2716 and 2718 may depend on the specific multi-AP transmission scheme adopted.

[0294] FIG.28 illustrates an example multi-AP uplink data transmission phase 2800. Example multi-AP uplink data transmission phase 2800 may be an example of multi-AP data transmission phase 2516. As shown in FIG.28, example multi-AP uplink data transmission phase 2800 may include a master AP 2802 and a slave AP 2804 of a multi-AP group. Example multi-AP uplink data transmission phase 2800 may further include STAs 2806 and 2808 associated with AP 2802, and a STA 2810 associated with AP 2804.

[0295] As shown in FIG.28, example multi-AP uplink data transmission phase 2800 may include frame exchanges to enable master AP 2802 to coordinate with slave AP 2804 to perform specific multi-AP transmission schemes with STAs 2806, 2808, and 28101810. The multi-AP transmission schemes may include COFDMA, CTDMA, CSR, CBF, JT / JR, or a combination of two or more of the aforementioned schemes.

[0296] As shown in FIG.28, master AP 2802 may begin phase 2800 by transmitting a frame 2812 to AP 2804. Frame 2812 may include information related to AP 2804 (e.g., an identifier of AP 2804), synchronization information, information related to a specific multi-AP transmission scheme to be used, and / or information related to an RU for use by AP 2804 to acknowledge frame 2812. Frame 2812 may comprise a control frame. For example, frame 2812 may comprise a multi-AP trigger frame.

[0297] In an example, like frame 2710 described above in relation to FIG.27, frame 2812 may be a Co-BF Trigger frame, and may indicate the length of the data PPDUs (e.g., the PPDUs carrying data frames 2818, 2820, and 2822), along with other values described above. In another example, again like frame 2710 described above in relation to FIG.27, frame 2812 may be a Co-SR Trigger frame and may indicate the length of the data PPDUs (e.g., the PPDUs carrying data frames 2818, 2820, and 2822) along with other values described above.

[0298] Slave AP 2804 may receive frame 2812 and may use the synchronization information to synchronize with master AP 2802. Subsequently, APs 2802 and 2804 may solicit uplink data transmissions from theirDocket No.: 24-3043PCT associated STAs 2806, 2808 and 2810 using trigger frames. Specifically, AP 2802 may transmit a trigger frame 2814 to its associated STAs 2806 and 2808, and AP 2804 may transmit a trigger frame 2816 to its associated STA 2810. Depending on the multi-AP transmission scheme being used, APs 2802 and 2804 may also transmit frames 2814 and 2816 respectively to STAs in different BSSs. For example, when the multi-AP transmission scheme is JT / JR, AP 2802 may also transmit frame 2814 to STA 2810 associated with slave AP 2804, and AP 2804 may also transmit frame 2816 to STAs 2806 and 2808 associated with AP 2802. The resources for transmitting and receiving frames 2814 and 2816 may depend on the specific multi- AP transmission scheme adopted.

[0299] STAs 2806 and 2808 may respond to frame 2814, STA 2810 may respond to frame 2816. For example, STAs 2806 and 2808 may transmit frames 2818 and 2820 respectively to AP 2802, while STA 2810 may transmit a frame 2822 to AP 2804. Frames 2818, 2820, and / or 2822 may be transmitted simultaneously. Frames 2818, 2820, and 2822 may comprise data frames or null data frames. STAs 2806, 2808, and 2810 may also transmit frames 2818, 2820, and 2822 respectively to APs in different BSSs, when required by the used multi-AP transmission scheme. For example, when the multi-AP transmission scheme is JT / JR, STAs 2806 and 2808 may also transmit respective frames 2818 and 2820 to AP 2804, and STA 2810 may also transmit frame 2822 to AP 2802. The resources for transmitting and receiving frames 2818, 2820, and 2822 may depend on the specific multi-AP transmission scheme adopted. AP 2802 may acknowledge frames 2818 and 2820 by transmitting a multi-STA BA frame 2824 to STAs 2806 and 2808. AP 2804 may acknowledge frame 2822 by transmitting a BA frame 2826 to STA 2810.

[0300] The MAPC framework includes a set of schemes (Co-BF, Co-SR, Co-TDMA, and Co-RTWT) and procedures in which APs operating their BSSs on the same primary 20 MHz channel coordinate to reduce interference levels and to improve network performance such as medium utilization efficiency, communication reliability, and latency.

[0301] An AP may use an MAPC scheme with another AP if the AP has established an agreement for that MAPC scheme by following the procedures defined in 37.13.1 (Common procedures for all multi-AP coordination schemes) of the IEEE 802.11 standard.

Claims

Docket No.: 24-3043PCT CLAIMS What is claimed is:

1. A method comprising: transmitting, by a first station (STA) to a second STA, a first frame indicating a first length of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU) to be transmitted by the first STA to the second STA after the first frame; receiving, by the first STA from the second STA, a second frame in response to the first frame; and transmitting, by the first STA to the second STA, the PPDU, wherein a second length of pre- forward error correction (FEC) padding bits of the PPDU is based on the first length of the PSDU.

2. A method comprising: transmitting, by a first station (STA) to a second STA, a first frame comprising an indication of a first length of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU); and transmitting, by the first STA to the second STA, the PPDU after transmitting the first frame.

3. The method of claim 2, wherein the first frame comprises an initial control frame (ICF).

4. The method of claim 3, wherein the ICF initiates a power save (PS) operation, dynamic subband operation (DSO), or a transmit opportunity (TXOP) protection.

5. The method of any of claims 2-4, wherein the indication of the first length is provided in a user info field of the first frame.

6. The method of any of claims 2-4, wherein the indication of the first length is provided in a common info field of the first frame.

7. The method of claim 2, wherein the first frame comprises a quality of service (QoS) data frame or a QoS Null frame.

8. The method of any of claims 2 or 7, wherein the indication of the first length is provided in a high throughput (HT) control field of the first frame.

9. The method of any of claims 2-8 wherein transmitting the PPDU comprises encoding the PSDU using a low density parity check (LDPC) code.

10. The method of any of claims 2-9, further comprising receiving, by the first STA from the second STA, a second frame in response to the first frame.

11. The method of claim 10, wherein transmitting the PPDU comprises encoding the PSDU of the PPDU without pre-forward error correction (FEC) padding.

12. The method of claim 11, wherein encoding the PSDU of the PPDU without pre-FEC padding is based on the first frame comprising the indication of the first length.Docket No.: 24-3043PCT 13. The method of any of claims 11-12, wherein encoding the PSDU of the PPDU without pre-FEC padding is based on receiving the second frame.

14. The method of claim 13, wherein the second frame indicates acceptance of encoding without pre-FEC padding.

15. The method of any of claims 11-14, wherein encoding the PSDU of the PPDU without pre-FEC padding comprises repeating of one or more coded bits of the PSDU.

16. The method of claim 10, wherein transmitting the PPDU comprises encoding the PSDU of the PPDU with pre-forward error correction (FEC) padding.

17. The method of claim 16, wherein encoding the PSDU of the PPDU with pre-FEC padding is based on the first frame comprising the indication of the first length.

18. The method of any of claims 16-17, wherein encoding the PSDU of the PPDU with pre-FEC padding is based on receiving the second frame.

19. The method of claim 18, wherein the second frame indicates rejection of encoding without pre-FEC padding.

20. The method of any of claims 2-19, wherein the first length comprises a length of a medium access layer protocol data unit (MPDU) or an aggregate MPDU (A-MPDU) carried in the PSDU.

21. The method of any of claims 2-20, further comprising issuing, by a medium access control (MAC) layer of the first STA, a physical layer (PHY)-transmit start request (TXSTART) primitive to a PHY layer of the first STA to transmit the PSDU.

22. The method of claim 21, wherein the PHY-TXSTART request primitive comprises the first length.

23. The method of any of claims 2-22, further comprising encoding the PSDU using a first number of bits comprising a second length of the PSDU.

24. The method of claim 23, wherein the second length comprises the first length multiplied by 8 plus 16.

25. The method of any of claims 23 or 24, wherein encoding the PSDU using the first number of bits comprising the second length of the PSDU is based on transmitting the first frame comprising the indication of the first length.

26. The method of any of claims 23-25, wherein encoding the PSDU using the first number of bits comprising the second length of the PSDU is based on receiving a response to the first frame.

27. The method of any of claims 2-26, wherein the PSDU comprises a medium access layer protocol data unit (MPDU) or an aggregate medium access layer protocol data unit (A-MPDU).

28. The method of any of claims 2-27, wherein the first length of the PSDU comprises a length of an aggregate medium access layer protocol data unit (A-MPDU) pre-end of frame (EOF) padding (APEP) carried in the PSDU.

29. The method of any of claims 2-28, wherein the PPDU is an ultra high reliability (UHR) PPDU.Docket No.: 24-3043PCT 30. The method of claim 2, wherein transmitting the PPDU comprises encoding the PSDU of the PPDU with pre-forward error correction (FEC) padding using up to N padding boundaries.

31. The method of claim 30, wherein the first length comprises an indication relating to the N padding boundaries.

32. The method of any of claims 30-31, wherein N is greater than 4.

33. A method comprising: transmitting, by a first station (STA) to a second STA, a first frame comprising an indication of a first padding boundary of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU); and transmitting, by the first STA to the second STA, the PPDU after transmitting the first frame.

34. The method of claim 33, wherein the first padding boundary comprises 1 up to N padding boundaries of a last orthogonal frequency division multiplexing (OFDM) symbol of the PPDU.

35. The method of claim 34, wherein N is greater than 4.

36. The method of claim 35, wherein N being greater than 4 is based on the transmitting of the first frame comprising the indication of the first padding boundary.

37. The method of any of claims 35-36, further comprising receiving a response to the first frame, wherein N being greater than 4 is based on the receiving of the response to the first frame.

38. The method of any of claims 33-37, wherein the first frame comprises an initial control frame (ICF).

39. The method of any of claims 33-37, wherein the first frame comprises a quality of service (QoS) data frame or a QoS Null frame.

40. A method comprising: receiving, by a first station (STA) from a second STA, a first frame indicating a first length of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU) to be transmitted by the second STA to the first STA after the first frame; transmitting, by the first STA to the second STA, a second frame in response to the first frame; and receiving, by the first STA from the second STA, the PPDU, wherein a second length of pre- forward error correction (FEC) padding bits of the PPDU is based on the first length of the PSDU.

41. A method comprising: receiving, by a first station (STA) from a second STA, a first frame comprising an indication of a first length of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU); and receiving, by the first STA from the second STA, the PPDU after receiving the first frame.

42. The method of claim 41, wherein the first frame comprises an initial control frame (ICF).Docket No.: 24-3043PCT 43. The method of claim 42, wherein the ICF initiates a power save (PS) operation, dynamic subband operation (DSO), or a transmit opportunity (TXOP) protection.

44. The method of any of claims 41-43, wherein the indication of the first length is provided in a user info field of the first frame.

45. The method of any of claims 41-43, wherein the indication of the first length is provided in a common info field of the first frame.

46. The method of claim 41, wherein the first frame comprises a quality of service (QoS) data frame or a QoS Null frame.

47. The method of any of claims 41 or 46, wherein the indication of the first length is provided in a high throughput (HT) control field of the first frame.

48. The method of any of claims 41-47 wherein the PSDU of the PPDU is encoded using a low density parity check (LDPC) code.

49. The method of any of claims 41-48, further comprising transmitting, by the first STA to the second STA, a second frame in response to the first frame.

50. The method of claim 49, wherein the PSDU of the PPDU is encoded without pre-forward error correction (pre-FEC) padding.

51. The method of claim 50, wherein encoding the PSDU of the PPDU without pre-FEC padding is based on the first frame comprising the indication of the first length.

52. The method of any of claims 50-51, wherein encoding the PSDU of the PPDU without pre-FEC padding is based on the second STA receiving the second frame.

53. The method of claim 52, wherein the second frame indicates acceptance of encoding without pre-FEC padding.

54. The method of any of claims 50-53, wherein encoding the PSDU of the PPDU without pre-FEC padding comprises repeating of one or more coded bits of the PSDU.

55. The method of claim 49, wherein the PSDU of the PPDU is encoded with pre-FEC padding.

56. The method of claim 55, wherein encoding the PSDU of the PPDU with pre-FEC padding is based on transmission by the second STA of the first frame comprising the indication of the first length.

57. The method of any of claims 55-56, wherein encoding the PSDU of the PPDU with pre-FEC padding is based on the second STA receiving the second frame.

58. The method of claim 57, wherein the second frame indicates rejection of encoding without pre-FEC padding.

59. The method of any of claims 41-58, wherein the first length comprises a length of a medium access layer protocol data unit (MPDU) or an aggregate MPDU (A-MPDU) carried in the PSDU.Docket No.: 24-3043PCT 60. The method of any of claims 41-59, further comprising issuing, by a medium access control (MAC) layer of the second STA, a physical layer (PHY)-transmit start request (TXSTART) primitive to a PHY layer of the first STA to transmit the PSDU.

61. The method of claim 60, wherein the PHY-TXSTART request primitive comprises the first length.

62. The method of any of claims 41-61, wherein the PSDU is encoded using a first number of bits that comprises a second length of the PSDU.

63. The method of claim 62, wherein the second length comprises the first length multiplied by 8 plus 16.

64. The method of any of claims 62 or 63, wherein encoding the PSDU using the first number of bits comprising the second length of the PSDU is based on the second STA transmitting the first frame comprising the indication of the first length.

65. The method of any of claims 62-64, wherein encoding the PSDU using the first number of bits comprising the second length of the PSDU is based on the second STA receiving a response to the first frame.

66. The method of any of claims 41-65, wherein the PSDU comprises a medium access layer protocol data unit (MPDU) or an aggregate medium access layer protocol data unit (A-MPDU).

67. The method of any of claims 41-66, wherein the first length of the PSDU comprises a length of an aggregate medium access layer protocol data unit (A-MPDU) pre-end of frame (EOF) padding (APEP) carried in the PSDU.

68. The method of any of claims 41-67, wherein the PPDU is an ultra high reliability (UHR) PPDU.

69. The method of claim 41, wherein the PSDU of the PPDU is encoded with pre-FEC padding using up to N padding boundaries.

70. The method of claim 69, wherein the first length comprises an indication relating to the N padding boundaries.

71. The method of any of claims 69-70, wherein N is greater than 4.

72. A method comprising: receiving, by a first station (STA) from a second STA, a first frame comprising an indication of a first padding boundary of a physical layer service data unit (PSDU) of a physical layer protocol data unit (PPDU); and receiving, by the first STA from the second STA, the PPDU after receiving the first frame.

73. The method of claim 72, wherein the first padding boundary comprises 1 up to N padding boundaries of a last orthogonal frequency division multiplexing (OFDM) symbol of the PPDU.

74. The method of claim 73, wherein N is greater than 4.

75. The method of claim 74, wherein N being greater than 4 is based on the second STA transmitting the first frame comprising the indication of the first padding boundary.Docket No.: 24-3043PCT 76. The method of any of claims 74-75, further comprising transmitting, from the first STA to the second STA, a response to the first frame, wherein N being greater than 4 is based on the second STA receiving the response to the first frame.

77. The method of any of claims 72-76, wherein the first frame comprises an initial control frame (ICF).

78. The method of any of claims 72-76, wherein the first frame comprises a quality of service (QoS) data frame or a QoS Null frame.

79. 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-78.

80. 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-78.

Images