WO2025193776A1 - Channel access control in restricted target wake time operations - Google Patents

Abstract

An access point (AP) transmits, to a first station (STA), a first frame indicating a restricted target wake time (RTWT) service period (SP) of an R-TWT setup between the AP and the first STA. The AP receives, from a second STA and during the R-TWT SP, a second frame to initiate a transmission opportunity (TXOP), where the second frame indicates a type of traffic to be transmitted by the second STA during the TXOP. Based on the type of traffic being of a first type of traffic, the AP transmits, to the second STA, a third frame for suspending channel access by the second STA.

Description

TITLE

Channel Access Control in Restricted Target Wake Time Operations

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/564,782, filed March 13, 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 (r-TWT) operation.

[0013] FIG. 11 illustrates an example Request-to-Send (RTS)ZCIear-to-Send (GTS) procedure.

[0014] FIG. 12 illustrates an example trigger enabled (TE) r-TWT operation.

[0015] FIG. 13 illustrates an example TE r-TWT operation.

[0016] FIG. 14 illustrates an example TE r-TWT operation according to an embodiment.

[0017] FIG. 15 illustrates an example TE r-TWT operation according to an embodiment.

[0018] FIG. 16 illustrates an example TE r-TWT operation.

[0019] FIG. 17 illustrates an example TE r-TWT operation according to an embodiment.

[0020] FIG. 18 illustrates an example TE r-TWT operation according to an embodiment.

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

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

[0023] FIG. 21 illustrates an example process according to an embodiment.

[0024] FIG. 22 illustrates an example process according to an embodiment. DETAILED DESCRIPTION

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

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

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

[0028] 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 {STA 1 , 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 “employ i n g/u sing” (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.

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

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

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

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

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

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

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

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

[0037] WLAN infra-structure network 102 may be coupled to one or more external networks. For example, as shown in FIG. 1, WLAN infra-structure network 102 may be connected to another network 108 (e.g., 802.X) via a portal 140. Portal 140 may function as a bridge connecting DS 130 of WLAN infra-structure network 102 with the other network 108. [0038] The example wireless communication networks illustrated in FIG. 1 may further include one or more ad-hoc networks or independent BSSs (I BSSs). An ad-hoc network or I BSS 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).

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

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

[0042] A frequency band may include one or more sub-bands or frequency channels. For example, PPDUs conforming to the IEEE 802.11 n, 802.11 ac, 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.

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

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

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

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

[0047] Target wake time (TWT), a feature introduced in the IEEE 802.11ah 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.

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

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

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

[0051] A TWT session may be negotiated between an AP and a STA. The TWT session may configure a TWT SP of DL and 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.

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

[0054] 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 311 and STA 313 may again exchange frames during second TWT SP 31-2.

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

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

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

[0058] FIG. 4 illustrates an example 400 of TWT operation in a multi-link environment including an AP multi-link 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, AP2412, and AP3413. In an example, AP 411, AP2412, and AP3413 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, AP2412, and AP3413 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.

[0059] In an example, STA 421 may transmit a TWT request to AP 411. 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.

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

[0061] In example 400, initial TWT SPs 430-1, 430-2, and 430-3 of links 1-3 respectively may be aligned (e.g., as aligned TWT SP 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.

[0062] FIG. 5 illustrates an example target wake time (TWT) element 500 which may be used to support individual TWT operation.

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

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

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

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

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

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

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

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

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

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

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

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

[0075] 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 nonnegotiated TWT schedules (e.g., broadcast TWT schedules).

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

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

[0079] The request type field may include, among other fields, a TWT request field, a flow type field, and a TWT wake interval exponent field.

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

[0081] 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) x 2<^{TWTWake lntereal} Exponent) The TWT _wa|_(e interval mantissa value is indicated in microseconds, base 2 in a TWT wake interval mantissa field of the TWT parameter information field.

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

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

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

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

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

[0088] 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 AP or the TWT scheduled STA as latency sensitive traffic streams in a downlink and a 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.

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

[0090] In trigger-enabled TWT, an AP may transmit a trigger frame for scheduling uplink multi-user transmissions from one or more STAs using uplink OFDMA (orthogonal frequency division multiple access) and/or uplink MU-MI MO (multiuser 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.

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

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

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

[0094] In an example, STA 711 may transmit a TWT request to AP 71 Oto 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 the 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. [0095] 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.

[0096] 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 711 and STA 12 may respond to the trigger frame by indicating that they are in awake state. In an example, STA 711 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.

[0097] 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 711 and STA 712 may return to a doze state.

[0098] 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 multi-user transmissions.

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

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

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

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

[0103] 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 811 and STA 812 may re-enter the doze state until the start of trigger-enabled TWT SP 820.

[0104] During trigger-enabled TWT SP 820, AP 810 may transmit a basic trigger frame to STA 811 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 811 and STA 812 may receive DL BUsfrom AP 810. STA 811 and STA 812 may return to the doze state outside of the TWT SP 720.

[0105] 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 811 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 811 receives a beacon frame from AP 810 at or after TBTT 830, STA 811 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 811 may return to the doze state after a nominal minimum TBTT wake duration time has elapsed from the TBTT start time.

[0106] 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 in 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.

[0107] 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, an RA field, and a frame check sequence (FCS) field.

[0108] 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. [0109] 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.

[0110] 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 911 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 GTS frame.

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

[0112] STA 911 may be scheduled to access the medium during the TWT SP 920. STA 911 may respond to the RTS frame with a GTS frame. Upon receiving the GTS frame, AP 910 may transmit a downlink frame to STA 911. STA 911 may respond to the downlink frame with a BA frame. When the TWT SP 920 ends, STA 911 may return to the doze state. [0113] Traffic originating from many real time applications may have stringent latency requirements (e.g., very low average latency, worst-case latency on the order of a few to tens of milliseconds, and small jitter). Such traffic is referred to as latency sensitive traffic. Restricted TWT operation may allow an AP to use enhanced medium access protection and resource reservation mechanisms to provide more predictable latency, reduced worst case latency, and/or reduced jitter, with higher reliability for latency sensitive traffic.

[0114] Using TWT, a STA may negotiate awake periods with an AP to transmit and receive data packets. The STA may save power the rest of the time as the STA may remain in a doze state. TWT operation may thus lead to low power consumption for the participating STAs. TWT operation may also reduce the contention level and may support a collision- free and deterministic operation when STAs are distributed over different TWT sessions.

[0115] Using restricted TWT (r-TWT) operation, an AP may allocate r-TWT SP(s) that may be used for transmission of data frames with latency sensitive traffic by the AP and one or more STAs. Traffic identifiers (TIDs) of latency sensitive traffic may be indicated in a broadcast frame (e.g., beacon frame, probe response frame, etc.) sent by the AP. The TIDs may be indicated in a restricted TWT DL TID bitmap and/or a restricted TWT UL TID bitmap of a restricted TWT traffic info field of a TWT element. A data frame with a TID that is not identified as latency sensitive traffic may not be transmitted during an r-TWT SP.

[0116] A restricted TWT scheduling AP, referred to as an r-TWT scheduling AP, may be an extremely high throughput AP (EHT AP) (or a “Beyond EHT” AP) that supports restricted TWT operation. A restricted TWT scheduled STA, referred to as an r-TWT scheduled STA, is a non-AP EHT STA (or a non-AP “Beyond EHT” STA) that supports restricted TWT operation. When a restricted TWT agreement is set up, the EHT AP may announce a restricted TWT SP (r-TWT SP) schedule information in a broadcast TWT element. The broadcast TWT element may be contained in a management frame such as a beacon frame or a probe response frame.

[0117] The EHT AP may schedule a quiet interval that overlaps with a restricted TWT SP. The quiet interval may have a duration of 1 TU. The quiet interval may start at the same time as the corresponding r-TWT SP. A quiet interval may be scheduled by including a quiet element in a beacon frame and/or a probe response frame. Legacy STAs may not be permitted to initiate a frame transmission during the quiet interval overlapping with the r-TWT SP.

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

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

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

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

[0122] During the r-TWT SP 1020, AP 1010 and STA 1011 may exchange an RTS frame and a GTS frame. Subsequently, AP 1010 may send a data frame to STA 1011. 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.

[0123] 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 EDOA (Enhanced Distributed Channel Access) operation during the trigger-enabled TWT SP.

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

[0125] FIG. 11 illustrates an example 1100 of a Request-to-Send (RTS)ZCIear-to-Send (CTS) procedure. Example 1100 may be an example according to the RTS/CTS procedure as defined in section 10.3.2.9 of the IEEE 802.11 standard draft “IEEE P802.11 -REVme™ /D1.3, June 2022.” As shown in FIG. 11 , example 1100 may include STAs 1102 and 1104. Other STAs of the same BSS may also be within communication range of STAs 1102 and 1104.

[0126] Example 1100 may begin with STA 1102 transmitting an RTS frame 1106 to STA 1104. STA 1102 may transmit RTS frame 1106 to protect from hidden STA(s) the transmission of a data frame 1110 that STA 1102 intends to transmit to STA 1104. RTS frame 1106 may include a Duration/ID field. The Duration/ID field may be set to the time, in microseconds, required to transmit data frame 1110, plus one GTS frame, plus one ACK frame (if required), plus three SIFS (Short Interframe Spacing) periods.

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

[0128] STA 1104 may set an RA field of CTS frame 1108 to a non-bandwidth signaling TA obtained from the TA field of RTS frame 1106. STA 1104 may seta Duration field of CTS frame 1108 based on the Duration/ID field of RTS frame 1106, namely as equal to the value of the Duration/ID field of RTS frame 1106, adjusted by subtracting the time required to transmit CTS frame 1108 and one SIFS period.

[0129] Upon receiving CTS frame 1108, STA 1102 may wait one SIFS period before transmitting data frame 1110. STA 1104 may transmit an ACK frame 1112 in response to data frame 1110. STA 1104 may transmit ACK frame 1112 one SIFS after receiving data frame 1110.

[0130] As shown in example 1100, other STAs within communication range of STAs 1102 and 1104, and belonging to the same BSS, may set their NAVs according to RTS frame 1106 and/or CTS frame 1108. For example, a STA receiving RTS frame 1106 may set its NAV based on the Duration/ID field of RTS frame 1106. Another STA receiving CTS frame 1108 may set its NAV based on the Duration field of CTS frame 1108. As such, the other STAs may not access the channel using EDCA until the end of transmission of ACK frame 1112.

[0131] FIG. 12 illustrates an example 1200 of trigger-enabled (TE) r-TWT operation. As shown in FIG. 12, example 1200 includes AP 1202, STA 1204, and STA 1206. In an example, AP 1202 may transmit a frame 1208 indicating a TE r-TWT SP 1210 of a TE r-TWT setup by AP 1202. Frame 1208 may be a beacon frame, for example. In example 1200, STA 1204 may be a member r-TWT scheduled STA of the TE r-TWT, while STA 1206 may be a non-member of the TE r-TWT. STA 1206 may be a non-HE (pre-HE) or a non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT.

[0132] According to existing IEEE 802.11 rules, as a member of the TE r-TWT, STA 1204 may transmit without using EDCA during TE r-TWT SP 1210 in response to receiving a trigger frame from r-TWT scheduling AP 1202. STA 1204, however, may not transmit using EDCA during TE r-TWT SP 1210. In contrast, as a non-member of the TE r-TWT, STA 1206 may access the channel using EDCA during TE r-TWT SP 1210. [0133] In example 1200, during TE r-TWT SP 1210, STA 1206 may transmit RTS frame 1226 to AP 1202. As discussed above, AP 1202 may respond to RTS frame 1226, when RTS frame 1226 is addressed to AP 1202 and if the NAV indicates idle. In example 1200, AP 1202 may transmit a GTS frame 1214 to STA 1206 in response to RTS frame 1226. STA 1206 may then transmit a data frame 1216 to AP 1202. AP 1202 may acknowledge data frame 1216 by transmitting a BA frame 1218 to STA 1206.

[0134] According to example 1200, the transmission of RTS frame 1226 by non-member STA 1206 may delay AP 1202 from transmitting a trigger frame 1212 to member STA 1204 to allow STA 1204 to transmit/receive latency sensitive traffic associated with the TE r-TWT during TE r-TWT SP 1210. For example, as shown in FIG. 12, AP 1202 may cancel/delay the transmission of a trigger frame 1212 to STA 1204 upon receiving RTS frame 1226 from STA 1206. Only after AP 1202 acknowledges data frame 1216 from non-member STA 1206, AP 1202 may transmit a trigger frame 1220 to STA 1204, which allows STA 1204 to transmit a data frame 1222 containing latency-sensitive traffic to AP 1202. AP 1202 may acknowledge data frame 1222 by transmitting a BA frame 1224 to STA 1204.

[0135] For example, as shown in FIG. 12, AP 1202 may cancel/delay the transmission of a trigger frame 1212 to STA 1204 upon receiving RTS frame 1226 from STA 1206. Only after AP 1202 acknowledges data frame 1216 from non- member STA 1206, AP 1202 may transmit a trigger frame 1220 to STA 1204, which allows STA 1204 to transmit a data frame 1222 containing latency-sensitive traffic to AP 1202. AP 1202 may acknowledge data frame 1222 by transmitting a BA frame 1224 to STA 1204.

[0136] In other examples, the presence of multiple non-member STAs may prevent altogether AP 1202 from transmitting a trigger frame to member STA 1204 during TE r-TWT SP 1210. As such, member STA 1204 may not be able to transmit/receive any latency-sensitive traffic during TE r-TWT SP 1210 scheduled for STA 1204 by AP 1202.

[0137] FIG. 13 illustrates an example 1300 of a TE r-TWT operation. As shown in FIG. 13, example 1300 includes an AP 1302, and STAs 1304 and 1306. In an example, AP 1302 may transmit a frame 1310 indicating a TE r-TWT SP 1312 of a TE r-TWT setup by AP 1302. Frame 1310 may be a beacon frame, for example.

[0138] In example 1300, STA 1304 may be a member r-TWT scheduled STA of the TE r-TWT or TE r-TWT SP 1312, while STA 1306 may be a non-member of the TE r-TWT or TE r-TWT SP 1312. STA 1306 may be a non-HE (pre-HE) or non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT.

[0139] According to existing IEEE 802.11 rules, as a member of the TE r-TWT, STA 1304 may transmit during TE r- TWT SP 1312 in response to receiving a trigger frame from r-TWT scheduling AP 1302. STA 1304 however may not transmit using EDOA during TE r-TWT SP 1312. In contrast, as a non-member of the TE r-TWT, non-member STA 1306 may access the channel using EDOA during TE r-TWT SP 1312.

[0140] In example 1300, non-member STA 1306 may transmit an RTS frame 1314 to AP 1302 during r-TWT SP 1312. The transmission of RTS frame 1314 by non-member STA 1306 may cause AP 1302 to cancel/delay transmission of a trigger frame 1316A to member STA 1304, e.g., trigger frame 1316A being to allow STA 1304 to transmit to AP 1302 traffic associated with the TE r-TWT during TE r-TWT SP 1312. [0141] In an implementation, AP 1302 may respond to RTS frame 1314 from non-member STA 1306 by transmitting a OTS-to-self frame 1318. OTS-to-self frame 1318 may be transmitted by AP 1302 SIFS after receiving RTS frame 1314. OTS-to-self frame 1318 may be configured to cause deferral of channel access by non-member STA 1306. In an implementation, an RA field of OTS-to-self frame 1318 may be based on a MAC address of AP 1302. In an example, CTS-to-self frame 1318 may include a duration field that indicates a period of channel access deferral. In another implementation, frame 1318 may be another control frame to indicate deferring channel access of STA 1306. The other control frame may be uncast to STA 1306.

[0142] On receiving CTS-to-self frame 1318, non-member STA 1306 may set its NAV based on CTS-to-self frame 1318, thereby deferring channel access based on CTS-to-self frame 1318. As mentioned above, non-member STA 1306 may be a non-HE (pre-HE) or non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT. In example 1300, non-member STA 1306 may set a NAV to a non-zero value based on receiving CTS-to-self frame 1318, e.g., NAV 1395.

[0143] After transmitting CTS-to-self frame 1318, AP 1302 may proceed to transmit trigger frame 1316B to member STA 1304. In response, member STA 1304 may transmit a data frame 1322 to AP 1302, which may acknowledge data frame 1322 by transmitting BA frame 1324 to STA 1304. The trigger frame 1316B may be transmitted by AP 1302 using EDCA. The trigger frame 1316B may be transmitted by AP 1302 SI FS/PIFS after transmitting frame 1318. In an example, AP 1302 may transmit trigger frame 1316B SIFS after receiving frame 1314 (RTS) without transmitting frame 1318.

[0144] In example 1300, member STA 1304 and non-member STA 1306 may be seeking channel access for communication of different types of traffic. For example, a first type of traffic may comprise non-low latency traffic, nonlatency sensitive traffic, non-urgent traffic, and/or lower priority traffic, while a second type of traffic may comprise low latency traffic, latency sensitive traffic, urgent traffic, and/or high priority traffic.

[0145] In a first example, where non-member STA 1306 transmits RTS frame 1314 in order to transmit traffic of the first type to AP 1302, , the deferral of channel access by non-member STA 1306 because non-member STA 1306 is a non-member of the TE r-TWT, results in an efficient use of channel resources, e.g., deferring channel access to the communication of less urgent traffic by non-member STA 1306 so that STA 1304, with comparatively higher urgency traffic, may utilize the communication channel.

[0146] In a second example, where non-member STA 1306 transmits RTS frame 1314 in order to transmit traffic of the second type, and where member STA 1304 has buffered traffic of the first type to transmit to AP 1302, the deferral of channel access by non-member STA 1306 because non-member STA 1306 is a non-member of the TE r-TWT, may result in a less efficient use of channel resources, e.g., deferring channel access to the communication of more urgent traffic by non-member STA 1306 so that STA 1304, with comparatively lower urgency traffic, may utilize the communication channel.

[0147] Embodiments of the present disclosure, as further described below, address the above-described problem. In some embodiments, an AP may selectively defer access to the communication channel based on the urgency of the type of traffic for which the communication channel is to be utilized. [0148] In an aspect of the embodiments, during a R-TWT SP scheduled for a second STA, an AP receives from a first STA a first frame (an initial control frame) to initiate a transmission opportunity (TXOP), with the first frame indicating a type of traffic to be transmitted by the first STA during the TXOP. In another aspect, based on the type of traffic, the AP transmits to the first STA, a second frame (initial control response) indicating whether channel access by the second STA is suspended.

[0149] Continuing this discussion of example embodiments, in another aspect, based on the indication by the first frame from the non-member STA that the traffic to be transmitted by the non-member STA is of the first traffic type, a second frame may be transmitted to the non-member STA for suspending channel access by the non-member STA. Alternatively, based on the indication by the first frame from the member STA that the traffic to be transmitted by the member STA is of the first traffic type, a third frame may be transmitted to the member STA for suspending channel access by the member STA.

[0150] Thus, in accordance with one or more embodiments, network performance and efficiency may be improved by having the AP avoid unnecessarily and wastefully deferring traffic of the second type of traffic of STAs that may utilize TE r-TWT SP.

[0151] FIG. 14 illustrates an example 1400 of TE r-TWT operation according to an embodiment. Example 1400 is provided for the purpose of illustration only and is not limiting of embodiments. As shown in FIG. 14, example 1400 includes an AP 1410, and STAs 1411 and 1412.

[0152] In example 1400, STA 1411 may be a member r-TWT scheduled STA of the TE r-TWT or TE r-TWT SP 1413, while STA 1412 may be either a member or a non-member of the TE r-TWT or TE r-TWT SP 1413. STA 1412 may be a non-HE (pre-HE) or non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT or TE r-TWT SP 1413.

[0153] In an example, AP 1410 may transmit frame 1415 indicating a TE r-TWT SP 1413 of a TE r-TWT setup by AP 1410. In different implementations, frame 1415 may be a beacon frame, a probe response frame, a fast initial link setup (FILS) discovery frame, and/or another broadcast/multicast/unicast management/action frame.

[0154] In an example, STA 1412 may have buffered traffic to transmit to AP 1410. To initiate a TXOP to transmit the buffered traffic to AP 1410, STA 1412 may transmit an Initial Control Frame (IGF) 1430 to AP 1410 during r-TWT SP 1413. In different implementations, IGF 1430 may be an RTS frame, a multi-user RTS (MU-RTS) frame, a buffer status report poll (BSRP) frame, a Block Acknowledgement Request (BAR) frame, a trigger frame, and/or a new control frame, etc.

[0155] In an embodiment, in contrast to RTS frame 1314 described above, IGF 1430 may include an indication of a type of traffic for which the TXOP is requested. IGF 1430 may include an indication of a type of traffic that STA 1412 is going to transmit to AP 1410 during the TXOP is requested. For example, the indication may indicate whether the type of traffic is of the first type or the second type as described above. In some embodiments, the type of traffic comprises a traffic identifier (TID) for the traffic. In example 1400, the receipt of IGF 1430 from STA 1412, by AP 1410, may cause AP 1410 to cancel/delay transmission of a trigger frame 1435A to member STA 1411 to allow STA 1411 to transmit traffic to AP 1410 during TE r-TWT SP 1413.

[0156] In example 1400, member STA 1411 has traffic to be transmitted that is of the second type discussed above (e.g., low latency, more urgent, less latency sensitive, lower latency, and/or higher priority) and STA 1412 has traffic to be transmitted that is of the first type discussed above, e.g., non-low latency, less urgent, less latency sensitive, higher latency, and/or lower priority.

[0157] In an embodiment, AP 1410 may respond to IGF 1430 from STA 1412 by transmitting an Initial Control Response (ICR) frame 1470. In different implementations, ICR frame 1470 may be a clear-to-send (CTS) frame, a CTS-to-self frame, a new control frame, a management frame, and/or a QoS null frame. In an embodiment, an RA field of ICR frame 1470 is based on a Medium Access Control (MAC) address of STA 1412.

[0158] In an embodiment, ICR frame 1470 may be configured to, based on the indication that STA 1412 has traffic to be transmitted that is of the first type, cause deferral of channel access by STA 1412. As described herein, deferring channel access for a STA may also be termed suspending channel access of a STA. In an embodiment, ICR frame 1470 may be configured to, based on the indication that STA 1412 has traffic to be transmitted that is of the first type, cause STA 1412 not to communicate with AP 1410.

[0159] Based on ICR frame 1470, STA 1412 may defer its channel access to transmit over the wireless medium. For example, as shown in FIG. 14, STA 1412 may implement suspension 1450 by setting its NAV to a non-zero value. In an embodiment, ICR frame 1470 may include a time information that indicates a period of channel access deferral by STA 1412 (e.g., this period of channel access deferral is shown as suspension time 1455 in FIG. 14), and STA 1412 may set the NAV based on the time information included in ICR frame 1470. The time information may be included in a duration field/subfield of ICR frame 1470. The time information may also be included in another field/subfield of ICR frame 1470. [0160] After transmitting ICR frame 1470, AP 1410 may proceed to transmit trigger frame 1435B to member STA 1411. In response, member STA 1411 may transmit a TB PPDU 1480 to AP 1410, which may acknowledge TB PPDU 1480 by transmitting BA frame 1445 to STA 1411. The TB PPDU 1480 may contain latency sensitive traffic. In an embodiment, because STA 1412 has deferred its channel access (or STA 1412 does not communicate with AP 1410) based on ICR frame 1470, unlike the interrupted transmission of trigger frame 1435A, the transmission of trigger frame 1435B may not be disturbed by STA 1412. Member STA 1411 may transmit its latency sensitive traffic earlier within r-TWT SP 1413 and a likelihood of higher urgency traffic being unnecessarily and wasteful ly deferred in favor of lower urgency traffic may be reduced.

[0161] In an embodiment, trigger frame 1435B may be transmitted by AP 1410 using EDCA. Trigger frame 1435B may be transmitted by AP 1410 SIFS/PIFS after transmitting ICR frame 1470. In an embodiment, AP 1410 may transmit trigger frame 1435B SIFS after receiving IGF 1430, without transmitting ICRframe 1470. In this example, suspension time 1455 may be determined by STA 1412 using different approaches, e.g., based on an estimated suspension time from the timing of trigger frame 1435B, or from being included with frames including frame 1415 and/or trigger frame 1435B. [0162] FIG. 15 illustrates an example 1500 of TE r-TWT operation according to an embodiment. Example 1500 is provided for the purpose of illustration only and is not limiting of embodiments. As shown in FIG. 15, example 1500 includes an AP 1510, and STAs 1511 and 1512.

[0163] In example 1500, STA 1511 may be a member r-TWT scheduled STA of the TE r-TWT, while STA 1512 may be either a member or a non-member of the TE r-TWT. STA 1512 may be a non-HE (pre-HE) or non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT.

[0164] In an example, AP 1510 may transmit frame 1515 indicating a TE r-TWT SP 1513 of a TE r-TWT setup by AP 1510. In different implementations, frame 1515 may be a beacon frame, a probe response frame, a fast initial link setup (FILS) discovery frame, and/or another broadcast management/action frame.

[0165] In an example, STA 1512 may have buffered traffic to transmit to AP 1510. To initiate a TXOP to transmit the buffered traffic to AP 1510, STA 1512 may transmit an Initial Control Frame (IGF) 1530 to AP 1510 during r-TWT SP 1513. In different implementations, IGF 1530 may be an RTS frame, a MU-RTS frame, a BSRP frame, a BAR frame, and/or a new control frame, etc.

[0166] In an embodiment, in contrast to RTS frame 1314 described above, IGF 1530 may include an indication of a type of traffic for which the TXOP is requested. IGF 1530 may include an indication of a type of traffic that STA 1512 is going to transmit to AP 1510 during the TXOP is requested. For example, the indication may indicate whether the type of traffic is of the first type or the second type as described above. In some embodiments, the type of traffic comprises a traffic identifier (TID) for the traffic. In example 1500, the receipt of IGF 1530 from STA 1512, by AP 1510, may cause AP 1510 to cancel/delay transmission of a trigger frame 1535A to member STA 1511 to allow STA 1511 to transmit traffic to AP 1510 during TE r-TWT SP 1513.

[0167] In this example, member STA 1512 has traffic to be transmitted that is of the second type discussed above (e.g. , low latency, more urgent, less latency sensitive, lower latency, and/or higher priority). STA 1511 may have traffic to be transmitted that is of the first type discussed above, e.g., non-low latency, less urgent, less latency sensitive, higher latency, and/or lower priority.

[0168] Embodiments of the present disclosure address the above-described problem of FIG. 15 where a STA with comparatively higher urgency traffic is unnecessarily and wastefully deferred use of a communication channel so that a STA with comparatively lower urgency traffic may utilize the communication channel. For example, in contrast to embodiments described above with FIG. 13, where non-member STA 1306 attempted to transmit low latency traffic, but was unnecessarily and wastefully deferred use of the communication channel so that STA 1304, with comparatively lower urgency traffic, would have access to the communication channel.

[0169] In some embodiments, AP 1510 may selectively defer access to the communication channel based on the urgency of the type of traffic for which the communication channel is to be utilized. In an embodiment, in contrast to RTS frame 1314 described above, IGF 1530 may include an indication of a type of traffic for which the TXOP is requested. For example, the indication may indicate whether the type of traffic is of the first type or the second type as described above. In some embodiments, the type of traffic comprises a traffic identifier (TID) for the traffic.

[0170] In an embodiment, the receipt of IGF 1530 by FIG. 1510 from STA 1512 may cause AP 1510 to transmit an Initial Control Response (ICR) frame 1570. In different implementations, ICR frame 1570 may be a clear-to-send (CTS) frame, a CTS-to-self frame, a new control frame, a management frame, and/or a QoS null frame. In contrast to the deferral of STA 1306 described with FIG. 13 above, ICR frame 1570 may be configured to, based on the indication that STA 1512 has traffic to be transmitted that is the second type of traffic, cause deferral of channel access by member STA

1511. In an embodiment, an RA field of ICR frame 1570 is based on a Medium Access Control (MAC) address of STA

1512.

[0171] STA 1512 may then transmit a data frame 1582 to AP 1510. AP 1510 may acknowledge data frame 1582 by transmitting a BA frame 1545A to STA 1512. After STA 1512 completes transmission of data frame 1582 (e.g., based on receipt of BA frame 1545A by AP 1510), AP 1510 may proceed to transmit trigger frame 1535B to member STA 1511. Receiving trigger frame 1535B by member STA 1511 may cause member STA 1511 to transmit a TB PPDU 1580 containing the first type of traffic to AP 1510, which may acknowledge TB PPDU 1580 by transmitting BA frame 1545B to STA 1511.

[0172] In an embodiment, because STA 1511 has deferred its channel access based on ICR frame 1570, STA 1512 may transmit its traffic of the first type earlier within r-TWT SP 1513 and a likelihood of higher urgency traffic being unnecessarily and wastefu lly deferred in favor of lower urgency traffic may be reduced.

[0173] FIG. 16 illustrates another example 1600 of a TE r-TWT operation. As shown in FIG. 16, example 1600 includes an AP 1602 and STAs 1604, 1606, and 1608. In an example, AP 1602 may transmit a frame 1610 indicating a TE r-TWT SP 1612 of a TE r-TWT will be setup by AP 1602. In different implementations, frame 1610 may be a beacon frame, a probe response frame, a fast initial link setup (FILS) discovery frame, and/or another broadcast management/action frame.

[0174] In example 1600, STA 1604 may be a member r-TWT scheduled STA of the TE r-TWT, while STA 1606 may be a member or a non-member of the TE r-TWT. STA 1606 may be a non-HE (pre-HE) or non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT. STA 1608 may be a non-member STA within communication range of AP 1602, STA 1604, and/or STA 1606.

[0175] According to existing IEEE 802.11 rules, as a member of the TE r-TWT, STA 1604 may transmit during TE r- TWT SP 1612 in response to receiving a trigger frame from r-TWT scheduling AP 1602. STA 1604 however may not transmit using EDCA during TE r-TWT SP 1612. In contrast, as a non-member of the TE r-TWT, STA 1606 may access the channel using EDCA during TE r-TWT SP 1612.

[0176] In example 1600, STA 1606 may transmit IGF 1630A to AP 1602 during r-TWT SP 1612. The transmission of IGF 1630A by STA 1606 may cause AP 1602 to cancel/delay transmission of trigger frame 1616A to member STA 1604, e.g . , trigger frame 1616A being to allow STA 1604 to transmit to AP 1602 traffic associated with the TE r-TWT during TE r-TWT SP 1612.

[0177] In an implementation, AP 1602 may respond to IGF 1630A from STA 1606 by transmitting ICR frame 1670. ICR frame 1670 may be configured to cause deferral of channel access by STA 1606. ICR frame 1670 may indicate unavailability of AP 1602. ICR frame 1670 may indicate unavailability time information of AP 1602. ICR frame 1670 may indicate that not STA 1606 should not communicate with AP 1602. In that case, STA 1606 will not communicate with AP 1602 during a time duration indicated by time information indicated in ICR frame 1670. In an example, an RA field of ICR frame 1670 may be based on a MAC address of AP 1602 or a BSSID of AP 1602. In an example, an RA field of ICR frame 1670 may be based on a MAC address of STA 1606.

[0178] In an example implementation, a non-member STA of the r-TWT may set its NAV based on ICR frame 1670, thereby deferring channel access based on ICR frame 1670. On receiving ICR frame 1670, STA 1606 may set its NAV based on ICR frame 1670, thereby deferring channel access based on ICR frame 1670. In an embodiment, a non-member STA may determine not to communicate with an AP during a time duration indicated by time information indicated in ICR frame 1670. The non-member STA may be provided with time information that the AP is unavailable during the time duration indicated in ICR frame 1670. As mentioned above, STA 1606 may be a non-HE (pre-HE) or non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT.

[0179] After transmitting ICR frame 1670, AP 1602 may proceed to transmit trigger frame 1616B to member STA 1604. In response, member STA 1604 may transmit TB PPDU 1680 to AP 1602, which may acknowledge TB PPDU 1680 by transmitting BA frame 1645 to STA 1604.

[0180] In example 1600, on receiving ICR frame 1670, STA 1606 may set a NAV to a non-zero value, e.g., the NAV shown as suspension 1650A. In an example, ICR frame 1670 may include time information that indicates a period of channel access deferral. The time information may be indicated in a duration field of ICR frame 1670. The time information may be indicated in a new field of ICR frame 1670. In an example, ICR frame 1670 may include a time information for which AP is unavailable with STA 1606. In an example, ICR frame 1670 may include time information for which AP does not communicate with STA 1606. STA 1606 may set its NAV to the period of channel access deferral included in the duration field of ICR frame 1670, e.g., this duration being labeled suspension time 1655 in FIG. 16. In addition to the example actions of STA 1606, non-member STA 1608 may also set a NAV to the period of channel access deferral included in the duration field of ICR frame 1670, e.g., the NAV shown as suspension 1650B. Based on the time information, STA 1606 may determine not to communicate with AP 1602 during the time period indicated in ICR frame 1670.

[0181] After transmission of ICR frame 1670, AP 1602 may transmit trigger frame 1616B, and on receiving trigger frame 1616B, memberSTA 1604 may transmit TB PPDU 1680 to AP 1602. On receiving TB PPDU 1680 by AP 1602, AP 1602 may transmit BA frame 1645 to member STA 1604. [0182] After the expiration of suspensions 1650A-B, STA 1606 may retransmit IGF 1630B. However, in some configurations, suspensions 1650A-B may be of similar duration, e.g., based on the access class of the traffic. In addition, when ICR frame 1670 is broadcast, it is likely that other stations will receive the period of channel access deferral included in the duration field of ICR frame 1670, and contend for channel access after the suspension time indicated by the period of channel access deferral. This can cause problems because STA 1606 may be at a channel access priority disadvantage after channel access to STA 1606 has been deferred, as in example 1600. This disadvantage may occur when STA 1606 uses an existing EDCA parameter (e.g., as assigned contention window (GW)), because based on this parameter, STA 1608 may still be permitted to obtain the channel before STA 1606. For example, as depicted in FIG. 16, after the expiration of suspensions 1650A-B, STA 1608 secured channel access for RTS 1636, this further delaying the transmission of IGF 1630B by STA 1606.

[0183] The approach to channel access for deferred STAs after a deferral has completed, as described above, may result in unnecessary and wasteful deferring of channel access, especially considering that deferring, by AP 1602, of channel access by STA 1606 may have occurred based on factors that are not directly related to the priority of the traffic, e.g., whether the traffic to be transmitted following IGF 1630A is of the first type of traffic discussed above.

[0184] Embodiments of the present disclosure, as further described below, address the above-described problem of a STA that has been unnecessarily and wasteful ly deferred from channel access for an excessive period of time. In some embodiments, an AP may selectively provide a channel access parameter for use by a deferred STA to advantageously contend for channel access after a suspension time.

[0185] In an aspect of the embodiments, after the AP sends a first frame indicating a TE r-TWT SP between the AP and the first STA, the AP may receive a second frame from a second STA to initiate a TXOP during the TE r-TWT SP, with this second frame including an indication that the traffic to be transmitted by the second STA is of the first type of traffic. In another aspect, based on the indication by the second frame from the second STA that the traffic to be transmitted by the second STA is of the first type, the AP may transmit a third frame to the second STA for suspending channel access by the second STA. In another aspect of embodiments, in response to the second frame, the AP may transmit a fourth frame to the second STA, with the fourth frame indicating a channel access parameter for use by the second STA after an end of suspension of the channel access.

[0186] Thus, in accordance with one or more embodiments, network performance and efficiency may be improved by providing a channel access parameter to a STA that was subject to a deferral of channel access.

[0187] FIG. 17 illustrates an example 1700 of TE r-TWT operation according to an embodiment. Example 1700 is provided for the purpose of illustration only and is not limiting of embodiments. As shown in FIG. 17, example 1700 includes an AP 1702 and STAs 1704, 1706, and 1708. In example 1700, STA 1704 may be a member r-TWT scheduled STA of the TE r-TWT, while STA 1706 may be a member or non-member of the TE r-TWT. STA 1708 may be a STA within communication range of AP 1702, STA 1704, and/or STA 1706, and may be a non-member of the TE r-TWT.

[0188] In an embodiment, STA 1706 may have buffered traffic to transmit to AP 1702. To initiate a TXOP to transmit the buffered traffic to AP 1702, STA 1706 may transmit an Initial Control Frame (IGF) 1730A to AP 1702during r-TWT SP 1713. In different implementations, IGF 1730A may be an RTS frame, an MU-RTS frame, a BSRP frame, a BAR frame, and/or a new control frame, etc. In an embodiment, receiving IGF 1730A from STA 1706 may cause AP 1702 to cancel/delay transmission of trigger frame 1716A to member STA 1704, e.g., to allow STA 1706 to transmit traffic to AP 1702 during TE r-TWT SP 1713

[0189] In an embodiment, AP 1702 may respond to IGF 1730A from STA 1706 by transmitting ICR frame 1770. ICR frame 1770 may be configured to cause deferral of channel access by STA 1706. In an embodiment, an RA field of ICR frame 1770 may be based on a MAC address of AP 1702.

[0190] In an embodiment, a member or non-member STA of the r-TWT may set a NAV based on ICR frame 1770, thereby deferring channel access based on ICR frame 1770. As a non-member, the STA may be a non-HE (pre-HE) or non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT. Generally, a non-HE or non-EHT STA, regardless of implementation, is capable of interpreting an ICR frame. Thus, a non-member STA that is a non-HE or non-EHT STA of any type may be controlled according to this embodiment to defer its channel access based on ICR frame 1770.

[0191] In example 1700, on receiving ICR frame 1770, STA 1706 may set a NAV to a non-zero value, e.g., the NAV shown as suspension 1750A. As such, STA 1706 may defer channel access to transmit over the wireless medium based on ICR frame 1770. In an embodiment, ICR frame 1770 may include a duration field that indicates a period of channel access deferral. STA 1706 may set its NAV based on the period of channel access deferral included in the duration field of ICR frame 1770, e.g., this duration being termed suspension time 1755. In addition to the example actions of STA 1706, non-member STA 1708 may seta NAV based on ICR frame 1770, e.g., the NAV shown as suspension 1750B.

[0192] After transmission of ICR frame 1770, AP 1702 may transmit trigger frame 1716B. Based on trigger frame 1716B, STA 1704 may transmit TB PPDU 1780 to AP 1702. AP 1702 may respond to TB PPDU 1780 from STA 1704 by transmitting BA frame 1745.

[0193] In an embodiment, trigger frame 1716B may be transmitted by AP 1702 using EDCA. Trigger frame 1716B may be transmitted by AP 1702 SIFS/PIFS after transmitting ICR frame 1770. In an embodiment, AP 1702 may transmit trigger frame 1716B SIFS after receiving IGF 1730A, without transmitting ICR frame 1770. In this example, suspension time 1755 may be determined by STA 1706 and 1708 using different approaches, e.g., based on an estimated suspension time from the timing of trigger frame 1716B, or from being included with a frame transmitted by AP 1702, including frame 1710 and/or trigger frame 1716B.

[0194] After the expiration of suspensions 1750A-B, STA 1706 may retransmit IGF frame 1730B after an EDCA Arbitration Coordination function Interframe Space (AIFS) 1753 from expiration of suspensions 1750A-B. In some configurations, suspensions 1750A-B may be of similar duration and both STAs 1706 and 1708 may wait AIFS 1753 before contending for channel access. In an example, AIFS 1753 of STA 1706 may be same as AIFS 1753 of STA 1708 (shown in Fig. 17). In an example, AIFS 1753 of STA 1706 may be same as AIFS 1753 of STA 1708 (not shown in Fig. 17). In addition, when ICR frame 1770 is broadcast, it is likely that other stationswill contend for channel access after the suspension time. Some embodiments, as further discussed below, address the problem described with FIG. 16 where STA 1706 can be at a channel access priority disadvantage after deferral of channel access to STA 1706.

[0195] For example, in an embodiment, channel access for STA 1706 and STA 1708 may be handled by access classes (AOs) of a EDOA prioritizing approach. In the EDOA approach, different AOs may have different minimum and maximum contention windows (CWs), with a smaller GW being assigned to higher priority traffic that requires a higher likelihood of gaining channel access than a larger GW. In an example shown in FIG. 17, AIFS 1753 of STA 1706 may be the same as AIFS 1753 of STA 1708, e.g., for STAs with the same AOs. In an example not shown in FIG. 17, AIFS 1753 of STA 1706 may not be the same as AIFS 1753 of STA 1708, e.g., for STAs with different AOs.

[0196] Returning to the example 1700, in an embodiment, ICR frame 1770 may further include a channel access parameter for use by STA 1706 after an end of suspension 1750A. In an example embodiment, the channel access parameter communicated to STA 1706 by ICR frame 1770 includes a CW value. In embodiments, the CW value may be determined using different approaches. In an example approach, for the current AC of the traffic to be handled by STA 1706, a minimum CW size (CWmin) may be selected. With this approach, the minimum CW size selected may provide a channel access advantage to STA 1706 as compared to a larger, standard CW size assigned to STA 1708 and other STAs. In the example above, where AP 1702 may transmit trigger frame 1716B without transmitting ICR frame 1770, the channel access parameter may be communicated to STA 1706 by frame 1710, by trigger frame 1716B, and/or by other similar approaches.

[0197] In an additional or alternative approach utilized by embodiments, a CW value associated with an AC different from the traffic to be handled by STA 1706 may be selected for the traffic of STA 1706. For example, in EDCA, the voice stream access class (e.g., the AC_VO class) may be given the highest priority of the access classes, and an embodiment may assign a CW size to the traffic of the traffic of STA 1706 based on the AC_VO access class. With this approach, the CW size selected may provide a channel access advantage to STA 1706 as compared to a larger, standard CW size assigned to STA 1708 and other STAs.

[0198] In another example, based on channel access parameters and selected/decided CW value, an embodiment of AP 1702 may select a channel access parameter that includes a backoff amount(/backoff count) for STA 1706 based on the assigned/selected/decided CW, with a smaller CW corresponding to smaller BO duration (e.g., BO 1799A), and a longer BO duration (e.g., BO 1799B) being applied to STA 1708 based on a larger CW. The BO is selected randomly by STA 1706 and STA 1708 between 0 and the assigned/selected/decided CW value. In an example, STA 1706 may transmit ICF frame 1730B with smaller BO 1799A faster than STA 1708 with larger BO 1799B.

[0199] FIG. 18 illustrates an example 1800 of TE r-TWT operation according to an embodiment. Example 1800 is provided for the purpose of illustration only and is not limiting of embodiments. As shown in FIG. 18, example 1800 includes an AP 1802 and STAs 1804, 1806, and 1808. In an example, AP 1802 may transmit a frame 1810 indicating a TE r-TWT SP 1814 of a TE r-TWT will be setup by AP 1802. In different implementations, frame 1810 may be a beacon frame, a probe response frame, a fast initial link setup (FILS) discovery frame, and/or another broadcast management/action frame. [0200] In example 1800, STA 1804 may be a member r-TWT scheduled STA of the TE r-TWT, while STA 1806 may be a non-member of the TE r-TWT. STA 1806 may be a non-HE (pre-HE) or non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT. STA 1808 may be a STA within communication range of AP 1802, STA 1804, and/or STA 1806, and may or may not be a member of the TE r-TWT.

[0201] According to existing IEEE 802.11 rules, as a member of the TE r-TWT, STA 1804 may transmit during TE r- TWT SP 1814 in response to receiving a trigger frame from r-TWT scheduling AP 1802. STA 1804 however may not transmit using EDOA during TE r-TWT SP 1814. In contrast, as a non-member of the TE r-TWT, STA 1806 may access the channel using EDOA during TE r-TWT SP 1814.

[0202] In example 1800, STA 1806 may transmit IGF 1830A to AP 1802 during r-TWT SP 1814. The transmission of IGF 1830A by STA 1806 may cause AP 1802 to cancel/delay transmission of trigger frame 1816A to member STA 1804, e.g., with trigger frame 1816A being to allow STA 1804 to transmit/receive traffic associated with the TE r-TWT during TE r-TWT SP 1814.

[0203] In an embodiment, AP 1802 may respond to IGF 1830A from STA 1806 by transmitting ICR frame 1870. ICR frame 1870 may be configured to cause deferral of channel access by STA 1806. In an embodiment, an RA field of ICR frame 1870 may be based on a MAC address of AP 1802.

[0204] In an embodiment, a member or non-member STA of the r-TWT may set a NAV based on ICR frame 1870, thereby deferring channel access based on ICR frame 1870. As a non-member, the STA may be a non-HE (pre-HE) or non-EHT (pre-EHT) STA, a non-r-TWT scheduled STA (an EHT STA that does not support r-TWT), or an r-TWT scheduled STA that is not a member of the TE r-TWT. Generally, a non-HE or non-EHT STA, regardless of implementation, is capable of interpreting an ICR frame. Thus, a non-member STA that is a non-HE or non-EHT STA of any type may be controlled according to this embodiment to defer its channel access based on ICR frame 1870.

[0205] In example 1800, STA 1806 may set a NAV to a non-zero value based on receiving ICR frame 1870, e.g., the NAV shown as suspension 1850A. As such, STA 1806 may defer channel access to transmit over the wireless medium based on ICR frame 1870. In an embodiment, ICR frame 1870 may include a duration field that indicates a period of channel access deferral. STA 1806 may set its NAV based on the period of channel access deferral included in the duration field of ICR frame 1870, e.g., this duration being termed suspension time 1855. In addition to the example actions of STA 1806, non-member STA 1808 may set a NAV based on ICR frame 1870, e.g., the NAV shown as suspension 1850B.

[0206] After transmission of ICR frame 1870, AP 1802 may transmit trigger frame 1816B. Based on trigger frame 1816B, STA 1804 may transmit TB PPDU 1880 to AP 1802. AP 1802 may respond to TB PPDU 1880 from STA 1804 by transmitting BA frame 1845.

[0207] After the expiration of suspensions 1850A-B, STA 1806 may retransmit IGF 1830B after an EDCA Point Coordination function Interframe Space (PIFS) 1854 from expiration of suspensions 1850A-B. In some configurations, suspensions 1850A-B may be of similar duration and both STAs 1706 and 1708 may wait PIFS 1854 before contending for channel access. In addition, when ICR frame 1870 is broadcast, it is likely that other stations will contend for channel access after the suspension time. Some embodiments, as further discussed below, address the problem described with FIG. 16 where STA 1806 can be at a channel access priority disadvantage after deferral of channel access to STA 1806. [0208] In some configurations, suspensions 1850A-B may be of similar duration, e.g., based on the access class of the traffic. In addition, when ICR frame 1870 is broadcast, it is likely that other stations will contend for channel access after the suspension time. As described below, some embodiments may address the problem described with FIG. 16 where STA 1806 can be at a channel access priority disadvantage after deferral of channel access to STA 1806.

[0209] In an embodiment, after suspension 1850A, the channel access parameter included with ICR frame 1870 may specify that STA 1806 wait PIFS 1854 before transmitting ICF 1830B. To provide an advantage to STA 1806 after suspension of channel access by ICR frame 1870, other STAs, such as STA 1808, may be configured to utilize Arbitration Interframe Space (AIFS) 1854 (which is longer than PIFS 1854) and a backoff operation before channel contention. As applied by EDCA, AIFS 1853 may be selected based on an AC of traffic for which channel access is sought, e.g., by STA 1808. In implementations of EDCA, PIFS 1854 is selected as a minimum duration for access by higher priority traffic.

[0210] In an embodiment, using the shorter PIFS 1854 for STA 1806 may provide an advantage to STA 1806 that solves the problems discussed with FIG. 16 above, where STA 1806 is at a channel access disadvantage based on deferral by ICR frame 1870.

[0211] FIG. 19 illustrates an example process 1900 according to an embodiment. Example process 1900 may be performed by an AP, such asAP 1410, AP 1510, AP 1702, or AP 1802, described above. As shown in FIG. 19, process 1900 may include steps 1902 and 1904.

[0212] In an embodiment, process 1900 may comprise a step 1902 that includes, receiving, by an access point (AP) from a first STA and during a restricted target wake time (R-TWT) service period (SP) scheduled for a second STA, a first frame to initiate a transmission opportunity (TXOP). The first frame may indicate a type of traffic to be transmitted by the first STA during the TXOP. The first STA and/or the second STA may be associated with the AP. The first STA and the second STA may each be any suitable STA, such as STA 1411, STA 1412, STA 1511, STA 1512, STA 1704, STA 1706, STA 1708, STA 1804, STA 1806, and STA 1808 described in FIGS. 14, 15, 17, and 18, for example.

[0213] In an embodiment, process 1900 may further comprise a step 1904 that includes, based on the type of traffic, transmitting, by the AP to the first STA, a second frame indicating whether channel access by the second STA is suspended.

[0214] In an embodiment, process 1900 may further comprise, based on the type of traffic being of a first type of traffic, transmitting, by the AP to the second STA, a third frame for suspending channel access by the second STA. In an embodiment, the first type of traffic may correspond to a latency characteristic that is non-low latency (e.g., non-low latency, less urgent, less latency sensitive, lower latency, and/or lower priority) as compared to the latency characteristic of a second traffic type, e.g., low latency, more urgent, more latency sensitive, lower latency, higher priority. In an embodiment, the third frame may include an ICR frame, a CTS frame, a CTS-to-self frame, a new control frame, a management frame, and/or a QoS null frame. [0215] In an embodiment, process 1900 may further comprise, based on the type of traffic being of the second type of traffic, transmitting, by the AP to the second STA, a fourth frame in response to the second frame. In an embodiment, the second type indicates latency sensitive traffic, low latency traffic, urgent traffic, or high priority traffic.

[0216] In an embodiment, process 1900 may further comprise, receiving, by the AP from the second STA, a fifth frame in response to the fourth frame. In an embodiment, the fifth frame comprises a data frame.

[0217] In an embodiment, process 1900 may further comprise, transmitting, by the AP to the second STA, a sixth frame in response to the fifth frame. In an embodiment, the sixth frame comprises a block acknowledgement (BA) frame or an acknowledgement (Ack) frame. In an embodiment, the first type comprises at least one of non-latency sensitive traffic, non-low latency traffic, non-urgent traffic, or low priority traffic. In an embodiment, a first receive address (RA) of the fourth frame is set to a MAC address of the second STA. In an embodiment, a second RA of the third frame is set to an MAC address of the AP or a basic service set identifier (BSSID) of the AP. In an embodiment, a third RA of the third frame is set to a MAC address of the second STA. In an embodiment, the first frame comprises a beacon frame, a probe response frame, a fast initial link setup (FILS) discovery frame, or other broadcast management/action frame. In an embodiment, the second frame comprises a RTS frame, an MU-RTS trigger frame, a trigger frame, a BAR frame, a BSRP frame, an initial control frame (ICF), or a new control frame. In an embodiment, the third frame comprises a CTS frame, a CTS-to- self frame, an initial control response frame, a new control frame, a management frame, or a QoS null frame. In an embodiment, the fourth frame comprises a CTS frame, an initial control response frame, a new control frame, a management frame, or a QoS null frame. In an embodiment, the type of traffic comprises an indication field indicating whether the traffic is of the first type or the second type.

[0218] In an embodiment, the type of traffic comprises a TID for the traffic. In an embodiment, the type of traffic comprises one or more TIDs for one or more traffic. In an embodiment, one of values of the TID is mapped to low latency traffic. In an embodiment, one of values of the TID is mapped to non-low latency traffic. In an embodiment, the suspending of the channel access by the second STA comprises a deferral of the channel access by the second STA. In an embodiment, the type of traffic comprises characteristics of the traffic. In an embodiment, the AP knows whether the STA will transmit latency sensitive (/urgent) traffic in the TXOP based on the type. In an embodiment, the AP determines whether the AP will suspend the channel access of the second STA. In an embodiment, the first STA comprises a member STA of the R-TWT SP. In an embodiment, the second STA comprises a member STA of the R-TWT SP. In an embodiment, the second STA comprises a non-member STA of the R-TWT SP. In an embodiment, the suspending channel access by the second STA happens during the R-TWT SP. In an embodiment, the suspending channel access by the second STA happens during a duration indicated in a duration field of the second frame. In an embodiment, the suspending channel access by the second STA happens during a duration indicated in a suspension time field of the second frame. In an embodiment, the R-TWT comprises a trigger-enabled R-TWT. In an embodiment, the R-TWT comprises a non-trigger-enabled R-TWT. In an embodiment, the first frame comprises a target wake time (TWT) element. In an embodiment, the TWT element indicates the R-TWT SP. In an embodiment, the AP invokes an enhanced distributed channel access (EDCA) backoff procedure at a start of the R-TWT SP. [0219] In an embodiment, process 1900 may further comprise, after transmitting the third frame, transmitting, by the AP to the first STA, a seventh frame to solicit the first STA. In an embodiment, the seventh frame to solicit the first STA may be a trigger frame. In an embodiment, process 1900 may further comprise, receiving, by the AP from the first STA, an eighth frame (TB PPDU) in response to the seventh frame, and transmitting, by the AP to the first STA, a ninth frame in response to the eighth frame. In an embodiment, the eighth frame may be a TB PPDU frame. In an embodiment, the nineth frame may be a BA frame.

[0220] In an embodiment, process 1900 may further comprise, in response to the second frame, transmitting, by the AP to the second STA, a fourth frame for suspending channel access by the second STA, wherein the fourth frame indicates a channel access parameter for use by the second STA after an end of suspension of the channel access. In an embodiment, process 1900 may further comprise, receiving, by the AP from the second STA, the second frame using the channel access parameter after the end of the suspension. In an embodiment, the channel access parameter comprises a contention window (GW) value. In an embodiment, the GW value is set to a value of CWmin of a current access category (AC). In an embodiment, the GW value is set to a value of CWmin of a high priority AC. In an embodiment, the high priority AC comprises an AC_VO. In an embodiment, the channel access parameter comprises a recommended EDCA operation for the second STA after the end of the suspension. In an embodiment, the recommended EDCA operation is EDCA operation with GW set to CWmin. In an embodiment, the EDCA operation with GW set to CWmin comprises that the second STA transmits the second frame using EDCA parameter with GW set to CWmin. In an embodiment, the CWmin is for a current AC. In an embodiment, the CWmin is for a high priority AC. In an embodiment, the recommended EDCA operation comprises a point coordination function interframe space (PIFS) operation. In an embodiment, the PIFS operation comprises a transmission of a PIFS of the first frame by the first STA, after the suspension.

[0221] FIG. 20 illustrates another example process 2000 according to an embodiment. Example process 2000 may be performed by a first STA, such as STA 1411, STA 1412, STA 1511, STA 1512, STA 1704, 1706, 1708, 1804, 1806, or 1808, described above. As shown in FIG. 20, process 2000 may include steps 2002 and 2004.

[0222] In an embodiment, process 2000 may comprise a step 2002 that includes transmitting, by a first station (STA) to an access point (AP), a first frame to initiate a transmission opportunity (TXOP), wherein the first frame indicates a type of traffic to be transmitted by the first STA during the TXOP.

[0223] In an embodiment, process 2000 may further comprise a step 2004 that includes, based on the type of traffic being of a first type of traffic, receiving, by the first STA from the AP, a second frame for suspending channel access by the first STA.

[0224] In an embodiment, the first type of traffic may correspond to a latency characteristic that is non-low latency (e.g., non-low latency, less urgent, less latency sensitive, lower latency, and/or lower priority) as compared to the latency characteristic of a second traffic type, e.g., low latency, more urgent, more latency sensitive, lower latency, higher priority. In an embodiment, the second frame may include an ICR frame, a GTS frame, a CTS-to-self frame, a new control frame, a management frame, and/or a QoS null frame. [0225] In an embodiment, process 2000 may further comprise receiving, by the first STA from the AP, a third frame indicating a R-TWT SP of a R-TWT setup between the AP and the first STA, and transmitting, by the first STA, the first frame during the R-TWT SP. In an embodiment, process 2000 may further comprise, based on the type of traffic being of the second type of traffic, receiving, by the first STA from the AP, a fourth frame in response to the first frame. In an embodiment, process 2000 may further comprise, transmitting, by the first STA to the AP, a fifth frame in response to the fourth frame. In an embodiment, the fifth frame comprises a data frame. In an embodiment, process 2000 may further comprise receiving, by the first STA from the AP, a sixth frame in response to the fifth frame. In an embodiment, the sixth frame comprises a block acknowledgement (BA) frame or an acknowledgement (Ack) frame.

[0226] In an embodiment, the first type comprises at least one of non-latency sensitive traffic, non-low latency traffic, non-urgent traffic, or low priority traffic. In an embodiment, a first receive address (RA) of the second frame is set to a MAC address of the second STA. In an embodiment, a second RA of the second frame is set to an MAC address of the AP or a basic service set identifier (BSSID) of the AP. In an embodiment, a third RA of the second frame is set to a MAC address of the second STA. In an embodiment, an RA of the fourth frame is set to an MAC address of the first STA. In an embodiment, the first frame comprises a beacon frame, a probe response frame, a fast initial link setup (FILS) discovery frame, or other broadcast management/action frame. In an embodiment, the first frame comprises a RTS frame, an MU-RTS trigger frame, a trigger frame, a BAR frame, a BSRP frame, an initial control frame (ICF), or a new control frame. In an embodiment, the second frame comprises a CTS frame, a CTS-to-self frame, an initial control response frame, a new control frame, a management frame, or a QoS null frame. In an embodiment, the fourth frame comprises a clear-to-send (CTS) frame, an initial control response frame, a new control frame, a management frame, or a QoS null frame. In an embodiment, the third frame comprises a beacon frame, a probe response frame, a fast initial link setup (FILS) discovery frame, or other broadcast management/action frame. In an embodiment, the type of traffic comprises an indication field indicating whether the traffic is the first type or the second type.

[0227] In an embodiment, the type of traffic comprises a TID for the traffic. In an embodiment, the type of traffic comprises a combination of two or more TIDs. In an embodiment, the TID corresponds to low latency traffic. In an embodiment, the TID corresponds to non-low latency traffic. In an embodiment, the type of traffic comprises one or more TIDs for one or more traffic. In an embodiment, one of values of the TID is mapped to low latency traffic. In an embodiment, one of values of the TID is mapped to non-low latency traffic. In an embodiment, the suspending of the channel access by the first STA comprises a deferral of the channel access by the first STA. In an embodiment, the type of traffic comprises characteristics of the traffic. In an embodiment, the AP knows whether the STA will transmit latency sensitive (/urgent) traffic in the TXOP based on the type. In an embodiment, the AP determines whether the AP will suspend the channel access of the second STA. In an embodiment, the first STA comprises a member STA of the R-TWT SP. In an embodiment, the first STA comprises a non-member STA of the R-TWT SP. In an embodiment, the second STA comprises a member STA of the R-TWT SP. In an embodiment, the second STA comprises a non-member STA of the R-TWT SP. In an embodiment, the suspending channel access by the second STA happens during the R-TWT SP. In an embodiment, the suspending channel access by the second STA happens during a duration indicated in a duration field of the second frame. In an embodiment, the suspending channel access by the second STA happens during a duration indicated in a suspension time field of the second frame. In an embodiment, the R-TWT comprises a trigger-enabled R- TWT. In an embodiment, the R-TWT comprises a non-trigger-enabled R-TWT. In an embodiment, the first frame comprises a target wake time (TWT) element. In an embodiment, the TWT element indicates the R-TWT SP. In an embodiment, the AP invokes an enhanced distributed channel access (EDCA) backoff procedure at a start of the R-TWT SP.

[0228] In an embodiment, process 2000 may further comprise, in response to the first frame, receiving, by the STA from the AP, a second frame for suspending channel access by the first STA, wherein the second frame indicates a channel access parameter for use by the first STA after an end of suspension of channel access. In an embodiment, process 2000 may further comprise, transmitting, by the first STA to the AP, the first frame using the channel access parameter after the end of the suspension. In an embodiment, the channel access parameter comprises a contention window (GW) value. In an embodiment, the GW value is set to a value of CWmin of a current access category (AC). In an embodiment, the CW value is set to a value of CWmin of a high priority AC. In an embodiment, the high priority AC comprises an AC_VO. In an embodiment, the channel access parameter comprises a recommended EDCA operation for the second STA after the end of the suspension. In an embodiment, the recommended EDCA operation is EDCA operation with CW set to CWmin. In an embodiment, the EDCA operation with CW set to CWmin comprises that the second STA transmits the second frame using EDCA parameter with CW set to CWmin. In an embodiment, the CWmin is set based on a current AC. In an embodiment, the CWmin is for a high priority AC. In an embodiment, the recommended EDCA operation comprises a point coordination function interframe space (PIFS) operation. In an embodiment, the PIFS operation comprises a transmission of a PIFS of the first frame by the first STA, after the suspension.

[0229] FIG. 21 illustrates another example process 2100 according to an embodiment. Example process 2100 may be performed by an AP, such asAP 1410, AP 1510, AP 1702, or AP 1802, described above. As shown in FIG. 21, process 2100 may include steps 2102, 2103, and 2104.

[0230] In an embodiment, process 2100 may comprise a step 2102 that includes, transmitting, by an access point (AP) to a first station (STA), a first frame indicating a restricted target wake time (R-TWT) service period (SP) of an R-TWT setup between the AP and the first STA. The first STA may be any suitable STA, such as STA 1411, STA 1412, STA 1511, STA 1512, STA 1704, STA 1706, STA 1708, STA 1804, STA 1806, and STA 1808 described in FIGS. 14, 15, 17, and 18, for example.

[0231] In an embodiment, process 2100 may further comprise step a 2103 that includes receiving, by the AP from a second STA during the R-TWT SP, a second frame (E.G., an initial control frame). The second STA may be any suitable STA, such as STA 1411, STA 1412, STA 1511, STA 1512, STA 1704, STA 1706, STA 1708, STA 1804, STA 1806, and STA 1808 described in FIGS. 14, 15, 17, and 18, for example.

[0232] In an embodiment, process 2100 may further comprise a step 2104 that includes, in response to the second frame, transmitting, by the AP to the second STA, a third frame for suspending channel access by the second STA, wherein the third frame indicates a channel access parameter for use by the second STA after an end of suspension of the channel access.

[0233] In an embodiment, the channel access parameter is for use by the second STA for channel access during the R-TWT SP.

[0234] In an embodiment, the channel access parameter is for use by the second STA for channel access after the R- TWT SP.

[0235] process 2100 may further comprise receiving, by the AP from the second STA, the second frame using the channel access parameter after the end of the suspension.

[0236] FIG. 22 illustrates another example process 2200 according to an embodiment. Example process 2200 may be performed by a first STA, such as STA 1411, STA 1412, STA 1511, STA 1512, STA 1704, 1706, 1708, 1804, 1806, or 1808, described above. As shown in FIG. 22, process 2200 may include steps 2202, 2203, and 2204.

[0237] In an embodiment, process 2200 may comprise a step 2202 that includes transmitting, by a station (STA) to an access point (AP), a first frame.

[0238] In an embodiment, process 2200 may comprise a step 2203 that includes, in response to the first frame, receiving, by the STA from the AP, a second frame suspending channel access by the STA.

[0239] In an embodiment, process 2200 may comprise step 2204 that includes, transmitting, by the STA after an end of suspension of the channel access, a third frame by using an updated channel access parameter. In an embodiment, the updated channel access parameter comprises a contention widow (GW) set to a value of CWmin.

[0240] In another embodiment, another example process may include transmitting, by a first station (STA) to an access point (AP) and during a restricted target wake time (R-TWT) service period (SP) scheduled for a second STA, a first frame (e.g., an initial control frame) to initiate a transmission opportunity (TXOP), wherein the first frame indicates a type of traffic to be transmitted by the first STA during the TXOP. This example may further include, based on the type of traffic, receiving, by the first STA from the AP, a second frame (e.g., an initial control response) indicating whether channel access by the second STA is suspended.

[0241] In another embodiment, another example process may include transmitting, by a station (STA) to and access point (AP), a first frame (an initial control frame). This example may further include, in response to the first frame receiving, by the STA from the AP, a second frame suspending channel access by the STA, wherein the second frame indicates a channel access parameter for use by the STA after an end of suspension of the channel access. The example may further include transmitting, by the STA after the end of suspension of the channel access, a third frame comprising the channel access parameter.

Claims

1. A method comprising: transmitting, by an access point (AP) to a first station (STA), a first frame indicating a restricted target wake time (R-TWT) service period (SP) of an R-TWT setup between the AP and the first STA; receiving, by the AP from a second STA and during the R-TWT SP, a second frame to initiate a transmission opportunity (TXOP), wherein the second frame indicates a type of traffic to be transmitted by the second STA during the TXOP; and based on the type of traffic being of a first type of traffic, transmitting, by the AP to the second STA, a third frame for suspending channel access by the second STA.

2. A method comprising: receiving, by an access point (AP) from a first STA and during a restricted target wake time (R-TWT) service period (SP) scheduled for a second STA, a first frame to initiate a transmission opportunity (TXOP), wherein the first frame indicates a type of traffic to be transmitted by the first STA during the TXOP; and based on the type of traffic, transmitting, by the AP to the first STA, a second frame indicating whether channel access by the second STA is suspended.

3. The method of claim 2, further comprising, based on the type of traffic being of a first type of traffic, transmitting, by the AP to the second STA, a third frame for suspending channel access by the second STA.

4. The method of claim 3, wherein the third frame comprises a clear-to-send (GTS) frame, a CTS-to-self frame, an initial control response frame, a new control frame, a management frame, or a QoS null frame.

5. The method of claim 3, wherein a second RA of the third frame is set to an MAC address of the AP or a basic service set identifier (BSSID) of the AP.

6. The method of claim 3, wherein a third RA of the third frame is set to a MAC address of the second STA.

7. The method of claim 3, wherein the first type comprises at least one of non-latency sensitive traffic, non-low latency traffic, non-urgent traffic, or low priority traffic.

8. The method of any of claims 3-7, further comprising, based on the type of traffic being of a second type of traffic, transmitting, by the AP to the second STA, a fourth frame in response to the second frame.

9. The method of claim 8, wherein the second type comprises latency sensitive traffic, low latency traffic, urgent traffic, or high priority traffic.

10. The method of any of claims 8-9, wherein the fourth frame comprises a clear-to-send (CTS) frame, an initial control response frame, a new control frame, a management frame, or a QoS null frame.

11. The method of any of claims 8-10, wherein a first receive address (RA) of the fourth frame is set to a MAC address of the second STA.

12. The method of any of claims 2-11, wherein the first frame comprises a beacon frame, a probe response frame, a fast initial link setup (FILS) discovery frame, or other broadcast management or action frame.

13. The method of any of claims 2-12, wherein the second frame comprises a request-to-send (RTS) frame, an MU- RTS trigger frame, a trigger frame, a blockack request (BAR) frame, a buffer status report poll (BSRP) frame, an initial control frame (IGF), or a new control frame.

14. The method of any of claims 8-13, wherein the type of traffic comprises an indication field indicating whether the traffic is of the first type or the second type.

15. The method of any of claims 2-14, wherein the type of traffic comprises a traffic identifier (TID) for the traffic.

16. The method of any of claims 2-15, wherein the type of traffic comprises one or more traffic identifiers (TIDs) for one or more traffic.

17. The method of any of claims 15-16, wherein one of values of the TID is mapped to low latency traffic.

18. The method of any of claims 15-16, wherein one of values of the Tl D is mapped to non-low latency traffic.

19. The method of any of claims 3-18, wherein the suspending of the channel access by the second STA comprises a deferral of the channel access by the second STA.

20. The method of any of claims 2-19, wherein the type of traffic comprises characteristics of the traffic.

21. The method of any of claims 2-20, wherein the first STA comprises a member STA of the R-TWT SP.

22. The method of any of claims 2-21, wherein the second STA comprises a member STA of the R-TWT SP.

23. The method of any of claims 2-22, wherein the second STA comprises a non-member STA of the R-TWT SP.

24. The method of any of claims 2-23, wherein the AP invokes an enhanced distributed channel access (EDOA) backoff procedure at a start of the R-TWT SP.

25. The method of claim 2, further comprising, in response to the second frame, transmitting, by the AP to the second STA, a fourth frame for suspending channel access by the second STA, wherein the fourth frame indicates a channel access parameter for use by the second STA after an end of suspension of the channel access.

26. The method of claim 25, further comprising, receiving, by the AP from the second STA, the second frame using the channel access parameter after the end of the suspension.

27. The method of any of claims 25-26, wherein the channel access parameter comprises a contention window (GW) value.

28. The method of claim 27, wherein the GW value is set to a value of CWmin of a current access category (AC).

29. The method of claim 27, wherein the CW value is set to a value of CWmin of a high priority AC.

30. The method of claim 29, wherein the high priority AC comprises an AC of voice (AC_VO).

31. The method of any of claims 25-30, wherein the channel access parameter comprises a recommended EDCA operation for the second STA after the end of the suspension.

32. The method of claim 31 , wherein the recommended EDCA operation is EDCA operation with CW set to CWmin.

33. The method of claim 32, wherein the EDCA operation with CW set to CWmin comprises that the second STA transmits the second frame using EDCA parameter with CW set to CWmin.

34. The method of claim 33, wherein the CWmin is for a current access category (AC).

35. The method of claim 33, wherein the CWmin is for a high priority AC.

36. The method of any of claims 31-35, wherein the recommended EDCA operation comprises a point coordination function interframe space (PIFS) operation.

37. The method of claim 36, wherein the PIFS operation comprises a transmission of a PIFS of the first frame by the first STA, after the suspension.

38. A method comprising: transmitting, by a first station (STA) to an access point (AP), a first frame to initiate a transmission opportunity (TXOP), wherein the first frame indicates a type of traffic to be transmitted by the first STA during the TXOP; and based on the type of traffic being of a first type of traffic, receiving, by the first STA from the AP, a second frame for suspending channel access by the first STA.

39. The method of claim 38, further comprising: receiving, by the first STA from the AP, a third frame indicating a restricted target wake time (R-TWT) service period (SP) of a R-TWT setup between the AP and the first STA; and transmitting, by the first STA, the first frame during the R-TWT SP.

40. The method of claim 38, further comprising, based on the type of traffic being of a second type of traffic, receiving, by the first STA from the AP, a fourth frame in response to the first frame.

41. The method of claim 40, wherein the second type indicates latency sensitive traffic, low latency traffic, urgent traffic, or high priority traffic.

42. The method of claim 38, wherein the first type comprises non-latency sensitive traffic, non-low latency traffic, nonurgent traffic, or low priority traffic.

43. The method of claim 38, wherein the first frame comprises a request-to-send (RTS) frame, an MU-RTS trigger frame, a trigger frame, a block acknowledgement request (BAR) frame, a buffer status report poll (BSRP) frame, an initial control frame (IGF), or a new control frame.

44. The method of claim 38, wherein the second frame comprises a clear-to-send (GTS) frame, a CTS-to-self frame, an initial control response frame, a new control frame, a management frame, or a QoS null frame.

45. The method of claim 40, wherein the fourth frame comprises a clear-to-send (GTS) frame, an initial control response frame, a new control frame, a management frame, or a QoS null frame.

46. The method of claim 38, wherein the suspending of the channel access by the first STA comprises a deferral of the channel access by the first STA.

47. The method of claim 38, wherein the type of traffic comprises a characteristic of the traffic.

48. The method of claim 38, further comprising, in response to the first frame, receiving, by the STA from the AP, a second frame for suspending channel access by the first STA, wherein the second frame indicates a channel access parameter for use by the first STA after an end of suspension of channel access.

49. The method of claim 48, further comprising, transmitting, by the first STA to the AP, the first frame using the channel access parameter after the end of the suspension.

50. The method of claim 48, wherein the channel access parameter comprises a contention window (CW) value.

51. The method of claim 50, wherein the CW value is set to a value of CWmin of a current access category (AC).

52. The method of claim 50, wherein the CW value is set to a value of CWmin of a high priority AC.

53. The method of claim 52, wherein the high priority AC comprises an AC of voice (AC_VO).

54. The method of claim 48, wherein the channel access parameter comprises a recommended EDCA operation for the first STA after an end of the suspension.

55. The method of claim 54, wherein the recommended EDCA operation comprises an EDCA operation with CW set to CWmin.

56. The method of claim 55, wherein the EDCA operation with CW set to CWmin comprises that the first STA transmits the first frame using EDCA parameter with CW set to CWmin.

57. The method of claim 56, wherein the CWmin is for a current access category (AC).

58. The method of claim 57, wherein the CWmin is for a high priority AC.

59. The method of claim 55, wherein the recommended EDCA operation comprises a point coordination function interframe space (PIFS) operation.

60. The method of claim 59, wherein the PIFS operation comprises a transmission of a PIFS of the first frame by the first STA, after the suspension.

61. 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 -60.

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