WO2025230870A1

WO2025230870A1 - Communication of in-device coexistence (idc) unavailability period information

Info

Publication number: WO2025230870A1
Application number: PCT/US2025/026598
Authority: WO
Inventors: Jeongki Kim; Leonardo Alisasis LANANTE; Esmael Hejazi Dinan; Serhat Erkucuk; Tuncer Baykas; Jiayi Zhang
Original assignee: Ofinno LLC
Current assignee: Ofinno LLC
Priority date: 2024-04-29
Filing date: 2025-04-28
Publication date: 2025-11-06
Anticipated expiration: 2026-10-29

Abstract

An access point (AP) receives, from a first station (STA), a control frame indicating a period of unavailability of the first STA. Based on the first frame, the AP communicates with a second STA during the period of unavailability. The AP receives, from the first STA and during the period of unavailability, a Quality of Service (QoS) null frame indicating that the period of unavailability ended. After receiving the QoS null frame, the AP transmits, to the first STA, a data frame. In response to the data frame, the AP receives, from the first STA, an acknowledgement frame.

Description

TITLE

Communication of In-Device Coexistence (IDC) Unavailability Period Information

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/639,790, filed April 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 of a Medium Access Control (MAC) frame format.

[0006] FIG. 4 illustrates an example of a Quality of Service (QoS) null frame indicating buffer status information.

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

[0008] FIG. 6 illustrates an example wireless device.

[0009] FIG. 7 illustrates a procedure in which a transmission opportunity (TXOP) may be adjusted based on a period of unavailability of a STA.

[0010] FIG. 8 illustrates another procedure in which a TXOP may be adjusted based on a period of unavailability of a STA.

[0011] FIG. 9 illustrates an example problem that may arise in the procedures illustrated in FIG. 7 and 8.

[0012] FIG. 10 illustrates an example procedure according to an embodiment.

[0013] FIG. 11 illustrates another example procedure according to an embodiment.

[0014] FIG. 12 illustrates another example procedure according to an embodiment.

[0015] FIG. 13 illustrates another example procedure according to an embodiment.

[0016] FIG. 14 illustrates another example procedure according to an embodiment.

[0017] FIG. 15 illustrates another example procedure according to an embodiment.

[0018] FIG. 16 illustrates another example procedure according to an embodiment.

[0019] FIG. 17 illustrates another example procedure according to an embodiment.

[0020] FIG. 18 illustrates another example procedure according to an embodiment.

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

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

DETAILED DESCRIPTION

[0023] 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 those shown. For example, the actions listed in any flowchart may be re-ordered or only optionally used in some embodiments.

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

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

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

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

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

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

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

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

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

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

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

[0035] WLAN infra-structure network 102 may be coupled to one or more external networks. For example, as shown in FIG. 1, WLAN infra-structure network 102 may be connected to another network 108 (e.g., 802.X) via a portal 140. Portal 140 may function as a bridge connecting DS 130 of WLAN infra-structure network 102 with the other network 108. [0036] The example wireless communication networks illustrated in FIG. 1 may further include one or more ad-hoc networks or independent BSSs (IBSSs). An ad-hoc network or IBSS is a network that includes a plurality of STAs that are within communication range of each other. The plurality of STAs are configured so that they may communicate with each other using direct peer-to-peer communication (i.e., not via an AP).

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

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

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

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

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

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

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

[0044] Transceiver 240/290 may be configured to transmit/receive radio signals. In an embodiment, transceiver 240/290 may implement a PHY layer of the corresponding device (STA 210 or AP 260). In an embodiment, STA 210 and/or AP 260 may be a multi-link device (MLD), that is a device capable of operating over multiple links as defined by the IEEE 802.11 standard. As such, STA 210 and/or AP 260 may each implement multiple PHY layers. The multiple PHY layers may be implemented using one or more of transceivers 240/290. [0045] FIG. 3 illustrates an example format of a MAC frame. In operation, a STA may construct a subset of MAC frames for transmission and may decode a subset of received MAC frames upon validation. The particular subsets of frames that a STA may construct and/or decode may be determined by the functions supported by the STA. A STA may validate a received MAC frame using the frame check sequence (FCS) contained in the frame and may interpret certain fields from the MAC headers of all frames.

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

[0047] The MAC header includes a frame control field, an optional duration/ID field, address fields, an optional sequence control field, an optional QoS control field, and an optional HT control field.

[0048] The frame control field includes the following subfields: protocol version, type, subtype, “To DS”, “From DS”, “More Fragments", retry, power management, “More Data , protected frame, and +HTC.

[0049] The protocol version subfield is invariant in size and placement across all revisions of the IEEE 802.11 standard. The value of the protocol version subfield is 0 for MAC frames.

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

[0051] The “To DS” subfield indicates whether a data frame is destined to the distribution system (DS). The “From DS” subfield indicates whether a data frame originates from the DS.

[0052] The “More Fragments” subfield is set to 1 in all data or management frames that have another fragment to follow the MAC service data unit (MSDU) or MAC management protocol data unit (MMPDU) carried by the MAC frame. The “More Fragments” subfield is set to 0 in all other frames in which the “More Fragments” subfield is present.

[0053] The retry subfield is set to 1 in any data or management frame that is a retransmission of an earlier frame. It is set to 0 in all other frames in which the retry subfield is present. A receiving STA uses this indication to aid it in the process of eliminating duplicate frames. These rules do not apply for frames sent by a STA under a block agreement.

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

[0055] The “More Data” subfield indicates to a STA in power save (PS) mode that bufferable units (BUs) are buffered for that STA at the AP. The “More Data” subfield is valid in individually addressed data or management frames transmitted by an AP to a STA in PS mode. The “More Data" subfield is set to 1 to indicate that at least one additional buffered BU is present for the STA. [0056] The protected frame subfield is set to 1 if the frame body field contains information that has been processed by a cryptographic encapsulation algorithm.

[0057] The +HTC subfield indicates that the MAC frame contains an HT control field.

[0058] The duration/ID field of the MAC header indicates various contents depending on the frame type and subtype and the QoS capabilities of the sending STA. For example, in control frames of the power save poll (PS-Poll) subtype, the duration/ID field carries an association identifier (AID) of the STA that transmitted the frame in the 14 least significant bits (LSB), with the 2 most significant bits (MSB) set to 1. In other frames sent by STAs, the duration/ID field contains a duration value (in microseconds) which is used by a recipient to update a network allocation vector (NAV). The NAV is a counter that indicates to a STA an amount of time during which the STA must defer from accessing the shared medium. [0059] Up to four address fields may be present in the MAC frame format. The address fields are used to indicate the basic service set identifier (BSSID), source address (SA), destination address (DA), transmitting address (TA), and receiving address (RA). Certain frames may not contain some of the address fields. Certain address field usage may be specified by the relative position of the address field (1-4) within the MAC header, independent of the type of address present in that field. Specifically, the address 1 field always identifies the intended receiver(s) of the frame, and the address 2 field, where present, always identifies the transmitter of the frame.

[0060] The sequence control field includes two subfields, a sequence number subfield and a fragment number subfield. The sequence number subfield in data frames indicates the sequence number of the MSDU (if not in an Aggregated MSDU (A-MSDU)) or A-MSDU. The sequence number subfield in management frames indicates the sequence number of the frame. The fragment number subfield indicates the number of each fragment of an MSDU or MMPDU. The fragment number is set to 0 in the first or only fragment of an MSDU or MMPDU and is incremented by one for each successive fragment of that MSDU or MMPDU. The fragment number is set to 0 in a MAC protocol data unit (MPDU) containing an A-MSDU, or in an MPDU containing an MSDU or MMPDU that is not fragmented. The fragment number remains constant in all retransmissions of the fragment.

[0061] The QoS control field identifies the traffic category (T C) or traffic stream (TS) to which the MAC frame belongs. The QoS control field may also indicate various other QoS related, A-MSDU related, and mesh-related information about the frame. This information can vary by frame type, frame subtype, and type of transmitting STA. The QoS control field is present in all data frames in which the QoS subfield of the subtype subfield is equal to 1.

[0062] The HT control field is present in QoS data, QoS null, and management frames as determined by the +HTC subfield of the frame control field.

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

[0064] The FCS field contains a 32-bit Cyclic Redundancy Check (CRC) code. The FCS field value is calculated over all of the fields of the MAC header and the frame body field. [0065] FIG. 4 illustrates an example of a QoS null frame indicating buffer status information. A QoS null frame refers to a QoS data frame with an empty frame body. A 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.

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

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

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

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

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

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

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

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

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

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

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

[0073] 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. [0074] A STA obtains the queue size, QS, from a received QoS control field, which contains a scaling factor, SF, and an unsealed value, UV, as follows:

QS =

16 *UV, if SF is equal to O;

1024 + 256 x CH/, if SF is equal to 1;

17 408 + 2048 x W, if SF is equal to 2;

148480 + 32 768 x UV, if SF is equal to 3 and UV is less than 62;

> 2 147 328, if SF equal to is 3 and UV is equal to 62;

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

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

[0076] The HT control field may include 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.

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

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

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

[0080] The scaling factor subfield indicates the unit SF, in octets, of the queue size high and queue size all subfields. [0081] 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.

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

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

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

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

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

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

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

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

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

[0092] The buffer status reported in the QoS control field includes a queue size value for a given TID. The buffer status reported in the BSR control field includes an ACI bitmap, delta TID, a high priority AC, and two queue sizes. [0093] A STA may report buffer status to the AP, in the QoS control field, of transmitted QoS null frames and QoS data frames and, in the BSR control subfield (if present), of transmitted QoS null frames, QoS data frames, and management frames as defined below.

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

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

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

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

[0098] FIG. 6 illustrates an example wireless device 600. Wireless device 600 may support a plurality of radio technologies, including wireless local area network (WLAN) (e.g., IEEE 802.11 Wi-Fi®), Bluetooth®, ultra-wideband (UWB), and long-term evolution (LTE)/5G, for example. As such, as shown in FIG. 6, wireless device 600 may comprise a plurality of radio modules, including a WLAN radio module 602, a Bluetooth® radio module 604, a UWB radio module 606, and an LTE/5G radio module 608, for example. Each radio module of radio modules 602, 604, 606, and 608 may comprise a baseband processor and radio frequency (RF) circuitry for the respective radio technology supported by the radio module. Radio modules 602, 604, 606, and 608 may be coupled respectively to antennas 610, 612, 614, and 616. [0099] Wireless device 600 may comprise or operate as a non-AP STA or an AP STA. Wireless device 600 may be, for example, an embodiment of STA 210 or AP 260 illustrated in FIG. 2. In operation, radio modules 602, 604, 606, and 608 may interfere with each other. For example, a transmission by WLAN radio module 602 may interfere with a reception by Bluetooth® radio module 604, UWB radio module 606, and/or LTE/5G radio module 608. Alternatively, a transmission by Bluetooth® radio module 604, UWB radio module 606, or LTE/5G radio module 608 may interfere with a reception by WLAN module 602. Such interference events may be referred to as in-device coexistence (I DC) interference events.

[00100] To reduce IDC interference events, wireless device 600 may be configured to avoid transmitting using a first radio module when the transmission using the first radio module is expected to or is likely to interfere with the reception using one or more second radio modules of wireless device 600. Alternatively, or additionally, wireless device 600 may be configured to avoid receiving using the first radio module when transmission using the one or more second radio modules is expected to or is likely to interfere with the reception using the first radio module. For example, wireless device 600 may be configured to avoid transmitting using a WLAN module 602 when the transmission using WLAN module 602 is expected to or is likely to interfere with the reception using Bluetooth® radio module 604, UWB radio module 606, and/or LTE/5G radio module 608 of wireless device 600. Alternatively, or additionally, wireless device 600 may be configured to avoid receiving using WLAN module 602 when transmission using Bluetooth® radio module 604, UWB radio module 606, and/or LTE/5G radio module 608 is expected to or is likely to interfere with the reception using WLAN module 602.

[00101] When wireless device 600 operates as a non-AP STA or an AP STA, the time periods during which wireless device 600 may avoid transmitting and/or receiving using WLAN module 602 (to avoid IDC interference events) may correspond to periods of unavailability for the non-AP STA or the AP STA. That is, the non-AP STA or the AP STA embodied by wireless device 600 may be unavailable to communicate with other WLAN devices (e.g., a peer non-AP STA(s) or an AP STA(s)) during those time periods. In an example, wireless device 600 may support a dynamic unavailability operation (DUO) mode (e.g., in which wireless device 600 may indicate unavailability in certain control frames). In another example, wireless device 600 may support a periodic unavailability operation (PUO) mode (e.g., in which wireless device 600 may indicate periodic service periods during which it will be unavailable).

[00102] FIG. 7 illustrates an example 700 of a procedure in which a transmission opportunity (TXOP) may be adjusted based on a period of unavailability of a STA. As shown in FIG. 7, example 700 includes a STA 702 and a STA 704. STAs 702 and 704 may each be a non-AP STA or an AP STA. In an example, STA 702 may be an AP STA and STA 704 may be a non-AP STA. In an example, STA 704 may be associated with STA 702.

[00103] Example 700 may begin with STA 702 transmitting an initial control frame (ICF) 706 to STA 704. ICF 706 may be a control frame, such as a request-to-send (RTS) frame, for example. ICF 706 may indicate a first transmission opportunity (TXOP). In an implementation, a duration of the first TXOP may be indicated in a duration field of ICF 706. ICF 706 may reserve the wireless medium for the duration of the first TXOP.

[00104] On receiving ICF 706, STA 704 may determine that STA 702 intends to communicate with STA 704 during the first TXOP. STA 704 may further determine that the first TXOP overlaps with a period of unavailability of STA 704. The period of unavailability may be due to an IDC interference event, within STA 704, that causes STA 704 to be unavailable for communication with other WLAN devices, including STA 702, during the period of unavailability.

[00105] In response to ICF 706, STA 704 may transmit to STA 702 an initial control response (ICR) 708 that indicates a second TXOP that does not overlap with the period of unavailability of STA 704. ICR 708 may be a control frame, such as a clear-to-send (CTS) frame, for example. In an implementation, ICR 708 may include information regarding the period of unavailability of STA 704. In an implementation, the second TXOP may be set to a shorter value than a value indicated in the first TXOP. In this case, as shown in FIG. 7, the end time of the second TXOP may end earlier than the end time of the first TXOP. casein another implementation (not shown in FIG. 7), the end time of the second TXOP may be equal to the end time of the first TXOP. In an implementation, a duration of the second TXOP may be indicated in a duration field of ICR 708. In another implementation, a duration of the second TXOP may be indicated in another field than a duration field of ICR 708. The other field may be a new field or an existing field of ICR 708. In another implementation, a duration of the second TXOP may be indicated in a duration field of ICR 708 and the period of unavailability of STA 704 may be indicated in another field of ICR 708. In this case, the end time of the second TXOP may be equal to the end time of the first TXOP. The other field may be a new field an existing field of ICR 708.

[00106] On receiving ICR 708, STA 702 may initiate transmission of a data frame 710 to STA 704. Data frame 710 may indicate a third TXOP based on the second TXOP indicated in ICR 708. In an implementation, an end time of the third TXOP may be equal to an end time of the second TXOP as shown in FIG. 7. As such, the third TXOP avoids the period of unavailability of STA 704, and communication between STA 702 and STA 704 can end before a start of the period of unavailability of STA 704. In another implementation, an end time of the second TXOP may be equal to an end time of the first TXOP. In this case, an end time of the third TXOP may be different from (e.g., shorter than) an end time of the second TXOP (not shown in FIG. 7). As such, the third TXOP avoids the period of unavailability of STA 704, and communication between STA 702 and STA 704 can end before a start of the period of unavailability of STA 704.

[00107] STA 704 may respond to data frame 710 by transmitting to STA 702 a blockack (BA) frame 712 marking the end of the third TXOP. Subsequently, the period of unavailability begins at STA 704, and STA 704 becomes unavailable for communication. In an implementation, based on receiving the information regarding the period of unavailability of STA 704 in ICR 708, STA 702 may refrain from any transmission to STA 704 during the period of unavailability of STA 704. In an implementation, after receiving BA frame 712, STA 702 may transmit a CF-End frame (not shown in FIG. 7).

[00108] FIG. 8 illustrates an example 800 of another procedure in which a TXOP may be adjusted based on a period of unavailability of a STA. As shown in FIG. 8, example 800 includes a STA 802 and a STA 804. STAs 802 and 804 may each be a non-AP STA or an AP STA. In an example, STA 802 may be an AP STA and STA 804 may be a non-AP STA. In an example, STA 804 may be associated with STA 802.

[00109] Example 800 may begin with STA 804 transmitting to STA 802 a frame 814 indicating a period of unavailability of STA 804. The period of unavailability may be due to an I DC interference event, within STA 804, that causes STA 804 to be unavailable for communication with other WLAN devices, including STA 802. Frame 814 may be a data frame, a control frame, a management frame, or an action frame, for example.

[00110] Subsequently, STA 802 may transmit an ICF 806 to STA 804. ICF 806 may be a control frame, such as an RTS frame, for example. ICF 806 may be a management frame, a data frame, or a QoS null frame. ICF 806 may indicate a first TXOP. Based on the information regarding the period of unavailability of STA 804 received in frame 814, STA 802 may be configured to set the first TXOP so as not overlap with the period of unavailability of STA 804. For example, as shown in FIG. 8, STA 802 may be configured to set the first TXOP to end before a start of the period of unavailability of STA 804. In an implementation, a duration of the first TXOP may be indicated in a duration field of ICF 806. ICF 806 may reserve the wireless medium for the duration of the first TXOP.

[00111] On receiving ICF 806, STA 804 may determine that STA 802 intends to communicate with STA 804 during the first TXOP. STA 804 may further determine that the first TXOP does not overlap with the period of unavailability of STA 804. In response to ICF 806, STA 804 may transmit to STA 802 an ICR 808 that indicates a second TXOP based on the first TXOP. In an implementation, an end time of the second TXOP is equal to an end time of the first TXOP. ICR 808 may be a control frame, such as a CTS frame, for example. [00112] On receiving ICR 808, STA 802 may initiate transmission of a data frame 810 to STA 804. Data frame 810 may indicate a third TXOP based on the second TXOP indicated in ICR 808. In an implementation, an end time of the third TXOP is equal to an end time of the second TXOP. The third TXOP avoids the period of unavailability of STA 804, and communication between STA 802 and STA 804 can end before a start of the period of unavailability of STA 804.

[00113] STA 804 may respond to data frame 810 by transmitting to STA 802 a BA frame 812 marking the end of the third TXOP. Subsequently, the period of unavailability begins at STA 804, and STA 804 becomes unavailable for communication. Based on receiving the information regarding the period of unavailability of STA 804 in frame 814, STA 802 may refrain from any transmission to STA 804 during the period of unavailability of STA 804.

[00114] FIG. 9 shows an example 900 that illustrates a problem that may arise in the procedure illustrated in FIG. 8. As shown in FIG. 9, example 900 may also begin with the transmission of STA 804 to STA 802 of frame 814, followed by the exchange of ICF 806 and ICR 808, the transmission of STA 802 to STA 804 of data frame 810, and the response of STA 804 to STA 802 with BA frame 812.

[00115] Subsequently, after the period of unavailability begins at STA 804, data for STA 804 arrives at STA 802. In an example, the data may be low latency (LL) data that requires urgent transmission to STA 804. However, as STA 802 is configured to refrain from any transmission to STA 804 during the period of unavailability of STA 804 (in accordance with the procedure of FIG. 8), STA 802 may only buffer the arriving data for STA 802 and may only transmit the data after the end of the period of unavailability of STA 804, e.g., in a data frame 902.

[00116] However, in some cases, an actual period of unavailability of STA 804 may be shorter than the period of unavailability of STA 804 announced/indicated in frame 814. For example, the actual period of unavailability of STA 804 may start later than or may end before the announced/indicated period of unavailability of STA 804. In a particular example (as shown in example 900), the announced/indicated period of unavailability of STA 804 may be due to an IDC interference event within STA 804, and an actual duration of the IDC interference event (during which STA 804 is effectively unavailable for communication) may be shorter than the announced/indicated period of unavailability of STA 804. For instance, the IDC interference event may end before the announced/indicated period of unavailability of STA 804 or may even be cancelled before the start of the announced/indicated period of unavailability of STA 804. Nevertheless, despite that STA 804 becomes available before the end of the announced/indicated period of unavailability of STA 804, STA 802 may only transmit the data buffered for STA 802 after the end of the announced/indicated period of unavailability of STA 804. This may result in the transmission of the data to STA 804 being unnecessarily delayed, and, in the case of LL data, may cause the data to be discarded and lost at STA 802.

[00117] Embodiments of the present disclosure, as further described below, address the above-described problem of existing technologies. In an aspect, a first STA may transmit to a second STA a first frame indicating a first period of unavailability of the first STA. The first STA and the second STA may each be a non-AP STA or an AP STA. In an embodiment, the first STA may be a non-AP STA and the second STA may be an AP STA. After transmitting the first frame, the first STA may transmit to the second STA, during the first period of unavailability, a second frame indicating that the first period of unavailability ended. In an embodiment, the second frame indicates that the first STA is available until an end of the first period of unavailability. In another embodiment, the second frame indicates that an event related to the first period of unavailability ended. The event may comprise an IDC interference event. On receiving the second frame, the second STA may transmit to the first STA any buffered data for the first STA, without waiting for an end of the indicated first period of unavailability of the first STA.

[00118] In another embodiment, after receiving the first frame from the first STA, the second STA may transmit to the first STA, during the first period of unavailability, a third frame indicating that the second STA has buffered traffic for the first STA or checking whether the first STA is available for communication. The second STA may transmit the third frame to the first STA after data (e.g. , LL data) for the first STA arrives at the second STA during the first period of unavailability. The third frame may be a control frame, a management frame, a data frame, an action frame, or a QoS null frame. The third frame may be transmitted individually. The third frame may be a broadcast/multicast frame. The third frame may be transmitted together with another frame. The other frame may be Ack frame, a BA frame, a control frame, a management frame, a data frame, an action frame, or a QoS null frame. In another embodiment, the information that the second STA has buffered traffic for the first STA may be included/piggybacked in an existing frame rather than be included in the third frame. The existing frame may be an Ack frame, a BA frame, a control frame, a management frame, a data frame, an action frame, or a QoS null frame. In response to the third frame, the second STA may receive a fourth frame from the first STA. The fourth frame may be an immediate response frame, PS-Poll frame, a control frame, a management frame, a data frame, an action frame, or a QoS null frame. Upon receiving the fourth frame, the second STA may determine that the first STA is available for communication with the second STA. The second STA may transmit any buffered data for the STA without waiting for an end of the indicated first period of unavailability of the first STA.

[00119] FIG. 10 illustrates an example 1000 of a procedure according to an embodiment. As shown in FIG. 10, example 1000 includes a STA 1002 and a STA 1004 STAs 1002 and 1004 may each be a non-AP STA or an AP STA. In an example, STA 1002 may be an AP STA and STA 1004 may be a non-AP STA. In an example, STA 1004 may be associated with STA 1002.

[00120] Example 1000 may begin with STA 1004 transmitting to STA 1002 a frame 1014 indicating a period of unavailability of STA 1004. The period of unavailability may be due to an IDC interference event, within STA 1004, that causes STA 1004 to be unavailable for communication with other WLAN devices, including STA 1002. Frame 1014 may be a control frame, an ICF, an ICR, a power save (PS)-poll frame, an RTS frame, a multi-user (MU)-RTS frame, a Quality of Service (QoS) null frame, a QoS data frame, an action frame, or a management frame, for example.

[00121] Subsequently, STA 1002 may transmit an ICF 1006 to STA 1004. ICF 1006 may be a control frame, such as an RTS frame, for example. ICF 1006 may be transmitted a SIFS after frame 1014. ICF 1006 may indicate a first TXOP. Based on the information regarding the period of unavailability of STA 1004 received in frame 1014, STA 1002 may be configured to set the first TXOP so as not overlap with the period of unavailability of STA 1004. For example, STA 1002 may be configured to set the first TXOP to end before a start of the period of unavailability of STA 1004. In an implementation, a duration of the first TXOP may be indicated in a duration field of ICF 1006. ICF 1006 may reserve the wireless medium for the duration of the first TXOP. [00122] On receiving ICF 1006, STA 1004 may determine that STA 1002 intends to communicate with STA 1004 during the first TXOP. STA 1004 may further determine that the first TXOP does not overlap with the period of unavailability of STA 1004. In response to ICF 1006, STA 1004 may transmit to STA 1002 an ICR 1008 that indicates a second TXOP based on the first TXOP. In an implementation, an end time of the second TXOP is equal to an end time of the first TXOP. ICR 1008 may be a control frame, such as a CTS frame, for example.

[00123] On receiving ICR 1008, STA 1002 may initiate transmission of a data frame 1010 to STA 1004. Data frame 1010 may indicate a third TXOP based on the second TXOP indicated in ICR 1008. In an implementation, an end time of the third TXOP is equal to an end time of the second TXOP. The third TXOP avoids the period of unavailability of STA 1004, and communication between STA 1002 and STA 1004 can end before a start of the period of unavailability of STA 1004. STA 1004 may respond to data frame 1010 by transmitting to STA 1002 a BA frame 1012 marking the end of the third TXOP.

[00124] Subsequently, after the period of unavailability begins at STA 1004, data for STA 1004 arrives at STA 1002. In an example, the data may be low latency data. In an embodiment, without a further indication from STA 1004, STA 1002 maybe configured to refrain from communicating with STA 1004 during the period of unavailability of STA 1004. As such, STA 1002 may buffer the data for STA 1004. In an example, STA 1002 may communicate with a STA other than STA 1004 during the period that STA 1002 refrains from communicating with STA 1004.

[00125] In an embodiment, STA 1004 may be configured, when an actual period of unavailability of STA 1004 ends during the period of unavailability announced/indicated in frame 1014, to transmit to STA 1002 a frame 1016, during the period of unavailability announced/indicated in frame 1014, indicating that the period of unavailability announced/indicated in frame 1014 has ended. In example 1000, the period of unavailability announced/indicated in frame 1014 may be due to an anticipated IDC interference event at STA 1004. When the anticipated IDC interference event ends during the period of unavailability announced/indicated in frame 1014 or is cancelled, STA 1004 may indicate in frame 1016 that the IDC interference event has ended. In an embodiment, STA 1004 may indicate in frame 1016 that STA 1004 is available for communication until an end of the period of unavailability announced/indicated in frame 1014. In an embodiment, STA 1004 may transmit frame 1016 on condition that, when the actual period of unavailability of STA 1004 ends, a remaining portion of the period of unavailability announced/indicated in frame 1014 is greater than a predetermined duration (e.g., at least 5 milliseconds remain of the period of unavailability announced/indicated in frame 1014).

[00126] In embodiments, frame 1016 may comprise a control frame, an ICF, an acknowledgement frame, a BA frame, a PS-poll frame, an RTS frame, a CTS frame, an MU-RTS frame, a QoS null frame, a QoS data frame, an action frame, or a management frame, for example.

[00127] On receiving frame 1016 from STA 1004, STA 1002 may transmit a frame 1018 to STA 1004. Frame 1018 may comprise a control frame, a management frame, an action frame, a data frame, a QoS data frame, or a QoS null frame, for example. In example 1000, frame 1018 may be a data frame that comprises the data buffered for STA 1004. As such, STA 1004 may receive the data in a relatively short time after its arrival at STA 1002. STA 1004 may respond to frame 1018 by transmitting a frame 1020 to STA 1002. Frame 1020 may comprise an acknowledgement (Ack) frame, a BA frame, a control frame, a management frame, an action frame, or a data frame, for example. In example 1000, where frame 1018 comprises a data frame, frame 1020 may be a BA frame.

[00128] In another embodiment, as illustrated in examples 1100 and 1200 shown in FIGs. 11 and 12 respectively, on receiving frame 1016 from STA 1004, STA 1002 transmits a response frame (e.g., frame 1102 in FIG. 11 or frame 1202 in FIG. 12) in response to frame 1016, to STA 1004. The response frame may comprise an ICR, a CTS frame, an Ack frame, a BA frame, or a control frame, for example. For example, the response frame may be an ICR in response to frame 1016 being an ICF, a CTS frame in response to frame 1016 being an RTS frame, or an Ack/BA frame in response to frame 1016 being a data frame.

[00129] In an embodiment, the response frame may indicate whether STA 1002 has buffered traffic for STA 1004. In example 1100, STA 1002 may have buffered traffic for STA 1004 when STA 1002 receives frame 1016 from STA 1004. As such, the response frame (frame 1102) indicates that STA 1002 has buffered traffic for STA 1004. Frame 1102 may further indicate a traffic identifier (TID) or an access category (AC) of the buffered traffic. In an embodiment, when the response frame indicates that STA 1002 has buffered traffic for STA 1004, STA 1004 may be configured to remain available to receive the buffered traffic from STA 1002. In an embodiment, STA 1004 may be configured to not access the wireless medium for transmission after receiving the response frame indicating that STA 1002 has buffered traffic for STA 1004. As such, in example 1100, after receiving frame 1102 indicating that STA 1002 has buffered traffic for STA 1004, STA 1004 remains available to receive frame 1018 described above from STA 1002. STA 1002 may transmit frame 1020 described above in response to frame 1018.

[00130] In example 1200, STA 1002 may not have buffered traffic for STA 1004 when STA 1002 receives frame 1016 from STA 1004. As such, the response frame (frame 1202) indicates that STA 1002 has no buffered traffic for STA 1004. In an embodiment, when the response frame indicates that STA 1002 has no buffered traffic for STA 1004, STA 1004 may be configured to enter a doze state or to return to being available, e.g., to accommodate transmission/reception by other radio technologies. STA 1004 may be in the doze state until the end of the remaining portion of the period of unavailability announced/indicated in frame 1014.

[00131] In another embodiment, not shown in FIGs. 11 and 12, STA 1002 may be configured to transmit the response frame to frame 1018 only when STA 1002 has buffered traffic of a certain category for STA 1004. For example, STA 1002 may be configured to transmit the response frame only STA 1002 has low latency buffered traffic for STA 1004. In another embodiment, the response frame may only indicate whether STA 1002 has low latency buffered traffic for STA 1004.

[00132] In another embodiment, as illustrated in examples 1300 and 1400 shown in FIGs 13 and 14 respectively, STA 1002 may be configured, on having data arrive for transmission to STA 1004 during the period of unavailability announced/indicated in frame 1014, to transmit to STA 1004 a probe frame (e.g., frame 1302 in FIG. 13 or frame 1402) that probes whether STA 1004 is available for communication. The probe frame may further indicate that STA 1002 has buffered traffic for STA 1004. The probe frame may comprise an ICF, a trigger frame, an RTS frame, an MU-RTS frame, a buffer status report poll (BSRP) trigger frame, or a block ack request (BAR) frame. If the period of unavailability of STA 1004 has ended when STA 1002 transmits the probe frame, STA 1004 may receive the probe frame and may respond to the probe frame by transmitting to STA 1002 frame 1016, described above, or an immediate response frame. Otherwise, if the period of unavailability of STA 1004 has not ended when STA 1002 transmits the probe frame, STA 1004 may not receive the probe frame and may not respond to the probe frame. STA 1002 may re-transmit the probe frame after a first time delay. STA 1002 may determine the first time delay based on network conditions.

[00133] For illustration, in example 1300, STA 1002 transmits the probe frame (frame 1302) to STA 1004 after the actual period of unavailability of STA 1004 has ended. STA 1004 thus receives frame 1302 and responds to frame 1302 by transmitting frame 1016 (or an immediate response frame) to STA 1002. On receiving frame 1016 (or the immediate response frame), STA 1002 may transmit to STA 1004 frame 1018 as described above. In example 1400, STA 1002 transmits a first probe frame (frame 1402) to STA 1004 before the actual period of unavailability of STA 1004 has ended. STA 1004 may not receive frame 1402 and does not respond to frame 1402. After waiting the first time delay, STA 1002 may transmit a second probe frame (frame 1404) to STA 1004. In example 1400, STA 1002 transmits frame 1404 to STA 1004 after the actual period of unavailability of STA 1004 has ended. STA 1004 thus receives frame 1404 and responds to frame 1404 by transmitting frame 1016 (or an immediate response frame) to STA 1002. On receiving frame 1016 (or the immediate response frame), STA 1002 may transmit to STA 1004 frame 1018 as described above.

[00134] In another embodiment, not shown in FIGs. 13 and 14, STA 1002 may be configured to transmit the probe frame to STA 1004 only when STA 1002 has buffered traffic of a certain category for STA 1004. For example, STA 1002 may be configured to transmit the probe frame only when STA 1002 has low latency buffered traffic for STA 1004. In another embodiment, the probe frame may only indicate whether STA 1002 has low latency buffered traffic for STA 1004.

[00135] In another embodiment, as illustrated in example 1500 of FIG. 15, STA 1004 may be configured, when an actual period of unavailability of STA 1004 ends during the period of unavailability announced/indicated in frame 1014, to transmit to STA 1002 frame 1016, described above, after waiting for a delay 1502 from the end of the actual period of unavailability of STA 1004. In an embodiment, STA 1002 may transmit to STA 1004 a frame indicating delay 1502. The frame indicating delay 1502 may be a beacon frame, a probe response frame, an association response frame, a control frame, a management frame, a QoS null/data frame, or an action frame. In another embodiment, STA 1004 may transmit to STA 1002 a frame indicating delay 1502. The frame indicating delay 1502 may be a probe request frame, an association request frame, a control frame, a management frame, a QoS null/data frame, or an action frame. In another embodiment, delay 1502 may be pre-configured within STA 1004. In an embodiment, delay 1502 may correspond to a medium synchronization delay. That is, delay 1502 may correspond to a minimum amount of time that STA 1004 must listen to the wireless medium for before attempting to access the medium using EDCA. In an embodiment, STA 1004 may transmit frame 1016 using EDCA. STA may wait for delay 1502 after the end of the actual period of unavailability of STA 1004 before invoking a backoff procedure of EDCA to transmit frame 1016.

[00136] In another embodiment, as illustrated in example 1600 of FIG. 16, STA 1004 may be allowed to transmit to STA 1002 frame 1016 before having fully waited delay 1502 from the end of the actual period of unavailability of STA 1004, on condition of receiving a frame from STA 1004 after the end of the actual period of unavailability of STA 1004. In accordance with this embodiment, STA 1002 may be configured, when STA 1004 is unavailable for communication, to communicate with a STA other than STA 1004. For example, in example 1600, STA 1002 may communicate with a STA 1602 after the period of unavailability of STA 1004 begins. Where STA 1002 is an AP STA, STA 1602 may be for example a non-AP STA associated with STA 1002. In example 1600, STA 1002 may receive a data frame 1604 from STA 1602 and may transmit a frame 1606 to STA 1602. Frame 1606 may be a BA frame in response to data frame 1604. Frame 1606 may be a control frame, a management frame, a data frame, an action frame, or a QoS null frame.

[00137] When the actual period of unavailability of STA 1004 ends, STA 1004 may launch a timer corresponding to delay 1502 to transmit frame 1016 using EDCA to STA 1002. However, on receiving frame 1606 from STA 1002, STA 1004 recovers medium synchronization without having to wait for the entirety of delay 1502 and may thus be allowed to access the wireless medium using EDCA. In an embodiment, based on frame 1606 (e.g., a duration field of frame 1606), STA 1004 may determine that communication between STA 1002 and STA 1602 ends with frame 1606. Thus, on receiving frame 1606 from STA 1002, STA 1004 may invoke the backoff procedure of EDCA to transmit frame 1016 to STA 1002. In another embodiment, based on frame 1606 (e.g., a duration field of frame 1606), STA 1004 may determine that communication between STA 1002 and STA 1602 may end a specific period after frame 1606. STA 1004 may wait for the specific period further before invoking the backoff procedure of EDCA to transmit frame 1016 to STA 1002.

[00138] FIG. 17 illustrates an example 1700 of another procedure according to an embodiment. As shown in FIG. 17, in example 1700, STA 1004 may transmit to STA 1002 a frame 1702 that may indicate a plurality of periods of unavailability (e.g., UP1 and UP2) of STA 1004. The plurality of periods of unavailability may correspond to consecutive periods of unavailability among periods of unavailability of STA 1004. In an implementation, frame 1702 may indicate in frame 1702 a start time and an end time or a duration/ interval of each of the plurality of periods of unavailability of STA 1004. In another implementation, the plurality of periods of unavailability may be periodic. STA 1004 may thus indicate in frame 1702 a start time of a first period of unavailability of the plurality of periods of unavailability, an end time or a duration/interval of the first period of unavailability, and a period for the plurality of periods of unavailability. Like frame 1014 described above, frame 1702 may be a control frame, an ICF, an ICR, a PS-poll frame, an RTS frame, an MU-RTS frame, a QoS null frame, a QoS data frame, an action frame, or a management frame, for example.

[00139] On receiving frame 1702, STA 1002 may determine the plurality of periods of unavailability (e.g., UP1 and UP2) of STA 1004. When the first period of unavailability (UP1) of STA 1004 begins and without a further indication from STA 1004 regarding the first period of unavailability, STA 1002 may be configured to refrain from any transmission to STA 1004 until the end of the first period of unavailability. STA 1002 may communicate with STA 1004 after the end of first period of unavailability and before the beginning of the second period of unavailability. After the second period of unavailability begins and without a further indication from STA 1004 regarding the second period of unavailability, STA 1002 may be configured to refrain from any transmission to STA 1004 until the end of the second period of unavailability. [00140] In example 1700, a first actual period of unavailability of STA 1004 corresponding to the first period of unavailability may end before the end of the first period of unavailability. STA 1004 may thus transmit to STA 1002 a frame 1704 indicating that the first period of unavailability has ended. In an embodiment, STA 1004 may indicate in frame 1704 that STA 1004 is available for communication until an end of the first period of unavailability announced/indicated in frame 1702. In an embodiment, STA 1004 may transmit frame 1704 on condition that, when the first actual period of unavailability of STA 1004 ends, a remaining portion of the first period of unavailability announced/indicated in frame 1702 is greater than a pre-determined duration (e.g., at least 5 milliseconds remain of the period of unavailability announced/indicated in frame 1702). In embodiments, frame 1704 may comprise a control frame, an ICF, an acknowledgement frame, a BA frame, a PS-poll frame, an RTS frame, a CTS frame, an MU-RTS frame, a QoS null frame, a QoS data frame, an action frame, or a management frame, for example.

[00141] On receiving frame 1704 from STA 1004, STA 1002 may determine that the first period of unavailability of STA 1004 has ended and may transmit a frame 1706 to STA 1004. Frame 1706 may comprise a control frame, a management frame, an action frame, a data frame, a QoS data frame, or a QoS null frame, for example. In example 1700, frame 1706 may be a data frame that comprises data buffered for STA 1004. STA 1004 may respond to frame 1706 by transmitting a frame 1708 to STA 1002. Frame 1708 may comprise an Ack frame, a BA frame, a control frame, a management frame, an action frame, or a data frame, for example. In example 1700, where frame 1706 comprises a data frame, frame 1708 may be a BA frame.

[00142] In example 1700, frame 1704 does not indicate information regarding the second period of unavailability of STA 1004 indicated/announced in frame 1702. In an embodiment (as illustrated in example 1700), based on frame 1704 not indicating information regarding the second period of unavailability of STA 1004, STA 1002 may determine that the second period of unavailability of STA 1004 has not been cancelled. As such, after the second period of unavailability begins and without a further indication from STA 1004 regarding the second period of unavailability, STA 1002 may refrain from any transmission to STA 1004 until the end of the second period of unavailability. In another embodiment (not shown in FIG. 17), based on frame 1704 not indicating information regarding the second period of unavailability of STA 1004, STA 1002 may determine that the second period of unavailability of STA 1004 is cancelled. STA 1002 may thus attempt to communicate with STA 1004 during the second period of unavailability. In this embodiment, to indicate that the second period of unavailability of STA 1004 is being maintained, STA 1004 may indicate the second period of unavailability again in frame 1704. In an embodiment, similar to FIG. 13, FIG. 14, and FIG. 16, STA 1002 may transmit a frame to STA 1004 during the first period (UP1). This frame may indicate that STA 1002 has buffered traffic (e.g., LL data) for STA 1004.

[00143] In another embodiment, illustrated in example 1800 of FIG. 18, both a first actual period of unavailability of STA 1004 corresponding to the first period of unavailability and a second actual period of unavailability of STA 1004 corresponding to the second period of unavailability indicated/announced in frame 1702 may end or be cancelled during the first period of unavailability of STA 1004. Accordingly, STA 1004 may thus transmit to STA 1002 a frame 1802 indicating that the first period of unavailability has ended and that the second period of unavailability is cancelled. In embodiments, frame 1802 may comprise a control frame, an ICF, an acknowledgement frame, a BA frame, a PS-poll frame, an RTS frame, a CTS frame, an MU-RTS frame, a QoS null frame, a QoS data frame, an action frame, or a management frame, for example. [00144] On receiving frame 1802 from STA 1004, STA 1002 may determine that the first period of unavailability of STA 1004 has ended and may transmit frame 1706 to STA 1004 during the first period of unavailability of STA 1004. STA 1004 may respond to frame 1706 by transmitting a frame 1708 to STA 1002. STA 1002 may also determine that the second period of unavailability of STA 1004 has been cancelled. As such, as shown in example 1800, STA 1002 may attempt to communicate with STA 1004 during the second period of unavailability. For example, STA 1002 may transmit to STA 1004 a frame 1804 and may receive from STA 1004 a frame 1806.

[00145] FIG. 19 illustrates an example process 1900 according to an embodiment. Example process 1900 may be performed by a first STA, such as STA 1002, for example. The first STA may be an AP STA or a non-AP STA. As shown in FIG. 19, process 1900 may include steps 1902 and 1904.

[00146] Step 1902 includes receiving, by the first STA from a second STA, a first frame indicating a first period of unavailability of the second STA. The second STA may be STA 1004 described above. The second STA may be an AP STA or a non-AP STA. In an embodiment, the first STA may be an AP STA and the second STA may be a non-AP STA. The second STA may be associated with the first STA.

[00147] The first frame may comprise a control frame, an ICF, an ICR, a PS-poll frame, an RTS frame, an MU-RTS frame, a QoS null frame, a QoS data frame, an action frame, or a management frame, for example.

[00148] Step 1904 includes receiving, by the first STA from the second STA and during the period of unavailability, a second frame indicating that the period of unavailability ended. In an embodiment, the second frame indicates that the second STA is available until an end of the first period of unavailability. In another embodiment, the second frame may indicate that an event related to the first period of unavailability ended. The event may comprise an I DC interference event.

[00149] The second frame may comprise a control frame, an ICF, an acknowledgement frame, a BA frame, a PS-poll frame, an RTS frame, a CTS frame, an MU-RTS frame, a QoS null frame, a QoS data frame, an action frame, or a management frame, for example.

[00150] In an embodiment, the first frame indicates a second period of unavailability of the second STA. The second period of unavailability may be consecutive to the first period of unavailability among periods of unavailability of the second STA. In an embodiment, the periods of unavailability of the second STA are periodic. The first frame may indicate a period (frequency) of the periods of unavailability of the second STA. In an embodiment, the first period of unavailability and the second period of unavailability are separated by the period. In an embodiment, the second frame further indicates information regarding the second period of unavailability of the second STA. For example, the second frame may indicate that the second period of unavailability has ended or has been cancelled. In another example, the second frame may indicate that the second period of unavailability is maintained.

[00151] In an embodiment, process 1900 may further comprise not communicating, by the first STA, with the second STA during the first period of unavailability. In an embodiment, process 1900 may further comprise, based on the first frame, communicating, by the first STA, with a third STA during the first period of unavailability. [00152] In an embodiment, process 1900 may further comprise, after receiving the second frame, transmitting, by the first STA to the second STA, a third frame. The third frame may comprise a control frame, a management frame, an action frame, a data frame, low latency data, latency sensitive data, urgent data, a QoS data frame, or a QoS null frame, for example.

[00153] In an embodiment, process 1900 may further comprise receiving, by the first STA from the second STA, a fourth frame in response to the third frame. The fourth frame may comprise an Ack frame, a BA frame, a control frame, a management frame, an action frame, or a data frame, for example.

[00154] In an embodiment, process 1900 may further comprise, in response to the second frame, transmitting, by the first STA to the second STA, a fifth frame. The fifth frame may comprise an ICR, a CTS frame, an Ack frame, a BA frame, or a control frame, for example. In an embodiment, process 1900 may further comprise transmitting the third frame after transmitting the fifth frame. In an embodiment, the fifth frame indicates whether the first STA has buffered traffic for the second STA.

[00155] In an embodiment, process 1900 may further comprise transmitting, by the first STA to the second STA, a sixth frame indicating that the first STA has the third frame for transmission for the second STA. The sixth frame may comprise an I CF, a trigger frame, an RTS frame, a BSRP trigger frame, a BAR frame, or an MU-RTS frame, for example.

[00156] In an embodiment, process 1900 may further comprise, in response to the sixth frame, receiving, by the first STA from the second STA, the second frame or an immediate response frame. In an embodiment, process 1900 may further comprise, based on not receiving the second frame or the immediate response frame from the second STA in response to the sixth frame, re-transmitting, by the first STA to the second STA, the sixth frame. In an embodiment, at least a first time delay separates the re-transmitting of the sixth frame from the transmitting of the sixth frame. In an embodiment, process 1900 may further comprise determining, by the first STA, the first time delay based on network conditions.

[00157] In an embodiment, process 1900 may further comprise transmitting, by the first STA to the second STA, a seventh frame indicating a second time delay. The seventh frame may comprise a beacon frame, a probe response frame, an association response frame, a control frame, a management frame, a QoS null/data frame, or an action frame, for example. In an embodiment, the second time delay comprises a medium synchronization delay. In an embodiment, the first STA may be configured to transmit the second frame using ECDA. The first STA may be configured to wait for the second time delay before invoking a backoff procedure using EDCA.

[00158] FIG. 20 illustrates another example process 2000 according to an embodiment. Example process 2000 may be performed by a first STA, such as STA 1004, for example. The first STA may be an AP STA or a non-AP STA. As shown in FIG. 20, process 2000 may include steps 2002 and 2004.

[00159] Step 2002 includes transmitting, by the first STA to a second STA, a first frame indicating a first period of unavailability of the first STA. The second STA may be STA 1002 described above. The second STA may be an AP STA or a non-AP STA. In an embodiment, the first STA may be a non-AP STA and the second STA may be an AP STA. The first STA may be associated with the second STA. [00160] The first frame may comprise a control frame, an ICF, an ICR, a PS-poll frame, an RTS frame, an MU-RTS frame, a QoS null frame, a QoS data frame, an action frame, or a management frame, for example.

[00161] Step 2004 includes transmitting, by the first STA to the second STA and during the first period of unavailability, a second frame indicating that the period of unavailability ended.

[00162] In an embodiment, the second frame indicates that the first STA is available until an end of the first period of unavailability. In another embodiment, the second frame may indicate that an event related to the first period of unavailability ended. The event may comprise an IDC interference event.

[00163] The second frame may comprise a control frame, an ICF, an acknowledgement frame, a BA frame, a PS-poll frame, an RTS frame, a CTS frame, an MU-RTS frame, a QoS null frame, a QoS data frame, an action frame, or a management frame, for example.

[00164] In an embodiment, transmitting the second frame in step 2004 comprises transmitting the second frame using EDCA, listen-before-talk (LBT), or distributed channel access (DCF).

[00165] In an embodiment, the first frame indicates a second period of unavailability of the first STA. The second period of unavailability may be consecutive to the first period of unavailability among periods of unavailability of the first STA. In an embodiment, the periods of unavailability of the first STA are periodic. The first frame may indicate a period (frequency) of the periods of unavailability of the first STA. In an embodiment, the first period of unavailability and the second period of unavailability are separated by the period. In an embodiment, the second frame further indicates information regarding the second period of unavailability of the first STA. For example, the second frame may indicate that the second period of unavailability has ended or has been cancelled. In another example, the second frame may indicate that the second period of unavailability is maintained.

[00166] In an embodiment, process 2000 may further comprise not communicating, by the first STA, with the second STA during the first period of unavailability.

[00167] In an embodiment, process 2000 may further comprise, after transmitting the second frame, receiving, by the first STA from the second STA, a third frame. The third frame may comprise a control frame, a management frame, an action frame, a data frame, low latency data, latency sensitive data, urgent data, a QoS data frame, or a QoS null frame, for example.

[00168] In an embodiment, process 2000 may further comprise transmitting, by the first STA to the second STA, a fourth frame in response to the third frame. The fourth frame may comprise an Ack frame, a BA frame, a control frame, a management frame, an action frame, or a data frame, for example.

[00169] In an embodiment, process 2000 may further comprise, in response to the second frame, receiving, by the first STA from the second STA, a fifth frame. The fifth frame may comprise an ICR, a CTS frame, an Ack frame, a BA frame, or a control frame, for example. In an embodiment, process 2000 may further comprise receiving the third frame after receiving the fifth frame. In an embodiment, the fifth frame indicates whether the second STA has buffered traffic for the first STA. [00170] In an embodiment, process 2000 may further comprise receiving, by the first STA from the second STA, a sixth frame indicating that the second STA has the third frame for transmission for the first STA. The sixth frame may comprise an ICF, a trigger frame, an RTS frame, a BSRP trigger frame, a BAR frame, or an MU-RTS frame, for example. In another embodiment, the sixth frame may be configured to check whether the first STA is available for communication.

[00171] In an embodiment, process 2000 may further comprise, in response to the sixth frame, transmitting, by the first STA to the second STA, the second frame or an immediate response frame.

[00172] In an embodiment, process 2000 may further comprise receiving, by the first STA from the second STA, a seventh frame indicating a time delay. The seventh frame may comprise a beacon frame, a probe response frame, an association response frame, a control frame, a management frame, a QoS null/data frame, or an action frame, for example. In an embodiment, the time delay comprises a medium synchronization delay. In an embodiment, process 2000 may further comprise waiting, by the first STA, for at least the time delay before invoking a backoff procedure of EDCA to transmit the second frame.

[00173] In an embodiment, process 2000 may further comprise receiving, by the first STA from the second STA, an eight frame while the first STA is waiting for at least the time delay; and after receiving the eighth frame, transmitting, by the first STA to the second STA, the second frame. The eighth frame may comprise an Ack frame, a BA frame, or a data frame.

Claims

CLAIMS What is claimed is:

1. A method comprising: receiving, by an access point (AP) from a first station (STA) , a control frame indicating a period of unavailability of the first STA; based on the first frame, communicating, by the AP, with a second STA during the period of unavailability; receiving, by the AP from the first STA and during the period of unavailability, a Quality of Service (QoS) null frame indicating that the period of unavailability ended; after receiving the QoS null frame, transmitting, by the AP to the first STA, a data frame; and in response to the data frame, receiving, by the AP from the first STA, an acknowledgement frame.

2. A method comprising: receiving, by a first station (STA) from a second STA, a first frame indicating a first period of unavailability of the second STA; and receiving, by the first STA from the second STA and during the first period of unavailability, a second frame indicating that the first period of unavailability ended.

3. The method of claim 2, wherein the second frame indicates that the second STA is available until an end of the first period of unavailability.

4. The method of any of claims 2-3, wherein the second frame indicates that an event related to the first period of unavailability ended.

5. The method of claim 4, wherein the event comprises an in-device coexistence (IDC) interference event.

6. The method of any of claims 2-5, wherein the first frame indicates a second period of unavailability of the second STA.

7. The method of claim 6, wherein the second period of unavailability is consecutive to the first period of unavailability among periods of unavailability of the second STA.

8. The method of claim 7, wherein the periods of unavailability of the second STA are periodic.

9. The method of claim 8, wherein the first frame indicates a period (frequency) of the periods of unavailability of the second STA.

10. The method of claim 9, wherein the first period of unavailability and the second period of unavailability are separated by the period.

11. The method of any of claims 6-10, wherein the second frame further indicates that the second period of unavailability ended.

12. The method of any of claims 2-11, further comprising not communicating, by the first STA, with the second STA during the first period of unavailability.

13. The method of any of claims 2-12, wherein the first frame comprises a control frame, an initial control frame (ICF), an initial control response (ICR), a power save (PS)-poll frame, a request-to-send (RTS) frame, a multi-user (MU)- RTS frame, a Quality of Service (QoS) null frame, a QoS data frame, an action frame, or a management frame

14. The method of any of claims 2-12, wherein the second frame comprises a control frame, an initial control frame (ICF), an acknowledgement frame, a blockack (BA) frame, a power save (PS)-poll frame, a request-to-send (RTS) frame, a clear-to-send (CTS) frame, a multi-user (MU)-RTS frame, a Quality of Service (QoS) null frame, a QoS data frame, an action frame, or a management frame.

15. The method of any of claims 2-14, further comprising, based on the first frame, communicating, by the first STA, with a third STA during the first period of unavailability.

16. The method of any of claims 2-15, further comprising, after receiving the second frame, transmitting, by the first STA to the second STA, a third frame.

17. The method of claim 16, wherein the third frame comprises a control frame, a management frame, an action frame, a data frame, low latency data, latency sensitive data, urgent data, a Quality of Service (QoS) data frame, or a QoS null frame.

18. The method of any of claims 16-17, further comprising receiving, by the first STA from the second STA, a fourth frame in response to the third frame.

19. The method of claim 18, wherein the fourth frame comprises an acknowledgement (Ack) frame, a blockack (BA) frame, a control frame, a management frame, an action frame, or a data frame.

20. The method of any of claims 16-19, further comprising, in response to the second frame, transmitting, by the first STA to the second STA, a fifth frame.

21. The method of claim 20, wherein the fifth frame comprises an initial control response (ICR), a clear-to-send (CTS) frame, an acknowledgment (Ack) frame, a blockack (BA) frame, or a control frame.

22. The method of any of claims 20-21, comprising transmitting the third frame after transmitting the fifth frame.

23. The method of any of claims 20-21, wherein the fifth frame indicates whether the first STA has buffered traffic for the second STA.

24. The method of any of claims 16-19, further comprising transmitting, by the first STA to the second STA, a sixth frame indicating that the first STA has the third frame for the second STA.

25. The method of claim 24, further comprising, in response to the sixth frame, receiving, by the first STA from the second STA, the second frame or an immediate response frame.

26. The method of claim 25, further comprising, based on not receiving the second frame or the immediate response frame from the second STA in response to the sixth frame, re-transmitting, by the first STA to the second STA, the sixth frame.

27. The method of claim 26, wherein at least a first time delay separates the re-transmitting of the sixth frame from the transmitting of the sixth frame.

28. The method of claim 27, further comprising determining, by the first STA, the first time delay based on network conditions.

29. The method of any of claims 24-28, wherein the sixth frame comprises an initial control frame (IGF), a trigger frame, a request-to-send (RTS) frame, a buffer status report poll (BSRP) trigger frame, a block ack request (BAR) frame or a multi-user (MU)-RTS frame.

30. The method of any of claims 2-29, further comprising transmitting, by the first STA to the second STA, a seventh frame indicating a second time delay.

31. The method of claim 30, wherein the seventh frame comprises a beacon frame, a probe response frame, an association response frame, a control frame, a management frame, a QoS null/data frame, or an action frame.

32. The method of any of claims 30-31, wherein the second time delay comprises a medium synchronization delay.

33. The method of any of claims 30-32, wherein the second STA is configured to transmit the second frame using enhanced distributed channel access (EDCA).

34. The method of claim 33, wherein the second STA is configured to wait for the second time delay before invoking an EDCA backoff procedure to transmit the second frame.

35. The method of any of claims 2-34, wherein the first STA is a non-AP STA or an AP STA.

36. The method of claim 35, wherein the second STA is an AP STA or a non-AP STA.

37. A method comprising: transmitting, by a station (STA) to an access point (AP), a control frame indicating a period of unavailability of the STA; transmitting, by the STA to the AP and during the period of unavailability, a Quality of Service (QoS) null frame indicating that the period of unavailability ended; and after transmitting the QoS null frame, receiving, by the STA from the AP, a data frame.

38. A method comprising: transmitting, by a first station (STA) to a second STA, a first frame indicating a first period of unavailability of the first STA; and transmitting, by the first STA to the second STA and during the first period of unavailability, a second frame indicating that the first period of unavailability ended.

39. The method of claim 38, wherein the second frame indicates that the first STA is available until an end of the first period of unavailability.

40. The method of any of claims 38-39, wherein the second frame indicates that an event related to the first period of unavailability ended.

41. The method of claim 40, wherein the event comprises an in-device coexistence (I DC) interference event.

42. The method of any of claims 38-41, wherein the first frame indicates a second period of unavailability of the first STA.

43. The method of claim 42, wherein the second period of unavailability is consecutive to the first period of unavailability among periods of unavailability of the first STA.

44. The method of claim 43, wherein the periods of unavailability of the first STA are periodic.

45. The method of claim 44, wherein the first frame indicates a period (frequency) of the periods of unavailability of the first STA.

46. The method of claim 45, wherein the first period of unavailability and the second period of unavailability are separated by the period.

47. The method of any of claims 45-46, wherein the second frame further indicates that the second period of unavailability ended.

48. The method of any of claims 38-47, further comprising not communicating, by the first STA, with the second STA during the first period of unavailability.

49. The method of any of claims 38-48, wherein the first frame comprises a control frame, an initial control frame (IGF), an initial control response (ICR), a power save (PS)-poll frame, a request-to-send (RTS) frame, a multi-user (MU)- RTS frame, a Quality of Service (QoS) null frame, a QoS data frame, an action frame, or a management frame.

50. The method of any of claims 38-48, wherein the second frame comprises a control frame, an initial control frame (ICF), an acknowledgement frame, a blockack (BA) frame, a power save (PS)-poll frame, a request-to-send (RTS) frame, a clear-to-send (CTS) frame, a multi-user (MU)-RTS frame, a Quality of Service (QoS) null frame, a QoS data frame, an action frame, or a management frame.

51. The method of any of claims 38-50, wherein transmitting the second frame comprises transmitting the second frame using enhanced distributed channel access (EDCA), listen-before-talk (LBT), or distributed channel access (DCF).

52. The method of any of claims 38-51, further comprising, after transmitting the second frame, receiving, by the first STA from the second STA, a third frame.

53. The method of claim 52, wherein the third frame comprises a control frame, a management frame, an action frame, a data frame, low latency data, latency sensitive data, urgent data, a Quality of Service (QoS) data frame, or a QoS null frame.

54. The method of any of claims 52-53, further comprising transmitting, by the first STA to the second STA, a fourth frame in response to the third frame.

55. The method of claim 54, wherein the fourth frame comprises an acknowledgement (Ack) frame, a blockack (BA) frame, a control frame, a management frame, an action frame, or a data frame.

56. The method of any of claims 52-55, further comprising, in response to the second frame, receiving, by the first STA from the second STA, a fifth frame.

57. The method of claim 56, wherein the fifth frame comprises an initial control response (ICR), a clear-to-send (CTS) frame, an acknowledgment (Ack) frame, a blockack (BA) frame, or a control frame.

58. The method of any of claims 56-57, comprising receiving the third frame after receiving the fifth frame.

59. The method of any of claims 56-57, wherein the fifth frame indicates whether the second STA has buffered traffic for the first STA.

60. The method of any of claims 52-55, further comprising receiving, by the first STA from the second STA, a sixth frame indicating that the second STA has the third frame for the first STA.

61. The method of claim 60, further comprising, in response to the sixth frame, transmitting, by the first STA to the second STA, the second frame.

62. The method of any of claims 60-61, wherein the sixth frame comprises an initial control frame (IGF), a trigger frame, a request-to-send (RTS) frame, a buffer status report poll (BSRP) trigger frame, a block ack request (BAR) frame, or a multi-user (MU)-RTS frame.

63. The method of any of claims 38-62, further comprising receiving, by the first STA from the second STA, a seventh frame indicating a time delay.

64. The method of claim 63, wherein the seventh frame comprises a beacon frame, a probe response frame, an association response frame, a control frame, a management frame, a QoS null/data frame, or an action frame.

65. The method of any of claims 63-64, wherein the time delay comprises a medium synchronization delay.

66. The method of any of claims 63-65, wherein transmitting the second frame comprises transmitting the second frame using enhanced distributed channel access (EDCA).

67. The method of claim 66, wherein the first STA is configured to wait for at least the time delay before invoking an EDCA backoff procedure to transmit the second frame.

68. The method of claim 67, further comprising: receiving, by the first STA from the second STA and while waiting for at least the time delay before invoking the EDCA backoff procedure to transmit the second frame, an eighth frame; and after receiving the eighth frame, transmitting, by the first STA to the second STA, the second frame.

69. The method of claim 68, wherein the eighth frame comprises an acknowledgment (Ack) frame, a blockack (BA) frame, or a data frame.

70. The method of any of claims 38-69, wherein the first STA is an AP STA or a non-AP STA.

71. The method of claim 70, wherein the second STA is a non-AP STA or an AP STA.

72. 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 -71.

73. 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-71.