Triggered TXOP Sharing (TXS) Power Save

A station (STA) receives from an access point (AP) a multi-user request to send (MU-RTS) triggered transmission opportunity (TXOP) sharing (MRTT) frame indicating a first time period, an association identifier (AID), and a triggered TXOP sharing mode. The STA transitions a power state to a doze state based on the AID being different from an AID of the STA and the triggered TXOP sharing mode having a non-zero value.

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

FIG.6illustrates an example TWT element which may be used to support restricted TWT (r-TWT) operation.

FIG.7illustrates an example of individual TWT operation.

FIG.8illustrates an example of broadcast TWT operation.

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

FIG.10illustrates an example of a triggered TXOP sharing (TXS) procedure (Mode=1).

FIG.11illustrates an example of a TXS procedure (Mode=2).

FIG.12is an example diagram of an MU-RTS trigger frame which may be used in a TXS procedure.

FIG.13is an example that illustrates an example TXS procedure between multi-link devices (MLDs).

FIG.14is an example that illustrates an inefficient STA operation that may occur during a TXS procedure.

FIG.15is an example that illustrates an example of a TXS power save (PS) mode according to an embodiment.

FIG.16is an example that illustrates an example TXS PS procedure between MLDs according to an embodiment.

FIG.17illustrates an example MAC capability field which may be used according to embodiments.

FIG.18illustrates an example process according to an embodiment.

FIG.19illustrates another example process according to an embodiment.

FIG.20illustrates another example process according to an embodiment.

FIG.21illustrates another example process according to an embodiment.

DETAILED DESCRIPTION

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.

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.

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.

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

In this disclosure, parameters (or equally called, fields, or Information elements: IEs) 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.

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.

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.

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

As shown inFIG.1, the example wireless communication networks may include an Institute of Electrical and Electronic Engineers (IEEE) 802.11 (WLAN) infra-structure network102. WLAN infra-structure network102may include one or more basic service sets (BSSs)110and120and a distribution system (DS)130.

BSS110-1and110-2each includes a set of an access point (AP or AP STA) and at least one station (STA or non-AP STA). For example, BSS110-1includes an AP104-1and a STA106-1, and BSS110-2includes an AP104-2and STAs106-2and106-3. The AP and the at least one STA in a BSS perform an association procedure to communicate with each other.

DS130may be configured to connect BSS110-1and BSS110-2. As such, DS130may enable an extended service set (ESS)150. Within ESS150, APs104-1and104-2are connected via DS130and may have the same service set identification (SSID).

WLAN infra-structure network102may be coupled to one or more external networks. For example, as shown inFIG.1, WLAN infra-structure network102may be connected to another network108(e.g., 802.X) via a portal140. Portal140may function as a bridge connecting DS130of WLAN infra-structure network102with the other network108.

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

For example, inFIG.1, STAs106-4,106-5, and106-6may be configured to form a first IBSS112-1. Similarly, STAs106-7and106-8may be configured to form a second IBSS112-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.

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.

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.

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

FIG.2is a block diagram illustrating example implementations of a STA210and an AP260.

As shown inFIG.2, STA210may include at least one processor220, a memory230, and at least one transceiver240. AP260may include at least one processor270, memory280, and at least one transceiver290. Processor220/270may be operatively connected to transceiver240/290.

Transceiver240/290may be configured to transmit/receive radio signals. In an embodiment, transceiver240/290may implement a PHY layer of the corresponding device (STA210or AP260).

In an embodiment, STA210and/or AP260may be a multi-link device (MLD), that is a device capable of operating over multiple links as defined by the IEEE 802.11be standard amendment. As such, STA210and/or AP260may each have multiple PHY layers. The multiple PHY layers may be implemented using one or more of transceivers240/290.

Processor220/270may implement functions of the PHY layer, the MAC layer, and/or the logical link control (LLC) layer of the corresponding device (STA210or AP260).

Processor220/270and/or transceiver240/290may include application specific integrated circuit (ASIC), other chipset, logic circuit and/or data processor. Memory230/280may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium and/or other storage unit.

When the embodiments are executed by software, the techniques (or methods) described herein can be executed with modules (e.g., processes, functions, and so on) that perform the functions described herein. The modules can be stored in memory230/280and executed by processor220/270. Memory230/280may be implemented (or positioned) within processor220/270or external to processor220/270. Memory230/280may be operatively connected to processor220/270via various means known in the art.

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.

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.

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.

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.

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.

FIG.3illustrates an example300of TWT operation. As shown inFIG.3, example300includes an AP311, a STA312, and a STA313. AP311and STA312may establish a TWT SP320. AP311and STA313may establish a TWT SP321. TWT SP320and TWT SP321may repeat as shown inFIG.3, such that TWT SP320may include a first TWT SP320-1and a second TWT SP320-2, and such that TWT SP321may include a first TWT SP321-1and a second TWT SP321-2.

AP311and STA312may exchange frames during first TWT SP320-1. STA312may enter a doze state at the end of TWT SP320-1and may remain in the doze state until the start of second TWT SP320-2. The start of second TWT SP320-2may be indicated by a TWT wake interval330associated with TWT SP320. AP311and STA312may again exchange frames during second TWT SP320-2.

Similarly, AP311and STA313may exchange frames during first TWT SP321-1. STA313may enter a doze state at the end of first TWT SP321-1and may remain in the doze state until the start of second TWT SP321-2. The start of second TWT SP321-2may be indicated by a TWT wake interval331associated with TWT SP321. AP311and STA313may again exchange frames during second TWT SP31-2.

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.

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

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.

FIG.4illustrates an example400of TWT operation in a multi-link environment including an AP multi-link device (AP MLD)410and a STA multi-link device (STA MLD)420. As shown inFIG.4, AP MLD410may have three affiliated APs, AP411, AP2412, and AP3413. In an example, AP411, AP2412, and AP3413may operate respectively on the 2.4 GHz band, the 5 GHz band, and the 6 GHz band. STA MLD420may have three affiliated STAs, STA421, STA422, and STA423. In an example, STA421, STA422, and STA423may operate respectively on the 2.4 GHz band, the 5 GHz band, and the 6 GHz band. In an example, AP411, AP2412, and AP3413may be communicatively coupled via a first link (link 1), a second link (link 2), and a third link (link 3) respectively with STA421, STA422, and STA423, respectively.

In an example, STA421may transmit a TWT request to AP411. 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, AP411may transmit a TWT response to STA421. 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.

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.

In example400, initial TWT SPs430-1,430-2, and430-3of links1-3respectively may be aligned. TWT wake intervals associated with the TWT agreements of links1-3respectively may be set differently. As such, second TWT SPs431-1,431-2, and431-3of links 1-3 respectively may not be aligned. STA421, STA422, and STA423may enter a doze state between the end of initial TWT SPs430-1,430-2, and430-3, respectively, and the start of second TWT SPs431-1,431-2,431-3, respectively.

FIG.5illustrates an example target wake time (TWT) element500which may be used to support individual TWT operation.

In an example, an AP and a STA may use TWT element500to negotiate a TWT agreement. The AP and/or the STA may transmit TWT element500in 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.

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.

Referring toFIG.5, TWT element500includes an element ID field, a length field, a control field, and a TWT parameter information field.

The element ID field (e.g., 1 octet in length) may indicate that information element500is a TWT element. The length field (e.g., 1 octet) may indicate the length of TWT element500starting from the control field until an end of TWT element500. The end of TWT element500may be the end of a TWT Channel field or the end of a Link ID bitmap field of the TWT parameter information field.

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

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

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 element500may represent a request to initiate TWT scheduling/setup.

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

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

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.

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.

In certain embodiments, a TWT element, such as TWT element500, 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.

FIG.6illustrates an example target wake time (TWT) element600which may be used to support restricted TWT (r-TWT) operation. For r-TWT, TWT element600may 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 element600provides non-negotiated TWT schedules (e.g., broadcast TWT schedules).

As shown, TWT element600includes an element ID field, a length field, a control field, and a TWT parameter information field.

The element ID field (e.g., 1 octet in length) may indicate that information element600is a TWT element. The length field (e.g., 1 octet) may indicate the length of TWT element600starting from the control field until an end of TWT element600. The end of TWT element600may 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.

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

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

The TWT request field indicates whether TWT element600is a request. If the TWT request field has a value of 0, then TWT element600may represent a response to a request to initiate TWT scheduling/setup (solicit TWT), an unsolicited TWT response, and/or a broadcast TWT message.

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)×2(TWT Wake Interval Exponent). The TWT wake interval mantissa value is indicated in microseconds, base 2 in a TWT wake interval mantissa field of the TWT parameter information field.

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.

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.

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.

A broadcast TWT element600that 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 element600. The r-TWT traffic info field is present in ar-TWT parameter set field when the r-TWT traffic info present subfield is set to 1.

The r-TWT traffic info field may include a traffic info control field, ar-TWT DL TID bitmap field, and a r-TWT UL TID bitmap field.

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.

The r-TWT DL TID bitmap subfield and the r-TWT UL TID bitmap subfield may specify which traffic identifier(s) (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.

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.

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-MIMO (multi-user multiple input multiple output) during a trigger-enabled (TE) 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 TE TWT SP.

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.

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.

FIG.7illustrates an example700of individual TWT operation. As shown inFIG.7, example700includes an AP710, a STA711, and a STA712. In an example, AP710may be a TWT responding STA and STA711and STA712may be TWT requesting STAs.

In an example, STA711may transmit a TWT request to AP710to setup a first trigger-enabled TWT agreement. STA711may set a trigger field of the TWT request to 1 to indicate that it is requesting a trigger-enabled TWT. AP710may accept the first TWT agreement with STA711. AP710may confirm the acceptance in a TWT response sent to STA711. The TWT response may indicate a next TWT730, which indicates the time until a next TWT SP720according to the first TWT agreement.

In an example, AP710may transmit an unsolicited TWT response to STA712to set up a second trigger-enabled TWT agreement with STA712without receiving a TWT request from STA712. The first and second TWT agreements may be set up as announced TWTs.

After the setup of the TWT agreements, STA711and STA712may enter a doze state until the start of TWT SP720. During TE TWT SP720, AP710may transmit a trigger frame. STA711and STA12may respond to the trigger frame by indicating that they are in awake state. In an example, STA711may 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 AP710and a transmitter address (TA) field set to an address of STA711. In an example, STA712may 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.

In response to the PS-Poll frame and the QoS null frame, AP710may 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 STAs711and712respectively. Subsequently, STA711and STA712may receive downlink bufferable units (DL BUs) from AP710. 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). STA711and STA712may transmit Block Ack (BA) frames in response to the DL BUs. At the end of the TWT SP720, STA711and STA712may return to a doze state.

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 TE TWT SPs. A HE TB PPDU may be transmitted by a STA based on receiving a trigger frame triggering uplink multi-user transmissions.

The AP of a trigger-enabled TWT agreement may schedule for transmission a trigger frame for a STA within the TE TWT SP. The STA may transmit an HE TB PPDU as a response to the trigger frame sent during the TE 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 a STA in PS mode, may deliver to the STA as many buffered BUs as are available at the AP during the TWT SP.

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.

FIG.8illustrates an example800of broadcast TWT operation. As shown inFIG.8, example800includes an AP810, a STA811, and a STA812. In an example800, AP810may be a TWT scheduling AP and STA811and STA812may be TWT scheduled STAs.

In an example, AP810may include a broadcast TWT element in a beacon frame that indicates a broadcast TWT SP820. During the broadcast TWT SP820, AP810may transmit trigger frames or DL BUs to STA811and STA812. Beacon frames may be sent by AP810at a regular interval defined as the target beacon transmission time (TBTT). The TBTT is a time interval measured in time units (TUs). A TU is equal to1024microseconds.

In an example, STA811and STA812may enter a doze state until the first target beacon transmission time (TBTT). STA811and STA812may 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, STA811and STA812may re-enter the doze state until the start of TE TWT SP820.

During TE TWT SP820, AP810may transmit a basic trigger frame to STA811and STA812. STA811may indicate that it is awake by transmitting a PS-Poll, and STA812may indicate that it is awake by transmitting a QoS null frame in response to the basic trigger frame. Subsequently, STA811and STA812may receive DL BUs from AP810. STA811and STA812may return to the doze state outside of the TWT SP720.

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 inFIG.8, STA811may transmit a TWT request to AP810that identifies a wake TBTT of the first beacon frame and a wake interval between subsequent beacon frames. AP810may respond with a TWT response to the TWT request confirming the wake TBTT and wake interval. After successfully completing the negotiation, STA811may enter a doze state until a first negotiated wake TBTT830. STA811may be in an awake state to listen to the beacon frame transmitted at first negotiated wake TBTT830. If STA811receives a beacon frame from AP810at or after TBTT830, STA811may 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 STA811. The STA811may return to the doze state after a nominal minimum TBTT wake duration time has elapsed from the TBTT start time.

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.

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

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.

FIG.9illustrates an example900of TWT protection in individual TWT operation. As shown inFIG.9, example900includes an AP910and a STA911.

In an example, AP910may 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, STA911may enter a doze state until the next TWT930. AP910that has set the TWT protection field to 1 may transmit a NAV setting frame at the start of the TWT SP920. For example, the NAV setting frame may be an RTS frame or a CTS frame.

A STA that receives the NV setting frame and that is not scheduled to access the medium during the TWT SP920may 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.

STA911may be scheduled to access the medium during the TWT SP920. STA911may respond to the RTS frame with a CTS frame. Upon receiving the CTS frame, AP910may transmit a downlink frame to STA911. STA911may respond to the downlink frame with a BA frame. When the TWT SP920ends, STA911may return to the doze state.

In the next Wi-Fi standard, a triggered TXOP sharing procedure may allow an AP to allocate a portion of the time within an obtained TXOP to a STA for transmitting one or more non-trigger-based (non-TB) PPDUs. For the triggered TXOP sharing procedure, the AP may transmit a multi-user request-to-send (MU-RTS) trigger frame with a TXOP sharing mode subfield set to a non-zero value. The MU-RTS Trigger frame is a trigger frame for triggering CTS frame(s) from multiple users.

In an example embodiment, an MU-RTS TXS (triggered TXOP sharing) trigger frame (MRTT) may indicate a TXOP sharing mode subfield set to a non-zero value.

In an example, during the portion of the allocated time, the STA may transmit the one or more non-TB PPDUs to the AP. In this case, a TXOP sharing mode subfield in an MU-RTS TXS trigger frame may be set to 1.

In an example, during the portion of the allocated time, the STA may transmit the one or more non-TB PPDUs to the AP or a peer STA. In an example, the peer STA may be a STA that may have a connection for a P2P communication or a direct communication with the STA. In this case, a TXOP sharing mode subfield in an MU-RTS TXS trigger frame may be set to 2.

FIG.10illustrates an example1000of a triggered TXOP sharing (TXS) procedure (Mode=1). As shown inFIG.10, the procedure may begin by an AP1010transmitting an MU-RTS TXS trigger (MRTT) frame1020to a STA1011. MRTT frame1020may allocate a portion of an obtained TXOP to STA1011and may indicate a triggered TXOP sharing mode equal to 1. STA1011receiving MRTT1020may use the allocated time duration to transmit one or more non-TB PPDUs1022,1024to AP1010.

In an example, MRTT frame1020may comprise a triggered TXOP sharing mode subfield and/or a first time period.

In an example, the first time period may indicate a portion of a time allocated by AP1010within an obtained TXOP. In an example, the first time period may be indicated by a subfield in MRTT frame1020. In an example, the first time period may be set to a value of X microseconds (us).

In an example, the triggered TXOP sharing mode subfield may be set to1. The triggered TXOP sharing mode subfield set to1may indicate that STA1011may transmit one or more non-TB PPDUs to AP1010during the first time period. The one or more non-TB PPDUs may comprise a data frame, a control frame, a management frame, or an action frame.

For example, as shown inFIG.10, MRTT frame1020may define a first time period of X us. STA1011may transmit non-TB PPDUs1022,1024comprising one or more data frame to AP1010during the first time period, preceded by a CTS frame1021. In an example, AP1010may transmit one or more Block Ack (BA) frames1023,1025in response to the one or more data frames contained in non-TB PPDUs1022,1024received from STA1011.

FIG.11illustrates an example1100of a TXS procedure (Mode=2). As shown inFIG.11, the procedure may begin by an AP1110transmitting an MRTT frame1120to a STA1111. MRTT frame1120may allocate a portion of an obtained TXOP to STA1111and may indicate a triggered TXOP sharing mode equal to 2. STA11111receiving MRTT1120may use the allocated time duration to transmit one or more non-TB PPDUs1122,1124to STA21112.

In an example, MRTT frame1120may comprise a triggered TXOP sharing mode subfield and/or a first time period.

In an example, the first time period may indicate a portion of a time allocated by AP1110within an obtained TXOP. In an example, the first time period may be indicated by a subfield in MRTT frame1120. In an example, the first time period may be set to a value of Y us.

In an example, the triggered TXOP sharing mode subfield may be set to 2. The triggered TXOP sharing mode subfield set to 2 may indicate that STA1111may transmit one or more non-TB PPDUs to AP1110or to a peer STA during the first time period. In an example, the peer STA may be a STA with a connection for P2P communication or direct communication with STA1111. The one or more non-TB PPDUs may comprise a data frame, a control frame, a management frame, or an action frame.

For example, as shown inFIG.11, MRTT frame1120may define a first time period of Y us. STA1111may transmit non-TB PPDUs1122,1124comprising one or more data frame to STA1112during the first time period, preceded by a CTS frame1121. In an example, STA1112may transmit one or more Block Ack (BA) frames1123,1124in response to the one or more data frames contained in non-TB PPDUs1122,1124received from the STA1011.

FIG.12is an example diagram of an MU-RTS trigger frame which may be used in a TXS procedure.

In an example, the MU-RTS trigger frame may comprise a frame control field, a duration field, a receiver address (RA) field, a transmitter address (TA) field, a common info field, a user info list field, a padding field, and/or frame check sequence (FCS) field.

In an example, the common info field may be a high-efficiency (HE) variant common info field or an extremely high throughput (EHT) variant common info field.

In an example, an EHT variant common info field may comprise one or more of the following subfields: trigger type, UL length/Allocation Duration, more TF, CS required, UL BW, GI and HE/EHT-LTF Type/Triggered TXOP sharing mode, number of HE/EHT-LTF symbols, LDPC extra symbol segment, AP Tx Power, Pre-FEC padding factor, PE disambiguity, UL spatial reuse, HE/EHT P160, special user info field flag, EHT reserved, reserved, or trigger dependent common info.

In an example, the trigger type subfield may indicate an MU-RTS trigger frame.

In an example, the GI and HE/EHT-LTF Type/Triggered TXOP sharing mode subfield may include a triggered TXOP sharing mode subfield (e.g., when the trigger type subfield indicates an MU-RTS trigger frame).

In an example, the triggered TXOP sharing mode subfield may be set to a non-zero value (e.g., 1 or 2).

In an example, the UL length/allocation duration subfield may include an allocation duration subfield (e.g., when the triggered TXOP sharing mode subfield is set to a non-zero value). The allocation duration subfield may indicate a time allocated by an AP transmitting the MU-RTS trigger frame. The allocated time may be a portion of the time of an obtained TXOP by the AP. In an example, the allocation duration subfield may be present in a user info field of the MU-RTS trigger frame instead of the common info field. In an example embodiment, the allocation duration subfield may indicate a first time period.

In an example, the triggered TXOP sharing mode subfield may indicate that a STA indicated by an AID12 subfield (of the user info list field) of the MU-RTS trigger frame may transmit one or more non-TB PPDUs to the AP during the time indicated by the allocation duration subfield. In this case, the triggered TXOP sharing mode subfield may be set to 1.

In an example, the triggered TXOP sharing mode subfield may indicate that a STA indicated by an AID12 subfield of the MU-RTS trigger frame may transmit one or more non-TB PPDUs to the AP or to a peer STA during the time indicated by the allocation duration subfield. In an example, the peer STA may be a STA with a connection for P2P communication or direct communication with the STA. In this case, the triggered TXOP sharing mode subfield may be set to 2.

In an example, the AID12 subfield of the MU-RTS trigger frame may indicate an association identifier (AID) of a STA that may use a time indicated by an allocation duration subfield of the MU-RTS trigger frame.

FIG.13is an example1300that illustrates an example TXS procedure between multi-link devices (MLDs). As shown inFIG.13, example1300includes an AP MLD1302and a non-AP MLD1304. An AP1302-1and an AP1302-2may be affiliated with AP MLD1302. A STA1304-1and a STA1304-2may be affiliated with non-AP MLD1304. STA1304-1may be associated with AP1302-1. AP1302-1and STA1304-1may communicate over a first link (link 1). STA1304-2may be associated with AP1302-2. AP1302-2and STA1304-2may communicate over a second link (link 2).

In an example, STA1304-1may transmit a CTS frame1308in response to MRTT frame1306on link 1. Subsequently, STA1304-1may transmit a data frame1310(e.g., in a non-TB PPDU) to AP1302-1on link 1 during the first time period. AP1302-1may transmit a blockack (BA) frame1313in response to data frame1310on link 1 during the first time period.

In an example, AP1302-2may transmit an MRTT frame1314to STA1304-2on link 2. MRTT frame1314may comprise a TXOP sharing mode subfield set to 1, an AID12 subfield set to an AID of STA1304-2, and/or a first time period (e.g., Y us, where Y is an integer value larger than 0).

In an example, STA1304-2may transmit a CTS frame1316in response to MRTT frame1314on link 2. Subsequently, STA1304-2may transmit a data frame1318(e.g., in a non-TB PPDU) to AP1302-2on link 2 during the first time period. AP1302-2may transmit a BA frame1320in response to data frame1318on link 2 during the first time period (e.g., Y us).

FIG.14is an example1400that illustrates an inefficient STA operation that may occur during a TXS procedure. As shown inFIG.14, example1400includes an AP1402and STAs1404,1406, and1408. STA1404may be associated with AP1402.

In an example, AP1402may allocate a portion of an obtained TXOP to STA1404by transmitting an MRTT frame1410. STA1404may transmit a CTS frame1412to AP1402in response to MRTT frame1410.

MRTT frame1410may comprise a TXOP sharing mode subfield, an AID12 subfield set to an AID of STA1404, and/or a first time period (e.g., X us).

In an example, the first time period may indicate a portion of time allocated by AP1402within an obtained TXOP. In an example, the first time period may be indicated by a subfield (e.g., an allocation duration field) in MRTT frame1410. In an example, the first time period may be set to a value of X us.

In an example, the TXOP sharing mode subfield is set to 2. The TXOP sharing mode subfield set to 2 indicates that STA1404may transmit one or more non-TB PPDUs to AP1402or to a peer STA during the first time period. In an example, the peer STA may be a STA having a connection for P2P communication or direct communication with STA1404. In an example, the peer STA may be STA1406. The one or more non-TB PPDUs may comprise a data frame, a control frame, a management frame, or an action frame. In example1400, STA1404may transmit a data frame1414to STA1406during the first time period. STA1406may transmit a BA frame1416to STA1404in response to data frame1414. STA1404may then transmit a data frame1418to STA1406. STA1406may respond to data frame1418with a BA frame1420.

According to existing technologies, after receiving MRTT frame1410, STA1408may be in an awake state during the first time period (X) indicated in MRTT frame1410. However, during this first time period, AP1402may not communicate with STA1408as STA1408is not allocated by MRTT frame1410. The awake power state of STA1408may thus result in power being unnecessarily wasted at STA1408.

Embodiments, as further described below, propose a STA power save mechanism during a TXS procedure. In an example embodiment, an AP may transmit a first frame indicating a TXS procedure. A STA that is not allocated by the first frame may transition to a doze state to save power during the TXS procedure.

FIG.15is an example1500that illustrates an example TXS power save (PS) mode according to an embodiment. As shown inFIG.15, example1500includes an AP1502and STAs1504,1506, and1508. One or more of STAs1504,1506, and1508may be associated with AP1502.

In an example, AP1510may transmit a first frame1510to allocate a portion of an obtained TXOP to STA1504. Frame1510may comprise a TXOP sharing mode subfield, an AID 12 subfield, and a first time period (e.g., X us). The TXOP sharing mode subfield may indicate a triggered TXOP sharing procedure. For example, the TXOP sharing mode subfield may be set to a non-zero value (e.g., 1, 2, . . . ) which indicates the triggered TXOP sharing mode 1 or the triggered TXOP sharing mode 2. The AID 12 subfield may be set to the AID of a STA that may use the first time period for transmitting and receiving one or more frame. For example, the AID 12 subfield field may be set to the AID of STA1504. The first time period may be specified in units of microseconds or some other unit of time. In an example, frame1510may be an MRTT frame.

In an example, STA1504may transmit a second frame1512to AP1502in response to frame1510. In an example, frame1512may be a CTS frame.

In an example, STA1504may subsequently transmit one or more non-TB PPDUs comprising one or more data frames1514and1518to STA1506during the first time period. In an example, STA1506may transmit one or more BA frames1516and1520to STA1504in response to data frames to STA1514and1518respectively.

In an embodiment, based on receiving frame1510which does not allocate STA1508during the first time period, STA1508may transition to a doze state. In an example embodiment, STA1508may transition to the doze state:after STA1508receives frame1510and before STA1508receives frame1512in response to frame1510;after STA1508receives frame1510in response to frame1510; orif STA1508does not receive a third frame during a second time period after STA1508receives frame1510.

In an example embodiment, the third frame may be a data frame, a control frame, or a management frame. A value of the second time period may be a fixed value or may be signaled by a fourth frame sent by AP1502. The fourth frame may be a beacon frame, a probe response frame, or an association response frame.

In an example embodiment, STA1508may support the triggered TXOP sharing procedure, a triggered TXOP sharing mode 1, a triggered TXOP sharing mode 2, and/or a triggered TXOP sharing power save mode. STA1508may be associated with AP1502. STA1508may maintain the doze state during a portion of the first time period after STA1508transitions to the doze state.

In an example embodiment, STA1508may be in an awake state at the end of the first time period or at least from the end of the first time period.

In an example embodiment, AP1502may not transmit a third frame to STA1508during the first time period. AP1510may transmit a third frame1522to STA1508after the first time period.

FIG.16is an example1600that illustrates an example TXS PS mode in a MLD environment according to an embodiment. As shown inFIG.16, example1600includes an AP MLD1602, a non-AP MLD1604, and a non-AP MLD1606. An AP1602-1and an AP1602-2may be affiliated with AP MLD1602. A STA1604-1and a STA1604-2may be affiliated with non-AP MLD1604. A STA1606-1and a STA1606-2may be affiliated with non-AP MLD1606. STA1604-1and STA1606-1may be associated with AP1602-1and may communicate with AP1602-1over a first link (link 1). STA1604-2and STA1606-2may be associated with AP1602-2and may communicate with AP1602-2over a second link (link 2).

In an example embodiment, AP1602-1may allocate a portion of an obtained TXOP to STA1604-1by transmitting on link 1 a frame1608comprising a TXOP sharing mode set to 1, an AID12 subfield set to an AID of STA1604-1, and/or a first time period (e.g., X us). In an example embodiment, STA1604-1may transmit on link 1 a frame1610to AP1602-1in response to frame1608.

In an example embodiment, AP1602-2may allocate a portion of an obtained TXOP to STA1604-2by transmitting on link 2 a frame1616comprising a TXOP sharing mode set to 1, an AID12 subfield set to an AID of STA1604-2, and/or a first time period (e.g., Y us). In an example embodiment, STA1604-2may transmit on link 2 a frame1618to AP1602-2in response to frame1616.

In an example embodiment, frames1610and1618may be CTS frames.

The TXOP sharing mode subfield set to 1 in frame1608(or frame1616) may indicate that a STA allocated by frame1608(or frame1616) may transmit one or more non-TB PPDUs to the AP transmitting frame1608(or frame1616). In an example, STA1604-1may transmit a data frame1612to AP1602-1on link 1, and STA1604-2may transmit a data frame1620to AP1602-2on link 2.

AP1602-1may transmit to STA1604-1a BA frame1614in response to data frame1612on link 1 during the first time period (X), and AP1602-2may transmit to STA1604-2a BA frame1622in response to data frame1620on link 2 during the first time period (Y).

In an example, STA1606-1and/or STA1606-2may support a triggered TXOP sharing procedure, a TXOP sharing mode 1, a TXOP sharing mode 2, and/or a triggered TXOP sharing mode power save mode.

In an example, STA1606-1may transition to the doze state after STA1606-1receives, on link 1, frame1608and frame1610sent in response to frame1608.

In an example, STA1606-2may transition to the doze state after STA1606-2receives, on link 2, frame1616and frame1618sent in response to frame1616.

STA1606-1may maintain the doze state during a portion of the first time period (X) after STA1606-1transitions to the doze state. STA1606-2may maintain the doze state during a portion of the first time period (Y) after STA1606-2transitions to the doze state.

FIG.17illustrates an example MAC capability field which may be used according to embodiments. The MAC capability field may be a High Efficiency (HE) MAC capability field. The MAC capability field may be included in a request frame or a response frame. As shown inFIG.17, the MAC capability field may include, among other subfields, a triggered TXOP sharing mode 1 support subfield, a triggered TXOP sharing mode 2 support subfield, and a TXS PS mode support subfield.

In an example embodiment, a STA may transmit to an AP a request frame comprising a MAC capability field as shown inFIG.17. The request frame may comprise:a first parameter indicating support for the STA to respond to a frame (e.g., MRTT frame) with a TXOP sharing mode equal to 1;a second parameter indicating support for the STA to respond to a frame (e.g., MRTT frame) with a TXOP sharing mode equal to 2; and/ora third parameter indicating support by the STA of a TXS power save mode.

In an example embodiment, the STA may receive, in response to the request frame from the AP, a response frame comprising:a fourth parameter indicating support for the AP to transmit a frame (e.g., MRTT frame) with a TXOP sharing mode equal to 1;a fifth parameter indicating support for the AP to transmit a frame (e.g., MRTT frame) with a TXOP sharing mode equal to 2; and/ora sixth parameter indicating support by the AP of the TXS power save mode.

The request frame may be a probe request frame or an association request frame. The response frame may be a probe response frame or an association response frame.

The first parameter set to1may indicate that the STA may be capable of responding to a frame that allocates time to the STA to transmit non-TB PPDUs to the AP. The second parameter set to 1 may indicate that the STA may be capable of responding to a frame that allocates time to the STA to transmit non-TB PPDUs to the AP or the peer STA. The third parameter set to 1 may indicate that the STA supports TXS power save mode as described herein. For example, the third parameter set to 1 indicates that the STA may transition to a doze state during a portion of a first time period indicated in a frame (e.g., MRTT frame) from the AP. The STA may transition to the doze state after the STA receives the frame or a subsequent frame transmitted in response to the frame.

The fourth parameter set to 1 may indicate that the AP may be capable of transmitting a frame that allocates time to a STA to transmit non-TB PPDUs to the AP. The fifth parameter set to 1 may indicate that the AP may be capable of transmitting a frame that allocates time to a STA to transmit non-TB PPDUs to the AP or to a peer STA. The sixth parameter set to 1 may indicate that the AP supports TXS power save mode as described herein. For example, the sixth parameter set to 1 indicates that the AP may not transmit any frame to STAs supporting the TXS power save mode during a first time period indicated in a frame (e.g., MRTT frame) transmitted by the AP.

FIG.18illustrates an example process1800according to an embodiment. Example process1800may be performed by a STA.

In step1810, the STA may receive from an AP a first frame indicating a first time period, an AID, and a TXOP sharing (TXS) mode.

In step1820, the STA may determine that the first time period is not allocated to the STA based on the AID indicated in the first frame being different from an AID of the STA.

In step1830, the STA may transition a power state of the STA to a doze state based on the determining and the TXOP sharing mode.

In step1840, the STA may maintain the doze state during at least a portion of the first time period.

In an example embodiment, the STA may be in an awake state at the end of the first time period or at least from the end of the first time period.

In an example embodiment, the STA may transmit to the AP a request frame comprising:a first parameter indicating support for the STA to respond to the first frame with the TXOP sharing mode equal to 1;a second parameter indicating support for the STA to respond to the first frame with the TXOP sharing mode equal to 2; and/ora third parameter indicating support by the STA of a TXS power save mode.

In an example embodiment, the STA may receive, in response to the request frame from the AP, a response frame comprising:a fourth parameter indicating support for the AP to transmit the first frame with the TXOP sharing mode equal to 1.a fifth parameter indicating support for the AP to transmit the first frame with the TXOP sharing mode equal to 2; ora sixth parameter indicating support by the AP of the TXS power save mode.

In an example embodiment, the request frame may be a probe request frame or an association request frame.

In an example embodiment, the response frame may be a probe response frame or an association response frame.

In an example embodiment, the first parameter set to 1 indicates that the STA may be capable of responding to the first frame that allocates time to the STA to transmit non-TB PPDUs to the AP.

In an example embodiment, the second parameter set to 1 indicates that the STA may be capable of responding to the first frame that allocates time to the STA to transmit non-TB PPDUs to the AP or the peer STA.

In an example embodiment, the fourth parameter set to 1 indicates that the AP may be capable of transmitting the first frame that allocates time to a STA to transmit non-TB PPDUs to the AP.

In an example embodiment, the fifth parameter set to 1 indicates that the AP may be capable of transmitting the first frame that allocates time to the STA to transmit non-TB PPDUs to the AP or the peer STA.

In an example embodiment, the second parameter or the fifth parameter may be provided in a triggered TXOP sharing (TXS) mode 2 support subfield.

In an example embodiment, the third parameter or the sixth parameter may be provided in a TXS PS mode support subfield.

In an example embodiment, the first parameter, the second parameter, and/or the third parameter may be comprised in an HE MAC capability field of the request frame.

In an example embodiment, the fourth parameter, the fifth parameter, and/or the sixth parameter may be comprised in an HE MAC capability field of the response frame.

In an example embodiment, the STA may transition to the doze state:after the STA receives the first frame and before the STA receives a second frame in response to the first frame;after the STA receives a second frame in response to the first frame; orif the STA does not receive a third frame during a second time period after the STA receives the first frame.

In an example embodiment, the second frame may be a clear-to-send (CTS) frame. In an example embodiment, the second frame may be received SIFS after the first frame.

In an example embodiment, a value of the second time period may be a fixed value or may be signaled by a fourth frame sent by the AP. In an example, the fourth frame may be a beacon frame, a probe response frame, or an association response frame.

In an example embodiment, the third frame may be a data frame, a control frame, or a management frame.

In an example embodiment, the STA may support the triggered TXOP sharing procedure or the TXS power save mode.

In an example embodiment, the STA may support the triggered TXOP sharing mode 1 or the triggered TXOP sharing mode 2.

In an example embodiment, the first frame may be an MRTT frame. A TXOP sharing mode subfield of the MRTT frame may be set to a non-zero value.

In an example embodiment, the first time period may be indicated by an allocation duration subfield of the first frame.

In an example embodiment, the AID indicated in the first frame may be an association identifier of a STA that may be assigned by the AP during an association procedure.

In an example embodiment, the AID indicated in the first frame may be indicated by an AID12 subfield of the first frame.

In an example embodiment, the triggered TXOP sharing procedure may be that the AP may allocate the first time period within an obtained TXOP to the first STA.

In an example embodiment, the TXOP sharing mode may be set to non-zero value (e.g., 1 or 2).

In an example embodiment, the TXOP sharing mode set to 1 may indicate that the first STA may transmits PPDU(s) addressed to the AP.

In an example embodiment, the TXOP sharing mode set to 2 may indicate that the first STA may transmit PPDU(s) addressed to the AP or addressed to another STA.

In an example embodiment, the AP may be affiliated with an AP multi-link device (MLD).

In an example embodiment, the STA may be affiliated with a non-AP multi-link device (MLD).

FIG.19illustrates an example process1900according to an embodiment. Example process1900may be performed by an AP.

In step1910, the AP may transmit to a first STA a first frame (e.g., MRTT frame) indicating a first time period, an AID of the first STA, and a TXOP sharing (TXS) mode (e.g., non-zero value).

In step1920, the AP may receive from the first STA a second frame (e.g., CTS frame) in response to the first frame.

In step1930, the AP may not transmit to a second STA a third frame (e.g., a data frame) during the first time period based on an indication, from the second STA, of support by the second STA of a TXS power save mode.

In step1940, the AP may transmit to a third STA a third frame (e.g., a data frame) during the first time period. In an example, the third STA may be a STA that does not indicate to the AP support by the third STA of the TXS power save mode. The third STA may not support the triggered TXOP sharing procedure or the TXS power save mode, or may be a legacy STA. In an example embodiment, the legacy STA may be a non-high throughput (non-HT) STA, a high throughput (HT) STA, a very high throughput (VHT) STA or a high efficiency (HE) STA.

In step1950, the AP may transmit to the second STA a fourth frame (e.g., a data frame) after the first time period.

In an example embodiment, if the AP receives the second frame a SIFS after the AP transmits the first frame, the AP may not transmit to the second STA a third frame during the first time period based on an indication, from the second STA, of support by the second STA of a TXS power save mode.

In an example embodiment, the first time period may be allocated to the third STA.

In an example embodiment, the first STA, the second STA or the third STA may be associated with the AP.

In an example embodiment, the first time period may be allocated to the first STA or may not be allocated to the second STA.

In an example embodiment, the second STA may support the triggered TXOP sharing procedure or the TXS power save mode.

In an example embodiment, the AP may be affiliated with an AP multi-link device (MLD). In an example embodiment, the first STA may be affiliated with a non-AP multi-link device (MLD). In an example embodiment, the second STA may be affiliated with a non-AP MLD.

FIG.20illustrates an example process2000according to an embodiment. Example process2000may be performed by a STA. In an embodiment, the STA is affiliated with a non-AP multi-link device (MLD).

As shown inFIG.20, in step2002, process2000includes receiving, by the STA from an AP, a first frame indicating a first time period and an association identifier (AID). In an embodiment, the first frame further indicates a triggered transmission opportunity (TXOP) sharing (TXS) mode.

In step2004, process2000includes transitioning, by the STA, a power state of the STA to a doze state based on the AID (indicated in the first frame) being different from an AID of the STA.

In an embodiment, transitioning the power state of the STA to the doze state is further based on the TXS mode having a non-zero value.

In an embodiment, transitioning the power state of the STA to the doze state comprises transitioning the power state of the STA to the doze state after receiving the first frame but before receiving a second frame transmitted in response to the first frame.

In an embodiment, transitioning the power state of the STA to the doze state comprises transitioning the power state of the STA to the doze state after receiving a second frame transmitted in response to the first frame.

In an embodiment, transitioning the power state of the STA to the doze state comprises transitioning the power state of the STA to the doze state based on not receiving a second frame during a second time period after receiving the first frame.

In an embodiment, process2000further comprises maintaining the power state in the doze state during at least a portion of the first time period.

In an embodiment, the first frame is an MRTT frame.

In an embodiment, the first time period is of a TXOP obtained by the AP.

In an embodiment, the AID indicated in the first frame is equal to an AID of a first STA associated with the AP. In an embodiment, the first time period is indicated by an allocation duration subfield of the first frame.

In an embodiment, process2000may further comprise transmitting, by the STA to the AP, a request frame comprising a first parameter indicating support by the STA for a TXS power save (PS) mode.

In an embodiment, process2000may further comprise receiving, by the STA from the AP, a response frame comprising a second parameter indicating support by the AP for the TXS PS mode.

FIG.21illustrates an example process2100according to an embodiment. Example process2100may be performed by an AP. In an embodiment, the AP is affiliated with an AP multi-link device (MLD).

As shown inFIG.21, in step2102, process2100includes transmitting, by the AP, a first frame indicating a first time period and an AID of a first STA. In an embodiment, the first frame further indicates a triggered transmission opportunity (TXOP) sharing (TXS) mode. In an embodiment, the TXS mode has a non-zero value. In an embodiment, the first frame is an MRTT frame.

In an embodiment, process2100may further comprise receiving, by the AP from the first STA, a second frame in response to the first frame.

In step2104, process2100includes transmitting, by the AP to a second STA, a second frame after the first time period, based on an indication from the second STA of support of a TXS power save mode.

In an embodiment, process2100may further comprise not transmitting a frame to the second STA during the first time period. The non-transmission of a frame during the first time period to the second STA may be based on the capability of the second STA to enter a doze state during the first time period (based on the second STA not being allocated by the first frame).

In an embodiment, process2100may further comprise transmitting a third frame to a third STA during the first time period. The third STA may be a STA that does not support the TXS PS mode. The third STA may thus remain awake during the first time period.

In an embodiment, the first time period is of a TXOP obtained by the AP. In an embodiment, the first time period is indicated by an allocation duration subfield of the first frame.

In an embodiment, process2100may further comprise receiving, by the AP from the second STA, a request frame comprising a first parameter indicating support by the second STA for the TXS PS mode.

In an embodiment, process2100may further comprise transmitting, by the AP to the second STA, a response frame comprising a second parameter indicating support by the AP for the TXS PS mode.