Non-primary channel access (NPCA) operation during coordinated time-division multiple access (CTDMA) procedure

Abstract

A first access point (AP) transmits to a second AP a multi-user request-to-send (MU-RTS) triggered transmission opportunity sharing (TXS) trigger frame indicating: sharing, by the first AP with the second AP, of a time portion of a transmission opportunity (TXOP) obtained by the first AP on a primary channel (PCH); and a duration of the time portion of the TXOP. The first AP disables a non-primary channel access (NPCA) mode of operation at a start time of the time portion of the TXOP, and enables the NPCA mode of operation at an end time of the time portion of the TXOP.

Description

Docket No.: 24-3059PCTTITLENON-PRIMARY CHANNEL ACCESS (NPCA) OPERATION DURING COORDINATED TIME-DIVISION MULTIPLE ACCESS (CTDMA) PROCEDURECROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 730,489, filed December 11 , 2024, which is hereby incorporated by reference in its entirety.BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Examples of several of the various embodiments of the present disclosure are described herein with reference to the drawings.

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

[0004] FIG. 2 is a block diagram illustrating example implementations of a station (STA) and an access point (AP).

[0005] FIG. 3 illustrates an example Medium Access Control (MAC) frame format.

[0006] FIG. 4 illustrates an example management frame which may be used as an action frame.

[0007] FIG. 5 illustrates an example control frame which may be used as a trigger frame.

[0008] FIG. 6 illustrates an example data frame which may be used as a Quality of Service (QoS) null frame.

[0009] FIG. 7 illustrates an example format of a physical layer (PHY) protocol data unit (PPDU).

[0010] FIG. 8 illustrates an example multi-AP network.

[0011] FIG. 9 illustrates an example network that includes a coordinated AP set.

[0012] FIG. 10 illustrates an example multi-AP operation procedure.

[0013] FIG. 11 illustrates an example of enhanced distributed channel access (EDCA) and CTDMA.

[0014] FIG. 12 illustrates an example of multi-AP coordination operation using coordinated time-division multiple access (CTDMA) procedure.

[0015] FIG. 13 illustrates an example clear to send (CTS) frame format.

[0016] FIG. 14 illustrates an example of a multi-user request-to-send (MU-RTS) trigger frame which may be used in a triggered transmit opportunity (TXOP) sharing (TXS) procedure.

[0017] FIG. 15 illustrates an example of a triggered TXS procedure (Mode =1).

[0018] FIG. 16 illustrates an example of a triggered TXS procedure (Mode =2).

[0019] FIG. 17 illustrates an example of an existing CTDMA procedure.

[0020] FIG. 18 illustrates another example of an existing CTDMA procedure.

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

[0022] FIG. 20 is an example that illustrates an MU-RTS / CTS procedure.

[0023] FIG. 21 is an example that illustrates non-primary channel access (NPCA) operation.Docket No.: 24-3059PCT

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

[0025] FIG. 23 shows an example that illustrates NPCA operation.

[0026] FIG. 24 shows an example that illustrates a problem that may arise using NPCA operation during a CTDMA procedure.

[0027] FIG. 25 shows an example that illustrates an operation according to an embodiment.

[0028] FIG. 26 shows an example that illustrates an operation according to an embodiment.

[0029] FIG. 27 shows an example that illustrates an operation according to an embodiment.

[0030] FIG. 28 shows an example that illustrates an operation according to an embodiment.

[0031] FIG. 29 illustrates an example process according to an embodiment of the present disclosure.

[0032] FIG. 30 illustrates an example process according to an embodiment of the present disclosure.

[0033] FIG. 31 illustrates an example process according to an embodiment of the present disclosure.

[0034] FIG. 32 illustrates an example process according to an embodiment of the present disclosure.DETAILED DESCRIPTION

[0035] In the present disclosure, various embodiments are presented as examples of how the disclosed techniques may be implemented and / or how the disclosed techniques may be practiced in environments and scenarios. It will be apparent to persons skilled in the relevant art that various changes in form and detail can be made therein without departing from the scope. After reading the description, it will be apparent to one skilled in the relevant art how to implement alternative embodiments. The present embodiments may not be limited by any of the described exemplary embodiments. The embodiments of the present disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments may be combined to create further embodiments within the scope of the disclosure. Any figures which highlight the functionality and advantages, are presented for example purposes only. The disclosed architecture is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown. For example, the actions listed in any flowchart may be re-ordered or only optionally used in some embodiments.

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

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

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

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

[0040] In this disclosure, parameters (or equally called, fields, or Information elements: lEs) may comprise one or more information objects, and an information object may comprise one or more other objects. For example, if parameter (IE) N comprises parameter (IE) M, and parameter (IE) M comprises parameter (IE) K, and parameter (IE) K comprises parameter (information element) J. Then, for example, N comprises K,Docket No.: 24-3059PCT 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.

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

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

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

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

[0045] BSS 110-1 and 110-2 each includes a set of an access point (AP or AP STA) and at least one station (STA or non-AP STA). For example, BSS 110-1 includes an AP 104-1 and a STA 106-1 , and BSS 1 10-2 includes an AP 104-2 and STAs 106-2 and 106-3. The AP and the at least one STA in a BSS perform an association procedure to communicate with each other.Docket No.: 24-3059PCT

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

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

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

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

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

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

[0052] A frequency band may include one or more sub-bands or frequency channels. For example, PPDUs conforming to the IEEE 802.11 n, 802.1 1ac, 802.11 ax and / or 802.11 be standard amendments may be transmitted over the 2.4 GHz, 5 GHz, and / or 6 GHz bands, each of which may be divided into multiple 20 MHz channels. The PPDUs may be transmitted over a physical channel having a minimum bandwidth of 20 MHz. Larger channels may be formed through channel bonding. For example, PPDUs may be transmitted over physical channels having bandwidths of 40 MHz, 80 MHz, 160 MHz, or 520 MHz by bonding together multiple 20 MHz channels.

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

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

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

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

[0057] FIG. 3 illustrates an example format of a MAC frame 300. 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.Docket No.: 24-3059PCT

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

[0059] The MAC header includes a frame control field, an optional duration / ID field (not in PS-Poll frames), address fields, an optional sequence control field, an optional QoS control field (only in QoS Data frames), and an optional high throughput (HT) control field (only in +HTC frames).

[0060] 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 high throughput control (+HTC).

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

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

[0063] The To DS subfield indicates whether a data frame is destined to the DS. The From DS subfield indicates whether a data frame originates from the DS.

[0064] The more fragments subfield is set to 1 in all data or management frames that have another fragment to follow of the MAC service data unit (MSDU) or MAC management protocol data unit (MMPDU) carried by the MAC frame. It is set to 0 in all other frames in which the more fragments subfield is present.

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

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

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

[0068] The protected frame subfield is set to 1 if the frame body field contains information that has been processed by a cryptographic encapsulation algorithm.Docket No.: 24-3059PCT

[0069] The +HTC subfield indicates that MAC frame 300 contains an HT control field. A frame that contains the HT Control field is referred to as a +HTC frame. A Control Wrapper frame is a +HTC frame.

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

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

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

[0073] The QoS control field identifies the traffic category (TC) or traffic stream (TS) to which MAC frame 300 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.

[0074] 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. The control frame subtype for which HT control field is present is the control wrapper frame. A control frame that is described as +HTC (e.g., a request to send (RTS)+HTC, clear to send (CTS)+HTC, block acknowledgment (BlockAck)+HTC or block acknowledgment request (BlockAckReq)+HTC frame) implies the use of the control wrapper frame to carry that control frame.Docket No.: 24-3059PCT

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

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

[0077] FIG. 4 illustrates an example management frame 400 which may be used as an action frame. In an example, management frame 400 includes a MAC header, a variable length frame body, and a frame check sequence (FCS). The MAC header includes a frame control field, a duration field, an address 1 field, an address 2 field, an address 3 field, a sequence control field, and an optional HT control field. The presence of the HT control field is determined by the setting of a +HTC subfield of the frame control field.

[0078] As shown in FIG. 4, when used as an action frame, the frame body of management frame includes an action field, vendor specific elements, management message integrity code element (MME), message integrity code (MIC), and an authenticated mesh peering exchange element.

[0079] The action field includes a category field and an action details field. The action field provides a mechanism for specifying extended management actions. The category field indicates a category of the action frame. The action details field contains the details of the action requested by the action frame. For example, the action frame may be a public action frame. As shown in FIG. 4, in the public action frame format, the action details field includes a public action field, in the octet immediately after the category field, followed by a variable length public action details field.

[0080] One or more vendor specific elements are optionally present. These elements are absent when the category subfield of the Action field is vendor-specific.

[0081] The MME is present when management frame protection is negotiated, the frame is a group addressed robust Action frame, and (MBSS only) the category of the action frame does not support group addressed privacy as indicated by category values; otherwise not present.

[0082] The MIC element is present in a self-protected action frame if a shared pairwise master key (PMK) exists between the sender and recipient of this frame; otherwise not present.

[0083] The authenticated mesh peering exchange element is present in a self-protected action frame if a shared PMK exists between the sender and recipient of this frame; otherwise not present.

[0084] FIG. 5 illustrates an example format of a trigger frame 500. Trigger frame 500 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 500 may also carry other information required by a responding STA to transmit a TB PPDU to the AP.

[0085] As shown in FIG. 5, trigger frame 500 includes a Frame Control field, a Duration field, a receiver address (RA) field, a transmitter address (TA) field, a Common Info field, a User Info List field, a Padding field, and an FCS field.Docket No.: 24-3059PCT

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

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

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

[0089] The Common Info field specifies a trigger frame type of trigger frame 500, a transmit power of trigger frame 500 in dBm, and several key parameters of a TB PPDU that is transmitted by a STA in response to trigger frame 500. 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. A non-EHT non-AP HE STA interprets the Common Info field as HE variant. A non-AP EHT STA interprets the Common Info field as HE variant if B54 and B55 in the Common Info field are equal to 1 ; and interprets the Common Info field as EHT variant otherwise. The HE variant Common Info field and the EHT variant Common Info field use the same encoding method for the Trigger Type, UL Length, More TF, CS Required, LDPC Extra Symbol Segment, AP TX Power, Pre-FEC Padding Factor, PE Disambiguity, and Trigger Dependent Common Info subfields.

[0090] The User Info List field contains zero or more User Info fields. There are three variants for the User Info field, which are the Special User Info field, the EHT variant User Info field, and the HE variant User Info field.

[0091] The Special User Info field is a User Info field that does not carry the user specific information but carries the extended common information not provided in the Common Info field. If the Special User Info field is included in the Trigger frame, then the Special User Info Field Flag subfield of the EHT variant Common Info field is set to 0, otherwise it is set to 1 . The Special User Info field is identified by an AID12 value of 2007 and is optionally present in a Trigger frame that is generated by an EHT AP. The Special User Info field, if present, is located immediately after the Common Info field of the Trigger frame and carries information for the U-SIG field of a solicited EHT TB PPDU. The PHY Version Identifier subfield indicates the PHY version of the solicited TB PPDU that is not an HE TB PPDU. The PHY Version Identifier subfield is set to 0 for EHT. Other values from 1 to 7 are reserved. The UL Bandwidth (BW) Extension subfield, together with the UL BW subfield in the Common Info field, indicates the bandwidth of the solicited TB PPDU from the addressed EHT STA (i.e., the bandwidth in the U-SIG field of the EHT TB PPDU). The EHT Spatial Reuse n subfield carriesDocket No.: 24-3059PCT the values to be included in the corresponding Spatial Reuse n subfield in the U-SIG field of the EHT TB PPDU. The U-SIG Disregard And Validate subfield carries the values to be included in the Disregard and Validate subfields of the U-SIG field of the solicited EHT TB PPDUs. The presence and length of the Trigger Dependent User Info subfield in the Special User Info field depends on the variant of the Trigger frame.

[0092] The EHT variant User Info field contains a User Info field per STA addressed in trigger frame 500. The per STA User Info field includes, among others, an AID12 subfield, an RU Allocation subfield, a UL PEC Coding Type subfield, a UL EHT-MCS subfield, a Reserved subfield, a Spatial Stream (SS) Allocation / RA- RU information subfield, a UL Target Receive Power subfield, and a Power Save (PS) 160 subfield to be used by a STA in a TB PPDU transmitted in response to trigger frame 500, and a Trigger Dependent User Info subfield. The RU Allocation subfield in an EHT variant User Info field in a Trigger frame that is not an MU-RTS Trigger frame, along with the UL BW subfield in the Common Info field, the UL BW Extension subfield in the Special User Info field, and the PS160 subfield in the EHT variant User Info field, identifies the size and the location of the RU or MRU. The values of PS160 subfield and B0 of RU Allocation subfield indicate the 80 MHz frequency subblock in which the RU or MRU is located for 26-tone RU, 52-tone RU, 106- tone RU, 242-tone RU, 484-tone RU, 996-tone RU, 52+26-tone RU, and 106+26-tone RU. The values of PS160 subfield indicates the 160 MHz segment in which the RU or MRU is located for 2 996-tone RU, 996+484-tone MRU, and 996+484+242-tone MRU. The UL FEC Coding Type subfield of the User Info field indicates the code type of the solicited EHT TB PPDU. The UL FEC Coding Type subfield is set to 0 to indicate BCC and set to 1 to indicate LDPC. The UL EHT-MCS subfield of the User Info field indicates the EHT-MCS of the solicited EHT TB PPDU. The SS Allocation subfield of the EHT variant User Info field indicates the spatial streams of the solicited EHT TB PPDU. The UL Target Receive Power subfield indicates the expected receive signal power, measured at the AP's antenna connector and averaged over the antennas, for the EHT portion of the EHT TB PPDU transmitted on the assigned RU. 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. The RA-RU Information subfield is reserved in the EHT variant User Info field.

[0093] The Padding field is optionally present in management frame 400 to extend the frame length to give recipient STAs enough time to prepare a response for transmission one SIFS after the frame is received. The Padding field, if present, is at least two octets in length and is set to all 1s.

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

[0095] FIG. 6 illustrates an example data frame 600 which may be used as a QoS null frame. A QoS null frame refers to a QoS data frame with an empty frame body. QoS null frame includes a QoS control field andDocket No.: 24-3059PCT an optional HT control field which may contain a buffer status report (BSR) control subfield. A QoS null frame indicating buffer status information may be transmitted by a STA to an AP.

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

[0097] The TID subfield identifies the TC or TS of traffic for which a TXOP is being requested, through the setting of the TXOP duration requested or queue size subfield. The encoding of the TID subfield depends on the access policy (e.g., Allowed value 0 to 7 for enhanced distributed channel access (EDCA) access policy to identify user priority for either TC or TS).

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

[0099] The queue size subfield is an 8-bit field that indicates the amount of buffered traffic for a given TC or TS at the STA for transmission to the AP identified by the receiver address of the frame containing the subfield. The queue size subfield is present in QoS null frames sent by a STA when bit 4 of the QoS control field is set to 1. The AP may use information contained in the queue size subfield to determine the TXOP duration assigned to the STA or to determine the uplink (UL) resources assigned to the STA.

[0100] In a frame sent by or to a non-high efficiency (non-HE) STA, the following rules may apply to the queue size value:The queue size value is the approximate total size, rounded up to the nearest multiple of 256 octets and expressed in units of 256 octets, of all MSDUs and A-MSDUs buffered at the STA (excluding the MSDU or A-MSDU contained in the present QoS Data frame) in the delivery queue used for MSDUs and A-MSDUs with TID values equal to the value indicated in the TID subfield of the QoS Control field.A queue size value of 0 is used solely to indicate the absence of any buffered traffic in the queue used for the specified TID.A queue size value of 254 is used for all sizes greater than 64 768 octets.A queue size value of 255 is used to indicate an unspecified or unknown size.

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

[0102] The queue size value, QS, is the approximate total size in octets, of all MSDUs and A-MSDUs buffered at the STA (including the MSDUs or A-MSDUs contained in the same PSDU as the frame containing the queue size subfield) in the delivery queue used for MSDUs and A-MSDUs with TID values equal to the value indicated in the TID subfield of the QoS control field.

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

[0104] A STA obtains the queue size, QS, from a received QoS control field, which contains a scaling factor, SF, and an unsealed value, UV, as follows:QS =16 *UV, if SF is equal to 0;1024 + 256 x UV, if SF is equal to 1 ;17 408 + 2048 x W, if SF is equal to 2;148 480 + 32 768 x UV, if SF is equal to 3 and UV is less than 62;> 2 147 328, if SF equal to is 3 and UV is equal to 62;Unspecified or Unknown, if SF is equal to 3 and UV is equal to 63.

[0105] The TXOP duration requested subfield, which may be included instead of the queue size subfield, indicates the duration, in units of 32 microseconds (us), that the sending STA determines it needs for its next TXOP for the specified TID. The TXOP duration requested subfield is set to 0 to indicate that no TXOP is requested for the specified TID in the current service period (SP). The TXOP duration requested subfield is set to a nonzero value to indicate a requested TXOP duration in the range of 32 us to 8160 us in increments of 32 us.

[0106] The HT control field may include an aggregated control (A-Control) subfield. The A-Control subfield may include a control list subfield including one or more control subfields.

[0107] The control subfield may be a BSR control subfield, which may contain buffer status information used for UL MU operation. The BSR control subfield may be formed from an access category index (ACI) bitmap subfield, a delta TID subfield, an ACI high subfield, a scaling factor subfield, a queue size high subfield, and a queue size all subfield of the HT control field.

[0108] The ACI bitmap subfield indicates the access categories for which buffer status is reported (e.g., B0: best effort (AC_BE), B1 : background (AC_BK), B2: video (AC_VI), B3: voice (AC_VO), etc.). Each bit of the ACI bitmap subfield is set to 1 to indicate that the buffer status of the corresponding AC is included in the queue size all subfield, and set to 0 otherwise, except that if the ACI bitmap subfield is 0 and the delta TID subfield is 3, then the buffer status of all 8 TIDs is included.

[0109] The delta TID subfield, together with the values of the ACI bitmap subfield, indicate the number of TIDs for which the STA is reporting the buffer status.

[0110] The ACI high subfield indicates the ACI of the AC for which the BSR is indicated in the queue size high subfield. The ACI to AC mapping is defined as ACI value 0 mapping to AC_BE, ACI value 1 mapping to AC_BK, ACI value 2 mapping to AC_VI, and ACI value 3 mapping to AC_VO.

[0111] The scaling factor subfield indicates the unit SF, in octets, of the queue size high and queue size all subfields.Docket No.: 24-3059PCT

[0112] The queue size high subfield indicates the amount of buffered traffic, in units of SF octets, for the AC identified by the ACI high subfield, that is intended for the STA identified by the receiver address of the frame containing the BSR control subfield.

[0113] The queue size all subfield indicates the amount of buffered traffic, in units of SF octets, for all ACs identified by the ACI Bitmap subfield, that is intended for the STA identified by the receiver address of the frame containing the BSR control subfield.

[0114] The queue size values in the queue size high and queue size all subfields are the total sizes, rounded up to the nearest multiple of SF octets, of all MSDUs and A-MSDUs buffered at the STA (including the MSDUs or A-MSDUs contained in the same PSDU as the frame containing the BSR control subfield) in delivery queues used for MSDUs and A-MSDUs associated with AC(s) that are specified in the ACI high and ACI bitmap subfields, respectively.

[0115] A queue size value of 254 in the queue size high and queue size all subfields indicates that the amount of buffered traffic is greater than 254 x SF octets. A queue size value of 255 in the queue size high and queue size all subfields indicates that the amount of buffered traffic is an unspecified or unknown size. The queue size value of QoS data frames containing fragments may remain constant even if the amount of queued traffic changes as successive fragments are transmitted.

[0116] MAC service provides peer entities with the ability to exchange MSDUs. To support this service, a local MAC uses the underlying PHY-level service to transport the MSDUs to a peer MAC entity. Such asynchronous MSDU transport is performed on a connectionless basis.

[0117] FIG. 7 illustrates an example format 700 of a PPDU. As shown, the PPDU may include a PHY preamble, a PHY header, a PSDU, and tail and padding bits.

[0118] The PSDU may include one or more MPDUs, such as a QoS data frame, an MMPDU, a MAC control frame, or a QoS null frame. In the case of an MPDU carrying a QoS data frame, the frame body of the MPDU may include a MSDU or an A-MSDU.

[0119] By default, MSDU transport is on a best-effort basis. That is, there is no guarantee that a transmitted MSDU will be delivered successfully. However, the QoS facility uses a traffic identifier (TID) to specify differentiated services on a per-MSDU basis.

[0120] A STA may differentiate MSDU delivery according to designated traffic category (TC) or traffic stream (TS) of individual MSDUs. The MAC sublayer entities determine a user priority (UP) for an MSDU based on a TID value provided with the MSDU. The QoS facility supports eight UP values. The UP values range from 0 to 7 and form an ordered sequence of priorities, with 1 being the lowest value, 7 the highest value, and 0 falling between 2 and 3.

[0121] An MSDU with a particular UP is said to belong to a traffic category with that UP. The UP may be provided with each MSDU at the medium access control service access point (MAC SAP) directly in an UP parameter. An A-MPDU may include MPDUs with different TID values.Docket No.: 24-3059PCT

[0122] A STA may deliver buffer status reports (BSRs) to assist an AP in allocating UL MU resources. The STA may either implicitly deliver BSRs in the QoS control field or BSR control subfield of any frame transmitted to the AP (unsolicited BSR) or explicitly deliver BSRs in a frame sent to the AP in response to a BSRP Trigger frame (solicited BSR).

[0123] The buffer status reported in the QoS control field includes a queue size value for a given TID. The buffer status reported in the BSR control field includes an ACI bitmap, delta TID, a high priority AC, and two queue sizes.

[0124] A STA may report buffer status to the AP, in the QoS control field, of transmitted QoS null frames and QoS data frames and, in the BSR control subfield (if present), of transmitted QoS null frames, QoS data frames, and management frames as defined below.

[0125] The STA may report the queue size for a given TID in the queue size subfield of the QoS control field of transmitted QoS data frames or QoS null frames; the STA may set the queue size subfield to 255 to indicate an unknown / unspecified queue size for that TID. The STA may aggregate multiple QoS data frames or QoS null frames in an A-MPDU to report the queue size for different TIDs.

[0126] The STA may report buffer status in the BSR control subfield of transmitted frames if the AP has indicated its support for receiving the BSR control subfield.

[0127] A High-Efficiency (HE) STA may report the queue size for a preferred AC, indicated by the ACI high subfield, in the queue size high subfield of the BSR control subfield. The STA may set the queue size high subfield to 255 to indicate an unknown / unspecified queue size for that AC.

[0128] A HE STA may report the queue size for ACs indicated by the ACI bitmap subfield in the queue size all subfield of the BSR control subfield. The STA may set the queue size all subfield to 255 to indicate an unknown / unspecified BSR for those ACs.

[0129] A multi-link device (MLD) is an entity capable of managing communication over multiple links. The MLD may be a logical entity and may have more than one affiliated station (STA). An MLD may be an access point MLD (AP MLD) where a STA affiliated with the MLD is an AP STA (or an AP). An MLD may be a non- access point MLD (non-AP MLD) where a STA affiliated with the MLD is a non-AP STA (or an STA).

[0130] Communication across different frequency bands / channels may occur simultaneously, or not, depending on the capabilities of both the communicating AP MLD and non-AP MLD.

[0131] An MLD may have a single MAC service access point (MAC-SAP) to the LLC layer, which includes a MAC data service. The MLD may support multiple MAC sublayers, coordinated by a sublayer management entity (SME). Each AP STA (or non-AP STA) affiliated with an AP MLD (or non-AP MLD) has a different MAC address within the MLD.

[0132] The SME is responsible for coordinating the MAC sublayer management entities (MLMEs) of the affiliated STAs of the MLD to maintain a single robust security network association (RSNA) key management entity as well as a single IEEE 802.1X Authenticator or Supplicant for multi-link operation (MLO).Docket No.: 24-3059PCT

[0133] Multi-link operation (MLO) procedures allow a pair of MLDs to discover, synchronize, (de)authenticate, (re)associate, disassociate, and manage resources with each other on any common bands or channels that are supported by both MLDs. The Authenticator and the MAC-SAP of an AP MLD may be identified by the same AP MLD MAC address. The Supplicant and the MAC-SAP of a non-AP MLD may be identified by the same non-AP MLD MAC address.

[0134] FIG. 8 illustrates an example multi-AP network 800. Example multi-AP network 800 may be a multi- AP network in accordance with the Wi-Fi Alliance standard specification for multi-AP networks. As shown in FIG. 8, multi-AP network 800 may include a multi-AP controller 802 and a plurality of multi-AP groups (or multi-AP sets) 804, 806, and 808.

[0135] Multi-AP controller 802 may be a logical entity that implements logic for controlling the APs in multi- AP network 800. Multi-AP controller 802 may receive capability information and measurements from the APs and may trigger AP control commands and operations on the APs. Multi-AP controller 802 may also provide onboarding functionality to onboard and provision APs onto multi-AP network 800.

[0136] Multi-AP groups 804, 806, and 808 may each include a plurality of APs. APs in a multi-AP group are in communication range of each other and may coordinate their transmissions and / or transmissions from their associated STAs. Coordinated transmissions may involve all or a subset of the APs in a multi-AP group. A multi-AP group may also be referred to as an AP candidate set as APs in a multi-AP group are considered candidates for a coordinated transmission initiated by an AP. The APs in a multi-AP group are not required to have the same primary channel. As used herein, the primary channel for an AP refers to a default channel that the AP monitors for management frames and / or uses to transmit beacon frames. For a STA associated with an AP, the primary channel refers to the primary channel of the AP, which is advertised through the AP's beacon frames.

[0137] In one approach, a multi-AP group may be established by a coordinator AP in a multi-AP setup phase prior to any multi-AP coordination. APs of the multi-AP group, other than the coordinator AP, may be referred to as the coordinated APs. A coordinator AP may establish one or more multi-AP groups. A coordinated AP may likewise be a member of multiple multi-AP groups. A coordinator AP of a multi-AP group may be a coordinated AP of another multi-AP group, and vice versa. In another approach, a multi-AP group may be established by a network administrator manually by configuring APs as part of the multi-AP group. In yet another approach, a multi-AP group may be established in a distributed manner by APs without a central controller. In this case, an AP may advertise its multi-AP capability in a beacon or other management frame (e.g., public action frame). Other APs that receive the frame with the multi-AP capability information may perform a multi-AP setup with the AP that advertised the multi-AP capability.

[0138] In one approach, one of the APs in a multi-AP group may be designated as a master AP. The designation of the master AP may be done by multi-AP controller 802 or by the APs of the multi-AP group.Docket No.: 24-3059PCTThe master AP of a multi-AP group may be fixed or may change over time between the APs of the multi-AP group. An AP that is not the master AP of the multi-AP group is known as a slave AP.

[0139] In one approach, APs in a multi-AP group may perform coordinated transmissions together. One aspect of coordination may include coordination to perform coordinated transmissions within the multi-AP group. As used herein, a coordinated transmission, also referred to as a multi-AP transmission, is a transmission event in which multiple APs (of a multi-AP group or a multi-AP network) transmit in a coordinated manner over a time period. Coordinated transmissions may involve simultaneous transmissions of a plurality of APs in a multi-AP group. The time period of simultaneous AP transmission may be a continuous period. The multi-AP transmission may use different transmission techniques, such as Coordinated OFDMA (COFDMA), Coordinated Spatial Reuse (CSR), Joint Transmission or Reception (JT / JR), Coordinated Beamforming (CBF), and CTDMA, or a combination of two or more of the aforementioned techniques.

[0140] Multi-AP group coordination may be enabled by the multi-AP controller and / or by the master AP of the multi-AP group. In one approach, the multi-AP controller and / or the master AP may control time and / or frequency sharing in a transmission opportunity (TXOP). For example, when one of the APs (e.g., the master AP) in the multi-AP group obtains a TXOP, the multi-AP controller and / or the master AP may control how time / frequency resources of the TXOP are to be shared with other APs of the multi-AP group. In an implementation, the AP of the multi-AP group that obtains a TXOP becomes the master AP of the multi-AP group. The master AP may then share a portion of its obtained TXOP (which may be the entire TXOP) with one or more other APs of the multi-AP group.

[0141] Different multi-AP transmission schemes may be suitable for different use cases in terms of privacy protection, including whether transmitted data may be shared with other BSSs in the multi-AP group. For example, some multi-AP transmission schemes, such as CSR, CDTMA, coordinated frequency division multiple access (CFDMA), COFDMA, and CBF, enable a master AP to coordinate slave APs by sharing control information among APs, without requiring the sharing of user data among APs. The control information may include BSS information of APs, link quality information of channels between each AP and its associated STAs, and information related to resources to be used to achieve multiplexing in power, time, frequency, or special domains for multi-AP transmission. The control information exchanged among a master AP and slave APs may be used for interference avoidance or nulling to avoid or null co-channel interference introduced to neighboring BSSs in a multi-AP network. Interference avoidance or interference nulling requires that data transmissions between an AP and STAs are only within the same BSS. In other words, each AP transmits or receives data frames to or from its associated STAs, while each STA receives or transmits data frames to or from its associating AP.

[0142] By contrast, other multi-AP transmission schemes may enable a master AP to coordinate slave APs by sharing both control information and user data among APs in a multi-AP group. Control information may include BSS information related to APs and link quality information of channels between each AP and itsDocket No.: 24-3059PCT associated STAs. By having user data exchanged over backhaul, the master AP and slave APs may perform data transmissions jointly to achieve spatial diversity, e.g., using distributed MIMO, for example, joint transmission (JT) for downlink transmissions and joint reception (JR) for uplink transmissions. The data transmissions between APs and STAs may include transmissions within the same BSS and / or across different BSSs. In other words, an AP may transmit or receive data frames to or from its associated STAs as well STAs associated with other APs participating in multi-AP transmission. Similarly, a STA may transmit or receive data frames to or from multiple APs.

[0143] Different multi-AP transmission schemes may be suitable for different use cases in terms of signal reception levels at STAs or APs within a multi-AP group. For example, CBF and JT / JR require that each STA involved in a multi-AP transmission be located within a common area of signal coverage of the APs involved in the multi-AP transmission. Generally, CBF may be suitable when a receiving STA suffers from potential interference from other APs in the multi-AP group By using channel related information such as channel state information (CSI), channel quality indication (CQI), or compressed beamforming (BF) feedback exchanged among APs, an AP may pre-code a signal to be transmitted to form a beam that increases power toward a target STA while reducing the power that interferes with a STA associated with a neighboring AP. Use cases of JT / JR may require a sufficient received signal power at receiving STAs for JT and a sufficient received signal power at receiving APs for JR. By contrast, CSR may perform multi-AP transmission in an interference coordination manner. The received signal power at a STA associated with an AP transmitting data may be required to be much higher than the received interference power.

[0144] Different multi-AP transmission schemes may require different synchronization levels and may operate with or without a backhaul between a master AP and slave APs in a multi-AP group. For example, CSR may require PPDU-level synchronization, whereas CBF may require symbol-level synchronization. On the other hand, JT / JR may require tight time / frequency / phase-level synchronization as well as a backhaul for data sharing between APs in the multi-AP group.

[0145] Different multi-AP transmission schemes may have different complexity levels with regard to coordination between a master AP and slave APs in a multi-AP group. For example, JT / JR may require very high complexity due to both CSI and user data being shared between APs. CBF may require medium complexity due to the sharing of CSI. CFDMA, COFDMA and CTDMA may require medium or relatively low complexity due to the CSI and time / frequency resources to be shared between APs. CSR may require low complexity as the amount of information related to spatial reuse and traffic that needs to be exchanged between APs may be low.

[0146] A multi-AP group may adopt a static multi-AP operation including a static multi-AP transmission scheme. A multi-AP network may also be dynamic due to various reasons. For example, a STA may join or leave the multi-AP network, a STA may switch to a power save mode, or an AP or a STA may change its location. Such changes may lead to changes in the conditions underlying the selection of the multi-APDocket No.: 24-3059PCT transmission scheme and may cause certain requirements (e.g., synchronization, backhaul, coordination, etc.) for the multi-AP transmission scheme to be lost. This results in an inferior quality of transmissions in the multi-AP network.

[0147] FIG. 9 illustrates an example network 900 that includes a coordinated AP set. As shown in FIG. 9, the coordinated AP set may include AP 902-1 and AP 902-2. The coordinated AP set may be a subset of an established multi-AP group. At least one STA may be associated with each of APs 902-1 and 902-2. For example, a STA 904-1 may be associated with AP 902-1 , and a STA 904-2 may be associated with AP 902- 2.

[0148] APs 902-1 and 902-2 may belong to the same ESS as described above in FIG. 1 . In such a case, APs 902-1 and 902-2 may be connected by a DS to support ESS features. In addition, as part of a coordinated AP set, APs 902-1 and 902-2 may be connected by a backhaul. The backhaul is used to share information quickly between APs to support coordinated transmissions. The shared information may be channel state information or data to be sent to associated STAs. The backhaul may be a wired backhaul or a wireless backhaul. A wired backhaul is preferred for high-capacity information transfer without burdening the main radios of the APs. However, a wired backhaul may require a higher deployment cost and may place greater constraints on AP placement. A wireless backhaul is preferred for its lower deployment cost and flexibility regarding AP placement. However, because a wireless backhaul relies on the main radios of the APs to transfer information, the APs cannot transmit or receive any data while the wireless backhaul is being used.

[0149] Typically, one of APs 902-1 and 902-2 may act as a Master AP and the other as a Slave AP. The Master AP is the AP that is the owner of the TXOP. The Master AP shares frequency resources during the TXOP with the Slave AP. When there are more than two APs in the coordinated set, a Master AP may share its TXOP with only a subset of the coordinated AP set. The role of the Master AP may change over time. For example, the Master AP role may be assigned to a specific AP for a duration of time. Similarly, the Slave AP role may be chosen by the Master AP dynamically or can be pre-assigned for a duration of time.

[0150] Depending on the capability of APs in a coordinated AP set, the APs may only do certain type of coordinated transmissions. For example, in FIG. 9, if AP 902-1 supports JT and CSR while AP 902-2 supports CSR and CBF, both APs may only perform CSR as a coordinated transmission scheme. An AP may also prefer to perform single AP transmissions for a duration of time if the benefit of coordinated transmission does not outweigh some disadvantages with coordinated transmission such as reduced flexibility and increased computational power required

[0151] FIG. 10 illustrates an example 1000 of a multi-AP operation procedure. In example 1000, the multi- AP operation procedure is illustrated with respect to a multi-AP network that includes APs 1002 and 1004 and STAs 1006 and 1008. In an example, APs 1002 and 1004 may form a multi-AP group. AP 1002 may be the master AP and AP 1004 may be a slave AP of the multi-AP group. For example, AP 1002 may obtain aDocket No.: 24-3059PCTTXOP making it the master AP of the multi-AP group. Alternatively, AP 1002 may be designated as the master AP by a multi-AP controller.

[0152] As shown in FIG. 10, the multi-AP operation procedure may include a series of phases in time, each of which may contain a plurality of frame exchanges within the multi-AP network. Specifically, the multi-AP operation procedure may include a multi-AP selection phase 1010, a multi-AP data sharing phase 1012, a multi-AP sounding phase 1014, and a multi-AP data transmission phase 1016.

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

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

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

[0156] Multi-AP data sharing phase 1012 may be performed using a wired backhaul, an in-channel wireless backhaul, or an off-channel wireless backhaul. In some cases, multi-AP data sharing phase 1012 may be performed over an in-channel backhaul, e.g., using the same wireless channel used to transmit / receive data to / from STAs. For example, as shown in FIG. 10, in phase 1012, AP 1002 may transmit a frame 1022, which may be received by AP 1004. Frame 1022 may include MPDUs thatAP 1002 wishes to transmit to associated STAs using a multi-AP operation. Similarly, AP 1004 may transmit a frame 1024, which may be received by AP 1002. Frame 1024 may include MPDUs that AP 1004 wishes to transmit to associated STAs using a multi-AP operation.

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

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

[0159] The order of phases 1010, 1012, 1014 and 1016 may be different than shown in FIG. 10. For example, in COFDMA, phase 1016 may occur immediately after phase 1010, whereas, in JT / JR, phase 1012 may occur after phase 1010. Further, as mentioned above, some phases may be optional and may or may not be present. For example, phase 1014 may not be required for COFDMA but may be required for JT / JR.

[0160] A common framework of a multi-AP coordination may comprise one or more multi-AP group(s) within multi-AP network 800 that carries out the multi-AP operation procedure illustrated in example 1000 as described above. The common framework of a multi-AP coordination may include various multi-AP coordination / transmission schemes, such as (but not limited to) CSR, CBF, CTDMA, or coordinated restricted T arget Wake Time (TWT). The common framework of a multi-AP coordination that can enable the procedures comprising: multi-AP coordination discovery procedure; and multi-AP coordination agreement negotiation procedure. In an implementation, establishing a multi-AP group (such the coordinated AP set of example network 900) may include the multi-AP coordination discovery procedure before or during the multi-AP operation procedure illustrated in example 1000. In an implementation, the multi-AP operation procedure illustrated by example 1000 may include the multi-AP coordination agreement negotiation procedure before, during, or after multi-AP selection phase 1010.

[0161] A sharing AP, that transmits a Trigger frame as part of a transmission sequence in a Multi-AP coordinated transmission scheme, may identify a shared AP via an AP ID carried in the AID12 field of theDocket No.: 24-3059PCTUser Info field of the frame. APs that intend to participate in multi-AP coordination may use management frames to advertise / discover the capabilities and / or parameters of individual schemes. APs that discovered each other and want to establish agreement(s) for multi-AP coordination scheme(s), may use individually addressed management frames to establish the agreement(s) and negotiate parameters.

[0162] EDCA is a listen-before-talk access mechanism that allows exactly one STA to access a channel and to transmit a PPDU in a given time slot. Before transmission using EDCA, a STA listens to the channel for a minimum of an Arbitration Interframe Space (AIFS) duration to determine whether the channel state is IDLE. This listening time for determining whether the channel is IDLE may be followed by one or more backoff slots before the STA attempts to transmit over the channel. The number of backoff slots is chosen randomly by the STA. This reduces the probability of multiple STAs attempting to transmit at the same time, which would result in a packet detect error. If the PPDU transmitted by the STA is received successfully, for example by an AP (not shown in the figure), the AP may respond with an acknowledgment (ACK) frame after a Short Interframe Space (SIPS) duration of receiving the PPDU.

[0163] FIG. 11 illustrates an example 1100 of enhanced distributed channel access (EDCA) and coordinated time division multiple access (CTDMA). In CTDMA, an AP (generally referred to as a master AP or a sharing AP) may share a portion of its TXOP with one or more APs (generally referred to as slave APs or shared APs). Specifically, the sharing AP may assign / allocate each of the one or more APs a respective time period within the TXOP of the sharing AP. A shared AP may use its allocated time period to communicate with one or more STA. CTDMA is illustrated in FIG. 1 1 as a multi-AP channel access scheme, compared with enhanced distributed channel access (EDCA). As shown in FIG. 11 , in EDCA, channel access by multiple APs (e.g., AP1 , AP2) may occur in consecutive time periods (e.g., TXOPs), where each AP has its own TXOP. During a given channel access, the channel in its entirety may be used by a single AP for the duration of the TXOP. In contrast, in CTDMA, access by multiple APs may take place in a same TXOP over consecutive time periods. For example, as shown in FIG. 1 1 , a TXOP may be divided into two nonoverlapping time periods, each assigned to a respective AP of the multiple APs. The multiple APs may transmit in a coordinated manner in the same TXOP consecutively. In an example, as shown in FIG. 11 , a sharing AP (e.g., AP1 ) may use itself a first portion of a first TXOP and may share a second portion of the first TXOP with a shared AP (e.g., AP2). In another example, the shared AP (e.g., AP1 ) may share a first portion of a second TXOP with a shared AP (e.g., AP2) and may use itself a second portion of the second TXOP.

[0164] A coordinated time division multiple access (CTDMA or Co-TDMA) may refer to a procedure that allows a TXOP owner AP that has obtained a TXOP to share a time portion of the obtained TXOP with another AP.

[0165] A TXOP owner AP that intends to share its TXOP is referred to as a sharing AP. An AP with which the sharing AP shares time resources of its obtained TXOP is referred to as a shared AP.Docket No.: 24-3059PCT

[0166] FIG. 12 illustrates an example 1200 of a multi-AP coordination operation using a coordinated timedivision multiple access (CTDMA) procedure. The CTDMA procedure of example 1200 may operate between an AP 1210 and an AP 1212. Example 1200 may comprise a polling phase 1214, a TXOP allocation phase 1216, and a TXOP return phase 1218.

[0167] Before example 1200 begins, an AP, e.g., AP 1210, may discover a neighboring AP that supports CTDMA operation based on the MAPC Operation element that the neighboring AP advertises during a discover phase for the multi-AP coordination discovery procedure. The AP, e.g., AP 1210, may initiate a request to negotiate with the discovered APs for enabling coordinated transmission . Only mutually discovered Co-TDMA capable APs may negotiate with each other an agreement on feature parameters. APs may use individually addressed management frames to establish a coordination agreement. During a negotiation phase for the multi-AP coordination agreement negotiation procedure and upon successful completion of a coordination agreement between a pair of APs, the APs may assign an AP Identifier (ID) to each other. The AP ID is a number that is assigned by each AP in a coordination pair to the other AP of the pair. While an AP may be a member of more than one coordination pairs, all the AP IDs assigned by the AP shall be unique. Additionally, an AP shall ensure that the AP IDs are not assigned to non-AP STAs associated with this AP. The AP IDs shall be maintained by an AP for a coordination pair lifetime.

[0168] In polling phase 1214, a sharing AP, e.g., AP 1210, may announce its intention of sharing a portion of the time resource of its TXOP for CTDMA procedure, in an initial control frame (ICF) 1220 sent at the beginning of the TXOP. ICF 1220 may poll one or more APs with whom the sharing AP may share the TXOP to solicit a response to determine their interest in participating in the CTDMA procedure within the TXOP. An AP identified (polled), e.g., AP 1212, in ICF 1220 may be referred to as a polled AP. A Duration field of ICF 1220 may be set to a value that indicates the ending time of the PPDU[+SigExt] carrying the solicited response from a polled AP plus one SIFS. ICF 1220 that polls an AP to determine its interest in participating in the CTDMA procedure within the TXOP may include a trigger frame. The sharing AP may identify an AP that is to be polled via the AID12 field carried in the User Info field of the trigger frame. The sharing AP may be mandated to send the ICF that announces the intention of sharing a portion of the time resource of its TXOP for CTDMA procedure. A polled AP, e.g., AP 1212, may indicate, via a response 1222, to a received ICF transmitted from the sharing AP whether or not the polled AP intends to participate in the time shared during the current TXOP. If the sharing AP does not receive a response from a polled AP (not shown in FIG. 12), it may assume that the polled AP is not interested in TXOP sharing during the current TXOP. An AP, e.g., AP 1212, may indicate to another AP, e.g., AP 1210, whether it is capable of responding with a TB PPDU to an ICF transmitted by the sharing AP. An AP, e.g., AP 1212, with dot1 ITBResponseSupported equal to true shall set the TB PPDU Response Enabled subfield to 1 in the MAPC Operation Parameters field that the AP transmits. A sharing AP, e.g., AP 1210, may solicit a poll response in a TB PPDU fromDocket No.: 24-3059PCT another AP only if the other AP has indicated support for responding in a TB PPDU by setting the TB PPDU Response Enabled subfield in the MAPC Operation Parameters field to 1.

[0169] In TXOP allocation phase 1216, the sharing AP, e.g., AP 1210, may allocate time within the obtained TXOP to a polled AP, e.g., AP 1212. To share a time portion of its TXOP, the sharing AP may transmit a TXOP allocation trigger frame 1226 to a single polled AP, e.g., AP 1212. For example, TXOP allocation trigger frame 1226 may include an multi-user request-to-send (MU-RTS) Triggered TXOP sharing (TXS) T rigger frame with modifications for CTDMA. A Duration field of TXOP allocation trigger frame 1226 may be set to a value that indicates the ending time of the PPDU carrying a solicited CTS response frame 1228 plus one SIPS. The sharing AP may identify an AP, e.g., AP 1212, with whom the TXOP is to be shared via the AID12 field carried in the User Info field of the MU-RTS TXS Trigger frame. The time allocated to the shared AP may be specified in the Allocation Duration subfield in the MU-RTS TXS Trigger frame. The portion of time of the obtained TXOP that is shared by a sharing AP, e.g., AP 1210, with a shared AP, e.g., AP 1212, may be referred to as a shared TXOP.

[0170] In TXOP return phase 1218, a shared AP, e.g., AP 1212, may return the remainder of a shared TXOP (if any) to the sharing AP.

[0171] FIG. 13 illustrates an example clear to send (CTS) frame format 1300. As shown in FIG. 13, CTS frame format 1300 may comprise a Frame Control field, a Duration field, an RA field, and an FCS field. The Frame Control field may be similar to the Frame Control field described in FIG. 3 above.

[0172] If the CTS frame is a response to a request to send (RTS) frame, the RA field of the CTS frame is set to the address from the TA field of the RTS frame with the Individual / Group bit set to 0. If the CTS frame is the first frame in a frame exchange, the RA field is set to the MAC address of the transmitter If the CTS frame is a response to an MU-RTS Trigger frame, the RA field of the CTS frame is set to the address from the TA field of the MU-RTS Trigger frame.

[0173] For all CTS frames transmitted by a non-QoS STA in response to RTS frames, the Duration field is the value obtained from the Duration field of the immediately previous RTS frame, minus the time, in microseconds, required to transmit the CTS frame and its SIFS. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer.

[0174] At a non-QoS STA, if the CTS frame is the first frame in the exchange and the pending Data or Management frame requires acknowledgment, the Duration field is the time, in microseconds, required to transmit the pending Data or Management frame, plus two SIFSs plus one Ack frame At a non-QoS STA, if the CTS frame is the first frame in the exchange and the pending Data or Management frame does not require immediate acknowledgment, the Duration field is the time, in microseconds, required to transmit the pending Data or Management frame, plus one SIFS. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher integer.Docket No.: 24-3059PCT

[0175] For other CTS frame transmissions by a QoS STA, the Duration field is set as defined in section 9.2.5 (Duration / ID field (QoS STA)) of the IEEE 802.11 standard ("IEEE P802.11 -REVme™ / D4.1 , October 2023”).

[0176] A CTS-to-self frame is a CTS frame in which the RA field is equal to the transmitter's MAC address. A CTS-to-AP frame is a CTS frame that is not transmitted in response to an RTS frame and in which the RA field is equal to the MAC address of the AP with which the STA is associated.

[0177] Triggered TXOP sharing (TXS) is a technique introduced in the IEEE 802.1 1 be standard amendment. TXS allows an AP to allocate a time duration within an obtained TXOP to a STA for transmitting one or more non-trigger-based (non-TB) PPDUs. For the TXS procedure, the AP may transmit a multi-user request-to-send (MU-RTS) trigger frame with a triggered TXOP sharing mode subfield set to a non-zero value. The MU-RTS trigger frame is a trigger frame for triggering CTS frame(s) from multiple users. An MU- RTS trigger frame with the triggered TXOP sharing mode subfield set to a non-zero value is called an MU- RTS TXS trigger (MRTT) frame.

[0178] In an example, when the triggered TXOP sharing mode subfield is set to 1 , the STA may transmit the one or more non-TB PPDUs to the AP during the allocated time duration. In an example, when the triggered TXOP sharing mode subfield is set to 2, the STA may transmit the one or more non-TB PPDUs to the AP or a peer STA during the allocated time duration. The peer STA may be a STA with a connection for peer-to-peer (P2P) communication or direct communication with the STA. In an example, the direct wireless link is established according to the tunneled direct link setup (TDLS) protocol.

[0179] FIG. 14 illustrates an example of a MRTT frame 1400 which may be used in a TXS procedure. As shown in FIG. 14, example MRTT frame 1400 may comprise a frame control field, a duration field, a receiver address (RA) field, a transmitter address (TA) field, a common info field, a user info list field, a padding field, and / or frame check sequence (FCS) field.

[0180] In an example, the common info field may be a high-efficiency (HE) variant common info field or an extremely high throughput (EHT) variant common info field. An EHT variant common info field may comprise, as shown in FIG. 14, one or more of the following subfields: trigger type, UL length, more TF, CS required, UL BW, Gl and HE / EHT-LTF Type / Triggered TXOP sharing mode, number of HE / EHT-LTF symbols, LDPC extra symbol segment, AP Tx Power, Pre-FEC padding factor, PE disambiguity, UL spatial reuse, HE / EHT P160, special user info field flag, EHT reserved, reserved, or trigger dependent common info.

[0181] The trigger type subfield indicates that frame 1400 is an MRTT frame.

[0182] The Gl and HE / EHT-LTF Type / Triggered TXOP sharing mode subfield may include a triggered TXOP sharing mode subfield. In an example, the triggered TXOP sharing mode subfield may be set to a nonzero value (e.g., 1 or 2). In an example, the triggered TXOP sharing mode subfield may be set to 1 . As such, the triggered TXOP sharing mode subfield may indicate that a STA indicated by an AID12 subfield of a user info field (of the user info list field) may transmit one or more non-TB PPDUs to the AP during a time indicatedDocket No.: 24-3059PCT in the allocation duration subfield of the user info field. In another example, the triggered TXOP sharing mode subfield may be set to 2. As such, the triggered TXOP sharing mode subfield may indicate that a STA indicated by an AID12 subfield of a user info field (of the user info list field) may transmit one or more non- TB PPDUs to the AP or to a peer STA during the time indicated by the allocation duration subfield of the user info field. In an example, the peer STA may be a STA with a connection for P2P communication or direct communication with the STA.

[0183] The user info list field may include one or more user info fields. In an example, an EHT variant user info field may comprise, as shown in FIG. 14, one or more of the following subfields: AID12, RU allocation, allocation duration, reserved, or PS160.

[0184] The AID12 subfield may indicate an association identifier (AID) of a STA that may use a time indicated by the allocation duration subfield.

[0185] The RU allocation subfield may indicate the location and size of the RU allocated for a STA indicated by the AID12 subfield.

[0186] The allocation duration subfield may indicate a time allocated by an AP transmitting MRTT frame 1400. The allocated time may be a portion a TXOP obtained by the AP. In an example embodiment, the allocation duration subfield may indicate a first time period.

[0187] FIG. 15 illustrates an example 1500 of a TXS procedure (Mode =1 ). As shown in FIG. 15, the TXS procedure may begin by an AP 1510 transmitting an MRTT frame 1520 to a STA 1511. MRTT frame 1520 may allocate a portion of a TXOP obtained by AP 1510 to STA 151 1 and may indicate a TXS mode equal to1 . STA 151 1 receiving MRTT frame 1520 may use the allocated time to transmit one or more non-TB PPDUs to AP 1510. The one or more non-TB PPDUs may comprise a data frame, a control frame, a management frame, or an action frame.

[0188] In an example, MRTT frame 1520 may comprise a triggered TXOP sharing mode subfield that indicates the TXS mode and / or subfield that indicates a first time period corresponding to the allocated time. In an example, the first time period may be set to a value of X microseconds (us).

[0189] STA 151 1 may respond to MRTT frame 1520 by transmitting a CTS frame 1521 to AP 1510. Subsequently, STA 1511 may transmit non-TB PPDUs 1522, 1524 comprising one or more data frame to AP 1510 during the first time period indicated in MRTT frame 1520. In an example, AP 1510 may transmit one or more Block Ack (BA) frames 1523, 1525 in response to the one or more data frames contained in non-TB PPDUs 1522, 1524 received from STA 1511

[0190] FIG. 16 illustrates an example 1600 of a TXS procedure (Mode =2). As shown in FIG. 16, the TXS procedure may begin by an AP 1610 transmitting an MRTT frame 1620 to a STA 1611. MRTT frame 1620 may allocate a portion of a TXOP obtained by AP 1610 to STA 161 1 and may indicate a TXS mode equal to2. STA 161 1 receiving MRTT frame 1620 may use the allocated time to transmit one or more non-TB PPDUsDocket No.: 24-3059PCT to STA 1612. The one or more non-TB PPDUs may comprise a data frame, a control frame, a management frame, or an action frame.

[0191] In an example, MRTT frame 1620 may comprise a triggered TXOP sharing mode subfield that indicates the TXS mode and / or subfield that indicates a first time period corresponding to the allocated time. In an example, the first time period may be set to a value of Y microseconds (us).

[0192] STA 161 1 may respond to MRTT frame 1620 by transmitting a CTS frame 1621 to AP 1610. Subsequently, STA 1611 may transmit non-TB PPDUs 1622, 1624 comprising one or more data frame to STA 1612 during the first time period indicated in MRTT frame 1620. In an example, STA 1612 may transmit one or more BA frames 1623, 1625 in response to the one or more data frames contained in non-TB PPDUs 1622, 1624 received from STA 1611.

[0193] In CTDMA, one approach for TXOP sharing may be achieved via the TXS procedure described above. The TXS procedure may be used to allow a sharing AP, which obtains a TXOP and is the TXOP owner, to allocate a time duration within its obtained TXOP to a shared AP for downlink and / or uplink transmission between the shared AP and its associated STAs.

[0194] FIG. 17 illustrates an example 1700 of an multi-AP operation procedure using CTDMA. As shown in FIG. 17, example 1700 may include APs 1702 and 1704 and STAs 1706 and 1708. AP 1702 and AP 1704 may be members of a multi-AP group. AP 1702 may be a sharing / master AP of the multi-AP group. AP 1704 may be a shared / slave AP of the multi-AP group. STA 1706 may be associated with AP 1702, and STA 1708 may be associated with AP 1704. In example 1700, it is assumed that APs 1702, 1704 and STAs 1706, 1708 are within communication range of each other.

[0195] In an implementation, an AP, such as APs 1702 and 1704, or a STA, such as STAs 1706 and 1708, may maintain two NAVs: an intra-BSS NAV and a basic NAV. The intra-BSS NAV is updated (set or reset) based on intra-BSS PPDUs (i.e., PPDUs received from the BSS to which the STA / AP belongs). The basic NAV is updated (set or reset) based on inter-BSS PPDUs (i.e., PPDUs received from a different BSS than the BSS to which the STA / AP belongs (also referred to as inter-BSS or OBSS)) or PPDUs that cannot be classified as intra-BSS or inter-BSS.

[0196] For a STA to access the channel using EDCA, both NAVs must be non-zero. The basic NAV of the STA is not updated by transmissions from the AP with which the STA is associated so that if the basic NAV of the STA is nonzero and the STA receives, from the AP, a Trigger frame with the CS Required subfield equal to 1 , the STA does not respond. The STA does not consider the intra-BSS NAV in determining whether to respond to a Trigger frame sent by the AP with which the STA is associated. The STA considers the basic NAV in determining whether to respond to a Trigger frame sent by the AP with which the STA is associated.

[0197] As shown in FIG. 17, the procedure may begin with AP 1702 transmitting an MRTT frame 1712 after obtaining a TXOP 1710. In an embodiment, MRTT frame 1712 may comprise an allocation for AP 1704. An allocation of MRTT frame 1712 may comprise an identifier of a shared AP and a duration (within the TXOP)Docket No.: 24-3059PCT allocated to the shared AP. In example 1700, MRTT frame 1712 may comprise an allocation for AP 1704. The allocation may comprise a first duration (denoted t1 in FIG. 17) of the TXOP allocated to AP 1704. The first duration may be indicated in an allocation duration subfield of a user info list field of MRTT frame 1712. In an embodiment, a duration field of MRTT frame 1712 may indicate a second duration (denoted t2 in FIG. 17). The second duration indicated in the duration field of MRTT frame 1712 may be shorter than the first duration. This is to avoid having an associated STA of a shared AP, which is an OBSS STA for the sharing AP, set its basic NAV for a long duration (e.g., the first duration) after hearing the MRTT frame, which would cause the associated STA not to respond to a trigger frame from its associated shared AP, which owns the TXOP during the first duration. In an implementation, setting the duration field of MRTT frame 1712 to the second duration allows AP 1702 to protect a CTS frame and / or trigger frame of the shared AP.

[0198] In example 1700, on receiving MRTT frame 1712, STA 1706 may set its intra-BSS NAV (as shown by l-BSS NAV 1714 in FIG. 17) to the second duration t2 indicated in MRTT frame 1712. On receiving MRTT frame 1712, STA 1708 may set its basic NAV (as shown by NAV 1716 in FIG. 17) to the second duration t2. On receiving MRTT frame 1712, AP 1704 may determine that AP 1702 has shared TXOP 1710 with AP 1704 for the duration t1 . AP 1704 may transmit a CTS frame 1718 to AP 1702, in response to MRTT frame 1712.

[0199] On receiving CTS frame 1718, AP 1702 may set its intra-BSS NAV (as shown by l-BSS NAV 1720 in FIG. 17) for the remaining duration of t2. After transmitting CTS frame 1718, AP 1704 may use the TXOP for the remaining duration of t1 . In an example, AP 1704 may transmit a downlink frame to STA 1708 (not shown in FIG. 17). In another example, AP 1704 may trigger STA 1708 to transmit an uplink frame to AP 1704.

[0200] In example 1700, after transmitting CTS frame 1718, AP 1704 may transmit a trigger frame 1722 to STA 1708 to trigger an uplink transmission from STA 1708. In an embodiment, a duration field of trigger frame 1722 may indicate a third duration t3. On receiving trigger frame 1722, an OBSS AP or an OBSS STA may set its basic NAV based on the duration field of trigger frame 1722. Specifically, in example 1700, on receiving trigger frame 1722, AP 1702 may set its basic NAV (as shown by NAV 1724 in FIG. 17) to the third duration indicated in trigger frame 1722. Similarly, on receiving trigger frame 1722, STA 1706 may set its basic NAV (as shown by NAV 1726 in FIG. 17) to the third duration indicated in trigger frame 1722.

[0201] In an implementation, on receiving trigger frame 1722 and seeing its own address in the RA field of trigger frame 1722, STA 1708 may determine that it is to transmit an uplink frame to AP 1704. In an embodiment, with trigger frame 1722 transmitted by AP 1704 with which STA 1708 is associated, STA 1708 may set its intra-BSS NAV (as shown by l-BSS NAV 1728 in FIG. 17) to the third duration indicated in trigger frame 1722. In another embodiment, STA 1708 may not set its intra-BSS NAV. Subsequently, STA 1708 may transmit a data frame 1730 to AP 1704. Data frame 1730 may include a duration field that indicates the remaining duration of the third duration. In response to data frame 1730, AP 1704 may transmit a BA frame 1732 to STA 1708.Docket No.: 24-3059PCT

[0202] In an example, after transmitting BA frame 1732 to STA 1708, AP 1704 may not have further uplink and / or downlink transmissions to perform within the remainder of the first duration allocated to AP 1704. In an implementation, AP 1704 may return the remainder of the first duration to AP 1702 (also referred to as truncating the first duration). In example 1700, AP 1704 may transmit a frame 1734 indicating a return by AP 1704 of the first duration to AP 1702 (or indicating truncation by AP 1704 of the first duration). In an example, frame 1734 may be a contention free-end (CF-end) frame. In an example, frame 1734 may comprise a transmitter address (TA) indicating AP 1704. In an example, frame 1734 may be a broadcast frame.

[0203] In example 1700, on receiving CF-end frame 1734, AP 1702 may reset its basic NAV to zero before the end of the third duration. AP 1702 may further determine that AP 1704 has returned the first duration to AP 1702. With the return of the first duration to AP 1702, AP 1702 (which is the owner of the TXOP) returns to being the holder of the TXOP. Similarly, on receiving CF-end frame 1734, STA 1706 may reset its basic NAV before the end of the third duration. On receiving CF-end frame 1734, STA 1708 may reset its intra- BSS NAV before the end of the third duration.

[0204] In an example, with the return of the first duration to AP 1702, AP 1702 may initiate uplink and / or downlink transmissions for the remaining duration of TXOP 1710 (which includes the remainder of the first duration). In an example, AP 1702 may transmit a frame 1736 to STA 1706 to initiate an uplink transmission. In an example, frame 1736 may be a trigger frame. On receiving frame 1736, an OBSS AP or an OBSS STA may set its basic NAV. As such, AP 1704 may set its basic NAV (as shown by NAV 1738 in FIG. 17) to a duration indicated in frame 1736. Similarly, STA 1708 may set its basic NAV (as shown by NAV 1740 in FIG. 17) to the duration indicated in frame 1736.

[0205] On receiving frame 1736 and seeing its own address in the RA field of frame 1736, STA 1706 may determine that it is to transmit an uplink frame to AP 1702. STA 1706 may set its intra-BSS NAV (as shown by l-BSS NAV 1742 in FIG. 17) to the duration indicated in frame 1736. In another embodiment, STA 1706 may not set its intra-BSS NAV. In response to frame 1736, STA 1706 may transmit a frame 1744 to AP 1702. In an example, frame 1744 may be a data frame. In an implementation, frame 1744 may include a duration field that indicates the remainder of the duration indicated frame 1736. In an example, after receiving frame 1744, AP 1702 may continue uplink and / or downlink transmissions within TXOP 1710. In another example, AP 1702 may share a remaining portion of TXOP 1710 with another shared AP.

[0206] FIG. 18 illustrates another example 1800 of an existing CTDMA procedure. As shown in FIG. 18, example 1800 may include APs 1802 and 1804 and STAs 1806 and 1808. AP 1802 and AP 1804 may be members of a multi-AP group. AP 1802 may be a sharing / master AP of the multi-AP group. AP 1804 may be a shared / slave AP of the multi-AP group. STA 1806 may be associated with AP 1802, and STA 1808 may be associated with AP 1804. In example 1800, it is assumed that APs 1802, 1804 and STAs 1806, 1808 are within communication range of each other.Docket No.: 24-3059PCT

[0207] As shown in FIG. 18, the procedure may begin with AP 1802 transmitting an MRTT frame 1820 after obtaining a TXOP 1810. In an embodiment, MRTT frame 1820 may comprise an allocation for AP 1804. An allocation of MRTT frame 1820 may comprise an identifier of a shared AP and a duration (within the TXOP) allocated to the shared AP. In example 1800, MRTT frame 1820 may comprise an allocation for AP 1804. The allocation may comprise a period 1812 of TXOP 1810 allocated to AP 1804. Period 1812 may have a first duration starting at a time T 1 . The first duration of period 1812 may be indicated in an allocation duration subfield of a user info list field of MRTT frame 1820.

[0208] On receiving MRTT frame 1820, AP 1804 may determine that AP 1802 has shared TXOP 1810 with AP 1804 for the first duration of period 1812. AP 1804 may transmit a CTS frame 1822 to AP 1802, in response to MRTT frame 1820.

[0209] After transmitting CTS frame 1822, AP 1804 may use the TXOP for the remaining duration of the first duration of period 1812. In an example, AP 1804 may transmit a downlink frame to STA 1808. In another example, AP 1804 may trigger STA 1808 to transmit an uplink frame to AP 1804 (not shown in FIG. 18). In example 1800, after transmitting CTS frame 1822, AP 1804 may transmit a data frame 1824 to STA 1808 for transmission. Data frame 1824 may include a duration field that indicates the remaining duration of the first duration of period 1812. In response to data frame 1824, AP 1804 may transmit a BA frame 1826 to AP 1804.

[0210] In an example, after receiving BA frame 1826 from STA 1808, AP 1804 may not have further uplink and / or downlink transmissions to perform within the remainder of the first duration of period 1812 allocated to AP 1804. In an implementation, AP 1804 may return the remainder of period 1812 to AP 1802 (also referred to as truncating period 1812). In example 1800, AP 1804 may transmit a frame 1828 indicating a return by AP 1804 of period 1812 to AP 1802 (or indicating truncation by AP 1804 of period 1812). In an example, frame 1828 may be a contention free-end (CF-end) frame. In an example, CF-end frame 1828 may comprise a transmitter address (TA) indicating AP 1804. In an example, CF-end frame 1828 may be a broadcast frame. As shown in FIG. 18, AP 1804 may return period 1812 after using only a period 1814 of period 1812. Period 1814 may have a second duration starting at time T1 and ending at a time T2.

[0211] In an example, with the return of period 1812 to AP 1802, AP 1802 may initiate uplink and / or downlink transmissions for the remaining duration of TXOP 1810 (which includes the remainder of the first duration of period 1812) starting at time T2. As shown in FIG. 18, the remaining duration of TXOP 1810 may include a period 1816, which may comprise the returned portion of period 1812. In an example, AP 1802 may transmit a frame 1830 to STA 1806 to initiate a downlink transmission. In an example, frame 1830 may be a data frame. In response to frame 1830, STA 1806 may transmit a frame 1832 to AP 1802. In an example, frame 1832 may be a BA frame.

[0212] In an example, after receiving frame 1832, AP 1802 may continue uplink and / or downlink transmissions within TXOP 1810. In another example, AP 1802 may share a remaining portion of TXOP 1810 with another shared AP.Docket No.: 24-3059PCT

[0213] FIG. 19 illustrates an example 1900 of a Request-to-Send (RTS) / Clear-to-Send (CTS) procedure. Example 1900 may be an example according to the RTS / CTS procedure as defined in section 10.3.2.9 of the IEEE 802.11 standard draft "IEEE P802.11-REVmeTM / D3.0, April 2023.” As shown in FIG. 19, example 1900 may include STAs 1902 and 1904. Other STAs of the same BSS may also be within communication range of STAs 1902 and 1904.

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

[0215] In an example, STA 1904 may respond to RTS frame 1906 by transmitting a CTS frame 1908 to STA 1902. CTS frame 1908 may be transmitted one SIFS period after RTS frame 1906. STA 1904 may respond to RTS frame 1906 when RTS frame 1906 is addressed to STA 1904 and after considering the NAV, unless the NAV was set by a frame originating from STA 1902. STA 1904 may respond to the RTS frame 1906 when RTS frame 1906 is addressed to STA 1904 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 1906 matches a saved TXOP holder address. For an S1G 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 1906 matches the saved TXOP holder address.

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

[0217] Upon receiving CTS frame 1908, STA 1902 may wait one SIFS period before transmitting data frame 1910. STA 1904 may transmit an ACK frame 1912 in response to data frame 1910. STA 1904 may transmit ACK frame 1912 one SIFS after receiving data frame 1910.

[0218] As shown in example 1900, other STAs within communication range of STAs 1902 and 1904, and belonging to the same BSS, may set their NAVs according to RTS frame 1906 and / or CTS frame 1908. For example, a STA receiving RTS frame 1906 may set its NAV based on the Duration / ID field of RTS frame 1906. Another STA receiving CTS frame 1908 may set its NAV based on the Duration field of CTS frame 1908. As such, the other STAs may not access the channel using EDCA until the end of transmission of ACK frame 1912.

[0219] FIG. 20 is an example 2000 that illustrates a multi-user Request-to-Send (MU-RTS) / Clear-to-Send (CTS) procedure. Example 2000 may be an example according to the MU-RTS / CTS procedure as definedDocket No.: 24-3059PCT in section 26.2.6 of the IEEE 2002.11 standard draft. As shown in FIG. 20, example 2000 may include an AP 2002 and STAs 2004 and 2006. STAs 2004 and 2006 may be associated with AP 2002. For the purpose of illustration, example 2000 also illustrates STAs of an overlapping basic service set (OBSS) relative to the BSS of AP 2002 (OBSS STAs). The OBSS STAs, as shown in FIG. 20, may be hidden from AP 2002 (outside of the communication range of AP 2002) or exposed to AP 2002 (within the communication range of AP 2002).

[0220] In example 2000, AP 2002 wishes to transmit a downlink (DL) multi-user (MU) PPDU 2014 to STAs 2004 and 2006. DL MU PPDU 2014 may comprise data for each of STAs 2004 and 2006. DL MU PPDU 2014 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 2004, STA 2006) served by DL MU PPDU 2014.

[0221] As shown in FIG. 20, to protect the transmission of DL MU PPDU 2014 to STAs 2004 and 2006 from interference by OBSS STAs hidden from AP 2002, AP 2002 may use the MU-RTS / CTS procedure to initiate a TXOP and to protect the TXOP frame exchange sequence. AP 2002 may initiate the TXOP by transmitting an MU-RTS trigger frame 2008 that solicits simultaneous CTS frame transmissions from STAs 2004 and 2006.

[0222] MU-RTS trigger frame 2008 may have a format as illustrated by trigger frame 500 illustrated in FIG. 5. As such, MU-RTS trigger frame 2008 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 2014, plus the time required to transmit one CTS frame, one ACK frame (if required), and three SIFS periods.

[0223] The one or more user info fields correspond respectively to the one or more STAs solicited by the MU-RTS trigger frame. In example 2000, MU-RTS trigger frame 2008 may comprise a user info field for each of STAs 2004 and 2006 indicating that a CTS frame is solicited from each of STAs 2004 and 2006. As shown in FIG. 20, 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 200 MHz channel, a primary 160 MHz, an 200+80 Mhz channel, or a 320 MHz channel.

[0224] AP 2002 may send MU-RTS trigger frame 2008 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 2008, AP 2002 may request at least one non-AP STA to send a CTS frame that occupies that channel. In an example, AP 2002 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 2008.

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

[0226] In example 2000, on receiving MU-RTS trigger frame 2008, STAs 2004 and 2006 respond by transmitting respectively CTS frames 2010 and 2012 to AP 2002. In an example, STAs 2004 and 2006 begin the transmission of CTS frames 2010 and 2012, respectively, at the SIFS time boundary after an end of a received PPDU comprising MU-RTS trigger frame 2008. In an example, STA 2004 (or STA 2006) responds to MU-RTS trigger frame 2008 with a CTS frame when the following conditions are met: MU-RTS trigger frame 2008 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 2008 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 2002.1 1 standard (“IEEE P802.1 1-REVmeTM / D3.0, April 2023”). Otherwise, if one of the conditions is not met, STA 2004 (or STA 2006) does not send a CTS frame to AP 2002.

[0227] In an example, STAs 2004 and 2006 may set an RA field of respectively CTS frames 2010 and 2012 to a TA obtained from the TA field of MU-RTS trigger frame 2008. In an example, STAs 2004 and 2006 may set a duration field of respectively CTS frames 2010 and 2012 based on the duration field of MU-RTS trigger frame 2008, namely as equal to the value of the duration field of MU-RTS trigger frame 2008, adjusted by subtracting the time required to transmit respectively CTS frames 2010 and 2012 and one SIFS period.

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

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

[0230] On receiving CTS frame 2010 and / or CTS frame 2012, AP 2002 may wait one SIPS period before transmitting DL MU PPDU 2014. On receiving DL MU PPDU 2014, STAs 2004 and 2006 may respond by transmitting respective BlockAck (BA) frames 2016 and 2018 to AP 2002.

[0231] It is envisioned in future IEEE 2002.1 1 standards that a STA (AP STA or non-AP STA) may access a non-primary channel to communicate with another STA. Such operation may be referred to as non-primary channel access (NPCA) operation. Specifically, in addition to a default primary channel (which is used by all STAs in the BSS and via which the AP transmits management frames), the STA may have one or more secondary channels considered as NPCA primary channels. The STA may transmit or receive on a channel that includes an NPCA primary channel but that does not necessarily include the primary channel (e.g., when the primary channel is unavailable). The STA may maintain a NAV for an NPCA primary channel independent of the NAV associated with the primary channel.

[0232] FIG. 21 shows an example 2100 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. 21 , 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. 21. For example, the NPCA primary channel may correspond to SCH1 .

[0233] In an implementation, as shown in FIG. 22 illustrating an example 2200, 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).

[0234] In contrast, as shown in FIG. 22, 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 mayDocket No.: 24-3059PCT 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.

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

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

[0237] FIG. 23 shows an example 2300 that illustrates an NPCA operation. As shown in FIG. 23, example 2300 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).

[0238] Example 2300 may begin with the AP transmitting a frame 2302 on the PCH. Frame 2302 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 2302 may be a management frame, such as a beacon frame, for example.Docket No.: 24-3059PCT

[0239] Subsequently, while the AP and STA operate on the PCH, transmission of a frame 2304 from an OBSS may begin on the PCH. The AP and the STA may detect frame 2304 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 2304 on the PCH. Frame 2304 may indicate a transmission (of one or more frames including frame 2304) on the PCH. A duration of the transmission on the PCH may be provided by a duration field of frame 2304, a transmission opportunity (TXOP) duration field of an inter-basic service set (inter-BSS) PPDU comprising frame 2304, or a length field of the inter-BSS PPDU. The AP and STA may set their NAVs for the PCH based on the duration of the OBSS transmission on the PCH (hereinafter, OBSS NAV duration or OBSS TXOP duration).

[0240] In accordance with NPCA operation, on receiving an inter-BSS 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. In an example, the AP and the STA may switch to the NPCA PCH at time T 1 as shown in example 2300. Here, time T1 may correspond to the time for switching to NPCA PCH after obtaining the OBSS NAV duration. The AP and STA may be configured to finish transmitting on the NPCA PCH before an end of the OBSS NAV duration and to return to the PCH by the end of the OBSS NAV duration, by time T2, as shown in example 2300.

[0241] 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 2302). In example 2300, 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 2306 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 2306 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. 23) on the NPCA PCH.

[0242] A STA that supports NPCA operation is called an NPCA STA. An AP that supports NPCA operation is called an NPCA AP. A non-AP NPCA STA shall set the NPCA Supported field of the UHR MAC Capabilities Information field of the UHR Capabilities element to 1.

[0243] An NPCA AP may enable NPCA operation for the BSS by setting the NPCA Operation Information Present field to 1 . An NPCA AP shall set the NPCA Operation Information Present field to 0 to indicate thatDocket No.: 24-3059PCTNPCA operation is disabled. An NPCA AP that has an operating bandwidth less than 80 or 160 MHz may not enable NPCA operation.

[0244]

[0245] An NPCA AP shall include the NPCA Operation Information field in its UHR Operation element and indicate its NPCA Switching Delay and NPCA Switch Back Delay respectively in the NPCA Switching Delay field and NPCA Switch Back Delay fields of the frames that it transmits.

[0246] A non-AP STA that supports NPCA operation shall announce its NPCA Switching Delay and NPCA Switch Back Delay in frames.

[0247] A non-AP NPCA STA shall not switch to the NPCA primary channel for NPCA operation if the value of the most recently received NPCA Operation Information Present field from its associated AP is equal to 0. An NPCA AP shall not switch to the NPCA primary channel for NPCA operation if the value of its most recently transmitted NPCA Operation Information Present field is equal to 0.

[0248] An NPCA STA may switch to the NPCA primary channel for NPCA operation if the value of the most recently received NPCA Operation Information Present subfield from its associated AP is equal to 1 if either condition a) or b) is met: a) the STA received a PPDU that is an HE / EHT / UHR PPDU on the BSS primary channel and all (or one or more) of the following conditions are true: a. the PPDU is classified by the STA as an inter-BSS PPDU following the procedure defined in 26.2.2 (Intra-BSS and inter-BSS PPDU classification). b. the duration of the PPDU, determined as the smaller of the value of TXTIME from the PLME- TXTIME. confirm primitive returned in response to a PLME-TXTIME. request primitive that used the RXVECTOR associated with the PPDU in place of the TXVECTOR parameter for the primitive and the value of the TXOP_DURATION parameter of the RXVECTOR of the PPDU, is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to its BSS c. the 20 / 40 / 80 / 160 MHz channel occupied by the PPDU is identified by the STA, based on the Bandwidth field in the PHY preamble of the PPDU and the channel allocations in the corresponding band, and the channel occupied by the PPDU does not overlap with the NPCA primary channel. b) the STA received a PPDU containing a Control frame and / or a PPDU containing a initial response frame of a Control frame exchange on the BSS primary channel and all of the following conditions apply: a. the received PPDU(s) are classified by the STA as inter-BSS PPDU(s) following the procedure of Intra-BSS and inter-BSS PPDU classification. b. the TXOP duration, determined from the Duration field of the received frame(s), is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to its BSS.Docket No.: 24-3059PCT c. the 20 / 40 / 80 / 160 MHz channel occupied by the received PPDU(s) is identified by the STA, based on the channel allocations in the corresponding band and the PPDU bandwidth that is signaled in the received PPDU(s) or obtained from the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT of the received PPDU(s) and the channel occupied by the received PPDU(s), does not overlap with the NPCA primary channel .I. if the Control frame is an RTS frame in a non-HT (duplicate) PPDU, then it includes a bandwidth signaling TA and the signaled PPDU bandwidth is 20 MHz, 40 MHz, 80 MHz, or 160 MHz. ii. identification of the channel occupied by a received CTS frame in a non-HT (duplicate) PPDU is determined by examining the RTS frame or the MU-RTS frame that elicited the CTS response.

[0249] When an NPCA STA switches to the NPCA primary channel for NPCA operation, the following rules may apply: a) If the STA switches from the BSS primary channel to the NPCA primary channel based on an inter- BSS HE / EHT / UHR PPDU reception on the BSS primary channel, the STA shall initiate the switch at the NPCA HE switch time and it shall be ready to transmit and receive frames (subject to its capabilities and operating mode) on the NPCA primary channel no later than the value of its most recently indicated NPCA switching delay after the NPCA HE switch time. b) If the STA switches from the BSS primary channel to the NPCA primary channel based on an inter- BSS Control frame exchange reception on the primary channel, the STA shall initiate the switch at the NPCA NHT switch time and it shall be ready to transmit and receive frames addressed to it (subject to its capabilities and operating mode) on the NPCA primary channel no later than the value of its most recently indicated NPCA switching delay after the NPCA NHT switch time c) The STA shall use the same EDCA parameter set, MU EDCA parameter set, and EPCS EDCA parameter set values for operation on the NPCA primary channel as it uses on the BSS primary channel. d) Once the STA becomes ready to transmit on the NPCA primary channel, the STA may initiate a TXOP on the NPCA primary channel by following the rules defined in 10.23.2.2 (EDCA backoff procedure) and 10.23.2.4 (Obtaining an EDCA TXOP) with the following exceptions: a. Each time that the STA switches to the NPCA primary channel, it shall initialize CW_NPCA[AC] to TBD value and randomly choose a new initial value between 0 and CW_NPCA[AC] for the backoff counter (BO_NPCA[AC]). b. QSRC_NPCA[AC] shall be set to 0. c. If the STA is a non-AP STA and the associated AP has disabled the use of untriggered UL transmissions on the NPCA primary channel, then the non-AP STA shall not initiate a TXOP on the NPCA primary channel. i.MU EDCA parameters mechanism and or some other mechanism may be used to disable untriggered UL transmissions on the NPCA primary channel.Docket No.: 24-3059PCT ii.The baseline EDCA procedure may be followed on the BSS primary channel. The values of CW_NPCA[AC] and BO_NPCA[AC] may be discarded by the NPCA STA when it switches back to the BSS primary channel. e) The STA shall not initiate a transmission on the NPCA primary channel to another STA until that STA's NPCA switching delay time has elapsed since the NPCA HE switch time or NPCA NHT switch time, whichever is relevant f) The STA shall begin all frame exchanges on the NPCA primary channel with an NPCA initial Control frame using non-HT PPDU or non-HT duplicate PPDU format using a rate of 6 Mb / s, 12 Mb / s, or 24 Mb / s. g) An NPCA AP that transmits a Trigger frame on the NPCA primary channel shall indicate RU index values that use the NPCA primary channel as the reference primary channel. The Trigger frame shall include an explicit indication that it is being transmitted on the NPCA primary channel. h) The 20 MHz channels occupied by PPDUs transmitted by the STA while performing NPCA operation on the NPCA primary channel shall meet all of the following conditions: a. include at least the NPCA primary channel. b. all be within the AP’s BSS bandwidth. c. not include any of the channels occupied by the inter-BSS traffic that caused the STA to switch from the BSS primary channel to the NPCA primary channel d. not include the channels that are indicated as punctured in the Disabled Subchannel Bitmap field in the EHT Operation element. e. a frame that solicits a response other than TB PPDUs may puncture 20 MHz subchannels not indicated as punctured in the Disabled Subchannel Bitmap field of the EHT Operation element.

[0250] FIG. 24 shows an example 2400 that illustrates a problem that may arise using NPCA operation during a CTDMA procedure. As shown in FIG. 24, example 2400 includes APs 2402 and 2404 and STAs 2406 and 2408. STA 2406 may be associated with AP 2402, and STA 2408 may be associated with AP 2404. APs 2402 and 2404 belong to different BSSs. AP 2402 may belong to a first BSS and AP 2404 may belong to a second BSS. The second BSS may comprise an overlapping basic service set (OBSS) relative to the first BSS. APs 2402 and 2404 may be members of a multi-AP group. AP 2402 may be a sharing / master AP of the multi-AP group. AP 2404 may be a shared / slave AP of the multi-AP group. In example 2400, it is assumed that APs 2402 and 2404 and STAs 2406 and 2408 are within communication range of each other. AP 2402 and STA 2406 may both support NPCA operation and may operate over a plurality of channels, including a primary channel (PCH), an NPCA primary channel (NPCA PCH), and a first secondary channel (SCH1).

[0251] As shown in FIG. 24, example 2400 may begin with AP 2402 transmitting an MRTT frame 2420 on the PCH after obtaining a TXOP 2410. In an example, MRTT frame 2420 may comprise an allocation for AP 2404. An allocation of MRTT frame 2420 may comprise an identifier of a shared AP and a duration (within the TXOP) allocated to the shared AP. The allocation for AP 2404 may comprise a time portion 2412 of TXOPDocket No.: 24-3059PCT2410 allocated to AP 2404. Time portion 2412 may have a first duration starting at a time T 1 . The first duration of time portion 2412 may be indicated in an allocation duration field of a user info list field of MRTT frame 2420.

[0252] On receiving MRTT frame 2420 via the PCH, AP 2404 may determine that AP 2402 has shared TXOP 2410 with AP 2404 on the PCH for the first duration of time portion 2412. AP 2404 may transmit a CTS frame 2422 via the PCH to AP 2402, in response to MRTT frame 2420.

[0253] After transmitting CTS frame 2422, AP 2404 may use the TXOP on the PCH for the remaining duration of the first duration of time portion 2412. As shown in FIG. 24, after transmitting CTS frame 2422, AP 2404 transmits a PPDU 2424 via the PCH to STA 2408. PPDU 2424 may include a duration field that indicates the remaining duration of the first duration of time portion 2412. In an example, PPDU 2424 may comprise a downlink frame transmitted to STA 2408. In response to PPDU 2424, STA 2408 may transmit a frame 2426 via the PCH to AP 2404 In an example, frame 2426 may comprise a BA frame.

[0254] AP 2402 and / or STA 2406 may detect PPDU 2424 as an inter-BSS PPDU on the PCH. AP 2402 and / or STA 2406 may respectively set a NAV associated with the PCH based on receiving PPDU 2424 on the PCH. In an implementation, AP 2402 and / or STA 2406 may be configured to set their respective NAVs for the PCH based on a duration of the OBSS transmission on the PCH (hereinafter, OBSS NAV duration or OBSS TXOP duration). In example 2400, the duration of the OBSS transmission may comprise / correspond to the remaining duration of time portion 2412 as indicated in the duration field of PPDU 2424.

[0255] Additionally, in accordance with NPCA operation, on receiving PPDU 2424 that is an inter-BSS PPDU and obtaining the OBSS NAV duration from PPDU 2424, AP 2402 and / or STA 2406 may be configured to switch to the NPCA PCH for the OBSS NAV duration. In example 2400, AP 2402 and / or STA 2406 may switch to the NPCA PCH at a time T3 as shown in FIG. 24. Here, time T3 may correspond to the time for switching to the NPCA PCH after obtaining the OBSS NAV duration.

[0256] As shown in FIG. 24, after switching to the NPCA PCH, AP 2402 and / or STA 2406 may remain on the NPCA PCH until the end of the OBSS NAV duration (the end of time portion 2412 allocated to AP 2404). However, as AP 2402 allocated time portion 2412 to AP 2404, AP 2402 may not have any downlink / uplink traffic to communicate with STA 2406 during the OBSS NAV duration. As such, AP 2402 and / or STA 2406 may switch to the NPCA PCH (e.g., at time T3) and may return to the PCH before an end of the OBSS NAV duration (e.g., by time T2) without communicating on the NPCA PCH. This switching by AP 2402 and / or STA 2406 during the CTDMA procedure is unnecessary and may waste processing / power resources at AP 2402 and any STA associated therewith, such as STA 2406.

[0257] Embodiments of the present disclosure, as further described below, address the above-described problem of existing technologies. In an aspect, a first AP may transmit to a second AP, a first frame indicating: sharing, by the first AP with the second AP, of a time portion of a TXOP obtained by the first AP on a PCH; and a duration of the time portion of the TXOP. In an embodiment, the first AP disables / deactivates an NPCADocket No.: 24-3059PCT mode of operation during the time portion of the TXOP. Disabling / deactivating the NPCA mode of operation during the time portion of the TXOP may comprise disabling / deactivating, by the first AP, the NPCA mode of operation at a start time of the time portion of the TXOP. The first AP may enable / activate the NPCA mode of operation at an end time of the time portion of the TXOP. In an embodiment, the first AP determines that a first physical layer protocol data unit (PPDU) being received via the PCH comprises an inter-basic service set (inter-BSS) PPDU; and does not switch from the PCH to an NPCA PCH in response to the first PPDU. Not switching from the PCH to the NPCA PCH in response to the first PPDU may be based on the disabling / deactivating of the NPCA mode of operation. In another embodiment, the first AP determines that a second PPDU being received, after an end of the TXOP, via the PCH comprises an inter-BSS PPDU; and switches from the PCH to the NPCA PCH in response to the second PPDU. The first frame may indicate triggered TXOP sharing (TXS) to the second AP during a duration of the time portion of the TXOP. The first frame may comprise an allocation duration field that indicates the duration of the time portion of the TXOP. A user info field of the first frame may comprise the allocation duration field. The user info field of the first frame may indicate an identifier of the second AP. In an embodiment, a common info field of the first frame instructs the STA to decode the user info field to obtain / determine the time portion of the TXOP. The common info field of the first frame may instruct the STA to decode the allocation duration field. In another embodiment, a common info field of the first frame indicates a time period during which the STA is to deactivate / disable the NPCA mode of operation.

[0258] FIG. 25 shows an example 2500 that illustrates an operation according to an embodiment. Example 2500 is provided for the purpose of illustration only and is not limiting. As shown in FIG. 25, example 2500 may include APs 2502 and 2504 and STAs 2506 and 2508. STA 2506 may be associated with AP 2502, and STA 2508 may be associated with AP 2504. AP 2502, AP 2504, STA 2506, and / or STA 2508 may each comprise a multi-link device (MLD). In example 2500, it is assumed that APs 2502, 2504 and STAs 2506, 2508 are within communication range of each other.

[0259] In an example, APs 2502 and 2504 may belong to the same ESS as described above in FIG. 1. In such a case, APs 2502 and 2504 may be connected by a DS to support ESS features. In an example, APs 2502 and 2504 belong to different BSSs. In an embodiment, AP 2502 may belong to a first BSS and AP 2504 may belong to a second BSS. In an embodiment, the second BSS may comprise an overlapping basic service set (OBSS) relative to the first BSS.

[0260] In an embodiment, APs 2502 and 2504 may form a multi-AP group. AP 2502 may be a sharing / master AP of the multi-AP group. AP 2504 may be a shared / slave AP of the multi-AP group. As part of the multi-AP group, APs 2502 and 2504 may be connected by a backhaul. In an example, the backhaul may be a wireless backhaul.Docket No.: 24-3059PCT

[0261] In an example, APs 2502 and 2504 may complete a multi-AP setup procedure as described above prior to the beginning of example 2500. In an implementation, the multi-AP setup procedure may comprise a multi-AP coordination discovery procedure as described above.

[0262] In an example, before example 2500 begins, APs 2502 and 2504 may complete a multi-AP selection phase such as multi-AP selection phase 1010 described in FIG. 10 above; and / or a multi-AP coordination negotiation procedure; and / or a polling phase of CTDMA procedure such as polling phase 1214 described in FIG. 12.

[0263] In example 2500, AP 2502 and STA 2506 may both support NPCA operation and may operate over a plurality of channels, including a primary channel (PCH), an NPCA primary channel (NPCA PCH), and a first secondary channel (SCH1 ).

[0264] In an embodiment, AP 2502 supports a first capability that allows / enables AP 2502 to perform the operations further described below. In an example, support of the first capability may allow AP 2702 to transmit a frame to instruct a STA to decode / receive the frame to obtain / determine a time portion of the TXOP obtained by AP 2502 on a PCH. In an example, support of the first capability may further allows AP 2502 to disabling / deactivating an NPCA mode of operation during the time portion of the TXOP.

[0265] In an embodiment, STA 2506 supports a second capability that allows / enables STA 2506 to perform the operations described below. In an example, support of the second capability allows STA 2506 to receive and process a frame from a first AP indicating sharing, by the first AP with a second AP, of a time portion of a TXOP obtained by the first AP on a PCH and a duration of the time portion of the TXOP. In an example, support of the second capability may allow STA 2506 to receive the frame instructing the STA to decode / receive the frame to obtain / determine the time portion of the TXOP. In an example, support of the second capability may further allow STA 2506 to disabling / deactivating an NPCA mode of operation during the time portion of the TXOP.

[0266] As shown in FIG. 25, example 2500 may begin with AP 2502 obtaining a TXOP 2510 on the PCH and transmitting a frame 2520 on the PCH. In an example, AP 2502 may transmit frame 2520 using EDCA. In an embodiment, frame 2520 indicates sharing, by AP 2502 with AP 2504, of a time portion 2512 of TXOP 2510 obtained by AP 2502 on the PCH. In an embodiment, frame 2520 further indicates a duration of time portion 2512 of TXOP 2510. In an embodiment, frame 2520 comprises an allocation for AP 2504. In an embodiment, a user info field of frame 2520 comprises the allocation for AP 2504. The user info field may comprise an allocation duration field and an identifier of AP 2504. In an embodiment, the allocation duration field indicates the duration of time portion 2512 of TXOP 2510. As shown in FIG. 25, the duration of time portion 2512 may start at a time T1 and end at a time T2.

[0267] In an embodiment, a first field of frame 2520 instructs STA 2506 to decode the user info field to obtain / determine time portion 2512 of TXOP 2510. In an embodiment, the first field of frame 2520 instructs STA 2506 to decode the allocation duration field. In an embodiment, the first field of frame 2520 indicates aDocket No.: 24-3059PCT first time period during which STA 2506 is to deactivate / disable the NPCA mode of operation. In an embodiment, the first field comprises a common info field or a special user info field. In an embodiment, the first time period comprises to time portion 2512 of TXOP 2510. In an embodiment, the first time period begins before time portion 2512 of TXOP 2510. In an embodiment, the first time period ends after time portion 2512 of TXOP 2510. In another embodiment, the first time period comprises an entirety of TXOP 2510 (not shown in FIG. 25).

[0268] In an embodiment, frame 2520 indicates triggered TXOP sharing (TXS) to AP 2504 during the duration of time portion 2512. In an example, frame 2520 may comprise a control frame comprising a trigger frame. The trigger frame may comprise a MU-RTS trigger frame. In an example, the MU-RTS trigger frame may comprise a MU-RTS TXS trigger frame. In an embodiment, frame 2520 comprises a broadcast frame.

[0269] In an embodiment, AP 2502 disables / deactivates, an NPCA mode of operation during time portion 2512 of the TXOP 2510. In an embodiment, disabling / deactivating the NPCA mode of operation during time portion 2512 of TXOP 2510 comprises disabling / deactivating, by AP 2502, the NPCA mode of operation at a start time, e.g., T1 , of time portion 2512 of TXOP 2510. In another embodiment, AP 2502 disables / deactivates an NPCA mode of operation during the first time period. In an embodiment, when the NPCA mode of operation is disabled / deactivated, AP 2502 is configured to not switch from the PCH to the NPCA PCH in response to an inter-BSS PPDU on the PCH.

[0270] In an embodiment, STA 2506 receives frame 2520. In an example, STA 2506 decodes the user info field of frame 2520 to obtain / determine time portion 2512 of TXOP 2510 in response to the first field of frame 2520. In an embodiment, STA 2506 disables / deactivates, an NPCA mode of operation during time portion 2512 of the TXOP 2510. In an embodiment, disabling / deactivating the NPCA mode of operation during time portion 2512 of TXOP 2510 comprises disabling / deactivating, by STA 2506, the NPCA mode of operation at a start time, e.g., T1 , of time portion 2512 of TXOP 2510. In another example, STA decodes the first field and obtains the first time period. In an embodiment, STA 2506 disables / deactivates, an NPCA mode of operation during the first time period. In an embodiment, when the NPCA mode of operation is disabled / deactivated, STA 2506 is configured to not switch from the PCH to the NPCA PCH in response to an inter-BSS PPDU on the PCH.

[0271] On receiving frame 2520 via the PCH, AP 2504 may determine that AP 2502 has shared TXOP 2510 with AP 2504 on the PCH for the duration of time portion 2512. In an embodiment, AP 2504 transmits a CTS frame 2522 via the PCH to AP 2502, in response to frame 2520.

[0272] After transmitting CTS frame 2522, AP 2504 may use the TXOP on the PCH for the remaining duration of time portion 2512. As shown in FIG. 25, after transmitting CTS frame 2522, AP 2504 transmits a PPDU 2524 via the PCH to STA 2508. PPDU 2524 may indicate a transmission (of one or more frames) on the PCH . A duration of the transmission on the PCH may be provided by a duration field of a first frame carried by PPDU 2524, a TXOP duration field of PPDU 2524, or a length field of the = PPDU 2524. TheDocket No.: 24-3059PCT duration of the transmission on the PCH may comprise / correspond to the remaining duration of time portion 2512. For example, the duration field of the first frame of the one or more frames carried by PPDU 2524 may indicate the remaining duration of time portion 2512. In an example, PPDU 2524 may carry a downlink frame transmitted to STA 2508. In response to the downlink frame carried in PPDU 2524, STA 2508 may transmit a frame 2526 via the PCH to AP 2504. In an example, frame 2526 may comprise a BA frame. In another example, PPDU 2524 may carry a trigger frame soliciting a frame 2526 from STA 2508. In response to the trigger frame carried in PPDU 2524, STA 2508 may transmit a TB PPDU carrying frame 2526 via the PCH to AP 2504. In an example, frame 2526 may comprise an uplink frame.

[0273] AP 2502 may detect PPDU 2524 on the PCH. AP 2502 may determine that PPDU 2524 being received via the PCH comprises an inter-BSS PPDU. In an implementation, AP 2502 may set a basic NAV associated with the PCH based on receiving PPDU 2524 on the PCH. In an implementation, AP 2502 may be configured to set the basic NAV for the PCH based on a duration of the OBSS transmission on the PCH (hereinafter, OBSS NAV duration or OBSS TXOP duration). The duration of the OBSS transmission may comprise / correspond to the remaining duration of time portion 2512.

[0274] In an embodiment, after receiving PPDU 2524, AP 2502 may remain on the PCH. Specifically, AP 2502 does not switch from the PCH to an NPCA PCH in response to PPDU 2524. In an embodiment, not switching, by AP 2502, from the PCH to an NPCA PCH in response to PPDU 2524 may be based on determining that PPDU 2524 being received via the PCH comprises an inter-BSS PPDU. Not switching, by AP 2502, from the PCH to an NPCA PCH in response to PPDU 2524 may be based on disabling / deactivating. by AP 2502, the NPCA mode of operation during time portion 2512 of TXOP 2510. Not switching, by AP 2502, from the PCH to the NPCA PCH may comprise not switching from the PCH to the NPCA PCH before an end of the TXOP 2510.

[0275] STA 2506 may detect PPDU 2524 on the PCH. STA 2506 may determine that PPDU 2524 being received via the PCH comprises an inter-BSS PPDU. In an implementation, STA 2506 may set a basic NAV associated with the PCH based on receiving PPDU 2524 on the PCH. In an implementation, STA 2506 may be configured to set the basic NAVs for the PCH based on a duration of the OBSS transmission on the PCH (hereinafter, OBSS NAV duration or OBSS TXOP duration). The duration of the OBSS transmission may comprise / correspond to the remaining duration of time portion 2512 as indicated in the duration field of PPDU 2524.

[0276] In an embodiment, after receiving PPDU 2524, STA 2506 may remain on the PCH Specifically, STA 2506 does not switch from the PCH to an NPCA PCH in response to PPDU 2524. In an embodiment, not switching, by STA 2506, from the PCH to an NPCA PCH in response to PPDU 2524 may be based on determining that PPDU 2524 being received via the PCH comprises an inter-BSS PPDU. Not switching, by STA 2506, from the PCH to an NPCA PCH in response to PPDU 2524 may be based on disabling / deactivating, by STA 2506, the NPCA mode of operation during time portion 2512. Not switching,Docket No.: 24-3059PCT by STA 2506, from the PCH to the NPCA PCH may comprise not switching from the PCH to the NPCA PCH before an end of the TXOP 2510.

[0277] As shown in FIG. 25, by supporting the proposed NPCA operation described herein, AP 2502 and / or STA 2506 remain on the PCH during time portion 2512 of TXOP 2510 allocated to AP 2504. Unnecessary back-and-forth switching by AP 2502 and / or STA 2506 from the PCH to the NPCA PCH may be prevented and processing / power resources of AP 2502 and / or STA 2506 may be saved.

[0278] FIG. 26 shows an example 2600 that illustrates an operation according to an embodiment. Example 2600 is provided for the purpose of illustration only and is not limiting. As shown in FIG. 26, example 2600 may include APs 2602 and 2604 and STAs 2606, 2608, and 2630. STA 2606 may be associated with AP 2602, and STA 2608 may be associated with AP 2604. STA 2630 may comprise an AP STA or a non-AP STA. AP 2602, AP 2604, STA 2606, STA 2608, and / or STA 2630 may each comprise a multi-link device (MLD). In example 2600, it is assumed that APs 2602 and 2604 and STAs 2606 and 2608 are within communication range of each other. It is further assumed that AP 2602, STA 2606, and STA 2630 are within communication range of each other.

[0279] In an example, APs 2602 and 2604 and STA 2630 may belong to the same ESS as described above in FIG. 1 . In such a case, APs 2602 and 2604 may be connected by a DS to support ESS features. In another example, APs 2602 and 2604 and STA 2630 belong to different BSSs. In an embodiment, AP 2602 may belong to a first BSS, AP 2604 may belong to a second BSS, and STA 2630 may belong to a third BSS. In an embodiment, the second BSS may comprise a first overlapping basic service set (OBSS) relative to the first BSS. The third BSS may comprise a second OBSS relative to the first BSS.

[0280] In an embodiment, APs 2602 and 2604 may form a multi-AP group. AP 2602 may be a sharing / master AP of the multi-AP group. AP 2604 may be a shared / slave AP of the multi-AP group. As part of the multi-AP group, APs 2602 and 2604 may be connected by a backhaul. In an example, the backhaul may be a wireless backhaul.

[0281] In an example, APs 2602 and 2604 may complete a multi-AP setup procedure as described above prior to the beginning of example 2600. In an implementation, the multi-AP setup procedure may comprise a multi-AP coordination discovery procedure as described above.

[0282] In an example, before example 2600 begins, APs 2602 and 2604 may complete a multi-AP selection phase such as multi-AP selection phase 1010 described in FIG. 10 above; and / or a multi-AP coordination negotiation procedure; and / or a polling phase of CTDMA procedure such as polling phase 1214 described in FIG. 12.

[0283] In example 2600, AP 2602 and STA 2606 may both support NPCA operation and may operate over a plurality of channels, including a primary channel (PCH), an NPCA primary channel (NPCA PCH), and a first secondary channel (SCH1 ).Docket No.: 24-3059PCT

[0284] In an embodiment, AP 2602 supports a first capability that allows / enables AP 2602 to perform the operations further described below. In an example, support of the first capability may allow AP 2602 to transmit a first frame comprising a first field that instructs a STA to decode / receive a second field of the first frame to obtain / determine a time portion of a TXOP obtained by AP 2602 on a PCH. In an example, support of the first capability may further allow AP 2602 to disable / deactivate an NPCA mode of operation during the time portion of the TXOP.

[0285] In an embodiment, STA 2606 supports a second capability that allows / enables STA 2606 to perform the operations described below. In an example, support of the second capability allows STA 2606 to receive and process a first frame from a first AP indicating sharing, by the first AP with a second AP, of a time portion of a TXOP obtained by the first AP on a PCH and a duration of the time portion of the TXOP. In an example, support of the second capability may allow STA 2606 to decode a first field of the first frame instructing the STA to decode a second field of the first frame to obtain / determine the time portion of the TXOP. In an example, support of the second capability may further allow STA 2606 to disable / deactivate an NPCA mode of operation during the time portion of the TXOP.

[0286] As shown in FIG. 26, example 2600 may begin with AP 2602 obtaining a TXOP 2610 on the PCH and transmitting a frame 2620 on the PCH. In an example, AP 2602 may transmit frame 2620 using EDCA. In an embodiment, frame 2620 indicates sharing, by AP 2602 with AP 2604, of a time portion 2612 of TXOP 2610 obtained by AP 2602 on the PCH. In an embodiment, frame 2620 further indicates a duration of time portion 2612 of TXOP 2610. In an embodiment, frame 2620 comprises an allocation for AP 2604. In an embodiment, a user info field of frame 2620 comprises the allocation for AP 2604. The user info field may comprise an allocation duration field and an identifier of AP 2604. In an embodiment, the allocation duration field indicates the duration of time portion 2612 of TXOP 2610. As shown in FIG. 26, the duration of time portion 2612 may start at a time T1 and end at a time T2.

[0287] In an embodiment, a first field of frame 2620 instructs STA 2606 to decode the user info field to obtain / determine time portion 2612 of TXOP 2610. In an embodiment, the first field of frame 2620 instructs STA 2606 to decode the allocation duration field. In an embodiment, the first field of frame 2620 indicates a first time period during which STA 2606 is to deactivate / disable the NPCA mode of operation. In an embodiment, the first field comprises a common info field or a special user info field. In an embodiment, the first time period comprises to time portion 2612 of TXOP 2610. In an embodiment, the first time period begins before time portion 2612 of TXOP 2610. In an embodiment, the first time period ends after time portion 2612 of TXOP 2610. In another embodiment, the first time period comprises an entirety of TXOP 2610 (not shown in FIG. 26). In an embodiment, frame 2620 indicates triggered TXOP sharing (TXS) to AP 2604 during the duration of time portion 2612. In an example, frame 2620 may comprise a control frame comprising a trigger frame. The trigger frame may comprise a MU-RTS trigger frame. In an example, the MU-RTS trigger frame may comprise a MU-RTS TXS trigger frame. In an embodiment, frame 2620 comprises a broadcast frame.Docket No.: 24-3059PCT

[0288] In an embodiment, AP 2602 disables / deactivates, an NPCA mode of operation during time portion 2612 of the TXOP 2610. In an embodiment, disabling / deactivating the NPCA mode of operation during time portion 2612 of TXOP 2610 comprises disabling / deactivating, by AP 2602, the NPCA mode of operation at a start time, e.g., T1 , of time portion 2612 of TXOP 2610. In another embodiment, AP 2602 disables / deactivates an NPCA mode of operation during the first time period. In an embodiment, when the NPCA mode of operation is disabled / deactivated, AP 2602 is configured to not switch from the PCH to the NPCA PCH in response to an inter-BSS PPDU on the PCH.

[0289] In an embodiment, STA 2606 receives frame 2620. In an example, STA 2606 decodes the user info field of frame 2620 to obtain / determine time portion 2612 of TXOP 2610 in response to the first field of frame 2620. In an embodiment, STA 2606 disables / deactivates, an NPCA mode of operation during time portion 2612 of the TXOP 2610. In an embodiment, disabling / deactivating the NPCA mode of operation during time portion 2612 of TXOP 2610 comprises disabling / deactivating, by STA 2606, the NPCA mode of operation at a start time, e.g., T1 , of time portion 2612 of TXOP 2610. In another example, STA decodes the first field and obtains the first time period. In an embodiment, STA 2606 disables / deactivates, an NPCA mode of operation during the first time period. In an embodiment, when the NPCA mode of operation is disabled / deactivated, STA 2606 is configured to not switch from the PCH to the NPCA PCH in response to an inter-BSS PPDU on the PCH.

[0290] On receiving frame 2620 via the PCH, AP 2604 may determine that AP 2602 has shared TXOP 2610 with AP 2604 on the PCH for the duration of time portion 2612. In an embodiment, AP 2604 transmits a CTS frame 2622 via the PCH to AP 2602, in response to frame 2620.

[0291] After transmitting CTS frame 2622, AP 2604 may use the TXOP on the PCH for the remaining duration of time portion 2612. As shown in FIG. 26, after transmitting CTS frame 2622, AP 2604 transmits a PPDU 2624 via the PCH to STA 2608. PPDU 2624 may indicate a transmission (of one or more frames) on the PCH. A first duration of the transmission on the PCH may be provided by a duration field of a first frame carried by PPDU 2624, a TXOP duration field of PPDU 2624, or a length field of PPDU 2624. The duration of the transmission on the PCH may comprise / correspond to the remaining duration of time portion 2612. For example, the duration field of the first frame carried by PPDU 2624 may indicate the remaining duration of the duration of time portion 2612. In an example, PPDU 2624 may carry a downlink frame transmitted to STA 2608. In response to the downlink frame carried in PPDU 2624, STA 2608 may transmit a frame 2626 via the PCH to AP 2604. In an example, frame 2626 may comprise a BA frame. In another example, PPDU 2624 may carry a trigger frame soliciting a frame 2626 from STA 2608. In response to the trigger frame carried in PPDU 2624, STA 2608 may transmit a TB PPDU carrying frame 2626 via the PCH to AP 2604. In an example, frame 2626 may comprise an uplink frame.

[0292] AP 2602 may detect PPDU 2624 on the PCH. AP 2602 may determine that PPDU 2624 being received via the PCH comprises an inter-BSS PPDU. In an implementation, AP 2602 may set a first basicDocket No.: 24-3059PCTNAV associated with the PCH based on receiving PPDU 2624 on the PCH. In an implementation, AP 2602 may be configured to set the first basic NAV for the PCH based on a first duration of the OBSS transmission on the PCH (hereinafter, OBSS NAV duration or OBSS TXOP duration). The first duration of the OBSS transmission may comprise / correspond to the remaining duration of time portion 2612.

[0293] In an embodiment, after receiving PPDU 2624, AP 2602 may remain on the PCH. Specifically, AP 2602 does not switch from the PCH to an NPCA PCH in response to PPDU 2624. In an embodiment, not switching, by AP 2602, from the PCH to an NPCA PCH in response to PPDU 2624 may be based on determining that PPDU 2624 being received via the PCH comprises an inter-BSS PPDU. Not switching, by AP 2602, from the PCH to an NPCA PCH in response to PPDU 2624 may be based on disabling / deactivating. by AP 2602, the NPCA mode of operation during time portion 2612 of TXOP 2610. Not switching, by AP 2602, from the PCH to the NPCA PCH may comprise not switching from the PCH to the NPCA PCH before an end of the TXOP 2610.

[0294] STA 2606 may detect PPDU 2624 on the PCH. STA 2606 may determine that PPDU 2624 being received via the PCH comprises an inter-BSS PPDU. In an implementation, STA 2606 may set a first basic NAV associated with the PCH based on receiving PPDU 2624 on the PCH. In an implementation, STA 2606 may be configured to set the first basic NAVs for the PCH based on a first duration of the OBSS transmission on the PCH (hereinafter, OBSS NAV duration or OBSS TXOP duration). The first duration of the OBSS transmission may comprise / correspond to the remaining duration of time portion 2612 as indicated in the duration field of PPDU 2624.

[0295] In an embodiment, after receiving PPDU 2624, STA 2606 may remain on the PCH. Specifically, STA 2606 does not switch from the PCH to an NPCA PCH in response to PPDU 2624. In an embodiment, not switching, by STA 2606, from the PCH to an NPCA PCH in response to PPDU 2624 may be based on determining that PPDU 2624 being received via the PCH comprises an inter-BSS PPDU. Not switching, by STA 2606, from the PCH to an NPCA PCH in response to PPDU 2624 may be based on disabling / deactivating, by STA 2606, the NPCA mode of operation during time portion 2612. Not switching, by STA 2606, from the PCH to the NPCA PCH may comprise not switching from the PCH to the NPCA PCH before an end of the TXOP 2610.

[0296] In an embodiment, AP 2602 enables / activates the NPCA mode of operation at an end time of time portion 2612 of TXOP 2610 (e.g., at time T2). In an implementation, AP 2602 may remain on the PCH after time T2. In an embodiment, STA 2606 enables / activates the NPCA mode of operation at an end time of time portion 2612 of TXOP 2610 (e.g., at time T2). In an implementation, STA 2606 may remain on the PCH after time T2.

[0297] As shown in FIG. 26, after TXOP 2610 ends, STA 2630 obtains a TXOP 2614 and transmits a PPDU 2632 via the PCH. In an implementation, PPDU 2632 may be addressed to another STA that belongs to the third BSS. PPDU 2632 may indicate a transmission (of one or more frames) on the PCH. A second durationDocket No.: 24-3059PCT of the transmission on the PCH may be provided by a duration field of a first frame carried by PPDU 2632, a TXOP duration field of PPDU 2632, or a length field of PPDU 2632. In an example the second duration of the transmission on the PCH may comprise / correspond to a time period 2616. For example, the duration field of the first frame carried by PPDU 2632 may indicate the duration of time period 2616. As shown in FIG. 26, time period 2616 may comprise a portion of TXOP 2614.

[0298] In an embodiment, AP 2602 determines that PPDU 2632 being received, after an end of TXOP 2610, via the PCH comprises an inter-BSS PPDU. In an embodiment, AP 2602 switches from the PCH to the NPCA PCH in response to PPDU 2632. Switching, by AP 2602, from the PCH to the NPCA PCH may comprise switching from the PCH to the NPCA PCH after an end of TXOP 2610. In an implementation, AP 2602 may set a second basic NAV associated with the PCH based on receiving PPDU 2632 on the PCH. In an implementation, AP 2602 may be configured to set the second basic NAV for the PCH based on the second duration indicated in PPDU 2632.

[0299] In an embodiment, STA 2606 determines that PPDU 2632 being received, after the end of the TXOP, via the PCH comprises an inter-BSS PPDU. In an embodiment, STA 2606 switches from the PCH to the NPCA PCH in response to PPDU 2632. Switching, by STA 2606, from the PCH to the NPCA PCH may comprise switching from the PCH to the NPCA PCH after an end of TXOP 2610. In an implementation, STA 2606 may set a second basic NAV associated with the PCH based on receiving PPDU 2632 on the PCH. In an implementation, STA 2606 may be configured to set the second basic NAV for the PCH based on the second duration indicated in PPDU 2632.

[0300] As shown in FIG. 26, by supporting the proposed NPCA operation described herein, AP 2602 and / or STA 2606 remain on the PCH during time portion 2612 of TXOP 2610 allocated to AP 2604. Unnecessary back-and-forth switching by AP 2602 and / or STA 2606 between the PCH and the NPCA PCH may be prevented and processing / power resources of AP 2602 and / or STA 2606 may be saved. Additionally, AP 2602 and / or STA 2606 switch from the PCH to the NPCA PCH during time period 2616 of TXOP 2614 obtained by STA 2630. AP 2602 and / or STA 2606 may communicate via the NPCA PCH during time period 2616.

[0301] FIG. 27 shows an example 2700 that illustrates an operation according to an embodiment. Example 2700 is provided for the purpose of illustration only and is not limiting. As shown in FIG. 27, example 2700 may include APs 2702 and 2704 and STAs 2706 and 2708. STA 2706 may be associated with AP 2702, and STA 2708 may be associated with AP 2704. AP 2702, AP 2704, STA 2706, and / or STA 2708 may each comprise a multi-link device (MLD). In example 2700, it is assumed that APs 2702 and 2704 and STAs 2706 and 2708 are within communication range of each other.

[0302] In an example, APs 2702 and 2704 may belong to the same ESS as described above in FIG. 1 . In such a case, APs 2702 and 2704 may be connected by a DS to support ESS features. In another example, APs 2702 and 2704 belong to different BSSs. In an embodiment, AP 2702 may belong to a first BSS and APDocket No.: 24-3059PCT2704 may belong to a second BSS. In an embodiment, the second BSS may comprise an overlapping basic service set (OBSS) relative to the first BSS.

[0303] In an embodiment, APs 2702 and 2704 may form a multi-AP group. AP 2702 may be a sharing / master AP of the multi-AP group. AP 2704 may be a shared / slave AP of the multi-AP group. As part of the multi-AP group, APs 2702 and 2704 may be connected by a backhaul. In an example, the backhaul may be a wireless backhaul.

[0304] In an example, APs 2702 and 2704 may complete a multi-AP setup procedure as described above prior to the beginning of example 2700. In an implementation, the multi-AP setup procedure may comprise a multi-AP coordination discovery procedure as described above.

[0305] In an example, before example 2700 begins, APs 2702 and 2704 may complete a multi-AP selection phase such as multi-AP selection phase 1010 described in FIG. 10 above; and / or a multi-AP coordination negotiation procedure; and / or a polling phase of CTDMA procedure such as polling phase 1214 described in FIG. 12.

[0306] In example 2700, AP 2702 and STA 2706 may both support NPCA operation and may operate over a plurality of channels, including a primary channel (PCH), an NPCA primary channel (NPCA PCH), and a first secondary channel (SCH1 ).

[0307] In an embodiment, AP 2702 supports a first capability that allows / enables AP 2702 to perform the operations further described below. In an example, support of the first capability may allow AP 2702 to transmit a first frame to instruct a STA to decode / receive a second frame to obtain / determine a time portion of a TXOP obtained by AP 2702 on a PCH. The first frame may further instruct the STA to disable / deactivate an N PCA mode of operation during the time portion of the TXOP. In an example, support of the first capability may further allow AP 2702 to disable / deactivate an NPCA mode of operation during the time portion of the TXOP.

[0308] In an embodiment, STA 2706 supports a second capability that allows / enables STA 2706 to perform the operations described below. In an example, support of the second capability allows STA 2706 to receive and process a first frame from a first AP instructing STA 2706 to decode / receive a second frame to obtain / determine a time portion of a TXOP obtained by the first AP on a PCH. The first frame may further instruct STA 2706 to disable / deactivate the NPCA mode of operation during the time portion of the TXOP. In an example, the second frame indicates sharing, by the first AP with a second AP, of the time portion of the TXOP and a duration of the time portion of the TXOP. In an example, support of the second capability may allow STA 2706 to decode / receive the second frame based on receiving the first frame. In an example, support of the second capability may further allow STA 2706 to disable / deactivate the NPCA mode of operation during the time portion of the TXOP.

[0309] As shown in FIG. 27, example 2700 may begin with AP 2702 obtaining a TXOP 2710 and transmitting to STA 2706 via the PCH a frame 2730 instructing STA 2706 to decode / receive a frame 2720 (to beDocket No.: 24-3059PCT transmitted by AP 2702) to obtain / determine a time portion 2712 of TXOP 2710. In an embodiment, frame 2730 instructs STA 2706 to decode an allocation duration field of frame 2720. In an example, a user info field of frame 2720 may comprise the allocation duration field. In another embodiment, frame 2730 instructs STA 2706 decode a common info field and / or a special user info field of frame 2720. In an embodiment, frame 2730 further instructs STA 2706 to disable / deactivate the NPCA mode of operation during time portion 2712 of TXOP 2710. In an embodiment, frame 2730 comprises a management frame, a control frame or a data frame. In an example, the management frame may comprise an action frame. In an example, the control frame may comprise a trigger frame. In an example, the data frame may comprise a QoS null frame. In an embodiment, STA 2706 may transmit a frame 2732 in response to frame 2730. Frame 2732 may acknowledge frame 2730.

[0310] Subsequently, AP 2702 may transmit frame 2720 on the PCH In an example, AP 2702 may transmit frame 2720 using EDCA. In an embodiment, frame 2720 indicates sharing, by AP 2702 with AP 2704, of time portion 2712 of TXOP 2710 obtained by AP 2702 on the PCH. In an embodiment, frame 2720 further indicates a duration of time portion 2712 of TXOP 2710. In an embodiment, frame 2720 comprises an allocation for AP 2704. In an embodiment, a user info field of frame 2720 comprises the allocation for AP 2704. The user info field may comprise the allocation duration field and an identifier of AP 2704. In an embodiment, the allocation duration field indicates the duration of time portion 2712 of TXOP 2710. As shown in FIG. 27, the duration of time portion 2712 may start at a time T1 and end at a time T2.

[0311] In an embodiment, a first field of frame 2720 instructs STA 2706 to decode the user info field to obtain / determine time portion 2712 of TXOP 2710. In an embodiment, the first field of frame 2720 instructs STA 2706 to decode the allocation duration field. In an embodiment, the first field of frame 2720 indicates a first time period during which STA 2706 is to deactivate / disable the NPCA mode of operation. In an embodiment, the first field comprises a common info field or a special user info field. In an embodiment, the first time period comprises to time portion 2712 of TXOP 2710. In an embodiment, the first time period begins before time portion 2712 of TXOP 2710. In an embodiment, the first time period ends after time portion 2712 of TXOP 2710. In another embodiment, the first time period comprises an entirety of TXOP 2710 (not shown in FIG. 27).

[0312] In an embodiment, frame 2720 indicates triggered TXOP sharing (TXS) to AP 2704 during the duration of time portion 2712. In an example, frame 2720 may comprise a control frame comprising a trigger frame. The trigger frame may comprise a MU-RTS trigger frame. In an example, the MU-RTS trigger frame may comprise a MU-RTS TXS trigger frame. In an embodiment, frame 2720 comprises a unicast frame.

[0313] In an embodiment, AP 2702 disables / deactivates, an NPCA mode of operation during time portion 2712 of the TXOP 2710. In an embodiment, disabling / deactivating the NPCA mode of operation during time portion 2712 of TXOP 2710 comprises disabling / deactivating, by AP 2702, the NPCA mode of operation at a start time, e.g., T1 , of time portion 2712 of TXOP 2710. In another embodiment, AP 2702Docket No.: 24-3059PCT disables / deactivates an NPCA mode of operation during the first time period. In an embodiment, when the NPCA mode of operation is disabled / deactivated, AP 2702 is configured to not switch from the PCH to the NPCA PCH in response to an inter-BSS PPDU on the PCH.

[0314] In an embodiment, STA 2706 receives frame 2720. In an example, STA 2706 decodes frame 2720 to obtain / determine time portion 2712 of TXOP 2710 in response to frame 2730. In an embodiment, decoding of frame 2720 is based on the receiving of frame 2730. In an embodiment, STA 2706 decodes the allocation duration field that indicates the duration of time portion 2712. In an embodiment, decoding of the allocation duration field is based on the receiving of frame 2730. In an embodiment, STA 2706 disables / deactivates, an NPCA mode of operation during time portion 2712 of the TXOP 2710. In an embodiment, disabling / deactivating the NPCA mode of operation during time portion 2712 of TXOP 2710 comprises disabling / deactivating, by STA 2706, the NPCA mode of operation at a start time, e.g., T1 , of time portion 2712 of TXOP 2710. In another example, STA decodes the first field of frame 2720 and obtains the first time period. In an example, decoding of the first field of frame 2720 is based on the receiving frame 2730. In an embodiment, STA 2706 disables / deactivates, an NPCA mode of operation during the first time period. In an embodiment, when the NPCA mode of operation is disabled / deactivated, STA 2706 is configured to not switch from the PCH to the NPCA PCH in response to an inter-BSS PPDU on the PCH.

[0315] On receiving frame 2720 via the PCH, AP 2704 may determine that AP 2702 has shared TXOP 2710 with AP 2704 on the PCH for the duration of time portion 2712. In an embodiment, AP 2704 transmits a CTS frame 2722 via the PCH to AP 2702, in response to frame 2720.

[0316] After transmitting CTS frame 2722, AP 2704 may use TXOP 2710 on the PCH for the remaining duration of time portion 2712. As shown in FIG. 27, after transmitting CTS frame 2722, AP 2704 transmits a PPDU 2724 via the PCH to STA 2708. PPDU 2724 may indicate a transmission (of one or more frames) on the PCH. A first duration of the transmission on the PCH may be provided by a duration field of a first frame carried by PPDU 2724, a TXOP duration field of PPDU 2724, or a length field of PPDU 2724. The first duration of the transmission on the PCH may comprise / correspond to the remaining duration of time portion 2712. For example, the duration field of the first frame carried by PPDU 2724 may indicate the remaining duration of time portion 2712. In an example, PPDU 2724 may carry a downlink frame transmitted to STA 2708. In response to the downlink frame carried in PPDU 2724, STA 2708 may transmit a frame 2726 via the PCH to AP 2704. In an example, frame 2726 may comprise a BA frame. In another example, PPDU 2724 may carry a trigger frame soliciting a frame 2726 from STA 2708. In response to the trigger frame carried in PPDU 2724, STA 2708 may transmit a TB PPDU carrying frame 2726 via the PCH to AP 2704. In an example, frame 2726 may comprise an uplink frame.

[0317] AP 2702 may detect PPDU 2724 on the PCH. AP 2702 may determine that PPDU 2724 being received via the PCH comprises an inter-BSS PPDU. In an implementation, AP 2702 may set a basic NAVDocket No.: 24-3059PCT associated with the PCH based on receiving PPDU 2724 on the PCH. In an implementation, AP 2702 may be configured to set the basic NAV for the PCH based on the first duration indicated in PPDU 2724.

[0318] In an embodiment, after receiving PPDU 2724, AP 2702 may remain on the PCH. Specifically, AP 2702 does not switch from the PCH to an NPCA PCH in response to PPDU 2724. In an embodiment, not switching, by AP 2702, from the PCH to an NPCA PCH in response to PPDU 2724 may be based on determining that PPDU 2724 being received via the PCH comprises an inter-BSS PPDU. Not switching, by AP 2702, from the PCH to an NPCA PCH in response to PPDU 2724 may be based on disabling / deactivating. by AP 2702, the NPCA mode of operation during time portion 2712 of TXOP 2710. Not switching, by AP 2702, from the PCH to the NPCA PCH may comprise not switching from the PCH to the NPCA PCH before an end of the TXOP 2710.

[0319] STA 2706 may detect PPDU 2724 on the PCH. STA 2706 may determine that PPDU 2724 being received via the PCH comprises an inter-BSS PPDU. In an implementation, STA 2706 may set a basic NAV associated with the PCH based on receiving PPDU 2724 on the PCH. In an implementation, STA 2706 may be configured to set the basic NAVs for the PCH based on a duration of the OBSS transmission on the PCH (hereinafter, OBSS NAV duration or OBSS TXOP duration). The duration of the OBSS transmission may comprise / correspond to the remaining duration of time portion 2712 as indicated in the duration field of PPDU 2724.

[0320] In an embodiment, after receiving PPDU 2724, STA 2706 may remain on the PCH. Specifically, STA 2706 does not switch from the PCH to an NPCA PCH in response to PPDU 2724. In an embodiment, not switching, by STA 2706, from the PCH to an NPCA PCH in response to PPDU 2724 may be based on determining that PPDU 2724 being received via the PCH comprises an inter-BSS PPDU. Not switching, by STA 2706, from the PCH to an NPCA PCH in response to PPDU 2724 may be based on disabling / deactivating, by STA 2706, the NPCA mode of operation during time portion 2712. Not switching, by STA 2706, from the PCH to the NPCA PCH may comprise not switching from the PCH to the NPCA PCH before an end of the TXOP 2710.

[0321] As shown in FIG. 27, by supporting the proposed NPCA operation described herein, AP 2702 and / or STA 2706 remain on the PCH during time portion 2712 of TXOP 2710 allocated to AP 2704. Unnecessary back-and-forth switching by AP 2702 and / or STA 2706 from the PCH to the NPCA PCH may be prevented and processing / power resources of AP 2702 and / or STA 2706 may be saved.

[0322] FIG. 28 shows an example 2800 that illustrates an operation according to an embodiment. Example 2800 is provided for the purpose of illustration only and is not limiting. As shown in FIG. 28, example 2800 may include APs 2802 and 2804 and STAs 2806 and 2808. STA 2806 may be associated with AP 2802, and STA 2808 may be associated with AP 2804. AP 2802, AP 2804, STA 2806, and / or STA 2808 may each comprise a multi-link device (MLD). In example 2800, it is assumed that APs 2802 and 2804 and STAs 2806 and 2808 are within communication range of each other.Docket No.: 24-3059PCT

[0323] In an example, APs 2802 and 2804 may belong to the same ESS as described above in FIG. 1. In such a case, APs 2802 and 2804 may be connected by a DS to support ESS features. In another example, APs 2802 and 2804 belong to different BSSs. In an embodiment, AP 2802 may belong to a first BSS and AP 2804 may belong to a second BSS. In an embodiment, the second BSS may comprise an overlapping basic service set (OBSS) relative to the first BSS.

[0324] In an embodiment, APs 2802 and 2804 may form a multi-AP group. AP 2802 may be a sharing / master AP of the multi-AP group. AP 2804 may be a shared / slave AP of the multi-AP group. As part of the multi-AP group, APs 2802 and 2804 may be connected by a backhaul. In an example, the backhaul may be a wireless backhaul.

[0325] In an example, APs 2802 and 2804 may complete a multi-AP setup procedure as described above prior to the beginning of example 2800. In an implementation, the multi-AP setup procedure may comprise a multi-AP coordination discovery procedure as described above.

[0326] In an example, before example 2800 begins, APs 2802 and 2804 may complete a multi-AP selection phase such as multi-AP selection phase 1010 described in FIG. 10 above; and / or a multi-AP coordination negotiation procedure; and / or a polling phase of CTDMA procedure such as polling phase 1214 described in FIG. 12.

[0327] In example 2800, AP 2802 and STA 2806 may both support NPCA operation and may operate over a plurality of channels, including a primary channel (PCH), an NPCA primary channel (NPCA PCH), and a first secondary channel (SCH1 ).

[0328] In an embodiment, AP 2802 supports a first capability that allows / enables AP 2802 to perform the operations further described below. In an example, support of the first capability may allow AP 2802 to transmit to a STA a frame indicating a first time period during which the STA is to deactivate / disable an NPCA mode of operation. The first time period may comprise a time portion of a TXOP obtained by AP 2802 on a PCH. In an example, support of the first capability may further allow AP 2802 to disable / deactivate an NPCA mode of operation during the time portion of the TXOP.

[0329] In an embodiment, STA 2806 supports a second capability that allows / enables STA 2806 to perform the operations described below. In an example, support of the second capability allows STA 2806 to receive and process a frame from a first AP indicating a time period during which the STA is to disable / deactivate the NPCA mode of operation. The time period may correspond to a time portion of a TXOP obtained by the first AP. In an example, support of the second capability may further allow STA 2806 to disable / deactivate an NPCA mode of operation during the time period.

[0330] As shown in FIG. 28, example 2800 may begin with AP 2802 obtaining a TXOP 2810 on the PCH and transmitting to STA 2806 via the PCH a frame 2830 indicating a first time period during which STA 2806 is to deactivate / disable the NPCA mode of operation. In an embodiment, the first time period corresponds to a time portion 2812 of TXOP 2810 obtained by AP 2802. In an embodiment, time portion 2812 is to be sharedDocket No.: 24-3059PCT by AP 2802 with AP 2804. As shown in FIG. 28, time portion 2812 may begin at a time T1 and end at a time T2. In an embodiment, the first time period begins before time portion 2812. In an embodiment, the first time period ends after time portion 2812 In another embodiment, the first time period comprises an entirety of TXOP 2810 (not shown in FIG. 28).

[0331] In an embodiment, frame 2830 comprises a management frame, a control frame or a data frame. In an example, the management frame may comprise an action frame instructing STA 2806. In an example, the control frame may comprise a trigger frame instructing STA 2806. In an example, the data frame may comprise a QoS null frame instructing STA 2806. In an embodiment, STA 2806 may transmit a frame 2832 in response to frame 2830.

[0332] Subsequently, AP 2802 may transmit a frame 2820 In an example, AP 2802 may transmit frame 2820 using EDCA. In an embodiment, frame 2820 indicates sharing, by AP 2802 with AP 2804, of time portion 2812 of TXOP 2810 obtained by AP 2802 on the PCH. In an embodiment, frame 2820 further indicates a duration of time portion 2812 of TXOP 2810. In an embodiment, frame 2820 comprises an allocation for AP 2804. In an embodiment, a user info field of frame 2820 comprises the allocation for AP 2804. The user info field may comprise the allocation duration field and an identifier of AP 2804. In an embodiment, the allocation duration field indicates the duration of time portion 2812 of TXOP 2810.

[0333] In an embodiment, frame 2820 indicates triggered TXOP sharing (TXS) to AP 2804 during the duration of time portion 2812. In an example, frame 2820 may comprise a control frame comprising a trigger frame. The trigger frame may comprise a MU-RTS trigger frame. In an example, the MU-RTS trigger frame may comprise a MU-RTS TXS trigger frame. In an embodiment, frame 2820 comprises a unicast frame.

[0334] In an embodiment, AP 2802 disables / deactivates an NPCA mode of operation during time portion 2812 of TXOP 2810. In an embodiment, disabling / deactivating the NPCA mode of operation during time portion 2812 of TXOP 2810 comprises disabling / deactivating, by AP 2802, the NPCA mode of operation at / before a start time, e.g., T1 , of time portion 2812 of TXOP 2810. In another embodiment, AP 2802 disables / deactivates an NPCA mode of operation during the first time period. In an embodiment, when the NPCA mode of operation is disabled / deactivated, AP 2802 is configured to not switch from the PCH to the NPCA PCH in response to an inter-BSS PPDU on the PCH.

[0335] In an embodiment, STA 2806 disables / deactivates an NPCA mode of operation during the first time period. In an embodiment, when the NPCA mode of operation is disabled / deactivated, STA 2806 is configured to not switch from the PCH to the NPCA PCH in response to an inter-BSS PPDU on the PCH.

[0336] On receiving frame 2820 via the PCH, AP 2804 may determine that AP 2802 has shared TXOP 2810 with AP 2804 on the PCH for the duration of time portion 2812. In an embodiment, AP 2804 transmits a CTS frame 2822 via the PCH to AP 2802, in response to frame 2820.

[0337] After transmitting CTS frame 2822, AP 2804 may use the TXOP on the PCH for the remaining duration of time portion 2812. As shown in FIG. 28, after transmitting CTS frame 2822, AP 2804 transmits aDocket No.: 24-3059PCTPPDU 2824 via the PCH to STA 2808. PPDU 2824 may indicate a transmission (of one or more frames) on the PCH. A first duration of the transmission on the PCH may be provided by a duration field of a first frame carried by PPDU 2824, a TXOP duration field of PPDU 2824, or a length field of PPDU 2824. The first duration of the transmission on the PCH may comprise / correspond to the remaining duration of time portion 2812. For example, the duration field of the first frame carried by PPDU 2824 may indicate the remaining duration of time portion 2812. In an example, PPDU 2824 may carry a downlink frame transmitted to STA 2808. In response to the downlink frame carried in PPDU 2824, STA 2808 may transmit a frame 2826 via the PCH to AP 2804. In an example, frame 2826 may comprise a BA frame. In another example, PPDU 2824 may carry a trigger frame soliciting a frame 2826 from STA 2808. In response to the trigger frame carried in PPDU 2824, STA 2808 may transmit a TB PPDU carrying frame 2826 via the PCH to AP 2804. In an example, frame 2826 may comprise an uplink frame.

[0338] AP 2802 may detect PPDU 2824 on the PCH. AP 2802 may determine that PPDU 2824 being received via the PCH comprises an inter-BSS PPDU. In an implementation, AP 2802 may set a basic NAV associated with the PCH based on receiving PPDU 2824 on the PCH. In an implementation, AP 2802 may be configured to set the basic NAV for the PCH based on the first duration indicated in PPDU 2824.

[0339] In an embodiment, after receiving PPDU 2824, AP 2802 may remain on the PCH. Specifically, AP 2802 does not switch from the PCH to the NPCA PCH in response to PPDU 2824. Not switching, by AP 2802, from the PCH to the NPCA PCH in response to PPDU 2824 may be based on disabling / deactivating, by AP 2802, the NPCA mode of operation during time portion 2812 of TXOP 2810. Not switching, by AP 2802, from the PCH to the NPCA PCH may comprise not switching from the PCH to the NPCA PCH before an end of the TXOP 2810.

[0340] STA 2806 may detect PPDU 2824 on the PCH. STA 2806 may determine that PPDU 2824 being received via the PCH comprises an inter-BSS PPDU. In an implementation, STA 2806 may set a basic NAV associated with the PCH based on receiving PPDU 2824 on the PCH. In an implementation, STA 2806 may be configured to set the basic NAVs for the PCH based on a the first duration indicated in PPDU 2824.

[0341] In an embodiment, after receiving PPDU 2824, STA 2806 may remain on the PCH. Specifically, STA 2806 does not switch from the PCH to an NPCA PCH in response to PPDU 2824. Not switching, by STA 2806, from the PCH to an NPCA PCH in response to PPDU 2824 may be based on disabling / deactivating, by STA 2806, the NPCA mode of operation during time portion 2812. Not switching, by STA 2706, from the PCH to the NPCA PCH may comprise not switching from the PCH to the NPCA PCH before an end of the TXOP 2810.

[0342] As shown in FIG. 28, by supporting the proposed NPCA operation described herein, AP 2802 and / or STA 2806 remain on the PCH during time portion 2812 of TXOP 2810 allocated to AP 2804. Unnecessary back-and-forth switching by AP 2802 and / or STA 2806 from the PCH to the NPCA PCH may be prevented and processing / power resources of AP 2802 and / or STA 2806 may be saved.Docket No.: 24-3059PCT

[0343] FIG. 29 illustrates an example process 2900 according to an embodiment. Example process 2900 is provided for the purpose of illustration only and is not limiting of embodiments. Example process 2900 may be performed by a first access point (AP). The first AP may correspond to AP 2502, 2602, 2702, or 2802, for example. As shown in FIG. 29, example process 2900 may include steps 2902 and 2904.

[0344] Step 2902 includes transmitting, by the first AP to a second AP, a first frame indicating: sharing, by the first AP with the second AP, of a time portion of a TXOP obtained by the first AP on a primary channel (PCH); and a duration of the time portion of the TXOP.

[0345] Step 2904 includes disabling / deactivating, by the first AP, NPCA mode of operation during the time portion of the TXOP.

[0346] In an embodiment, disabling / deactivating the NPCA mode of operation during the time portion of the TXOP comprises disabling / deactivating, by the first AP, the NPCA mode of operation at a start time of the time portion of the TXOP.

[0347] In an embodiment, process 2900 further comprises enabling / activating, by the first AP, the NPCA mode of operation at an end time of the time portion of the TXOP.

[0348] In an embodiment, process 2900 further comprises determining, by the first AP, that a first physical layer protocol data unit (PPDU) being received via the PCH comprises an inter-basic service set (inter-BSS) PPDU; and not switching, by the first AP, from the PCH to an NPCA PCH in response to the first PPDU.

[0349] In an embodiment, not switching from the PCH to the NPCA PCH in response to the first PPDU is based on the disabling / deactivating of the NPCA mode of operation.

[0350] In an embodiment, not switching from the PCH to the NPCA PCH comprises not switching from the PCH to the NPCA PCH before an end of the TXOP.

[0351] In an embodiment, process 2900 further comprises determining, by the first AP, that a second PPDU being received, after an end of the TXOP, via the PCH comprises an inter-BSS PPDU; and switching, by the first AP, from the PCH to the NPCA PCH in response to the second PPDU.

[0352] In an embodiment, switching from the PCH to the NPCA PCH comprises switching from the PCH to the NPCA PCH after an end of the TXOP.

[0353] In an embodiment, the first frame comprises an allocation duration field that indicates the duration of the time portion of the TXOP.

[0354] In an embodiment, a user info field of the first frame comprise the allocation duration field.

[0355] In an embodiment, the user info field of the first frame indicates an identifier of the second AP.

[0356] In an embodiment, process 2900 further comprises transmitting, by the first AP to a station (STA), a second frame indicating a first time period during which the STA is to deactivate / disable the NPCA mode of operation.

[0357] In an embodiment, the first time period corresponds to the time portion of the TXOP.

[0358] In an embodiment, the first time period begins before the time portion of the TXOP.Docket No.: 24-3059PCT

[0359] In an embodiment, the first time period ends after the time portion of the TXOP.

[0360] In an embodiment, the first time period comprises an entirety of the TXOP.

[0361] In an embodiment, the second frame comprises a management frame, a control frame, or a data frame.

[0362] In an embodiment, process 2900 further comprises receiving, from the STA, a third frame in response to the second frame.

[0363] In an embodiment, process 2900 further comprises transmitting, by the first AP to a station (STA), a second frame instructing the STA to decode / receive the first frame to obtain / determine the time portion of the TXOP.

[0364] In an embodiment, the second frame instructs the STA to decode the allocation duration field.

[0365] In an embodiment, the second frame further instructs the STA to disable / deactivate the NPCA mode of operation during the time portion of the TXOP.

[0366] In an embodiment, the second frame comprises a management frame, a control frame or a data frame.

[0367] In an embodiment, a common info field of the first frame instructs the STA to decode the user info field to obtain / determine the time portion of the TXOP.

[0368] In an embodiment, the common info field of the first frame instructs the STA to decode the allocation duration field.

[0369] In an embodiment, a common info field of the first frame indicates a second time period during which the STA is to deactivate / disable the NPCA mode of operation.

[0370] In an embodiment, the second time period corresponds to the time portion of the TXOP.

[0371] In an embodiment, the second time period begins before the time portion of the TXOP.

[0372] In an embodiment, the second time period ends after the time portion of the TXOP.

[0373] In an embodiment, the second time period comprises an entirety of the TXOP.

[0374] In an embodiment, the first frame indicates triggered TXOP sharing (TXS) to the second AP during the duration of the time portion of the TXOP.

[0375] In an embodiment, the first frame comprises a multi-user request-to-send (MU-RTS) trigger frame.

[0376] In an embodiment, the first frame comprises a broadcast frame.

[0377] In an embodiment, the first frame comprises a unicast frame.

[0378] FIG. 30 illustrates an example process 3000 according to an embodiment. Example process 3000 is provided for the purpose of illustration only and is not limiting of embodiments. Example process 3000 may be performed by a first AP. The first AP may correspond to AP 2602, for example. As shown in FIG. 30, example process 3000 may include steps 3002 and 3004.Docket No.: 24-3059PCT

[0379] Step 3002 includes transmitting, by the first AP to a second AP, a first frame indicating: sharing, by the first AP with the second AP, of a time portion of a TXOP obtained by the first AP on a primary channel (PCH); and a duration of the time portion of the TXOP.

[0380] Step 3004 includes enabling / activating, by the first AP, an NPCA mode of operation at an end time of the time portion of the TXOP.

[0381] In an embodiment, process 3000 further comprises disabling / deactivating, by the first AP, the NPCA mode of operation at a start time of the time portion of the TXOP.

[0382] In an embodiment, process 3000 further comprises: determining, by the first AP, that a first physical layer protocol data unit (PPDU) being received via the PCH comprises an inter-basic service set (inter-BSS) PPDU; and not switching, by the first AP, from the PCH to a NPCA PCH in response to the first PPDU.

[0383] In an embodiment, not switching from the PCH to the NPCA PCH in response to the PPDU is based on the disabling / deactivating of the NPCA mode of operation.

[0384] In an embodiment, not switching from the PCH to the NPCA PCH comprises not switching from the PCH to the NPCA PCH before an end of the TXOP.

[0385] In an embodiment, process 3000 further comprises: determining, by the first AP, that a second PPDU being received, after an end of the TXOP, via the PCH comprises an inter-BSS PPDU; and switching, by the first AP, from the PCH to the NPCA PCH in response to the second PPDU.

[0386] In an embodiment, switching from the PCH to the NPCA PCH in response to the PPDU is based on the enabling / activating of the NPCA mode of operation.

[0387] In an embodiment, switching from the PCH to the NPCA PCH comprises switching from the PCH to the NPCA PCH after an end of the TXOP.

[0388] FIG. 31 illustrates an example process 3100 according to an embodiment. Example process 3100 is provided for the purpose of illustration only and is not limiting of embodiments. Example process 3100 may be performed by a STA, such as STA 2506, STA 2606, or STA 2706, for example. As shown in FIG. 31 , example process 3100 may include steps 3102 and 3104.

[0389] Step 3102 includes receiving, by the STA, a first frame indicating: sharing, by a first AP with a second AP, of a time portion of a TXOP obtained by the first AP on a primary channel (PCH); and a duration of the time portion of the TXOP.

[0390] Step 3104 includes disabling / deactivating, by the STA, an NPCA mode of operation during the time portion of the TXOP.

[0391] In an embodiment, process 3100 further comprises decoding, by the STA, the first frame to obtain / determine the time portion of the TXOP.

[0392] In an embodiment, the decoding of the first frame comprises decoding an allocation duration field of the first frame to obtain the duration of the time portion of the TXOP.

[0393] In an embodiment, the first frame comprises a unicast frame.Docket No.: 24-3059PCT

[0394] In an embodiment, process 3100 further comprises receiving, by the STA from the first AP, a second frame instructing the STA to decode / receive the first frame to obtain / determine the time portion of the TXOP.

[0395] In an embodiment, the first frame comprises an allocation duration field that indicates the duration of the time portion of the TXOP, and wherein the second frame instructs the STA to decode the allocation duration field.

[0396] In an embodiment, the decoding of the first frame is based on the receiving of the second frame.

[0397] In an embodiment, the decoding of the allocation duration field is based on the receiving of the second frame.

[0398] In an embodiment, the second frame further instructs the STA to disable / deactivate the NPCA mode of operation during the time portion of the TXOP.

[0399] In an embodiment, the second frame comprises a management frame, a control frame, or a data frame.

[0400] In an embodiment, the first frame comprises a broadcast frame.

[0401] In an embodiment, the first frame comprises an allocation duration field that indicates the duration of the time portion of the TXOP.

[0402] In an embodiment, a common info field of the first frame instructs the STA to decode / receive the allocation duration field.

[0403] In an embodiment, a common info field of the first frame indicates a first time period during which the STA is to deactivate / disable the NPCA mode of operation.

[0404] In an embodiment, the first time period comprises an entirety of the TXOP.

[0405] In an embodiment, a user info field of the first frame comprise the allocation duration field.

[0406] In an embodiment, the user info field of the first frame indicates an identifier of the second AP.

[0407] In an embodiment, the first frame comprises a multi-user request-to-send (MU-RTS) trigger frame.

[0408] In an embodiment, the first frame indicates triggered TXOP sharing (TXS) to the second AP during the time portion of the TXOP.

[0409] In an embodiment, process 3100 further comprises: determining, by the STA, that a physical layer protocol data unit (PPDU) being received via the PCH comprises an inter-basic service set (in ter-BSS) PPDU; and not switching, by the STA, from the PCH to a NPCA PCH in response to the PPDU.

[0410] In an embodiment, not switching from the PCH to the NPCA PCH in response to the PPDU is based on the disabling / deactivating of the NPCA mode of operation.

[0411] In an embodiment, not switching from the PCH to the NPCA PCH comprises not switching from the PCH to the NPCA PCH before an end of the TXOP.

[0412] In an embodiment, the STA is associated with the first AP.

[0413] FIG. 32 illustrates an example process 3200 according to an embodiment. Example process 3200 is provided for the purpose of illustration only and is not limiting of embodiments. Example process 3200 mayDocket No.: 24-3059PCT be performed by a STA, such as STA 2806, for example. As shown in FIG. 32, example process 3200 may include steps 3202 and 3204.

[0414] Step 3202 includes receiving, by the STA from a first AP, a first frame indicating a first time period during which the STA is to deactivate / disable an NPCA mode of operation.

[0415] Step 3204 includes disabling / deactivating, by the STA, the NPCA mode of operation during the first time period.

[0416] In an embodiment, the first time period corresponds to a time portion of a TXOP obtained by the first AP on a primary channel (PCH).

[0417] In an embodiment, the first time period begins before the time portion of the TXOP.

[0418] In an embodiment, the first time period ends after the time portion of the TXOP.

[0419] In an embodiment, the first time period comprises an entirety of the TXOP.

[0420] In an embodiment, the time portion of the TXOP is shared by the first AP with a second AP.

[0421] In an embodiment, process 3200 further comprises: determining, by the STA, that a physical layer protocol data unit (PPDU) being received via the PCH comprises an inter-basic service set (in ter-BSS) PPDU; and not switching, by the STA, from the PCH to a NPCA PCH in response to the PPDU.

[0422] In an embodiment, not switching from the PCH to the NPCA PCH in response to the PPDU is based on the disabling / deactivating of the NPCA mode of operation.

[0423] In an embodiment, not switching from the PCH to the NPCA PCH comprises not switching from the PCH to the NPCA PCH before an end of the TXOP.

[0424] In an embodiment, the first frame comprises a management frame, a control frame or a data frame.

[0425] In an embodiment, the STA is associated with the first AP

[0426] In an embodiment, a STA (e.g., an AP or non-AP STA) described in any of the embodiments above may further perform one or more of the NPCA operations described herein below. As would be understood by a person of skill in the art based on the teachings, any of the NPCA operations described below may be combined with the procedures / operations described above. For example, a STA (e.g., an AP or non-AP STA) described above in relation to FIGS. 21 -32 may switch to the NPCA primary channel for NPCA operation if either condition 1) or 2), described below, is met.

[0427] Hereinafter, a STA that supports NPCA operation is called an NPCA STA. An AP that supports NPCA operation is called an NPCA AP. A non-AP NPCA STA may set an NPCA Supported field of a UHR MAC Capabilities Information field of a UHR Capabilities element to 1 . In an implementation, a non-AP NPCA STA does not enable the NPCA mode unless the non-AP NPCA STA is associated with an NPCA AP that has enabled NPCA operation.

[0428] In an implementation, an NPCA AP that has an operating bandwidth less than 80 MHz does not enable NPCA operation. In an implementation, an AP of a multiple BSSID set that enables NPCA operation may indicate the same NPCA primary channel, same NPCA minimum duration, same NPCA switching delay,Docket No.: 24-3059PCT and same NPCA switch back delay as all of the other APs of the same multiple BSSID set that have enabled NPCA operation. In an implementation, an AP of a co-hosted BSS that enables NPCA operation may indicate the same NPCA primary channel, same NPCA minimum duration, same NPCA switching delay, and same NPCA switch back delay as all of the other APs of the same co-hosted BSSs that have enabled NPCA operation.

[0429] In an implementation, an NPCA AP that has enabled NPCA operation may set to 1 the NPCA Enabled field in the UHR Operation element of the (Re)Association Response, UHR Link Reconfiguration Notify, Beacon and Probe Response frames that it transmits.

[0430] In an implementation, an NPCA AP with a value (e.g., dotH HEPSROption Implemented) set to true may set the TXVECTOR parameter SPATIAL_REUSE to PSR_DISALLOW for PPDUs that it transmits, and may set the PSR Disallowed subfield in the SR Control field of the Spatial Reuse Parameter Set element to 1 in Management frames it transmits before enabling NPCA operation in its BSS and while NPCA operation remains enabled.

[0431] In an implementation, an AP may enable a PHY Header-based (PHYLEN) NPCA operation by setting a MAC Header-based (MOPLEN) NPCA field to 0 and may enable both PHYLEN NPCA and MOPLEN NPCA operation by setting the MOPLEN NPCA field to 1 .

[0432] In an implementation, an NPCA AP may advertise an NPCA Disabled Subchannel Bitmap field in the NPCA Operation Parameters field. The NPCA Disabled Subchannel Bitmap field may indicate the subchannels that are punctured when an NPCA STA operates on the NPCA primary channel:If an NPCA Disabled Subchannel Bitmap field is present, then the NPCA Disabled Subchannel Bitmap Field Present bit may be set to 1 , otherwise the NPCA Disabled Subchannel Bitmap Field Present field may be set to 0.The NPCA Disabled Subchannel Bitmap field value may satisfy the following requirements:• The puncturing pattern indicated by the value of the NPCA Disabled Subchannel Bitmap field is a valid non-OFDMA puncturing pattern.• A 20 MHz subchannel indicated as punctured in the Disabled Subchannel Bitmap field of an EHT Operation element (if any) is also indicated as punctured in the NPCA Disabled Subchannel Bitmap field.An NPCA AP may indicate one or more 20 MHz subchannels as punctured in the NPCA Disabled Subchannel Bitmap field of the EHT Operation Element for the purpose of maximizing the BW of the NPCA operating channel.An NPCA AP may indicate one or more 20 MHz subchannels as punctured in the NPCA Disabled Subchannel Bitmap field of the EHT Operation Element for the purpose of creating a gap between the PPDU that initiated the NPCA switch and the NPCA operating channel.Docket No.: 24-3059PCTIf no NPCA Disabled Subchannel Bitmap field is present in the NPCA Operation Parameters field transmitted by the AP that the STA is associated with, then the subchannels may be punctured during NPCA operation.

[0433] In an implementation, an NPCA AP may indicate a value in the NPCA Primary Channel field, of transmitted NPCA Operation Parameters fields, that corresponds to a channel that is located within the secondary 40 MHz of the BSS operating channel if the BSS is an 80 MHz BSS, that corresponds to a channel that is located within the secondary 80 MHz of the BSS operating channel if the BSS is a 160 MHz BSS, and that corresponds to a channel that is located within the secondary 160 MHz of the BSS operating channel if the BSS is a 320 MHz BSS.

[0434] In an implementation, a non-AP NPCA STA may indicate an NPCA switching delay and an NPCA switch back delay, respectively, in the NPCA Switching Delay field and NPCA Switch Back Delay fields of the OMP Request frames.

[0435] In an implementation, when a non-AP STA that supports NPCA mode (re)associates with an AP, the NPCA mode may be disabled by default for the non-AP STA. In the UHR OMP request sent to enable or update the parameters of NPCA mode for the non-AP STA, a non-AP STA may include the following in the Mode Parameters field of the Mode Tuple field:NPCA switching delay,NPCA switch back delay.

[0436] In an implementation, for a non-AP STA to enable NPCA mode, the associated AP must support NPCA and must have NPCA enabled for the BSS.

[0437] In an implementation, if an NPCA AP that has enabled NPCA operation advertises MU EDCA parameters in the Beacon frames that it transmits, a MU EDCA protocol may apply jointly on both BSS primary channel and NPCA primary channel for a non-AP NPCA STA. In an implementation, an NPCA STA may maintain a single MU EDCA timer that is shared across the BSS primary channel and the NPCA primary channel, transition from using EDCA parameters to using MU EDCA parameters (and vice-versa) at the same time on both the BSS primary channel and the NPCA primary channel based on certain conditions that occur on either the BSS primary channel or the NPCA primary channel, and when the STA is operating on the NPCA primary channel, use the same MU EDCA parameters as are used on the BSS primary channel except that AIFSN[AC] may be set to 0 for all ACs. When the STA switches back to the BSS primary channel, it may revert to using the AIFSN[AC] values from the dot11 MUEDCATable.

[0438] In an implementation, an NPCA STA does not switch to the NPCA primary channel for NPCA operation if NPCA mode has not been enabled by its associated AP.

[0439] In an implementation, an NPCA STA may switch to the NPCA primary channel for NPCA operation if the NPCA mode has been enabled for the BSS of which it is a member and either condition 1 ) or 2) is met:Docket No.: 24-3059PCT1 ) the STA received a PPDU and / or received a PHY-RXSTART. indication primitive for an HE / EHT / UHR PPDU on the BSS primary channel and all of the following conditions are true: a) Condition 2) is not true. b) The PPDU is classified by the STA as in inter-BSS PPDU. c) At least one of the following conditions is true:1) The value of the MAC variable NPCA_PPDU_REM_DUR derived from the received PPDU is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to the BSS of which the STA is a member. ii) If the NPCA AP corresponding to the BSS of which the STA is a member has enabled MOPLEN NPCA in addition to PHYLEN NPCA and the value of the MAC variable NPCA_PHY_TXOP_REM_DUR derived from the received PPDU is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to the BSS of which the STA is a member. d) The bandwidth of the PPDU is determined by the STA to be 20, 40, 80 or 160 MHz, based on the Bandwidth field in the PHY preamble of the PPDU and the channel occupied by the PPDU does not overlap with the NPCA primary channel. e) If the STA maintains an intra-BSS NAV, it is zero.2) All of the following conditions are true: a) A sequence of three PPDUs, separated by aSIFSTime, is identified on the BSS primary channel, comprising an initial Control frame, an initial response frame, and a third PPDU following the initial response frame. b) The STA received at least the first PPDU containing the initial Control frame and the PHY- RXSTART. indication and / or the PHY-RXEARLYSIG. indication of the third PPDU. c) An indication that a valid TXOP was obtained on the BSS primary channel, as verified by the receipt of a PHY-RXEARLYSIG. indication or PHYRXSTART. indication primitive corresponding to the third PPDU that occurs during a time window that: i) begins at aSIFSTime + ICR_Timeout after the MAC receives a PHY-RXEND. indication primitive corresponding to the first PPDU, where ICR_Timeout is equal to:(1) The length (in usee) of the expected CTS if the initial Control frame is an RTS or an MU-RTS Trigger frame,(2) the value of RXTIME calculated using Equation (27-147) with the value of LENGTH replaced by the value from the UL Length field of the Common Info field, if the initial Control frame is a BSRP Trigger frame or a BSRP NTB Trigger frame. ii) has a duration that is equal to NPCA_START_TIMEOUT which is aSIFSTime + (2 x aSlotTime) + aRxPHYStartDelay.Docket No.: 24-3059PCT d) At least one of the three PPDUs in the sequence of PPDUs is classified by the STA as an inter-BSS PPDU. e) At least one of the following conditions is true: i) The NPCA AP corresponding to the BSS of which the STA is a member has enabled PHYLEN NPCA only and the value of the MAC variable NPCA_PPDU_REM_DUR derived from the received third PPDU of the sequence of PPDUs is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to its BSS. ii) If the NPCA AP corresponding to the BSS of which the STA is a member has enabled MOPLEN NPCA in addition to PHYLEN NPCA and the value of the MAC variable NPCA_CFRAME_TXOP_REM_DUR derived from the received first PPDU (containing the initial Control frame of the control frame exchange) of the sequence of PPDUs is greater than the value indicated in the most recently received or transmitted NPCA Minimum Duration Threshold field corresponding to its associated BSS. f) The bandwidth of the third PPDU is determined by the STA to be 20, 40, 80, 160 or 320 MHz based on the Bandwidth field in the PHY preamble of the PPDU not overlap with the NPCA primary channel and the channel occupied by the PPDU does not overlap with the NPCA primary channel. g) If the STA maintains an intra-BSS NAV, it is zero at the time of the receipt of the PHYRXSTART.indication and / or the PHY-RXEARLYSIG.indication of the first PPDU.

[0440] In an implementation, when a PHY-CCA.indication(BUSY) primitive corresponding to the start of the reception of a PPDU is indicated at an NPCA STA while operating on the BSS primary channel, the values of the MAC variables NPCA_PPDU_REM_DUR, NPCA_PHY_TXOP_REM_DUR and NPCA_TIMER are all set to 0. When a PHY-CCA.indication(BUSY) corresponding to the start of the reception of a PPDU containing an initial Control frame is indicated at an NPCA STA while operating on the BSS primary channel, the MAC variable NPCA_CFRAME_TXOP_REM_DUR is set to 0.

[0441] In an implementation, the MAC variable NPCA_PPDU_REM_DUR derived from a received PPDU is equal to the value in usee, of the remaining duration of the received PPDU, determined by the MAC at the time of the receipt of the PHY-RXSTART. indication primitive associated with the received PPDU, by subtracting the time elapsed between the reception of the PHY-CCA.indication(BUSY) and PHYRXSTART.indication primitives associated with the received PPDU from the value of RXTIME of the received PPDU.

[0442] In an implementation, the MAC variable NPCA_PHY_TXOP_REM_DUR derived from a received PPDU is:Set to 0, if the RXVECTOR parameter TXOP_DURATION is UNSPECIFIED, or if the NPCA AP corresponding to the BSS of which the STA is a member has not enabled MOPLEN NPCA.Otherwise, it is equal to the value in usee, of the remaining duration of the PPDU, determined by the MAC at the time of the receipt of the PHY-RXSTART. indication primitive associated with the received PPDU,Docket No.: 24-3059PCT by subtracting the time elapsed between the reception of the PHY-CCA.indication(BUSY) and PHY- RXSTART. indication primitives associated with the received PPDU from the value of RXTIME corresponding to the received PPDU, plus the value of the TXOP_DURATION parameter of the RXVECTOR of the PPDU.

[0443] In an implementation, the MAC variable NPCA_CFRAME_TXOP_REM_DUR derived from a received PPDU is:Set to 0, if the NPCA AP corresponding to the BSS of which the STA is a member has not enabled MOPLEN NPCA.Otherwise, it is set to the value in the Duration / ID field of the initial Control frame in the received PPDU at the receipt of the PHY-RXEND. indication primitive of the PPDU that contained the frame. The value of NPCA_CFRAME_TXOP_REM_DUR is reduced by the amount of time elapsed between the PHY- RXEND.indication primitive of the initial Control frame from which the value of NPCA_CFRAME_TXOP_REM_DUR was determined and the PHY-RXSTART. indication primitive of the third PPDU of the frame exchange sequence identified in condition 2) above at the time of the receipt of the PHY- RXSTART. indication primitive of the third PPDU.

[0444] In an implementation, when an NPCA STA switches to the NPCA primary channel for NPCA operation, then the following rules apply:1 ) If the STA switches from the BSS primary channel to the NPCA primary channel based on meeting condition 1) described above, the STA initiates the switch at the NPCA HE switch time and shall be ready to transmit and receive frames (subject to its capabilities and operating mode) on the NPCA primary channel no later than the value of its most recently indicated NPCA switching delay after the NPCA HE switch time. The NPCA HE switch time is the point in time immediately after the reception of the HE-SIG-A / U-SIG field of the received PPDU from condition 1) above.2) If the STA switches from the BSS primary channel to the NPCA primary channel based on meeting condition 2) described above, the STA initiates the switch at the NPCA NHT switch time and shall be ready to transmit and receive frames addressed to it (subject to its capabilities and operating mode) on the NPCA primary channel no later than the value of its most recently indicated NPCA switching delay after the NPCA NHT switch time. The NPCA NHT switch time is equal to the point in time that is 3 x TSYM after the reception of the L-SIG field of the third PPDU of the received sequence of PPDUs from condition 2) above.3) The STA uses the same EDCA parameter set and EPCS EDCA parameter set values for operation on the NPCA primary channel as it uses on the BSS primary channel.4) At each NPCA HE switch time or NPCA NHT switch time, as appropriate, if the STA is an AP or if the STA is a non-AP STA and transmission of frames that are not a response to a Trigger frame is not disabled by the MU EDCA protocol, the STA may initiate a TXOP on the NPCA primary channel with the following exceptions: a) Each time that the STA switches to the NPCA primary channel, the STA does:Docket No.: 24-3059PCT i) If condition 1) is met, set NPCA_CFRAME_TXOP_REM_DUR to O, set NPCA_TIMER to the largest non-zero value of the variables NPCA_PPDU_REM_DUR, NPCA_PHY_TXOP_REM_DUR and NPCA_CFRAME_TXOP_REM_DUR, minus the switch back delay that the STA indicated in the most recently transmitted NPCA Operation Parameters field. ii) Store the existing values of the variables QSRC[AC], CW[AC] and the backoff counter for each EDCAF.Hi) Set QSRC[AC] for each AC to the value of the Initial NPCA QSRC field of the NPCA Operation Parameters received from its associated NPCA AP. iv) initialize variables CW[AC] to 2lnit-QSRc_NPCAx(CWmin[AC] + 1) - 1 . v) invoke the backoff procedure even if the medium for the NPCA primary channel is not busy. vi) initiate countdown of the MAC variable NPCA_TIMER in units of 1 usee.5) A first STA does not initiate a transmission on the NPCA primary channel to a second STA until theNPCA switching delay time of the second STA has elapsed since the NPCA HE switch time at the first STA if the first STA is switching due to condition 1 ) above or since the NPCA NHT switch time at the first STA if the first STA is switching due to condition 2) above.6) The STA begins all frame exchanges on the NPCA primary channel with an initial control frame (ICF) using non-HT PPDU or non-HT duplicate PPDU format using a rate of 6 Mb / s, 12 Mb / s, or 24 Mb / s. a) For TXOPs initiated by an AP, the ICF is a BSRP Trigger frame or an MU-RTS Trigger frame except when at least one of the target non-AP STA(s) is operating in the DUO mode, in which case, the ICF may be a BSRP Trigger frame or a BSRP NTB Trigger frame but not an MU-RTS. In addition, the ICF conforms to the rules for Dynamic Unavailability Operation (DUO) mode if at least one of the target non-AP STA(s) is operating in DUO mode, to the rules for Enhanced multi-link single-radio (EMLSR) operation if at least one of the target non-AP STA(s) is affiliated with a non-AP MLD that is operating in EMLSR mode, and to the rules for Dynamic power save (DPS) operation if at least one of the target non-AP STA(s) is operating in DPS mode. b) For TXOPs initiated by a non-AP STA, the initial control frame is a BSRP NTB Trigger frame, except that if the non-AP STA is operating in the Dynamic Unavailability Operation mode (DUO), then the ICF conforms to the DUO mode rules.7) An NPCA AP that transmits a Trigger frame on the NPCA primary channel indicates RU index values that use the NPCA primary channel as the reference primary channel.8) An NPCA STA that transmits a Trigger frame on the NPCA primary channel sets the NPCA Primary Indication field to 1 in the Special User Info field, otherwise, this field is set to 0.9) The 20 MHz channels occupied by PPDUs transmitted by the STA shall meet all of the following conditions: a) include at least the NPCA primary channel.Docket No.: 24-3059PCT b) all be within the BSS bandwidth. c) not include any of the channels occupied by either the PPDU mentioned in condition 1) or by the third PPDU mentioned in condition 2), whichever caused the STA to switch from the BSS primary channel to the NPCA primary channel. d) not include channels that are indicated as punctured in the Disabled Subchannel Bitmap field in the EHT Operation element or in the NPCA Disabled Subchannel Bitmap field in the UHR Operation element.10) UHR ELR PPDUs, HE ER SU PPDUs, EHT MCS14 / 15 shall not be transmitted on the NPCA primary channel.1 1) Dynamic Subband Operation shall not be used on the NPCA primary channel.12) If TBTT for the BSS occurs while an NPCA AP is operating on the NPCA primary channel, the scheduling of the transmission of the Beacon frame and following group addressed frames shall be deferred until immediately after the AP switches back to the BSS primary channel

[0445] In an example, an AP and associated STAs are not required to switch back to the BSS primary channel at TBTT. The group addressed frames may be buffered and delivered immediately following the next DTIM Beacon, unless explicitly specified otherwise. Further, in an example, exponential backoff may apply on the NPCA primary channel when there are failed transmissions.

[0446] In an implementation, an NPCA STA shall switch back to the BSS primary channel when the NPCA_TIMER expires. In an implementation, when the STA switches back to the BSS primary channel, it may:1) replace the current values of the variables QSRC[AC], CW[AC] and the backoff counter for each EDCAF with the values that it stored when it switched to the NPCA primary channel.2) resume the backoff procedure.

[0447] In an embodiment, a STA (e.g., an AP or non-AP STA) described in any of the embodiments above may further perform one or more of the Co-TDMA operations described herein below. As would be understood by a person of skill in the art based on the teachings, any of the Co-TDMA operations described below may be combined with the procedures / operations described above.

[0448] In an implementation, a coordinated time division multiple access (Co-TDMA) procedure enables an AP with dotH CoTDMAOption Implemented equal to true to allocate a portion of an obtained TXOP sequentially to one or more non-colocated APs with dot1 I CoTDMAOption Implemented equal to true. An AP that receives a time allocation from another AP as part of the Co-TDMA procedure exchanges one or more PPDUs during the allocated time.

[0449] An AP may not initiate a Co-TDMA procedure with another AP if any of the following conditions are true:

[0450] — No MAPC agreement on Co-TDMA exists between the APs.

[0451] — The primary 20 MHz channels of the two APs' BSS differ.Docket No.: 24-3059PCT

[0452] - Both APs are part of the same colocated AP set.

[0453] In an implementation, a Co-TDMA negotiation to establish, update, and tear down a Co-TDMA agreement may be performed by following the rules defined in MAPC agreement negotiation and Co-TDMA negotiations.

[0454] An AP that follows the rules defined in MAPC agreement negotiation to establish, update, or tear down a Co-TDMA agreement is referred to in Co-TDMA negotiations as a Co-TDMA requesting AP. It is a MAPC requesting AP and may additionally follow the rules defined in the Co-TDMA negotiations.

[0455] A Co-TDMA requesting AP may include a Co-TDMA profile in the MAPC element carried in a MAPC Negotiation Request frame. The Co-TDMA profile may include one MAPC Scheme Request field.

[0456] A Co-TDMA requesting AP may not set the MAPC Operation T ype field to 0 if a Co-TDMA agreement is already established between the Co-TDMA requesting AP and the Co-TDMA responding AP.

[0457] A Co-TDMA requesting AP may not set the MAPC Operation Type field to 1 or 2 if there is no established Co-TDMA agreement between the Co-TDMA requesting AP and the Co-TDMA responding AP.

[0458] An AP that responds to a Co-TDMA requesting AP during a MAPC agreement negotiation for a Co- TDMA agreement is referred to in this subclause as a Co-TDMA responding AP. It is a MAPC responding AP and may respond to a Co-TDMA requesting AP by following the rules defined in MAPC agreement negotiation. The Co-TDMA responding AP may not set the MAPC Operation Type field carried in the MAPC Scheme Request field of the Co-TDMA profile included in the MAPC Negotiation Response frame to 5.

[0459] An AP that has established a Co-TDMA agreement with a peer AP may operate as both a Co-TDMA coordinating AP and a Co-TDMA coordinated AP.

[0460] In an implementation, the Co-TDMA procedure may include a polling phase.

[0461] A Co-TDMA coordinating AP may announce its intention of allocating a portion of an obtained TXOP to another AP in an ICF sent at the beginning of the TXOP. The ICF polls one or more APs that have established MAPC agreements for Co-TDMA with the Co-TDMA coordinating AP, to solicit response(s) from polled AP(s) and determine their intent to receive a time allocation from the Co-TDMA coordinating AP within the TXOP.

[0462] A Co-TDMA coordinating AP may solicit a Co-TDMA ICR in a TB PPDU from another AP with which it has a MAPC agreement for Co-TDMA, only if the AP to be polled has indicated support for transmitting a Co-TDMA ICR in a TB PPDU by setting the AP TB PPDU Response Supported field in the MAPC element to 1.

[0463] The ICF that polls the AP(s) as part of the Co-TDMA procedure and solicits a Co-TDMA ICR from a polled AP in a TB PPDU is called a Co-TDMA TB ICF.

[0464] The Co-TDMA TB ICF may be a BSRP Trigger frame.

[0465] The ICF, as part of the Co-TDMA procedure, that solicits a Co-TDMA ICR from a polled AP in a non- HT PPDU or a non-HT duplicate PPDU is called a Co-TDMA NTB ICF.Docket No.: 24-3059PCT

[0466] The Co-TDMA NTB IGF may be a BSRP NTB Trigger frame, which has the Gl And HE / UHR-LTF Type field set to 3.

[0467] The Co-TDMA coordinating AP identifies a polled AP in the Co-TDMA TB ICF or the Co-TDMA NTB ICF by setting the AID12 field of a User Info field to the polled AP's AP ID, as assigned by the Co-TDMA coordinating AP.

[0468] The Duration field of the Co-TDMA TB ICF and the Co-TDMA NTB ICF may be set to one SIFS plus the time required to transmit the solicited Co-TDMA ICR(s) from the polled AP(s).

[0469] When a Co-TDMA coordinating AP transmits a Co-TDMA TB ICF, the AP may set the Feedback Type field of the Feedback User Info field of the Co-TDMA TB ICF to 3.

[0470] When a Co-TDMA coordinating AP transmits a Co-TDMA NTB ICF, the AP may set the Feedback Type field of a User Info field addressed to the polled AP to 3.

[0471] A polled AP may transmit a Co-TDMA ICR, in response to a received Co-TDMA TB ICF or the Co- TDMA NTB ICF that includes a User Info field with an AID12 field set to the AP ID of the polled AP as assigned by the Co-TDMA coordinating AP, subject to the rules defined for non-AP STAs in UL MU CS mechanism and UL MU CS mechanism for EHT STAs.

[0472] The Co-TDMA ICR may be a Multi-STA BlockAck frame with the following fields in the Per AID TID Info field:

[0473] - The Feedback Type field may be set to 3.

[0474] — The Al D11 field may be set to 0.

[0475] — The Ack Type field and TID field may be set to 0 and 13, respectively.

[0476] - The TXOP Sharing Solicited field of the Feedback field may be set to 1 if the polledAP intends to receive a time allocation from the Co-TDMA coordinating AP during the current TXOP; otherwise, it may be set to 0.

[0477] If a Co-TDMA coordinating AP does not receive a Co-TDMA ICR from a polled AP, the Co-TDMA coordinating AP may consider that the polled AP does not wish to receive a time allocation from the Co- TDMA coordinating AP during the current TXOP.

[0478] A polled AP may use the duration indicated by the Max TXOP Allocation Under Consideration field in a Co-TDMA ICF to determine the value to set for the TXOP Sharing Solicited field of a Multi-STA BlockAck frame.

[0479] NOTE— When performing a Co-TDMA agreement by following the rules defined in MAPC agreement negotiation and Co-TDMA negotiations, an AP that receives a MAPC Negotiation Request frame can determine the overlapping BSS bandwidth based on the bandwidth configuration information included in the Bandwidth Control field.

[0480] In an implementation, the Co-TDMA procedure may include a TXOP allocation phase.Docket No.: 24-3059PCT

[0481] To allocate a portion of an obtained TXOP, the Co-TDMA coordinating AP may transmit an MU-RTS TXS Trigger frame, with the TXS Mode field equal to 2, only to a polled AP that is not collocated with the Co- TDMA coordinating AP and from which the Co-TDMA coordinating AP has received a Co-TDMA ICR with the TXOP Sharing Solicited field equal to 1.

[0482] The time allocation to the Co-TDMA coordinated AP may start at the end of the PPDU that contains the MU-RTS TXS Trigger frame.

[0483] The Duration field of the MU-RTS TXS Trigger frame may be set to one SIFS plus the time required to transmit the solicited CTS response frame.

[0484] A Co-TDMA coordinating AP identifies the Co-TDMA coordinated AP to which a portion of the obtained TXOP is to be allocated by setting the AID12 field of the User Info field of the MU-RTS TXS Trigger frame to the Co-TDMA coordinated AP’s AP ID, as assigned by the Co-TDMA coordinating AP.

[0485] After a Co-TDMA coordinated AP receives an MU-RTS TXS Trigger frame from the Co-TDMA coordinating AP that contains a User Info field and the AID12 field of the User Info field contains the AP ID of the Co-TDMA coordinated AP, the Co-TDMA coordinated AP may exchange one or more PPDUs within the time allocation signaled in the MU-RTS TXS Trigger frame. The first PPDU of this exchange may carry a CTS frame, which is transmitted as per the rules defined in CTS frame sent in response to an MU-RTS Trigger frame with the exceptions stated in Coordinated time division multiple access (Co-TDMA).

[0486] The time allocated to a Co-TDMA coordinated AP identified in the MU-RTS TXS Trigger frame is specified in the Allocation Duration field in the MU-RTS TXS Trigger frame.

[0487] The Co-TDMA coordinating AP may follow Fairness considerations for TXOP sharing when determining the time allocated to Co-TDMA coordinated AP(s) within an obtained TXOP.

[0488] During the allocated time, any frame exchange between a Co-TDMA coordinated AP and its associated non-AP(s) may be from the same or higher priority ACs as the primary AC of the obtained TXOP indicated in the Primary AC field of the Co-TDMA TB ICF or the Co-TDMA NTB IGF transmitted by the Co- TDMA coordinating AP during the polling phase of Co-TDMA.

[0489] In an MU-RTS TXS Trigger frame that allocates a TXOP to a Co-TDMA coordinated AP, the Co- TDMA coordinating AP may not allocate an RU to the Co-TDMA coordinated AP outside the overlapping portion of the BSS bandwidth of the Co-TDMA coordinated AP and the bandwidth of the PPDU carrying the MU-RTS TXS Trigger frame.

[0490] The PPDU carrying the CTS frame from a Co-TDMA coordinated AP may be transmitted on the 20 MHz channel(s) indicated in the RU Allocation field of the User Info field of the MU-RTS TXS Trigger frame that allocated the time to the Co-TDMA coordinated AP.

[0491] During the time allocated by a Co-TDMA coordinating AP, a Co-TDMA coordinated AP that is addressed by the MU-RTS TXS Trigger frame may not transmit any PPDU that occupies subchannels other than those used when transmitting the CTS frame in response to the MU-RTS TXS Trigger frame.Docket No.: 24-3059PCT

[0492] In an implementation, the Co-TDMA procedure may include a TXOP return phase.

[0493] A Co-TDMA coordinated AP may return the remainder of the allocated time (if any) to the Co-TDMA coordinating AP if the Co-TDMA coordinating AP has indicated support for TXOP return by setting the Rx TXOP Return Support field to 1 in the MAPC element, otherwise the Co-TDMA coordinated AP may not return the TXOP. If the Co-TDMA coordinated AP is to return the TXOP back to the Co-TDMA coordinating AP, any NAV set by the Co-TDMA coordinated AP during the allocated time may end before this AP returns the TXOP to the Co-TDMA coordinating AP. Otherwise, any NAV set by the Co-TDMA coordinated AP during the allocated time may end before the end of the allocated duration.

[0494] A Co-TDMA coordinated AP may not transmit a CF-End frame in the allocated time to truncate the TXOP if the AP is to return the TXOP.

[0495] As part of Co-TDMA operation, when the Co-TDMA coordinated AP returns the TXOP to the Co- TDMA coordinating AP, the TXOP return may be indicated, within the allocated time, via a CAS Control field with the RDG / More PPDU field equal to 0. This CAS Control field is carried in an HE variant HT Control field in the MAC header of a MAPC TXOP Return frame that includes only the Action field in the frame body.

[0496] The Co-TDMA coordinating AP may respond with an Ack frame when it receives the TXOP return indication from a Co-TDMA coordinated AP.

[0497] No other MAPC Public Action frame may carry a CAS Control field in the HT Control field of the frame’s MAC header.

[0498] A Co-TDMA coordinating AP that has indicated support for TXOP return by setting the Rx TXOP Return Support field to 1 in the MAPC element and that is soliciting a TXOP return from a Co-TDMA coordinated AP may set the TXOP Return Solicited field of the Co-TDMA TB ICF or the Co-TDMA NTB ICF to 1 ; otherwise, the Co-TDMA coordinating AP may set the TXOP Return Solicited field to 0.

[0499] The Co-TDMA coordinated AP may return the TXOP after receiving a Co-TDMA TB ICF or a Co- TDMA NTB ICF that has set the TXOP Return Solicited field to 1 .

Claims

Docket No.: 24-3059PCTCLAIMSWhat is claimed is:1 . A method comprising: transmitting, by a first access point (AP) to a second AP, a multi-user request-to-send (MU-RTS) triggered transmission opportunity sharing (TXS) trigger frame indicating: sharing, by the first AP with the second AP, of a time portion of a transmission opportunity (TXOP) obtained by the first AP on a primary channel (PCH); and a duration of the time portion of the TXOP; disabling, by the first AP, a non-primary channel access (NPCA) mode of operation at a start time of the time portion of the TXOP; and enabling, by the first AP, the NPCA mode of operation at an end time of the time portion of the TXOP.

2. A method comprising: transmitting, by a first access point (AP) to a second AP, a first frame indicating: sharing, by the first AP with the second AP, of a time portion of a transmission opportunity (TXOP) obtained by the first AP on a primary channel (PCH); and a duration of the time portion of the TXOP; and disabling, by the first AP, a non-primary channel access (NPCA) mode of operation during the time portion of the TXOP.

3. The method of claim 2, wherein disabling the NPCA mode of operation during the time portion of the TXOP comprises disabling, by the first AP, the NPCA mode of operation at a start time of the time portion of the TXOP.

4. The method of any of claims 2-3, further comprising enabling, by the first AP, the NPCA mode of operation at an end time of the time portion of the TXOP.

5. The method of any of claims 2-4, further comprising: determining, by the first AP, that a first physical layer protocol data unit (PPDU) being received via the PCH comprises an inter-basic service set (inter-BSS) PPDU; and not switching, by the first AP, from the PCH to an NPCA PCH in response to the first PPDU.

6. The method of claim 5, wherein not switching from the PCH to the NPCA PCH in response to the first PPDU is based on the disabling of the NPCA mode of operation.

7. The method of any of claims 5-6, wherein not switching from the PCH to the NPCA PCH comprises not switching from the PCH to the NPCA PCH before an end of the TXOP.

8. The method of any of claims 2-7, further comprising: determining, by the first AP, that a second PPDU being received, after an end of the TXOP, via the PCH comprises an inter-BSS PPDU; and switching, by the first AP, from the PCH to the NPCA PCH in response to the second PPDU.Docket No.: 24-3059PCT9. The method of claim 8, wherein switching from the PCH to the NPCA PCH comprises switching from the PCH to the NPCA PCH after an end of the TXOP.

10. The method of any of claims 2-9, wherein the first frame comprises an allocation duration field that indicates the duration of the time portion of the TXOP.11 . The method of claim 10, wherein a user info field of the first frame comprise the allocation duration field.

12. The method of claim 11 , wherein the user info field of the first frame indicates an identifier of the second AP.

13. The method of any of claims 2-12, further comprising transmitting, by the first AP to a station (STA), a second frame indicating a first time period during which the STA is to disable the NPCA mode of operation.

14. The method of claim 13, wherein the first time period corresponds to the time portion of the TXOP.

15. The method of claim 13, wherein the first time period begins before the time portion of the TXOP.

16. The method of any of claims 14-15, wherein the first time period ends after the time portion of the TXOP.

17. The method of any of claims 13-16, wherein the first time period comprises an entirety of the TXOP.

18. The method of any of claims 3-17, wherein the second frame comprises a management frame, a control frame, or a data frame.

19. The method of any of claims 13-18, further comprising receiving, from the STA, a third frame in response to the second frame.

20. The method of any of claims 2-12, further comprising transmitting, by the first AP to a station (STA), a second frame instructing the STA to decode the first frame to determine the time portion of the TXOP.21 . The method of claim 20, wherein the second frame instructs the STA to decode an allocation duration field.

22. The method of any of claims 20-21 , wherein the second frame further instructs the STA to disable the NPCA mode of operation during the time portion of the TXOP.

23. The method of any of claims 20-22, wherein the second frame comprises a management frame, a control frame or a data frame.

24. The method of any of claims 20-23, wherein a common info field of the first frame instructs the STA to decode a user info field to determine the time portion of the TXOP.

25. The method of claim 24, wherein the common info field of the first frame instructs the STA to decode an allocation duration field.

26. The method of any of claims 20-25, wherein a common info field of the first frame indicates a second time period during which the STA is to disable the NPCA mode of operation.

27. The method of claim 26, wherein the second time period corresponds to the time portion of the TXOP.

28. The method of claim 26, wherein the second time period begins before the time portion of the TXOP.Docket No.: 24-3059PCT29. The method of any of claims 27-28, wherein the second time period ends after the time portion of the TXOP.

30. The method of any of claims 26-29, wherein the second time period comprises an entirety of the TXOP.31 . The method of any of claims 2-30, wherein the first frame indicates triggered TXOP sharing (TXS) to the second AP during the duration of the time portion of the TXOP.

32. The method of any of claims 2-31 , wherein the first frame comprises a multi-user request-to-send (MU- RTS) trigger frame.

33. The method of any of claims 2-32, wherein the first frame comprises a broadcast frame.

34. The method of any of claims 2-33, wherein the first frame comprises a unicast frame.

35. A method comprising: receiving, by a station (STA) from a first access point (AP), a multi-user request-to-send (MU-RTS) triggered transmission opportunity sharing (TXS) trigger frame indicating: sharing, by the first AP with a second AP, of a time portion of a transmission opportunity (TXOP) obtained by the first AP on a primary channel (PCH); and a duration of the time portion of the TXOP; disabling, by the STA, a non-primary channel access (NPCA) mode of operation at a start time of the time portion of the TXOP; and enabling, by the STA, the NPCA mode of operation at an end time of the time portion of the TXOP.

36. A method comprising: receiving, by a station (STA), a first frame indicating: sharing, by a first access point (AP) with a second AP, of a time portion of a transmission opportunity (TXOP) obtained by the first AP on a primary channel (PCH); and a duration of the time portion of the TXOP; and disabling, by the STA, a non-primary channel access (NPCA) mode of operation during the time portion of the TXOP.

37. The method of claim 36, further comprising decoding, by the STA, the first frame to determine the time portion of the TXOP.

38. The method of claim 37, wherein the decoding of the first frame comprises decoding an allocation duration field of the first frame to obtain the duration of the time portion of the TXOP.

39. The method of any of claims 36-38, wherein the first frame comprises a unicast frame.

40. The method of any of claims 37-38, further comprising receiving, by the STA from the first AP, a second frame instructing the STA to receive the first frame to determine the time portion of the TXOP.41 . The method of claim 40, wherein the first frame comprises an allocation duration field that indicates the duration of the time portion of the TXOP, and wherein the second frame instructs the STA to decode the allocation duration field.Docket No.: 24-3059PCT42. The method of claim 41 , wherein the decoding of the first frame is based on the receiving of the second frame.

43. The method of claim 41 , further comprising decoding the allocation duration field based on the receiving of the second frame.

44. The method of any of claims 40-43, wherein the second frame further instructs the STA to disable the NPCA mode of operation during the time portion of the TXOP.

45. The method of any of claims 40-44, wherein the second frame comprises a management frame, a control frame, or a data frame.

46. The method of any of claims 36-38, wherein the first frame comprises a broadcast frame.

47. The method of claim 46, wherein the first frame comprises an allocation duration field that indicates the duration of the time portion of the TXOP.

48. The method of claim 47, wherein a common info field of the first frame instructs the STA to decode the allocation duration field.

49. The method of claim 47, wherein a common info field ofthe first frame indicates a first time period during which the STA is to disable the NPCA mode of operation.

50. The method of claim 49, wherein the first time period comprises an entirety of the TXOP.51 . The method of any of claims 47-50, wherein a user info field of the first frame comprise the allocation duration field.

52. The method of claim 51 , wherein the user info field of the first frame indicates an identifier of the second AP.

53. The method of any of claims 36-52, wherein the first frame comprises a multi-user request-to-send (MU- RTS) trigger frame.

54. The method of claim 53, wherein the first frame indicates triggered TXOP sharing (TXS) to the second AP during the time portion of the TXOP.

55. The method of any of claims 36-54, further comprising: determining, by the STA, that a physical layer protocol data unit (PPDU) being received via the PCH comprises an inter-basic service set (inter-BSS) PPDU; and not switching, by the STA, from the PCH to a NPCA PCH in response to the PPDU.

56. The method of claim 55, wherein not switching from the PCH to the NPCA PCH in response to the PPDU is based on the disabling of the NPCA mode of operation.

57. The method of any of claims 36-56, wherein not switching from the PCH to the NPCA PCH comprises not switching from the PCH to the NPCA PCH before an end of the TXOP.

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

59. A device comprising: one or more processors; andDocket No.: 24-3059PCT 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-58.

60. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method according to any of claims 1-

Images