Non-primary channel access (NPCA) operation for extended long range (ELR) transmission

Abstract

A first station (STA) receives, via a primary channel (PCH), an extended long range (ELR) physical layer protocol data unit (PPDU). Based on failing to identify a basic service set (BSS) color from a first preamble of the ELR PPDU, the first STA receives a portion of a second preamble, following the first preamble, of the ELR PPDU to identify the BSS color. The BSS color identifies a BSS of which a second STA that transmits the ELR PPDU is a member. Based on the BSS color indicating that the ELR PPDU comprises an inter-BSS PPDU, the first STA switches, after receiving the portion, from the PCH to a non-primary channel access (NPCA) PCH.

Description

Docket No.: 24-3048PCTTITLENON-PRIMARY CHANNEL ACCESS (NPCA) OPERATION FOR EXTENDED LONG RANGE (ELR) TRANSMISSIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 708,831 , filed October 18, 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 an example of a Medium Access Control (MAC) frame format.

[0006] FIG. 4 illustrates an example trigger frame.

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

[0008] FIG. 6 illustrates an example common info field.

[0009] FIG. 7 illustrates an example of a Request-to-Send (RTS)ZCIear-to-Send (CTS) procedure.

[0010] FIG. 8 is an example that illustrates an MU-RTS / CTS procedure.

[0011] FIG. 9 illustrates an example non-high throughput (non-HT) physical layer protocol data unit (PPDU) format.

[0012] FIG. 10 illustrates an example extended long range (ELR) PPDU format.

[0013] FIG. 11 is an example that illustrates non-primary channel access (NPCA) operation.

[0014] FIG. 12 illustrates virtual and physical carrier sense (CS) functions associated with primary and secondary channels for NPCA operation and non-NPCA operation.

[0015] FIG. 13 shows an example that illustrates an NPCA operation.

[0016] FIG. 14 shows an example that illustrates another NPCA operation.

[0017] FIG. 15 shows an example that illustrates an example NPCA operation according to an embodiment.

[0018] FIG. 16 shows an example that illustrates another example NPCA operation according to an embodiment

[0019] FIG. 17 shows an example that illustrates another example NPCA operation according to an embodiment.

[0020] FIG. 18 shows an example that illustrates another example NPCA operation according to an embodiment.Docket No.: 24-3048PCT

[0021] FIG. 19 shows an example that illustrates another example NPCA operation according to an embodiment.

[0022] FIG. 20 shows an example that illustrates another example NPCA operation according to an embodiment.

[0023] FIG. 21 shows an example that illustrates another example NPCA operation according to an embodiment.

[0024] FIG. 22 shows an example that illustrates another example NPCA operation according to an embodiment.

[0025] FIG. 23 shows an example that illustrates an example frame exchange according to an embodiment.

[0026] FIG. 24 illustrates an example process according to an embodiment.DETAILED DESCRIPTION

[0027] 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 those shown. For example, the actions listed in any flowchart may be re-ordered or only optionally used in some embodiments.

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

[0029] 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 suitableDocket No.: 24-3048PCT possibilities that may, or may not, be employed by one or more of the various embodiments. The terms “comprises” and “consists of’, as used herein, enumerate one or more components of the element being described. The term “comprises” is interchangeable with “includes" and does not exclude unenumerated components from being included in the element being described. By contrast, “consists of provides a complete enumeration of the one or more components of the element being described. The term “based on”, as used herein, may be interpreted as “based at least in part on” rather than, for example, “based solely on”. The term “and / or” as used herein represents any possible combination of enumerated elements. For example, “A, B, and / or C” may represent A; B; C; A and B; A and C; B and C; or A, B, and C.

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

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

[0032] In this disclosure, parameters (or equally called, fields, or Information elements: IBs) 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 ofDocket No.: 24-3048PCT 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.

[0033] Many features presented are described as being optional through the use of “may” or the use of parentheses. For the sake of brevity and legibility, the present disclosure does not explicitly recite each and every permutation that may be obtained by choosing from the set of optional features. The present disclosure is to be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional features may be embodied in seven ways, namely with just one of the three possible features, with any two of the three possible features or with three of the three possible features.

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

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

[0036] 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) 1 10 and 120 and a distribution system (DS) 130

[0037] 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 1 10-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.Docket No.: 24-3048PCT

[0038] DS 130 may be configured to connect BSS 110-1 and BSS 110-2. As such, DS 130 may enable an extended service set (ESS) 150. Within ESS 150, APs 104-1 and 104-2 are connected via DS 130 and may have the same service set identification (SSID).

[0039] WLAN infra-structure network 102 may be coupled to one or more external networks. For example, as shown in FIG. 1 , WLAN infra-structure network 102 may be connected to another network 108 (e.g., 802.X) via a portal 140. Portal 140 may function as a bridge connecting DS 130 of WLAN infra-structure network 102 with the other network 108.

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

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

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

[0043] 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 PHY service data unit (PSDU). For example, the PSDU may include a PHY preamble and header and / or one or more MAC protocol data units (MPDUs). The information provided in the PHY preamble may be used by a receiving device to decode the subsequent data in the PSDU. In instances in which PPDUs are transmitted over a bonded channel (channel formed through channel bonding), the preamble fields may be duplicated and transmitted in each of the multiple component channels. The PHY preamble may include both a legacy portion (or “legacy preamble”) and a non-legacy portion (or “non-legacy preamble”). The legacy preamble may be used for packet detection, automatic gain control and channel estimation, among other uses. The legacy preamble also may generally be used to maintain compatibility with legacy devices. The format of, coding of, and information provided in the non-legacy portion of the preamble is based on the particular IEEE 802.11 protocol to be used to transmit the payload.

[0044] A frequency band may include one or more sub-bands or frequency channels. For example, PPDUs conforming to the IEEE 802.11 n, 802.1 1ac, 802.11 ax and / or 802.11 be standard amendments may beDocket No.: 24-3048PCT 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 optionally formed through channel bonding of a primary 20 MHz channel and one or more 20 MHz secondary channels. For example, PPDUs may be transmitted over physical channels having bandwidths of 40 MHz, 80 MHz, 160 MHz, or 320 MHz by bonding together a primary 20 MHz channel and 1 , 3, 7, or 15 secondary channel respectively. The primary channel is the default channel for a BSS. An AP of the BSS uses the primary channel to transmit management frames, thereby ensuring that all STAs in the BSS (regardless of channel bonding support) can receive the management frames.

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

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

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

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

[0049] FIG. 3 illustrates an example format of a MAC frame. In operation, a STA may construct a subset of MAC frames for transmission and may decode a subset of received MAC frames upon validation. The particular subsets of frames that a STA may construct and / or decode may be determined by the functionsDocket No.: 24-3048PCT supported by the STA. A STA may validate a received MAC frame using the frame check sequence (FCS) contained in the frame and may interpret certain fields from the MAC headers of all frames.

[0050] As shown in FIG. 3, a MAC frame includes a MAC header, a variable length frame body, and a frame check sequence (FCS).

[0051] The MAC header includes a frame control field, an optional duration / ID field, address fields, an optional sequence control field, an optional QoS control field, and an optional HT control field.

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

[0053] The protocol version subfield is invariant in size and placement across all revisions of the IEEE 802.1 1 standard. The value of the protocol version subfield is 0 for MAC frames.

[0054] The type and subtype subfields together identify the function of the MAC frame. There are three frame types: control, data, and management. Each of the frame types has several defined subtypes. Bits within the subtype subfield are used to indicate a specific modification of the basic data frame (subtype 0). For example, in data frames, the most significant bit (MSB) of the subtype subfield, bit 7 (B7) of the frame control field, is defined as the QoS subfield. When the QoS subfield is set to 1 , it indicates a QoS data frame, which is a data frame that contains a QoS control field in its MAC header. The second MSB of the subtype field, bit 6 (B6) of the frame control field, when set to 1 in data subtypes, indicates a data frame that contain no frame body field.

[0055] The “To DS” subfield indicates whether a data frame is destined to the distribution system (DS). The “From DS” subfield indicates whether a data frame originates from the DS.

[0056] The “More Fragments” subfield is set to 1 in all data or management frames that have another fragment to follow the MAC service data unit (MSDU) or MAC management protocol data unit (MMPDU) carried by the MAC frame. The “More Fragments” subfield is set to 0 in all other frames in which the “More Fragments” subfield is present.

[0057] The retry subfield is set to 1 in any data or management frame that is a retransmission of an earlier frame. It is set to 0 in all other frames in which the retry subfield is present. A receiving STA uses this indication to aid it in the process of eliminating duplicate frames. These rules do not apply for frames sent by a STA under a block agreement.

[0058] The power management subfield is used to indicate the power management mode of a STA

[0059] The “More Data” subfield indicates to a STA in power save (PS) mode that bufferable units (BUs) are buffered for that STA at the AP. The “More Data" subfield is valid in individually addressed data or management frames transmitted by an AP to a STA in PS mode. The “More Data” subfield is set to 1 to indicate that at least one additional buffered BU is present for the STA.Docket No.: 24-3048PCT

[0060] The protected frame subfield is set to 1 if the frame body field contains information that has been processed by a cryptographic encapsulation algorithm.

[0061] The +HTC subfield indicates that the MAC frame contains an HT control field

[0062] The duration / ID field of the MAC header indicates various contents depending on the frame type and subtype and the QoS capabilities of the sending STA. For example, in control frames of the power save poll (PS-Poll) subtype, the duration / ID field carries an association identifier (AID) of the STA that transmitted the frame in the 14 least significant bits (LSB), with the 2 most significant bits (MSB) set to 1 . In other frames sent by STAs, the duration / ID field contains a duration value (in microseconds) which is used by a recipient to update a network allocation vector (NAV). The NAV is a counter that indicates to a STA an amount of time during which the STA must defer from accessing the shared medium.

[0063] Up to four address fields may be present in the MAC frame format. The address fields are used to indicate the basic service set identifier (BSSID), source address (SA), destination address (DA), transmitting address (TA), and receiving address (RA). Certain frames may not contain some of the address fields. Certain address field usage may be specified by the relative position of the address field (1-4) within the MAC header, independent of the type of address present in that field. Specifically, the address 1 field always identifies the intended receiver(s) of the frame, and the address 2 field, where present, always identifies the transmitter of the frame.

[0064] The sequence control field includes two subfields, a sequence number subfield and a fragment number subfield. The sequence number subfield in data frames indicates the sequence number of the MSDU (if not in an Aggregated MSDU (A-MSDU)) or A-MSDU. The sequence number subfield in management frames indicates the sequence number of the frame. The fragment number subfield indicates the number of each fragment of an MSDU or MMPDU. The fragment number is set to 0 in the first or only fragment of an MSDU or MMPDU and is incremented by one for each successive fragment of that MSDU or MMPDU. The fragment number is set to 0 in a MAC protocol data unit (MPDU) containing an A-MSDU, or in an MPDU containing an MSDU or MMPDU that is not fragmented. The fragment number remains constant in all retransmissions of the fragment.

[0065] The QoS control field identifies the traffic category (TC) or traffic stream (TS) to which the MAC frame belongs. The QoS control field may also indicate various other QoS related, A-MSDU related, and mesh- related information about the frame. This information can vary by frame type, frame subtype, and type of transmitting STA The QoS control field is present in all data frames in which the QoS subfield of the subtype subfield is equal to 1.

[0066] The HT control field is present in QoS data, QoS null, and management frames as determined by the +HTC subfield of the frame control field.Docket No.: 24-3048PCT

[0067] The frame body field is a variable length field that contains information specific to individual frame types and subtypes. The frame body may include one or more MSDUs or MMPDUs. The minimum length of the frame body is 0 octets.

[0068] The FCS field contains a 32-bit Cyclic Redundancy Check (CRC) code. The FCS field value is calculated over all of the fields of the MAC header and the frame body field.

[0069] FIG. 4 illustrates an example trigger frame 400. Trigger frame 400 may correspond to a basic trigger frame as defined in the existing IEEE 802.1 1 ax standard amendment. Trigger frame 400 may be used by an AP to allocate resources for and solicit one or more TB PPDU transmissions from one or more STAs. Trigger frame 400 may also carry other information required by a responding STA to transmit a TB PPDU to the AP.

[0070] As shown in FIG. 4, trigger frame 400 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.

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

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

[0073] 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 400 if trigger frame 400 is addressed to STAs that belong to a single BSS. The TA field is the transmitted BSSID if the trigger frame 400 is addressed to STAs from at least two different BSSs of the multiple BSSID set.

[0074] The common info field may have a format as illustrated by common info field 600 described further below. The common info field specifies a trigger frame type of trigger frame 400, a transmit power of trigger frame 400 in dBm, and several key parameters of a TB PPDU that is transmitted by a STA in response to trigger frame 400. 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.

[0075] The User List Info field contains a User Info field per STA addressed in trigger frame 400. 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 400, 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,Docket No.: 24-3048PCT along with the BW, MCS, RU allocation, SS allocation, Tx power, preferred AC, and maximum duration of the TB PPDU per participating STA.

[0076] The Padding field is optionally present in trigger frame 400 to extend the frame length to give recipient STAs enough time to prepare a response for transmission one SIPS (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 1 s.

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

[0078] FIG. 5 illustrates an example multi-user request to send (MU-RTS) trigger frame 500. MU-RTS trigger frame 500 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. 5, MU-RTS trigger frame 500 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 400 described above. The common info field may have a format as illustrated by common info field 600 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.

[0079] The one or more user info fields correspond respectively to the one or more STAs solicited by MU- RTS trigger frame 500. As shown in FIG. 5, 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.

[0080] FIG. 6 illustrates an example Common Info field 600. Common Info field 600 may be an embodiment of the Common Info field of trigger frame 400 or MU-RTS trigger frame 500, for example. As shown in FIG. 6, Common Info field 600 may include a Trigger Type subfield, a UL Length subfield, a More TF subfield, a CS required subfield, a UL BW subfield, a Gl 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 P160 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, Gl 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, thirdDocket No.: 24-3048PCTReserved subfield, HE / EHT P160 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.11 be draft amendment (“IEEE P802.11 be / D3.1 , March 2023”).

[0081] FIG. 7 illustrates an example 700 of a Request-to-Send (RTS) / Clear-to-Send (CTS) procedure. Example 700 may be an example according to the RTS / CTS procedure as defined in section 10.3.2.9 of the IEEE 802.1 1 standard draft “IEEE P802.1 1-REVme™ / D3.0, April 2023.” As shown in FIG. 7, example 700 may include STAs 702 and 704. Other STAs of the same BSS may also be within communication range of STAs 702 and 704.

[0082] In an example, STA 702 may transmit an RTS frame 706 to STA 704. STA 702 may transmit RTS frame 706 to protect from hidden STA(s) the transmission of a data frame 710 that STA 702 intends to transmit. RTS frame 706 may include a Duration / ID field. The Duration / ID field may be set to the time, in microseconds, required to transmit data frame 710, plus one CTS frame, plus one ACK frame (if required), plus three SIFS (Short Interframe Spacing) periods.

[0083] In an example, STA 704 may respond to RTS frame 706 by transmitting a CTS frame 708 to STA 702. CTS frame 708 may be transmitted one SIFS period after RTS frame 706. STA 704 may respond to RTS frame 706 when RTS frame 706 is addressed to STA 704 and after considering the NAV, unless the NAV was set by a frame originating from STA 702. STA 704 may respond to the RTS frame 706 when RTS frame 706 is addressed to STA 704 and if the NAV indicates idle. For a non-S1 G STA, the NAV indicates idle when the NAV count is 0 or when the NAV count is non-zero but a nonbandwidth signaling TA obtained from a TA field of RTS frame 706 matches a saved TXOP holder address. For an S1 G STA, the NAV indicates idle when both the NAV and RID (response indication deferral) counters are 0 or when either the NAV or RID counter is non-zero but the TA field of RTS frame 706 matches the saved TXOP holder address.

[0084] STA 704 may set an RA field of CTS frame 708 to a nonbandwidth signaling TA obtained from the TA field of RTS frame 706. STA 704 may set a Duration field of CTS frame 708 based on the Duration / ID field of RTS frame 706, namely as equal to the value of the Duration / ID field of RTS frame 706, adjusted by subtracting the time required to transmit CTS frame 708 and one SIFS period.

[0085] Upon receiving CTS frame 708, STA 702 may wait one SIFS period before transmitting data frame 710. STA 704 may transmit an ACK frame 712 in response to data frame 710. STA 704 may transmit ACK frame 712 one SIFS after receiving data frame 710

[0086] As shown in example 700, other STAs within communication range of STAs 702 and 704, and belonging to the same BSS, may set their NAVs according to RTS frame 706 and / or CTS frame 708. For example, a STA receiving RTS frame 706 may set its NAV based on the Duration / ID field of RTS frame 706. Another STA receiving CTS frame 708 may set its NAV based on the Duration field of CTS frame 708. AsDocket No.: 24-3048PCT such, the other STAs may not access the channel using EDCA until the end of transmission of ACK frame 712.

[0087] FIG. 8 is an example 800 that illustrates a multi-user Request-to-Send (MU-RTS) / Clear-to-Send (CTS) procedure. Example 800 may be an example according to the MU-RTS / CTS procedure as defined in section 26.2.6 of the IEEE 802.1 1 standard draft. As shown in FIG. 8, example 800 may include an AP 802 and STAs 804 and 806. STAs 804 and 806 may be associated with AP 802. For the purpose of illustration, example 800 also illustrates STAs of an overlapping basic service set (OBSS) relative to the BSS of AP 802 (OBSS STAs). The OBSS STAs, as shown in FIG. 8, may be hidden from AP 802 (outside of the communication range of AP 802) or exposed to AP 802 (within the communication range of AP 802).

[0088] In example 800, AP 802 wishes to transmit a downlink (DL) multi-user (MU) PPDU 814 to STAs 804 and 806. DL MU PPDU 814 may comprise data for each of STAs 804 and 806. DL MU PPDU 814 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 804, STA 806) served by DL MU PPDU 814.

[0089] As shown in FIG. 8, to protect the transmission of DL MU PPDU 814 to STAs 804 and 806 from interference by OBSS STAs hidden from AP 802, AP 802 may use the MU-RTS / CTS procedure to initiate a TXOP and to protect the TXOP frame exchange sequence. AP 802 may initiate the TXOP by transmitting an MU-RTS trigger frame 808 that solicits simultaneous CTS frame transmissions from STAs 804 and 806.

[0090] MU-RTS trigger frame 808 may have a format as illustrated by MU-RTS trigger frame 500 illustrated in FIG. 5. As such, MU-RTS trigger frame 808 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 duration field may be set to the time, in microseconds, required to transmit DL MU PPDU 814, plus the time required to transmit one CTS frame, one ACK frame (if required), and three SIFS periods.

[0091] The one or more user info fields correspond respectively to the one or more STAs solicited by the MU-RTS trigger frame. In example 800, MU-RTS trigger frame 808 may comprise a user info field for each of STAs 804 and 806 indicating that a CTS frame is solicited from each of STAs 804 and 806. As shown in FIG. 8, 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.

[0092] AP 802 may send MU-RTS trigger frame 808 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 MU-RTS trigger frame 808, AP 802 may request at least one non-AP STA to send a CTS frame that occupies that channel. In an example, AP 802 may not request that a non-AP STA send a CTS frame that occupies a channel that is not occupied by the PPDU carrying MU-RTS trigger frame 808.Docket No.: 24-3048PCT

[0093] After transmitting MU-RTS trigger frame 808, AP 802 may wait for a CTSTimeout interval of aSIFSTime + aSlotTime + aRxPHYStartDelay that begins when a MAC layer of AP 802 receives a PHYTXEND confirm primitive for transmitted MU-RTS trigger frame 808 If the MAC layer does not receive a PHY-RXEARLYSIG. indication or a PHY-RXSTART. indication primitive during the CTSTimeout interval, AP 802 may conclude that the transmission of MU-RTS trigger frame 808 has failed, and, if MU-RTS trigger frame 808 initiated a TXOP, AP 802 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 MU-RTS trigger frame 808 was successful. The receipt of a CTS frame from any non-AP STA addressed by MU-RTS trigger frame 808 before the PHY-RXEND. indication primitive shall be interpreted as the successful transmission of MU-RTS trigger frame 808, 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 MU-RTS trigger frame 808. AP 802 may process the received frame and, if MU-RTS trigger frame 808 initiated a TXOP, AP 802 shall invoke its backoff procedure at the PHY-RXEND. indication primitive.

[0094] In example 800, on receiving MU-RTS trigger frame 808, STAs 804 and 806 respond by transmitting respectively CTS frames 810 and 812 to AP 802. In an example, STAs 804 and 806 begin the transmission of CTS frames 810 and 812, respectively, at the SIPS time boundary after an end of a received PPDU comprising MU-RTS trigger frame 808. In an example, STA 804 (or STA 806) responds to MU-RTS trigger frame 808 with a CTS frame when the following conditions are met: MU-RTS trigger frame 808 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 MU-RTS trigger frame 808 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.1 1 standard ("IEEE P802.11-REVme™ / D3.0, April 2023”). Otherwise, if one of the conditions is not met, STA 804 (or STA 806) does not send a CTS frame to AP 802.

[0095] In an example, STAs 804 and 806 may set an RA field of respectively CTS frames 810 and 812 to a TA obtained from the TA field of MU-RTS trigger frame 808. In an example, STAs 804 and 806 may set a duration field of respectively CTS frames 810 and 812 based on the duration field of MU-RTS trigger frame 808, namely as equal to the value of the duration field of MU-RTS trigger frame 808, adjusted by subtracting the time required to transmit respectively CTS frames 810 and 812 and one SIPS period.

[0096] OBSS STAs exposed to AP 802 may receive MU-RTS trigger frame 808 due to being within the communication range of AP 802. In an example, as shown in FIG. 8, on receiving MU-RTS trigger frame 808, OBSS STAs exposed to AP 802 set their respective NAVs based on the duration field of MU-RTS trigger frame 808. As such, the OBSS STAs exposed to AP 802 may not access the wireless medium for the duration of the TXOP initiated by AP 802.Docket No.: 24-3048PCT

[0097] OBSS STAs hidden from AP 802 do not receive MU-RTS trigger frame 808 due to being outside the communication range of AP 802. However, in an example, as shown in FIG. 8, some of the OBSS STAs hidden from AP 802 may receive CTS frame 810 and / or CTS frame 812 and may set their respective NAVs based on the duration field of CTS frame 810 and / or CTS frame 812. As such, some of the OBSS STAs hidden from AP 802 may also not access the wireless medium for the duration of the TXOP initiated by AP 802.

[0098] On receiving CTS frame 810 and / or CTS frame 812, AP 802 may wait one SIPS period before transmitting DL MU PPDU 814. On receiving DL MU PPDU 814, STAs 804 and 806 may respond by transmitting respective BlockAck (BA) frames 816 and 818 to AP 802.

[0099] FIG. 9 illustrates an example non-HT PPDU format. As shown in FIG. 9, the non-HT PPDU format may include a PHY preamble, a PHY header, a PSDU, tail bits, and pad bits. The PHY preamble may include 12 OFDM symbols

[0100] The PHY header includes a SIGNAL field and a SERVICE field. The SIGNAL field includes a RATE field, a reserved bit, a LENGTH field, a parity bit, and tail bits. The tail bits of the SIGNAL field enable decoding of the RATE and LENGTH fields immediately after the reception of the tail bits. The SIGNAL field may constitute a single OFDM symbol. The SIGNAL field may be transmitted using the most robust combination of Binary Phase Shift Keying (BPSK) modulation and a coding rate of R =1 / 2.

[0101] The SERVICE field of the PHY header and the PSDU (with 6 zero tail bits and pad bits appended), denoted as DATA field, are transmitted at the data rate described in the RATE field of the PHY header. The DATA field may constitute multiple OFDM symbols. The RATE and LENGTH fields are required for decoding the DATA field

[0102] FIG. 10 illustrates an example extended long range (ELR) PPDU format. ELR PPDU may be supported by ultra-high reliability (UHR) STAs (STAs compliant with the IEEE 802.1 1 bn standard amendment). As shown in FIG. 10, an ELR PPDU may include a legacy preamble, an ELR preamble, and a DATA field.

[0103] The legacy preamble enables backward compatibility of the ELR PPDU. Specifically, the legacy preamble allows legacy (e.g., pre-UHR) IEEE 802.11 device to detect the ELR PPDU. The legacy preamble may include a legacy short training field (L-STF), a legacy long training field (L-LTF), a legacy signal field (L- SIG), a repeated L-SIG (RL-SIG), a universal signal (U-SIG) field (including two OFDM symbols (U-SIG1 and U-SIG2)). The L-STF may be used by a receiver of the ELR PPDU to synchronize with the carrier frequency and frame timing of a transmitter of the ELR PPDU and to adjust the receiver signal gain. The L-LTF may be used by the receiver of ELR PPDU 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 ELR PPDU. The L-SIG contains parameters needed to demodulate the DATA field, which contains a payload of the ELR PPDU. The L-SIG may be equalized using the channel coefficients estimated using the L-LTF and demodulated to obtainDocket No.: 24-3048PCT the demodulation parameters of the DATA field. The L-SIG may have a format similar to the SIGNAL field of the non-HT PPDU illustrated in FIG. 9. Among other parameters, the L-SIG may indicate in the LENGTH subfield a length of the ELR PPDU. The RL-SIG is a duplicate of the L-SIG Its presence increases the reception range of the ELR PPDU when received by legacy IEEE 802.1 1 devices. The U-SIG field provides U-SIG information that is used by a STA receiving the ELR PPDU. For example, the U-SIG field may indicate a TXOP duration associated with the ELR PPDU (based on which a receiving STA may set its NAV), a BSS color associated with the STA transmitting the ELR PPDU (BSS color of the BSS of which the STA transmitting the ELR PPDU is a member), a bandwidth associated with the ELR PPDU, an UL / DL indication, and / or a PHY version of the ELR PPDU.

[0104] The ELR preamble is intended to increase the reception range of the ELR PPDU. The ELR preamble may be transmitted using the most robust combination of BPSK modulation and a coding rate of R =1 / 2. The ELR preamble may include one or more ELR Mark fields (e.g., ELR-Mark 1 and ELR-Mark 2), an ELR-STF, an ELR-LTF, and an ELR-SIG.

[0105] The one or more ELR Mark fields may be used by a receiving STA to detect the ELR PPDU. For example, a receiving STA may not receive / decode the legacy preamble of the ELR PPDU but may detect the ELR PPDU by receiving / decoding the one or more ELR Mark fields. The one or more ELR Mark fields may indicate a BSS color of the ELR PPDU.

[0106] Similar to the L-STF, the ELR-STF may be used by a receiver of the ELR PPDU to synchronize with the carrier frequency and frame timing of the transmitter of the ELR PPDU and to adjust the receiver signal gain. The ELR-STF may be a longer version of L-STF to support longer range synchronization compared to L-STF. Similarly, ELR-LTF may be a longer version of L-LTF to support higher robustness when estimating the channel coefficients. The ELR-LTF may also include a higher number of symbol repetitions compared to the L-STF (e.g., 2). The ELR-SIG may include indications per STA of resource unit (RU) allocations. A STA may use the indications in the ELR-SIG to locate its payload in the ELR PPDU.

[0107] It is envisioned in future IEEE 802.11 standards that a STA (AP STA or non-AP STA) may access a non-primary channel to communicate with another STA. Such operation may be referred to as non-primary channel access (NPCA) operation. Specifically, in addition to a default primary channel (which is used by all STAs in the BSS and via which the AP transmits management frames), the STA may have one or more secondary channels considered as NPCA primary channels. The STA may transmit or receive on a channel that includes an NPCA primary channel but that does not necessarily include the primary channel (e.g., when the primary channel is unavailable). The STA may maintain a NAV for an NPCA primary channel independent of the NAV associated with the primary channel. FIG. 11 shows an example that illustrates non-primary channel access (NPCA) operation. For the purpose of illustration, NPCA operation is contrasted with single primary channel (non-NPCA STA) operation. As shown in FIG. 11 , the STA may be capable of operating over a plurality of channels. According to non-NPCA operation, the plurality of channels may include a primaryDocket No.: 24-3048PCT channel (PCH), a first secondary channel (SCH1 ), a second secondary channel (SCH2), and a third secondary channel (SCH2). According to NPCA operation, the same channels may include a primary channel (PCH), a first secondary channel (SCH1), an NPCA primary channel (NPCA PCH), and a second secondary channel (SCH2). It is noted that the position of the NPCA primary channel may or may not be as shown in the example of FIG. 11 . For example, the NPCA primary channel may correspond to SCH1 .

[0108] In an implementation, as shown in FIG. 12, in non-NPCA operation, a virtual carrier sense (CS) function (e.g., NAV) may be associated with only the PCH. Secondary channels may have only a physical CS function (e.g., energy detection) associated with them, which may be performed only when contending for transmission on the PCH. As such, as shown in FIG. 11 , the STA may only transmit on a channel that includes the PCH (e.g., PCH, PCH+SCH1 , PCH+SCH1+SCH2, PCH+SCH1 +SCH2+SCH3) and only when the NAV associated with the PCH is zero (and the physical CS function indicates "channel idle’’ for all channels being used).

[0109] In contrast, as shown in FIG. 12, in NPCA operation, a virtual CS function (e.g., NAV) may be associated with multiple channels (e.g., PCH and NPCA PCH). As such, as shown in FIG. 11 , the STA may transmit on channels that do not include the PCH but that include the NPCA PCH (e.g., NPCA PCH, NPCA PCH+SCH1 , NPCA PCH+SCH2) if the NAV associated with the NPCA PCH is zero (and the physical CS indicates "channel idle” for all channels being used). In an implementation, the STA may also transmit on channels that do not include the PCH but that include the NPCA PCH (e.g., NPCA PCH, NPCA PCH+SCH1 , NPCA PCH+SCH2) if the STA detects that the NPCA PCH is idle using physical CS for at least a medium synchronization duration.

[0110] In implementations, the STA may perform physical and / or virtual CS functions (herein referred to as CS or CCA) on multiple channels (e.g., PCH and NPCA PCH). If the PCH is busy (non-zero NAV or CCA indicates “channel busy”), the STA may use the NPCA PCH for transmission if the NPCA PCH is idle (zero NAV and CCA indicates “channel idle”).

[0111] In an implementation, the STA may perform CS in parallel on multiple channels, including the PCH and the NPCA PCH. Such a STA is referred to herein as a concurrent CCA NPCA STA (such a STA may also be referred to as a concurrent CCA multiple primary channel (MPC) STA or a Type 1 STA). Because of its concurrent CCA capability, a concurrent CCA NPCA STA is capable of medium synchronization simultaneously on multiple channels (e.g., PCH and NPCA PCH). Medium synchronization on a channel (e.g , PCH or NPCA PCH) may be performed by detecting a frame that includes NAV information or by listening to the channel for at least a medium synchronization duration and finding the channel idle throughout the medium synchronization duration. An NPCA STA that does not support this capability may perform CS on a single channel at a time. In an implementation, an NPCA STA may perform CS on the PCH by default, and when the PCH is found busy, the STA may perform CS on the NPCA PCH. Such a STA is referred to herein as a non-concurrent CCA NPCA STA (such a STA may also be referred to as a non-concurrent CCADocket No.: 24-3048PCTMPC STA or a Type 2 STA). In contrast to the concurrent CCA NPCA STA, a non-concurrent CCA NPCA STA may only synchronize to the NPCA PCH after the PCH is found busy. Hence, it may need to listen to the channel for at least a medium synchronization duration (if it does not receive any frame that includes NAV information) before it is able to transmit.

[0112] FIG. 13 shows an example 1300 that illustrates an NPCA operation. As shown in FIG. 13, example 1300 includes an AP and a STA associated with the AP. The AP and the STA may both support NPCA operation and may operate over a plurality of channels, including a primary channel (PCH), an NPCA primary channel (NPCA PCH), a first secondary channel (SCH1), and a second secondary channel (SCH2).

[0113] Example 1300 may begin with the AP transmitting a frame 1302 on the PCH. Frame 1302 may indicate a medium synchronization duration for the NPCA PCH. The medium synchronization duration of a channel indicates a minimum duration that a STA must listen to the channel before the STA is able to transmit on the channel (if the STA does not receive via the channel before the end of the medium synchronization duration a frame that indicates NAV information). Frame 1302 may be a management frame, such as a beacon frame, for example.

[0114] Subsequently, while the AP and STA operate on the PCH, transmission of a frame 1304 from an OBSS may begin on the PCH. The AP and the STA may detect frame 1304 on the PCH. In an implementation, the AP and STA may be configured to set a NAV associated with the PCH based on receiving frame 1304 on the PCH. Frame 1304 may indicate a transmission (of one or more frames including frame 1304) on the PCH. A duration of the transmission on the PCH may be provided by a duration field of frame 1304, a transmission opportunity (TXOP) duration field of an OBSS PPDU comprising frame 1304, or a length field of the OBSS PPDU. The AP and STA may set their NAVs for the PCH based on the duration of the OBSS transmission on the PCH (hereinafter, OBSS NAV duration or OBSS TXOP duration).

[0115] In accordance with NPCA operation, on receiving an OBSS PPDU and obtaining the OBSS NAV duration, the AP and the STA may be configured to switch to the NPCA PCH for the OBSS NAV duration. The AP and STA may be configured to finish transmitting on the NPCA PCH before an end of the OBSS NAV duration and to return to the PCH by the end of the OBSS NAV duration.

[0116] In an implementation, after switching to the NPCA PCH, the AP and STA may start a “MediumSyncDelay” timer for the medium synchronization duration of the NPCA PCH (e.g., as indicated in frame 1302). In example 1300, the AP may be a concurrent CCA STA capable of concurrent CS on both the PCH and the NPCA PCH. As such, provided that the NPCA PCH is idle, the AP may access the NPCA PCH, without waiting for expiration of the “MediumSyncDelay" timer, to transmit a frame 1306 on the NPCA PCH. In an example, the STA may be a non-concurrent CCA STA. On switching to the NPCA PCH, the STA may not be aware of whether a transmission is ongoing on the NPCA PCH. The STA may thus be configured to sense the NPCA PCH until the “MediumSyncDelay” timer expires before attempting to access the NPCA PCH. However, the STA may acquire medium synchronization on the NPCA PCH before expiration of theDocket No.: 24-3048PCT"MediumSyncDelay" timer if the STA receives a frame indicating NAV information on the NPCA PCH. For example, the STA may acquire medium synchronization on the NPCA PCH on receiving frame 1306 from the AP. The STA may reset the "MediumSyncDelay" timer to zero and may then proceed to access the NPCA PCH, after performing a random backoff, to transmit a frame (not shown in FIG. 13) on the NPCA PCH.

[0117] FIG. 14 shows an example 1400 that illustrates another NPCA operation. As shown in FIG. 14, example 1400 includes a STA 1402, which may be an AP STA or a non-AP STA. STA 1402 may be a UHR STA. Additionally, STA 1402 may support the NPCA operation described in FIG. 14, which includes switching from the PCH to the NPCA PCH after receiving / decoding the U-SIG field of an OBSS (or inter-BSS) PPDU.

[0118] In example 1400, while STA 1402 operates on the PCH, a PPDU 1404 is transmitted from an OBSS relative to the BSS of which STA 1402 is a member. PPDU 1404 may comprise a U-SIG field. For example, PPDU 1404 may be an HE PPDU, an EHT PPDU, a UHR PPDU, or an ELR PPDU. For example, PPDU 1404 may comprise a legacy preamble (e.g., comprising an L-STF, L-LTF, L-SIG, RL-SIG, and U-SIG / HE- SIG-A) and a HE / EHT / UHR / ELR preamble (e.g., comprising an HE-SIG-B / EHT-SIG / UHR-SIG, an HE / EHT / UHR / ELR-STF and an HE / EHT / UHR / ELR-LTF).

[0119] Being a UHR STA, STA 1402 may receive / decode the U-SIG field of PPDU 1404. Specifically, STA 1402 may receive / decode the U-SIG field of PPDU 1404 to obtain a BSS color from a BSS color field of the U-SIG field. The BSS color indicates the color of the BSS of which the STA transmitting PPDU 1404 is a member. In example 1400, based on PPDU 1404 being transmitted from an OBSS relative to the BSS of STA 1402, STA 1402 determines from the BSS color that PPDU 1404 is an OBSS (or inter-BSS PPDU). Additionally, STA 1402 may receive / decode the U-SIG field of PPDU 1404 to obtain a TXOP duration from a TXOP field of the U-SIG field. As shown in FIG. 14, the TXOP duration indicated in the TXOP field of the U- SIG field of PPDU 1404 may extend at least until an end of PPDU 1404 (in example 1400, the TXOP duration extends beyond PPDU 1404). STA 1402 sets its NAV based on the TXOP duration indicated in PPDU 1404. This TXOP duration is interchangeably referred to herein as OBSS NAV duration or OBSS TXOP duration.

[0120] In accordance with the supported NPCA operation, STA 1402 may be configured to switch from the PCH to the NPCA PCH after receiving / decoding the U-SIG field of a received PPDU and determining that the PPDU is an OBSS PPDU based on the BSS color field of the U-SIG field and obtaining the OBSS NAV (or TXOP) duration from the TXOP field of the U-SIG field. As such, in example 1400, after receiving / decoding the U-SIG field of PPDU 1404, STA 1402 switches from the PCH to the NPCA PCH.

[0121] In an example, after switching from the PCH to the NPCA PCH, and during the OBSS NAV (or TXOP) duration, STA 1402 may exchange (transmit / receive) an initial control frame (ICF) 1406 and (receive / transmit) an initial control response (ICR) 1408 with another STA of its BSS, before exchanging (transmitting / receiving) a data frame 1410 (and an associated BA frame 1412) with the other STA. STA 1402 may return to the PCH by the end of OBSS NAV (or TXOP) duration.Docket No.: 24-3048PCT

[0122] A problem, however, may arise in the above-described NPCA operation when PPDU 1404 is an ELR PPDU. In an implementation, the BSS color field of the U-SIG field of PPDU 1404 is used to indicate allowance or prohibition of spatial reuse with PPDU 1404, when PPDU 1404 is an ELR PPRU. The BSS color field of the U-SIG field of PPDU 1404 thus may not convey the actual BSS color of PPDU 1404 when PPDU 1404 is an ELR PPDU. In such cases, STA 1402 may not be able to determine whether PPDU 1404 is an OBSS PPDU in accordance with the supported NPCA operation. STA 1402 may thus remain on the PCH and may lose the opportunity to communicate on the NPCA PCH during the OBSS NAV (or TXOP) duration indicated by PPDU 1404. Low latency traffic at STA 1402 may be lost or discarded due to the inability of STA 1402 to communicate on the NPCA PCH during the OBSS NAV (or TXOP) duration.

[0123] Embodiments of the present disclosure, as further described below, address the above-described problem of existing technologies. In an aspect, a STA (AP STA or non-AP STA) may be configured to switch from the PCH to the NPCA PCH after receiving / decoding a portion of a first preamble of a PPDU received via the PCH. The first preamble may follow a second preamble of the PPDU. In an embodiment, the first preamble may be an ELR (or an HE / EHT / UHR) preamble, and the second preamble may be a legacy preamble (or non-ELR preamble). In an embodiment, the PPDU may be an ELR PPDU (or an HE / EHT / UHR PPDU). In an embodiment, the STA may be configured to switch from the PCH to the NPCA PCH based on a BSS color, indicated in the portion of the first preamble, indicating that the PPDU comprises an inter-BSS PPDU. In an embodiment, the STA may be configured to receive / decode the portion of the first preamble based on failing to identify the BSS color from the second preamble of the PPDU. The BSS color identifies a BSS of which a STA that transmits the PPDU is a member. In an embodiment, where the PPDU is an ELR PPDU, the portion may comprise one or more of: an ELR-Mark field, an ELR-STF, an ELR-LTF, and an ELR- SIG field of an ELR preamble of the ELR PPDU.

[0124] FIG. 15 shows an example 1500 that illustrates an example NPCA operation according to an embodiment. Example 1500 is provided for the purpose of illustration only and is not limiting of embodiments. As shown in FIG. 15, example 1500 includes a STA 1502, which may be an AP STA or a non-AP STA. STA 1502 may be a UHR STA. STA 1502 may operate over a plurality of channels, including a PCH, an NPCA PCH, a first secondary channel (SCH1 ), and a second secondary channel (SCH2). Additionally, STA 1502 may support the NPCA operation described in FIG. 15, which includes switching from the PCH to the NPCA PCH after receiving / decoding a portion of a first preamble of an (OBSS) PPDU received via the PCH, where the first preamble follows a second preamble of the PPDU. The PPDU may be an ELR PPDU (or an HE / EHT / UHR PPDU). As such, the first preamble may be an ELR (or an HE / EHT / UHR) preamble, and the second preamble may be a legacy preamble / non-ELR preamble (e.g., as shown in FIG. 10). In an embodiment, where the PPDU is an ELR PPDU, the first preamble may be an ELR preamble and the portion of the first preamble may comprise one or more of: an ELR-Mark field (e.g., ELR-Mark-1 , ELR-Mark-2), an ELR-STF, an ELR-LTF, and an ELR-SIG field of the ELR preamble. The legacy preamble may comprise oneDocket No.: 24-3048PCT or more of: an L-STF, an L-LTF, an L-SIG field, an RL-SIG field, and a U-SIG field. In an embodiment, STA 1502 may be configured not to receive / decode a remaining portion of the first preamble of the PPDU and to switch from the PCH to the NPCA (immediately) after receiving / decoding the portion of the first preamble.

[0125] In an embodiment, in accordance with the supported NPCA operation, STA 1502 may be configured to receive / decode the second preamble (e.g., legacy preamble) of the PPDU being received via the PCH. In an embodiment, STA 1502 may be configured to obtain a BSS color of the PPDU from a BSS color field of a U-SIG field of the second preamble. In embodiment, STA 1502 may additionally be configured to obtain a TXOP duration from a TXOP field of the U-SIG field of the second preamble. In an embodiment, STA 1502 may be configured to receive / decode the portion of the first preamble of the PPDU based on failing to identify the BSS color from the second preamble and / or based on failing to obtain the TXOP duration from the second preamble. In embodiment, STA 1502 may fail to obtain the BSS color from the second preamble due to the BSS color field of the U-SIG field of the second preamble being set to a special value (e.g., 0) that does not convey the BSS color of the PPDU. For example, where the PPDU is an ELR PPDU, the BSS color field of the U-SIG field may be used to indicate whether spatial reuse is allowed / prohibited with the ELR PPDU. In another embodiment, STA 1502 may fail to obtain the BSS color from the second preamble due to failing to receive / decode one or more fields of the second preamble. For example, where the second preamble is a legacy preamble, the one or more fields may include at least one of the L-SIG, RL-SIG, and U-SIG of the legacy preamble. In an embodiment. STA 1502 may fail to obtain the TXOP duration from the second preamble due to the TXOP field of the U-SIG field of the second preamble being set to the value UNSPECIFIED. In another embodiment, STA 1502 may fail to obtain the TXOP duration from the second preamble due to failing to receive / decode one or more fields of the second preamble. For example, where the second preamble is a legacy preamble, the one or more fields may include at least one of the L-SIG, RL- SIG, and U-SIG of the legacy preamble. In an embodiment, STA 1502 may be configured to obtain the BSS color and / or the TXOP duration from the decoded portion of the first preamble of the PPDU. In an embodiment, STA 1502 may be configured to obtain the BSS color from an ELR-Mark-1 field and / or an ELR- Mark-2 field of the first preamble. In an embodiment, STA 1502 may be configured to obtain the TXOP duration from an ELR-SIG field of the first preamble.

[0126] In an embodiment, STA 1502 may be configured to determine that the PPDU comprises an OBSS (or inter-BSS) PPDU based on receiving the PPDU from a STA that does not belong to a BSS of STA 1502. Specifically, STA 1502 may determine that the PPDU is an inter-BSS PPDU based on a BSS color field (in the U-SIG field of the second preamble of the PPDU or in the first portion (e.g., ELR-Mark-1 and / or ELR- Mark-2) of the first preamble) indicating a first BSS color (or a first BSSID) different than a second BSS color (or a second BSSID) of STA 1502.

[0127] Returning to FIG. 15, example 1500 begins with a PPDU 1504 being transmitted on the PCH. PPDU 1504 may be transmitted by a STA that does not belong to the BSS of STA 1502. As such, PPDU 1504 is anDocket No.: 24-3048PCTOBSS (or inter-BSS) PPDU for STA 1502. In example 1500, PPDU 1504 is an ELR PPDU. As depicted, PPDU 1504 may comprise a legacy preamble, an ELR preamble, a data portion, and a packet extension (PE). As STA 1502 operates on the PCH, STA 1502 may detect / sense the transmission of PPDU 1504 and may begin to decode (read, detect, process, parse, or receive) PPDU 1504. In example 1500, STA 1502 may be configured to decode the legacy preamble and a portion of the ELR preamble of PPDU 1504. Based on determining that PPDU 1504 is an inter-BSS PPDU, and after decoding the portion of the ELR preamble, STA 1502 may be configured to switch from the PCH to the NPCA PCH. In example 1500, the portion of the ELR preamble includes an ELR-Mark-1 field (and, optionally, an ELR-Mark-2 field) of the ELR preamble. As such, after determining that PPDU 1504 is an inter-BSS PPDU, and after decoding the ELR-Mark-1 field (and, optionally, the ELR-Mark-2 field) of the ELR preamble, STA 1502 switches from the PCH to the NPCA PCH. In an implementation, STA 1502 does not decode a remaining portion (e.g., ELR-STF, ELR-LTF, and ELR-SIG) of the ELR preamble and / or the data portion and the PE of PPDU 1504.

[0128] In an example, STA 1502 may determine that PPDU 1504 is an inter-BSS PPDU after decoding the BSS color field of the U-SIG field of the legacy preamble of PPDU 1504. In another example, STA 1502 may fail to obtain the BSS color from the BSS color field of the U-SIG field of the legacy preamble and, instead, may determine that PPDU 1504 is an inter-BSS PPDU after decoding the ELR-Mark-1 field (and, optionally, the ELR-Mark-2 field) of the ELR preamble.

[0129] After switching from the PCH to the NPCA PCH, and during the TXOP duration obtained from the U- SIG field of the legacy preamble of PPDU 1504, STA 1502 may exchange (transmit / receive) an ICF 1506 and (receive / transmit) an ICR 1508 with another STA of its BSS, before exchanging (transmitting / receiving) a data frame 1510 (and an associated BA frame 1512) with the other STA. In example 1500, STA 1502 obtains the TXOP duration from the U-SIG field of PPDU 1504. STA 1502 may thus remain on the NPCA PCH for the TXOP duration. STA 1502 may return to the PCH by the end of the TXOP duration.

[0130] In another embodiment (not illustrated in FIG. 15), STA 1502 may be configured to decode the legacy preamble, and to decode a portion of the ELR preamble of PPDU 1504 on condition of the BSS color field of the U-SIG field of the legacy preamble not indicating the BSS color of PPDU 1504 (e.g., the BSS color field set to a special value, such as 0). As such, where STA 1502 decodes the legacy preamble and identifies the BSS color of PPDU 1504 from the U-SIG field of the legacy preamble, STA 1502 may switch from the PCH to the NPCA PCH after decoding the U-SIG field (and determining that PPDU 1504 is an inter-BSS PPDU). Alternatively, where STA 1502 decodes the legacy preamble and cannot identify the BSS color of PPDU 1504 from the U-SIG field of the legacy preamble, STA 1502 may proceed to decode the portion of the ELR preamble of the PPDU 1504 and may switch from the PCH to the NPCA PCH after decoding the portion of the ELR preamble (and determining that PPDU 1504 is an inter-BSS PPDU). The portion of the ELR preamble may include the ELR-Mark-1 field (and, optionally, the ELR-Mark-2 field) of the ELR preamble. In another embodiment, STA 1502 may be configured to decode the portion of the ELR preamble of PPDUDocket No.: 24-3048PCT1504 on the further condition of the TXOP field of the U-SIG field of the legacy preamble not being set to the value UNSPECIFIED (i.e., that STA 1502 is able to determine the TXOP duration of PPDU 1504 from the U- SIG field of the legacy preamble).

[0131] In an example, STA 1502 may obtain a TXOP duration from a TXOP field of the U-SIG field of the legacy preamble of PPDU 1504. In another example, STA 1502 may obtain a length of PPDU 1504 from a LENGTH subfield of the L-SIG field of the legacy preamble of PPDU 1504. STA 1502 may thus determine a time duration to operate on the NPCA PCH before returning to the PCH. However, in some cases, STA 1502 may not receive or may not be able to decode one or more fields of the legacy preamble of PPDU 1504. For example, STA 1502 may not receive or may not be able to decode the L-SIG, the RL-SIG, and / or the U-SIG of PPDU 1504. In such cases, although STA 1502 may decode the portion of the ELR preamble to determine that PPDU 1504 is an inter-BSS PPDU, STA 1502 cannot obtain the TXOP duration or the PPDU length of PPDU 1504. In an implementation, STA 1502 may refrain from switching from the PCH to the NPCA PCH unless STA 1502 determines the TXOP duration or the PPDU length of PPDU 1504. STA 1402 may thus remain on the PCH and may lose the opportunity to communicate on the NPCA PCH during the TXOP duration of PPDU 1504. Further embodiments, as further described below, address this potential problem.

[0132] FIG. 16 shows an example 1600 that illustrates another example NPCA operation according to an embodiment. Example 1600 is provided for the purpose of illustration only and is not limiting of embodiments. As shown in FIG. 16, example 1600 includes STAs 1602 and 1604, each of which may be an AP STA or a non-AP STA. STAs 1602 and 1604 may belong to the same BSS; for example, STA 1602 may be an AP STA, and STA 1604 may be a non-AP STA associated with STA 1602, or vice versa. STAs 1602 and 1604 may be UHR STAs. STAs 1602 and 1604 may operate over a plurality of channels, including a PCH, an NPCA PCH, a first secondary channel (SCH1), and a second secondary channel (SCH2). Additionally, STAs 1602 and 1604 may support the NPCA operation described above in FIG. 15, which includes switching from the PCH to the NPCA PCH after receiving / decoding a portion of an ELR preamble of an ELR (OBSS) PPDU received via the PCH. In example 1600, the portion of the ELR preamble may include the ELR-Mark-1 field (and, optionally, the ELR-Mark-2 field) of the ELR preamble.

[0133] In an embodiment, STA 1602 (or STA 1604) may be further configured, when STA 1602 (or STA 1604) determines the TXOP duration (and / or the length of the PPDU) from the U-SIG field of the legacy preamble of the ELR PPDU, to transmit a frame via the NPCA PCH indicating the TXOP duration (and / or the length of the PPDU) after switching from the PCH to the NPCA PCH. In an embodiment, STA 1602 (or STA 1604) may perform transmission of the frame indicating the TXOP duration (and / or the length of the PPDU) when STA 1602 (or STA 1604) is an AP STA. In another embodiment, STA 1602 (or STA 1604) may perform transmission of the frame indicating the TXOP duration (and / or the length of the PPDU) regardless of whether STA 1602 (or STA 1604) is an AP STA.Docket No.: 24-3048PCT

[0134] Example 1600 begins with a PPDU 1606 being transmitted on the PCH. PPDU 1606 may be transmitted by a STA that does not belong to the BSS of STAs 1602 and 1604. As such, PPDU 1606 is an OBSS (or inter-BSS) PPDU for STAs 1602 and 1604. In example 1600, PPDU 1606 is an ELR PPDU. As depicted, PPDU 1606 may comprise a legacy preamble, an ELR preamble, a data portion, and a PE. As STAs 1602 and 1604 operate on the PCH, STAs 1602 and 1604 may detect / sense the transmission of PPDU 1606 and may begin to decode (read, detect, process, parse, or receive) PPDU 1606. In example 1600, STA 1602 receives the U-SIG field of the legacy preamble of PPDU 1606 and decodes the (e.g., TXOP field of the) U-SIG field to determine a TXOP duration of PPDU 1606. In contrast, STA 1604 may not receive the U- SIG field of the legacy preamble of PPDU 1606 or may fail to decode the (e.g., TXOP field of the) U-SIG field of the legacy preamble of PPDU 1606. As such, STA 1604 does not determine the TXOP duration of PPDU 1606. Both STAs 1602 and 1604 determine that PPDU 1606 is an inter-BSS PPDU and switch from the PCH to the NPCA PCH after receiving / decoding the ELR-Mark-1 field (and, optionally, the ELR-Mark-2 field) of the ELR preamble of PPDU 1606.

[0135] On switching to the NPCA PCH, STA 1602 transmits a frame 1608 indicating a remaining duration until an end time of the TXOP duration or the end time of the TXOP duration. Frame 1608 may comprise an initial control frame (ICF), a request-to-send (RTS) frame, a multi-user (MU)-RTS trigger frame, a buffer status report poll (BSRP) trigger frame, a blockack request (BAR) frame, a MU-BAR trigger frame, a trigger frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0136] On receiving frame 1608, STA 1604 may determine the end time of the TXOP duration. In an embodiment, STA 1604 may transmit a frame 1610 to STA 1602 in response to frame 1608. Frame 1610 may comprise an initial control response frame (ICR), a clear-to-send (CTS) frame, a blockack (BA) frame, a multi-STA BA frame, a buffer status report (BSR) frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0137] Subsequently, with both STAs 1602 and 1604 having information regarding the end time of the TXOP duration, STAs 1602 and 1604 may exchange one or more frames before the end time of the TXOP duration. For example, STA 1602 may transmit a data frame 1612 to STA 1604, and STA 1604 may respond with a BA frame 1614 to STA 1602. STAs 1602 and 1604 may return to the PCH by the end of the TXOP duration.

[0138] In another embodiment, STA 1602 may receive the L-SIG field of the legacy preamble of PPDU 1606 and may decode the (e.g., LENGTH field of the) L-SIG field to determine a length of PPDU 1606. After switching to the NPCA PCH, STA 1602 may indicate a duration (length) of PPDU 1606, a remaining duration until an end time of PPDU 1606, or the end time of PPDU 1606 in frame 1608. In an embodiment, STA 1602 may indicate the duration (length) of PPDU 1606, the remaining duration until the end time of PPDU 1606, or the end time of PPDU 1606 based on failing to decode the U-SIG field to determine the TXOP duration of PPDU 1606. On receiving frame 1608, STA 1604 may determine the end time of PPDU 1606. Subsequently, with both STAs 1602 and 1604 having information regarding the end time of PPDU 1606, STAs 1602 andDocket No.: 24-3048PCT1604 may exchange one or more frames before the end time of PPDU 1606. STAs 1602 and 1604 may return to the PCH by the end of PPDU 1606.

[0139] In another embodiment, when STA 1604 determines the TXOP duration and / or the length of PPDU 1606 based on the legacy preamble of PPDU 1606, STA 1604 may indicate in frame 1610 the same information as described above for frame 1608.

[0140] FIG. 17 shows an example 1700 that illustrates another example NPCA operation according to an embodiment. Example 1700 is provided for the purpose of illustration only and is not limiting of embodiments. In example 1700, STA 1602 does not receive the U-SIG field of the legacy preamble of PPDU 1606 or may fail to decode the (e.g., TXOP field of the) U-SIG field of the legacy preamble of PPDU 1606. As such, STA 1604 does not determine the TXOP duration of PPDU 1606. In contrast, STA 1604 receives the U-SIG field of the legacy preamble of PPDU 1606 and decodes the (e.g., TXOP field of the) U-SIG field to determine the TXOP duration of PPDU 1606. Both STAs 1602 and 1604 determine that PPDU 1606 is an inter-BSS PPDU and switch from the PCH to the NPCA PCH after receiving / decoding the ELR-Mark-1 field (and, optionally, the ELR-Mark-2 field) of the ELR preamble of PPDU 1606.

[0141] After switching to the NPCA PCH, STA 1602 transmits a frame 1702 indicating that STA 1602 does not know the remaining duration until the end time of the TXOP duration of PPDU 1606 (and requesting the remaining duration). Frame 1702 may comprise an initial control frame (ICF), a request-to-send (RTS) frame, a multi-user (MU)-RTS trigger frame, a buffer status report poll (BSRP) trigger frame, a blockack request (BAR) frame, a MU-BAR trigger frame, a trigger frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0142] On receiving frame 1702, STA 1604 may transmit to STA 1602 a frame 1704 indicating the remaining duration until the end time of the TXOP duration or indicating the end time of the TXOP duration. Frame 1704 may comprise an initial control response frame (ICR), a clear-to-send (CTS) frame, a blockack (BA) frame, a multi-STA BA frame, a buffer status report (BSR) frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0143] Subsequently, with both STAs 1602 and 1604 having information regarding the end time of the TXOP duration, STAs 1602 and 1604 may exchange one or more frames before the end time of the TXOP duration. For example, STA 1602 may transmit a data frame 1706 to STA 1604, and STA 1604 may respond with a BA frame 1708 to STA 1602. STAs 1602 and 1604 may return to the PCH by (or before) the end of the TXOP duration

[0144] In another embodiment (not shown in FIG. 17), STA 1602 may receive the L-SIG field of the legacy preamble of PPDU 1606 and may determine a length of PPDU 1606 based on a LENGTH subfield of the L- SIG field of the legacy preamble. STA 1602 may indicate in frame 1702 a duration (length) of PPDU 1606, a remaining duration until an end time of PPDU 1606, or the end time of PPDU 1606 in frame 1608. STA 1602 may further indicate in frame 1702 that STA 1602 does not know the remaining duration until the end time ofDocket No.: 24-3048PCT the TXOP duration of PPDU 1606. On receiving frame 1702, STA 1604 may respond with frame 1704 described above.

[0145] In a further embodiment (not shown in FIG. 17), STA 1602 may fail to receive both the L-SIG field and the U-SIG field of the legacy preamble and may thus not determine both the TXOP duration and the length of PPDU 1606. STA 1602 may indicate in frame 1702 that STA 1602 does not know the remaining duration until the end time of the TXOP duration of PPDU 1606 and / or the remaining duration until the end time of PPDU 1606. On receiving frame 1702, STA 1604 may respond with frame 1704 indicating, if STA 1604 determined the TXOP duration, the remaining duration until the end time of the TXOP duration or the end time of the TXOP duration; and if STA 1604 did not determine the TXOP duration but determined the length of PPDU 1606, the remaining duration until an end time of PPDU 1606 or the end time of PPDU 1606.

[0146] FIG. 18 shows an example 1800 that illustrates another example NPCA operation according to an embodiment Example 1800 is provided for the purpose of illustration only and is not limiting of embodiments. In example 1800, both STAs 1602 and 1604 fail to determine both the TXOP duration and the length of PPDU 1606. For example, both STAs 1602 and 1604 may fail receive both the L-SIG field and the U-SIG field of the legacy preamble of PPDU 1606. After switching from the PCH to the NPCA PCH after receiving / decoding the portion (e.g., ELR-Mark-1 and, optionally, ELR-Mark-2) of the ELR preamble of PPDU 1606, STA 1602 / 1604 may be configured to transmit a frame indicating that STA 1602 / 1604 does not know the remaining duration until the end time of the TXOP duration and / or the remaining duration until the end time of PPDU 1606.

[0147] As such, in example 1800, STA 1602 transmits a frame 1802 indicating that STA 1602 does not know the remaining duration until the end time of the TXOP duration and / or the remaining duration until the end time of PPDU 1606 (and requesting the remaining duration). Frame 1802 may comprise an initial control frame (ICF), a request-to-send (RTS) frame, a multi-user (MU)-RTS trigger frame, a buffer status report poll (BSRP) trigger frame, a blockack request (BAR) frame, a MU-BAR trigger frame, a trigger frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame. Similarly, e.g., in response to frame 1802, STA 1604 transmits a frame 1804 indicating that STA 1604 does not know the remaining duration until the end time of the TXOP duration and / or the remaining duration until the end time of PPDU 1606 (and requesting the remaining duration). Frame 1804 may comprise an initial control response frame (ICR), a clear-to-send (CTS) frame, a blockack (BA) frame, a multi-STA BA frame, a buffer status report (BSR) frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0148] In an embodiment, after exchanging frames 1802 and 1804 indicating that neither STA has knowledge of a remaining time duration (e.g., remaining duration of the TXOP duration or remaining duration of PPDU 1606), STAs 1602 and 1604 may be configured to return to the PCH. As such, in example 1800, STAs 1602 and 1604 may return to the PCH after completing the exchange of frames 1802 and 1804.Docket No.: 24-3048PCT

[0149] In another embodiment, illustrated in example 1900 of FIG. 19, after exchanging frames 1802 and 1804 indicating that neither STA has knowledge of a remaining time duration (e.g . , remaining duration of the TXOP duration or remaining duration of PPDU 1606), STAs 1602 and 1604 may be configured to remain on the NPCA PCH for a first time period before returning to the PCH. As such, in example 1900, STAs 1602 and 1604 remain on the NPCA PCH for a first time period after exchanging frames 1802 and 1804. During the first time period, STAs 1602 and 1604 may exchange one or more frames. For example, STA 1602 may transmit a data frame 1902 to STA 1604, and STA 1604 may respond with a BA frame 1904 to STA 1602. STAs 1602 and 1604 may return to the PCH by the end of the first time period.

[0150] In another embodiment, illustrated in example 2000 of FIG. 20, after exchanging frames 1802 and 1804 with STA 1604 indicating that neither STA 1602 nor STA 1604 has knowledge of a remaining time duration (e.g., remaining duration of the TXOP duration and / or remaining duration of PPDU 1606), STA 1602 (e.g , when STA 1602 is an AP STA) may be configured to transmit a frame 2004 to another STA 2002 to obtain the remaining time duration (e.g., remaining duration of the TXOP duration and / or remaining duration of PPDU 1606). Frame 2004 may comprise an initial control frame (ICF), a request-to-send (RTS) frame, a multi-user (MU)-RTS trigger frame, a buffer status report poll (BSRP) trigger frame, a blockack request (BAR) frame, a MU-BAR trigger frame, a trigger frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0151] On receiving frame 2004 from STA 1602, and based on having knowledge of the remaining time duration (e.g., remaining duration of the TXOP duration or remaining duration of PPDU 1606), STA 2002 may transmit to STA 1602 a frame 2006 indicating the remaining time duration. Frame 2006 may comprise an initial control response frame (ICR), a clear-to-send (CTS) frame, a blockack (BA) frame, a multi-STA BA frame, a buffer status report (BSR) frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0152] Subsequently, with both STAs 1602 and STA 2002 having information regarding the remaining time duration (e.g., remaining duration of the TXOP duration and / or remaining duration of PPDU 1606), STAs 1602 and 2002 may exchange one or more frames before the end time of the remaining time duration. For example, STA 1602 may transmit a data frame 2008 to STA 2002, and STA 2002 may respond with a BA frame 2010 to STA 1602. STAs 1602 and 2002 may return to the PCH by the end of the remaining time duration.

[0153] In an embodiment, after the exchange of frames 1802 and 1804 with STA 1602, STA 1604 (e g., when STA 1604 is a non-AP STA) may be configured to return to the PCH. Alternatively, STA 1604 may remain on the NPCA PCH and may determine the remaining time duration based on frame 2006 transmitted by STA 2002 or a subsequent frame transmitted by STA 1602.

[0154] In another embodiment, illustrated in example 2100 of FIG. 21 , after switching to the NPCA PCH without having determined a remaining time duration (e.g., remaining duration of the TXOP duration orDocket No.: 24-3048PCT remaining duration of PPDU 1606), STA 1602 may be configured to transmit a multi-user (MU) frame 2104 indicating that STA 1602 does not know the remaining duration until the end time of the TXOP duration or the remaining duration until the end time of PPDU 1606 (and requesting the remaining duration). In an embodiment, frame 2104 may be an MU-ICF. In an embodiment, frame 2104 may be addressed to multiple STAs, such as STA 1604 and a STA 2102. In an embodiment, frame 2104 may be transmitted over an aggregate channel comprising the NPCA PCH. For example, as shown in example 2100, frame 2104 may be transmitted over an aggregate channel comprising the NPCA PCH and SCH2. In an embodiment, frame 2104 may allocate a respective channel of the aggregate channel to each of the multiple STAs to use for transmitting a response frame to frame 2104. For example, in example 2100, frame 2104 allocates the NPCA PCH to STA 2102 and SCH2 to STA 1604.

[0155] On receiving frame 2104, STA 1604 transmits a frame 2106 via SCH2 to STA 1602. Frame 2106 may comprise an ICR. In example 2100, STA 1604 did not receive or failed to decode the U-SIG of the legacy preamble of PPDU 1606. As such, STA 1604 may indicate in frame 2106 that STA 1604 does not know does not know the remaining duration until the end time of the TXOP duration and / or the remaining duration until the end time of PPDU 1606.

[0156] On receiving frame 2104, STA 1604 transmits a frame 2106 via SCH2 to STA 1602. Frame 2106 may comprise an initial control response frame (ICR), a clear-to-send (CTS) frame, a blockack (BA) frame, a multi-STA BA frame, a buffer status report (BSR) frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0157] . In example 2100, STA 1604 did not receive or failed to decode the U-SIG of the legacy preamble of PPDU 1606. As such, STA 1604 may indicate in frame 2106 that STA 1604 does not know does not know the remaining duration until the end time of the TXOP duration and / or the remaining duration until the end time of PPDU 1606. In an embodiment, STA 1604 may remain on the NPCA PCH after transmitting frame 2106 or may return to the PCH.

[0158] On receiving frame 2104 from STA 1602, and based on having knowledge of the remaining time duration (e.g., remaining duration of the TXOP duration and / or remaining duration of PPDU 1606), STA 2102 may transmit to STA 1602 via the NPCA PCH a frame 2108 indicating the remaining time duration. Frame 2108 may comprise an initial control response frame (ICR), a clear-to-send (CTS) frame, a blockack (BA) frame, a multi-STA BA frame, a buffer status report (BSR) frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0159] Subsequently, with STA 1602 having information regarding the remaining time duration (e.g., remaining duration of the TXOP duration or remaining duration of PPDU 1606), STAs 1602 may exchange one or more frames with STAs 1604 and 2102 before the end time of the remaining time duration. For example, STA 1602 may transmit to STAs 1604 and 2102 a PPDU 21 10 via the aggregate channel (e.g., using an OFDMA PPDU or MU-MIMO) comprising the NPCA PCH and SCH2. PPDU 21 10 may comprise aDocket No.: 24-3048PCT data frame 2112 for STA 1604 transmitted via a first resource unit corresponding to SCH2, and a data frame 2114 for STA 2102 transmitted via a second resource unit corresponding to the NPCA PCH. In an embodiment, data frame 2112 may indicate the remaining time duration to STA 1604. STAs 1604 and 2102 may respond to data frames 21 12 and 2114 respectively with respective BA frames. STAs 1602, 1604, and 2102 may return to the PCH by the end of the remaining time duration.

[0160] FIG. 22 shows an example 2200 that illustrates another example NPCA operation according to an embodiment. Example 2200 is provided for the purpose of illustration only and is not limiting of embodiments. As shown in FIG. 22, example 2200 includes a STA 2202, which may be an AP STA or a non-AP STA. STA 2202 may be a UHR STA. STA 2202 may operate over a plurality of channels, including a PCH, an NPCA PCH, a first secondary channel (SCH1 ), and a second secondary channel (SCH2). Additionally, STA 2202 may support the NPCA operation described in FIG. 22, which includes switching from the PCH to the NPCA PCH after receiving / decoding a portion of a first preamble of an (OBSS) PPDU received via the PCH, where the first preamble follows a second preamble of the PPDU. The PPDU may be an ELR PPDU (or an HE / EHT / UHR PPDU). As such, the first preamble may be an ELR (or an HE / EHT / UHR) preamble, and the second preamble may be a legacy preamble (e.g ., as shown in FIG. 10). In an embodiment, where the PPDU is an ELR PPDU, the first preamble may be an ELR preamble and the portion of the first preamble may comprise an ELR-Mark field (e.g., ELR-Mark-1 , ELR-Mark-2), an ELR-STF, an ELR-LTF, and an ELR-SIG field of the ELR preamble. The legacy preamble may comprise one or more of: an L-STF, an L-LTF, an L- SIG field, an RL-SIG field, and a U-SIG field.

[0161] In an embodiment, in accordance with the supported NPCA operation, STA 2202 may be configured to receive / decode the second preamble (e.g., legacy preamble) of the PPDU being received via the PCH In an embodiment, STA 2202 may be configured to obtain a BSS color of the PPDU from a BSS color field of a U-SIG field of the second preamble. In embodiment, STA 2202 may additionally be configured to obtain a TXOP duration from a TXOP field of the U-SIG field of the second preamble. In an embodiment, STA 2202 may be configured to receive / decode the portion of the first preamble of the PPDU based on failing to identify the BSS color from the second preamble and / or based on failing to obtain the TXOP duration from the second preamble. In embodiment, STA 2202 may fail to obtain the BSS color from the second preamble due to the BSS color field of the U-SIG field of the second preamble being set to a special value (e.g., 0) that does not convey the BSS color of the PPDU. For example, where the PPDU is an ELR PPDU, the BSS color field of the U-SIG field may be used to indicate whether spatial reuse is allowed / prohibited with the ELR PPDU In another embodiment, STA 2202 may fail to obtain the BSS color from the second preamble due to failing to receive / decode one or more fields of the second preamble. For example, where the second preamble is a legacy preamble, the one or more fields may include at least one of the L-SIG, RL-SIG, and U-SIG of the legacy preamble. In an embodiment. STA 2202 may fail to obtain the TXOP duration from the second preamble due to the TXOP field of the U-SIG field of the second preamble being set to the valueDocket No.: 24-3048PCTUNSPECIFIED. In another embodiment, STA 2202 may fail to obtain the TXOP duration from the second preamble due to failing to receive / d ecode one or more fields of the second preamble. For example, where the second preamble is a legacy preamble, the one or more fields may include at least one of the L-SIG, RL- SIG, and U-SIG of the legacy preamble. In an embodiment, STA 2202 may be configured to obtain the BSS color and / or the TXOP duration from the decoded portion of the first preamble of the PPDU. In an embodiment, STA 2202 may be configured to obtain the BSS color from an ELR-Mark-1 field and / or an ELR- Mark-2 field of the first preamble. In an embodiment, STA 2202 may be configured to obtain the TXOP duration from an ELR-SIG field of the first preamble.

[0162] In an embodiment, STA 2202 may be configured to determine that the PPDU comprises an OBSS (or inter-BSS) PPDU based on receiving the PPDU from a STA that does not belong to a BSS of STA 2202. Specifically, STA 2202 may determine that the PPDU is an inter-BSS PPDU based on a BSS color field (in the U-SIG field of the second preamble of the PPDU or in the first portion (e.g., ELR-Mark-1 and / or ELR- Mark-2) of the first preamble) indicating a first BSS color (or a first BSSID) different than a second BSS color (or a second BSSID) of STA 2202.

[0163] Returning to FIG. 22, example 2200 begins with a PPDU 2204 being transmitted on the PCH. PPDU 2204 may be transmitted by a STA that does not belong to the BSS of STA 2202. As such, PPDU 2204 is an OBSS (or inter-BSS) PPDU for STA 2202. In example 2200, PPDU 2204 is an ELR PPDU. As depicted, PPDU 2204 may comprise a legacy preamble, an ELR preamble, a data portion, and a packet extension (PE). As STA 2202 operates on the PCH, STA 2202 may detect / sense the transmission of PPDU 2204 and may begin to decode (read, detect, process, parse, or receive) PPDU 2204. In example 2200, STA 2202 may be configured to decode the legacy preamble and a portion of the ELR preamble of PPDU 2204. Based on determining that PPDU 2204 is an inter-BSS PPDU, and after decoding the portion of the ELR preamble, STA 2202 may be configured to switch from the PCH to the NPCA PCH. In example 2200, the portion of the ELR preamble includes an ELR-Mark-1 field (and, optionally, an ELR-Mark-2 field), an ELR-STF, an ELR- LTF, and an ELR-SIG field of the ELR preamble. As such, after determining that PPDU 2204 is an inter-BSS PPDU, and after decoding the ELR-SIG field of the ELR preamble, STA 2202 switches from the PCH to the NPCA PCH. Decoding through the ELR-SIG field of the ELR preamble allows STA 2202 to determine the TXOP duration and / or the length of PPDU 2204 even when STA 2202 fails to decode the legacy preamble (or the L-SIG or U-SIG of the legacy preamble).

[0164] In an example, STA 2202 may determine that PPDU 2204 is an inter-BSS PPDU after decoding the BSS color field of the U-SIG field of the legacy preamble of PPDU 2204. In another example, STA 2202 may fail to obtain the BSS color from the BSS color field of the U-SIG field of the legacy preamble and, instead, may determine that PPDU 2204 is an inter-BSS PPDU after decoding the ELR-Mark-1 field (and, optionally, the ELR-Mark-2 field) of the ELR preamble.Docket No.: 24-3048PCT

[0165] After switching from the PCH to the NPCA PCH, and during the TXOP duration obtained from the U- SIG field of the legacy preamble of PPDU 2204 (or from the ELR-SIG of the ELR preamble), STA 2202 may exchange (transmit / receive) an ICF 2206 and (receive / transmit) an ICR 2208 with another STA of its BSS, before exchanging (transmitting / receiving) a data frame 2210 (and an associated BA frame 2212) with the other STA. In example 2200, STA 2202 obtains the TXOP duration from the U-SIG field of PPDU 2204 (or from the ELR-SIG field of PPDU 2204). STA 2202 may thus remain on the NPCA PCH for the TXOP duration. STA 2202 may return to the PCH by the end of the TXOP duration.

[0166] FIG. 23 shows an example 2300 that illustrates an example frame exchange according to an embodiment. Example 2300 is provided for the purpose of illustration only and is not limiting of embodiments. Example 2300 includes an AP 2302 and a STA 2304. AP 2302 may be an embodiment of STA 1602, for example. STA 2304 may be an embodiment of STA 1604, for example. As such, AP 2302 may be configured as described above with respect to STA 1602, and STA 2304 may be configured as described above with respect to STA 1604. Additionally, AP 2302 and STA 2304 may be configured to perform the frame exchange illustrated in FIG. 23, which may performed prior to AP 2302 and STA 2304 receiving an inter-BSS PPDU on the PCH. For example, the example frame exchange illustrated in FIG. 23 may be performed in examples 1600, 1700, 1800, 1900, 2000, and 2100 before STAs 1602 and 1604 receive / detect PPDU 1606.

[0167] As shown in FIG. 23, the example frame exchange may include AP 2302 transmitting a frame 2306 on the PCH. In an embodiment, frame 2306 may indicate support, by AP 2302, of an ELR NPCA switching operation. The ELR NPCA switching operation corresponds to the NPCA switching operation, as described above, used in conjunction with receiving an ELR PPDU by a STA. In an embodiment, frame 2306 may further indicate enablement / disablement (or (activation / deactivation) or (using / not using)), by AP 2302, of the ELR NPCA switching operation. In embodiments, the first frame may comprise a beacon frame, a fast initial link setup (FILS) discovery frame, a traffic indication map (TIM) broadcast frame, a broadcast probe response frame, a broadcast frame, a control frame, a management frame, an action frame, a quality of service (QoS) null frame, or a QoS data frame.

[0168] The example frame exchange may further include, before or after the transmission of frame 2306, STA 2304 transmitting a frame 2308 to AP 2302. In an embodiment, frame 2308 may indicate support, by STA 2304, of the ELR NPCA switching operation. In an embodiment, frame 2308 may further indicate enablement / disablement (or (activation / deactivation) or (using / not using)), by STA 2304, of the ELR NPCA switching operation. In an embodiment, where frame 2308 indicates enablement, by STA 2304, of the ELR NPCA switching operation, frame 2308 may further comprise a request to AP 2302 to enable the ELR NPCA switching operation by AP 2302. In embodiments, frame 2308 may comprise an individually addressed probe request frame, a broadcast addressed probe request frame, association request frame, request frame, control frame, management frame, action frame, quality of service (QoS) null frame, or QoS data frame.Docket No.: 24-3048PCT

[0169] The example frame exchange may further include, before or after the transmission of frame 2306, AP 2302 transmitting a frame 2310 to STA 2304. In an embodiment, frame 2310 may indicate support, by AP 2302, of the ELR NPCA switching operation. In an embodiment, frame 2310 may further indicate enablement / disablement (or (activation / deactivation) or (using / not using)), by AP 2302, of the ELR NPCA switching operation. Frame 2310 may be in response to frame 2308. In an embodiment, where frame 2308 comprises a request to AP 2302 to enable the ELR NPCA switching operation by AP 2302, frame 2310 may indicate acceptance / rejection of the request. In embodiments, frame 2310 may comprise an individually addressed probe response frame, association response frame, response frame, control frame, management frame, action frame, quality of service (QoS) null frame, or QoS data frame.

[0170] FIG. 24 illustrates an example process 2400 according to an embodiment. Example process 2400 is provided for the purpose of illustration only and is not limiting of embodiments. Example process 2400 may be performed by a first STA, such as STA 1502, STA 1602, STA 1604, STA 2202, AP 2302, or STA 2304. As shown in FIG. 24, example process 2400 may include steps 2402 and 2404. The first STA may be an AP STA or a non-AP STA.

[0171] Step 2402 includes receiving ( / decoding / detecting), by the first STA, a portion of a first preamble of a PPDU being received via a PCH. In an embodiment, the first preamble follows a second preamble of the PPDU.

[0172] Step 2404 includes, based on a BSS color, indicated in the portion, indicating that the PPDU comprises an inter-BSS PPDU, switching, by the first STA and after receiving the portion, from the PCH to an NPCA PCH. The BSS color identifies a BSS ofwhich a second STA that transmits the PPDU is a member. In an embodiment, the BSS color indicated in the portion does not match a value in a BSS_COLOR_LIST parameter of a PHYCONFIG VECTOR.

[0173] In an embodiment, the PPDU comprises an ELR PPDU.

[0174] In an embodiment, the first preamble comprises an ELR preamble. As such, the portion of the first preamble may comprise one or more of: an ELR-Mark field, an ELR-STF, an ELR ELR-LTF, and an ELR- SIG field of the ELR preamble.

[0175] In an embodiment, the second preamble comprises a legacy preamble. The second preamble may comprise one or more of: an L-STF, an L-LTF, an L-SIG field, an RL-SIG field, and a U-SIG field. The U-SIG may comprise one or more of: a PHY version identifier field, a bandwidth field, an uplink / downlink (UL / DL) field, a BSS color field, a transmission opportunity (TXOP) field, a disregard field, a validate field, a PPDU type and compression mode field, a punctured channel information field, an extremely high throughput signal (EHT-SIG) modulation and coding scheme (MCS) field, a number of EHT-SIG symbols field, a cyclic redundancy check (CRC) field, or a Tail field.

[0176] In an embodiment, the second preamble comprises a non-ELR preamble.Docket No.: 24-3048PCT

[0177] In an embodiment the receiving of the portion of the first preamble in step 2402 is based on the first STA failing to identify the BSS color from the second preamble of the PPDU.

[0178] In an embodiment, the STA failing to identify ( / obtain) the BSS color from the second preamble comprises the BSS color field of the U-SIG field of the second preamble having a special value. In an embodiment, the special value is equal to 0.

[0179] In an embodiment, the STA failing to identify ( / obtain) the BSS color from the second preamble comprises failing to receive at least one of the L-SIG, RL-SIG, and U-SIG of the second preamble.

[0180] In an embodiment, process 2400 further comprises receiving ( / detect! ng / decodi ng), by the first STA, one or more first fields of the second preamble. In an embodiment, the one or more first fields comprise at least one of the L-STF, the L-LTF, the L-SIG, the RL-SIG, or the U-SIG.

[0181] In an embodiment, process 2400 further comprises failing to receive ( / detect / decode), by the first STA, one or more second fields of the second preamble. In an embodiment, the one or more second fields comprise at least one of the L-STF, the L-LTF, the L-SIG, the RL-SIG, or the U-SIG.

[0182] In an embodiment, the TXOP field of the second preamble comprises / indicates a TXOP duration (or a network allocation vector (NAV) duration) for the PPDU. In an embodiment, process 2400 may further comprise obtaining, by the first STA, the TXOP duration (or the NAV duration) from the TXOP field of the second preamble.

[0183] In an embodiment, process 2400 may further comprise switching, by the first STA and after receiving the portion of the first preamble, from the PCH to the NPCA PCH.

[0184] In an embodiment, process 2400 may further comprise transmitting, by the first STA to a third STA and via the NPCA PCH, a first frame; and in response to the first frame, receiving, by the first STA from the third STA and via the NPCA PCH, a second frame.

[0185] In an embodiment, the first frame comprises an initial control frame (ICF), a request-to-send (RTS) frame, a multi-user (MU)-RTS trigger frame, a buffer status report poll (BSRP) trigger frame, a blockack request (BAR) frame, a MU-BAR trigger frame, a trigger frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0186] In an embodiment, the second frame comprises an initial control response frame (ICR), a clear-to- send (CTS) frame, a blockack (BA) frame, a multi-STA BA frame, a buffer status report (BSR) frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

[0187] In an embodiment, the first frame indicates a first value indicating a duration of the PPDU ( / PPDU length), a remaining duration until an end time of the PPDU, or the end time of the PPDU.

[0188] In an embodiment, the first frame indicates a second value indicating a TXOP duration (or a NAV duration) indicated in the PPDU, a remaining duration until an end time of a TXOP duration (or a NAV duration) indicated in the PPDU or the end time of the TXOP duration (the NAV duration) indicated by the PPDU.Docket No.: 24-3048PCT

[0189] In an embodiment, the first frame indicates whether the first STA has ( / knows) a duration of the PPDU (PPDU length, the remaining duration until an end time of the PPDU, or the end time of the PPDU) and / or a TXOP duration (or a NAV duration) indicated in the PPDU (or a remaining duration until an end time of a TXOP duration (or a NAV duration) indicated in the PPDU or the end time of the TXOP duration (the NAV duration) indicated by the PPDU).

[0190] In an embodiment, the second frame indicates a third value indicating a duration of the PPDU (PPDU length), a remaining duration until an end time of the PPDU, or the end time of the PPDU.

[0191] In an embodiment, the second frame indicates a fourth value indicating a TXOP duration (or a NAV duration) indicated in the PPDU, a remaining duration until an end time of a TXOP duration (or a NAV duration) indicated in the PPDU or the end time of the TXOP duration (the NAV duration) indicated by the PPDU.

[0192] In an embodiment, the second frame indicates whether the third STA has ( / knows) a duration of the PPDU (PPDU length, the remaining duration until an end time of the PPDU, or the end time of the PPDU) and / or a TXOP duration (or a NAV duration) indicated in the PPDU (or a remaining duration until an end time of a TXOP duration (or a NAV duration) indicated in the PPDU or the end time of the TXOP duration (the NAV duration) indicated by the PPDU).

[0193] In an embodiment, the third STA comprises a non-AP STA or an AP STA.

[0194] In an embodiment, process 2400 may further comprise, based on the first frame and / or the second frame, transmitting, by the first STA to the third STA and via the NPCA PCH, a third frame. In an embodiment, process 2400 may further comprise receiving, by the first STA from the third STA and via the NPCA PCH, a fourth frame.

[0195] In an embodiment, process 2400 may further comprise, based on the first frame and / or the second frame, switching ( / returning back), by the first STA, from the NPCA PCH to the PCH.

[0196] In an embodiment, process 2400 may further comprise, based on the first frame and / or the second frame, operating ( / camping / parking), by the first STA and during a first time duration, on the NPCA PCH.

[0197] In an embodiment the first time duration is decided / calculated / determined / set based on one or more of the first value, the second value, the third value, and the fourth value. In an embodiment, the first time duration is less than at least one of the first value, the second value, the third value, and the fourth value. In an embodiment, the first time duration equals at least one of the first value, the second value, the third value, and the fourth value.

[0198] In an embodiment, process 2400 may further comprise exchanging, by the first STA with the third STA and during the first time duration, one or more frames on the NPCA PCH. In an embodiment, process 2400 may further comprise exchanging by the first STA the first time duration with the third STA using one or more frames. The one or more frames comprises a management frame, a control frame, an action frame, a quality of service (QoS) null frame, or data frame.Docket No.: 24-3048PCT

[0199] In an embodiment the first frame is further transmitted to a fourth STA.

[0200] In an embodiment, process 2400 may further comprise, based on not receiving a response to the first frame from the third STA, transmitting, by the first STA and via the NPCA PCH, a fifth frame to a fourth STA. In an embodiment, the fifth frame is identical to the first frame.

[0201] Further, one or more embodiments described above in relation to FIGS. 15-24 may perform according to one or more examples described further below. For example, a UHR PHY entity may implement a receive procedure for decoding multiple PPDU formats, including a UHR multi-user (MU) PPDU, a UHR trigger-based (TB) PPDU, and a UHR extended long range (ELR) PPDU. Each PHY receive procedure may include receiving a preamble, performing a clear-channel assessment (CCA), and generating PHY-indication primitives to communicate channel and decoding state to the medium access control (MAC) entity.

[0202] In an example, when a PPDU is received, the PHY may first perform energy detection and may issue a PHY-CCA.indication(BUSY, channel-list) primitive to the MAC to indicate that the channel is busy. The PHY may then process training symbols, measure received signal strength, and attempt to identify a legacy long training field (L-LTF), followed by detection of the legacy signal (L-SIG) and repetition legacy signal (RL-SIG). Upon detection, the PHY may evaluate parity bits, rate fields, and length fields in L-SIG and RL-SIG to determine whether the PPDU duration can be predicted and whether an early signal indication is to be issued.

[0203] In an example, if a UHR STA detects a non-HT PHY PPDU format, the receive procedure may operate according to non-HT procedures. In another example, if the detected format indicates a high throughput (HT) PPDU format, the STA may utilize an HT receive procedure. In another example, if the detected format indicates a Very High Throughput (VHT) PPDU format, the STA may use a VHT receive procedure In another example, if the detected format indicates a High Efficiency (HE) PPDU format, the STA may utilize an HE receive procedure. In another example, if the detected format indicates an EHT PPDU format, the STA may use an EHT receive procedure. In an implementation, multiple receive procedures may operate in parallel (e.g., until the STA identifies a format and initiates a receive procedure).

[0204] In an example, if the UHR STA is ELR-capable, additional processing may be used. For example, when L-SIG, HT-SIG, VHT-SIG-A, HE-SIG-A, or U-SIG fields are invalid, an ELR-capable PHY may continue processing the PPDU and searching for an ELR-MARK sequence. A valid SIG field may refer to a valid CRC or parity check in a field whose contents have not caused the PPDU to be filtered out. An invalid SIG field may refer to a failed CRC or parity check or to a PPDU filtered out due to invalid content.

[0205] Prior to reception, the PHY may be configured via the physical layer management entity (PLME) with frequency, BS) identification information, and STA identification information, including BSS color and STAID, to enable filtering for PPDUs intended for the STA. Additional receive parameters such as received signal strength indicator (RSSI) and indicated data rate may be accessed through the PHY service access point (SAP).Docket No.: 24-3048PCT

[0206] In an example, upon reception of a PHY preamble in a BSS operating on 20 MHz or wider bandwidth, the PHY may measure a receive signal strength and indicate this measurement to the MAC using PHY- CCA. indication (e.g., PHY-CCA indication(BUSY, channel-list)). The channel-list parameter may be omitted for 20 MHz operation and present for 40 MHz, 80 MHz, 160 MHz, or 320 MHz operation.

[0207] In an example, the PHY may not issue PHY-RXEARLYSIG. indication nor PHY-RXSTART. indication for a PPDU that does not overlap the primary channel, except that an AP PHY may issue both indications when receiving a solicited UHR TB PPDU. For example, the PHY may issue both a PHY- RXEARLYSIG. indication primitive and a PHY-RXSTART. indication primitive for a UHR TB PPDU solicited by the AP. In an example, when the PHY issues PHY-RXSTART. indication(RXVECTOR), it may include measured RSSI and RSSI_LEGACY values.

[0208] In an example, after a PHY-CCA.indication(BUSY, channel-list) primitive is issued, the PHY entity may begin receiving training symbols and searching for L-SIG in order to set the maximum duration of the data stream. Then the PHY may search for the preambles for non-HT, HT-MF, VHT, HE, EHT and UHR PPDU. If the constellation used in the first symbol after the first long training field is quadrature BPSK (QBPSK), the PHY entity may continue to detect the received signal using the receive procedure for HT-GF. For detecting the UHR preamble, the PHY entity may search for RLSIG and evaluate the LENGTH field. If RL-SIG is detected, the PHY entity may check the parity bit and RATE fields in L- SIG and RL-SIG. If either the check of the parity bit is invalid or the RATE field is not set to 6 Mb / s, neither a PHY- RXEARLYSIG. indication nor a PHY-RXSTART.indication primitive may be issued issued. If the check of the parity bit is valid and the RATE field indicates 6 Mb / s but the LENGTH field value in LSIG is a not a multiple of three, neither a PHY-RXEARLYSIG. indication nor a PHY-RXSTART.indication primitive may be issued. In an example, a PHY entity may determine from L-SIG that UHR PPDU format are excluded via other means, in which case neither a PHY-RXEARLYSIG. indication nor a PHY-RXSTART.indication primitive may be issued. For example, ff the UHR preamble is not detected, the PHY may continue to detect the received signal using non-HT, HT, VHT, and HE receive procedures.

[0209] In an example, when a parity bit and RATE are valid (e.g., with 6 MB / s indicated in L-SIG and RL- SIG) and LENGTH is a multiple of three, a U-SIG field may be present after RL-SIG. The PHY may issue PHY-RXEARLYSIG. indication, receive the U-SIG field, and identify the PPDU version from the PHY Version Identifier field.

[0210] In an example, the PHY may check the CRC of the U-SIG field and report version-independent parameters (e.g., TXOP, BSS color, bandwidth) to the MAC if the CRC is valid. If the PHY version identifier or BSS color or UL / DL fields do not contain intended values, and the PHY is not ELR-capable, the PHY may issue PHY-RXSTART. indication(RXVECTOR) followed by PHY-RXEND.indication(Filtered); otherwise, it may continue searching for an ELR-MARK.Docket No.: 24-3048PCT

[0211] In an example, ff the U-SIG field indicates a Validate state, the PHY may issue PHY- RXEND.indication(FormatViolation) and maintain a BUSY state for the predicted duration of the PPDU unless a PHY-CCARESET. request is received, such as during spatial reuse operation. If the U-SIG field indicates a Disregard state, the PHY may continue processing the U-SIG and may not process the Disregard field. If the U-SIG CRC is invalid, the PHY may issue PHY-RXEND.indication(FormatViolation) and maintain BUSY for the predicted duration unless a PHY-CCARESET. request is received, such as during spatial reuse operation, if the PHY is not ELR capable; otherwise, it may continue searching for an ELR-MARK. In an example, the PHY may predict duration using an equation: RXTIME gs) =LENG™+ 3* 4 + 20 + SignalExtension where LENGTH is the value of the LENGTH field in L-SIG and SignalExtension is defined elsewhere in an IEEE 802.11 standard amendment (e.g., for HE PHY characteristics).

[0212] In an example, when the U-SIG is valid and the PHY version identifier, the BSS color(s), the UL / DL, the PPDU Type and compression mode, and the Co-BF / Co-SR indication all indicate an intended value, the PHY may parse the PPDU Type and Compression Mode subfield, UL / DL subfield, and Co-BF / Co-SR indication subfield to identify the UHR PPDU type.

[0213] In an example, if the PPDU is a UHR MU PPDU, the PHY may receive the UHR-SIG, UHR-STF, and UHR-LTF fields and check the CRC of the Common field of UHR-SIG. When the CRC is valid (e.g., for all supported modes, unsupported modes, and a Validate indication), the PHY may maintain the BUSY indication for the predicted duration (RXTIME) unless a CCAReset request is received. A Validate UHR-SIG indication may be defined as a field value of a subfield either in the EHT-SIG common field or in the receiver ’s own user field being set to a Validate state.

[0214] In an example, if the UL / DL subfield of the U-SIG field is set to 0 and the CRCs protecting the Common field of the UHR-SIG field are valid, the PHY entity may search for intended STA-ID (e.g., based on the intended BSS color indication if Co-BF / Co-SR is used) in each User field. If an intended STA-ID is detected in a user encoding block or an intended STA-ID is detected in the common encoding block of UHRSIG (STA-ID may be present in the common encoding block of UHR-SIG only if the PPDU type and compression mode and UL / DL indicate a DL non-OFDMA transmission) with valid CRC, and an unsupported mode or a Validate UHR-SIG indication is not indicated, the PHY entity may continue receiving the UHR-STF after the UHR-SIG field.

[0215] In an example, if the receiving PHY entity is contained in an AP, the UL / DL subfield of the U-SIG field is set to 1 , the value of the BSS Color subfield matches a value in the PHYCONFIG VECTOR parameter BSS_COLOR_LIST, the CRC protecting the common encoding block of the UHR-SIG field is valid and an unsupported mode or a Validate UHR-SIG indication is not indicated, the PHY entity may check the STA-ID in the User field.Docket No.: 24-3048PCT

[0216] In an example, if the PHY entity checks the STA-ID in the User field and the STA-ID value matches the 1 1 LSBs of the AID of a STA in the AP’s BSS, then the PHY may continue receiving the UHR-STF after the UHR-SIG field. If the PHY entity does not check the STA-ID in the User field, then the PHY may continue receiving the UHR-STF after the UHR-SIG field.

[0217] In an example, if the UL / DL subfield of the U-SIG field is set to 0 and the CRCs protecting the Common field of the UHR-SIG field are valid and no intended STA-ID (based on the intended BSS color indication if Co-BF / Co-SR is used) is detected in all the User fields, the PHY entity may issue a PHYRXSTART.indication(RXVECTOR) then issue a PHY- RXEND.indication(Filtered).

[0218] In an example, if the UL / DL subfield of the U-SIG field is set to 0 and the CRCs protecting the Common field of the UHR-SIG field are valid and an intended STA-ID (based on the intended BSS color indication if Co-BF / Co-SR is used) is detected, but an unsupported mode or a Validate UHR-SIG indication is indicated in UHR-SIG field, the PHY may issue a PHY- RXSTART.indication(RXVECTOR) then issue a PHY-RXEND.indication(UnsupportedRate) primitive.

[0219] In an example, if the UL / DL subfield of the U-SIG field is set to 1 and the CRC protecting the common encoding block of the UHR-SIG field is valid, but an unsupported mode or a Validate UHR-SIG indication is indicated in UHR-SIG field, the PHY may issue a PHY-RXSTART.indication(RXVECTOR) then issue a PHY- RXEND.indication(UnsupportedRate) primitive.

[0220] In an example, if the CRCs protecting the Common field of the UHR-SIG field are not valid, the PHY may issue the error condition PHY-RXEND.indication(FormatViolation) primitive and maintain PHY- CCA. indication(BU S Y, channellist) primitive for the predicted duration of the transmitted PPDU derived from the LENGTH field in L-SIG as defined in Equation (38-64) unless it receives a PHY- CCARESET. request primitive before the end of the PPDU for instance during spatial reuse operation.

[0221] In an example, ff the received PPDU is UHR TB PPDU, the PHY entity may continue receiving the UHR-STF and UHRLTF for a UHR TB PPDU. If a STA receives a UHR TB PPDU and the TRIGVECTOR parameters are not present in its PHY entity, the STA may calculate the predicted duration of the UHR TB PPDU. If U-SIG indicates the received PPDU is UHR ELR PPDU and the three ELR Validate bits are all ones and STA-ID value matches the 11 LSBs of the AID of the receive STA, the PHY entity may skip the ELRMARK detection and continue receiving the UHR-STF and UHR- LTF and ELR-SIG. If L-SIG, HT-SIG, VHT-SIG-A, HE-SIG-A, or U-SIG is invalid, the ELR capable PHY entity may begin detecting ELR-MARK for UHR ELR PPDU. The PHY entity may detect the ELR-MARK using the known MARK sequence corresponding to its current BSS color. If the PHY entity is in parallel receive procedures and ELR-MARK is not detected, the PHY entity may continue with other non-ELR PPDU receive procedures.

[0222] In an example, if the PHY entity got invalid SIG in receiving L-SIG, HT-SIG, VHT-SIG, HE-SIG, or U-SIG in other non-ELR PPDU mode and ELR-MARK is not detected, the PHY entity may continue with other non-ELR PPDU receive procedures and set PHY-CCA.indication(BUSY, channellist) primitive for theDocket No.: 24-3048PCT predicted duration of the transmitted PPDU. If ELR-MARK is detected, or the received PPDU is UHR ELR PPDU intended for the STA that is detected from U-SIG such that the ELR-MARK detection is bypassed, the PHY entity may continue receiving the UHR-STF and UHR- LTF and ELR-SIG for a UHR ELR PPDU. The PHY entity may check the CRCs of ELR-SIG1 and ELR-SIG2.

[0223] In an example, if the CRC protecting ELR-SIG1 is not valid, the PHY may issue the error condition PHYRXEND.indication(FormatViolation) primitive and maintain PHY-CCA.indication(BUSY, channellist) primitive for the predicted duration of the transmitted PPDU derived from the LENGTH field in L-SIG, if L-SIG is valid. If L-SIG is invalid, neither a PHYRXEARLYSIG. indication nor a PHY-RXSTART. indication primitive may be issued.

[0224] In an example, if the CRC protecting ELR-SIG1 is valid, the UL / DL does not contain an intended value, the PHY entity may issue a PHY-RXSTART.indication(RXVECTOR) then issue a PHY- RXEND.indication(Filtered). The PHY may maintain PHY- CCA.indication(BUSY, channellist) primitive for the predicted duration of the transmitted PPDU derived from the LENGTH field in ELR-SIG1.

[0225] In an example, if the CRC protecting ELR-SIG1 is valid and the UL / DL contains an intended value, the PHY may continue to check CRC of ELR-SIG2. If the CRC protecting ELR-SIG2 is not valid, the PHY may issue the error condition PHYRXEND.indication(FormatViolation) primitive and maintain PHY- CCA.indication(BUSY, channellist) primitive for the predicted duration of the transmitted PPDU derived from the LENGTH field in ELR-SIG1 . If the CRC protecting ELR-SIG2 is valid, the STA-ID in ELR-SIG2 does not match the 11 LSBs of the AID of a STA in the AP's BSS, then the PHY entity may issue a PHY- RXSTART. indication(RXVECTOR) then issue a PHY-RXEND.indication(Filtered). In an example, the PHY may maintain PHYCCA.indication(BUSY, channellist) primitive for the predicted duration of the transmitted PPDU derived from the LENGTH field in ELR-SIG. If the CRC protecting ELR-SIG2 is valid, the STA-ID in ELR-SIG2 matches the 11 LSBs of the AID of a STA in the AP's BSS, then the PHY entity may continue receiving the Data field of the PSDU. If signal loss occurs during reception prior to completion of the PSDU reception, the error condition PHYRXEND.indication(CarrierLost) may be reported to the MAC. After waiting for the end of the PPDU, the PHY may set the P H Y-CCA. i n d ication ( I DLE) primitive and return to the RX IDLE state. The following equation may be used to predict duration derived from the LENGTH field in ELR-SIG1 :TUHR_PREAMBLE and NSYM are defined in an IEEE 802.11 standard amendment.

[0226] In an example, received PSDU bits may be assembled into octets and present to the MAC using a series of PHYDATA.indication(DATA) primitive exchanges. Any final bits that cannot be assembled into a complete octet may be considered pad bits and discarded. After the reception of the final bit of the last PSDU octet, and possible padding and tail bits, the PHY entity may check whether packet extension and / or signal extension is applied. If packet extension and / or signal extension is applied, the PHY entity may wait until theDocket No.: 24-3048PCT packet extension and / or signal extension expires before issuing a PHY-RXEND. indication (NoError, RXVECTOR) returning to the RX IDLE state.

Claims

Docket No.: 24-3048PCTCLAIMSWhat is claimed is:1 . A method comprising: receiving, by a first station (STA) and via a primary channel (PCH), an extended long range (ELR) physical layer protocol data unit (PPDU); based on failing to identify a basic service set (BSS) color from a first preamble of the ELR PPDU, receiving, by the first STA, a portion of a second preamble, following the first preamble, of the ELR PPDU to identify the BSS color, wherein the BSS color identifies a BSS of which a second STA that transmits the ELR PPDU is a member; and based on the BSS color indicating that the ELR PPDU comprises an inter-BSS PPDU, switching, by the first STA and after receiving the portion, from the PCH to a non-primary channel access (NPCA) PCH.

2. A method comprising: receiving, by a first station (STA), a portion of a first preamble of a physical layer protocol data unit (PPDU) being received via a primary channel (PCH), wherein the first preamble follows a second preamble of the PPDU; and based on a basic service set (BSS) color, indicated in the portion, indicating that the PPDU comprises an inter-BSS PPDU, switching, by the first STA and after receiving the portion, from the PCH to a nonprimary channel access (NPCA) PCH.

3. The method of claim 2, wherein the first STA comprises an access point (AP) STA or a non-AP STA.

4. The method of any of claims 2-3, wherein the PPDU comprises an extended long range (ELR) PPDU.

5. The method of claim 4, wherein the first preamble comprises an extended long range (ELR) preamble.

6. The method of claim 5, wherein the portion comprises one or more of: an extended long range (ELR)- Mark field, an ELR short training field (ELR-STF), an ELR long training field (ELR-LTF), and an ELR signal (ELR-SIG) field of the ELR preamble.

7. The method of any of claims 4-6, wherein the second preamble comprises a legacy preamble.

8. The method of any of claims 4-7, wherein the second preamble comprises a non-ELR preamble.

9. The method of any of claims 4-8, wherein the second preamble comprises one or more of: a legacy short training field (L-STF), a legacy long training field (L-LTF), a legacy signal (L-SIG) field, a repeated L-SIG (RL-SIG) field, and a universal signal (U-SIG) field.

10. The method of claim 9, wherein the U-SIG comprises one or more of: a PHY version identifier field, a bandwidth field, an uplink / downlink (UL / DL) field, a BSS color field, a transmission opportunity (TXOP) field, a disregard field, a validate field, a PPDU type and compression mode field, a punctured channel information field, an extremely high throughput signal (EHT-SIG) modulation and coding scheme (MCS) field, a number of EHT-SIG symbols field, a cyclic redundancy check (CRC) field, or a Tail field.Docket No.: 24-3048PCT1 1 . The method of claim 10, wherein the receiving of the portion of the first preamble is based on the first STA failing to identify the BSS color from the second preamble of the PPDU.

12. The method of claim 11 , wherein the STA failing to identify the BSS color from the second preamble comprises the BSS color field of the U-SIG field of the second preamble having a special value.

13. The method of claim 12, wherein the special value is equal to 0.

14. The method of claim 11 , wherein the STA failing to identify the BSS color from the second preamble comprises failing to receive at least one of the L-SIG, RL-SIG, and U-SIG of the second preamble.

15. The method of claim 10, further comprising: receiving, by the first STA, one or more first fields of the second preamble; and failing to receive, by the first STA, one or more second fields of the second preamble.

16. The method of claim 15, wherein the one or more first fields comprise at least one of the L-STF, the L- LTF, the L-SIG, the RL-SIG, or the U-SIG17. The method of claim 15, wherein the one or more second fields comprise at least one of the L-STF, the L-LTF, the L-SIG, the RL-SIG, or the U-SIG.

18. The method of any of claims 2-17, wherein the BSS color identifies a BSS of which a second STA that transmits the PPDU is a member.

19. The method of any of claims 2-18, wherein the BSS color indicated in the portion does not match a value in a BSS_COLOR_LIST parameter of a PHYCONFIG VECTOR.

20. The method of claim 10, wherein the TXOP field of the second preamble comprises / indicates a TXOP duration for the PPDU.

21. The method of claim 20, further comprising obtaining, by the first STA, the TXOP duration from the TXOP field of the second preamble.

22. The method of any of claims 2-21 , further comprising switching, by the first STA and after receiving the portion of the first preamble, from the PCH to the NPCA PCH.

23. The method of any of claims 2-22, further comprising: transmitting, by the first STA to a third STA and via the NPCA PCH, a first frame; and in response to the first frame, receiving, by the first STA from the third STA and via the NPCA PCH, a second frame.

24. The method of claim 23, wherein the first frame comprises an initial control frame (IGF), a request-to- send (RTS) frame, a multi-user (MU)-RTS trigger frame, a buffer status report poll (BSRP) trigger frame, a blockack request (BAR) frame, a MU-BAR trigger frame, a trigger frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

25. The method of any of claims 23-24, wherein the second frame comprises an initial control response frame (ICR), a clear-to-send (CTS) frame, a blockack (BA) frame, a multi-STA BA frame, a buffer statusDocket No.: 24-3048PCT report (BSR) frame, a control frame, a quality of service (QoS) null frame, a management frame, or an action frame.

26. The method of any of claims 23-25, wherein the first frame indicates a first value indicating a duration of the PPDU, a remaining duration until an end time of the PPDU, or the end time of the PPDU.

27. The method of any of claims 23-25, wherein the first frame indicates a second value indicating a TXOP duration indicated in the PPDU, a remaining duration until an end time of a TXOP duration (or a NAV duration) indicated in the PPDU or the end time of the TXOP duration (the NAV duration) indicated by the PPDU.

28. The method of any of claims 23-25, wherein the first frame indicates whether the first STA has a duration of the PPDU, a remaining duration until an end time of the PPDU, the end time of the PPDU, a TXOP duration indicated in the PPDU a remaining duration until an end time of the TXOP duration indicated in the PPDU, or the end time of the TXOP duration indicated by the PPDU.

29. The method of any of claims 23-27, wherein the second frame indicates a third value indicating a duration of the PPDU, a remaining duration until an end time of the PPDU, or the end time of the PPDU.

30. The method of any of claims 23-27, wherein the second frame indicates a fourth value indicating a TXOP duration indicated in the PPDU, a remaining duration until an end time of a TXOP duration (or a NAV duration) indicated in the PPDU or the end time of the TXOP duration (the NAV duration) indicated by the PPDU.31 . The method of any of claims 23-25 or 28, wherein the second frame indicates whether the third STA has a duration of the PPDU, a remaining duration until an end time of the PPDU, the end time of the PPDU, a TXOP duration indicated in the PPDU, a remaining duration until an end time of the TXOP duration indicated in the PPDU, or the end time of the TXOP duration indicated by the PPDU).

32. The method of any of claims 23-31 , wherein the third STA comprises a non-AP STA or an AP STA.

33. The method of any of claims 23-32, further comprising: based on the first frame and / or the second frame, transmitting, by the first STA to the third STA and via the NPCA PCH, a third frame; and receiving, by the first STA from the third STA and via the NPCA PCH, a fourth frame.

34. The method of any of claims 23-33, further comprising, based on the first frame and / or the second frame, switching, by the first STA, from the NPCA PCH to the PCH.

35. The method of any of claims 23-34, further comprising, based on the first frame and / or the second frame, operating, by the first STA and during a first time duration, on the NPCA PCH.

36. The method of claim 35, further comprising exchanging, by the first STA with the third STA and during the first time duration, one or more frames on the NPCA PCH.

37. The method of any of claims 35-36, further comprising exchanging by the first STA the first time duration with the third STA using one or more frames.Docket No.: 24-3048PCT38. The method of claim 37, wherein the one or more frames comprises a management frame, a control frame, an action frame, a quality of service (QoS) null frame, or data frame.

39. The method of any of claims 35-38, wherein the first time duration is determined based on one or more of: (i) a first value indicating a duration of the PPDU, a remaining duration until an end time of the PPDU, or the end time of the PPDU, (ii) a second value indicating a TXOP duration indicated in the PPDU, a remaining duration until an end time of a TXOP duration (or a NAV duration) indicated in the PPDU or the end time of the TXOP duration (the NAV duration) indicated by the PPDU, a third value indicating a duration of the PPDU, a remaining duration until an end time of the PPDU, or the end time of the PPDU, and (v) a fourth value indicating a TXOP duration indicated in the PPDU, a remaining duration until an end time of a TXOP duration (or a NAV duration) indicated in the PPDU or the end time of the TXOP duration (the NAV duration) indicated by the PPDU.

40. The method of claim 39, wherein the first time duration is less than at least one of the first value, the second value, the third value, and the fourth value.

41. The method of claim 39, wherein the first time duration equals at least one of the first value, the second value, the third value, and the fourth value.

42. The method of any of claims 23-41 , wherein the first frame is further transmitted to a fourth STA.

43. The method of any of claims 23-41 , further comprising, based on not receiving a response to the first frame from the third STA, transmitting, by the first STA and via the NPCA PCH, a fifth frame to a fourth STA.

44. 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-43.

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

Images