Indicating station unavailability after transmission opportunity sharing

Abstract

A station (STA) transmits, to an access point (AP), a first frame indicating a power state transition. The STA transmits, to the AP, a second frame, sharing with the AP a transmit opportunity (TXOP) obtained by the STA. Based on the power state transition, the STA transitions from a first power state to a second power state, for a remaining portion of the TXOP.

Description

TITLEINDICATING STATION UNAVAILABILITY AFTER TRANSMISSION OPPORTUNITY SHARINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 626,131, filed January 29, 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 multi-user request-to-send (MU-RTS) transmit opportunity (TXOP) sharing (TXS) trigger (MRTT) frame which may be used in a TXS procedure.

[0006] FIG. 4 illustrates an example data frame which may be used as a QoS null frame.

[0007] FIG. 5 illustrates an example management frame which may be used as an action frame.

[0008] FIG. 6 illustrates an example of a TXS procedure.

[0009] FIG. 7 illustrates another example of a TXS procedure.

[0010] FIG. 8 is an example that illustrates an inefficient STA operation that may occur during a TXS procedure.

[0011] FIG. 9 is an example that illustrates an example TXS power save (PS) mode that may be used to address potential waste during some awake states.

[0012] FIG. 10 illustrates an example, where the frame that indicates enabling or disabling of the TXS PS mode at the STA may be an association request frame or a reassociation request frame.

[0013] FIG. 11 illustrates an example where a STA transmits an association request frame to an AP.

[0014] FIG. 12 illustrates an example of existing operation whereby a TXOP acquired by a non-AP STA is shared with an AP.

[0015] FIG. 13 illustrates an example of one or more embodiments that may utilize a power saving operation during an operation where the STA shares a TXOP with an AP.

[0016] FIG. 14 illustrates an example of one or more embodiments that may provide STA unavailability information to an AP that receives TXOP sharing from a STA.

[0017] FIG. 15 illustrates an example of one or more embodiments that may provide STA unavailability information to an AP that receives TXOP sharing from a STA.

[0018] FIG. 16 illustrates an example of one or more embodiments that may provide STA unavailability information to an AP that receives TXOP sharing from a STA.

[0019] FIG. 17 illustrates an example process performed by a STA according to an embodiment.

[0020] FIG. 18 illustrates an example process performed by an AP according to an embodiment.DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

[0029] FIG. 1 illustrates example 100 wireless communication networks in which embodiments of the present disclosure may be implemented. As shown in FIG. 1, the example wireless communication networks may include an Institute of Electrical and Electronic Engineers (IEEE) 802.11 Wireless Local-Area Network (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0047] FIG. 3 illustrates an example multi-user request-to-send (MU-RTS) transmit opportunity (TXOP) sharing (TXS) trigger (MRTT) frame 300 which may be used in a TXS procedure. As shown in FIG. 3, example MRTT frame 300 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.

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

[0049] The trigger type subfield indicates that frame 300 is an MRTT frame.

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

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

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

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

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

[0055] FIG. 4 illustrates an example data frame 400 which may be used as a QoS null frame. A QoS null frame refers to a QoS data frame with an empty frame body. QoS null frame includes a QoS control field and an optional HT control field which may contain a buffer status report (BSR) control subfield. A QoS null frame indicating buffer status information may be transmitted by a STA to an AP.

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

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

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

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

[0060] In a frame sent by or to a non-high efficiency (non-HE) STA, the following rules may apply to the queue size value:

[0061] The queue size value is the approximate total size, rounded up to the nearest multiple of 256 octets and expressed in units of 256 octets, of all MSDUs and A-MSDUs buffered at the STA (excluding the MSDU or A-MSDU contained in the present QoS Data frame) in the delivery queue used for MSDUs and A-MSDUs with TID values equal to the value indicated in the TID subfield of the QoS Control field.

[0062] A queue size value of 0 is used solely to indicate the absence of any buffered traffic in the queue used for the specified TID.

[0063] A queue size value of 254 is used for all sizes greater than 64768 octets.

[0064] A queue size value of 255 is used to indicate an unspecified or unknown size.

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

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

[0067] The queue size subfield includes a scaling factor subfield in bits B14-B15 of the QoS control field and an unsealed value, UV, in bits B8-B13 of the QoS control field. The scaling factor subfield provides the scaling factor, SF.

[0068] A STA obtains the queue size, QS, from a received QoS control field, which contains a scaling factor, SF, and an unsealed value, UV, as follows:

[0069] QS =

[0070] 16 xW, if SF is equal to 0;

[0071] 1024 +256 x Ul / , if SF is equal to 1;

[0072] 17408 +2048 x UV, if SF is equal to 2;

[0073] 148480 + 32768 x UV, if SF is equal to 3 and UV is less than 62;

[0074] > 2 147328, if SF equal to is 3 and UV is equal to 62;

[0075] Unspecified or Unknown, if SF is equal to 3 and UV is equal to 63.

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

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

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

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

[0080] The delta Tl D subfield, together with the values of the ACI bitmap subfield, indicate the number of Tl Ds for which the STA is reporting the buffer status.

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

[0082] The scaling factor subfield indicates the unit SF, in octets, of the queue size high and queue size all subfields.

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

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

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

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

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

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

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

[0090] The action field includes a category field and an action details field. The action field provides a mechanism for specifying extended management actions. The category field indicates a category of the action frame. The action details field contains the details of the action requested by the action frame.

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

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

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

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

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

[0096] STA 611 may respond to MRTT frame 620 by transmitting a clear-to-send (CTS) frame 621 to AP 610. Subsequently, STA 611 may transmit non-TB PPDUs 622, 624 comprising one or more data frames to AP 610 during the first time period indicated in MRTT frame 620. In an example, AP 610 may transmit one or more blockacknowledgement (BA) frames 623, 625 in response to the one or more data frames contained in non-TB PPDUs 622, 624 received from STA 611.

[0097] FIG. 7 illustrates an example 700 of a TXS procedure (e.g., sharing mode=2). As shown in FIG. 7, the TXS procedure may begin by an AP 710 transmitting an MRTT frame 720 to a STA 711. MRTT frame 720 may allocate a portion of a TXOP obtained by AP 710 to STA 711 and may indicate a TXS mode equal to 2. STA 711 receiving MRTT frame 720 may use the allocated time to transmit one or more non-TB PPDUs to STA 712. The one or more non-TB PPDUs may comprise a data frame, a control frame, a management frame, or an action frame.

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

[0099] STA 711 may respond to MRTT frame 720 by transmitting a GTS frame 721 to AP 710. Subsequently, STA 711 may transmit non-TB PPDUs 722, 724 comprising one or more data frame to STA 712 during the first time period indicated in MRTT frame 720. In an example, STA 712 may transmit one or more BA frames 723, 725 in response to the one or more data frames contained in non-TB PPDUs 722, 724 received from STA 711.

[0100] FIG. 8 is an example 800 that illustrates an inefficient STA operation that may occur during a TXS procedure. As shown in FIG. 8, example 800 includes an AP 802 and STAs 804, 806, and 808. STA 804 may be associated with AP 802.

[0101] In an example, AP 802 may allocate a portion of an obtained TXOP to STA 804 by transmitting an MRTT frame 810. STA 804 may transmit a GTS frame 812 to AP 802 in response to MRTT frame 810.

[0102] MRTT frame 810 may comprise a TXOP sharing mode subfield, an AID12 subfield set to an AID of STA 804, and / or a first time period (e.g., X us).

[0103] In an example, the first time period may indicate a portion of time allocated by AP 802 within an obtained TXOP. In an example, the first time period may be indicated by a subfield (e.g., an allocation duration field) in MRTT frame 810. In an example, the first time period may be set to a value of X us.

[0104] In an example, the TXOP sharing mode subfield is set to 2. The TXOP sharing mode subfield set to 2 indicates that STA 804 may transmit one or more non-TB PPDUs to AP 802 or 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 STA 804. In an example, the peer STA may be STA 806. The one or more non-TB PPDUs may comprise a data frame, a control frame, a management frame, or an action frame. In example 800, STA 804 may transmit a data frame 814 to STA 806 during the first time period. STA 806 may transmit a BA frame 816 to STA 804 in response to data frame 814. STA 804 may then transmit a data frame 818 to STA 806. STA 806 may respond to data frame 818 with a BA frame 820.

[0105] After receiving MRTT frame 810, STA 808 may be in an awake state during the first time period (X) indicated in MRTT frame 810. However, during this first time period, AP 802 may not communicate with STA 808 as STA 808 is not allocated by MRTT frame 810. The awake power state of STA 808 may thus result in power being unnecessarily wasted at STA 808.

[0106] FIG. 9 is an example 900 that illustrates an example TXS PS (PS) mode that may be used to address potential waste during some awake states. As shown in FIG. 9, example 900 includes an AP 902 and STAs 904, 906, and 908. One or more of STAs 904, 906, and 908 may be associated with AP 902.

[0107] As shown in FIG. 9, example 900 may begin with AP 902 transmitting a first frame 910 to allocate a portion of an obtained TXOP to STA 904. Frame 910 may 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 STA 904. The first time period may be specified in units of microseconds or some other unit of time. In an example, frame 910 may be an MRTT frame.

[0108] On receiving frame 910, STA 904 may transmit a second frame 912 to AP 902. In an example, frame 912 may be a GTS frame. STA 904 may subsequently transmit one or more non-TB PPDUs comprising one or more data frames 914 and 918 to STA 906 during the first time period. STA 906 may transmit one or more BA frames 916 and 920 to STA 904 in response to data frames 914 and 918, respectively.

[0109] In an implementation, based on receiving frame 910 which does not allocate STA 908 during the first time period, STA 908 may transition to a doze state. In an example, STA 908 may transition to the doze state: after STA 908 receives frame 910 and before STA 908 receives frame 912 in response to frame 910; after STA 908 receives frame 912 in response to frame 910; or if STA 908 does not receive a third frame during a second time period after STA 908 receives frame 910.

[0110] 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 AP 902. The fourth frame may be a beacon frame, a probe response frame, or an association response frame.

[0111] In an implementation, STA 908 may maintain the doze state during a portion of the first time period after STA 908 transitions to the doze state. In an implementation, STA 908 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.

[0112] In an implementation, AP 902 may not transmit a third frame 922 to STA 908 during the first time period. AP 902 may transmit third frame 922 to STA 908 after the first time period.

[0113] In an implementation, AP 902 and STA 908 may exchange indications of support of the TXS Power save (PS) mode prior to the beginning of example 900. For example, STA 908 may include an indication of support of the TXS PS mode in an association request frame to AP 902. STA 908 may set a TXS PS mode field (or a TXS PS Support field) to 1 in the association request frame to indicate support of the TXS PS mode. The TXS PS mode field (or TXS PS Support field) may be provided in an EHT MAC Capabilities Information field of the association request frame. AP 902 may include an indication of support of the TXS PS mode in an association response frame to STA 908. STA 908 may set a TXS PS mode field (or a TXS PS Support field) to 1 in the association response frame to indicate support of the TXS PS mode.The TXS PS mode field (or TXS PS Support field) may be provided in an EHT MAC Capabilities Information field of the association response frame.

[0114] In an implementation, when STA 908 indicates support of the TXS PS mode (e.g., TXS PS field set to 1 in the association request frame to AP 902), AP 902 may refrain from transmitting to STA 908 during the first time period (in which STA 908 is not allocated) because STA 908 may enter the doze state during the first time period (even if STA 908 does not actually enter the doze state during the first time period). AP 902 may continue to use this behavior with respect to STA 908 for any subsequent TXS time period during which STA 908 is not allocated. That is, based on STA 908 having indicated support of the TXS PS mode, AP 902 may not transmit to STA 908 during TXS time periods in which STA 908 is not allocated.

[0115] Recently, however, it has been proposed in the 902.11be standard amendment that a STA may return to the AP any remaining time of a time period allocated to the STA (in TXS sharing mode 2) after the STA has finished transmitting its buffered traffic. The AP may use the remaining time of the time period to transmit downlink traffic or may allocate a portion of the remaining time to another STA. For example, referring to FIG. 9, assuming that STA 904 has no more traffic to transmit after transmitting data frame 918, STA 904 may return the remaining time of the first time period after receiving BA frame 920 from STA 906. AP 902 may use the remaining time of the first time period to transmit downlink traffic (e.g., to STA 906 or 908) or may allocate a portion of the remaining time (e.g., to STA 906 or 908). According to the IEEE 802.11 be standard amendment, an AP that supports this “TXOP Return” feature may transmit to an associated STA an EHT MAC Capabilities Information field with a “TXOP Return Support In TXOP Sharing Mode 2” subfield set to 1. This indicates that the AP supports receiving from a STA allocated in TXS sharing mode 2, a frame (e.g., QoS Data or QoS Null frame) that includes an HE variant HT Control field with a CAS Control subfield with the RDG / More PPDU subfield equal to 0. The AP may transmit a PPDU a SIFS after receiving the frame with the CAS Control subfield. Conversely, a STA that receives an MRTT frame with the TXOP sharing mode subfield equal to 2 may transmit, within an allocated time, a QoS Data or QoS Null frame that includes an HE variant HT Control field with a CAS Control subfield with the RDG / More PPDU subfield equal to 0 to the associated AP from which it has received an EHT Capabilities element with the “TXOP Return Support In TXOP Sharing Mode 2” subfield set to 1.

[0116] But, according to existing behavior, an AP may not use returned remaining time of a time period to transmit to, or to allocate a portion of the remaining time to, a STA that indicated support of the TXS PS mode and that was not allocated in the time period. Indeed, as described above, when a STA indicates support of the TXS PS mode and is not allocated during a time period, the AP may not transmit to the STA during the time period because the STA may enter the doze state during the time period. For example, referring to FIG. 9, assuming that STA 908 indicated support of the TXS PS mode to AP 902 (e.g., TXS PS field set to 1 in an association request frame to AP 902), AP 902 may not transmit to STA 908 during the first time period (in which STA 908 is not allocated) even if STA 904 were to return the remaining time of the first time period to AP 902 after receiving BA frame 920. Similarly, AP 902 may not allocate a portion of the returned remaining time to STA 908. This may occur even when STA 908 does not enter the doze state during the first time period.

[0117] This behavior may lead to inefficiencies as the AP may be limited in the ways it may use returned remaining time of a TXS time period. For example, the AP may have buffered downlink traffic for a STA that was not allocated in the TXS time period and that has indicated support of the TXS PS mode. Although the STA may be in the awake state during the TXS time period, the AP must wait until the end of the TXS time period before it may transmit the buffered downlink traffic to the STA. In another example, the AP may wish to share a portion of the returned remaining time with the STA. But as the AP may not transmit to the STA during the TXS time period, the AP may not send the time allocation to the STA even though the STA may be in the awake state during the TXS time period.

[0118] FIG. 10 illustrates an example 1000, where the frame that indicates enabling or disabling of the TXS PS mode at the STA may be an association request frame or a reassociation request frame. As shown in FIG. 10, example 1000 includes an AP 1002 and STAs 1004, 1006, and 1008. One or more of STAs 1004, 1006, and 1008 may be associated with AP 1002. STAs 1004, 1006, and / or 1008 may support the TXS PS mode as described above.

[0119] As shown in FIG. 10, example 1000 may begin with STA 1008 transmitting an association (or reassociation) request frame 1010 to AP 1002. In an example, association request frame 1010 may comprise a TXS PS mode field (or a TXS PS Support field). In example 1000, the TXS PS mode field (or TXS PS Support field) may be set to 1 to indicate enabling of the TXS PS mode at STA 1008. The TXS PS mode field (or TXS PS Support field) may be provided in an EHT MAC Capabilities Information field of the association request frame. AP 1002 may respond to association request frame 1010 by transmitting an association response frame 1012 to STA 1008. In an example, association response frame 1012 may comprise a TXS PS mode field (or a TXS PS Support field). In example 1000, the TXS PS mode field (or TXS PS Support field) may be set to 1 to indicate support of the TXS PS mode at AP 1002. The TXS PS mode field (or TXS PS Support field) may be provided in an EHT MAC Capabilities Information field of the association response frame.

[0120] Subsequently, AP 1002 may transmit a frame 1014 to allocate a portion of an obtained TXOP to STA 1004. Frame 1014 may 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 STA 1004. The first time period may be specified in units of microseconds or some other unit of time. In an example, frame 1014 may be an MRTT frame.

[0121] On receiving frame 1014, STA 1004 may transmit a frame 1016 to AP 1002. In an example, frame 1016 may be a CTS frame. STA 1004 may subsequently transmit a non-TB PPDU comprising a data frame 1018 to STA 1006 during the first time period. STA 1006 may transmit a BA frame 1020 to STA 1004 in response to data frame 1018.

[0122] Based on receiving frame 1014 which does not allocate STA 1008 during the first time period, and the TXS PS mode being enabled at STA 1008, STA 1008 may transition to a doze state during the first time period. In accordance with the TX PS mode, STA 1008 may transition to the doze state: after STA 1008 receives frame 1014 and before STA 1008 receives frame 1016 in response to frame 1014; after STA 1008 receives frame 1016 in response to frame 1014;or if STA 1008 does not receive a third frame during a second time period after STA 1008 receives frame 1014. 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 AP 1002. The fourth frame may be a beacon frame, a probe response frame, or an association response frame.

[0123] In an implementation, STA 1008 may maintain the doze state during a portion of the first time period after STA 1008 transitions to the doze state. In an implementation, STA 1008 may return to an awake state at the end of the first time period or at least from the end of the first time period. In an implementation, AP 1002 may not transmit a frame to STA 1008 during the first time period. AP 1002 may transmit a frame to STA 1008 after the first time period. In an example (not shown in FIG. 10), AP 1002 may receive from STA 1004, within the first time period, a frame indicating release or return of a remaining time of the first time period. The frame may comprise a QoS Data frame or a QoS Null frame that includes an HE variant HT Control field with a CAS Control subfield with the RDG / More PPDU subfield equal to 0. Based on the TXS PS mode being enabled at STA 1008, AP 1002 may wait for an end of the remaining time before transmitting a frame to STA 1008. In an example, AP 1002 may use the remaining time to transmit a frame to STA 1004 or STA 1006 (assuming STA 1004 or STA 1006 is in the awake state) or to another STA (not shown in FIG. 10, e.g., a legacy STA that does not support TXS PS mode). In another example, AP 1002 may allocate a portion of the remaining time to STA 1006.

[0124] In example 1000, STA 1008 may return to the awake state after the end of the first time period or at least from the end of the first time period. Subsequently, STA 1008 may transmit an association (or reassociation) request frame 1022 to AP 1002. In an example, association request frame 1022 may comprise a TXS PS mode field (or a TXS PS Support field). In example 1000, the TXS PS mode field (or TXS PS Support field) may be set to 0 to indicate disabling of the TXS PS mode at STA 1008. The TXS PS mode field (or TXS PS Support field) may be provided in an EHT MAC Capabilities Information field of association request frame 1022. AP 1002 may respond to association request frame 1022 by transmitting an association response frame 1024 to STA 1008. In an example, association response frame 1024 may comprise a TXS PS mode field (or a TXS PS Support field). In example 1000, the TXS PS mode field (or TXS PS Support field) may be set to 1 to indicate support of the TXS PS mode at AP 1002. The TXS PS mode field (or TXS PS Support field) may be provided in an EHT MAC Capabilities Information field of the association response frame.

[0125] Subsequently, AP 1002 may transmit a frame 1026 to allocate a portion of an obtained TXOP to STA 1004. Frame 1026 may 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 STA 1004. The first time period may be specified in units of microseconds or some other unit of time. In an example, frame 1026 may be an MRTT frame.

[0126] On receiving frame 1026, STA 1004 may transmit a frame 1028 to AP 1002. In an example, frame 1016 may be a GTS frame. STA 1004 may subsequently transmit a non-TB PPDU comprising a data frame 1030 to STA 1006 during the first time period. STA 1006 may transmit a BA frame 1032 to STA 1004 in response to data frame 1030.

[0127] On receiving frame 1026 which does not allocate STA 1008 during the first time period, and based on the TXS PS mode being disabled at STA 1008, STA 1008 may remain in the awake state during the first time period. In an example (not shown in FIG. 10), AP 1002 may receive from STA 1004, within the first time period, a frame indicating release or return of a remaining time of the first time period. The frame may comprise a QoS Data frame or a QoS Null frame that includes an HE variant HT Control field with a CAS Control subfield with the RDG / More PPDU subfield equal to 0. In an example, based on the TXS PS mode being disabled at STA 1008, AP 1002 may transmit a frame to STA 1008 during the remaining time of the first time period. In another example, based on the TXS PS mode being disabled at STA 1008, AP 1002 may allocate a portion of the remaining time to STA 1008. STA 1008 may use the allocated portion of the remaining time to transmit to AP 1002 or to another STA depending on the indicated TXS mode.

[0128] An advantage of example 1000 is that it reuses existing (re)association request / response frames (with minor modification) to enable a STA to signal enabling or disabling of the TXS mode to an AP. However, as (re)association request / response frames may be potentially large in size due to containing information regarding various capabilities supported by the STA / AP, example 1000 may result in increased signaling overhead. The construction of (re)association request / response frames may also require relatively large processing times at the STA / AP. The signaling by the STA, and the acknowledgment by the AP, of a TXS PS mode state change at the STA may thus require a substantial amount of time, leading to sub-optimal operation.

[0129] FIG. 11 illustrates an example that may begin with STA 1108 transmitting an association (or reassociation) request frame 1110 to AP 1102. In an example, association request frame 1110 may comprise a TXS PS mode field (or a TXS PS Support field). In example 1100, the TXS PS mode field (or TXS PS Support field) may be set to 1 to indicate support of the TXS PS mode by STA 1108. The TXS PS mode field (or TXS PS Support field) may be provided in an EHT MAC Capabilities Information field of association request frame 1110.

[0130] In an implementation, support of the TXS PS mode by STA 1108 may include STA 1108 being able to perform a TXS PS mode operation in a defined condition. In an implementation, the TXS PS mode operation may comprise STA 1108 entering a doze state during a time period of a TXOP. The defined condition may comprise STA 1108 not being allocated by AP 1102 during the time period of the TXOP. In an implementation, support of the TXS PS mode by STA 1108 may include STA 1108 being able to transmit to an AP a frame indicating enabling or disabling of the TXS PS mode as described herein. In an example, the frame may include a TXS PS (TPS) Control subfield (further described below) that indicates enabling or disabling of the TXS PS mode at STA 1108. The TPS Control subfield may include a TPS Disabling subfield that carries the indication of enabling or disabling of the TXS PS mode at STA 1108. In an implementation, support of the TXS PS mode by STA 1108 may include STA 1108 being capable of entering the doze state during a TXS time period that is not allocated to STA 1108 (e.g., by an MRTT frame) when STA 1108 sets the TPS Disabling subfield to 0.

[0131] AP 1102 may respond to association request frame 1110 by transmitting an association response frame 1112 to STA 1108. In an example, association response frame 1112 may comprise a TXS PS mode field (or a TXS PS Support field). In example 1100, the TXS PS mode field (or TXS PS Support field) may be set to 1 to indicate support of the TXS PS mode by AP 1102. The TXS PS mode field (or TXS PS Support field) may be provided in an EHT MAC Capabilities Information field of association response frame 1112.

[0132] In an implementation, support of the TXS PS mode by AP 1102 may include AP 1102 being able to receive from a STA a frame indicating enabling or disabling of the TXS PS mode at the STA as described herein. In an example, the frame may include a TPS Control subfield that indicates enabling or disabling of the TXS PS mode at the STA. The TPS Control subfield may include a TPS Disabling subfield that carries the indication of enabling or disabling of the TXS PS mode at the STA. In an implementation, support of the TXS PS mode by AP 1102 may further include AP 1102 being able to transmit to the STA an acknowledgment of the frame indicating enabling or disabling of the TXS PS mode at the STA. In an implementation, support of the TXS PS mode by AP 1102 may further include AP 1102 being capable of not transmitting (or refraining from transmitting) any frame, during a TXS time period, to a STA that sets the TPS Disabling subfield to 0 when the TXS time period is not allocated to the STA (e.g., by an MRTT frame).

[0133] Subsequently, in an example, STA 1108 may transmit a frame 1134 indicating enabling of the TXS PS mode at STA 1108. Frame 1134 may be a QoS data frame, a QoS null frame, an action frame, a control frame, or a management frame. Frame 1134 may comprise an element or subfield that may be used to indicate enabling or disabling of the TXS PS mode at STA 1108.

[0134] In an example, frame 1134 may be a QoS data frame or a QoS null frame. The QoS data frame or QoS null frame may comprise an A-Control field that carries an indication of enabling or disabling the TXS PS mode at STA 1108. The A-Control field may be carried in an FIT Control field of the QoS data frame or QoS null frame. In an example, the A- Control field may comprise a TPS Control subfield. The TPS Control subfield may include a TPS Disabling subfield. The TPS Disabling subfield may be set to 0 to indicate enabling of the TXS PS mode at STA 1108 and may be set to 1 to indicate disabling of the TXS PS mode at STA 1108. The TPS Control subfield may further include Reserved bits.

[0135] In another example, frame 1134 may be an action frame. The action frame may comprise an element / field indicating enabling or disabling the TXS PS mode at STA 1108. In an example, the action frame may be an EML Operating Mode Notification frame. In an example, the action frame may comprise a TPS Disabling subfield. The TPS Disabling subfield may be set to 0 to indicate enabling of the TXS PS mode at STA 1108 and may be set to 1 to indicate disabling of the TXS PS mode at STA 1108. The TPS Control subfield may further include Reserved bits.

[0136] In an implementation, AP 1102 may acknowledge frame 1134 by transmitting an acknowledgement frame 1136 to STA 1108. Acknowledgment frame 1136 may be an ACK frame or a BA frame.

[0137] Subsequently, AP 1102 may transmit a frame 1114 to allocate a portion of an obtained TXOP to STA 1104. Frame 1114 may 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 triggeredTXOP 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 STA 1104. The first time period may be specified in units of microseconds or some other unit of time. In an example, frame 1114 may be an MRTT frame.

[0138] On receiving frame 1114, STA 1104 may transmit a frame 1116 to AP 1102. In an example, frame 1116 may be a GTS frame. STA 1104 may subsequently transmit a non-TB PPDU comprising a data frame 1118 to STA 1106 during the first time period. STA 1106 may transmit a BA frame 1120 to STA 1104 in response to data frame 1118.

[0139] Based on receiving frame 1114 which does not allocate STA 1108 during the first time period, and the TXS PS mode being enabled at STA 1108, STA 1108 may transition to a doze state during the first time period. In accordance with the TX PS mode, STA 1108 may transition to the doze state: after STA 1108 receives frame 1114 and before STA 1108 receives frame 1116 in response to frame 1114; after STA 1108 receives frame 1116 in response to frame 1114; or if STA 1108 does not receive a third frame during a second time period after STA 1108 receives frame 1114. 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 AP 1102. The fourth frame may be a beacon frame, a probe response frame, or an association response frame.

[0140] In an implementation, STA 1108 may maintain the doze state during a portion of the first time period after STA 1108 transitions to the doze state. In an implementation, STA 1108 may return to an awake state at the end of the first time period or at least from the end of the first time period. In an implementation, AP 1102 may not transmit a frame to STA 1108 during the first time period. AP 1102 may transmit a frame to STA 1108 after the first time period. In an example (not shown in FIG. 11), AP 1102 may receive from STA 1104, within the first time period, a frame indicating release or return of a remaining time of the first time period. The frame may comprise a QoS Data frame or a QoS Null frame that includes an HE variant HT Control field with a CAS Control subfield with the RDG / More PPDU subfield equal to 0. Based on the TXS PS mode being enabled at STA 1108, AP 1102 may wait for an end of the remaining time before transmitting a frame to STA 1108. In an example, AP 1102 may use the remaining time to transmit a frame to STA 1104 or STA 1106 (assuming STA 1104 or STA 1106 is in the awake state) or to another STA (not shown in FIG. 11, e.g., a legacy STA that does not support TXS PS mode). In another example, AP 1102 may allocate a portion of the remaining time to STA 1106.

[0141] In example 1100, STA 1108 may return to the awake state after the end of the first time period or at least from the end of the first time period. Subsequently, STA 1108 may transmit a frame 1138 indicating disabling of the TXS PS mode at STA 1108. Frame 1138 may be a QoS data frame, a QoS null frame, an action frame, a control frame, or a management frame. Frame 1138 may comprise an element or subfield that may be used to indicate enabling or disabling of the TXS PS mode at STA 1108. In an example, frame 1138 may be a QoS data frame or a QoS null frame. The QoS data frame or QoS null frame may comprise an A-Control field that carries an indication of enabling or disabling the TXS PS mode at STA 1108. The A-Control field may be carried in an HT Control field of the QoS data frame or QoS null frame. In another example, frame 1138 may be an action frame. The action frame may comprise an element / field indicatingenabling or disabling the TXS PS mode at STA 1108. In an example, the action frame may be an EML Operating Mode Notification frame.

[0142] In an implementation, AP 1102 may acknowledge frame 1138 by transmitting an acknowledgement frame 1140 to STA 1108. Acknowledgment frame 1140 may be an ACK frame or a BA frame.

[0143] Subsequently, AP 1102 may transmit a frame 1126 to allocate a portion of an obtained TXOP to STA 1104. Frame 1126 may 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 STA 1104. The first time period may be specified in units of microseconds or some other unit of time. In an example, frame 1126 may be an MRTT frame.

[0144] On receiving frame 1126, STA 1104 may transmit a frame 1128 to AP 1102. In an example, frame 1116 may be a GTS frame. STA 1104 may subsequently transmit a non-TB PPDU comprising a data frame 1130 to STA 1106 during the first time period. STA 1106 may transmit a BA frame 1132 to STA 1104 in response to data frame 1130.

[0145] On receiving frame 1126 which does not allocate STA 1108 during the first time period, and based on the TXS PS mode being disabled at STA 1108, STA 1108 may remain in the awake state during the first time period. In an example (not shown in FIG. 11), AP 1102 may receive from STA 1104, within the first time period, a frame indicating release or return of a remaining time of the first time period. The frame may comprise a QoS Data frame or a QoS Null frame that includes an HE variant HT Control field with a CAS Control subfield with the RDG / More PPDU subfield equal to 0. In an example, based on the TXS PS mode being disabled at STA 1108, AP 1102 may transmit a frame to STA 1108 during the remaining time of the first time period. In another example, based on the TXS PS mode being disabled at STA 1108, AP 1102 may allocate a portion of the remaining time to STA 1108. STA 1108 may use the allocated portion of the remaining time to transmit to AP 1102 or to another STA depending on the indicated TXS mode.

[0146] Advantages of the other example illustrated in FIG. 11 include decreased signaling overhead and latency for a STA to signal to an AP a TXS PS mode state change at the STA. As described above, the TXS PS mode state change may be carried in various frame types and is not limited to association request frames. For example, the TXS PS mode state change may be carried in a QoS data / null frame or in a short action frame. The AP may respond to the frame from the STA with a short acknowledgement frame instead of a relatively large association response frame.

[0147] In yet another example, similar to the previous example, an AP may solicit the TXS PS mode state at a STA. The STA may respond to the solicitation from the AP by transmitting to the AP a frame that indicates enabling or disabling of the TXS PS mode at the STA. In an example, the AP may transmit to the STA a frame soliciting the TXS PS mode state at the STA before initiating a TXS operation.

[0148] FIG. 12 illustrates an example 1200 of an existing operation whereby a TXOP acquired by a non-AP STA is shared with an AP. As shown in FIG. 12, example 1200 includes AP 1210, and STAs 1211 and 1212, associated withAP 1210. In some circumstances, a non-AP STA may optionally share its TXOP with an AP (e.g., with which the non- AP STA is associated) after the non-AP STA completes utilization of the TXOP for transmission / reception.

[0149] As shown in FIG. 12, example 1200 may begin with STA 1211 obtaining a TXOP and transmitting RTS frame 1216 to AP 1210. The TXOP may have a TXOP duration 1250. AP 1210 may respond to RTS frame 1216 with GTS frame 1215. Based on receiving GTS frame 1215, STA 1211 may transmit data frame 1240 to AP 1210. AP 1210 may respond to data frame 1240 by transmitting a BA frame 1230 to STA 1211. In this example, after data frame 1240 is transmitted, STA 1211 has no more data frames to transmit during TXOP duration 1250. In an example, STA 1211 may indicate this by setting to zero a “more data” field in data frame 1240. Based on this completion of the utilization of TXOP duration 1250 by STA 1211, as depicted, STA 1211 may transmit reverse TXOP sharing control frame (CTRL) 1280 to AP 1210, e.g., to share a portion of TXOP duration 1250 with AP 1210, starting at label 1245 and continuing for shared TXOP duration 1255.

[0150] In this example, shared TXOP duration 1255 may correspond to the remaining portion of TXOP duration 1250. However, notwithstanding that STA 1211 has shared the remaining portion of TXOP duration 1250 with AP 1210, STA 1211 remains in awake state 1260 for the entirety of shared TXOP duration 1255. Because STA 1211 has no additional data to transmit (or receive from AP 1210) during shared TXOP duration 1255, remaining in awake state 1260 during shared TXOP duration 1255 increases unnecessarily power consumption of STA 1211.

[0151] Embodiments of the present disclosure, as further described below, address the above-described problem where a STA unnecessarily and wastefully remains in an awake state after returning a first time period (e.g., a TXOP duration) to the AP. In an aspect, a STA may transition to a power saving mode during a portion of a TXOP that the STA shares with an AP. In another aspect, the STA may transmit to the AP, a frame that shares a transmit opportunity (TXOP) with the AP. In some embodiments, the power state transition may include a transition by the STA, after the transmitting of the frame, from a first power state to a second power state. In an aspect, the frame may further include an indication of the sharing of the remainder of the TXOP with the AP. With respect to the transitioning between states, in some embodiments, the first power state may include an awake power state and the second power state may include a comparatively lower power consumption power state, e.g., a doze power state. Thus, in accordance with one or more embodiments, the STA may avoid unnecessarily and wastefully remaining in an awake state after returning the first time period to the AP.

[0152] The STA may as such avoid unnecessarily and wastefully remaining in an awake state after returning the first time period to the AP.

[0153] FIG. 13 illustrates an example 1300 of one or more embodiments that may utilize a power saving operation during an operation where the STA shares a TXOP with an AP. As shown in FIG. 13, example 1300 includes AP 1310, and STAs 1311 and 1312, associated with AP 1310. Depicted in FIG. 13, example 1300 may begin with STA 1311 obtaining a TXOP and transmitting RTS frame 1316 to AP 1310. The TXOP may have a TXOP duration 1350.

[0154] AP 1310 may respond to RTS frame 1316 with GTS frame 1315. Based on receiving GTS frame 1315, STA 1311 may transmit data frame 1340-1 to AP 1310. AP 1310 may respond to data frame 1340-1 by transmitting a BAframe 1330-1 to STA 1311. In this example, after data frame 1340-1 is transmitted, STA 1311 has no more data frames to transmit during TXOP duration 1350.

[0155] Based on this completion of the utilization of TXOP duration 1350 by STA 1311, in certain circumstances STA 1311 may communicate CTRL frame 1380 to share a portion of TXOP duration 1350 with AP 1310, e.g., starting at label 1345 and continuing for shared TXOP duration 1355. In this example, based on the TXOP sharing at 1345, AP 1310 may utilize shared TXOP duration 1355 for transmission of data frame 1340-2 to STA 1311. STA 1311 may successfully receive data frame 1340-2 and may transmit BA frame 1330-2 in response.

[0156] Continuing this example, in contrast with FIG. 12 above, after STA 1311 has shared the remaining portion of TXOP duration 1350 with AP 1310, in one or more embodiments STA 1311 may enter doze state 1365. For example, in accordance with one or more embodiments, after STA 1311 receives data frame 1340-2 and transmits BA frame 1330-2 in response, STA 1311 may transition from a first power state (e.g., STA 1311 in awake state 1360) to a second power state (e.g., STA 1311 in doze state 1365). In one or more embodiments, this transition may be based on a combination of one or more factors, including, but not limited to the sharing mode of the TXOP portion allocated to AP 1310, and the sharing by STA 1311 of the remaining portion of TXOP duration 1350 with AP 1310.

[0157] Thus, based on the transition from awake state 1360 to doze state 1365, one or more embodiments may address the above-described problems that may be associated with a STA unnecessarily and wastefully remaining in an awake state after sharing a TXOP duration with an AP, e.g., as discussed with FIG. 12 above.

[0158] While one or more embodiments may address the wasteful awake state problems discussed above, a problem may arise in some circumstances due to the transition of STA 1311 into doze state 1365 after point 1323 as described below. In an example that illustrates potential problems that may occur given the transition, of STA 1311 into doze state 1365, as depicted, at point 1322, AP 1310 may receive and buffer additional data frames for STA 1311.

[0159] Thus, after doze state 1365 begins for STA 1311 at point 1323, utilizing shared TXOP duration 1355, AP 1310 may attempt to transmit the buffered data frames to STA 1311, e.g., as data frame 1340-3. In this example, because the transmission of data frame 1340-3 for STA 1311 occurs while STA 1311 is in doze state 1365, receive failure 1325 may occur. In some implementations, based on the sharing of TXOP duration 1350 with AP 1310 by STA 1311, data frame 1340-3 may have been prioritized for transmission to STA 1311 over other data to be transmitted to other STAs, thereby increasing the likelihood of receive failure 1325, as occurs in this example.

[0160] In some circumstances, receive failure 1325 may cause network performance degradation, e.g., failure of reception of data frames (e.g., 1340-3) for STAs that enter doze state 1365 to save power (e.g., STA 1311), failure of transmission of data frames for other STAs that attempt to send data frames to STAs that enter doze state 1365 to save power, and wasteful retransmission of data frames by APs associated with STAs that enter doze state 1365 to save power. In some cases, the data frames missed by the STAs that enter doze state 1365 may be low latency data frames, resulting in application performance degradation.

[0161] Embodiments of the present disclosure, as further described below, address the above-described problems of network performance degradation, e.g., caused by reception failures. In one aspect of embodiments, a STA may transmita first frame to an AP, indicating a power state transition, e.g., that STA 1411 will be unavailable due to a transition to a power saving mode. In another aspect, the STA may transmit to the AP, a second frame that shares a transmit opportunity (TXOP) with the AP. In some embodiments, the power state transition may include a transition by the STA, after the transmitting of the second frame, from a first power state to a second power state. In an aspect, the second frame may further include an indication of the sharing of the remainder of the TXOP with the AP. With respect to the transitioning between states, in some embodiments, the first power state may include an awake power state and the second power state may include a comparatively lower power consumption power state, e.g., a doze power state.

[0162] Thus, in accordance with one or more embodiments, the STA may avoid network performance degradation, e.g., degradation associated with receive failures.

[0163] FIG. 14 illustrates an example 1400 of one or more embodiments that may provide STA unavailability information to an AP being allocated a portion of a TXOP by a STA. As shown in FIG. 14, example 1400 includes AP 1410, and STAs 1411 and 1412, associated with AP 1410. Depicted in FIG. 14, example 1400 may begin with STA 1411 performing a random backoff 1405 and gaining access to the shared medium to obtain a TXOP. The TXOP may have a TXOP duration 1450.

[0164] AP 1410 may respond to RTS frame 1416 with GTS frame 1415. Based on receiving GTS frame 1415, STA 1411 may transmit data frame 1440-1 to AP 1410. AP 1410 may respond to data frame 1440-1 by transmitting a BA frame 1430-1 to STA 1411. In this example, after data frame 1440-1 is transmitted, STA 1411 has no more data frames to transmit during TXOP duration 1450. In an example, STA 1411 may indicate this by setting to zero a “more data” field in data frame 1440-1. Based on this completion of the utilization of TXOP duration 1450 by STA 1411, as depicted, STA 1411 may transmit reverse TXOP sharing control frame (CTRL) 1480 to AP 1410, e.g., to share a portion of TXOP duration 1450 with AP 1410, starting at label 1445 and continuing for shared TXOP duration 1455.

[0165] In one or more embodiments, based on this completion of utilization of TXOP duration 1450 by STA 1411, and the sharing of the portion of TXOP duration 1450 with AP 1410, in certain circumstances STA 1411 may determine to enter doze state 1465 (e.g., following an awake state 1460) for some portion of the shared TXOP duration 1455. In contrast to the examples of FIGS. 12 and 13, STA 1411 may utilize CTRL frame 1480 to additionally indicate that STA 1411 will be unavailable for TXOP duration 1455 (e.g., after doze state begins at point 1423). In one or more embodiments, the information describing the unavailability of STA 1411 may be indicated to AP 1410 by setting to zero a “more data” field in CTRL frame 1480, e.g., without the need to add additional fields to CTRL frame 1480.

[0166] In this example, based on the TXOP sharing at 1445, AP 1410 may utilize shared TXOP duration 1455 for transmission of data frame 1440-2 to STA 1411, with STA 1411 successfully receiving data frame 1440-2 and transmitting BA frame 1430-2 in response.

[0167] The following example depicted in FIG. 14 illustrates how one or more embodiments may address the abovedescribed network performance degradation problems associated with a STA entering a doze state after sharing the remaining portion of TXOP duration 1350, e.g., receive failure 1325 described with FIG. 13 above.In this example, at point 1422, AP 1410 may receive and buffer additional data for STA 1411. As depicted in FIG. 14, in contrast to the transmission of data frame 1340-3 to STA 1311 in doze state 1365 (e.g., causing receive failure 1325), although AP 1410 also receives and buffers additional data for STA 1411, based on the indications included in CTRL frame 1480, during shared TXOP duration 1455, AP 1410 may refrain from transmitting any frame to STA 1411. Instead, AP 1410 may only transmit data frame 1440-3 to STA 1412 (resulting in BA 1430-3 being transmitted in response). Thus, in some implementations, CTRL frame 1480 may prevent the network performance degradation problems described with FIG. 13 above.

[0168] FIG. 15 illustrates an example 1500 of one or more embodiments that may provide STA unavailability information to an AP being allocated a portion of a TXOP by a STA. As shown in FIG. 15, example 1500 includes AP 1510, and STAs 1511 and 1512, associated with AP 1510. Depicted in FIG. 15, example 1500 may begin with STA 1511 performing a random backoff 1505 and gaining access to the shared medium to obtain a TXOP. The TXOP may have a TXOP duration 1550.

[0169] AP 1510 may respond to RTS frame 1516 with CTS frame 1515. Based on receiving CTS frame 1515, STA 1511 may transmit data frame 1540-1 to AP 1510. AP 1510 may respond to data frame 1540-1 by transmitting a BA frame 1530-1 to STA 1511. In this example, after data frame 1540-1 is transmitted, STA 1511 has no more data frames to transmit during TXOP duration 1550. In an example, STA 1511 may indicate this by setting to zero a “more data” field in data frame 1540-1.

[0170] Based on this completion of the utilization of TXOP duration 1550 by STA 1511, as depicted, STA 1511 may transmit reverse TXOP sharing control frame (CTRL) 1580 to AP 1510, e.g., to share a portion of TXOP duration 1550 with AP 1510, starting at a label 1545 and continuing for shared TXOP duration 1555.

[0171] As depicted, to provide an indication to AP 1510 that STA 1511 will be entering doze state 1565 (e.g., at point 1523 following an awake state 1560) for a portion of shared TXOP duration 1555, one or more embodiments may include indication 1542 with data frame 1540-1.

[0172] One approach that may be used by one or more embodiments to provide indication 1542, is for STA 1511 to send a BSR report, in data frame 1540-1, showing an empty buffer during transmissions by STA 1511 during TXOP duration 1550, before reverse TXOP sharing at 1545. In one embodiment, the BSR report may be provided in an A- Control subfield of an FIT control field of data frame 1540-1. In another embodiment (not shown in FIG. 15), the BSR report may be provided in an A-Control subfield of an FIT control field of a QoS null frame (e.g., the QoS null frame may have a format as shown in FIG. 4) that is aggregated with data frame 1540-1. In one or more embodiments, AP 1510 may be configured to interpret this empty buffer BSR report as an indication that STA 1511 will be in doze state for a portion of shared TXOP duration 1555. In this approach CTRL frame 1580 may include the reverse TXOP sharing indication, but not the doze state indication included with data frame 1540-1.

[0173] Another approach to providing indication 1542 includes providing indication 1542 as a PS flag in an A-Control subfield of an FIT control field of data frame 1540-1 , e.g., the A-Control subfield of an FIT control field of a data frame may have a format as shown in FIG. 4. The PS flag may be carried using 1 or more bits in the A-Control subfield. For thisapproach, a new Control ID field may be used to indicate that the Control information field comprises a PS Flag. Similar to the previous approach, the PS flag indication in the A-Control subfield may be carried in the HT control field of a QoS null frame that is aggregated with data frame 1540-1. In this example, based on the TXOP sharing at 1545, AP 1510 may utilize shared TXOP duration 1555 for transmission of data frame 1540-2 to STA 1511. STA 1511 may successfully receive data frame 1540-2 and transmit BA frame 1530-2 in response. Continuing this example, as depicted, during TXOP duration 1550, AP 1510 may receive and buffer additional data frames for STA 1511.

[0174] As depicted in FIG. 15, although AP 1510 also receives and buffers additional data frames for STA 1511 at point 1522, one or more embodiments may prevent the network performance degradation problems described with FIG. 13 above, e.g., based on the transmission of data frame 1340-3 to STA 1311 in doze state 1365 (e.g., causing receive failure 1325). For example, one or more embodiments, based on the unavailability information (e.g., use of power saving modes of operation by STA 1511) included in indication 1542, during shared TXOP duration 1555, AP 1510 may refrain from transmitting any frame to STA 1511. Instead, AP 1510 may only transmit data frame 1540-3 to STA 1512 (resulting in BA 1530-3 being transmitted in response). In one or more embodiments, this approach may avoid a receive failure by not transmitting the buffered data frames to STA 1511 during the remainder of shared TXOP duration 1555. Thus, in some implementations, indication 1542 may prevent the network performance degradation problems described with FIG. 13 above.

[0175] FIG. 16 illustrates an example 1600 of one or more embodiments that may utilize an action frame to signal PS information to an AP being allocated a portion of a TXOP by a STA. As shown in FIG. 16, example 1600 includes AP 1610, and STAs 1611 and 1612, associated with AP 1610.

[0176] Depicted in FIG. 16, example 1600 may begin with mode frame 1618 transmitted by STA 1611. In one or more embodiments, mode frame 1618 may include information provided by STA 1611 to AP 1610 that corresponds to STA 1611 operating in a RTXOP PS mode. For example, STA 1611 may transition to a power saving mode (e.g., doze state 1665) based on STA 1611 utilizing an RTXOP operation to share a portion of TXOP duration 1650 (e.g., shared TXOP duration 1655) with AP 1610. In one or more embodiments, mode frame 1618 may be an action frame. As such, the RTXOP PS mode may be indicated to AP 1610 by a PS Flag in an RTXOP PS element of mode frame 1618. In other embodiments, mode frame 1618 may comprise an association frame, an authentication frame, and / or another similar frame. In response to mode frame 1618, AP 1610 may respond with acknowledgment frame 1619.

[0177] Example 1600 continues with STA 1611 performing a random backoff 1605 and gaining access to the shared medium to obtain a TXOP. The TXOP may have a TXOP duration 1650. AP 1610 may respond to RTS frame 1616 with CTS frame 1615. Based on receiving CTS frame 1615, STA 1611 may transmit data frame 1640-1 toAP 1610. AP 1610 may respond to data frame 1640-1 by transmitting a BA frame 1630-1 to STA 1611. In this example, after data frame 1640-1 is transmitted, STA 1611 has no more data frames to transmit during TXOP duration 1650. In an example, STA 1611 may indicate this by setting to zero a “more data” field in data frame 1640-1.

[0178] In one or more embodiments, based on this completion of the utilization of TXOP duration 1650 by STA 1611, in certain circumstances STA 1611 may determine to operate in accordance with the RTXOP PS mode specified by modeframe 1618, e.g., a mode that may facilitate STA 1611 transitioning to doze state 1665 for a portion of shared TXOP duration 1655.

[0179] Continuing this example, to cause the reverse TXOP sharing with AP 1610, STA 1611 may transmit CTRL frame 1680 to AP 1610. In this example, the communication of the use of RTXOP PS mode by STA 1611 may be accomplished by mode frame 1618 discussed above, e.g., not by CTRL frame 1680 as described with FIG. 14 above. Based on the TXOP sharing at label 1645, AP 1610 may utilize shared TXOP duration 1655 for transmission of data frame 1640-2 to STA 1611. STA 1611 may successfully receive data frame 1640-2 and may transmit BA frame 1630-2 in response. Continuing this example, as depicted, just before label 1623, where doze state 1665 of STA 1611 begins (e.g., following an awake state 1660), at point 1622, AP 1610 may receive and buffer additional data frames for STA 1611.

[0180] Continuing this example, as depicted at point 1622, AP 1610 may receive and buffer additional data for STA 1611. As depicted in FIG. 16, in contrast to the transmission of data frame 1340-3 to STA 1311 in doze state 1365 (e.g., causing receive failure 1325), based on the RTXOP PS mode specified in mode frame 1618, during shared TXOP duration 1655, AP 1610 may refrain from transmitting any frame to STA 1611. Instead, AP 1610 may only transmit data frame 1640-3 to STA 1612 (resulting in BA 1630-3 being transmitted in response). Thus, in some implementations, mode frame 1618 may prevent the network performance degradation problems described with FIG. 13 above.

[0181] FIG. 17 illustrates an example process 1700 according to an embodiment. Example process 1700 may be performed by a STA, such as STA 1411, STA 1412, STA 1511, STA 1512, STA 1611, and STA 1612, described above. As shown in FIG. 17, process 1700 may include steps 1702 and 1704.

[0182] Step 1702 includes transmitting, by a STA, a first frame to an AP, indicating a power state transition, e.g., that the STA will be unavailable due to a transition to a power saving mode. Step 1704 includes transmitting, by the STA, to the AP, a second frame sharing with the AP a transmit opportunity (TXOP) obtained by the STA.

[0183] In additional or alternative embodiments, the power state transition may include a power state transition by the STA, after the transmitting of the second frame, from a first power state to a second power state. The second frame may further include an indication of sharing a remaining portion of the TXOP with the AP. In additional or alternative embodiments, with respect to the power state transition, the first power state may include an awake power state and the second power state may include a power state with lower power consumption than the awake power state. In additional or alternative embodiments, the power state may correspond to a doze power state.

[0184] In additional or alternative embodiments, the power state transition includes a power state transition for the remaining portion of the TXOP. In additional or alternative embodiments, the second frame includes a control frame for the sharing of the TXOP, a trigger frame, a quality of service (QoS) null frame, a QoS data frame, or a management frame. In additional or alternative embodiments, indicating the power state transition to the second power state comprises indicating a more data field value of zero in the second frame.

[0185] In additional or alternative embodiments, indicating the transitioning to the second power state may include indicating an uplink BSR of zero in the second frame. In an embodiment, the uplink BSR may be included in an A-Control field of the second frame. In additional or alternative embodiments, the response to the third frame may include anacknowledgement frame (ACK), a block ACK, or an action frame. In additional or alternative embodiments, the third frame may comprise an action frame, an association response frame, a probe request frame, or an authentication request frame. In additional or alternative embodiments, process 1700 may further include, receiving, from the AP, a third frame. In additional or alternative embodiments, the third frame may comprise an indication of whether the first STA is allowed to be in the second power state. In additional or alternative embodiments, the power state transition may be based on the indication.

[0186] In additional or alternative embodiments, the indication of whether the first STA is allowed to be in the second power state may comprise an indication of an end of transmission, by the AP to the first STA, during the TXOP. In additional or alternative embodiments, the indication whether the first STA is allowed to be in the second power state may comprise receiving, by the first STA, a fourth frame transmitted by the AP to a second STA. In additional or alternative embodiments, the fourth frame may comprise an address of the second STA in a receive address field of the fourth frame.

[0187] In additional or alternative embodiments, process 1700 may further include, transitioning, by the first STA, from the second power state to the first power state, before or during an end of the TXOP. In additional or alternative embodiments, the first power state may correspond to an awake state. In additional or alternative embodiments, the second power state may correspond to a doze state. In additional or alternative embodiments, the second power state may correspond to a state of unavailability of the STA.

[0188] FIG. 18 illustrates another example process 1800 according to an embodiment. Example process 1800 may be performed by an AP, such as AP 1410, AP 1510, and AP 1610, described above. As shown in FIG. 18, process 1800 may include step 1802.

[0189] Step 1802 includes transmitting, by an access point (AP) to a first station (STA), a first frame, during a transmit opportunity (TXOP) shared with the AP by the first STA, indicating that the first STA is allowed to be in the first power state during the TXOP. In additional or alternative embodiments, process 1800 may further include, based on the STA being allowed to be in the first power state, receiving an indication of a power state transition from a second power state to the first power state, during the TXOP. In additional or alternative embodiments, the power state transition may include a power state transition for a remaining portion of the TXOP.

[0190] In additional or alternative embodiments, the second power state may include an awake power state and the first power state may include a doze power state. In additional or alternative embodiments, process 1800 may further include, receiving, by the AP from the STA, a second frame comprising, a first indication of the sharing of the TXOP with the AP.

[0191] In additional or alternative embodiments, the second frame may further include an indication of sharing of a remaining portion of the TXOP with the AP. In additional or alternative embodiments, the first power state may include an awake power state and the second power state may include a power state with lower power consumption than the awake power state.

[0192] In additional or alternative embodiments, the first frame may include a control frame for the sharing of the TXOP. In additional or alternative embodiments, the first frame may include a trigger frame. In additional or alternativeembodiments, the first frame may include a quality of service (QoS) null frame, a QoS data frame, or a management frame. In additional or alternative embodiments, indicating the power state transition to the first power state may include indicating a more data field value of zero in the second frame. In additional or alternative embodiments, indicating the power state transition to the first power state may include indicating an uplink buffer status report (BSR) of zero in the second frame. In an embodiment, the uplink BSR is indicated in an A-Control field of the second frame.

Claims

CLAIMSWhat is claimed is:

1. A method comprising: transmitting, by a station (STA) to an access point (AP), a first frame indicating a power state transition; transmitting, by the STA to the AP, a second frame, sharing with the AP a transmit opportunity (TXOP) obtained by the STA; and based on the power state transition, transitioning, by the STA, from a first power state to a second power state, for a remaining portion of the TXOP.

2. A method comprising: transmitting, by a station (STA) to an access point (AP), a first frame indicating a power state transition; and transmitting, by the STA to the AP, a second frame, sharing with the AP a transmit opportunity (TXOP) obtained by the STA.

3. The method of claim 2, wherein the power state transition comprises a power state transition, after the transmitting of the second frame, from a first power state to a second power state.

4. The method of claim 3, wherein the second frame further comprises an indication of sharing of a remaining portion of the TXOP with the AP.

5. The method of claim 3, wherein the first power state comprises an awake power state and the second power state comprises a power state with lower power consumption than the awake power state.

6. The method of claim 5, wherein the second power state comprises a doze power state.

7. The method of claim 3, wherein the power state transition comprises a power state transition for a remaining portion of the TXOP.

8. The method of any of claims 3-7, wherein the second frame comprises a control frame for the sharing of the TXOP.

9. The method of any of claims 2-7, wherein the second frame comprises a trigger frame.

10. The method of any of claims 2-7, wherein the second frame comprises a quality of service (QoS) null frame, a QoS data frame, or a management frame.

11. The method of claim 8, wherein indicating the power state transition to the second power state comprises indicating a more data field value of zero in the second frame.

12. The method of claim 8, wherein indicating the power state transition to the second power state comprises indicating an uplink buffer status report (BSR) of zero in the second frame.

13. The method of claim 12, wherein the uplink BSR is indicated in an A-Control field of the second frame.

14. The method of claim 3, further comprising transmitting, by the STA to the AP, a third frame prior to the TXOP, wherein the power state transition to the second power state is based on receiving a response to the third frame.

15. The method of claim 14, wherein the response to the third frame comprises an acknowledgement frame (ACK), a block ACK, or an action frame.

16. The method of any of claims 14-15, wherein the third frame comprises an action frame, an association response frame, a probe request frame, or an authentication request frame.

17. The method of any claims 3-14, further comprising receiving, from the AP, a third frame, wherein the third frame comprises an indication of whether the STA is allowed to be in the second power state, and wherein the power state transition is based on the indication.

18. The method of claim 17, wherein the indication of whether the STA is allowed to be in the second power state comprises an indication of an end of transmission, by the AP to the STA, during the TXOP.

19. The method of claim 17, wherein the indication whether the STA is allowed to be in the second power state comprises receiving, by the STA, a fourth frame transmitted by the AP to a second STA.

20. The method of claim 19, wherein the fourth frame comprises an address of the second STA in a receive address field of the fourth frame.

21. The method of any of claims 3-20, further comprising transitioning, by the STA, from the second power state to the first power state, before or during an end of the TXOP.

22. The method of any of claims 3-21, wherein the first power state is an awake state.

23. The method of any of claims 3-22, wherein the second power state is a doze state.

24. The method of any of claims 3-21, wherein the second power state is a state of unavailability of the STA.

25. A method comprising: receiving, by an access point (AP) from a station (STA) and during a transmit opportunity (TXOP) obtained by the STA, a first frame comprising: a first indication of a sharing of the TXOP, with the AP; and a second indication of a transitioning from a first power state to a second power state, during the TXOP, by the STA; and transmitting, by the AP to the STA, a second frame indicating that the STA is allowed to be in the second power state during the TXOP.

26. A method comprising: transmitting, by an access point (AP) to a station (STA), a first frame, during a transmit opportunity (TXOP) shared with the AP by the STA, indicating that the STA is allowed to be in a first power state during the TXOP.

27. The method of claim 26, further comprising, based on the STA being allowed to be in the first power state, receiving an indication of a power state transition from a second power state to the first power state, during the TXOP.

28. The method of claim 27, wherein the power state transition comprises transitioning for a remaining portion of the TXOP.

29. The method of claim 27, wherein the second power state comprises an awake power state and the first power state comprises a dose power state.

30. The method of claims 27-29, further comprising, receiving, by the AP from the STA, a second frame comprising, a first indication of the sharing of the TXOP with the AP.

31. The method of claim 30, wherein the second frame further comprises an indication of sharing of a remaining portion of the TXOP with the AP.

32. The method of claim 27, wherein the first power state comprises an awake power state and the second power state comprises a power state with lower power consumption than the awake power state.

33. The method of any of claims 26-32, wherein the first frame comprises a control frame for the sharing of the TXOP.

34. The method of any of claims 26-31, wherein the first frame comprises a trigger frame.

35. The method of any of claims 26-31, wherein the first frame comprises a quality of service (QoS) null frame, a QoS data frame, or a management frame.

36. The method of claim 26, wherein indicating that the STA is allowed to be in the first power state comprises indicating a more data field value of zero in the first frame.

37. The method of claim 30, wherein receiving the indication of the power state transition comprises receiving an uplink buffer status report (BSR) of zero in the second frame.

38. The method of claim 37, wherein the uplink BSR is indicated in an A-Control field of the second frame.

39. 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 -38.

40. 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-38.

Images