Non-primary channel access (NPCA) switching operation for peer-to-peer link communication

Abstract

An access point (AP) detects, via a primary channel (PCH), a physical layer protocol data unit (PPDU). The AP decodes a signal (SIG) field of the PPDU to determine an uplink (UL) / downlink (DL) flag of the PPDU. Based on the UL / DL flag being set to a first value indicating DL, the AP switches from the PCH to a non-primary channel access (NPCA) PCH. After switching to the NPCA PCH, the AP communicates, during a duration of the PPDU, with a station (STA) on the NPCA PCH. The AP switches from the NPCA PCH to the PCH before an end of the PPDU, an end of a network allocation vector (NAV) determined based on the PPDU, or an end of a transmit opportunity (TXOP) associated with the PPDU.

Description

Docket No.: 24-3040PCTTITLENON-PRIMARY CHANNEL ACCESS (NPCA) SWITCHING OPERATION FOR PEER-TO-PEER LINK COMMUNICATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 691 ,348, filed September 6, 2024, and U.S. Provisional Application No. 63 / 714,914, filed November 1 , 2024, all of which are hereby incorporated by reference in their entireties.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 is an example that illustrates non-primary channel access (NPCA) operation.

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

[0013] FIG. 11 shows an example that illustrates an NPCA operation.

[0014] FIG. 12 illustrates an inefficiency that may arise in the NPCA operation of FIG. 11 .

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

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

[0017] FIG. 15 shows an example that illustrates another 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.Docket No.: 24-3040PCT

[0020] FIG. 18 shows an example that illustrates another example NPCA operation according to an embodiment.

[0021] FIG. 19 illustrates an example process according to an embodiment.

[0022] FIG. 20 illustrates another example process according to an embodiment.DETAILED DESCRIPTION

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

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

[0025] In this disclosure, "a” and ‘‘an” and similar phrases are to be interpreted as "at least one” and “one or more.” Similarly, any term that ends with the suffix “(s)” is to be interpreted as “at least one” and “one or more." In this disclosure, the term “may” is to be interpreted as “may, for example.” In other words, the term “may” is indicative that the phrase following the term “may” is an example of one of a multitude of suitable possibilities that may, or may not, be employed by one or more of the various embodiments. The terms “comprises” and “consists of’, as used herein, enumerate one or more components of the element being described. The term “comprises” is interchangeable with “includes" and does not exclude unenumerated components from being included in the element being described. By contrast, “consists of' provides a complete enumeration of the one or more components of the element being described. The term “based on”, as used herein, may be interpreted as “based at least in part on” rather than, for example, “based solely on”.Docket No.: 24-3040PCTThe 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.

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

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

[0028] 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 of parameters, it implies that a parameter in the plurality of parameters is in at least one of the one or more messages / frames but does not have to be in each of the one or more messages / frames.

[0029] 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 havingDocket No.: 24-3040PCT 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.

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

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

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

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

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

[0035] 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.Docket No.: 24-3040PCT

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

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

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

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

[0040] A frequency band may include one or more sub-bands or frequency channels. For example, PPDUs conforming to the IEEE 802.11 n, 802.11ac, 802.11 ax and / or 802.11 be standard amendments may be transmitted over the 2.4 GHz, 5 GHz, and / or 6 GHz bands, each of which may be divided into multiple 20 MHz channels. The PPDUs may be transmitted over a physical channel having a minimum bandwidth of 20 MHz. Larger channels may be 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 a common channel operation forDocket No.: 24-3040PCT all STAs where management frames are sent by the AP to ensure that all STAs (regardless of channel bonding support) can receive.

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

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

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

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

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

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

[0047] 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.Docket No.: 24-3040PCT

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

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

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

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

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

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

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

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

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

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

[0058] 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 framesDocket No.: 24-3040PCT 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.

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

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

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

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

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

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

[0065] 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.Docket No.: 24-3040PCT

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

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

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

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

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

[0071] 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, along with the BW, MCS, RU allocation, SS allocation, Tx power, preferred AC, and maximum duration of the TB PPDU per participating STA.

[0072] 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 SIFS (short interframe spacing) after the frame is received. The Padding field, if present, is at least two octets in length and is set to all 1 s.

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

[0074] 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 aDocket No.: 24-3040PCT 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 GTS frame, one ACK frame (if required), and three SIFS periods.

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

[0076] 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, third Reserved 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.1 1 be draft amendment ("IEEE P802.11 be / D3.1 , March 2023”).

[0077] 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.Docket No.: 24-3040PCT

[0078] 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 SIRS (Short Interframe Spacing) periods.

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

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

[0081] 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

[0082] 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. As such, the other STAs may not access the channel using EDCA until the end of transmission of ACK frame 712.

[0083] 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).Docket No.: 24-3040PCT

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

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

[0086] 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 SIPS periods.

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

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

[0089] 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-APDocket No.: 24-3040PCTSTA 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.

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

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

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

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

[0094] On receiving CTS frame 810 and / or CTS frame 812, AP 802 may wait one SIFS 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.Docket No.: 24-3040PCT

[0095] 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), 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. 9 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. 9, the STA may be capable of operating over a plurality of channels. According to non- NPCA operation, the plurality of channels may include a primary 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. 9. For example, the NPCA primary channel may correspond to SCH1 .

[0096] In an implementation, as shown in FIG. 10, 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. 9, 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).

[0097] In contrast, as shown in FIG. 10, 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. 9, 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.

[0098] 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”).Docket No.: 24-3040PCT

[0099] 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 CCA MPC 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.

[0100] FIG. 11 shows an example 1 100 that illustrates an NPCA operation. As shown in FIG. 11 , example 1 100 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).

[0101] Example 1100 may begin with the AP transmitting a frame 1 102 on the PCH. Frame 1102 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 1102 may be a management frame, such as a beacon frame, for example.

[0102] Subsequently, while the AP and STA operate on the PCH, transmission of a frame 1104 from an OBSS may begin on the PCH. The AP and the STA may detect frame 1 104 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 1 104 on the PCH. Frame 1 104 may indicate a transmission on the PCH. A duration of the transmission on the PCH may be provided by a duration field of frame 1104, a transmission opportunity (TXOP) duration field of an OBSS PPDU comprising frame 1 104, 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 (OBSS NAV duration).

[0103] 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.Docket No.: 24-3040PCTThe 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.

[0104] 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 1 102). In example 1 100, 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 1 106 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 the “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 1106 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. 11 ) on the NPCA PCH.

[0105] Existing NPCA operation, however, does not envision the AP and STA switching to the NPCA PCH on detecting / receiving an intra-BSS PPDU (a PPDU transmitted by another STA of the same BSS as the AP / STA). For example, as shown in example 1200 of FIG. 12, on detecting / receiving an intra-BSS PPDU 1202 on the PCH, the AP and STA set their (intra-BSS) NAVs for the PCH (based on a NAV duration indicated in intra-BSS PPDU 1202) and remain on the PCH for the NAV duration. The AP and STA may communicate with each other after the end of the NAV duration via the PCH, for example by the AP transmitting to the STA a frame 1204 as shown in example 1200. However, in some cases, intra-BSS PPDU 1202 may not be addressed to either the AP or the STA. For example, intra-BSS PPDU 1202 may be a peer-to-peer (P2P) PPDU transmitted between two other STAs of the BSS. The AP and STA, therefore, may not need to remain on the PCH to receive intra-BSS PPDU 1202. Nevertheless, and despite that the NPCA PCH may be available during the NAV duration, the AP and STA do not switch to the NPCA PCH according to existing NPCA operation. In some cases, this may result in buffered traffic between the AP and STA being delayed and / or discarded (e.g., when the buffered traffic comprises low-latency traffic) and the NPCA PCH resources being wasted / under-utilized during the NAV duration.

[0106] Embodiments of the present disclosure, as further described below, address the above-described problem of existing technologies. In an aspect, an AP may be configured, after (or based on) detecting an intra-BSS DL PPDU via the PCH, to switch from the PCH to an NPCA PCH. In an embodiment, the AP supports a first NPCA mode according to which the AP switches from the PCH to the NPCA PCH after detecting on the PCH an intra-BSS DL PPDU. In an embodiment, the AP switches from the PCH to the NPCA PCH after detecting the intra-BSS DL PPDU on the PCH, based on the first NPCA mode being enabledDocket No.: 24-3040PCT(used, activated) at the AP. In another aspect, a STA, associated with the AP, may be configured, after (or based on) detecting an intra-BSS DL PPDU via the PCH, to switch from the PCH to the NPCA PCH. In an embodiment, the STA supports a second NPCA mode according to which the STA switches from the PCH to the NPCA PCH after detecting on the PCH an intra-BSS DL PPDU that is not addressed to the STA. In an embodiment, the STA switches from the PCH to the NPCA PCH after detecting the intra-BSS DL PPDU on the PCH, based on the second NPCA mode being enabled (used, activated) at the STA. In an embodiment, the AP may be configured to switch from the PCH to the NPCA PCH after detecting an intra-BSS DL PPDU on the PCH, based on the second NPCA mode being enabled (used, activated) at the STA. This ensures that the AP switches from the PCH to the NPCA PCH (after detecting an intra-BSS DL PPDU on the PCH) when the STA is also configured to switch from the PCH to the NPCA PCH (after detecting the intra-BSS DL PPDU on the PCH) and may thus communicate with the AP via the NPCA PCH. In another embodiment, the STA may be configured to switch from the PCH to the NPCA PCH after detecting an intra-BSS DL PPDU on the PCH, based on the first NPCA mode being enabled (used, activated) at the AP. This ensures that the STA switches from the PCH to the NPCA PCH (after detecting an intra-BSS DL PPDU on the PCH) when the AP is also configured to switch from the PCH to the NPCA PCH (after detecting the intra-BSS DL PPDU on the PCH) and may thus communicate with the AP via the NPCA PCH.

[0107] FIG. 13 shows an example 1300 that illustrates an example NPCA operation according to an embodiment. Example 1300 is provided for the purpose of illustration only and is not limiting of embodiments. As shown in FIG. 13, example 1300 includes an AP 1302 and STAs 1304 and 1306. Example 1300 also includes a STA 1308 (not shown in FIG. 13). AP 1302 and STAs 1304, 1306, and 1308 belong to the same BSS. STAs 1304, 1306, and 1308 may be associated with AP 1302. AP 1302 and STAs 1304, 1306, and 1308 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). AP 1302 and STAs 1304, 1306, and 1308 may each support an NPCA (switching) mode (or NPCA operation mode).

[0108] In example 1300, AP 1302 supports a first NPCA mode. In an embodiment, according to the first NPCA mode, AP 1302 may be configured to switch from the PCH to the NPCA PCH after detecting an intra- BSS DL PPDU on the PCH. In an embodiment, AP 1302 may detect an intra-BSS DL PPDU based on receiving a PPDU that indicates a downlink transmission and that is transmitted by a first STA to a second STA. The first STA may belong to the BSS of AP 1302. The second STA may belong to the BSS of AP 1302. In an embodiment, based on the downlink transmission indication of the PPDU, AP 1302 may determine that the PPDU comprises an intra-BSS P2P PPDU (i.e., a PPDU transmitted by the first STA directly (not via the AP) to the second STA). In another embodiment, according to the first NPCA mode, AP 1302 may be configured to switch from the PCH to the NPCA PCH after / based on detecting / receiving an OBSS (inter- BSS) DL PPDU on the PCH. In an embodiment, AP 1302 may detect an inter-BSS DL PPDU on the PCH based on detecting / receiving on the PCH a PPDU that indicates a downlink transmission. The PPDUDocket No.: 24-3040PCT indicating a downlink transmission may be transmitted by another AP (not shown in FIG. 13), belonging to another BSS. AP 1302 may classify the PPDU indicating a downlink transmission as an inter-BSS PPDU.

[0109] In an embodiment, AP 1302 may be configured to decode (read, detect, process, parse, or receive) a signal (SIG) field of the PPDU to determine whether the PPDU is an intra-BSS DL PPDU (or an inter-BSS DL PPDU). In an embodiment, AP 1302 may decode (read, detect, process, parse, or receive) a BSS color field of the SIG field. AP 1302 may determine that the PPDU is an intra-BSS PPDU based on the BSS color field indicating a BSS color (or a BSSID) of AP 1302. Additionally, or alternatively, AP 1302 may be configured to decode (read, detect, process, parse, or receive) an uplink / downlink (UL / DL) flag of the SIG field. AP 1302 may determine that the PPDU is a DL PPDU based on the UL / DL flag being to set to DL (or a value corresponding to DL). The SIG field may be located in a preamble part or in a PHY header of the PPDU. Depending on the type of PPDU, the SIG field may comprise a U-SIG, a UHR SIG, an EHT SIG, an HE SIG- A / B, a VHT SIG-A / B, or an HT SIG, for example. The SIG field may be a universal SIG (U-SIG) field, for example when the PPDU comprises an extremely high throughput (EHT) PPDU, an ultra-high reliability (UHR) PPDU, or a UHR+ PPDU. The SIG field may be an HE-SIG-A field, for example when the PPDU comprises a high efficiency (HE) PPDU.

[0110] In an embodiment, AP 1302 may be configured to decode (read, detect, process, parse, or receive) the SIG field of the PPDU to determine duration information associated with the PPDU. The duration information may be for NAV setting and protection of a TXOP in which the PPDU is transmitted. AP 1302 may set a NAV for the PCH based on the duration information. In an embodiment, AP 1302 may be configured to decode (read, detect, process, parse, or receive) a TXOP field of the SIG field to determine the duration information. The TXOP field may indicate a value of 0; a non-zero value; or a value of UNSPECFIED (e g., all bits of the TXOP field set to 1s).

[0111] In another embodiment, AP 1302 may be configured to decode (read, detect, process, parse, or receive) an MPDU (or a MAC header of the MPDU) of the PPDU to determine whether the PPDU is an intra- BSS DL PPDU (or an inter-BSS DL PPDU). The MPDU may be a first occurring MPDU of the PPDU. In an embodiment, AP 1302 may decode (read, detect, process, parse, or receive) a BSSID field of (the MAC header of) the MPDU. AP 1302 may determine that the PPDU is an intra-BSS PPDU based on the BSSID field indicating a MAC address of AP 1302. Additionally, or alternatively, AP 1302 may be configured to decode (read, detect, process, parse, or receive) one or more Address fields (e.g., Address 1 (RA), Address 2 (TA), Address 3, and / or Address 4) of the MPDU. AP 1302 may determine that the PPDU is a DL PPDU based on of the one more Address fields of the MPDU. For example, AP 1302 may determine that the PPDU is a DL PPDU based on an RA of the MPDU being set to a MAC header of another STA (i.e., other than AP 1302) of the BSS. In an embodiment, AP 1302 may determine that the PPDU is a P2P PPDU based on a “To DS” subfield and a “From DS” subfield in a Frame Control field of a MAC header of the PPDU. ForDocket No.: 24-3040PCT example, if the To DS subfield is equal to 0 and the From DS subfield is equal to 0, AP 1302 may determine that the PPDU is a P2P( / D2D) PPDU.

[0112] In another embodiment, AP 1302 may be configured to decode (read, detect, process, parse, or receive) an MPDU (or a MAC header of the MPDU) of the PPDU to determine the duration information associated with the PPDU. AP 1302 may set a NAV for the PCH based on the duration information. In an embodiment, AP 1302 may be configured to decode (read, detect, process, parse, or receive) a Duration / ID field (of the MAC header of) the MPDU to determine the duration information.

[0113] In an embodiment, AP 1302 may enable (use, activate) or disable (unuse, deactivate) the first NPCA mode. AP 1302 may switch from the PCH to the NPCA PCH after detecting an intra-BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH, based on the first NPCA mode being enabled (used, activated). AP 1302 may not switch from the PCH to the NPCA PCH after detecting an intra-BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH, based on the first NPCA mode being disabled (unused, deactivated). In an embodiment, AP 1302 switching to the NPCA PCH comprises AP 1302 operating (or camping, or parking) on the NPCA PCH.

[0114] In example 1300, STA 1304 supports a second NPCA mode (or NPCA operation mode). According to the second NPCA mode, STA 1304 may be configured to switch from the PCH to the NPCA PCH after detecting an intra-BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH. In an embodiment, STA 1304 may detect an intra-BSS DL PPDU based on receiving a PPDU that indicates a downlink transmission and that is transmitted by a first STA, belonging to the BSS of STA 1304, to a second STA, belonging to the BSS of STA 1304. In an embodiment, STA 1304 switches from the PCH to the NPCA PCH when the detected intra-BSS DL PPDU is not addressed to STA 1304. In an embodiment, STA 1304 may not distinguish the detected intra-BSS DL PPDU as being a P2P PPDU . In an embodiment, STA 1304 may detect an inter-BSS DL PPDU on the PCH based on detecting / receiving on the PCH a PPDU that indicates a downlink transmission.

[0115] In an embodiment, STA 1304 may be configured to decode (read, detect, process, parse, or receive) a signal (SIG) field of the PPDU to determine whether the PPDU is an intra-BSS DL PPDU (or an inter-BSS DL PPDU). In an embodiment, STA 1304 may decode (read, detect, process, parse, or receive) a BSS color field of the SIG field. STA 1304 may determine that the PPDU is an intra-BSS PPDU based on the BSS color field indicating a BSS color (or a BSSID) of AP 1302 (with which STA 1304 is associated). Additionally, or alternatively, STA 1304 may be configured to decode (read, detect, process, parse, or receive) an uplink / downlink (UL / DL) flag of the SIG field. STA 1304 may determine that the PPDU is a DL PPDU based on the UL / DL flag being to set to DL (or a value corresponding to DL). Additionally, or alternatively, STA 1304 may be configured to decode (read, detect, process, parse, or receive) a field (e.g., STA ID) of the SIG field indicating a receiver of the PPDU. STA 1304 may determine whether the PPDU is addressed to STA 1304 based on this field. The SIG field may be located in a preamble part or in a PHY header of the PPDU. Depending on the type of PPDU, the SIG field may comprise a U-SIG, a UHR SIG, an EHT SIG, an HE SIG-Docket No.: 24-3040PCTA / B, a VHT SIG-A / B, or an HT SIG, for example. The SIG field may be a universal SIG (U-SIG) field, for example when the PPDU comprises an extremely high throughput (EHT) PPDU, an ultra-high reliability (UHR) PPDU, or a UHR+ PPDU. The SIG field may be an HE-SIG-A field, for example when the PPDU comprises a high efficiency (HE) PPDU.

[0116] In an embodiment, STA 1304 may be configured to decode (read, detect, process, parse, or receive) the SIG field of the PPDU to determine duration information associated with the PPDU. The duration information may be for NAV setting and protection of a TXOP in which the PPDU is transmitted. STA 1304 may set a NAV for the PCH based on the duration information. In an embodiment, STA 1304 may be configured to decode (read, detect, process, parse, or receive) a TXOP field of the SIG field to determine the duration information. The TXOP field may indicate a value of 0; a non-zero value; or a value of UNSPECFIED (e.g., all bits of the TXOP field set to 1 s).

[0117] In another embodiment, STA 1304 may be configured to decode (read, detect, process, parse, or receive) an MPDU (or a MAC header of the MPDU) of the PPDU to determine whether the PPDU is an intra- BSS DL PPDU (or an inter-BSS DL PPDU). The MPDU may be a first occurring MPDU of the PPDU. In an embodiment, STA 1304 may decode (read, detect, process, parse, or receive) a BSSID field of (the MAC header of) the MPDU. STA 1304 may determine that the PPDU is an intra-BSS PPDU based on the BSSID field indicating a MAC address of AP 1302 (with which STA 1304 is associated). Additionally, or alternatively, STA 1304 may be configured to decode (read, detect, process, parse, or receive) one or more Address fields (e.g., Address 1 (RA), Address 2 (TA), Address 3, and / or Address 4) of the MPDU. STA 1304 may determine that the PPDU is a DL PPDU based on of the one more Address fields of the MPDU. For example, STA 1304 may determine that the PPDU is a DL PPDU based on an RA of the MPDU being set to a MAC header of a STA other than AP 1302 of the BSS. In an embodiment, STA 1304 may determine that the PPDU is a P2P PPDU based on a “To DS” subfield and a “From DS” subfield in a Frame Control field of a MAC header of the PPDU. For example, if the To DS subfield is equal to 0 and the From DS subfield is equal to O, STA 1304 may determine that the PPDU is a P2P( / D2D) PPDU.

[0118] In another embodiment, STA 1304 may be configured to decode (read, detect, process, parse, or receive) an MPDU (or a MAC header of the MPDU) of the PPDU to determine the duration information associated with the PPDU. STA 1304 may set a NAV for the PCH based on the duration information. In an embodiment, STA 1304 may be configured to decode (read, detect, process, parse, or receive) a Duration / ID field (of the MAC header of) the MPDU to determine the duration information.

[0119] In an embodiment, STA 1304 may enable (use, activate) or disable (unuse, deactivate) the second NPCA mode. STA 1304 may switch from the PCH to the NPCA PCH after detecting an intra-BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH, based on the second NPCA mode being enabled (used, activated). STA 1304 may not switch from the PCH to the NPCA PCH after detecting an intra-BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH, based on the second NPCA mode being disabled (unused, deactivated).Docket No.: 24-3040PCTIn an embodiment, STA 1304 switching to the NPCA PCH comprises STA 1304 operating (or camping, or parking) on the NPCA PCH.

[0120] Returning to FIG 13, example 1300 begins with STA 1306 transmitting a PPDU 1310 on the PCH to STA 1308 (not shown in FIG. 13). As AP 1302 and STA 1304 operate on the PCH, AP 1302 and STA 1304 may (in parallel) detect / sense the transmission of PPDU 1310 and begin to decode (read, detect, process, parse, or receive) PPDU 1310. In an example, AP 1302 and STA 1304 may decode (read, detect, process, parse, or receive) a PHY identifier field of PPDU 1310, which allows AP 1302 and STA 1304 to determine a PPDU type of PPDU 1310.

[0121] Next, in an embodiment, AP 1302 and STA 1304 may decode (read, detect, process, parse, or receive) a preamble / PHY header of PPDU 1310 to determine if PPDU 1310 is an intra-BSS DL PPDU (or an inter-BSS DL PPDU). As described above, AP 1302 and STA 1304 may decode (read, detect, process, parse, or receive) a BSS color field of a SIG field of the preamble / PHY header to determine whether PPDU 1310 is an intra-BSS PPDU (or an inter-BSS DL PPDU). In example 1300, AP 1302 and STA 1304 may determine that PPDU 1310 is an intra-BSS PPDU based on the BSS color field indicating a BSS color (or a BSSID) of AP 1302. Additionally, AP 1302 and STA 1304 may decode (read, detect, process, parse, or receive) an UL / DL flag of the SIG field to determine whether PPDU 1310 is a DL PPDU. In example 1300, AP 1302 and STA 1304 may determine that PPDU 1310 is a DL PPDU based on the UL / DL flag being to set to DL (or a value corresponding to DL). Additionally, STA 1304 may decode (read, detect, process, parse, or receive) a field (e.g., STA ID) of the SIG field that indicates a receiver of PPDU 1310. In example 1300, STA 1304 may determine that PPDU 1310 is addressed to STA 1308 and not to STA 1304. In an embodiment, AP 1302 and / or STA 1304 may classify PPDU 1310 as an inter-BSS PPDU based on the UL / DL flag being set to DL (or a value corresponding to DL).

[0122] In another embodiment (not shown in FIG. 13), alternatively or additionally, AP 1302 and STA 1304 may decode (read, detect, process, parse, or receive) an MPDU (or a MAC header of the MPDU) of PPDU 1310 to determine if PPDU 1310 is an intra-BSS DL PPDU (or an inter-BSS DL PPDU). The MPDU may be a first occurring MPDU of PPDU 1310. In an embodiment, AP 1302 and STA 1304 may be configured to decode (read, detect, process, parse, or receive) the MPDU of PPDU 1310 to determine if PPDU 1310 is an intra-BSS DL PPDU (or an inter-BSS DL PPDU) based on failing to determine whether PPDU 1310 is an intra-BSS PPDU and / or a DL PPDU based on reading / decoding the preamble / PHY header of PPDU 1310. As described above, AP 1302 and STA 1304 may decode (read, detect, process, parse, or receive) a BSSID field of the MPDU to determine whether the BSSID field indicates a MAC address of AP 1302. Additionally, or alternatively, AP 1302 may decode (read, detect, process, parse, or receive) one or more Address fields (e.g., Address 1 (RA), Address 2 (TA), Address 3, and / or Address 4) of the MPDU. AP 1302 may determine that the PPDU is a DL PPDU based on of the one more Address fields of the MPDU. For example, AP 1302 may determine that the PPDU is a DL PPDU based on an RA of the MPDU being set to a MAC header ofDocket No.: 24-3040PCT another STA (i.e., other than AP 1302) of the BSS. In an embodiment, AP 1302 may determine that the PPDU is a P2P PPDU based on a “To DS” subfield and a “From DS” subfield in a Frame Control field of a MAC header of the PPDU. For example, if the To DS subfield is equal to 0 and the From DS subfield is equal to 0, AP 1302 may determine that the PPDU is a P2P( / D2D) PPDU.

[0123] Continuing with example 1300, after determining that PPDU 1310 is an intra-BSS DL PPDU, AP 1302 switches from the PCH to the NPCA PCH. Similarly, after determining that PPDU 1310 is an intra-BSS DL PPDU not addressed to STA 1304, STA 1304 switches from the PCH to the NPCA PCH. In an embodiment, AP 1302 and STA 1304 may be configured to switch to the NPCA PCH at the same switching time. The switching time may correspond to the time that AP 1302 and STA 1304 finish decoding / reading the SIG field of PPDU 1310, for example. However, other switching times may also be configured or negotiated / agreed between AP 1302 and STA 1304. In another embodiment, based on the UL / DL flag of PPDU 1310 being set to DL (or a value corresponding to DL), AP 1302 and / or STA 1304 classify PPDU 1310 as an inter-BSS DL PPDU. Based on this classification, AP 1302 and / or STA 1304 switch from the PCH to the NPCA PCH.

[0124] Subsequently, AP 1302 may access the NPCA PCH and transmit a frame 1312 to STA 1304. As shown in FIG. 13, frame 1312 may be transmitted via a bandwidth that comprises the NPCA PCH. For example, frame 1312 may be transmitted via the NPCH PCH and SCH2. Frame 1312 may comprise an initial control frame (ICF), a request-to-send (RTS) frame, a multi-user (MU)-RTS frame, a buffer status report poll (BSRP) trigger frame, a block ack request (BAR) frame, a clear-to-send (CTS) frame, a block ack (BA) frame, an acknowledgment (Ack) frame, a buffer status report (BSR) frame, an initial control response frame (ICR), a request frame, a control frame, a management frame, or an action frame, for example. STA 1304 may respond to frame 1312 from AP 1302 by transmitting a frame 1314 to AP 1302. Frame 1314 may comprise a clear-to-send (CTS) frame, a BlockAck (BA) frame, an acknowledgment (Ack) frame, a buffer status report (BSR) frame, an initial control response frame (ICR), a response frame, a control frame, a management frame, or an action frame, for example.

[0125] AP 1302 may then transmit a frame 1316 to STA 1304. Frame 1316 may comprise a data frame, a management frame, or an action frame, for example. STA 1304 may respond to frame 1316 by transmitting a frame 1318 to AP 1302. Frame 1318 may comprise an immediate response frame, such as an Ack frame or a BA frame. As such, communication between AP 1302 and STA 1304 may occur on the NPCA PCH during at least the transmission time of PPDU 1310 by STA 1306 to STA 1308 on the PCH. This allows for buffered traffic between AP 1302 and STA 1304 to be transmitted with minimal delay and avoids NPCA PCH resources from being wasted.

[0126] In an embodiment, AP 1302 and STA 1304 may switch to the NPCA PCH as described above, without determining the duration information (NAV / TXOP duration) associated with PPDU 1310. Accordingly, AP 1302 and STA 1304 may be configured to finish communicating on the NPCA PCH and return to the PCHDocket No.: 24-3040PCT before an end of PPDU 1310. In another embodiment, AP 1302 and STA 1304 may only switch to the NPCA PCH after determining the NAV / TXOP duration associated with PPDU 1310. As such, AP 1302 and STA 1304 may be configured to return to the PCH before an end of the NAV / TXOP duration associated with PPDU 1310. In an embodiment, AP 1302 and STA 1304 may be configured to operate on the NPCA PCH until an end of the NAV / TXOP duration associated with PPDU 1310 duration as shown in FIG. 16.

[0127] FIG. 14 shows an example 1400 that illustrates another NPCA operation according to an embodiment. Example 1400 is provided for the purpose of illustration only and is not limiting of embodiments. As shown in FIG. 14, example 1400 also includes AP 1302 and STAs 1304, 1306, and 1308 described above in FIG. 13.

[0128] Example 1400 may begin with AP 1302 transmitting a frame 1402 via the PCH. Frame 1402 may indicate whether AP 1302 supports the first NPCA mode described above. As described above, according to the first NPCA mode, AP 1302 switches from the PCH to the NPCA PCH after detecting on the PCH an intra- BSS DL PPDU (or an inter-BSS DL PPDU). In an embodiment, when AP 1302 supports the first NPCA mode, AP 1302 may be configured to switch from the PCH to the NPCA PCH (after detecting on the PCH an intra- BSS DL PPDU (or an inter-BSS DL PPDU)) on condition that at least one STA associated with AP 1302 supports (or supports and has indicated enablement / activation of) a mode (e.g., the second NPCA mode) according to which the STA switches from the PCH to the NPCA PCH after detecting on the PCH an intra- BSS DL PPDU (or an inter-BSS DL PPDU). Frame 1402 may comprise a beacon frame, a fast initial link setup (FILS) discovery frame, a short beacon frame, a traffic indication map (TIM) broadcast frame, a broadcast frame, or an announcement frame, for example.

[0129] Subsequently, example 1400 may include STA 1304 transmitting a frame 1404 to AP 1302. Frame 1404 may indicate whether STA 1304 supports the second NPCA mode. As described above, according to the second NPCA mode, STA 1304 switches from the PCH to the NPCA PCH after detecting on the PCH an intra-BSS DL PPDU that is not addressed to STA 1304 (or after detecting an inter-BSS DL PPDU). In an embodiment, when STA 1304 supports the second NPCA mode, STA 1304 may be configured to switch from the PCH to the NPCA PCH (after detecting on the PCH an intra-BSS DL PPDU not addressed to it (or after detecting an inter-BSS DL PPDU)) on condition that AP 1302 (with which STA 1304 is associated) supports (or supports and has indicated enablement / activation of) a mode (e.g., the first NPCA mode) according to which AP 1302 switches from the PCH to the NPCA PCH after detecting on the PCH an intra-BSS DL PPDU (or an inter-BSS DL PPDU)

[0130] In another embodiment, additionally or alternatively, frame 1404 may indicate enablement / disablement (activation / deactivation) of the second NPCA mode at STA 1304. In an embodiment, when STA 1304 has enabled (used, activated) the second NPCA mode, STA 1304 may be configured to switch from the PCH to the NPCA PCH (after detecting on the PCH an intra-BSS DL PPDU not addressed to it) on condition that AP 1302 (with which STA 1304 is associated) supports (or supports andDocket No.: 24-3040PCT has indicated enablement / activation of) a mode (e.g., the first NPCA mode) according to which AP 1302 switches from the PCH to the NPCA PCH after detecting on the PCH an intra-BSS DL PPDU (or an inter- BSS DL PPDU) Frame 1404 may comprise a probe request frame, an association request frame, a reassociation request frame, a request frame, a management frame, an action frame, a control frame, a quality of service (QoS) null frame, or a QoS data frame, for example.

[0131] In an embodiment, AP 1302 may respond to frame 1404 from STA 1304 by transmitting a frame 1406 to STA 1304. In another embodiment, AP 1302 may not respond to frame 1404 from STA 1304. In an embodiment, frame 1406 acknowledges frame 1404. In another embodiment, frame 1406 responds to frame 1404. In an embodiment, frame 1406 indicates whether AP 1302 supports the first NPCA mode described above. In another embodiment, additionally or alternatively, frame 1406 may indicate enablement / disablement (activation / deactivation) of the first NPCA mode at AP 1302. In an embodiment, when AP 1302 has enabled (used, activated) the first NPCA mode, AP 1302 may be configured to switch from the PCH to the NPCA PCH (after detecting on the PCH an intra-BSS DL PPDU (or an inter-BSS DL PPDU)) on condition that at least one STA associated with AP 1302 supports (or supports and has indicated enablement / activation of) a mode (e.g., the second NPCA mode) according to which the STA switches from the PCH to the NPCA PCH after detecting on the PCH an intra-BSS DL PPDU (or an inter-BSS DL PPDU). In an embodiment, in response to frame 1404 indicating enablement / activation of the second NPCA mode at STA 1304, AP 1302 may transmit frame 1406 indicating enablement / activation of the first NPCA mode at AP 1302. That is, AP 1302 may enable / activate the first NPCA mode in response to STA 1304 indicating enablement / activation of the second NPCA mode. Frame 1406 may comprise a probe response frame, an association response frame, a reassociation response frame, a response frame, a management frame, an action frame, a control frame, a quality of service (QoS) null frame, or a QoS data frame, for example.

[0132] In an embodiment, AP 1302 may be configured to switch from the PCH to the NPCA PCH after detecting an intra-BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH, based on the first NPCA mode supported by AP 1302 and / or the second NPCA mode supported by STA 1304. In an embodiment, AP 1302 switches from the PCH to the NPCA PCH (after detecting an intra-BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH) based on STA 1304 supporting the second NPCA mode and / or enabling / activating the second NPCA mode. In an embodiment, AP 1302 switches from the PCH to the NPCA PCH (after detecting an intra- BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH) based on enablement / activation of the first NPCA mode at AP 1302 and enablement / activation of the second NPCA mode at STA 1304. Similarly, STA 1304 may be configured to switch from the PCH to the NPCA PCH after detecting on the PCH an intra-BSS DL PPDU not addressed to STA 1304 (or after detecting an inter-BSS DL PPDU), based on the first NPCA mode supported by AP 1302 and / or the second NPCA mode supported by STA 1304. In an embodiment, STA 1304 switches from the PCH to the NPCA PCH (after detecting an intra-BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH) based on AP 1302 supporting the first NPCA mode and / or enabling / activating the first NPCADocket No.: 24-3040PCT mode. In an embodiment, STA 1304 switches from the PCH to the NPCA PCH (after detecting an intra-BSS DL PPDU (or an inter-BSS DL PPDU) on the PCH) based on enablement / activation of the first NPCA mode at AP 1302 and enablement / activation of the second NPCA mode at STA 1304.

[0133] In an example, AP 1302 may indicate in frame 1402 that AP 1302 supports the first NPCA mode. Subsequently, STA 1304 may indicate in frame 1404 enablement / activation of the second NPCA mode at STA 1304. In response, AP 1302 may indicate in frame 1406 enablement / activation of the first NPCA mode at AP 1302. After detecting PPDU 1310 on the PCH, AP 1302 may switch from the PCH to the NPCA PCH based on the first NPCA mode and the second NPCA being enabled (used, activated). Similarly, STA 1304 may switch from the PCH to the NPCA PCH based on the first NPCA mode and the second NPCA being enabled (used, activated). Example 1400 may then continue as described for example 1300 above.

[0134] In some cases, as described above, while determining that PPDU 1310 is an intra-BSS PPDU, STA 1304 may not recognize whether PPDU 1310 is a P2P PPDU. For example, STA 1304 may be configured to switch from the PCH to the NPCA PCH after determining that PPDU 1310 is an intra-BSS PPDU and that PPDU 1310 is a DL PPDU. In contrast, the DL indication of PPDU 1310 is enough for AP 1302 to determine that PPDU 1310 is a P2P PPDU (an intra-BSS DL PPDU may be either a P2P PPDU or a PPDU transmitted by AP 1302 to a non-AP STA). Due to this capability mismatch between AP 1302 and STA 1304, in some cases, STA 1304 may switch by itself (i.e., without AP 1302 also switching) from PCH to the NPCA PCH after detecting on the PCH an intra-BSS DL PPDU being transmitted by AP 1302. As AP 1302 does not switch to the NPCA PCH based on such a PPDU, STA 1304 may not communicate with AP 1302 after switching to the NPCA PCH. STA 1304 may remain on the NPCA PCH based on the duration information indicated in the PPDU before returning to the PCH. Thus, STA 1304 may needlessly switch to the NPCA PCH in some cases, which may increase power consumption at STA 1304. An example embodiment that addresses this potential problem is described below with reference to FIG. 15.

[0135] FIG. 15 shows an example 1500 that illustrates another example operation according to an embodiment. As shown in FIG. 15, example 1500 includes an AP 1502 and STAs 1504 and 1506. Example 1500 also includes a STA 1508 (not shown in FIG. 15). AP 1502 and STAs 1504, 1506, and 1508 belong to the same BSS. STAs 1504, 1506, and 1508 may be associated with AP 1502. AP 1502 and STAs 1504, 1506, and 1508 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). AP 1502 and STAs 1504, 1506, and 1508 may each support an NPCA (switching) mode (or NPCA operation mode).

[0136] In example 1500, AP 1502 supports the first NPCA mode described above. According to the first NPCA mode, AP 1502 may be configured to switch from the PCH to the NPCA PCH after detecting an intra- BSS DL PPDU on the PCH. Particularly, based on the downlink transmission indication of the PPDU, AP 1502 may determine that the PPDU comprises an intra-BSS P2P PPDU. In another embodiment, accordingDocket No.: 24-3040PCT to the first NPCA mode, AP 1502 may be configured to switch from the PCH to the NPCA PCH after / based on detecting / receiving an inter-BSS DL PPDU on the PCH. In an embodiment, AP 1502 may detect an inter- BSS DL PPDU on the PCH based on detecting / receiving on the PCH a PPDU that indicates a downlink transmission.

[0137] In an embodiment, as described in more detail above with reference to example 1300, AP 1502 may be configured to decode (read, detect, process, parse, or receive) a signal (SIG) field of the PPDU to determine whether the PPDU is an intra-BSS DL PPDU. In an embodiment, AP 1502 may decode (read, detect, process, parse, or receive) a BSS color field of the SIG field. AP 1502 may determine that the PPDU is an intra-BSS PPDU based on the BSS color field indicating a BSS color (or a BSSID) of AP 1502. Additionally, or alternatively, AP 1502 may be configured to decode (read, detect, process, parse, or receive) an uplink / downlink (UL / DL) flag of the SIG field. AP 1502 may determine that the PPDU is a DL PPDU based on the UL / DL flag being to set to DL (or a value corresponding to DL). In another embodiment, AP 1502 may be configured to decode (read, detect, process, parse, or receive) a P2P flag of the PPDU. The P2P flag may be set to a first value (e.g., 1) when the PPDU is a P2P PPDU and to a second value (e.g., 0) when the PPDU is not a P2P PPDU. The P2P flag may be provided in a preamble or a PHY header of the PPDU, for example in a SIG field.

[0138] In an embodiment, as described in more detail above with reference to example 1300, AP 1502 may be configured to decode (read, detect, process, parse, or receive) the SIG field of the PPDU to determine duration information associated with the PPDU.

[0139] In another embodiment, as described in more detail above with reference to example 1300, AP 1502 may be configured to decode (read, detect, process, parse, or receive) an MPDU (or a MAC header of the MPDU) of the PPDU to determine whether the PPDU is an intra-BSS DL PPDU. In another embodiment, AP 1502 may be configured to decode (read, detect, process, parse, or receive) an MPDU (or a MAC header of the MPDU) of the PPDU to determine the duration information associated with the PPDU. AP 1502 may set a NAV for the PCH based on the duration information.

[0140] In example 1500, STA 1504 supports a third NPCA mode. According to the third NPCA mode, STA 1504 may be configured to switch from the PCH to the NPCA PCH after detecting on the PCH an intra-BSS P2P PPDU not addressed to STA 1504.

[0141] In an embodiment, as described in more detail above with reference to example 1300, STA 1504 may be configured to decode (read, detect, process, parse, or receive) a signal (SIG) field of the PPDU to determine whether the PPDU is an intra-BSS P2P PPDU. In an embodiment, STA 1504 may decode (read, detect, process, parse, or receive) a BSS color field of the SIG field. STA 1504 may determine that the PPDU is an intra-BSS PPDU based on the BSS color field indicating a BSS color (or a BSSID) of AP 1502 (with which STA 1504 is associated). Additionally, STA 1504 may be configured to decode (read, detect, process, parse, or receive) a P2P flag of the PPDU. The P2P flag may be set to a first value (e.g., 1) when the PPDUDocket No.: 24-3040PCT is a P2P PPDU and to a second value (e.g., 0) when the PPDU is not a P2P PPDU. The P2P flag may be provided in a preamble or a PHY header of the PPDU, for example in a SIG field. Alternatively, the P2P flag may be provided in a MAC frame of the PPDU, for example in a MAC header of the PPDU.

[0142] Additionally, or alternatively, as described above in more detail with reference to example 1300, STA 1504 may be configured to decode (read, detect, process, parse, or receive) a field (e.g., STA ID) of the SIG field indicating a receiver of the PPDU. STA 1504 may determine whether the PPDU is addressed to STA 1504 based on this field.

[0143] In an embodiment, as described in more detail above with reference to example 1300, STA 1504 may be configured to decode (read, detect, process, parse, or receive) the SIG field of the PPDU to determine duration information associated with the PPDU.

[0144] In another embodiment, as described in more detail above with reference to example 1300, STA 1504 may be configured to decode (read, detect, process, parse, or receive) an MPDU (or a MAC header of the MPDU) of the PPDU to determine whether the PPDU is an intra-BSS P2P PPDU. The MPDU may be a first occurring MPDU of the PPDU. In an embodiment, STA 1504 may decode (read, detect, process, parse, or receive) a BSSID field of (the MAC header of) the MPDU. STA 1504 may determine that the PPDU is an intra-BSS PPDU based on the BSSID field indicating a MAC address of AP 1502 (with which STA 1504 is associated). Additionally, or alternatively, STA 1504 may be configured to decode (read, detect, process, parse, or receive) a P2P field of the MPDU. STA 1504 may determine that the PPDU is a P2P PPDU based on the P2P field of the MPDU.

[0145] In another embodiment, STA 1504 may be configured to decode (read, detect, process, parse, or receive) an MPDU (or a MAC header of the MPDU) of the PPDU to determine the duration information associated with the PPDU. STA 1504 may set a NAV for the PCH based on the duration information.

[0146] Returning to FIG. 15, example 1500 begins with STA 1506 transmitting a PPDU 1510 on the PCH to STA 1508 (not shown in FIG. 15). As AP 1502 and STA 1504 operate on the PCH, AP 1502 and STA 1504 may (in parallel) detect / sense the transmission of PPDU 1510 and begin to decode (read, detect, process, parse, or receive) PPDU 1510. In an example, AP 1502 and STA 1504 may decode (read, detect, process, parse, or receive) a PHY identifier field of PPDU 1510, which allows AP 1502 and STA 1504 to determine a PPDU type of PPDU 1510.

[0147] Next, in an embodiment, AP 1502 and STA 1504 may decode (read, detect, process, parse, or receive) a preamble / PHY header of PPDU 1510 to determine if PPDU 1510 is an intra-BSS DL PPDU. As described above, AP 1502 and STA 1504 may decode (read, detect, process, parse, or receive) a BSS color field of a SIG field of the preamble / PHY header to determine whether PPDU 1510 is an intra-BSS PPDU. In example 1500, AP 1502 and STA 1504 may determine that PPDU 1510 is an intra-BSS PPDU based on the BSS color field indicating a BSS color (or a BSSID) of AP 1502.Docket No.: 24-3040PCT

[0148] In an embodiment, AP 1502 may decode (read, detect, process, parse, or receive) an UL / DL flag of the SIG field to determine whether PPDU 1510 is a DL PPDU. In example 1500, AP 1502 may determine that PPDU 1510 is a DL PPDU based on the UL / DL flag being to set to DL (or a value corresponding to DL). Additionally, or alternatively, AP 1502 may decode (read, detect, process, parse, or receive) a P2P flag of the SIG field to determine whether PPDU 1510 is a P2P PPDU. In example 1500, AP 1502 may determine that PPDU 1510 is a P2P PPDU based on the P2P flag being to set to 1 (or a value corresponding to P2P). In an example, PPDU 1510 may be transmitted by another AP with the same BSS color as AP 1502. Without the P2P flag, AP 1502 may determine wrongly that PPDU 1510 is a P2P PPDU. The P2P may thus be useful in such a case for the AP to identify P2P PPDUs.

[0149] In an embodiment, STA 1504 may decode (read, detect, process, parse, or receive) a P2P flag of the SIG field to determine whether PPDU 1510 is a P2P PPDU. In example 1500, STA 1504 may determine that PPDU 1510 is a P2P PPDU based on the P2P flag being to set to 1 (or a value corresponding to P2P). Optionally, STA 1504 may decode (read, detect, process, parse, or receive) an UL / DL flag of the SIG field to determine whether PPDU 1510 is a DL PPDU. In example 1500, STA 1504 may determine that PPDU 1510 is a DL PPDU based on the UL / DL flag being to set to DL (or a value corresponding to DL). Additionally, STA 1504 may decode (read, detect, process, parse, or receive) a field (e.g., STA ID) of the SIG field that indicates a receiver of PPDU 1510. In example 1500, STA 1504 may determine that PPDU 1510 is addressed to STA 1508 and not to STA 1504.

[0150] Continuing with example 1500, after determining that PPDU 1510 is an intra-BSS DL / P2P PPDU, AP 1502 switches from the PCH to the NPCA PCH. Similarly, after determining that PPDU 1510 is an intra- BSS P2P PPDU not addressed to STA 1504, STA 1504 switches from the PCH to the NPCA PCH. In an embodiment, AP 1502 and STA 1504 may be configured to switch to the NPCA PCH at the same switching time. The switching time may correspond to the time that AP 1502 and STA 1504 finish decoding / reading the SIG field of PPDU 1510, for example. However, other switching times may also be configured or negotiated / agreed between AP 1502 and STA 1504.

[0151] Subsequently, AP 1502 may access the NPCA PCH and transmit a frame 1512 to STA 1504. Frame 1512 may be similar to frame 1312 described above. STA 1504 may respond to frame 1512 from AP 1502 by transmitting a frame 1514 to AP 1502. Frame 1514 may be similar to frame 1512 described above. AP 1502 may then transmit a frame 1516 to STA 1504. Frame 1516 may be similar to frame 1316 described above. STA 1504 may respond to frame 1516 by transmitting a frame 1518 to AP 1502. Frame 1518 may be similar to frame 1318 described above. As such, communication between AP 1502 and STA 1504 may occur on the NPCA PCH during at least the transmission time of PPDU 1510 by STA 1506 to STA 1508 on the PCH. This allows for buffered traffic between AP 1502 and STA 1504 to be transmitted with minimal delay and avoids NPCA PCH resources from being wasted. Further, STA 1504 only switches to the NPCA PCHDocket No.: 24-3040PCT when PPDU 1510 is a P2P PPDU (and not any DL PPDU) guaranteeing that communication with AP 1502 can take place via the NPCA PCH.

[0152] In an embodiment, AP 1502 and STA 1504 may switch to the NPCA PCH as described above, without determining the duration information (NAV / TXOP duration) associated with PPDU 1510. Accordingly, AP 1502 and STA 1504 may be configured to finish communicating on the NPCA PCH and return to the PCH before an end of PPDU 1510. In another embodiment, AP 1502 and STA 1504 may only switch to the NPCA PCH after determining the NAV / TXOP duration associated with PPDU 1510. As such, AP 1502 and STA 1504 may be configured to return to the PCH before an end of the NAV / TXOP duration associated with PPDU 1510.

[0153] FIG. 16 shows an example 1800 that illustrates an example NPCA operation according to an embodiment. Example 1800 also includes AP 1302, STA 1304, and STA 1306 described above in FIG. 13. As explained in FIG. 13, AP 1302 and STA 1304 may only switch to the NPCA PCH after determining the NAV / TXOP duration associated with PPDU 1310. As such, AP 1302 and STA 1304 may be configured to return to the PCH before an end of the NAV / TXOP duration associated with PPDU 1310 based on the NAV / TXOP duration. In example 1800, AP 1302 and STA 1304 may be configured to operate on the NPCA PCH until an end of the NAV / TXOP duration associated with PPDU 1310 based on the NAV / TXOP duration.

[0154] FIG. 17 shows an example 1700 that illustrates an example NPCA operation according to an embodiment. Example 1700 also includes AP 1302, STA 1304, and STA 1306 described above in FIG. 13. In FIG. 17, AP 1302 transmits a DL PPDU 1710 to STA 1306. When STA 1304 receives DL PPDU 1710, if STA 1304 detects / determines that PPDU 1710 is an intra-BSS DL PPDU, STA 1304 may determine to switch to the NPCA PCH at the NPCA PCH switch time. After switching to the NPCA PCH, if STA 1304 does not receive a frame from AP 1302 (or does not communicate with AP 1302) on the NPCA PCH during a specific time period, STA 1304 may be configured to return to the PCH from the NPCA PCH before an end of duration ( / length) of PPDU 1710 associated with PPDU 1710. In an example, the specific time period is based / determined based on the duration / length of PPDU 1710. For example, the specific time period may equal to or less than the duration / length of PPDU 1710. After switching to the NPCA PCH, STA 1304 may transmit one or more frames (e.g., frame 1712, 1714, 1716 in FIG. 17) to AP 1302 on the NPCA PCH before returning to the PCH. In an embodiment, based on STA 1304 not receiving a response to the one or more frames, STA 1304 may determine that AP 1302 did not switch to the NPCA PCH based on PPDU 1710. In an embodiment, based on determining that AP 1302 did not switch to the NPCA PCH, STA 1304 may determine that AP transmitted PPDU 1710.

[0155] FIG. 18 shows an example 1800 that illustrates an example NPCA operation according to an embodiment. Example 1800 also includes AP 1302, STA 1304, and STA 1306 described above in FIG. 13. In FIG. 18, STA 1306 transmits PPDU 1310 to STA 1308. When AP 1302 receives PPDU 1310, if AP 1302 detects / determines that PPDU 1310 is an intra-BSS DL PPDU, AP 1302 may determine to switch to NPCADocket No.: 24-3040PCTPCH at the NPCA PCH switch time. After switching to NPCA PCH, if AP 1302 does not receive a frame from STA 1304 (or does not communicate with STA 1304) on the NPCA PCH during a specific time period, AP 1302 may be configured to return to the PCH from the NPCA PCH before an end of duration ( / length) of PPDU 1310 associated with PPDU 1310. In an example, the specific time period is based / determined based on the duration / length of PPDU 1310. For example, the specific time period may be equal to or less than the duration / length of PPDU 1310. After switching to the NPCA PCH, AP 1302 may transmit one or more frames (e.g., frame 1812, 1814, 1816 in FIG. 18) to STA 1304 on the NPCA PCH before returning to the PCH. In an embodiment, based on AP 1302 not receiving a response to the one or more frames, AP 1302 may determine that STA 1304 did not switch to the NPCA PCH based on PPDU 1310.

[0156] FIG. 19 illustrates an example process 1900 according to an embodiment. Example process 1900 is provided for the purpose of illustration only and is not limiting of embodiments. Example process 1900 may be performed by an AP, such as AP 1302 or AP 1502, for example. As shown in FIG. 19, example process 1900 may include steps 1902 and 1904.

[0157] Step 1902 includes detecting, by the AP and via a primary channel (PCH), a PPDU. In an embodiment, step 1902 includes detecting an intra-BSS DL PPDU. In another embodiment, step 1904 includes detecting an inter-BSS DL PPDU.

[0158] Step 1904 includes, after detecting the PPDU, switching, by the AP, from the PCH to a non-primary channel access (NPCA) PCH. In an embodiment, the switching from the PCH to the NPCA PCH may be based on a first NPCA mode associated with the AP and / or a second NPCA mode associated with a first station (STA). The first STA may be a STA associated with the AP.

[0159] In an embodiment, the detecting of the intra-BSS DL PPDU in step 1902 comprises receiving a PPDU indicating a downlink transmission and transmitted by a second STA to a third STA, where the second STA and the third STA belong to a BSS of the AP. In an embodiment, the detecting of the inter-BSS DL PPDU comprises receiving a PPDU indicating a downlink transmission and transmitted by another AP.

[0160] In an embodiment, the detecting of the PPDU comprises decoding a signal (SIG) field of the PPDU. In an embodiment, the PPDU comprises a preamble part (or a PHY header) that comprises the SIG field. In an embodiment, where the PPDU comprises an extremely high throughput (EHT) PPDU, an ultra-high reliability (UHR) PPDU, or a UHR+ PPDU, the SIG field may comprise a universal SIG (U-SIG) field of the PPDU. In an embodiment, where the PPDU comprises a high efficiency (HE) PPDU, the SIG field may comprise an HE-SIG-A field of the PPDU.

[0161] In an embodiment, the SIG field comprises a BSS color field set to a BSS color of the AP. In an embodiment, the SIG field comprises an uplink (UL)Zdownlink (DL) flag field set to DL. In an embodiment, the switching from the PCH to the NPCA PCH in step 1904 is based on the UL / DL flag being set to a first value indicating DL. In an embodiment, process 1900 may further comprise classifying the PPDU as an inter-BSS PPDU based on the UL / DL flag being set to the first value indicating DL.Docket No.: 24-3040PCT

[0162] In an embodiment, the detecting of the PPDU in step 1902 comprises decoding one or more MPDU of the PPDU.

[0163] In an embodiment, the PPDU comprises a TXOP field indicating duration information. In an embodiment, process 1900 may further comprise setting, by the AP, a NAV for the PCH based on the duration information. The TXOP field may indicate a value of 0; a non-zero value; or a value of UNSPECIFIED.

[0164] In an embodiment, where the PPDU comprises an intra-BSS DL PPDU, process 1900 may further comprise determining, by the AP, that the intra-BSS DL PPDU comprises a peer-to-peer PPDU.

[0165] In an embodiment, according to the first NPCA mode the AP switches from the PCH to the NPCA PCH after detecting a first intra-BSS DL PPDU (or a first inter-BSS DL PPDU). In an embodiment, the switching from the PCH to the NPCA PCH based on the first NPCA mode comprises switching from the PCH to the NPCA PCH based on the AP supporting (and / or enabling) the first NPCA mode. In an embodiment, the switching from the PCH to the NPCA PCH comprises the AP operating (or camping / parking) on the NPCA PCH.

[0166] In an embodiment, where the PPDU comprises an intra-BSS DL PPDU, the intra-BSS DL PPDU indicates a peer-to-peer (P2P) transmission. In an embodiment, the P2P transmission is indicated in a preamble part (or a PHY header) of the intra-BSS DL PPDU. In an embodiment, the P2P transmission is indicated in a signal (SIG) field of the intra-BSS DL PPDU. In an embodiment, the first STA switches from the PCH to the NPCA PCH based on the intra-BSS DL PPDU indicating the P2P transmission.

[0167] In an embodiment, according to the second NPCA mode, the first STA switches from the PCH to the NPCA PCH after detecting a second intra-BSS DL PPDU (or a second inter-BSS DL PPDU). In an embodiment, according to the second NPCA mode, the first STA switches from the PCH to the NPCA PCH based on the second intra-BSS DL PPDU not being addressed to the first STA.

[0168] In an embodiment, the switching, by the AP, from the PCH to the NPCA PCH based on the second NPCA mode in step 1902 comprises switching from the PCH to the NPCA PCH based on the first STA supporting the second NPCA mode.

[0169] In an embodiment, process 1900 may further comprise transmitting, by the AP, a first frame indicating whether the AP supports the first NPCA mode. The first frame may comprise a beacon frame, a broadcast probe response frame, a fast initial link setup (FILS) discovery frame, a traffic indication map (TIM) broadcast frame, or a broadcast / multicast frame.

[0170] In an embodiment, process 1900 may further comprise receiving, by the AP from the first STA, a second frame indicating whether the first STA supports the second NPCA mode. In an embodiment, the second frame further indicates enablement ( / activation) of the second NPCA mode by the first STA. The second frame may comprise a probe request frame, an association request frame, a reassociation request frame, a request frame, a management frame, an action frame, a control frame, a quality of service (QoS) null frame, or a QoS data frame.Docket No.: 24-3040PCT

[0171] In an embodiment, process 1900 may further comprise, in response to the second frame, transmitting, by the AP to the first STA, a third frame indicating whether the AP supports the first NPCA mode. In an embodiment, the third frame further indicates enablement ( / activation) of the first NPCA mode by the AP. The third frame may comprise a probe response frame, an association response frame, a reassociation response frame, a response frame, a management frame, an action frame, a control frame, a quality of service (QoS) null frame, or a QoS data frame.

[0172] In an embodiment, process 1900 may further comprise switching, by the AP, from the NPCA PCH to the PCH before an end of the PPDU, an end of a network allocation vector (NAV) determined based on the PPDU, or an end of a transmit opportunity (TXOP) associated with the PPDU. In an embodiment, the switching, by the AP, from the NPCA PCH to the PCH comprises the AP operating ( / park! ng / camping) on the PCH.

[0173] In an embodiment, process 1900 may further comprise communicating, by the AP and during a duration of the PPDU, with the first STA on the NPCA PCH.

[0174] FIG. 20 illustrates another example process 2000 according to an embodiment. Example process 2000 is provided for the purpose of illustration only and is not limiting of embodiments. Example process 2000 may be performed by a first STA, such as STA 1304 or STA 1504, for example. As shown in FIG. 20, example process 2000 may include steps 2002 and 2004. The first STA may be associated with an AP.

[0175] Step 2002 includes detecting, by the first STA and via a primary channel (PCH), an intra-BSS DL PPDU.

[0176] Step 2004 includes, after detecting the intra-BSS DL PPDU, switching, by the first STA, from the PCH to a non-primary channel access (NPCA) PCH. In an embodiment, the switching from the PCH to the NPCA PCH may be based on a first NPCA mode associated with the AP and / or a second NPCA mode associated with the first STA.

[0177] In an embodiment, the detecting of the intra-BSS DL PPDU in step 2002 comprises receiving a PPDU indicating a downlink transmission and transmitted by a second STA to a third STA, where the second STA and the third STA belong to a BSS of the AP (or the first STA).

[0178] In an embodiment, the detecting of the intra-BSS DL PPDU comprises decoding a signal (SIG) field of the intra-BSS DL PPDU . In an embodiment, the intra-BSS DL PPDU comprises a preamble part (or a PHY header) that comprises the SIG field. In an embodiment, where the intra-BSS DL PPDU comprises an extremely high throughput (EHT) PPDU, an ultra-high reliability (UHR) PPDU, or a UHR+ PPDU, the SIG field may comprise a universal SIG (U-SIG) field of the intra-BSS DL PPDU. In an embodiment, where the intra-BSS DL PPDU comprises a high efficiency (HE) PPDU, the SIG field may comprise an HE-SIG-A field of the intra-BSS DL PPDU.

[0179] In an embodiment, the SIG field comprises a BSS color field set to a BSS color of the AP. In an embodiment, the SIG field comprises an uplink (UL)Zdownlink (DL) flag field set to DL.Docket No.: 24-3040PCT

[0180] In an embodiment, the detecting of the intra-BSS DL PPDU in step 2002 comprises decoding one or more MPDU of the intra-BSS DL PPDU.

[0181] In an embodiment, the intra-BSS DL PPDU comprises a TXOP field indicating duration information. In an embodiment, process 2000 may further comprise setting, by the first STA, a NAV for the PCH based on the duration information. The TXOP field may indicate a value of 0; a non-zero value; or a value of UNSPECIFIED.

[0182] In an embodiment, process 2000 may further comprise determining, by the first STA, that the intra- BSS DL PPDU comprises a peer-to-peer PPDU.

[0183] In an embodiment, according to the second NPCA mode, the first STA switches from the PCH to the NPCA PCH after detecting a first intra-BSS DL PPDU. In an embodiment, according to the second NPCA mode, the first STA switches from the PCH to the NPCA PCH based on the second intra-BSS DL PPDU not being addressed to the first STA. In an embodiment, the switching by the first STA from the PCH to the NPCA PCH based on the second NPCA mode comprises switching from the PCH to the NPCA PCH based on the first STA supporting (and / or enabling) the second NPCA mode. In an embodiment, the switching by the first STA from the PCH to the NPCA PCH comprises the first STA operating (or camping / parking) on the NPCA PCH.

[0184] In an embodiment, the intra-BSS DL PPDU indicates a peer-to-peer (P2P) transmission. In an embodiment, the P2P transmission is indicated in a preamble part (or a PHY header) of the intra-BSS DL PPDU. In an embodiment, the P2P transmission is indicated in a signal (SIG) field of the intra-BSS DL PPDU. In an embodiment, the switching by first STA from the PCH to the NPCA PCH is based on the intra-BSS DL PPDU indicating the P2P transmission.

[0185] In an embodiment, according to the first NPCA mode, the AP switches from the PCH to the NPCA PCH after detecting a second intra-BSS DL PPDU. In an embodiment, the switching by the first STA from the PCH to the NPCA PCH based on the first NPCA mode comprises switching from the PCH to the NPCA PCH based on the AP supporting (and / or enabling) the first NPCA mode.

[0186] In an embodiment, process 2000 may further comprise receiving, by the first STA from the AP, a first frame indicating whether the AP supports the first NPCA mode. The first frame may comprise a beacon frame, a broadcast probe response frame, a fast initial link setup (FILS) discovery frame, a traffic indication map (TIM) broadcast frame, or a broadcast / multicast frame.

[0187] In an embodiment, process 2000 may further comprise transmitting, by the first STA to the AP, a second frame indicating whether the first STA supports the second NPCA mode. In an embodiment, the second frame further indicates enablement ( / activation) of the second NPCA mode by the first STA. The second frame may comprise a probe request frame, an association request frame, a reassociation request frame, a request frame, a management frame, an action frame, a control frame, a quality of service (QoS) null frame, or a QoS data frame.Docket No.: 24-3040PCT

[0188] In an embodiment, process 2000 may further comprise, in response to the second frame, receiving, by the first STA from the AP, a third frame indicating whether the AP supports the first NPCA mode. In an embodiment, the third frame further indicates enablement ( / activation) of the first NPCA mode by the AP. The third frame may comprise a probe response frame, an association response frame, a reassociation response frame, a response frame, a management frame, an action frame, a control frame, a quality of service (QoS) null frame, or a QoS data frame.

[0189] In an embodiment, process 2000 may further comprise switching, by the first STA, from the NPCA PCH to the PCH before an end of the intra-BSS DL PPDU, an end of a network allocation vector (NAV) determined based on the intra-BSS DL PPDU, or an end of a transmit opportunity (TXOP) associated with the intra-BSS DL PPDU. In an embodiment, the switching, by the first STA, from the NPCA PCH to the PCH comprises the first STA operating ( / parking / camping) on the PCH.

[0190] In an embodiment, process 2000 may further comprise communicating, by the first STA and during a duration of the intra-BSS DL PPDU, with the AP on the NPCA PCH.

Claims

Docket No.: 24-3040PCTCLAIMSWhat is claimed is:

1. A method comprising: detecting, by an access point (AP) and via a primary channel (PCH), a physical layer protocol data unit (PPDU); based on an uplink (UL)Zdownlink (DL) flag of the PPDU being set to a first value indicating DL, switching, by the AP, from the PCH to a non-primary channel access (NPCA) PCH; and communicating, by the AP and during a duration of the PPDU, with a station (STA) on the NPCA PCH.

2. A method comprising: detecting, by an access point (AP) and via a primary channel (PCH), a physical layer protocol data unit (PPDU); and based on an uplink (UL)Zdownlink (DL) flag, of the PPDU, being set to a first value indicating DL, switching, by the AP, from the PCH to a non-primary channel access (NPCA) PCH.

3. The method of claim 2, wherein the PPDU is transmitted by another AP.

4. The method of any of claims 2-3, wherein the detecting of the PPDU comprises decoding a signal (SIG) field of the PPDU.

5. The method of claim 4, wherein the PPDU comprises a preamble part, and wherein the preamble part comprises the SIG field.

6. The method of claim 5, wherein the PPDU comprises an extremely high throughput (EHT) PPDU, an ultra-high reliability (UHR) PPDU, or a UHR+ PPDU, and wherein the SIG field comprises a universal SIG (U-SIG) field of the PPDU.

7. The method of claim 5, wherein the PPDU comprises a high efficiency (HE) PPDU, and wherein the SIG field comprises an HE-SIG-A field of the PPDU.

8. The method of any of claims 4-7, wherein the SIG field comprises a BSS color field set to a BSS color of the AP.

9. The method of any of claims 4-8, wherein the SIG field comprises the ULZDL flag.

10. The method of any of claims 2-3, wherein the detecting of the PPDU comprises decoding one or more medium access control (MAC) protocol data unit (MPDU) of the PPDU.

11. The method of any of claims 2-10, wherein the PPDU comprises a transmission opportunity (TXOP) field indicating duration information.

12. The method of claim 11 , further comprising setting, by the AP, a network allocation vector (NAV) for the PCH based on the duration information.

13. The method of any of claims 11 -12, wherein the TXOP field indicates: a value of 0;Docket No.: 24-3040PCT a non-zero value; or a value of UNSPECIFIED.

14. The method of any of claims 2-13, wherein according to a first NPCA mode the AP switches from the PCH to the NPCA PCH after detecting a first inter-BSS DL PPDU.

15. The method of claim 14, wherein the switching from the PCH to the NPCA PCH is based on the AP supporting and / or enabling the first NPCA mode.

16. The method of any of claims 14-15, further comprising transmitting, by the AP, a first frame indicating whether the AP supports the first NPCA mode.

17. The method of claim 16, wherein the first frame comprises a beacon frame, a broadcast probe response frame, a fast initial link setup (FILS) discovery frame, a traffic indication map (TIM) broadcast frame, or a broadcast / multicast frame.

18. The method of any of claims 2-15, wherein the switching from the PCH to the NPCA PCH comprises the AP operating on the NPCA PCH.

19. The method of any of claims 2-18, further comprising switching, by the AP, from the NPCA PCH to the PCH before an end of the PPDU, an end of a network allocation vector (NAV) determined based on the PPDU, or an end of a transmit opportunity (TXOP) associated with the PPDU.

20. The method of claim 19, wherein the switching, by the AP, from the NPCA PCH to the PCH comprises the AP operating on the PCH.21 . The method of any of claims 2-20, further comprising communicating, by the AP and during a duration of the PPDU, with a first STA on the NPCA PCH.

22. The method of claim 21 , wherein the first STA is associated with the AP.

23. A method comprising: transmitting, by a first station (STA) to an access point (AP), a first frame indicating enablement of a first non-primary channel access (NPCA) mode for the first STA, wherein according to the first NPCA mode, the first STA switches from a primary channel (PCH) to an NPCA PCH after receiving a first intra-basic service set (BSS) downlink (DL) physical layer protocol data unit (PPDU) not addressed to the first STA; receiving, by the first STA from the AP, a second frame indicating enablement of a second NPCA mode for the AP, wherein according to the second NPCA mode, the AP switches from the PCH to the NPCA PCH after detecting a second intra-BSS DL PPDU; detecting, by the first STA and via the PCH, a third intra-BSS DL PPDU; after detecting the third intra-BSS DL PPDU, switching, by the first STA, from the PCH to the NPCA PCH based on the first and the second NPCA modes being enabled; and communicating, by the first STA and during a duration of the third intra-BSS DL PPDU, with the AP on the NPCA PCH.

24. A method comprising:Docket No.: 24-3040PCT detecting, by a first station (STA) and via a primary channel (PCH), an intra-basic service set (intra- BSS) downlink (DL) physical layer protocol data unit (PPDU); and after detecting the intra-BSS DL PPDU, switching, by the first STA, from the PCH to a non-primary channel access (NPCA) PCH based on a first NPCA mode associated with an access point (AP) and a second NPCA mode associated with the first STA.

25. The method of claim 24, wherein the detecting of the intra-BSS DL PPDU by the first STA comprises receiving a PPDU indicating a downlink transmission and transmitted by a second STA to a third STA, wherein the second STA and the third STA belong to a basic service set (BSS) of the first STA.

26. The method of any of claims 24-25, wherein the detecting of the intra-BSS DL PPDU comprises decoding a signal (SIG) field of the intra-BSS DL PPDU.

27. The method of claim 26, wherein the intra-BSS DL PPDU comprises a preamble part (or a PHY header), and wherein the preamble part (or PHY header) comprises the SIG field.

28. The method of claim 27, wherein the intra-BSS DL PPDU comprises an extremely high throughput (EHT) PPDU, an ultra-high reliability (UHR) PPDU, or a UHR+ PPDU, and wherein the SIG field comprises a universal SIG (U-SIG) field of the intra-BSS DL PPDU.

29. The method of claim 27, wherein the intra-BSS DL PPDU comprises a high efficiency (HE) PPDU, and wherein the SIG field comprises an HE-SIG-A field of the intra-BSS DL PPDU.

30. The method of any of claims 26-29, wherein the SIG field comprises a BSS color field set to a BSS color of the AP.31 . The method of any of claims 26-30, wherein the SIG field comprises an uplink (UL)Zdownlink (DL) flag field set to DL.

32. The method of any of claims 24-25, wherein the detecting of the intra-BSS DL PPDU comprises decoding one or more medium access control (MAC) protocol data unit (MPDU) of the intra-BSS DL PPDU.

33. The method of any of claims 24-32, wherein the intra-BSS DL PPDU comprises a transmission opportunity (TXOP) field indicating duration information.

34. The method of claim 33, further comprising setting, by the first STA, a network allocation vector (NAV) for the PCH based on the duration information.

35. The method of any of claims 33-34, wherein the TXOP field indicates: a value of 0; a non-zero value; or a value of UNSPECIFIED.

36. The method of any of claims 24-35, wherein according to the second NPCA mode the first STA switches from the PCH to the NPCA PCH after detecting a first intra-BSS DL PPDU.Docket No.: 24-3040PCT37. The method of claim 36, wherein according to the second NPCA mode the first STA switches from the PCH to the NPCA PCH based on the second intra-BSS DL PPDU not being addressed to the first STA.

38. The method of any of claims 36-37, wherein the switching from the PCH to the NPCA PCH based on the second NPCA mode comprises switching from the PCH to the NPCA PCH based on the first STA supporting and / or enabling the second NPCA mode.

39. The method of any of claims 24-38, wherein the switching from the PCH to the NPCA PCH comprises the first STA operating on the NPCA PCH.

40. The method of any of claims 24-39, wherein the intra-BSS DL PPDU indicates a peer-to-peer (P2P) transmission.

41. The method of claim 40, wherein the P2P transmission is indicated in a preamble part (or a PHY Header) of the intra-BSS DL PPDU .

42. The method of any of claims 40-41 , wherein the P2P transmission is indicated in a signal (SIG) field of the intra-BSS DL PPDU.

43. The method of any of claims 40-42, further comprising switching, by the first STA, from the PCH to the NPCA PCH based on the intra-BSS DL PPDU indicating the P2P transmission.

44. The method of any of claims 24-43, wherein according to the first NPCA mode the AP switches from the PCH to the NPCA PCH after detecting a second intra-BSS DL PPDU.

45. The method of any of cl aims 24-44, wherein the switching, by the STA, from the PCH to the NPCA PCH based on the first NPCA mode comprises switching from the PCH to the NPCA PCH based on the AP supporting and / or enabling the first NPCA mode.

46. The method of any of claims 24-45, further comprising receiving, by the first STA from the AP, a first frame indicating whether the AP supports the first NPCA mode.

47. The method of claim 46, wherein the first frame comprises a beacon frame, a broadcast probe response frame, a fast initial link setup (FILS) discovery frame, a traffic indication map (TIM) broadcast frame, or a broadcast / multicast frame.

48. The method of any of claims 24-47, further comprising: transmitting, by the first STA to the AP, a second frame indicating whether the first STA supports the second NPCA mode; and in response to the second frame, receiving, by the first STA from the AP, a third frame indicating whether the AP supports the first NPCA mode.

49. The method of claim 48, wherein the second frame further indicates enablement of the second NPCA mode by the first STA.

50. The method of any of claims 48-49, wherein the second frame comprises a probe request frame, an association request frame, a reassociation request frame, a request frame, a management frame, an action frame, a control frame, a quality of service (QoS) null frame, or a QoS data frame.Docket No.: 24-3040PCT51. The method of any of claims 48-50, wherein the third frame further indicates enablement of the first NPCA mode by the AP.

52. The method of any of claims 48-51 , wherein the third frame comprises a probe response frame, an association response frame, a reassociation response frame, a response frame, a management frame, an action frame, a control frame, a quality of service (QoS) null frame, or a QoS data frame.

53. The method of any of claims 24-52, further comprising switching, by the first STA, from the NPCA PCH to the PCH before an end of the intra-BSS DL PPDU, an end of a network allocation vector (NAV) determined based on the intra-BSS DL PPDU, or an end of a transmit opportunity (TXOP) associated with the intra-BSS DL PPDU.

54. The method of claim 53, wherein the switching, by the first STA, from the NPCA PCH to the PCH comprises the first STA operating on the PCH.

55. The method of any of claims 24-54, further comprising communicating, by the first STA and during a duration of the intra-BSS DL PPDU, with the AP on the NPCA PCH.

56. The method of any of claims 24-55, further comprising determining, by the first STA, that the intra-BSS DL PPDU comprises a peer-to-peer PPDU.

57. The method of any of claims 24-56, wherein the first STA is associated with the AP.

58. 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-57.

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

Images