Dynamic subchannel access in restricted target wake time operations

Abstract

A first access point (AP) receives, from a second AP and via a primary channel, a beacon frame indicating a restricted target wake time (R-TWT) service period (SP) scheduled by the second AP on the primary channel. The first AP obtains a transmit opportunity (TXOP) on the primary channel, wherein a bandwidth of the TXOP comprises a secondary channel. Before a start of the R-TWT SP, the first AP ends communication using the TXOP via the primary channel. The first AP transmits a frame using the TXOP and via the secondary channel, wherein the frame overlaps with the R-TWT SP.

Description

Docket No.: 24-3034PCTTITLEDynamic Subchannel Access in Restricted Target Wake Time Operations CROSS-REFERENCE TO RELATED APPLICATIONS

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

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

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

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

[0005] FIG. 3 illustrates an example of target wake time (TWT) operation.

[0006] FIG. 4 illustrates an example of TWT operation in an environment including an AP multi-link device (AP MLD) and a station multi-link device (STA MLD).

[0007] FIG. 5 illustrates an example TWT element which may be used to support individual TWT operation.

[0008] FIG. 6 illustrates an example TWT element which may be used to support restricted TWT (R-TWT) operation.

[0009] FIG. 7 illustrates an example of individual TWT operation.

[0010] FIG. 8 illustrates an example of broadcast TWT operation.

[0011] FIG. 9 illustrates an example of TWT protection in individual TWT operation.

[0012] FIG. 10 illustrates an example of restricted TWT operation.

[0013] FIG. 11 illustrates an example of R-TWT coordination with multiple APs.

[0014] FIG. 12 illustrates an example of a Dynamic Subband Operation (DSO).

[0015] FIG. 13 illustrates an example of a DSO with coordinated R-TWT operations.

[0016] FIG. 14 illustrates an example that highlights a problem that may arise when APs use a DSO with coordinated R-TWT operation as illustrated in FIG. 13.

[0017] FIG. 15 illustrates an example of a DSO with coordinated R-TWT operations, as illustrated in FIG. 13, according to an embodiment.

[0018] FIG. 16 illustrates another example of a DSO with coordinated R-TWT operations, as illustrated in FIG. 13, according to an embodiment.

[0019] FIG. 17 illustrates an example of a DSO with coordinated R-TWT operations, as illustrated in FIG. 13, according to an embodiment.

[0020] FIG. 18 illustrates an example format of a continuation field, according to an embodiment.

[0021] FIG. 19 illustrates an example process according to an embodiment.Docket No.: 24-3034PCT

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

[0023] FIG. 21 illustrates an example multi-AP network.

[0024] FIG. 22 illustrates an example of a multi-AP negotiation procedure, followed by a multi-AP termination procedure.

[0025] FIG. 23 illustrates an example of Dynamic Subband Operation (DSO).

[0026] FIG. 24 illustrates another example of DSO.DETAILED DESCRIPTION

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

[0028] Embodiments may be configured to operate as needed. The disclosed mechanism may be performed when certain criteria are met, for example, in a station, an access point, a radio environment, a network, a combination of the above, and / or the like. Example criteria may be based, at least in part, on for example, wireless device or network node configurations, traffic load, initial system set up, packet sizes, traffic characteristics, a combination of the above, and / or the like. When the one or more criteria are met, various example embodiments may be applied. Therefore, it may be possible to implement example embodiments that selectively implement disclosed protocols.

[0029] In this disclosure, “a” and “an” and similar phrases are to be interpreted as “at least one” and “one or more.” Similarly, any term that ends with the suffix “(s)” is to be interpreted as “at least one” and “one or more.” In this disclosure, the term “may” is to be interpreted as “may, for example.” In other words, the term “may” is indicative that the phrase following the term “may” is an example of one of a multitude of suitable possibilities that may, or may not, be employed by one or more of the various embodiments. The terms “comprises” and “consists of’, as used herein, enumerate one or more components of the element being described. The term “comprises” is interchangeable with “includes" and does not exclude unenumerated components from being included in the element being described. By contrast, “consists of provides aDocket No.: 24-3034PCT complete enumeration of the one or more components of the element being described. The term “based on”, as used herein, may be interpreted as “based at least in part on” rather than, for example, “based solely on". The term “and / or” as used herein represents any possible combination of enumerated elements. For example, “A, B, and / or C” may represent A; B; C; A and B; A and C; B and C; or A, B, and C.

[0030] If A and B are sets and every element of A is an element of B, A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {STA1 , STA2) are: {STA1 }, {STA2}, and {STA1 , STA2}. The phrase “based on” (or equally “based at least on”) is indicative that the phrase following the term “based on” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “in response to” (or equally “in response at least to”) is indicative that the phrase following the phrase “in response to” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “depending on” (or equally “depending at least to”) is indicative that the phrase following the phrase “depending on” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments. The phrase “employing / using” (or equally “employing / using at least”) is indicative that the phrase following the phrase “employing / using” is an example of one of a multitude of suitable possibilities that may, or may not, be employed to one or more of the various embodiments.

[0031] The term configured may relate to the capacity of a device whether the device is in an operational or non-operational state. Configured may refer to specific settings in a device that effect the operational characteristics of the device whether the device is in an operational or non-operational state. In other words, the hardware, software, firmware, registers, memory values, and / or the like may be “configured” within a device, whether the device is in an operational or nonoperational state, to provide the device with specific characteristics. Terms such as “a control message to cause in a device" may mean that a control message has parameters that may be used to configure specific characteristics or may be used to implement certain actions in the device, whether the device is in an operational or non-operational state.

[0032] In this disclosure, parameters (or equally called, fields, or Information elements: IBs) may comprise one or more information objects, and an information object may comprise one or more other objects. For example, if parameter (IE) N comprises parameter (IE) M, and parameter (IE) M comprises parameter (IE) K, and parameter (IE) K comprises parameter (information element) J. Then, for example, N comprises K, and N comprises J. In an example embodiment, when one or more messages / frames comprise a plurality 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.

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

[0034] Many of the elements described in the disclosed embodiments may be implemented as modules. A module is defined here as an element that performs a defined function and has a defined interface to other elements. The modules described in this disclosure may be implemented in hardware, software in combination with hardware, firmware, wetware (e.g. hardware with a biological element) or a combination thereof, which may be behaviorally equivalent. For example, modules may be implemented as a software routine written in a computer language configured to be executed by a hardware machine (such as C, C++, Fortran, Java, Basic, Matlab or the like) or a modeling / simulation program such as Simulink, Stateflow, GNU Octave, or LabVIEWMathScript. It may be possible to implement modules using physical hardware that incorporates discrete or programmable analog, digital and / or quantum hardware. Examples of programmable hardware comprise: computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs); field programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers and microprocessors are programmed using languages such as assembly, C, C++ or the like. FPGAs, ASICs and CPLDs are often programmed using hardware description languages (HDL) such as VHSIC hardware description language (VHDL) or Verilog that configure connections between internal hardware modules with lesser functionality on a programmable device. The mentioned technologies are often used in combination to achieve the result of a functional module.

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

[0036] As shown in FIG. 1 , the example wireless communication networks may include an Institute of Electrical and Electronic Engineers (IEEE) 802.11 (WLAN) infra-structure network 102. WLAN infra-structure network 102 may include one or more basic service sets (BSSs) 1 10 and 120 and a distribution system (DS) 130.

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

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

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

[0040] The example wireless communication networks illustrated in FIG. 1 may further include one or more ad-hoc networks or independent BSSs (IBSSs). An ad-hoc network or IBSS is a network that includes a plurality of STAs that are within communication range of each other. The plurality of STAs are configured so that they may communicate with each other using direct peer-to-peer communication (i.e., not via an AP).

[0041] For example, in FIG. 1 , STAs 106-4, 106-5, and 106-6 may be configured to form a first IBSS 112- 1. Similarly, STAs 106-7 and 106-8 may be configured to form a second IBSS 112-2. Since an IBSS does not include an AP, it does not include a centralized management entity. Rather, STAs within an IBSS are managed in a distributed manner. STAs forming an IBSS may be fixed or mobile.

[0042] A STA as a predetermined functional medium may include a medium access control (MAC) layer that complies with an IEEE 802.11 standard. A physical layer interface for a radio medium may be used among the APs and the non-AP stations (STAs). The STA may also be referred to using various other terms, including mobile terminal, wireless device, wireless transmit / receive unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or user. For example, the term “user" may be used to denote a STA participating in uplink Multi-user Multiple Input, Multiple Output (MU MIMO) and / or uplink Orthogonal Frequency Division Multiple Access (OFDMA) transmission.

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

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

[0045] FIG. 2 is a block diagram 200 illustrating example implementations of a STA 210 and an AP 260. As shown in FIG. 2, STA 210 may include at least one processor 220, a memory 230, and at least one transceiver 240 AP 260 may include at least one processor 270, a memory 280, and at least one transceiver 290. Processor 220 / 270 may be operatively connected to memory 230 / 280 and / or to transceiver 240 / 290.

[0046] Processor 220 / 270 may implement functions of the PHY layer, the MAC layer, and / or the logical link control (LLC) layer of the corresponding device (STA 210 or AP 260). Processor 220 / 270 may include one or more processors and / or one or more controllers. The one or more processors and / or one or more controllers may comprise, for example, a general-purpose processor, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a logic circuit, or a chipset, for example.

[0047] Memory 230 / 280 may include a read-only memory (ROM), a random-access memory (RAM), a flash memory, a memory card, a storage medium, and / or other storage unit. Memory 230 / 280 may comprise one or more non-transitory computer readable mediums. Memory 230 / 280 may store computer program instructions or code that may be executed by processor 220 / 270 to carry out one or more of the operations / embodiments discussed in the present application. Memory 230 / 280 may be implemented (or positioned) within processor 220 / 270 or external to processor 220 / 270. Memory 230 / 280 may be operatively connected to processor 220 / 270 via various means known in the art.

[0048] Transceiver 240 / 290 may be configured to transmit / receive radio signals. In an embodiment, transceiver 240 / 290 may implement a PHY layer of the corresponding device (STA 210 or AP 260). In an embodiment, STA 210 and / or AP 260 may be a multi-link device (MLD), that is a device capable of operating over multiple links as defined by the IEEE 802.11 standard. As such, STA 210 and / or AP 260 may each implement multiple PHY layers. The multiple PHY layers may be implemented using one or more of transceivers 240 / 290.

[0049] Target wake time (TWT), a feature introduced in the IEEE 802.11 ah standard, allows STAs to manage activity in the BSS by scheduling STAs to operate at different times to reduce contention. TWTs may allow STAs to reduce the required amount of time that a STA utilizing a power management mode may be awake. TWTs may be individual TWTs or broadcast TWTs. Individual TWTs follow a negotiated TWT agreement between STAs. Broadcast TWTs are based on a schedule set and provided to STAs by an AP.

[0050] In an individual TWT, a STA that requests a TWT agreement is called a TWT requesting STA. The TWT requesting STA may be a non-AP STA for example The STA that responds to the request is called a TWT responding STA. The TWT responding STA may be an AP for example. The TWT requesting STA is assigned specific times to wake up and exchange frames with the TWT responding STA. The TWT requesting STA may communicate wake scheduling information to the TWT responding STA. The TWT responding STA may transmit TWT values to the TWT requesting STA when a TWT agreement is established between them.Docket No.: 24-3034PCT

[0051] When explicit TWT is employed, the TWT requesting STA may wake up and perform a frame exchange. The TWT requesting STA may receive a next TWT information in a response from the TWT responding STA. When implicit TWT is used, the TWT requesting STA may calculate a next TWT by adding a fixed value to the current TWT value.

[0052] The TWT values for implicit TWT may be periodic. The TWT requesting STA operating with an implicit TWT agreement may determine a next TWT service period (TWT SP) start time by adding a value of a TWT wake interval associated with the TWT agreement to the value of the start time of the current TWT SP. The TWT responding STA may include the start time for a series of TWT SPs corresponding to a single TWT flow identifier of an implicit TWT agreement in a target wake time field of a TWT element. The TWT element may contain a value of ‘accept TWT’ in a TWT setup command field. The start time of the TWT SP series may indicate the start time of a first TWT SP in the series. Start times of subsequent TWT SPs may be determined by adding the value of the TWT wake interval to the start time of the current TWT SP. In an example, the TWT requesting STA, awake for an implicit TWT SP, may enter a doze state after the TWT SP has elapsed or after receiving an end of service period (EOSP) field equal to 1 from the TWT responding STA, whichever occurs first.

[0053] A TWT session may be negotiated between an AP and a STA. The TWT session may configure a TWT SP of downlink (DL) and uplink (UL) traffic between the AP and the STA. Expected traffic may be limited within the negotiated SP. The TWT SP may start at a specific time. The TWT SP may run for a SP duration. The TWT SP may repeat every SP interval.

[0054] FIG. 3 illustrates an example 300 of TWT operation. As shown in FIG. 3, example 300 includes an AP 311 , a STA 312, and a STA 313. AP 31 1 and STA 312 may establish a TWT SP 320. AP 311 and STA 313 may establish a TWT SP 321 . TWT SP 320 and TWT SP 321 may repeat as shown in FIG. 3, such that TWT SP 320 may include a first TWT SP 320-1 and a second TWT SP 320-2, and such that TWT SP 321 may include a first TWT SP 321 -1 and a second TWT SP 321 -2.

[0055] AP 311 and STA 312 may exchange frames during first TWT SP 320-1. STA 312 may enter a doze state at the end of TWT SP 320-1 and may remain in the doze state until the start of second TWT SP 320-2. The start of second TWT SP 320-2 may be indicated by a TWT wake interval 330 associated with TWT SP 320. AP 311 and STA 312 may again exchange frames during second TWT SP 320-2.

[0056] Similarly, AP 311 and STA 313 may exchange frames during first TWT SP 321-1. STA 313 may enter a doze state at the end of first TWT SP 321 -1 and may remain in the doze state until the start of second TWT SP 321-2. The start of second TWT SP 321-2 may be indicated by a TWT wake interval 331 associated with TWT SP 321 . AP 31 1 and STA 313 may again exchange frames during second TWT SP 31-2.

[0057] In an awake state, a STA may be fully powered. The STA may transmit and / or receive a frame to / from an AP or another STA. In a doze state, a STA may not transmit and may not receive a frame to / from an AP or another STA.Docket No.: 24-3034PCT

[0058] An 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). The MLD may have a single MAC service access point (MAC-SAP) to the LLC layer, which includes a MAC data service An MLD may be an access point MLD (AP MLD) when 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) or STA MLD when a STA affiliated with the MLD is a non-AP STA (or a STA).

[0059] During negotiation of TWT agreements, a TWT requesting STA affiliated with a STA MLD and a TWT responding STA affiliated with an AP MLD may communicate multiple TWT elements. The TWT elements may comprise link ID bitmap subfields indicating different link(s) in a TWT setup frame. The TWT parameters provided by a TWT element may be applied to the respective link that is indicated in the TWT element.

[0060] FIG. 4 illustrates an example 400 of TWT operation in a multi-link environment including an AP multilink device (AP MLD) 410 and a STA multi-link device (STA MLD) 420. As shown in FIG. 4, AP MLD 410 may have three affiliated APs, AP 411 , AP2 412, and AP3 413. In an example, AP 411 , AP2 412, and AP3 413 may operate respectively on the 2.4 GHz band, the 5 GHz band, and the 6 GHz band. STA MLD 420 may have three affiliated STAs, STA 421 , STA 422, and STA 423. In an example, STA 421 , STA 422, and STA 423 may operate respectively on the 2.4 GHz band, the 5 GHz band, and the 6 GHz band. In an example, AP 411 , AP2 412, and AP3 413 may be communicatively coupled via a first link (link 1), a second link (link 2), and a third link (link 3) respectively with STA 421 , STA 422, and STA 423, respectively.

[0061] In an example, STA 421 may transmit a TWT request to AP 41 1. The TWT request may include three TWT elements. Each TWT element may indicate a respective link of links 1-3 and may request the setup of a TWT agreement for the indicated link. The three TWT elements may have different TWT parameters, such as target wake time (TWT). In response to the TWT request, AP 411 may transmit a TWT response to STA 421 . The TWT response may include three TWT elements. Each TWT element may indicate a respective link of links 1-3 and may include a value of ‘accept TWT’ in a TWT setup command field.

[0062] Successful TWT agreement setup on links 1-3 establishes three TWT SPs with same or different TWT parameters on links 1 -3 respectively. The target wake time field of the TWT element indicating a given link indicates the start time of the TWP SP for that link. The starting time may be indicated in reference to a time synchronization function (TSF) time of the link.

[0063] In example 400, initial TWT SPs 430-1 , 430-2, and 430-3 of links 1-3 respectively may be aligned 430 TWT wake intervals associated with the TWT agreements of links 1-3 respectively may be set differently. As such, second TWT SPs 431 -1 , 431-2, and 431 -3 of links 1-3 respectively may not be aligned. STA 421 , STA 422, and STA 423 may enter a doze state between the end of initial TWT SPs 430-1 , 430-2, and 430- 3, respectively, and the start of second TWT SPs 431-1 , 431 -2, 431-3, respectively.

[0064] FIG. 5 illustrates an example target wake time (TWT) element 500 which may be used to support individual TWT operation.Docket No.: 24-3034PCT

[0065] In an example, an AP and a STA may use TWT element 500 to negotiate a TWT agreement. The AP and / or the STA may transmit TWT element 500 in an individually addressed management frame. The management frame may be of the type action, action no ack, (re)association request / response, and probe request response, for example.

[0066] The TWT schedule and parameters may be provided during a TWT setup phase. Renegotiation / changes of TWT schedules may be signaled via individually addressed frames that contain the updated TWT schedule / parameters. The frames may be management frames as described above or control or data frames that carry a field containing the updated TWT schedule / parameters.

[0067] Referring to FIG. 5, TWT element 500 includes an element ID field, a length field, a control field, and a TWT parameter information field.

[0068] The element ID field (e.g., 1 octet in length) may indicate that information element 500 is a TWT element The length field (e.g., 1 octet) may indicate the length of TWT element 500 starting from the control field until an end of TWT element 500. The end of TWT element 500 may be the end of a TWT Channel field or the end of a Link ID bitmap field of the TWT parameter information field.

[0069] The TWT parameter information field may include a request type field (e.g., 2 octets), a target wake time field (e.g., 8 octets or less), a TWT group assignment field (e.g., 9, 3, 2, or 0 octets), a nominal minimal TWT wake duration field (e.g., 1 octet), a TWT wake interval mantissa (e.g., 2 octets), a TWT channel field (e.g., 1 octet), an optional NDP paging field (e.g., 0 or 4 octets), and / or a Link ID bitmaps field (e.g., 0 or 2 Octets ).

[0070] The request type field may indicate a type of TWT request. The request type field may include a TWT request field (e.g., 1 bit), a TWT setup command field (e.g., 3 bits), a trigger field (e.g., 1 bit), an implicit field (e.g., 1 bit), a flow type (e.g., 1 bit), a TWT flow identifier (e.g., 3 bits), a TWT wake interval exponent (e.g., 5 bits), and / or a TWT protection field (e.g., 1 bit).

[0071] The TWT request field may indicate whether the TWT element 500 represents a request. If TWT request field has a value of 1 , then the TWT element 500 may represent a request to initiate TWT scheduling / setup.

[0072] The TWT setup command field may indicate a type of TWT command. In a TWT request, the type of TWT command indicated may be: a request TWT (the TWT responding STA specifies the TWT value; e.g., field set to 0), a suggest TWT (the TWT requesting STA suggests a TWT value; e.g., field set to 1), and a demand TWT (the TWT requesting STA demands a TWT value; e g., field set to 2).

[0073] In a TWT response, the type of TWT command indicated may be: TWT grouping (the TWT responding STA suggests TWT group parameters that are different than the suggested or demanded TWT parameters of the TWT requesting STA; e.g., field set to 3), accept TWT (the TWT responding STA accepts the TWT request with the TWT parameters indicated by the TWT requesting STA; e.g. field set to 4), alternate TWT (the TWT responding STA suggests TWT parameters that are different than the parameters suggestedDocket No.: 24-3034PCT or demanded by the TWT requesting STA; e.g., field set to 5), dictate TWT (the TWT responding STA demands TWT parameters that are different than the parameters suggested or demanded by the TWT requesting STA; e.g., field set to 6), or reject TWT (the TWT responding STA rejects the TWT setup; e.g. field set to 7).

[0074] In a TWT response, the TWT command may also indicate an unsolicited response or a broadcast TWT. An unsolicited TWT response is an individually addressed frame that is intended for a specific STA. An unsolicited TWT response may be followed by an ACK frame from the STA receiving the unsolicited TWT response. A broadcast TWT may be intended for multiple STAs and may be carried in a broadcast frame such as, for example, a beacon frame. A broadcast TWT may not be acknowledged by receiving STAs.

[0075] An unsolicited TWT response may be used a TWT responding STA to demand that a recipient follow a TWT schedule contained in the TWT element. In an embodiment, an unsolicited TWT response may have the TWT request field set to 0 and a value of ‘dictate TWT' in the TWT setup command field. A broadcast TWT response may be used by a TWT responding STA to schedule a TWT for any STA that receives and decodes the TWT element.

[0076] In certain embodiments, a TWT element, such as TWT element 500, may contain TWT parameter sets for multiple TWT negotiations or indications as described herein. As such, the TWT element may include multiple instances of the Control and the TWT parameter information fields. The TWT flow identifier of the request type field indicates the TWT negotiation which parameters are carried by the TWT parameter information field.

[0077] FIG. 6 illustrates an example target wake time (TWT) element 600 which may be used to support restricted TWT (R-TWT) operation. For R-TWT, TWT element 600 may be transmitted in a broadcast management frame, which can be a beacon frame, a TIM broadcast frame, a probe response frame, etc. In this embodiment, TWT element 600 provides non-negotiated TWT schedules (e.g., broadcast TWT schedules).

[0078] As shown, TWT element 600 includes an element ID field, a length field, a control field, and a TWT parameter information field.

[0079] The element ID field (e.g., 1 octet in length) may indicate that information element 600 is a TWT element. The length field (e.g., 1 octet) may indicate the length of TWT element 600 starting from the control field until an end of TWT element 600. The end of TWT element 600 may be the end of a broadcast TWT info field or the end of a R-TWT traffic info field of the TWT parameter information field.

[0080] The TWT parameter information field may include a request type field, a target wake time field (e.g., 2 octets), a nominal minimal TWT wake duration field (e.g., 1 octet), a TWT wake interval mantissa (e.g., 2 octets), a broadcast TWT info field (e.g., 2 octets), and an optional R-TWT traffic info field (e.g., 0 or 3 octets).

[0081] The request type field may include, among other fields, a TWT request field, a flow type field, and a TWT wake interval exponent field.Docket No.: 24-3034PCT

[0082] The TWT request field indicates whether TWT element 600 is a request. If the TWT request field has a value of 0, then TWT element 600 may represent a response to a request to initiate TWT scheduling / setup (solicit TWT), an unsolicited TWT response, and / or a broadcast TWT message

[0083] The TWT wake interval represents the average time that a TWT requesting STA or a TWT scheduled STA expects to elapse between successive TWT SP start times of a TWT schedule. The TWT wake interval exponent field indicates a (base 2) exponent used to calculate the TWT wake interval in microseconds. In an embodiment, the TWT wake interval is equal to: (TWT wake interval mantissa)The TWT wake interval mantissa value is indicated in microseconds, base 2 in a TWT wake interval mantissa field of the TWT parameter information field.

[0084] The nominal minimum TWT wake duration field may indicate the minimum amount of time (in the unit indicated by a wake duration unit subfield of the control field) that a TWT requesting STA or a TWT scheduled STA is expected to be awake to complete frame exchanges for the period of the TWT wake interval.

[0085] The flow type field, in a TWT response that successfully set up a TWT agreement between a TWT requesting STA and a TWT responding STA, may indicate a type of interaction between the TWT requesting STA and the TWT responding STA within a TWT SP of the TWT agreement. A flow type field equal to 0 may indicate an announced TWT. In an announced TWT, the TWT responding STA may not transmit a frame to the TWT requesting STA within a TWT SP until the TWT responding STA receives a PS-Poll frame or a QoS Null frame from the TWT requesting STA. A flow type field equal to 1 may indicate an unannounced TWT. In an unannounced TWT, the TWT responding STA may transmit a frame to the TWT requesting STA within a TWT SP before it has received a frame from the TWT requesting STA.

[0086] Within a TWT element that includes a TWT setup command value of ‘request TWT', ‘suggest TWT’, or ‘demand TWT, a broadcast TWT ID may indicate a specific broadcast TWT in which the TWT requesting STA is requesting to participate. Within a TWT element that includes a TWT setup command value of 'accept TWT', 'alternate TWT’, 'dictate TWT', or ‘reject TWT, a broadcast TWT ID may indicate a specific broadcast TWT for which the TWT responding STA is providing TWT parameters. The value 0 in the broadcast TWT ID subfield may indicate the broadcast TWT whose membership corresponds to all STAs that are members of the BSS corresponding to the BSSID of the management frame carrying the TWT element and that is permitted to contain trigger frames with random access resource units for unassociated STAs. The Broadcast TWT ID subfield in a R-TWT Parameter set field is always set to a nonzero value.

[0087] A broadcast TWT element 600 that contains a R-TWT parameter set is also referred to as a R-TWT element. A R-TWT traffic info present subfield of the broadcast TWT info field may be set to 1 to indicate the presence of the R-TWT traffic info field in TWT element 600. The R-TWT traffic info field is present in a R- TWT parameter set field when the R-TWT traffic info present subfield is set to 1.Docket No.: 24-3034PCT

[0088] The R-TWT traffic info field may include a traffic info control field, a R-TWT DL TID bitmap field, and a R-TWT UL TID bitmap field.

[0089] The traffic info control field may include a DL TID bitmap valid subfield and an UL TID bitmap valid subfield. The DL TID bitmap valid subfield indicates if the R-TWT DL TID bitmap field has valid information. When the value of the DL TID bitmap valid subfield is set to 0, it may indicate that DL traffic of TIDs is identified as latency sensitive traffic, and the R-TWT DL TID bitmap field is reserved. The UL TID bitmap valid subfield may indicate if the R-TWT UL TID bitmap field has valid information. When the value of the UL TID bitmap valid subfield is set to 0, it may indicate that UL traffic of TIDs is identified as latency sensitive traffic, and the R-TWT UL TID bitmap field is reserved.

[0090] The R-TWT DL TID bitmap subfield and the R-TWT UL TID bitmap subfield may specify which TID(s) are identified by the TWT scheduling AR or the TWT scheduled STA as latency sensitive traffic streams in a downlink and an uplink direction, respectively. A value of 1 at bit position k in the bitmap indicates that TID k is classified as a latency sensitive traffic stream. A value of 0 at bit position k in the bitmap indicates that TID k is not classified as a latency sensitive traffic stream.

[0091] An individual target wake time (TWT) may be a specific time or set of times negotiated between two individual stations (e.g., a STA and another STA, or a STA and an AP, etc.) at which the stations may be awake to exchange frames during a service period (SP) of the TWT.

[0092] In trigger-enabled TWT, an AP may transmit a trigger frame for scheduling uplink multi-user transmissions from one or more ST As using uplink OFDMA (orthogonal frequency division multiple access) and / or uplink MU-MIMO (multi-user multiple input multiple output) during a trigger-enabled TWT SP. A TWT STA that receives the trigger frame from the AP may transmit a frame to the AP through a resource indicated in the trigger frame during the trigger-enabled TWT SP.

[0093] In non-trigger-enabled TWT, an AP may not be required to transmit a trigger frame to schedule uplink multi-user transmissions from one or more STAs during a non-trigger-enabled TWT SP.

[0094] In announced TWT, a STA may transmit a frame (e.g., a PS-Poll frame or a QoS null frame) to the AP to retrieve a downlink buffered data from the AP during a TWT SP. In unannounced TWT, an AP may transmit downlink data to a TWT STA without receiving a frame (e.g., a PS-Poll frame, or a QoS null frame) from the TWT STA during a TWT SP.

[0095] FIG. 7 illustrates an example 700 of individual TWT operation. As shown in FIG. 7, example 700 includes an AP 710, a STA 711 , and a STA 712. In an example, AP 710 may be a TWT responding STA and STA 711 and STA 712 may be TWT requesting STAs.

[0096] In an example, STA 711 may transmit a TWT request to AP 710 to setup a first trigger-enabled TWT agreement. STA 711 may set a trigger field of the TWT request to 1 to indicate that it is requesting a trigger- enabled TWT. AP 710 may accept the first TWT agreement with STA 711 . AP 710 may confirm theDocket No.: 24-3034PCT acceptance in a TWT response sent to STA 711. The TWT response may indicate a next TWT 730, which indicates the time until a next TWT SP 720 according to the first TWT agreement.

[0097] In an example, AP 710 may transmit an unsolicited TWT response to STA 712 to set up a second trigger-enabled TWT agreement with STA 712 without receiving a TWT request from STA 712. The first and second TWT agreements may be set up as announced TWTs.

[0098] After the setup of the TWT agreements, STA 711 and STA 712 may enter a doze state until the start of TWT SP 720. During trigger-enabled TWT SP 720, AP 710 may transmit a trigger frame. STA 71 1 and STA 12 may respond to the trigger frame by indicating that they are in awake state. In an example, STA 71 1 may transmit a power save poll (PS-Poll) frame. The PS-Poll frame may comprise a BSSID (receiver address: RA) field set to an address of AP 710 and a transmitter address (TA) field set to an address of STA 711 . In an example, STA 712 may transmit a QoS null frame in response to the trigger frame. The QoS null frame may comprise a MAC header (e.g., a frame control field, a duration field, address fields, a sequence control field, QoS control field) without a frame body.

[0099] In response to the PS-Poll frame and the QoS null frame, AP 710 may transmit a multi-STA Block Ack (M-BA) frame. The M-BA frame may include acknowledgement information associated with the PS-Poll frame and the QoS null frame received from STAs 711 and 712 respectively. Subsequently, STA 711 and STA 712 may receive downlink bufferable units (DL BUs) from AP 710. The DL BUs may include a medium access control (MAC) service data unit (MSDU), an aggregate MAC service data unit (A-MSDU), and / or a bufferable MAC management protocol data unit (MMPDU). STA 711 and STA 712 may transmit Block Ack (BA) frames in response to the DL BUs. At the end of the TWT SP 720, STA 71 1 and STA 712 may return to a doze state

[0100] A STA may execute individual TWT setup exchanges. The STA may not transmit frames to an AP outside of negotiated TWT SPs. The STA may not transmit frames that are not contained within high efficiency trigger-based physical protocol data units (HE TB PPDUs) to the AP within trigger-enabled TWT SPs. A HE TB PPDU may be transmitted by a STA based on receiving a trigger frame triggering uplink multiuser transmissions.

[0101] The AP of a trigger-enabled TWT agreement may schedule for transmission a trigger frame for a STA within the trigger-enabled TWT SP. The STA may transmit an HE TB PPDU as a response to the trigger frame sent during the trigger-enabled TWT SP. A STA that is in power save (PS) mode may include a PS- Poll frame or a QoS null frame in the HE TB PPDU if the TWT is an announced TWT, to indicate to the AP that the STA is currently in the awake state. The AP that receives the PS-Poll frame or the QoS Null frame or any other indication from an STA in PS mode, may deliver to the STA as many buffered BUs as are available at the AP during the TWT SP.Docket No.: 24-3034PCT

[0102] A broadcast target wake time (TWT) may be a specific time or set of times broadcast by an AP to one or more STAs at which the STAs may be awake to exchange frames with the AP during a SP of the TWT.

[0103] FIG. 8 illustrates an example 800 of broadcast TWT operation. As shown in FIG. 8, example 800 includes an AP 810, a STA 81 1 , and a STA 812. In an example 800, AP 810 may be a TWT scheduling AP and STA 811 and STA 812 may be TWT scheduled STAs.

[0104] In an example, AP 810 may include a broadcast TWT element in a beacon frame that indicates a broadcast TWT SP 820. During the broadcast TWT SP 820, AP 810 may transmit trigger frames or DL BUs to STA 811 and STA 812. Beacon frames may be sent by AP 810 periodically at target beacon transmission times (TBTTs). The number of time units (TUs) between consecutive TBTTs is called the beacon interval. A TU is equal to 1024 microseconds.

[0105] In an example, STA 811 and STA 812 may enter a doze state until the first target beacon transmission time (TBTT). STA 811 and STA 812 may wake up to receive the beacon frame at the first TBTT to determine the broadcast TWT. Upon reception of a broadcast TWT element in a beacon frame, STA 81 1 and STA 812 may re-enter the doze state until the start of trigger-enabled TWT SP 820.

[0106] During trigger-enabled TWT SP 820, AP 810 may transmit a basic trigger frame to STA 81 1 and STA 812. STA 811 may indicate that it is awake by transmitting a PS-Poll, and STA 812 may indicate that it is awake by transmitting a QoS null frame in response to the basic trigger frame. Subsequently, STA 81 1 and STA 812 may receive DL BUs from AP 810. STA 81 1 and STA 812 may return to the doze state outside of the TWT SP 720.

[0107] In an example, a STA that intends to operate in power save mode may negotiate a wake TBTT and a wake interval with the AP. For example, as shown in FIG. 8, STA 811 may transmit a TWT request to AP 810 that identifies a wake TBTT of the first beacon frame and a wake interval between subsequent beacon frames. AP 810 may respond with a TWT response to the TWT request confirming the wake TBTT and wake interval. After successfully completing the negotiation, STA 81 1 may enter a doze state until a first negotiated wake TBTT 830. STA 811 may be in an awake state to listen to the beacon frame transmitted at first negotiated wake TBTT 830. If STA 81 1 receives a beacon frame from AP 810 at or after TBTT 830, STA 81 1 may return to the doze state until the next wake TBTT unless a traffic indication map (TIM) element in a beacon frame includes a positive indication for STA 811 . The STA 81 1 may return to the doze state after a nominal minimum TBTT wake duration time has elapsed from the TBTT start time.

[0108] A Network Allocation Vector (NAV) is an indicator, maintained by a station (STA), of time periods when transmission onto the wireless medium (WM) may not be initiated by the STA regardless of whether the clear channel assessment (CCA) function of the STA senses that the WM is busy. A STA that receives at least one valid frame in a PSDU may update its NAV with the information from any valid duration field inDocket No.: 24-3034PCT the PSDU. The STA may update the NAV when a value of the received duration field is greater than the current NAV value of the STA.

[0109] A TWT protection is a mechanism employed to protect a TWT session from external STA transmissions. During a TWT SP configured to protect the TWT session, a STA that initiates a transmission opportunity (TXOP) to transmit a frame may transmit a request to transmit (RTS) frame or a clear to transmit (CTS) frame to protect the TWT session by setting the NAV of other STAs based on receiving of the RTS frame and / or the CTS frame. The RTS frame may comprise a frame control field, a duration field, a receiver address (RA) field, a transmitter address (TA) field, and a frame check sequence (FCS) field. The CTS frame may comprise a frame control field, a duration field, a receiver address (RA) field, and a frame check sequence (FCS) field.

[0110] The TWT protection field in a TWT element may indicate whether a TWT is protected or unprotected. A TWT requesting STA may set the TWT protection field to 1 to request the TWT responding STA to provide protection for the set of TWT SPs. A TWT protection field equal to 1 may indicate to use a NAV protection mechanism to protect access to the medium during the corresponding TWT SPs.

[0111] FIG. 9 illustrates an example 900 of TWT protection in individual TWT operation. As shown in FIG. 9, example 900 includes an AP 910 and a STA 911 .

[0112] In an example, AP 910 may set the TWT protection field to 1 in a TWT response frame to protect the TWT SPs using a NAV protection mechanism. Upon reception of the TWT response frame, STA 91 1 may enter a doze state until the next TWT 930. AP 910 that has set the TWT protection field to 1 may transmit a NAV setting frame at the start of the TWT SP 920. For example, the NAV setting frame may be an RTS frame or a CTS frame.

[0113] A STA that receives the NV setting frame and that is not scheduled to access the medium during the TWT SP 920 may set their NAV according to the NAV setting frame. The STA may not access the medium for the specified amount of time in the NAV setting frame.

[0114] STA 91 1 may be scheduled to access the medium during the TWT SP 920. STA 91 1 may respond to the RTS frame with a CTS frame. Upon receiving the CTS frame, AP 910 may transmit a downlink frame to STA 911. STA 91 1 may respond to the downlink frame with a BA frame. When the TWT SP 920 ends, STA 911 may return to the doze state.

[0115] FIG. 10 illustrates an example 1000 of restricted TWT operation. As shown in FIG. 10, example 1000 includes an AP 1010, a first STA 1011 , and a second STA 1012

[0116] In an example, a restricted TWT agreement may be setup between AP 1010 and STA 1011. The R- TWT agreement may not include STA 1012. For example, STA 1012 may be a legacy STA or an EHT STA not scheduled by AP 1010 as part of the R-TWT agreement.Docket No.: 24-3034PCT

[0117] In an example, AP 1010 may transmit a beacon frame including a TWT element that indicates an R- TWT SP 1020 and TIDs allowed to be transmitted during the R-TWT SP 1020. The beacon frame may also include a quiet element indicating a quiet interval 1021 .

[0118] Upon receiving the beacon frame, STA 1011 may enter a doze state and may remain in the doze state until the start of R-TWT SP 1020. STA 1012, which is not scheduled by AP 1010 for the R-TWT SP 1020, may transmit a data frame after receiving the beacon frame. However, STA 1012 must end its transmission before the start of R-TWT SP 1020.

[0119] During the R-TWT SP 1020, AP 1010 and STA 1011 may exchange an RTS frame and a CTS frame. Subsequently, AP 1010 may send a data frame to STA 101 1 . The data frame includes traffic having a TID from among the TIDs indicated as permitted to transmit during R-TWT SP 1020 (i.e., latency sensitive traffic) in the beacon frame. STA 1012 may not access the channel at least during quiet interval 1021 indicated in the beacon frame. When quiet interval 1021 or R-TWT SP 1020 ends, STA 1012 may resume its transmission. STA 1011 may enter doze state at the end of R-TWT SP 1020.

[0120] In existing WLAN systems, an AP may allocate a trigger-enabled TWT SP to a STA that supports TWT operation. The allocated STA may be allowed to transmit a frame during the trigger-enabled TWT SP after receiving a trigger frame from the AP. That is, the STA may not transmit a frame by using EDCA (Enhanced Distributed Channel Access) operation during the trigger-enabled TWT SP.

[0121] In an example, an AP may allocate a trigger-enabled R-TWT SP to a STA that supports R-TWT operation. In a trigger-enabled R-TWT SP, the R-TWT scheduling AP may first trigger member R-TWT scheduled STAs to allow them to deliver their QoS data frames first. The QoS data frames may correspond to TIDs that are associated with the trigger-enabled R-TWT SP. In a triggered-enabled R-TWT SP, a member R-TWT scheduled STA may transmit an UL frame to a R-TWT scheduling AP in response to a trigger frame received from the AP. In a triggered-enabled R-TWT SP, a transmission of the member R-TWT scheduled STA may not be allowed by using EDCA.

[0122] FIG. 11 illustrates an example 1100 of R-TWT coordination with multiple APs. The IEEE 802.1 1 standard may support R-TWT coordination between APs. R-TWT coordination between APs may be of different levels, described below.

[0123] In R-TWT (Level 1 ) coordination, shared APs may share scheduling information to minimize interference with OBSS schedules, e.g., by devising non-overlapping schedules in their own BSS where possible. In this level of coordination, minimization of interference for an AP may be achieved during an R- TWT SP that is scheduled by the AP, because other APs may avoid scheduling R-TWT SPs during the R- TWT SP of the AP. In this level of coordination, an AP announces R-TWT SPs of STAs that are associated to the AP and not R-TWT SPs of STAs that are associated with other APs.

[0124] In R-TWT (e.g., Level 2) coordination, an AP may be configured to end a TXOP of the AP at a start boundary of an R-TWT announced by another AP, e.g., providing an optional, comparatively enhanced levelDocket No.: 24-3034PCT of protection compared to R-TWT (Level 1). In an implementation, an AP may receive information about an R-TWT SP scheduled by another AP by receiving beacon frames from the other AP. In another implementation, an AP may receive information of an R-TWT SP scheduled by another AP by receiving a unicast transmission. Different operations that may be used by APs to receive information about R-TWT SPs are defined in the 802.11 bn amendment to support multi-AP coordination. For example, as illustrated in Example 1100, AP1 terminates a TXOP 1 105 based on the R-TWT SP coordination initiated by AP2 using a frame 1130.

[0125] In R-TWT (Level 3) coordination, shared APs may announce OBSS schedules as R-TWT schedules in their own BSS, e.g., providing an optional, comparatively higher level of protection. Similar to R-TWT coordination (e.g., Level 2), in R-TWT coordination (Level 3), an AP may receive information about a R-TWT SP scheduled by another AP by receiving beacon frames from the other AP. In another implementation, an AP may receive information about an R-TWT SP scheduled by another AP by receiving a unicast transmission defined in the 802.11 bn amendment. After an AP obtains information about the R-TWT SP scheduled by the other AP, the AP may announce to associated STAs, both R-TWT SPs of STAs associated with the AP and R-TWT SPs of the other AP. In an implementation, a STA associated with an AP that announces a R-TWT SP that supports the R-TWT feature is configured to end a TXOP before the start of the R-TWT in the same way the STA is configured to end a TXOP before the start of a regular R-TWT SP scheduled by AP associated with the STA.

[0126] FIG. 12 illustrates an example 1200 of a Dynamic Subband Operation (DSO). As shown in FIG. 12, example 1200 includes an AP 1210, a STA 1215, and a STA 1217. In an example, AP 1210 may operate over a plurality of channels, including a primary channel (PCH) 1222 and a secondary channel (SCH) 1220. In an example, AP 1210 supports a coordinated R-TWT operation (e.g., Level 2), as described with FIG. 11 above. In example 1200, AP 1210 supports a bandwidth up to 320 MHz, while STA 1215 and STA 1217 support a bandwidth up to160 MHz.

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

[0128] In example 1200, STA 1215 may support DSO and may be referred to as a “DSO STA.” As a DSO STA, STA 1215 may switch channel of operations from a primary channel to a secondary channel after receiving from an AP an initial control frame (IGF) that indicates the switch from the primary channel to the secondary channel. As a DSO STA, STA 1215 may respond to the ICF with an initial control ICR response (ICR) frame via the secondary channel to inform the AP of the switch to the secondary channel. In example 1200, STA 1217 may not support DSO and may be referred to as a “non-DSO STA.” As such, STA 1217 may not respond to an ICF from an AP indicating a switch from the primary channel to the secondary channel.

[0129] Example 1200 begins with AP 1210 transmitting an ICF 1270 over PCH 1222 and SCH 1220. ICF 1270 may indicate a switch from PCH 1222 to SCH 1220. On receiving ICF 1270, STA 1215 switches itsDocket No.: 24-3034PCT channel of operation from PCH 1222 to SCH 1220. STA 1215 may respond to ICF 1270 with an initial control response (ICR) frame 1271 via SCH 1220 to inform AP 1210 that STA 1215 successfully switched to SCH 1220.

[0130] After receiving ICF 1270, STA 1217 may transmit an ICR frame 1272 on PCH 1222, to inform AP 1210 that STA 1217 is able to receive a DL frame on PCH 1222, e.g., PCH 1222 is not busy from the perspective of STA 1217.

[0131] Continuing example 1200, after receiving ICR frames 1271 and 1272 from STA 1215 and STA 1217 respectively, AP 1210 may transmit a DL frame 1250 to both of STAs 1215 and 1217. As shown in FIG. 12, DL frame 1250 may comprise data 1260 for STA 1215 on SCH 1220 and data 1265 for STA 1217 on PCH 1222. In an implementation, AP 1210 may transmit DL frame 1250 by using an OFDMA PPDU (i.e., a PPDU format in which data 1260 and data 1265 are transmitted via distinct resource units within the PPDU), a frequency domain aggregated physical layer PPDU (A-PPDU) (i.e. a PPDU format in which data 1260 and data 1265 are transmitted using distinct PPDUs which may or may not have the same PPDU format on SCH 1220 and PCH 1222 respectively), or a Frequency Division Multiple Access (FDMA) PPDU (i.e. a PPDU format in which data 1260 and data 1265 are transmitted via distinct frequency subchannels).

[0132] In response to data 1260, STA 1215 may transmit a BA frame 1218 while still on SCH 1220 before returning to PCH 1222. In an alternative or additional example, AP 1210 may not solicit a BA frame from STA 1215. With no BA frame solicited, STA 1215 may return to PCH 1222 after receiving data 1260. In response to data 1265, STA 1217 may transmit a BA frame 1219 on PCH 1222. In an alternative or additional example, AP 1210 may not solicit a BA frame from STA 1217.

[0133] FIG. 13 illustrates an example 1300 of a DSO with coordinated R-TWT operations. As shown in FIG. 13, example 1300 includes an AP 1310 and an AP 1312. In an example, AP 1310 and AP 1312 may operate over a plurality of channels, including a PCH 1322 and an SCH 1320. Both AP 1310 and AP 1312 support coordinated R-TWT operation, with AP 1310 supporting R-TWT (e.g., Level 2) coordination, as described with FIG. 11 above.

[0134] At least AP 1310 has DSO capabilities, as described with respect to FIG. 12 above. In example 1300, AP 1310 is depicted as communication with a STA that has DSO capabilities (DSO STA), and a STA that does not have DSO capabilities (non-DSO STA). Specifically, example 1300 references a DSO STA 1315, which has characteristics similar to DSO STA 1215 described with FIG. 12 above. Example 1300 further references a non-DSO STA 1317, which has characteristics similar to non-DSO STA 1217 described with FIG. 12 above. For the sake of simplification of illustration, DSO STA 1315 and non-DSO STA 1317 are not shown in FIG. 13 but are referenced in frames received and transmitted by AP 1310.

[0135] Example 1300 commences with AP 1312 transmitting a frame 1330. In an example, frame 1330 may be a beacon frame including a TWT element that announces an R-TWT SP 1350 scheduled by AP 1312Docket No.: 24-3034PCT for the performance of frame exchanges 1395 by AP 1312 (e.g., with one or more STAs associated with AP 1312). AP 1310 may acknowledge / accept R-TWT SP 1350 (not shown).

[0136] Continuing example 1300, AP 1310 transmits an ICF 1370 on the combined 320 MHz bandwidth of PCH 1322 and SCH 1320. In an example, a DSC STA 1315 (e.g., similar to DSC STA 1215) and a non- DSO STA 1317 (e.g., similar to non-DSO STA 1217) receive ICF 1370 on PCH 1322. With receipt of ICF 1370, similar to the operation of DSC STA 1215, DSC STA 1315 receives an indication to switch to SCH 1320. Based on the indication, DSC STA 1315 may switch from PCH 1322 to SCH 1320.

[0137] To indicate the switch to SCH 1320 to AP 1310, DSC STA 1315 may transmit an ICR frame 1371 on SCH 1320. With receipt of ICF 1370, non-DSO STA 1317 may transmit an ICR frame 1372 on PCH 1322 to AP 1310 indicating that PCH 1322 is not busy from the perspective of non-DSO STA 1317.

[0138] After receiving ICR frames 1371 and 1372 from DSO STA 1315 and non-DSO STA 1317, respectively, AP 1310 may simultaneously transmit a data frame 1360 on PCH 1322 to DSO STA 1315 and a data frame 1365 on SCH 1320 to non-DSO STA 1317. Data frames 1360 and 1365 may be transmitted in an OFDMA PPDU, an A-PPDU, or an FDMA PPDU.

[0139] In an example, because AP 1310 supports coordinated R-TWT operation (e.g., Level 2), AP 1310 may be configured to terminate its transmission of data on PCH 1322 and SCH 1320 during R-TWT SP 1350. Accordingly, before the start of R-TWT SP 1350, AP 1310 terminates the transmission of data frame 1360 to DSO STA 1315 using SCH 1320 and the transmission of data frame 1365 to non-DSO STA 1317 using PCH 1322. The termination by AP 1310 of the transmission of data frame 1360 on SCH 1320 and data frame 1365 on PCH 1322 respectively facilitates frame exchanges 1395 by AP 1312 during R-TWT SP 1350 on SCH 1320 as well as on PCH 1322.

[0140] FIG. 14 illustrates an example 1400 that highlights a problem that may arise when APs use a DSO with coordinated R-TWT operation as illustrated in FIG. 13. As shown in FIG. 14, example 1400 includes an AP 1410 and an AP 1412. In an example, APs 1410 and 1412 operate on a plurality of channels, including a PCH 1422 and a SCH 1420. In an example, AP 1410 is a DSO STA. In an example, each of PCH 1422 and SCH 1420 may have a bandwidth of 160 MHz. AP 1412 supports the 160 MHz bandwidth of PCH 1422, and AP 1410 supports the combined 320 MHz bandwidth of PCH 1422 and SCH 1420. AP 1410 and AP 1412 support coordinated R-TWT operation, with AP 1410 supporting R-TWT coordination (e.g., Level 2) as described with respect to FIG. 11 above.

[0141] At least AP 1410 has DSO capabilities, as described with respect to FIG. 12 above. In example 1400, AP 1410 is depicted as transmitting and receiving communications from a STA that has DSO capabilities (DSO STA), and a STA that does not have DSO capabilities (non-DSO STA). Example 1400 references DSO STA 1415, which has characteristics similar to DSO STA 1215 described with FIG. 12 above. Example 1400 further references non-DSO STA 1417, which has characteristics similar to non-DSO STA 1217 described with FIG. 12 above. For the sake of simplification of illustration, DSO STA 1415 and non-DSODocket No.: 24-3034PCTSTA 1417 are not shown in FIG. 14 but are referenced in frames received and transmitted by AP 1410. DSO STA 1415 and non-DSO STA 1417 support 160 MHz bandwidth.

[0142] Example 1400 commences with AP 1412 transmitting a frame 1430. In an example, frame 1430 may be a beacon frame including a TWT element that announces an R-TWT SP 1450 scheduled by AP 1412 for the performance of frame exchanges 1495 by AP 1412 (e.g., with one or more STAs associated with AP 1412). AP 1410 may acknowledge / accept R-TWT SP 1450 (not shown).

[0143] Continuing example 1400, AP 1410 transmits ICF 1470 on the combined 320 MHz bandwidth of PCH 1422 and SCH 1420. In an example, a DSO STA 1415 (e.g., similar to DSO STA 1215) and a non- DSO STA 1417 (e.g., similar to non-DSO STA 1217) receive ICF 1470 on PCH 1422. With receipt of ICF 1470, similar to the operation of DSO STA 1215, DSO STA 1415 receives an indication to switch to SCH 1420. Based on the indication, DSO STA 1415 may switch from PCH 1422 to SCH 1420.

[0144] To indicate the switch to SCH 1420 to AP 1410, DSO STA 1415 may transmit an ICR frame 1471 on SCH 1420. With receipt of ICF 1470, non-DSO STA 1417 may transmit an ICR frame 1472 on PCH 1422 to AP 1410 indicating that PCH 1422 is not busy from the perspective of non-DSO STA 1417.

[0145] After receiving ICR frames 1471 and 1472 from the DSO STA and the non-DSO STA, respectively, AP 1410 may simultaneously transmit a data frame 1460A to DSO STA 1415 on PCH 1422 and a data frame 1465 to non-DSO STA 1417 on SCH 1420.

[0146] In an example, because AP 1410 supports coordinated R-TWT operation (e.g., Level 2), AP 1410 may be configured to terminate its transmission of data frame 1460A before the start of R-TWT SP 1450. Accordingly, before the start of R-TWT SP 1450, AP 1410 terminates the transmission of data frame 1460A to DSO STA 1415 using SCH 1420. In an example, AP 1412 may gain control of PCH 1422 right at the start of R-TWT SP 1450 and initiate frame exchanges 1495. In example 1400, because AP 1410 is configured to obtain a TXOP using PCH 1422 for successive transmissions, AP 1410 may not be able to resume transmission of data frame 1460B to DSO STA 1415 until the end of R-TWT SP 1450.

[0147] After the completion of R-TWT SP 1450, AP 1410 obtains a TXOP via PCH 1422 and proceeds to commence transmission of a data frame 1460B by performing a backoff 1466. After completion of backoff 1466, AP 1410 acquires control of PCH 1422, and proceeds to commence transmission of data frame 1460B on PCH 1422.

[0148] In contrast to example 1300, in which AP 1312 performed frame exchanges 1395 during R-TWT SP 1350, on both PCH 1322 and SCH 1320, in example 1400, AP 1412 performs frame exchanges 1495 on PCH 1422 only. Notwithstanding this lack of utilization of SCH 1420 by AP 1412, in accordance with the configuration of AP 1410, based on R-TWT (e.g., Level 2) coordination, AP 1410 terminates the transmission of data frame 1460A on SCH 1420 before the start of R-TWT SP 1450. Due to this termination, SCH 1420 is wasted during the period of R-TWT SP 1450 labeled “unused 1480” in FIG. 14.Docket No.: 24-3034PCT

[0149] Embodiments of the present disclosure, as further described below, address the above-described problem of existing technologies. In an aspect, a first STA may receive from a second STA and via a first channel, a first frame indicating an R-TWT SP scheduled by the second STA on the first channel The first frame may be a beacon frame indicating the R-TWT SP. The first STA may obtain a transmit opportunity (TXOP) on the first channel, with a bandwidth of the TXOP including a second channel. Before a start of the R-TWT SP, the first STA may transmit a second frame using the TXOP and via the second channel, with the second frame overlapping the R-TWT SP. In an aspect, the first STA may be an MPC DSO AP. In an aspect, the first channel may be a primary channel of the first and second STAs and the second channel may be a secondary channel of the first STA.

[0150] FIG. 15 illustrates an example 1500 of a DSO with coordinated R-TWT operations, as illustrated in FIG. 13, according to an embodiment. As shown in FIG. 15, example 1500 includes an AP 1510 and an AP 1512. In an example, APs 1510 and 1512 operate on a plurality of channels, including a PCH 1522 and a SCH 1520. In an example, each of PCH 1522 and SCH 1520 may have a bandwidth of 160 MHz.

[0151] In an example, AP 1512 may support the 160 MHz bandwidth of PCH 1522, and AP 1510 may support the combined 320 MHz bandwidth of PCH 1522 and SCH 1520.

[0152] AP 1510 and AP 1512 support a R-TWT coordination (e.g., multi-AP coordinated R-TWT (Co- RTWT)), with at least AP 1510 supporting R-TWT coordination (e.g., Level 2) as described with respect to FIG. 11 above. In an example, AP 1512 may also support R-TWT Level 2 coordination, as described with FIG. 11 above.

[0153] At least AP 1510 has DSO capabilities, as described with respect to FIG. 12 above. In an example, AP 1512 may also have DSO capabilities. In example 1500, AP 1510 is depicted as transmitting and receiving communications from a STA that has DSO capabilities (DSO STA), and a STA that does not have DSO capabilities (non-DSO STA). In an example, a non-DSO STA may also reference a STA that has DSO capabilities, but is not using the DSO capabilities in the example. Example 1500 references DSO STA 1515, which has characteristics similar to DSO STA 1215 described with FIG. 12 above. Example 1500 further references non-DSO STA 1517, which has characteristics similar to non-DSO STA 1217 described with FIG. 12 above. For the sake of simplification of illustration, DSO STA 1515 and non-DSO STA 1517 are not shown in FIG. 15 but are referenced in frames received and transmitted by AP 1510.

[0154] In an embodiment, whether AP 1512 operates or does not operate on SCH 1520 may be known to AP 1510 based on passively listening to beacon frames transmitted by AP 1512, or by unicast transmissions from AP 1512 to AP 1510 (e.g., using a communication procedure to support multi-AP coordination).

[0155] Example 1500 commences with AP 1512 transmitting a frame 1530. In an example, frame 1530 may be a beacon frame including a TWT element that announces an R-TWT SP 1550 scheduled by AP 1512 for the performance of frame exchanges 1595 by AP 1512 (e.g., with one or more STAs associated with AP 1512). AP 1510 may acknowledge / accept R-TWT SP 1550 (not shown).Docket No.: 24-3034PCT

[0156] In an embodiment, AP 1512 may be referred to as a Co-RTWT requesting AP. For example, as discussed above, AP 1512 may announce R-TWT SP 1550 (e.g. , in frame 1530), scheduled by AP 1512. In an embodiment, AP 1510 may be referred to as a Co-RTWT responding AP or a Co-RTWT coordinated AP. For example, as discussed above, AP 1510 may acknowledge / accept R-TWT SP 1550 (e.g., scheduled by AP 1512).

[0157] In an embodiment, frame 1530 includes a field 1535 that specifies conditions that may be used to determine a continuation of a TXOP beyond a start time of a R-TWT SP (on a channel other than PCH 1522, e.g., SCH 1520) that overlaps R-TWT SP 1550. In an embodiment, field 1535 may be used by a STA, such as AP 1510, to determine whether a TXOP initiated by the STA on a channel other than the primary channel of AP 1512 may be continued without termination / interruption beyond a start time of R-TWT SP 1550. In an implementation, field 1535 includes a BW value 1536 that specifies a bandwidth range of PCH 1522 on which R-TWT SP 1550 is scheduled for transmission of frame exchanges 1595.

[0158] Continuing example 1500, AP 1510 transmits an ICF 1570 on the combined 320 MHz bandwidth of PCH 1522 and SCH 1520. In an embodiment, ICF 1570 may indicate to one or more DSC STAs to move / switch to SCH 1520. For example, a DSC STA 1515 and a non-DSO STA 1517 receive ICF 1570 on PCH 1522. With receipt of ICF 1570, similar to the operation of DSO STA 1215, DSC STA 1515 receives an indication to switch to SCH 1520. Based on the indication of ICF 1570, DSO STA 1515 may switch from PCH 1522 to SCH 1520. To indicate the switch by DSO STA 1515 to SCH 1520 to AP 1510, DSO STA 1515 may transmit an ICR frame 1571 on SCH 1520. With receipt of ICF 1570, non-DSO STA 1517 may transmit an ICR frame 1572 on PCH 1522 to AP 1510 indicating that PCH 1522 is not busy from the perspective of non-DSO STA 1517.

[0159] After receiving ICR frame 1571 from DSO STA 1515 on SCH 1520, and ICR frame 1572 from non- DSO STA 1517 on PCH 1522, AP 1510 may acquire a TXOP 1555 for transmission of a data frame 1560 and a data frame 1565 to DSO STA 1515 and non-DSO STA 1517, respectively. In an example, TXOP 1555 may be initiated with a bandwidth of 320 MHz that includes PCH 1522 and SCH 1520.

[0160] After acquiring TXOP 1555, AP 1510 may simultaneously transmit a data frame 1560 to DSO STA 1515 and a data frame 1565 to non-DSO STA 1517, respectively. AP 1510 transmits data frame 1565 to non-DSO STA 1517 on PCH 1522, and data frame 1560 to DSO STA 1515 on SCH 1520. In an example, data frame 1560 and data frame 1565 are included in a PPDU transmitted during TXOP 1555. In an example, one or both of DSO STA 1515 and non-DSO STA 1517, may respond to the data frames by transmitting a BA frame to AP 1510 (not shown).

[0161] In an embodiment, after an AP initiates a TXOP with a bandwidth that overlaps a bandwidth of an R- TWT SP of another AP, the AP may be configured to end transmission using the TXOP for the overlapping bandwidth portion before the start of the R-TWT SP. In example 1500, the bandwidth of TXOP 1555 comprises both PCH 1522 and SCH 1520 and overlaps the bandwidth of R-TWT SP 1550 over PCH 1522.Docket No.: 24-3034PCTThus, in an embodiment illustrated by example 1500, before the start of R-TWT SP 1550, AP 1510 stops transmission of data frame 1565 to non-DSO STA 1517 on PCH 1522. In contrast, as the bandwidth of R- TWT SP 1550 does not comprise SCH 1520 (and may not overlap over SCH 1520 with the bandwidth of TXOP 1555), AP 1510 maintains transmission of data frame 1560 to DSO STA 1515 on SCH 1520 during the full duration of TXOP 1555.

[0162] In example 1500, SCH 1520 is outside of BW value 1536 that specifies the bandwidth range of PCH 1522. In an embodiment, because SCH 1520 is outside of BW value 1536 of field 1535, AP 1510 may continue TXOP 1555 on SCH 1520 after the start of R-TWT SP 1550. As such, AP 1510 may not terminate its transmission of data frame 1560 before the start of R-TWT SP 1550. In another example, different conditions may also be an indication to AP 1510 to continue TXOP 1555 on SCH 1520 after the start of R- TWT SP 1550.

[0163] In contrast to example 1400, where AP 1410 is configured to terminate use of SCH 1420 during R- TWT SP 1450, in example 1500, AP 1510 continues to use SCH 1520 to continue transmission of data frame 1560 after the beginning of R-TWT SP 1550. Thus, at least based on the foregoing, embodiments depicted with FIG. 15 may avoid the problem described above with FIG. 14.

[0164] FIG. 16 illustrates an example 1600 of a DSO with coordinated R-TWT operations, as illustrated in FIG. 13, according to an embodiment. As shown in FIG. 16, example 1600 includes an AP 1610 and an AP 1612. In an example, APs 1610 and 1612 operate on a plurality of channels, including a PCH 1622 and a SCH 1620. In an example, each of PCH 1622 and SCH 1620 may have a bandwidth of 160 MHz.

[0165] In an example, AP 1612 may support the 160 MHz bandwidth of PCH 1622, and AP 1610 may support the combined 320 MHz bandwidth of PCH 1622 and SCH 1620.

[0166] AP 1610 and AP 1612 support a R-TWT coordination, with at least AP 1610 supporting R-TWT coordination (e.g., Level 2) as described with respect to FIG. 11 above. In an example, AP 1612 may also support R-TWT Level 2 coordination, as described with FIG. 11 above.

[0167] At least AP 1610 has DSO capabilities, as described with respect to FIG. 12 above. In an example, AP 1612 may also have DSO capabilities. In example 1600, AP 1610 is depicted as transmitting and receiving communications from STAs that have DSO capabilities (DSO STA), and a STA that does not have DSO capabilities (non-DSO STA). In an example, a non-DSO STA may also reference a STA that has DSO capabilities, but is not using the DSO capabilities in the example. Example 1600 references DSO STA 1615 and DSO STA 1619, which have characteristics similar to DSO STA 1215 described with FIG. 12 above. Example 1600 further references non-DSO STA 1617, which has characteristics similar to non-DSO STA 1217 described with FIG. 12 above. For the sake of simplification of illustration, DSO STA 1615, DSO STA 1619, and non-DSO STA 1617 are not shown in FIG. 16 but are referenced in frames received and transmitted by AP 1610.Docket No.: 24-3034PCT

[0168] In an embodiment, whether AP 1612 operates or does not operate on SCH 1620 may be known to AP 1610 based on passively listening to beacon frames transmitted by AP 1612, or by unicast transmissions from AP 1612 to AP 1610 (e.g., using a communication procedure to support multi-AP coordination).

[0169] Example 1600 commences with AP 1612 transmitting a frame 1630. In an example, frame 1630 may be a beacon frame including a TWT element that announces an R-TWT SP 1650 scheduled by AP 1612 for the performance of frame exchanges 1695 by AP 1612 (e.g., with one or more STAs associated with AP 1612). AP 1610 may acknowledge / accept R-TWT SP 1650 (not shown).

[0170] In an embodiment, AP 1612 may be referred to as a Co-RTWT requesting AP. For example, as discussed above, AP 1612 may announce R-TWT SP 1650 (e.g., in frame 1630), scheduled by AP 1612. In an embodiment, AP 1610 may be referred to as a Co-RTWT responding AP or a Co-RTWT coordinated AP. For example, as discussed above, AP 1610 may acknowledge / accept R-TWT SP 1650 (e.g., scheduled by AP 1612).

[0171] In an embodiment, frame 1630 includes a field 1635 that specifies conditions that may be used to determine a continuation of a TXOP beyond a start time of a R-TWT SP (on a channel other than PCH 1622, e.g., SCH 1620) that overlaps R-TWT SP 1650. In an embodiment, field 1635 may be used by a STA, such as AP 1610, to determine whether a TXOP initiated by the STA on a channel other than the primary channel of AP 1612 may be continued without termination / interruption beyond a start time of R-TWT SP 1650. In an implementation, field 1635 includes a PCH only indication 1636 that specifies whether R-TWT SP 1650 applies only to PCH 1622.

[0172] Continuing example 1600, AP 1610 transmits an ICF 1670 on the combined 320 MHz bandwidth of PCH 1622 and SCH 1620. In an embodiment, ICF 1670 may indicate to one or more DSO STAs to move / switch to SCH 1620. For example, a DSO STA 1615, a DSO STA 1619, and a non-DSO STA 1617 receive ICF 1670 on PCH 1622. With receipt of ICF 1670, similar to the operation of DSO STA 1215, DSO STA 1615 and DSO STA 1619 receive an indication to switch to SCH 1620. In an example, DSO STA 1615 is directed to immediately switch to SCH 1620, and DSO STA 1619 is directed to switch at the beginning of R-TWT SP 1650, e.g., a delayed DSO indication. In another embodiment, DSO STA 1615 may be directed by ICF 1670 to remain on SCH 1620 for continuation of a DSO frame exchange with AP 1610.

[0173] Based on the indication of ICF 1670, DSO STA 1615 may switch from PCH 1622 to SCH 1620. To indicate the switch by DSO STA 1615 to SCH 1620 to AP 1610, DSO STA 1615 may transmit an ICR frame 1671 on SCH 1620. With receipt of ICF 1670, non-DSO STA 1617 may transmit an ICR frame 1672 on PCH 1622 to AP 1610 indicating that PCH 1622 is not busy from the perspective of non-DSO STA 1617.

[0174] After receiving ICR frame 1671 from DSO STA 1615 on SCH 1620, and ICR frame 1672 from DSO STA 1617 on PCH 1622, AP 1610 may acquire a TXOP for transmission (not shown) of a data frame 1660 and a data frame 1665 to DSO STA 1615 and non-DSO STA 1617, respectively. In an example, the TXOP may be initiated with a bandwidth of 320 MHz that includes PCH 1622 and SCH 1620.Docket No.: 24-3034PCT

[0175] After acquiring the TXOP, AP 1610 may simultaneously transmit data frame 1660 to DSO STA 1615 and data frame 1665 to non-DSO STA 1617, respectively. AP 1610 transmits data frame 1665 to non-DSO STA 1617 on PCH 1622, and data frame 1660 to DSO STA 1615 on SCH 1620. In an example, data frame 1660 and data frame 1665 are included in a PPDU transmitted during a TXOP. In an example, one or both of DSO STA 1615 and non-DSO STA 1617, may respond to the data frames by transmitting a BA frame to AP 1610 (not shown).

[0176] Continuing example 1600, in accordance with the indication to DSO STA 1619 in ICF 1670, at the starting time of R-TWT SP 1650, DSO STA 1619 may switch from PCH 1622 to SCH 1620. To indicate the switch by DSO STA 1619 to SCH 1620 to AP 1610, DSO STA 1619 may transmit an ICR frame 1674 on SCH 1620. Using the TXOP obtained for the transmission of data frame 1660, after receiving ICR frame 1674, AP 1610 may transmit a data frame 1667 to DSO STA 1619. In an example, data frame 1667 is included in the PPDU used to transmit data frame 1660 and data frame 1665, during the TXOP obtained by AP 1610. In another example (not shown in FIG. 16), in accordance with the direction to DSO STA 1615 in ICF 1670 to remain on SCH 1620, DSO STA 1615 may remain on SCH 1620 after receiving data frame 1660. To indicate to AP 1610 that DSO STA 1615 is on SCH 1620 to, DSO STA 1615 may transmit an ICR frame 1674 on SCH 1620. Using the TXOP obtained for the transmission of data frame 1660, after receiving ICR frame 1674, AP 1610 may transmit a data frame 1667 to DSO STA 1615. In an example, data frame 1667 is included in the PPDU used to transmit data frame 1660 and data frame 1665, during the TXOP obtained by AP 1610.

[0177] In example 1600, data frame 1667 is transmitted to DSO STA 1619 using PCH 1622, and, because of the delayed DSO starting at the beginning of R-TWT SP, the transmission of data frame 1667 overlaps PCH 1622 during R-TWT SP 1650.

[0178] In an additional or alternative example, DSO STA 1619 does not send ICR frame 1674 at the start of R-TWT SP 1650. In this example, when no ICR is received from DSO STA 1619, AP 1610 proceeds to transmit data frame 1667 at the start of R-TWT SP 1650. In an example, AP 1610 proceeds to transmit data frame 1667 after a backoff procedure is performed. In an example, the backoff procedure may be a full backoff, such as a backoff used for an initial access attempt of a STA to a communications channel. In different implementations, a full backoff may include an initial SIFS duration or PIFS duration followed by a random duration backoff after the initial SIFS or PIFS duration. In another example, the backoff may be a partial backoff, with a shorter backoff time and / or using a less sensitive CCA threshold, than a full backoff In another example, the backoff may comprise an initial SIFS duration or a PIFS duration without or with a short random duration backoff (e.g., compared to a full backoff), to increase the probability of reestablishing control of SCH 1620.

[0179] In an embodiment, data frame 1667 is transmitted using SCH 1620, with transmission of data frame 1667 using SCH 1620 not overlapping the bandwidth of R-TWT SP 1650, e.g., PCH 1622. Thus, in anDocket No.: 24-3034PCT embodiment illustrated by example 1600, before the start of R-TWT SP 1650, AP 1610 is configured to stop transmission of data frame 1665 to non-DSO STA 1617 using PCH 1622, and to maintain transmission of data frame 1667 to DSO STA 1617 on SCH 1620, during the R-TWT SP 1650.

[0180] In example 1600, PCH only indication 1636 specifies that R-TWT SP 1650 only applies to PCH 1622. In an embodiment, because R-TWT SP 1650 only applies to PCH 1622, this is an indication to AP 1610 to use a DSO to continue the TXOP after the start of R-TWT SP 1650. As such, AP 1610 may not terminate its transmission of data frame 1660 before the start of R-TWT SP 1650. This configuration is different from the example provided with FIG. 14, where the transmission of data frame 1460A is terminated at the start of R- TWT SP 1450 and the available bandwidth of SCH 1420 remains unused by AP 1410 during R-TWT SP 1450.

[0181] In contrast to example 1400, where AP 1410 is configured to terminate use of SCH 1420 during R- TWT SP 1450, in example 1600, AP 1610 continues to use SCH 1620 to transmit data frame 1667 after the beginning of R-TWT SP 1650. Thus, at least based on the foregoing, embodiments depicted with FIG. 16 may avoid the problem described above with FIG. 14.

[0182] FIG. 17 illustrates an example 1700 of a DSO with coordinated R-TWT operations, as illustrated in FIG. 13, according to an embodiment. As shown in FIG. 17, example 1700 includes an AP 1710 and an AP 1712. In an example, APs 1710 and 1712 operate on a plurality of channels, including a PCH 1722 and a SCH 1720. In an example, each of PCH 1722 and SCH 1720 may have a bandwidth of 160 MHz.

[0183] In an example, AP 1712 may support the 160 MHz bandwidth of PCH 1722, and AP 1710 may support the combined 320 MHz bandwidth of PCH 1722 and SCH 1720.

[0184] AP 1710 and AP 1712 support a R-TWT coordination, with at least AP 1710 supporting R-TWT coordination (e.g., Level 2) as described with respect to FIG. 11 above. In an example, AP 1712 may also support R-TWT Level 2 coordination, as described with FIG. 11 above.

[0185] At least AP 1710 has DSO capabilities, as described with respect to FIG. 12 above. In an example, AP 1712 may also have DSO capabilities. In example 1700, AP 1710 is depicted as transmitting and receiving communications from STAs that have DSO capabilities (DSO STA), and a STA that does not have DSO capabilities (non-DSO STA). In an example, a non-DSO STA may also reference a STA that has DSO capabilities, but is not using the DSO capabilities in the example. Example 1700 references DSO STA 1715 and DSO STA 1719, which have characteristics similar to DSO STA 1215 described with FIG. 12 above. Example 1700 further references non-DSO STA 1717, which has characteristics similar to non-DSO STA 1217 described with FIG. 12 above. For the sake of simplification of illustration, DSO STA 1715 and non- DSO STA 1717 are not shown in FIG. 17 but are referenced in frames received and transmitted by AP 1710.

[0186] In an embodiment, whether AP 1712 operates or does not operate on SCH 1720 may be known to AP 1710 based on passively listening to beacon frames transmitted byAP 1712, or by unicast transmissions from AP 1712 to AP 1710 (e.g., using a communication procedure to support multi-AP coordination).Docket No.: 24-3034PCT

[0187] Example 1700 commences with AP 1712 transmitting a frame 1730. In an example, frame 1730 may be a beacon frame including a TWT element that announces an R-TWT SP 1750 scheduled by AP 1712 for the performance of frame exchanges 1795 by AP 1712 (e.g., with one or more STAs associated with AP 1712). AP 1710 may acknowledge / accept R-TWT SP 1750 (not shown).

[0188] In an embodiment, AP 1712 may be referred to as a Co-RTWT requesting AP. For example, as discussed above, AP 1712 may announce R-TWT SP 1750 (e.g., in frame 1730), scheduled by AP 1712. In an embodiment, AP 1710 may be referred to as a Co-RTWT responding AP or a Co-RTWT coordinated AP. For example, as discussed above, AP 1710 may acknowledge / accept R-TWT SP 1750 (e.g., scheduled by AP 1712).

[0189] Continuing example 1700, AP 1710 transmits an ICF 1770 on the combined 320 MHz bandwidth of PCH 1722 and SCH 1720. In an embodiment, ICF 1770 may indicate to one or more DSC STAs to move / switch to SCH 1720. For example, a DSC STA 1715 and a non-DSO STA 1717 receive ICF 1770 on PCH 1722. With receipt of ICF 1770, similar to the operation of DSO STA 1215, DSC STA 1715 receives an indication to switch to SCH 1720. In an example, DSO STA 1715 is directed to immediately switch to SCH 1720. In another example, DSO STA 1715 may be further directed by ICF 1770 to remain at SCH 1720 for continuation of a DSO frame exchange with AP 1710.

[0190] Based on the indication of ICF 1770, DSO STA 1715 may switch from PCH 1722 to SCH 1720. To indicate the switch by DSO STA 1715 to SCH 1720 to AP 1710, DSO STA 1715 may transmit an ICR frame 1771 on SCH 1720. With receipt of ICF 1770, non-DSO STA 1717 may transmit an ICR frame 1772 on PCH 1722 to AP 1710 indicating that PCH 1722 is not busy from the perspective of non-DSO STA 1717.

[0191] After receiving ICR frame 1771 from DSO STA 1715 on SCH 1720, and ICR frame 1772 from DSO STA 1717 on PCH 1722, AP 1710 may acquire a TXOP for transmission (not shown) of data frame 1760 and data frame 1765 to DSO STA 1715 and non-DSO STA 1717, respectively. In an example, the TXOP may be initiated with a bandwidth of 320 MHz that includes PCH 1722 and SCH 1720.

[0192] After acquiring the TXOP, AP 1710 may simultaneously transmit a data frame 1760 to DSO STA 1715 and a data frame 1765 to non-DSO STA 1717, respectively. AP 1710 transmits data frame 1765 to non-DSO STA 1717 on PCH 1722, and data frame 1760 to DSO STA 1715 on SCH 1720. In an example, data frame 1760 and data frame 1765 are included in a PPDU transmitted during a TXOP. In an example, one or both of DSO STA 1715 and non-DSO STA 1717, may respond to the data frames by transmitting a BA frame to AP 1710 (not shown).

[0193] Continuing example 1700, before the start of R-TWT SP 1750, AP 1710 may transmit an ICF 1769 to DSO STA 1719 on the combined 320 MHz bandwidth of PCH 1722 and SCH 1720. In an embodiment, ICF 1769 may indicate to DSO STA 1719 to switch to SCH 1720. In an example, DSO STA 1715 is directed to immediately switch to SCH 1720. Based on the indication of ICF 1770, DSO STA 1719 may switch from PCH 1722 to SCH 1720. To indicate the switch of DSO STA 1719 by to SCH 1720 to AP 1710, DSO STADocket No.: 24-3034PCT1719 may transmit an ICR frame 1771 on SCH 1720. In another example (not shown in FIG. 17), in accordance with the direction to DSO STA 1715 in ICF 1770 to remain on SCH 1720, DSC STA 1715 may remain on SCH 1720 after receiving data frame 1760. To indicate to AP 1710 that DSO STA 1715 is on SCH1720 to, DSO STA 1715 may transmit an ICR frame 1774 on SCH 1720. Using the TXOP obtained for the transmission of data frame 1760, after receiving ICR frame 1774, AP 1710 may transmit a data frame 1767 to DSO STA 1715. In an example, data frame 1767 is included in the PPDU used to transmit data frame 1760 and data frame 1765, during the TXOP obtained by AP 1710.

[0194] In accordance with the direction to DSO STA 1719 in ICF 1770, at the starting time of R-TWT SP 1750, DSO STA 1719 may switch from PCH 1722 to SCH 1720. To indicate the switch by DSO STA 1719 to SCH 1720 to AP 1710, DSO STA 1719 may transmit an ICR frame 1774 to AP 1710 on SCH 1720. After receiving ICR frame 1774, AP 1710 may transmit a data frame 1767 to DSO STA 1719. In an example, data frame 1767 is included in the PPDU used to transmit data frame 1760 and data frame 1765, during the TXOP obtained by AP 1710. In an alternative embodiment, data frame 1767 may be included in a PPDU different from the PPDU used to transmit data frame 1760 and data frame 1765, during the TXOP obtained by AP 1710

[0195] In an additional or alternative example, DSO STA 1719 does not send ICR frame 1774 at the start of R-TWT SP 1750. In this example, when no ICR is received from DSO STA 1719, AP 1710 proceeds to transmit data frame 1767 at the start of R-TWT SP 1750. In an example, AP 1710 proceeds to transmit data frame 1767 after a backoff procedure is performed. In an example, the backoff procedure may be a full backoff, such as a backoff used for an initial access attempt of a STA to a communications channel. In different implementations, a full backoff may include an initial SIFS duration or PIFS duration followed by a random duration backoff after the initial SIFS or PIFS duration. In another example, the backoff may be a partial backoff, with a shorter backoff time and / or using a less sensitive CCA threshold, than a full backoff. In another example, the backoff may comprise an initial SIFS duration or a PIFS duration without or with a short random duration backoff (e.g., compared to a full backoff), to increase the probability of reestablishing control of SCH 1720.

[0196] In an embodiment, data frame 1767 is transmitted using SCH 1720, with transmission of data frame 1767 using SCH 1720 not overlapping the bandwidth R-TWT SP 1750, e.g., PCH 1722. Thus, in an embodiment illustrated by example 1700, before the start of R-TWT SP 1750, AP 1710 is configured to stop transmission of data frame 1765 to non-DSO STA 1717 using PCH 1722, and to maintain transmission of data frame 1767 to DSO STA 1717 on SCH 1720, during the R-TWT SP 1750.

[0197] In contrast to example 1400, where AP 1410 is configured to terminate use of SCH 1420 during R- TWT SP 1450, in example 1700, AP 1710 continues to use SCH 1720 to transmit data frame 1767 after the beginning of R-TWT SP 1750. Thus, at least based on the foregoing, embodiments depicted with FIG. 17 may avoid the problem described above with FIG. 14.Docket No.: 24-3034PCT

[0198] FIG. 18 illustrates an example format of a continuation field 1800, according to an embodiment. Continuation field 1800 may be an embodiment of field 1535 or 1635 described above. Continuation field 1800 may be carried in a broadcast action frame, a beacon frame, a unicast action frame, a trigger frame, or a QoS Null frame, for example.

[0199] In an example, continuation field 1800 may include an RTWT Flow ID subfield, a TWT subfield, a BW value and / or a PCH only indication value subfield, and a PCH subfield. In example 1500, continuation field 1800 corresponds to field 1535, and in example 1600, continuation field 1800 corresponds to field 1635.

[0200] The RTWT Flow ID subfield identifies an R-TWT SP. For example, when continuation field 1800 is used in example 1500 as an embodiment of field 1535, the RTWT Flow ID subfield may correspond to R- TWT SP 1550. For example, when continuation field 1800 is used in example 1600 as an embodiment of field 1635, the RTWT Flow ID subfield may correspond to R-TWT SP 1650.

[0201] The TWT subfield identifies a start of the R-TWT SP. In an implementation, RTWT Flow ID identifies the start of the R-TWT SP. In an example, this value may or may not be needed if the RTWT Flow ID identifies an existing TWT. For example, when continuation field 1800 is used in example 1500 as an embodiment of field 1535, the TWT subfield may correspond to the start of R-TWT SP 1550. For example, when continuation field 1800 is used in example 1600 as an embodiment of field 1635, the TWT subfield may correspond to the start of R-TWT SP 1650.

[0202] When continuation field 1800 includes a BW value subfield, the BW value subfield indicates bandwidth information of a primary channel used by the R-TWT SP identified in the RTWT Flow ID subfield. For example, when continuation field 1800 is used in example 1500 as an embodiment of field 1535, the BW value subfield may carry value 1536 that specifies the bandwidth range of PCH 1522 on which R-TWT SP 1550 is scheduled for transmission of frame exchanges 1595.

[0203] When R-TWT continuation field 1800 includes a PCH only indication value subfield, the PCH only indication value indicates whether an R-TWT SP only applies to the primary channel used by the R-TWT SP. For example, when continuation field 1800 is used in example 1600 as an embodiment of field 1635, the PCH only indication 1636 may indicate that R-TWT SP 1650 only applies to PCH 1622 for transmission of frame exchanges 1695 by AP 1612.

[0204] The PCH subfield identifies a primary channel of a sending AP. This may be optional if the APs parse the beacons of each other. For example, when continuation field 1800 is used in example 1500 as an embodiment of field 1535, the PCH subfield may correspond AP 1512. For example, when continuation field 1800 is used in example 1600 as an embodiment of field 1635, the PCH subfield may correspond to AP 1612.

[0205] In embodiments, continuation field 1800 may be sent as a request, response or notification.

[0206] FIG. 19 illustrates an example process according to an embodiment. Example process 1900 may be performed by a first STA, such as AP 1510, AP 1610, and AP 1710, for example. Example process 1900Docket No.: 24-3034PCT may be performed by a second STA, such as AP 1512, AP 1612, and AP 1712, for example. As shown in FIG. 19, process 1900 may include steps 1902, 1904, and 1906.

[0207] In an embodiment, step 1902 of process 1900 may include, receiving, by a first station (STA) from a second STA and via a first channel, a first frame indicating a restricted target wake time (R-TWT) service period (SP) scheduled by the second STA on the first channel. In an embodiment, step 1904 of process 1900 may include, obtaining by the first the STA, a transmit opportunity (TXOP) on the first channel, with a bandwidth of the TXOP including a second channel. In an embodiment, step 1906 of process 1900 may include, before a start of the R-TWT SP, transmitting, by the first STA, a second frame using the TXOP and via the second channel, with the second frame overlapping the R-TWT SP.

[0208] In an embodiment, the first STA may include a first access point (AP). In an embodiment, the second STA may include a second AP. In an embodiment, the first AP and the second AP comprise a coordinating AP set. In an embodiment, the first frame may include a broadcast frame. In an embodiment, the broadcast frame may include a beacon frame. In an embodiment, the first frame may include a unicast frame. In an embodiment, the first frame may include an action frame. In an embodiment, the first frame may include a quality of service (QoS) null frame. In an embodiment, the first frame may include a trigger frame. In an embodiment, the first channel may include a primary channel of the second STA. In an embodiment, the first channel may include a primary channel of the first STA. In an embodiment, the second channel may include a secondary channel of the first STA. In an embodiment, whether the bandwidth of the TXOP may include the second channel is based on a clear channel assessment (CCA) status of the second channel being idle. In an embodiment, process 1900 may further include invoking a backoff procedure on the first channel to obtain a TXOP on the first channel.

[0209] In an embodiment, process 1900 may further include transmitting, by the first STA, a third frame using the TXOP and via the first channel, with the third frame ending before a start of the R-TWT SP. In an embodiment, the transmitting of the second frame and the transmitting of the third frame may include transmitting the second frame and the third frame using orthogonal frequency division multiple access. In an embodiment, the transmitting of the second frame and the transmitting of the third frame may include transmitting the second frame and the third frame using frequency domain aggregated physical layer protocol data unit.

[0210] In an embodiment, process 1900 may further include transmitting, by the first STA to a third STA, a fourth frame, before a start of the R-TWT SP, with the fourth frame indicating that the third STA is to switch a channel of operation from the first channel to the second channel. In an embodiment, the fourth frame may indicate a time to switch the channel of operation from the first channel to the second channel. In an embodiment, the time to switch the channel of operation from the first channel to the second channel is provided in a user info field of the fourth frame, with the user info field being associated with the third STA. In an embodiment, the fourth frame may include a trigger frame. In an embodiment, a time of a switching ofDocket No.: 24-3034PCT the channel operation may include a short interframe space after an end of the fourth frame. In an embodiment, the fourth frame may include padding associated with a delay of switching of channel operation from the first channel to the second channel by the third STA. In an embodiment, the fourth frame may include an initial control frame.

[0211] In an embodiment, process 1900 may further include receiving, from the second STA, an indication of allowance or disallowance of a dynamic subchannel operation that overlaps the R-TWT. In an embodiment, the indication is provided in the first frame. In an embodiment, the transmitting of the second frame is based on the indication indicating allowance of dynamic subchannel operation overlapping the R-TWT.

[0212] FIG. 20 illustrates an example process according to an embodiment. Example process 2000 may be performed by a first STA, such as AR 1512, AR 1612, and AR 1712, for example. Example process 2000 may be performed by a second STA, such as AR 1510, AR 1610, and AR 1710, for example. As shown in FIG 20, process 2000 may include step 2002.

[0213] In an embodiment, step 2002 of process 2000 may include, transmitting, by a first station (STA) to a second STA and via a first channel, a first frame indicating a restricted target wake time (R-TWT) service period (SR) scheduled by the first STA on the first channel, with the first frame including an indication of allowance or disallowance of a dynamic subchannel operation by the second STA that overlaps the R-TWT.

[0214] In an embodiment, process 2000 may further include, transmitting, by the first STA on the first channel, a second frame during the R-TWT SP. In an embodiment, the first STA may include a first access point (AR). In an embodiment, the second STA may include a second AR. In an embodiment, the first AR and the second AR form a coordinating AR set. In an embodiment, the first AR and the second AR are comprised in different BSSs. In an embodiment, the first frame may include a broadcast frame. In an embodiment, the broadcast frame may include a beacon frame. In an embodiment, the first frame may include a unicast frame. In an embodiment, the first frame may include an action frame.

[0215] In an embodiment, the first frame may include a trigger frame. In an embodiment, the first frame may include a quality of service (QoS) null frame. In an embodiment, the first channel may include a primary channel of the first STA. In an embodiment, first channel further may include a primary channel of the second STA. In an embodiment, the second channel may include a secondary channel of the second STA. In an embodiment, the field that determines a continuation of the TXOP may include a bandwidth value, that specifies a bandwidth of the first channel.

[0216] In an embodiment, process 2000 may further include, receiving, from the second STA, an indication of allowance or disallowance of a dynamic subchannel operation that overlaps the R-TWT. In an embodiment, the indication is provided in the first frame. In an embodiment, the transmitting of the second frame is based on the indication indicating allowance of dynamic subchannel operation overlapping the R-TWT.

[0217] FIG. 21 illustrates an example multi-AP network 2100. Example multi-AP network 2100 may be a multi-AP network in accordance with the Wi-Fi Alliance standard specification for multi-AP networks. AsDocket No.: 24-3034PCT shown in FIG. 21 , multi-AP network 2100 may include a multi-AP controller 2102 and a plurality of multi-AP groups (or multi-AP sets) 2104, 2106, and 2108.

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

[0219] Multi-AP groups 2104, 2106, and 2108 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.

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

[0221] 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 AP controller 2102 or by the APs of the multi-AP group. The 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.

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

[0223] Multi-AP transmissions may be enabled by the AP controller and / or by the master AP of the multi- AP group. In one approach, the 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 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.

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

[0225] 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 its 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.Docket No.: 24-3034PCT

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

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

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

[0229] 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-AP 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.

[0230] In an example, a multi-AP coordination (MAPC) framework includes a set of schemes (Co-BF, Co- SR, Co-TDMA, and Co-RTWT) and procedures in which APs operating their BSSs on the same primary 20 MHz channel coordinate to reduce interference levels and to improve network performance such as medium utilization efficiency, communication reliability, and latency.Docket No.: 24-3034PCT

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

[0232] An AP may advertise its MAPC capabilities, common MAPC parameters, and parameters specific to MAPC schemes by transmitting a MAPC Discovery Request frame to the broadcast address, or as an individually addressed frame to another AP. If an AP receives a soliciting MAPC Discovery Request frame from a transmitting AP, the AP shall respond by sending a MAPC Discovery Response frame to the broadcast address or as an individually addressed Management frame to the transmitting AP. The value of the Dialog Token field of the MAPC Discovery Response frame by the AP shall be set equal to the value of the Dialog Token field of the soliciting MAPC Discovery Request frame.

[0233] An AP that transmits a MAPC Discovery Request frame or a MAPC Discovery Response frame may include a Per-Scheme Profile subelement in the reported MAPC element for each MAPC scheme for which the AP signals a capability. The AP shall not include the MAPC Scheme Request Set field in the reported Per-Scheme Profile subelements.

[0234] A MAPC requesting AP is an AP that initiates an MAPC negotiation for one or more MAPC schemes with another AP. An MAPC requesting AP shall not initiate a MAPC negotiation for a specific MAPC scheme with a peer AP if the peer AP has set the corresponding field for the support of that MAPC scheme in the MAPC Common Info field reported in the MAPC Discovery Request frame, MAPC Discovery Response frame, or MAPC Negotiation Request frame most recently received by the MAPC requesting AP to 0. A MAPC responding AP is an AP that responds to a MAPC requesting AP.

[0235] A MAPC requesting AP may initiate a MAPC negotiation for one or more MAPC schemes by sending an individually addressed MAPC Negotiation Request frame to an MAPC responding AP. The MAPC Negotiation Request frame shall include a MAPC element including at least one Per-Scheme Profile subelement in the MAPC Schemes Info field. Additionally, the MAPC requesting AP shall not include the Per- Scheme Profile subelement for a specific MAPC scheme in the MAPC element if the AP has not indicated support for that MAPC scheme in the MAPC Capabilities field carried in the MAPC element. If a Per-Scheme Profile subelement is included in the MAPC element, the Per-Scheme Profile subelement shall carry the MAPC Scheme Request Set field including at least one MAPC Scheme Request field.

[0236] A MAPC responding AP that receives an individually addressed MAPC Negotiation Request frame from a MAPC requesting AP shall respond by sending an individually addressed MAPC Negotiation Response frame to the MAPC requesting AP. The value of the Dialog Token field of the MAPC Negotiation Response frame shall be set equal to the value of the Dialog Token field of the MAPC Negotiation Request frame. The MAPC Negotiation Response frame shall include a MAPC element including one Per-Scheme Profile subelement in the MAPC Schemes Info field for each Per-Scheme Profile subelement included by the MAPC requesting AP in the MAPC Negotiation Request frame. In the MAPC Negotiation Response frame,Docket No.: 24-3034PCT each Per-Scheme Profile subelement shall include a MAPC Scheme Request field with MAPC Operation Type field set to 3 and including a Status Code field for each corresponding MAPC Scheme Request field received in the MAPC Negotiation Request frame. If the AP accepts a request, the corresponding Status Code field shall be set to SUCCESS. If the AP rejects a request, it shall set the corresponding Status field to indicate an appropriate rejection status code.

[0237] After two APs establish an MAPC agreement, any of the two APs may initiate a MAPC negotiation as MAPC requesting AP to update or teardown the MAPC agreement.

[0238] To request for a new agreement establishment, the MAPC requesting AP shall set the MAPC Operation Type field to 0 and shall include the MAPC Scheme Parameters Set field in the MAPC Scheme Request field that carries the request.

[0239] A MAPC requesting AP shall not request to establish a new agreement for a specific MAPC scheme if the MAPC responding AP has set to 0 the corresponding field for enabling MAPC agreement establishment for that MAPC scheme in the MAPC Discovery Request frame, MAPC Discovery Response frame, or MAPC Negotiation Request frame most recently received by the MAPC requesting AP.

[0240] If the MAPC responding AP has accepted the request to establish a new MAPC agreement for a specific MAPC scheme, the MAPC requesting AP and the MAPC responding AP have established an MAPC agreement for that specific MAPC scheme.

[0241] A MAPC requesting AP and a MAPC responding AP may establish up to one MAPC agreement for each one of Co-BF, Co-SR, and Co-TDMA, and up to one MAPC agreement per R-TWT schedule for Co- RTWT.

[0242] When an AP participates in a MAPC negotiation to establish new MAPC agreement(s), the AP shall additionally follow the rules defined herein to assign an AP ID to a peer AP with which the AP establishes a MAPC agreement.

[0243] The same AP ID value shall not be assigned by the AP or by its affiliated MLD to any other STA. The STA is an associated non-AP STA, an unassociated non-AP STA that has been allocated a (Ranging session Identifier) RSID, or any other coordinated AP, or a non-AP MLD that is associated with the AP MLD.

[0244] The same AP ID value shall not be assigned by any other AP within the same multiple BSSID set to any other STA.

[0245] The AP ID value shall not be assigned by any other AP MLD that has any affiliated AP within the same multiple BSSID set to any other non-AP MLD.

[0246] The AP ID value shall be greater than 2nwhere n the value carried in the MBSSID Indicator (n) field of the Multiple BSSID element if the AP belongs to a multiple BSSID set.

[0247] To assign an AP ID to another AP, an AP shall include the AP ID field in a MAPC element.

[0248] A MAPC requesting AP shall include the AP ID field in the MAPC element carried in the transmitted MAPC Negotiation Request frame only if the MAPC requesting AP has not established any MAPC agreementDocket No.: 24-3034PCT for any one of Co-BF, Co-SR, or Co-TDMA with the MARC responding AP and the MAPC requesting AP is requesting to establish a new MAPC agreement for any one of Co-BF, Co-SR, or Co-TDMA.

[0249] A MAPC responding AP shall include the AP ID field in the MAPC element carried in the transmitted MAPC Negotiation Response frame, only if it has not established any MAPC agreement for any one of Co- BF, Co-SR, or Co-TDMA with the MAPC requesting AP and it is accepting a new MAPC agreement for any one of Co-BF, Co-SR, or Co-TDMA.

[0250] To request a parameter update for an established MAPC agreement, the MAPC requesting AP shall set the MAPC Operation Type field to 1 and shall include the corresponding MAPC Request Parameter Set field in the MAPC Scheme Request field that carries the request.

[0251] To accept or reject an update of an existing MAPC agreement, the MAPC responding AP shall follow the rules defined in 37.13.1.3.1 (General). If the MAPC responding AP rejects the update, the agreement update procedure fails and the parameters of the MAPC agreement are not updated.

[0252] FIG. 22 illustrates an example 2200 of a multi-AP negotiation procedure, followed by a multi-AP termination procedure. As shown in FIG. 22, example 2200 may include an AP 2202, an AP 2204, and an AP 2206. In an example, the multi-AP negotiation procedure may begin with a multi-AP discovery phase, in which AP 2202 transmits a frame 2208 to APs 2204 and 2206. In an example, frame 2208 polls APs 2204 and 2206 regarding joining a multi-AP group with AP 2202. In an example, frame 2208 may further indicate that r-TWT operation parameters will be negotiated in the multi-AP group. Frame 2208 may be a broadcast or multicast frame. APs 2204 and 2206 may respond to frame 2208 by transmitting to AP 2202 a frame 2210 and a frame 2212, respectively. For example, frames 2210 and 2212 may indicate acceptance or rejection by APs 2204 and 2206, respectively, of joining the multi-AP group with AP 2202. In an example, AP 2202 may be referred to as a coordinating AP, and APs 2204 and 2206 may be referred to as coordinated APs.

[0253] Subsequently, the multi-AP negotiation procedure may proceed to the multi-AP r-TWT negotiation phase, in which AP 2202 negotiates r-TWT operation parameters with APs 2204 and 2206. In an implementation, the objective of the multi-AP r-TWT negotiation phase is to reduce interference among APs 2202, 2204, and 2206 during r-TWT operation by, for example, ensuring that APs 2204 and 2206 extend protection to an r-TWT schedule of AP 2202. In an example, the r-TWT schedule may comprise periodic SPs for one or more STAs associated with AP 2202. The SPs may be used for low latency traffic communication between AP 2202 and the one or more STA associated with AP 2202. In an example, AP 2204 or AP 2206 extends protection to the r-TWT schedule of AP 2202 by terminating / ending an obtained TXOP before a start time of a SP of the r-TWT schedule of the AP 2202. In an example, AP 2202 may determine the r-TWT schedule for itself.

[0254] Subsequently, as shown, AP 2202 may transmit a frame 2214 to AP 2204. In an example, frame 2214 requests that AP 2204, itself, extend protection to the r-TWT schedule, but may not request that STAs associated with AP 2204 also extend protection to the r-TWT schedule. In another example, frame 2214 mayDocket No.: 24-3034PCT request that AP 2204 and one or more of its associated STAs (e.g. , all associated STAs or any subset of associated STAs) extend protection to the r-TWT schedule. Upon receiving frame 2214, AP 2204 may transmit a frame 2216 to AP 2202. For example, frame 2216 may indicate acceptance or rejection, by AP 2204, of the request to extend protection to the r-TWT schedule. APs 2202 and 2204 may exchange additional frames (not shown in FIG. 22) until agreement is reached on extending protection to the r-TWT schedule by AP 2204. In example 2200, it is assumed that AP 2204 accepts the request to extend protection to the r-TWT schedule indicated in frame 2214.

[0255] Subsequently, AP 2202 may transmit a frame 2218 to AP 2206. In an example, frame 2218 requests that AP 2206, itself, extend protection to the r-TWT schedule, but may not request that STAs associated with AP 2206 also extend protection to the r-TWT schedule. In another example, frame 2218 may request that AP 2206 and one or more of its associated STAs (e.g., all associated STAs or any subset of associated STAs) extend protection to the r-TWT schedule. Upon receiving frame 2218, AP 2206 may transmit a frame 2220 to AP 2202. For example, frame 2220 may indicate acceptance or rejection, by AP 2206, of the request to extend protection to the r-TWT schedule. APs 2202 and 2206 may exchange additional frames (not shown in FIG. 22) until agreement is reached on extending protection to the r-TWT schedule by AP 2206. In example 2200, it is assumed that AP 2206 accepts the request to extend protection to the r-TWT schedule in frame 2218. Thus, the multi-AP r-TWT negotiation phase ends with frame 2220.

[0256] Subsequently, as shown, the multi-AP termination procedure may begin with the multi-AP agreement tear down. In an example, AP 2202 may transmit a frame 2222 to AP 2204. In an example, frame 2222 may indicate termination of the r-TWT schedule agreement between AP 2202 and AP 2204. Upon receiving frame 2222, AP 2204 may transmit a frame 2224 to AP 2202. In an example, frame 2224 may indicate to AP 2202 an acknowledgment of reception of frame 2222 by AP 2204. In an example, upon transmitting frame 2224, AP 2204 stops extending protection to the r-TWT schedule.

[0257] Subsequently, as shown, AP 2202 may transmit a frame 2226 to AP 2206. In an example, frame 2226 may indicate termination of the r-TWT schedule agreement between AP 2202 and AP 2206. Upon receiving frame 2226, AP 2206 may transmit a frame 2228 to AP 2202. In an example, frame 2228 may indicate to AP 2202 an acknowledgment of reception of frame 2226 by AP 2206. In an example, upon transmitting frame 2228, AP 2206 stops extending protection to the r-TWT schedule.

[0258] FIG. 23 illustrates an example 2300 of Dynamic Subband Operation (DSO). A non-AP STA supporting DSO may be referred to as a DSO non-AP STA. In an example this STA may set a DSO Support subfield of a UHR MAC Capabilities Information field of a UHR Capabilities element to 1 . If the STA does not support DSO, the STA may set the DSO Support subfield to 0. Similarly, an AP that supports DSO may be referred to as a DSO AP and may set the DSO Support subfield of the UHR MAC Capabilities Information field of the UHR Capabilities element to 1 . If the AP does not support DSO, the AP may set the DSO Support subfield to 0.Docket No.: 24-3034PCT

[0259] In an example, a DSO AP may dynamically allocate frequency resources to an associated DSO non- AP STA which has an operating bandwidth narrower than the DSO AP. For example, the DSO AP may dynamically allocate frequency resources outside the associated DSO non-AP STA's current operating bandwidth, and within the DSO AP's BSS bandwidth. As one example, this may be done on a per-TXOP basis. In an example, for a DSO non-AP STA, the channel with bandwidth equal to the STA’s operating bandwidth that includes the BSS primary channel may be referred to as the primary subband. Further, as one example, a channel with bandwidth equal to the STA’s operating bandwidth that lies outside the STA’s primary subband, but within the BSS bandwidth and where the DSO AP may allocate resources during DSO frame exchanges, may be referred to as a DSO subband. As one example, FIG. 23 illustrates a 160 MHz BSS bandwidth divided into eight 20 MHz subbands. A DSO AP may allocate or more of these subbands as a DSO subband. For example, a DSO non-AP STA may operate using an 80 MHz bandwidth. A DSO AP may allocate an 80 MHz DSO subband to the non-AP STA (e.g., four of the illustrated 20 MHz subbands).

[0260] When a DSO AP and a DSO non-AP STA operate in DSO mode, specific operational rules may apply. A DSO AP initiating a DSO frame exchange that excludes g roup-addressed data or management frames, and requires the DSO non-AP STA to switch to the DSO subband, may begin the frame exchange by transmitting a DSO Initial Control Frame (ICF) to the DSO non-AP STA. For example, the DSO ICF may be a BSRP Trigger frame. In an example, the DSO ICF may be sent in the non-HT duplicate PPDU format (e.g., at rates of 6 Mb / s, 12 Mb / s, or 24 Mb / s). Example 2300 illustrates a DSO AP transmitting a DSO ICF (e.g., a BSRP trigger frame transmitted using a non-HT duplicate PPDU) to two associated STAs: STA 2304 (a DSO non-AP STA) and STA 2306 (a non-AP STA that may or may not support DSO) (not illustrated).

[0261] In an example, the DSO ICF may include padding. In this example, a DSO AP may set the length of a padding field (e.g., as illustrated for example 2300) in the DSO ICF according to specific rules (e.g., rules described in section 37.20 of the IEEE 802.1 1 bn standard). As one example, the DSO AP may set the length of the padding field to ensure the MAC padding duration following an intermediate frame control sequence (IFCS) is greater than or equal to a DSO padding delay indicated by the DSO non-AP STA in a DSO padding delay field of a most recent successfully transmitted frame enabling DSO mode.

[0262] In an example, the number of spatial streams, used by a DSO non-AP STA to transmit an initial control response (ICR) in response to the DSO ICF, may be limited to one, for all scheduled DSO non-AP STAs, and may be indicated in the DSO ICF. Further, the DSO ICF, MAC padding duration, and response to the DSO ICF (e.g., ICR), may meet additional requirements associated with other mechanisms the scheduled non-AP STA may engage in, such as enhanced multi-link single radio (EMLSR) or dynamic power saving (DPS). In the DSO ICF, an AID12 subfield of a user info field may be set to the association identifier (AID) of the DSO non-AP STA, and the resource unit (RU) allocation subfield of a user info field corresponding to the DSO non-AP STA may be set to an RU assigned to the DSO non-AP STA that is contained in a single DSO subband.Docket No.: 24-3034PCT

[0263] In an implementation, as discussed above, a DSO AP may include an IFCS in the DSO ICF, if required by the DSO non-AP STA receiving the DSO ICF (e.g., if the DSO ICF requires padding). An IFCS may not be needed if the DSO non-AP STA requires no padding.

[0264] In an example, when a DSO non-AP STA receives the DSO ICF from its DSO AP, where the allocated RU to the DSO non-AP STA is contained in a DSO subband, the DSO non-AP STA transitions to the indicated DSO subband. Further, the DSO non-AP STA may transmit a corresponding ICR, to the DSO AP, on the allocated RU. The DSO non-AP STA may transmit the ICR a short interframe space (SIFS) after the end of the PPDU carrying the DSO ICF. In an example, the DSO non-AP STA may follow a carrier sense (CS) mechanism (e.g., defined in section 35.5.2.4 of the IEEE 802.1 1bn standard) before transmitting the ICR.

[0265] For example, as illustrated, a STA 2304 may receive the DSO ICF and transition to the indicated DSO subband (e.g., an upper 80 MHz out of the 160 MHz BSS bandwidth). STA 2304 may use the DSO subband to transmit an ICR 2314 to the DSO AP. For example, ICR 2314 may be a BSR, transmitted in response to a BSRP trigger frame transmitted by the DSO AP as an ICF. Similarly, a STA 2306 may also receive the DSO ICF and remain on the indicated primary subband (e.g., a lower 80 MHz out of the 160 MHz BSS bandwidth). STA 2306 may use the primary subband to transmit an ICR 2316 to the DSO AP. For example, ICR 2314 may be a BSR, transmitted in response to a BSRP trigger frame transmitted by the DSO AP as an ICF.

[0266] In an example, a DSO non-AP STA that switches to the DSO subband may receive frames, or may be triggered to transmit frames, by monitoring at least one 20 MHz channel in the DSO subband that overlaps with the allocated RU, subject to its spatial stream capabilities and operation mode. For example, the DSO non-AP STA may begin this monitoring a SIFS after the end of the PPDU carrying the ICR (e.g., a SIFS after the end of the PPDU carrying ICR 2314, for STA 2304, and a SIFS after the end of the PPDU carrying ICR 2316, for STA 2306. As illustrated, the DSO AP may transmit data to STA 2304 using its DSO subband (e.g., the upper 80 MHz of the 160 MHz BSS bandwidth), and may transmit data to STA 2306 using its primary subband (e.g., the lower 80 MHz of the 160 MHz BSS bandwidth). Each STA 2304 and STA 2306 may reply to the data transmission with an Ack, using the respective DSO subband for that STA.

[0267] A DSO AP may follow specific rules after the ICF / ICR exchange and until the DSO non-AP STA switches back from the DSO subband to the primary subband. The AP may indicate RU allocations for the DSO non-AP STA with reference to the BSS primary channel in all triggering frames and may ensure RU allocations for the DSO non-AP STA remain within the DSO subband during all triggering frames and DL MU PPDUs. In an example, the AP may not use MU-RTS or BSRP NTB Trigger frames during this period.

[0268] The DSO non-AP STA may switch back from the DSO subband to the primary subband no later than the DSO switch back delay indicated by the DSO non-AP STA in the DSO Switch Back Delay field of theDocket No.: 24-3034PCT most recent successfully transmitted frame enabling DSO mode. This switch back may occur when certain conditions are met.

[0269] For example, as illustrated, the switch back may occur after a timeout interval. As one example, the DSO non-AP STA may not receive a PHY-RXSTART. indication primitive during a timeout interval of aSIFSTime + aSlotTime + 20 ps starting at the end of the PPDU transmitted by the DSO non-AP STA as a response to the most recently received frame from the DSO AP (e.g ., starting at the end of the illustrated Ack) or starting at the end of the reception of the PPDU containing a frame for the DSO non-AP STA from the DSO AP that does not require immediate acknowledgment. Alternatively, the DSO non-AP STA may receive a PHY-RXSTART. indication primitive during the timeout interval but may not detect within the PPDU corresponding to the PHY-RXSTART. indication any valid frames, such as an individually addressed frame with the RA equal to the MAC address of the DSO non-AP STA, a trigger frame with one of the user info fields addressed to the DSO non-AP STA, a CTS frame with the RA equal to the MAC address of the DSO AP, a multi-STA BlockAck frame with one of the per AID traffic identifier (TID) info fields addressed to the DSO non-AP STA, or an NDP announcement frame with one of the STA info fields addressed to the DSO non-AP STA.

[0270] Further, the DSO non-AP STA may not respond to the most recently received frame from the DSO AP within the DSO frame exchange that requires an immediate response after a SIFS and the DSO non-AP STA may switch back. If no non-AP STA with assigned resources in the primary 20 MHz subband responds to the DSO IGF, and at least one STA responds on another subband, the AP may either terminate the DSO frame exchange sequence with all non-AP STAs or may continue the sequence while ensuring the primary 20 MHz channel remains occupied.

[0271] FIG. 24 illustrates another example 2400 of DSO. DSO can enable an AP to utilize a secondary channel (e.g., DSO subband) in a dynamic manner on a per-TXOP basis whenever the AP wins channel access. The AP can dynamically decide whether to allocate STAs on the primary channel (e.g., primary subband) or the secondary channel, e.g., depending on bandwidth availability, channel conditions, QoS requirements and the STAs supporting the DSO. For example, the AP may use DSO to align the presence of narrower bandwidth STAs on the secondary channel.

[0272] As shown in FIG. 24, example 2400 includes an AP 2402 and STAs 2404, 2406, and 2408. In an example, STAs 2404, 2406, and 2408 may be associated with AP 2402. In an example, AP 2402 may operate over a plurality of channels, including a primary subband 2420 (labeled as PSB 2420 in FIG. 24) and a DSO subband 2422 (labeled as DSB 2422 in FIG. 24).

[0273] In example 2400, AP 2402 has DSO capabilities which enable AP 2402 to utilize available bandwidth in a dynamic manner on a per-TXOP basis whenever AP 2402 wins channel access. In an example, STAs 2404 and 2406 may support DSO and may be referred to as DSO STAs (or DSO non-AP STAs). As DSO STAs, STA 2404 and STA 2406 may be able to switch from the primary subband to the DSO subband withinDocket No.: 24-3034PCT a pre-defined delay (e.g., DSO padding / switching delay). In an example, STA 2408 may not support DSO and may be referred to as a non-DSO STA. As such, AP 2402 may communicate with STA 2408 only on primary subband 2420.

[0274] In example 2400, AP 2402 may have buffered data for STA 2404, STA 2406, and STA 2408. AP 2402 may have information that STAs 2404 and 2406 support DSO. In addition, AP 2402 may further have information regarding a set of channels (e.g., RUs in the DSO subband) to which STAs 2404 and 2406 are able to switch from the primary subband. Based on STAs 2404 and 2406 supporting DSO, AP 2402 may consider using DSO for frame exchanges with its associated STAs.

[0275] As shown in FIG. 24, example 2400 may start with AP 2402 transmitting an ICF 2430 over primary subband 2420 and DSO subband 2422. In an example, ICF 2430 may be a DSO ICF. By transmitting ICF 2430, AP 2402 may obtain a transmission opportunity (TXOP) 2410 on the BSS bandwidth that comprises primary subband 2420 and DSO subband 2422. In an example, AP 2402 may want to communicate with STA 2404 and STA 2406 simultaneously on DSO subband 2422. In an example, ICF 2430 may require / request / trigger STAs 2404 and 2406 to switch from primary subband 2420 to DSO subband 2422. In an example, AP 2402 may set an AID12 subfield of a user info field of ICF 2430 to an association identifier (AID) of STA 2404. In an example, AP 2402 may set a resource unit (RU) allocation subfield of the user info field corresponding to STA 2404 to an upper portion of DSO subband 2422 (e.g., to RUs corresponding to the upper portion of DSO subband 2422). Similarly, in an example, AP 2402 may set an AID12 subfield of another user info field of ICF 2430 to an AID of STA 2406. In an example, AP 2402 may set an RU allocation subfield of the user info field corresponding to STA 2406 to a lower portion of DSO subband 2422 (e.g., to RUs corresponding to the lower portion of DSO subband 2422). Similarly, in an example, AP 2402 may set an AID 12 subfield of another user info field of ICF 2430 to an AID of STA 2408. In an example, AP 2402 may set an RU allocation subfield of the user info field corresponding to STA 2408 to primary subband 2420 (e.g., to RUs corresponding to the full bandwidth of primary subband 2420).

[0276] In an example, AP 2402 may further set a length of a padding field in ICF 2430 to a value greater than or equal to a maximum value of DSO padding delay values of STA 2404 and STA 2406. As such, ICF 2430 provides enough time for both STAs to switch from primary subband 2420 to DSO subband 2422 before they respond to ICF 2430.

[0277] On receiving ICF 2430 and based on STA 2404 supporting DSO and being able to switch within a pre-defined delay (e.g., DSO padding delay of STA 2404), STA 2404 switches its channel operation from primary subband 2420 to DSO subband 2422. More specifically, STA 2404 may respond to ICF 2430 with an initial control response (ICR) frame 2434, a SIFS after ICF 2430, via RUs that are on DSO subband 2422 and that are indicated in ICF 2430 (e.g., upper portion of DSO subband 2422), to inform AP 2402 that STA 2404 has successfully switched to DSO subband 2422.Docket No.: 24-3034PCT

[0278] On receiving IGF 2430 and based on STA 2406 supporting DSO and being able to switch within a pre-defined delay (e.g., DSO padding delay of STA 2406), STA 2406 switches its channel operation from primary subband 2420 to DSO subband 2422. More specifically, STA 2406 may respond to ICF 2430 with an ICR frame 2436, a SIFS after ICF 2430, via RUs that are on DSO subband 2422 and that are indicated in ICF 2430 (e.g., lower portion of DSO subband 2422), to inform AP 2402 that STA 2406 has successfully switched to DSO subband 2422.

[0279] On receiving ICF 2430, STA 2408 may respond to ICF 2430 with an ICR frame 2438, a SIFS after ICF 2430, via RUs that are on primary subband 2420 and that are indicated in ICF 2430 (e.g., RUs corresponding to the full bandwidth of primary subband 2420), to inform AP 2402 that STA 2408 has successfully received ICF 2430.

[0280] On receiving ICR frames 2434, 2436, and 2438 from STAs 2404, 2406, and 2408, respectively, AP 2402 may transmit a downlink (DL) PPDU 2440 to STAs 2404, 2406, and 2408 a SIFS after the reception of ICR frames 2434, 2436, and 2438. As shown in FIG. 24, DL PPDU 2440 may comprise a data frame 2444 for STA 2404 on the upper portion of DSO subband 2422, a data frame 2446 for STA 2406 on the lower portion of DSO subband 2422, and a data frame 2448 for STA 2408 on primary subband 2420. In an implementation, AP 2402 may transmit DL PPDU 2440 by using an OFDMA PPDU (e.g., a PPDU format in which data frame 2444, data frame 2446, and data frame 2448 are transmitted via distinct resource units within the PPDU), a frequency domain aggregated physical layer PPDU (A-PPDU) (e.g., a PPDU format in which data frame 2444, data frame 2446, and data frame 2448 are transmitted using distinct PPDUs which may or may not have the same PPDU format on the upper portion of DSO subband 2422, on the lower portion of DSO subband 2422, and on primary subband 2420, respectively), or a Frequency Division Multiple Access (FDMA) PPDU (e.g., a PPDU format in which data frame 2444, data frame 2446, and data frame 2448 are transmitted via distinct frequency subchannels).

[0281] In response to data frame 2444, STA 2404 may transmit a BA frame 2454 on DSO subband 2422, a SIFS after receiving data frame 2444. In response to data frame 2446, STA 2406 may transmit a BA frame 2456 on DSO subband 2422, a SIFS after receiving data frame 2446. In response to data frame 2448, STA 2408 may transmit a BA frame 2458 on primary subband 2420, a SIFS after receiving data frame 2448. In an alternative or additional example (not shown in FIG. 24), AP 2402 may not solicit BA frames from STAs 2404, 2406, and 2408.

[0282] After transmitting BA frames 2454 and 2456 respectively and not receiving a further frame from AP 2402 within a predetermined duration (e.g., during a timeout interval from BA frames 2454 and 2456), STAs 2404 and 2406 may switch to primary subband 2420.

Claims

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

1. A method comprising: receiving, by a first access point (AP) from a second AP and via a primary channel, a beacon frame indicating a restricted target wake time (R-TWT) service period (SP) scheduled by the second AP on the primary channel; obtaining, by the first AP, a transmit opportunity (TXOP) on the primary channel, wherein a bandwidth of the TXOP comprises a secondary channel; before a start of the R-TWT SP, ending communication using the TXOP via the primary channel; and transmitting, by the first AP, a frame using the TXOP and via the secondary channel, wherein the frame overlaps with the R-TWT SP.

2. A method comprising: receiving, by a first station (STA) from a second STA and via a first channel, a first frame indicating a restricted target wake time (R-TWT) service period (SP) scheduled by the second STA on the first channel; obtaining by the first STA, a transmit opportunity (TXOP) on the first channel, wherein a bandwidth of the TXOP comprises a second channel; and before a start of the R-TWT SP, transmitting, by the first STA, a second frame using the TXOP and via the second channel, wherein the second frame overlaps with the R-TWT SP.

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

4. The method of claim 3, wherein the second STA comprises a second AP.

5. The method of claim 4, wherein the first AP and the second AP comprise a coordinating AP set.

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

7. The method of claim 6, wherein the broadcast frame comprises a beacon frame.

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

9. The method of claim 8, wherein the first frame comprises an action frame.

10. The method of any of claims 2-5, wherein the first frame comprises a quality of service (QoS) null frame.11 . The method of any of claims 2-5, wherein the first frame comprises a trigger frame.

12. The method of any of claims claim 2-11 , wherein the first channel comprises a primary channel of the second STA.

13. The method of any of claims 2-12, wherein the first channel comprises a primary channel of the first STA.Docket No.: 24-3034PCT14. The method of any of claims claim 2-13, wherein the second channel comprises a secondary channel of the first STA.

15. The method of any of claims 2-14, wherein the bandwidth of the TXOP comprises the second channel based on a clear channel assessment (CCA) status of the second channel being idle.

16. The method of any of claims 2-15, further comprising invoking a backoff procedure on the first channel to obtain the TXOP on the first channel.

17. The method of any of claims 2-16, further comprising transmitting, by the first STA, a third frame using the TXOP and via the first channel, wherein the third frame ends before the start of the R-TWT SP.

18. The method of claim 17, wherein the transmitting of the second frame and the transmitting of the third frame comprise transmitting the second frame and the third frame using orthogonal frequency division multiple access.

19. The method of claim 17, wherein the transmitting of the second frame and the transmitting of the third frame comprises transmitting the second frame and the third frame using a frequency domain aggregated physical layer protocol data unit.

20. The method of any of claims 2-19, further comprising transmitting, by the first STA to a third STA, a fourth frame, before the start of the R-TWT SP, wherein the fourth frame indicates that the third STA is to switch a channel of operation from the first channel to the second channel.21 . The method of claim 20, wherein the fourth frame indicates a time to switch the channel of operation from the first channel to the second channel.

22. The method of claim 21 , wherein the time to switch the channel of operation from the first channel to the second channel is provided in a user info field of the fourth frame, wherein the user info field is associated with the third STA.

23. The method of claim 22, wherein the fourth frame comprises a trigger frame.

24. The method of claim 22, wherein the time to switch the channel operation from the first channel to the second channel comprises a short interframe space after an end of the fourth frame.

25. The method of claim 24, wherein the fourth frame comprises padding associated with a delay of switching the channel operation from the first channel to the second channel by the third STA.

26. The method of any of claims 20-25, wherein the fourth frame comprises an initial control frame.

27. The method of any of claims 2-26, further comprising receiving, from the second STA, an indication of allowance or disallowance of a dynamic subchannel operation that overlaps the R-TWT.

28. The method of claim 27, wherein the indication is provided in the first frame.

29. The method of claim 27, wherein the transmitting of the second frame is based on the indication indicating allowance of dynamic subchannel operation overlapping the R-TWT.

30. A method comprising:Docket No.: 24-3034PCT transmitting, by a first access point (AP) to a second AP and via a primary channel of the first AP and the second AP, a beacon frame indicating a restricted target wake time (R-TWT) service period (SP) scheduled by the first AP, wherein the first frame comprises an indication of allowance or disallowance of a dynamic subchannel operation by the second AP that overlaps the R-TWT.

31. A method comprising: transmitting, by a first station (STA) to a second STA and via a first channel, a first frame indicating a restricted target wake time (R-TWT) service period (SP) scheduled by the first STA on the first channel, wherein the first frame comprises an indication of allowance or disallowance of a dynamic subchannel operation by the second STA that overlaps the R-TWT.

32. The method of claim 31 , further comprising: transmitting, by the first STA on the first channel, a second frame during the R-TWT SP.

33. The method of claim 31 , wherein the first STA comprises a first access point (AP).

34. The method of claim 33, wherein the second STA comprises a second AP.

35. The method of claim 34, wherein the first AP and the second AP form a coordinating AP set.

36. The method of claim 34, wherein the first AP and the second AP are comprised in different BSSs.

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

38. The method of claim 37, wherein the broadcast frame comprises a beacon frame.

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

40. The method of any of claims 31-36, wherein the first frame comprises an action frame.41 . The method of any of claims 31-36, wherein the first frame comprises a trigger frame.

42. The method of any of claims 31-36, wherein the first frame comprises a quality of service (QoS) null frame.

43. The method of any of claims 31-42, wherein the first channel comprises a primary channel of the first STA.

44. The method of claim 43, wherein the first channel further comprises a primary channel of the second STA.

45. The method of any of claims 41-44, wherein the second channel comprises a secondary channel of the second STA.

46. The method of any of claims 41-45, wherein a field that determines a continuation of a transmit opportunity (TXOP) comprises a bandwidth value, that specifies a bandwidth of the first channel.

47. The method of any of claims 41-46, further comprising receiving, from the second STA, an indication of allowance or disallowance of a dynamic subchannel operation that overlaps the R-TWT.

48. The method of claim 47, wherein the indication is provided in the first frame.

49. The method of claim 32, wherein the transmitting of the second frame is based on the indication indicating allowance of dynamic subchannel operation overlapping the R-TWT.Docket No.: 24-3034PCT50. A device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the device to perform a method according to any of claims 1-49.51 . A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method according to any of claims

Images