Power saving operation and AP behavior for Coex unavailability

Abstract

The invention relates to power saving operation and AP behavior for Coex unavailability. Methods and apparatus for transmitting data in a wireless local area network are envisaged. In an embodiment, a first wireless device (AP) is configured to transmit a data packet to a second wireless device (STA), and transmit an initial control frame (ICF) to the STA, the ICF indicating a transmit opportunity time period (TXOP) for data transmission from the first wireless device to the second wireless device. In response to the ICF, the second wireless device returns an initial control response (ICR) indicating an unavailability (e.g., Coex unavailability) period of time. Alternatively, the STA may transmit an unsolicited unavailability advertisement (UUA) containing unavailability information for the STA to the AP without a prompt. In response to receiving the ICR or UUA, the AP may modify a transmission plan, such as shortening or cancelling the TXOP, or transmitting a portion of the data to another STA, etc. A power setting may be determined based on the unavailability time period.

Description

TECHNICAL FIELD

[0001] This application relates to wireless communications, including techniques and apparatus for implementing and handling coexistence (Coex) unavailability in wireless local area network architectures. BACKGROUND

[0002] Wireless communication systems are ubiquitous. In addition, wireless communication technology has evolved from voice-only communications to also include the transmission of data, such as Internet and multimedia content.

[0003] A mobile electronic device or station (STA) or user equipment device (UE) can take the form of a smartphone or tablet computer that a user typically carries. One aspect of wireless communications that can typically be performed by a mobile device can include wireless networking, such as over a wireless local area network (WLAN), which can include devices operating according to one or more of the IEEE 802.11 family of standards. In a wireless local area network, certain traffic can be delayed while other communications in the network are being performed. This can potentially result in performance degradation of traffic for which low latency is important, at least in some cases. Thus, improvements in this area are desirable. SUMMARY

[0004] Embodiments of systems, apparatuses, and methods are presented herein, among other things, for devices to transmit and receive unavailability announcements for coexistence in wireless local area network architectures, as well as to determine data transmissions (e.g., transmit opportunities (TXOP)) and adjust transmission durations based on unavailability of the devices.

[0005] A wireless device can include one or more antennas, one or more radios operably coupled to the one or more antennas, and a processor operably coupled to the one or more radios. The wireless device can be configured to establish a connection with an access point over a wireless local area network (WLAN) on one or more wireless links, or can be an access point configured to establish a connection with one or more other wireless devices over a WLAN on one or more wireless links. In some embodiments, the wireless device can operate in each of the multiple wireless links using a respective radio of the one or more radios.

[0006] The techniques described herein can be implemented in and / or used with a number of different types of devices, including but not limited to cellular phones, tablet computers, accessory and / or wearable computing devices, portable media players, base stations, access points, and other network infrastructure equipment, servers, unmanned aerial vehicles, unmanned aerial controllers, automobiles and / or motor vehicles, and any of various other computing devices.

[0007] This Summary is intended to provide a brief overview of some of the subject matter described in this document. Accordingly, it will be appreciated that the above-described features are merely examples and should not be construed to narrow the scope or spirit of the subject matter described herein. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following DETAILED DESCRIPTION, Figures, and Claims. BRIEF DESCRIPTION OF DRAWINGS

[0008] A better understanding of the present subject matter can be obtained when the following detailed description of the embodiments is considered in conjunction with the drawings.

[0009] Figure 1 An example wireless communication system including a wireless device is illustrated in accordance with some embodiments;

[0010] Figure 2 is a block diagram illustrating an example wireless device in accordance with some embodiments;

[0011] Figure 3 is a block diagram illustrating an example network element or access point in accordance with some embodiments;

[0012] Figure 4 is a block diagram illustrating an example modem or baseband processor in accordance with some embodiments;

[0013] Figure 5 is a flow diagram illustrating ICF / ICR exchange in accordance with embodiments described herein;

[0014] Figure 6A , Figure 6B A timeline for data packet transmission between an AP and a STA with periods of unavailability is illustrated in accordance with embodiments.

[0015] Figure 7 A timeline for data packet transmission between an AP and a STA with a Coex unavailability period that partially overlaps with a scheduled AP transmit opportunity (TXOP) is illustrated in accordance with embodiments.

[0016] Figure 8 A timeline for data packet transmission between an AP and a STA with a Coex unavailability period that occurs within the duration of a scheduled AP TXOP is illustrated in accordance with embodiments.

[0017] Figure 9 A timeline for ICF and ICR exchange in accordance with embodiments, where the ICR includes an announcement of a STA Coex unavailability period, and a timeline for updating a previously announced Coex unavailability period before the start of the previously announced Coex unavailability period is illustrated.

[0018] Figure 10 A timeline for ICF and IC exchange and subsequent data transmission is illustrated according to embodiments, where the ICR includes an announcement of a STA Coex Unavailability period, and a timeline for updating a previously announced Coex Unavailability period during the previously announced Coex Unavailability period.

[0019] Figure 11 A timeline for attempted exchange of ICF and ICR, ICF / ICR failure in the presence of an established Block Acknowledgement (BA) protocol, and subsequent repetition of ICF / ICR exchange is illustrated according to embodiments, where the STA has a Coex Unavailability duration during the attempted ICF / ICR exchange.

[0020] Figure 12A , Figure 12B Mitigation of the negative impact of ICF / ICR failure in the presence of a Block Acknowledgement (BA) protocol is illustrated according to embodiments, where the STA has a Coex Unavailability duration during the attempted and failed ICF / ICR exchange.

[0021] Figure 13 A timeline for attempted exchange of ICF and ICR, ICF / ICR failure in the absence of an established Block Acknowledgement (BA) protocol, and subsequent repetition of ICF / ICR exchange is illustrated according to embodiments, where the STA has a Coex Unavailability duration during the attempted and failed ICF / ICR exchange.

[0022] Figure 14A , Figure 14B Mitigation of the negative impact of ICF / IR failure in the absence of an established Block Acknowledgement (BA) protocol is illustrated according to embodiments, where the STA has a Coex Unavailability duration during the attempted and failed ICF / ICR exchange.

[0023] Figure 15 AP rate adaptation due to ICF / ICR failure with or without BA protocol is illustrated according to embodiments.

[0024] Figure 16A , Figure 16B Data packet transmission failure and recovery methods for the case where the Unavailability duration is partially within and partially outside of a scheduled TXOP are illustrated according to embodiments.

[0025] Figure 17A , Figure 17BA data packet transmission failure and recovery method is illustrated for the case where the duration of the unavailability lies completely within the scheduled TXOP, according to embodiments.

[0026] Figure 18 Acknowledgement of STA Coex unavailability received by the AP when the AP continues the TXOP with STA1 is illustrated, according to embodiments.

[0027] Figure 19A Acknowledgement of STA Coex unavailability received by the AP when the AP terminates the TXOP, with STA1 having an unavailability period, is illustrated, according to embodiments.

[0028] Figure 19B Acknowledgement of STA Coex unavailability received by the AP when the AP terminates the TXOP to STA1 and uses the TXOP for transmitting data to STA2, with STA1 having an unavailability period, and STA2 being a third party device, is illustrated, according to embodiments.

[0029] Figure 20A Acknowledgement of STA Coex unavailability received by the AP in response to receiving an ICR of an ICF, indicating the Coex unavailability of the STA and the power management mode of the STA at the end of the Coex unavailability period, is illustrated, according to embodiments.

[0030] Figure 20B A UUA indicating the Coex unavailability of the STA and the power management mode of the STA at the end of the Coex unavailability period, according to embodiments, is illustrated.

[0031] Figure 20C Interactions with power management modes are described for embodiments shown in Figure 20A , Figure 20B .

[0032] While the features described herein are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to be limiting, as the application is to be accorded the full scope of the claims as defined in the appended claims, and equivalents thereof. DETAILED DESCRIPTION

[0033] Acronyms

[0034] The following is a list of acronyms used in the present disclosure:

[0035] UE - User Equipment

[0036] AP - Access Point

[0037] UHR - Ultra High Reliability

[0038] HE - High Efficiency

[0039] HT - High Throughput

[0040] EHT - Extremely High Throughput

[0041] MU - Multi-User

[0042] MU-RTS - Multi-User Request To Send

[0043] MU-CTS - Multi-User Clear To Send

[0044] MU-BAR - Multi-User Block Ack Request

[0045] BSRP - Buffer Status Report Poll

[0046] TXOP - Transmit Opportunity

[0047] SIFS - Short Interframe Space

[0048] L-SIG - Legacy Signal

[0049] EIFS - Extended Interframe Space

[0050] ICF - Initial Control Frame

[0051] ICR - Initial Control Response

[0052] EMLSR - Enhanced Multi-Link Single Radio

[0053] BA - Block Ack

[0054] NAV - Network Allocation Vector

[0055] PPDU - Physical Layer Protocol Data Unit

[0056] TB - Trigger-Based

[0057] QoS - Quality of Service

[0058] QN - QoS Null

[0059] Terminology

[0060] The following are definitions of terminology used in this disclosure:

[0061] Memory Medium - any one or all of volatile and non-volatile, computer-readable media, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. The term "memory medium" specifically excludes propagated signals per se. Examples of a memory medium include, but are not limited to, random access memories (RAM), read only memories (ROM), programmable read-only memories (PROMs), erasable programmable read-only memories (EPROMs), electrically erasable

[0062] Carrier Medium - a memory medium as described above, and a physical transmission medium such as a bus, network, and / or other physical transmissions medium which conveys signals such as electrical, electromagnetic, or digital signals.

[0063] Computer System - various types of computing systems or processing systems including a personal computer system (PC), a server computer system, a wearable computer, a network appliance, an internet appliance, a smart phone, a television system, a grid computing system, or other device or combination of devices. In general, the term "computer system" can be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0064] User Equipment (UE) (or "UE Device") - any of various types of computer systems or devices that have a wireless interface and that are portable or otherwise moveable as users transport them. Examples of UE devices include mobile or portable personal computers, cellular telephones, smart phones, tablet computers, gaming devices, media players, Internet appliances, and similar devices. In general, the term "UE" or "UE device" can be broadly defined to encompass any electronic, computing, and / or telecommunications device (or combination of devices) capable of sending, receiving, and / or otherwise processing a signal. ™ ™ User Equipment (UE) (or "UE Device") - any of various types of computer systems or devices that have a wireless interface and that are portable or otherwise moveable as users transport them. Examples of UE devices include mobile or portable personal computers, cellular telephones, smart phones, tablet computers, gaming devices, media players, Internet appliances, and similar devices. In general, the term "UE" or "UE device" can be broadly defined to encompass any electronic, computing, and / or telecommunications device (or combination of devices) capable of sending, receiving, and / or otherwise processing a signal.

[0065] ​Wireless device or station (STA)—any of various types of computer systems or devices that perform wireless communication. A wireless device can be portable (or mobile) or can be stationary or fixed at a location. The terms "station" and "STA" are similarly used. A UE is one example of a wireless device.

[0066] Communication device—any of various types of computer systems or devices that perform communications, which can be wired or wireless. A communication device can be portable (or mobile) or can be stationary or fixed at a location. A wireless device is one example of a communication device. A UE is another example of a communication device.

[0067] Base station or access point (AP)—the term "base station" has all of its ordinary meanings and includes at least a wireless communication station installed at a fixed location and used to communicate as part of a wireless communication system. The term "access point" (or "AP") is often associated with Wi-Fi®-based communications and is used similarly.

[0068] Processing element (or processor)—refers to various elements or combinations of elements that can perform a function, e.g., a computation, in a device such as a communication device or a network infrastructure device. Processing elements can include, for example, processor cores and associated memory, circuitry such as an ASIC (application specific integrated circuit), portions or circuits of individual processor cores, entire processor cores, processor arrays, programmable hardware devices such as FPGAs (field programmable gate arrays), and / or larger portions of systems that include multiple processors, any combination thereof, and the like. A processing element can include a portion of a processing element, e.g., a core of an ASIC, a core of a processor, a core of a processor core, and / or a core of a processing core.

[0069] IEEE 802.11—refers to technologies based on IEEE 802.11 wireless standards such as 802.11a, 802.11b, 802.11g, 802.11n, 802.11-2012, 802.11ac, 802.11ad, 802.11ax, 802.11ay, 802.11be, and / or other IEEE 802.11 standards. IEEE 802.11 technologies can also be referred to as "Wi-Fi" or "wireless local area network (WLAN)" technologies.

[0070] Configured To - Various components can be described as being "configured to" perform one or more tasks. In such contexts, "configured to" is a broad recitation generally meant to encompass a wide variety of circumstances in which a component is configured to perform one or more tasks. Thus, a component can be configured to perform a task even when the component is not currently on or connected to an operating device. In some contexts, "configured to" can mean that a component is structurally designed or constructed to perform one or more tasks. In general, a component that is configured to perform a task is generally considered to be a structural equivalent of a component that performs the task.

[0071] For ease of description, various components can be described as performing one or more tasks. Such descriptions should be interpreted as including the phrase "configured to." A component that is configured to perform one or more tasks is expressly intended to invoke 35 U.S.C. § 112(f) interpretation.

[0072] Figures 1-2 Wireless Communication System

[0073] Figure 1 Examples of a wireless communication system are illustrated. Note that, Figure 1 represents one possibility among many, and features of the disclosure can be implemented by any of a variety of systems as desired. For example, the scenarios described herein can be implemented in any type of wireless device. The wireless communication system described below is one example.

[0074] As shown, the example wireless communication system includes an access point (AP) 102, which communicates with one or more wireless devices 106A, 106B, etc. over a transmission medium. The wireless devices 106A and 106B can be user devices such as stations (STAs), non-AP STAs, UEs, or other WLAN devices.

[0075] The STAs 106 can be devices with wireless network connectivity, such as mobile phones, handheld devices, wearable devices (e.g., such as smart watches, smart glasses, and / or head-mounted display devices), computers or tablets, unmanned aerial vehicles (UAVs), unmanned aerial controllers (UACs), automobiles, or almost any other type of wireless device. The STAs 106 can include a processor (processing element) configured to execute program instructions stored in memory. The STAs 106 can perform any of the methods described herein by executing one or more of such stored instructions. Alternatively, or additionally, the STAs 106 can include programmable hardware elements, such as an FPGA (field programmable gate array), integrated circuits (e.g., ASICs), programmable logic devices (PLDs), and / or any of a variety of other possible hardware components that are configured to execute (e.g., individually or in combination) any of the methods described herein or any portion of the methods described herein.

[0076] The AP 102 can be a standalone AP or an enterprise AP, can be a base transceiver station (BTS) or cell site, and can include hardware enabling wireless communication with the STA devices 106A and 106B. The AP 102 can also be equipped to communicate with the network 100 (e.g., a core network of a service provider (e.g., a cellular service provider, an internet service provider, and / or an operator), a WLAN, an enterprise network, and / or another communication network connected to the internet, among various possibilities). Thus, the AP 102 can facilitate communication between the STA devices 106 and / or between the STA devices 106 and the network 100. The AP 102 can be configured to provide communication through one or more wireless technologies, such as any of 802.11 a, 802.11 b, 802.11 g, 802.11 n, 802.11 ac, 802.11 ad, 802.11 ax, 802.11 ay, 802.11 be, and / or other 802.11 versions, and / or cellular protocols such as 6G, 5G, or LTE, including in unlicensed frequency bands.

[0077] The communication area (or coverage area) of the AP 102 can be referred to as a basic service area (BSA) or a cell. The AP 102 and the STAs 106 can be configured to communicate through a transmission medium using any of a variety of radio access technologies (RATs) or wireless communication technologies, such as Wi-Fi, LTE, LTE-Advanced (LTE-A), 5G NR, 6G, Ultra-Wide Band (UWB), etc.

[0078] Accordingly, the AP 102 and other similar access points (not shown) that operate according to one or more wireless communication technologies can be set up as a network that can provide continuous or nearly continuous overlapping service to the STA devices 106A to 106B and similar devices within a geographic area, e.g., via one or more communication technologies. STAs can roam directly from one AP to another or can transition between APs and / or network cells (e.g., such as cellular network cells).

[0079] Note that, at least in some cases, the STA devices 106 can be capable of communicating using any of a plurality of wireless communication technologies. For example, the STA devices 106 can be configured to communicate using Wi-Fi, LTE, LTE-A, 5G NR, 6G, Bluetooth, UWB, one or more satellite systems, etc. Other combinations of wireless communication technologies (including more than two wireless communication technologies) are also possible. Likewise, in some cases, the STA devices 106 can be configured to communicate using only a single wireless communication technology.

[0080] As shown, the example wireless communication system can also include an access point (AP) 104 that communicates with the wireless device 106B over a transmission medium. The AP 104 also provides a communication connection to the network 100. Thus, the wireless device can connect to either or both of the AP 102 (or another cellular base station) and the access point 104 (or another access point) to access the network 100. For example, the STA can roam from the AP 102 to the AP 104, e.g., based on one or more factors such as mobility, coverage, interference, and / or capability. Note that the AP 104 can also allow access to a different network than the network that the AP 102 allows access to (e.g., an enterprise Wi-Fi network, a home Wi-Fi network, etc.).

[0081] The STAs 106A and 106B can include handheld devices (such as smartphones or tablets), wearable devices (such as smartwatches, smartglasses, head-mounted display devices), and / or can include any of various types of devices that have wireless communication capability. For example, one or more of the STAs 106A and / or 106B can be a wireless device intended for fixed or nomadic deployment, such as a home appliance, a measurement device / sensor, a control device, etc.

[0082] STA 106B can also be configured to communicate with STA 106A. For example, STA 106A and STA 106B can be capable of performing direct device-to-device (D2D) communication. Note that such direct communication between STAs can also be referred to or alternatively be known as peer-to-peer (P2P) communication. Direct communication can be supported by the AP 102 (e.g., the AP 102 can facilitate discovery, as well as various forms of assistance), or can be performed in a manner that is unsupported by the AP 102. According to various examples, such P2P communication can be performed using any of 3GPP-based D2D communication technology, Wi-Fi based P2P communication technology, UWB, BT, and / or any of various other direct communication technologies.

[0083] The STA 106 can include one or more devices or integrated circuits for facilitating wireless communication, potentially including a Wi-Fi modem, a cellular modem, and / or one or more other wireless modems. The wireless modems can include one or more processors (processor elements) and various hardware components as described herein. The STA 106 can perform any of the methods described herein (or any portion thereof) by executing instructions on one or more programmable processors. For example, the STA 106 can be configured to perform techniques for performing channel state information reporting for multi-transmit receive point operation in a wireless communication system, such as according to the various methods described herein. Alternatively or additionally, the one or more processors can be one or more programmable hardware elements such as FPGA (field programmable gate array), ASIC (application specific integrated circuit), or other circuit that is configured to perform any of the methods described herein or any portion of the methods described herein. The wireless modems described herein can be used in a STA device as defined herein, a wireless device as defined herein, or a communication device as defined herein. The wireless modems described herein can also be used in an AP, a base station, a pico cell, a femto cell, and / or other similar network-side devices.

[0084] The STA 106 can include one or more antennas for communicating using two or more wireless communication protocols or radio access technologies (RATs). In some cases, the STA device 106 can be configured to communicate using a single shared radio. The shared radio can be coupled to a single antenna, or can be coupled to multiple antennas (e.g., for MIMO) for performing wireless communication. Alternatively, the STA device 106 can include two or more radios, each of which can be configured to communicate via a respective wireless link. Other configurations are also possible.

[0085] Figure 2 Example block diagram of a STA device

[0086] Figure 2 An example block diagram of a STA device, such as the STA 106, is illustrated. In some cases, the STA 106 can additionally or alternatively be referred to as a UE 106. The STA 106 can also be referred to as a non-AP STA 106. As shown, the STA 106 can include a system on chip (SOC) 200, which can include one or more portions configured for various purposes. Some or all of the various illustrated components (and / or other device components not illustrated, e.g., in variants and alternative arrangements) can be “communicatively coupled” or “operatively coupled,” which can be used herein to indicate components that can communicate, directly or indirectly, when the device is operational.

[0087] In some cases, the STA 106 can be configured as a multi-link device (MLD). In such cases, the STA 106 (e.g., one or more radio components of the STA 106) can be configured for concurrent data transmission and reception in multiple channels across a single band and / or multiple bands (e.g., such as the 2.4 GHz band, the 5 GHz band, and / or the 6 GHz band). Thus, the STA 106 (e.g., one or more radio components of the STA 106) can be configured to perform multi-link operations (MLO). For example, the STA 106 (e.g., one or more radio components of the STA 106) can be configured to perform simultaneous transmit receive (STR) operations (e.g., can be configured for simultaneous uplink and downlink traffic on a pair of links) and / or enhanced multi-link single radio (EMLSR) operations (e.g., can be configured such that a single radio component is used for simultaneously listening to two or more links).

[0088] As shown, SOC 200 can include a processor 202 that can execute program instructions for the STA 106 and a display circuit 204 that can perform graphics processing and provide a display signal to a display 260. SOC 200 can also include a motion sensing circuit 270 that can detect motion of the STA 106 in one or more dimensions, e.g., using a gyroscope, an accelerometer, and / or any of a variety of other motion sensing components. Processor 202 can also be coupled to a memory management unit (MMU) 240 that can be configured to receive addresses from the processor 202 and translate those addresses to locations in memory (e.g., a memory 206, a read only memory (ROM) 250, a flash memory 210). The MMU 240 can be configured to perform memory protection and page table translation or set up. In some cases, the MMU 240 can be included as part of the processor 202.

[0089] As shown, SOC 200 can be coupled to various other circuits of the STA 106. For example, the STA 106 can include various types of memory (e.g., including NAND flash 210), a connector interface 220 (e.g., for coupling to a computer system, a docking station, a charging station, etc.), a display 260, and wireless communication circuitry 230 (e.g., for LTE, LTE-A, 5G NR, 6G, Bluetooth, Wi-Fi, NFC, GPS, UWB, peer-to-peer (P2P), device-to-device (D2D), etc.).

[0090] The STA 106 can include at least one antenna, and in some cases can include multiple antennas, e.g., 235A and 235B, for performing wireless communication with access points, base stations, wireless stations, and / or other devices. For example, the STA 106 can use antennas 235A and 235B to perform wireless communication. As noted above, the STA 106 can be configured in some examples to use multiple wireless communication standards or radio access technologies (RATs) for wireless communication.

[0091] The wireless communication circuitry 230 may include a Wi-Fi modem 232, a cellular modem 234, and a Bluetooth modem 236. It should be noted that one or more of the Wi-Fi modem 232, cellular modem 234, and / or Bluetooth modem 236 may be configured for MLO, for example, as described above. The Wi-Fi modem 232 enables STA 106 to perform Wi-Fi or other WLAN communications, for example, on an 802.11 network. The Bluetooth modem 236 enables STA 106 to perform Bluetooth communications. The cellular modem 234 may be able to perform cellular communications according to one or more cellular communication technologies, for example, according to one or more 3GPP specifications.

[0092] As described herein, STA 106 may include hardware and software components for implementing aspects of this disclosure. For example, one or more components of the wireless communication circuitry 230 of STA 106 (e.g., Wi-Fi modem 232, cellular modem 234, BT modem 236) may be configured, for example, to implement part or all of the methods described herein for providing multi-user request transmission and allowing transmission using dedicated hardware components that may include ASICs (Application-Specific Integrated Circuits).

[0093] Figure 3 —Block diagram of the access point

[0094] Figure 3 An example block diagram of Access Point (AP) 104 is shown. In some cases (e.g., in an 802.11 communication context), AP 104 may also be referred to as a Station (STA), and may be more specifically referred to as an AP STA. Note that... Figure 3 The AP is merely one example of a possible access point. As shown, AP 104 may include a processor 304 capable of executing program instructions for AP 104. Processor 304 may also be coupled to a memory management unit (MMU) 340, which may be configured to receive addresses from processor 304 and translate these addresses into locations in memory (e.g., memory 360 and read-only memory (ROM) 350), or into other circuitry or devices.

[0095] In some cases, AP 104 can be configured as a multi-link device (MLD). In such cases, AP 104 (e.g., one or more radio components of AP 104) can be configured to perform concurrent data transmission and reception across a single frequency band and / or multiple frequency bands (e.g., such as the 2.4 GHz band, the 5 GHz band, and / or the 6 GHz band) on multiple channels. Therefore, AP 104 (e.g., one or more radio components of AP 104) can be configured to perform multi-link operation (MLO). For example, AP 104 (e.g., one or more radio components of AP 104) can be configured to perform simultaneous transmit and receive (STR) operation (e.g., configured for simultaneous uplink and downlink traffic on a pair of links) and / or enhanced multi-link single radio (EMLSR) operation (e.g., configured such that a single radio component can be used to simultaneously listen on two or more links).

[0096] AP 104 may include at least one network port 370. Network port 370 may be configured to be coupled to a network and provide network access to multiple devices such as STA device 106, as described above in this document. Figure 1 As described in the text.

[0097] Network port 370 (or an additional network port) may also be configured, or alternatively configured, to be coupled to a cellular network, such as the core network of a cellular service provider (e.g., an operator and / or cellular carrier). The core network may provide mobility-related services and / or other services to multiple devices, such as STA device 106. In some cases, network port 370 may be coupled to a telephone network via the core network, and / or the core network may provide a telephone network (e.g., in other STA devices served by a cellular service provider).

[0098] The AP 104 can include one or more radios 330A-N and at least one antenna 334 (and possibly multiple antennas), which can be coupled to one or more respective communication chains. The antenna 334 can be configured to operate in conjunction with one or more other components as a wireless transceiver and can also be configured to communicate with the STA devices 106 via the radios 330A-N. Note that one or more of the radios 330A-N can be configured for MLO, e.g., as described above. The antennas 334A-N communicate with one or more respective radios 330A-N via communication chains 332A-N. The communication chains 332 can be receive chains, transmit chains, or both. The radios 330A-N can be configured to communicate in accordance with various wireless communication standards, including but not limited to LTE, LTE-A, 5G NR, 6G, UWB, Wi-Fi, BT, and so on. The AP 104 can be configured to operate on multiple wireless links using one or more radios 330A-N. In some implementations, each radio can be used to operate on a respective wireless link.

[0099] The AP 104 can be configured to use multiple wireless communication standards for wireless communication. In some cases, the AP 104 can include multiple radios that can enable the network entity to communicate according to multiple wireless communication technologies. For example, as one possibility, the AP 104 can include a 4G or 5G radio for performing communications according to 3GPP wireless communication technologies, and a Wi-Fi radio for performing communications according to one or more Wi-Fi specifications. In this case, the AP 104 can be capable of operating as both a cellular base station and a Wi-Fi access point. As another possibility, the AP 104 can include a multi-mode radio capable of performing communications according to any of a variety of wireless communication technologies, e.g., 5G NR and Wi-Fi, 5G NR and LTE, and so on. As yet another possibility, the AP 104 can be configured to function solely as a Wi-Fi access point, e.g., without cellular communication capabilities.

[0100] As further described herein, the AP 104 can include hardware and software components for implementing or supporting implementation of the features described herein, such as performing multi-user request transmission and allow transmit sending, and various other possible features. The processor 304 of the AP 104 can be configured, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium) to implement or support implementation of part or all of the methods described herein using multiple respective radios to operate multiple wireless links. Alternatively, the processor 304 can be configured as a programmable hardware element, such as an FPGA (field-programmable gate array) or ASIC (application-specific integrated circuit) or a combination thereof. Alternatively (or additionally), the processor 304 of the AP 104, in conjunction with one or more of the other components 330, 332, 334, 340, 350, 360, 370 can be configured to implement or support implementation of part or all of the features described herein.

[0101] Figure 4 Block diagram of a modem or baseband processor

[0102] Figure 4 An example block diagram of a modem 400, which can also be referred to as a baseband processor 400, is illustrated. The modem 400 can provide signal processing functionality for one or more wireless communication technologies, such as Wi-Fi, Bluetooth, and / or cellular (e.g., 3GPP) communication technologies. Thus, as one possibility, the modem 400 can represent a Wi-Fi modem; for example, Figure 4 The illustrated modem 400 can represent Figure 2 one possible example of the illustrated Wi-Fi modem 232. As another possibility, the modem 400 can represent a cellular modem or cellular baseband processor; for example, Figure 4 The illustrated modem 400 can represent Figure 2 one possible example of the illustrated cellular modem 234. As yet further possibilities, the modem 400 can represent a Bluetooth modem; for example, Figure 4 The illustrated modem 400 can represent Figure 2 one possible example of the illustrated Wi-Fi modem 236. In some cases, the modem 400 can implement functionality to support communications in accordance with multiple wireless communication technologies. At least in some cases, the modem 400 can run a real-time operating system, for example, to facilitate performance of timing-dependent wireless communication functionality.

[0103] In some cases, modem 400 can be configured for concurrent data transmission and reception in multiple channels across a single band and / or multiple bands (e.g., such as the 2.4 GHz band, the 5 GHz band, and / or the 6 GHz band). Accordingly, modem 400 can be configured to perform multi-link operations (MLO). For example, modem 400 can be configured to perform simultaneous transmit receive (STR) operations (e.g., can be configured for simultaneous uplink and downlink traffic on a pair of links) and / or enhanced multi-link single radio (EMLSR) operations (e.g., can be configured such that a single radio is used to simultaneously listen to two or more links).

[0104] Modem 400 can include processing circuitry 402, which can include one or more processor cores, ASICs, programmable hardware elements, digital signal processors, and / or other processing elements. The processing circuitry can be capable of preparing baseband signals for up-conversion and transmission by radio circuitry of a wireless device, and / or processing baseband signals received and down-converted by radio circuitry of a wireless device. Such processing can include signal modulation, coding, decoding, etc. among various possible functions. The processing circuitry can also or alternatively be capable of performing functionality of one or more baseband and / or other layers / sub-layers of a protocol stack for wireless communication technologies implemented by modem 400, such as physical layer (PHY) functionality, medium access control (MAC) functionality, logical link control (LLC) functionality, radio resource control (RRC) functionality, radio link control (RLC) functionality, etc. In some cases, modem 400 itself can include at least some radio circuitry (e.g., for performing conversion of input baseband signals to radio frequency signals and / or conversion of input radio frequency signals to baseband signals). Alternatively or additionally, some or all such functionality can be performed by a separate radio / transceiver component of a wireless device.

[0105] Modem 400 can also include memory 404, which can include non-transitory computer-readable memory media. Memory 404 can include program instructions for performing signal processing and / or any of a variety of possible general processing functions. Processing circuitry 402 can be capable of executing program instructions stored in memory 404. Memory 404 can also store data generated and / or used by processing circuitry 402 during processing.

[0106] As shown, modem 400 can also include, for example, one or more input / output interface(s) 406, such as one or more input / output interface(s) 406 for communicating with a wireless device (such as a mobile terminal, a computer, a sensor, etc.) and / or other devices. Figures 1-3interface circuitry through which the processor communicates with other components of the STA 106 or AP 104 (such as an application processor, radio / transceiver circuitry, and / or any of a variety of other components). Such interfaces can be implemented in any of a variety of ways; as one possibility, for example, the modem 400 can have a direct interface with transceiver circuitry of a wireless device, and can have an additional indirect interface through a system bus with an application processor and / or other components of the wireless device. Other configurations are also possible.

[0107] In at least some cases, hardware and software components of the modem 400 can be configured to implement or support implementation of features described herein, such as the sending of unavailability, as well as a variety of other possible features. For example, the processing circuitry 402 of the modem 400 can be configured to implement or support implementation of some or all of the methods described herein, e.g., by executing program instructions stored on a memory (e.g., a non-transitory computer-readable memory medium) 404 and / or using special-purpose hardware components.

[0108] Figure 5 – flowchart of sending unavailability information

[0109] Figure 5 is a flowchart showing a method for supporting sending unavailability information in a WLAN, in accordance with some embodiments. In various embodiments, some of the elements of the illustrated method can be performed concurrently, in a different order than illustrated, can be omitted, replaced by other method elements, or combined with other method elements. Additional method elements can also be performed as desired.

[0110] Figure 5 Aspects of the method of Figures 1-4 the AP 104 or STA 106 shown and described with respect to these figures, or more generally, can be implemented in connection with any of the computer circuitry, systems, devices, elements, or components, etc. shown in the figures, as desired. For example, a processor of such a device, such as the baseband processor 400 illustrated in Figure 4 and / or other hardware described in and with respect to FIG. 4 of the present disclosure) can be configured to cause the device to perform the method elements shown and / or any combination of other method elements. As shown, the method can proceed as follows:

[0111] At 502, the wireless device establishes a first wireless connection using a first set of radio resources. The first wireless connection can utilize any of a variety of radio access technologies (RATs), such as a WLAN, Bluetooth, or a cellular RAT (such as 5G NR). In some embodiments, the first wireless connection can be made with a wireless access point (AP).

[0112] At 504, the wireless device establishes a second wireless connection using the first set of radio resources. The second wireless connection can utilize any of a variety of radio access technologies (RATs), such as a WLAN, Bluetooth, or a cellular RAT (such as 5G NR). Notably, the first and second wireless connections can share at least some radio resources (i.e., the “first set” of radio resources), such that a coexistence event can potentially occur between the first and second wireless connections.

[0113] According to various embodiments, the first and second wireless connections can comprise associations established using Wi-Fi, a wireless communication technology based at least in part on Wi-Fi, and / or any of a variety of other wireless communication technologies. In some embodiments, the first and / or second wireless connections can comprise infrastructure Wi-Fi connections. For example, as one possibility, a wireless AP can provide a beacon transmission comprising information for associating with the wireless AP, and one or more other wireless devices (e.g., non-AP wireless devices, which can include the wireless device) can use the information provided in the beacon transmission to request association with the wireless AP. In some embodiments, the first and / or second wireless connections can comprise peer-to-peer (P2P) Wi-Fi connections, or non-Wi-Fi connections such as Bluetooth connections. For example, as one possibility, a wireless device can form a Wi-Fi connection with an AP as the first wireless connection, and form a P2P Wi-Fi connection with another non-AP wireless device as the second wireless connection. As another possibility, the first wireless connection can be a WLAN connection, and the wireless device can form a Bluetooth wireless connection with a paired Bluetooth device as the second wireless connection, or a wireless connection with another wireless device according to another wireless communication technology.

[0114] Variations and / or other techniques for establishing associations are possible. In some embodiments, the multiple wireless connections established by the wireless device using the first set of radio resources can comprise more than two wireless connections. Also note that, according to various embodiments, the radio resources shared by the multiple wireless connections can comprise some or all of the portion of the frequency spectrum used by each of the wireless connections; in other words, the radio resources of the multiple wireless connections can partially overlap, or can completely overlap, in various cases. In some cases, the wireless device can additionally have one or more wireless connections using radio resources that do not overlap with the first set of radio resources.

[0115] At 506, the wireless device receives, from the wireless access point over the first wireless connection, an initial control frame (ICF).

[0116] At 508, based at least in part on receiving the ICF, the wireless device sends a control response message (ICR) to the wireless access point. In embodiments, the control response message indicates the unavailability information of the wireless device. In some embodiments, the control response message can be transmitted a short interframe space (SIFS) after receiving the ICF.

[0117] In some embodiments, the ICF is a BSRP frame and the ICR control response message is an M-STA BA frame. The ICR message includes a duration field to indicate a future availability duration (NAV), an adjusted transmit opportunity (TXOP) duration, and a start time and duration of Coex unavailability.

[0118] In some embodiments, the indication of the future unavailability time period includes a future unavailability start time, a minimum future unavailability duration, and / or a bitmap indicating one or more links involved in the future unavailability event. In some embodiments, a duration field in the control response message can be used to indicate the availability duration. The future unavailability start time value can be indicated as part of a TSF value.

[0119] In some embodiments, the unavailability information is for a single coexistence event on a single link, or it can be for multiple coexistence events involving multiple links. In some embodiments, instead of transmitting an ICR control message indicating the unavailability information in response to receiving the multi-user ICF, the wireless device can transmit an unsolicited unavailability announcement (UUA) to communicate the unavailability information. The UUA can be transmitted after establishing the first and second wireless connections and determining that a future unavailability event will occur, but it can be transmitted without receiving the ICF at step 506 (e.g., it is unsolicited). In these embodiments, the UUA can be included in a management frame, where it can be processed at a higher layer (e.g., above the MAC layer) than a control frame. This can be particularly useful for cross-link unavailability information, where the unavailability information related to an unavailability event on a first link is communicated over a different second link. Thus, according to the method of Figure 5 According to the method of

[0120] Note that while at least some elements of the methods are described in ways that involve the use of communication techniques and / or features associated with IEEE 802.11 specification documents, such description is not intended to limit the present disclosure, and aspects of the methods Figure 5 may be used for any suitable wireless communication system as desired. Figure 5

[0121] FIGS. 6-20 and additional information

[0122] FIGS. 6-20 illustrate additional aspects that can be used in connection with the methods of Figure 5 However, it should be noted that the example details illustrated in and described with respect to FIGS. 6-20 are not intended to be limiting of the present disclosure as a whole: many variations and alternatives to the details provided herein below are possible and should be considered to be within the scope of the present disclosure.

[0123] Figure 6A A timeline is illustrated in accordance with various embodiments that illustrates the timing relationship between an AP and a STA that is to receive data packets from the AP. The STA receives an ICF from the AP, the ICF indicating a planned TXOP during which the AP will transmit data packets to the STA via a first access technology (e.g., WiFi). In response to the received ICF, the STA transmits an ICR to the AP, the ICR providing unavailability information including a time period during which the STA will be unavailable to receive data packets via the first communication access technology due to a planned communication task via a second access technology. Figure 6A Three cases are indicated that can apply depending on the start and end times of the STA’s unavailability period (e.g., Coex unavailability).

[0124] Case 1 illustrates an unavailability duration A-B that occurs outside the time range of the TXOP planned by the AP. For Case 1, the TXOP can be executed as planned, without the need to reschedule the TXOP or reduce the timeframe of the TXOP (e.g., without the need to reduce the amount of data to be communicated to STA 1).

[0125] Case 2 illustrates an unavailability duration A-B that includes a portion of the timeline planned by the AP for the TXOP.

[0126] Case 3 illustrates an unavailability duration A-B that is entirely within the planned TXOP timeline.

[0127] Considering Cases 2 and 3, the unavailability duration A-B overlaps, in part or in whole, with the planned TXOP indicated by the ICF issued by the AP, so the STA is unavailable during a portion of the planned TXOP.

[0128] ​Figure 6B UUA is illustrated as being issued by a STA to indicate that the STA is receiving WiFi transmissions from an AP that are unavailable, e.g., due to Coex unavailability caused by transmissions via a different transmission medium (e.g., cellular transmissions) that will utilize the STA’s communication portion and thus be unavailable for WiFi communications with the AP. The UUA can be issued without prior hint, e.g., in the case that the STA does not receive an ICF transmitted by the AP. In response to receiving the UUA, the AP issues an acknowledgement (Ack) to the STA.

[0129] Reference Figure 6A and Figure 6B With reference to power management in

[0130] Reference Figure 6B , in some other embodiments, the UUA frame can be a QoS null frame or other frame type such as a management frame with the Coex unavailability information (start time, duration, and link bitmap indicating which links the Coex unavailability applies to) included in the A-control field of the UUA frame. In some other embodiments, the UUA frame can be a control frame or a management frame. The AP can transmit an acknowledgement frame to the UUA frame as an acknowledgement of receiving the UUA frame.

[0131] If the unavailability duration partially or completely overlaps with a TWT service period (SP), the STA overrides the TWT requirement and is unavailable to receive packets.

[0132] In Figure 6A , Figure 6B , during the Coex unavailability duration announced by the ICR or UUA, if the AP cannot deliver a BU addressed to STA 1 on another link of the MLD in case the STA is available on the same non-AP MLD, the AP will buffer the individually addressed BU.

[0133] Figure 7 Illustrated Figure 6ACase 2-4: The AP aborts the TXOP with STA1 and instead sends data to a third party STA2.

[0134] In Case 2-1, the AP does not react to the Coex unavailability indication provided in the ICR transmitted by the STA (e.g., due to short time to respond) and continues to transmit data throughout the planned TXOP, despite the STA being unavailable during A-B.

[0135] In Case 2-2 (“smart AP”), the AP shortens the TXOP with STA1 according to the feedback from STA1 (e.g., via ICR). During the unavailability of STA1, the AP can transmit a CF-END frame to terminate the remaining part of the TXOP. Alternatively, the AP transmits the remaining part of the data intended to be sent to another (third party) station (STA2).

[0136] Case 2-3: The AP fails to successfully transmit the data intended to be sent and transmits a CF-END frame, the AP cancels the TXOP and does not send to any station. By cancelling the TXOP, the AP frees the transmission medium to be used to send data.

[0137] Case 2-4: The AP aborts the TXOP with STA1 and instead sends data to a third party STA2.

[0138] In each of the 4 cases 2-1 to 2-4, during the part B-C of the unavailability duration, the AP can buffer the individually addressed bufferable units (BUs) destined to the STA or the AP can transmit the BUs on another link of a multi-link device (MLD) to which the STA belongs, e.g., to another available STA belonging to the same non-AP MLD.

[0139] Figure 8 The 4 sub-cases of Case 3 (“Case 3-x”) are depicted. Figure 6A

[0140] Case 3-1: The AP does not react to the Coex unavailability indication provided in the ICR transmitted by the STA, e.g., due to short time to respond, and continues to transmit data throughout the planned TXOP, despite the STA being unavailable during A-B.

[0141] ​Case 3-2, the AP shortens the TXOP with STA1, sends a reduced amount of data to STA1 within the duration field value (communicated to the AP in the ICR) before the start of the unavailability duration. During the Coex unavailability period, the AP can send a CF-END frame to terminate the remaining portion of the TXOP, or send to a third party device. If the AP does not terminate the remaining portion of the TXOP during the Coex unavailability period, the AP can resume transmitting data to STA1 after the end of the unavailability period by communicating another ICF to STA1 and receiving another ICR from STA1 in response.

[0142] Case 3-3: the AP communicates a CF-END frame and cancels the TXOP.

[0143] Case 3-4: the AP aborts the TXOP with STA1 and instead sends data to a third party device, STA2.

[0144] Figure 9 Involves updating previously advertised unavailability information. As depicted in 902, the AP communicates ICF1 to the STA and receives ICR1 in response, which includes an indication of the unavailability duration for the STA.

[0145] As depicted in 904, according to method 1, the AP communicates ICF2 and receives ICR2 indicating updated unavailability information that overrides the previously communicated indication of unavailability information, before the start of the Coex unavailability information previously advertised in ICR1, according to method 1. Alternatively, according to method 2, the STA can initiate a UUA to the AP indicating updated unavailability information that overrides the previously communicated indication of unavailability information.

[0146] At 906, the updated availability duration is illustrated that compares to the unavailability information previously indicated by ICR 1 to the AP (shifted to a later start time).

[0147] Figure 10 The update by the STA during the unavailability period established by ICR 1 in response to ICF 1, the STA can communicate a packet (e.g., any type of packet, e.g., a data packet) to the AP that cancels the remaining portion of the previously established unavailability period. In one embodiment, the packet communicated to the AP can include new unavailability information for the STA, e.g., updated unavailability information, or no unavailability information.

[0148] Figures 11-1 7 illustrates a failure and recovery method for a system including an AP and a STA.

[0149] Figure 11The time between successive ICFs when no ICR is received (e.g., a failure to receive an acknowledgement to an ICF) is illustrated for a system employing a Block Acknowledgement (BA) protocol. Typically, a failure to receive an ICR results in a QSTA Retry Counter (QSRC) increment and a Contention Window (CW) increase, thereby resulting in an extended time to access the wireless medium to transmit a frame. As the dotl l QAP ED CAT Table MSDU lifetime expires, a data packet will be discarded. The long backoff performed upon a retry ICF results in potentially increased difficulty in gaining access to use the transmission medium (through which the data packet is delivered), and a waste of use of the medium.

[0150] In one embodiment, to mitigate or avoid such failures, a STA can transmit a non-requested Unavailability Announcement (UUA) frame so that the AP is aware of the STA's unavailability information and avoids sending ICFs to the STA during the STA's unavailability, and thus avoids a failure of the ICF / ICF exchange. If the initial UUA to indicate upcoming Coex unavailability does not result in an acknowledgement, the STA can submit another UUA frame to the AP. That is, if the STA has previously communicated a UUA transmission to the AP, but the UUA was not successfully acknowledged, the STA can communicate another UUA frame to indicate upcoming Coex unavailability.

[0151] As shown in FIG. 12, in one embodiment, when an ICF is communicated by the AP and does not result in an ICR being communicated back to the AP, a new counter "Coex_RC" (with a corresponding retry limit "Coex_ICF_RetryLimit") can be employed that does not increment the size of the Contention Window (CW) (e.g., does not result in an extended CW that can be up to twice the size of the CW, as depicted in Figure 11 Thus, after a failure of the ICF / ICR exchange, a subsequent Coex_ICF_RetryLimit is employed that does not increment the size of the Contention Window for data packet transmission. When the Coex_ICF_RetryLimit is reached, the AP can wait for an AP implementation specific duration before attempting an ICF retry.

[0152] Figure 13 ICF / ICR failure without a Block Acknowledgement (BA) protocol is depicted. As shown in Figure 13 ICF / ICR failure increments the QSTA Retry Counter QSRC, which doubles the Contention Window (CW) and results in a long backoff, which in turn results in more difficulty in gaining access to the medium for delivery of data packets. Additionally, in this system without a BA protocol, the discard of a data packet occurs upon expiration of the retry dotl l (short retry limit) or the MSDU retry lifetime, whichever occurs first, as shown in Figure 11 ​

[0153] Figure 14A 、 Figure 14B A suggested remedy for ICF / ICR failure includes a new counter Coex_RC with a corresponding retry limit Coex_ICF_retrylimit. For each ICF / ICR exchange failure, Coex_RC is incremented by 1, e.g., an ICF / ICR exchange failure will cause Coex_RC to be incremented by 1; however, the contention window is not doubled. That is, as Figure 14A depicted, the ICF / ICR exchange failure does not increase the CW or cause channel access difficulties for the subsequent data packet delivery. Instead, the subsequent data packet delivery is not penalized by the failure of the ICF / ICR exchange and the retry failure.

[0154] Figure 15 A summary of AP data rate adaptation due to ICF / ICR failure with or without BA protocol is summarized. In Option A, during the Coex session, the AP’s rate adaptation takes into account the STA’s unavailability feedback and does not simply assume poor link quality. In Option B, during the Coex session, the AP does not reduce the data rate simply due to ICF / ICR failure.

[0155] Figure 16A 、 Figure 16B A summary of data packet transmission failure and recovery options for Case 2-1, 2-2, 2-3, 2-4 according to embodiments herein is summarized, as Figure 7 originally presented in

[0156] In Case 2-1, the AP continues with the unaltered / unaltered TXOP with STA1 and causes packet failure. Regarding the contention window (CW), the AP does not double the minimum value of the CW. Regarding the AP’s retry behavior, if the AP learns from the ICR that there is Coex unavailability, the AP refrains from retrying STA1 during the Coex unavailability. Regarding the data rate, the AP does not reduce the data rate for STA1.

[0157] In Case 2-2, the AP shortens the TXOP with STA1 according to the STA1 feedback. During the Coex unavailability of STA1, the AP can send a CF-End frame to terminate the remaining TXOP; alternatively, the AP can send data to another station (STA2) during the remaining portion of the TXOP.

[0158] In Case 2-3, the AP sends a CF-End frame and terminates the current TXOP.

[0159] In case 2-4: the AP aborts the TXOP with STA1 and instead transmits data to a third party STA2.

[0160] For cases 2-2, 2-3, and 2-4, in some embodiments, the method performed by the AP after a data transmission failure can include the following routine actions.

[0161] Figure 17A 、 Figure 17B The data packet transmission failure and recovery options for cases 3-1, 3-2, 3-3, 3-4 are summarized according to embodiments herein as Figure 8 As initially presented in, for example, the duration of the unavailability is entirely within the TXOP planned by the AP.

[0162] In case 3-1, the AP continues with the unchanged / unchroned TXOP with STA1 and causes the packet failure. Regarding the contention window (CW), the AP does not double the minimum value of the CW. Regarding the AP’s retry behavior, if the AP learns from the ICR that there is Coex unavailability, the AP refrains from retrying STA1 during the Coex unavailability. Regarding the data rate, the AP does not reduce the data rate of STA1.

[0163] In case 3-2, the AP shortens the TXOP with STA1 according to the STA1 feedback. During the Coex unavailability of STA1, the AP can transmit a CF-End frame to terminate the remaining TXOP; alternatively, the AP can transmit data to another station (STA2) during the remaining part of the TXOP. After the Coex unavailability is complete, if the AP wants to return to STA1, the AP will transmit another ICF and receive an ICR in response, which indicates that STA1 is available to receive additional data.

[0164] In case 3-3, the AP transmits a CF-End frame and terminates the current TXOP.

[0165] In case 3-4, the AP aborts the TXOP with STA1 and instead transmits data to STA2.

[0166] For cases 3-2, 3-3, and 3-4, in some embodiments, the method performed by the AP after a data transmission failure can include the following routine actions.

[0167] Figure 18An illustration of the acknowledgement of the ICR that has been transmitted to the AP in response to the ICF received by the STA, where the unavailability period starts after the AP's planned TXOP. If the AP continues the TXOP with STA 1 after the ICR is received, any download (DL) transmission during the TXOP serves as an acknowledgement of the ICR. The acknowledgement of the ICR confirms to the AP that the Coex unavailability of STA 1 is received.

[0168] Figure 19A , 19B An illustration of the acknowledgement of the ICR, where the unavailability duration occurs within the duration field value of the ICF. As shown in Figure 19A , after receiving the ICR in response to the ICF, the AP can choose to terminate the TXOP, e.g., not transmit with any STA. In this case, the AP sends a CF-End, which frame serves as an acknowledgement of the ICR. As shown in Figure 19B , after receiving the ICR, the AP aborts the TXOP with STA 1 and continues the TXOP with another station, STA 2. Any preamble sent by the AP to STA 2 that is detected by STA 1 can serve as an acknowledgement that the ICR of STA 1 is received by the AP.

[0169] For all scenarios in Figure 18 , Figure 19A and Figure 19B , if the AP acknowledges the ICR containing Coex unavailability using the respective methods described, the STA does not send the same unavailability information again, e.g., does not repeat the unavailability information.

[0170] During the PBT (ICF / ICR) setup procedure, the STA and the AP can each indicate respective Coex behavior policies. For example, a Coex behavior policy that can be indicated by the STA during the setup is that the AP aborts the transmission if the TXOP cannot be shortened. Another Coex behavior policy that can be indicated by the STA is the expected number of ICF retries in case of ICF / ICR failure. Yet another Coex behavior policy that can be indicated by the STA is the expected number of ICR retries in case of ICF / ICR failure. Yet another Coex behavior policy that can be indicated by the STA is whether the STA is willing to participate in a multi-user (MU) Coex group. Alternatively, the STA can indicate other policies during the setup.

[0171] The AP can indicate various policies during the setup. For example, a policy of the AP can include that the AP can shorten the TXOP short interframe space (SIFS) after receiving the ICR (see Figure 19A , Figure 19BAs another example, the AP can indicate different strategies: if the TXOP cannot be shortened, the AP will abort the TXOP. Another strategy that can be indicated by the AP during setup is: if the TXOP cannot be shortened, the AP will continue the TXOP. Yet another strategy that can be indicated by the AP during setup is the contention window (CW) behavior of the AP in case of a failed packet transmission, e.g., to extend (or not to extend) the contention window in case of a failed packet transmission. Yet another strategy that can be indicated by the AP during setup is the number of ICF retries in case of ICF / ICR failure. Yet another strategy that can be indicated by the AP during setup is the number of ICF retries in case of a failed data packet transmission. Alternatively, the AP can indicate other strategies during setup.

[0172] Figure 20A 、 Figure 20B 、 Figure 20C Embodiments are illustrated in which the STA has the capability to indicate the power management mode (active mode or power save mode) at the end of the unavailability period. The STA can indicate the Coex unavailability via an ICR ( Figure 20A ) or via a UUA ( Figure 20B ). The ICR (or UUA) can also indicate the power management mode (active mode or power save mode) at the end of the unavailability duration A-B (point B). For example, in one embodiment, the STA is in active mode at point A. Between A and B, the STA is unavailable. At B, the STA remains in active mode; however, if the STA indicates power save mode in the ICR or UUA containing the unavailability information, then the STA is in power save mode at time point B.

[0173] In another embodiment, the STA is in power save mode at the beginning of the unavailability period. Between A and B, the STA is in power save mode ("sleep state"). At B, the STA remains in power save mode, however, if the STA indicates active mode in the ICR or UUA containing the unavailability information, then the STA is in active mode at time point B.

[0174] Regarding the sending of a Delivery Traffic Indication Message (DTIM) to warn the clients that the AP is going to send frames, in an embodiment, the sending follows the conventions in the 802.11 standard.

[0175] In one embodiment, the UUA frame can only be sent if the reported unavailability period is longer than a threshold. Such a threshold can be an implementation-specific internal value, or can be communicated by the STA to the AP, or can be specified in a new 802.11 standard amendment.

[0176] In addition to the exemplary embodiments described above, further embodiments of the disclosure can be realized in any of various forms. For example, some embodiments can be realized as a computer-implemented method, a computer-readable memory medium, or a computer system. Other embodiments can be realized using one or more custom-designed hardware devices such as ASICs. Other embodiments can be realized using one or more programmable hardware elements such as FPGAs.

[0177] In some embodiments, a non-transitory computer-readable memory medium can be configured such that it stores program instructions and / or data, where the program instructions, if executed by a computer system, cause the computer system to perform a method, such as any of the method embodiments described herein, or any combination of the method embodiments described herein, or any subset of any of the method embodiments described herein, or any combination of such subsets.

[0178] In some embodiments, a device (e.g., an AP 104 or a STA 106) can be configured to include a processor (or a set of processors) and a memory medium, where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memory medium, where the program instructions can be executed to implement any of the various method embodiments described herein (or any combination of the method embodiments described herein, or any subset of any of the method embodiments described herein, or any combination of such subsets). The device can be implemented in any of various forms.

[0179] While the above embodiments have been described in considerable detail, many variations and modifications will now become apparent to those skilled in the art once fully understood. It is intended that the following claims be construed to include all such variations and modifications as fall within the true spirit and scope of the above disclosure.

Claims

1. A method, the method comprising: From the first wireless device: Receive information from the second wireless device indicating an unavailability period during which the second wireless device cannot receive data packets transmitted from the first wireless device; as well as Based on the received information, an execution plan for sending the data packets to the second wireless device is determined.

2. The method of claim 1, wherein the execution plan includes determining, based on the received information, to adjust the duration of the Transmission Opportunity Period (TXOP) during which the data packets are transmitted from a planned TXOP duration to an adjusted TXOP duration, wherein the second wireless device may be used to receive the data packets for the adjusted TXOP duration.

3. The method according to claim 1, further comprising: Transmit an Initial Control Frame (ICF) to the second wireless device, the ICF indicating a planned Transmission Opportunity Period (TXOP) for transmitting data packets to the second wireless device; and In response to receiving the ICF from the second wireless device, an Initial Control Response (ICR) is received from the second wireless device, wherein the ICR indicates the unavailability period.

4. The method of claim 3, further comprising, after receiving the ICR: Send an acknowledgment to the second wireless device that the ICR has been received; Transmit a CF-END frame to the second wireless device; or Transmit to another wireless device.

5. The method according to claim 1, further comprising: Transmit an Initial Control Frame (ICF) to the second wireless device, the ICF indicating a planned Transmission Opportunity Period (TXOP) for transmitting data packets to the second wireless device; and In response to receiving the ICF from the second wireless device, an Initial Control Response (ICR) is received from the second wireless device, wherein the ICR update indicates the information of the unavailability period.

6. The method of claim 1, wherein the unavailability period at least partially overlaps with a transmission opportunity period (TXOP) planned for the first wireless device to transmit data packets to the second wireless device, and the execution plan includes determining based on received information: Terminate the TXOP, wherein the termination cancels the transmission of the data packets during the TXOP; or During the TXOP, at least some of the data packets are transmitted to another wireless device.

7. The method of claim 1, wherein the received information is included in an unsolicited unavailability announcement (UUA) from the second wireless device, wherein the information updates the previously announced unavailability period.

8. The method of claim 1, wherein the information is received in an unsolicited unavailability announcement (UUA) from the second wireless device, wherein the unavailability information includes an unavailability start time, an unavailability duration, and a link bitmap indicating which links the unavailability applies to, wherein the information is included in the A-control field of the UUA.

9. The method of claim 1, wherein the received information is included in an unsolicited unavailability notice (UUA) from the second wireless device, wherein the information indicates a power management mode at the endpoint of the unavailability period.

10. The method of claim 1, wherein the unavailability period at least partially overlaps with a transmission opportunity period (TXOP) planned for the first wireless device to transmit data packets to the second wireless device, and wherein the execution plan includes shortening the TXOP in response to received information.

11. The method of claim 1, wherein the execution plan comprises: During the unavailability period, at least some of the data packets are sent to a third wireless device but not to the second wireless device.

12. The method according to claim 1, further comprising: In response to receiving the ICF from the second wireless device, an Initial Control Response (ICR) is received from the second wireless device, wherein the ICR indicates the power management mode at the endpoint of the unavailability period.

13. A processor, the processor including a memory, the memory being configured to cause the processor to perform operations including: Receive information from the second wireless device indicating the duration of unavailability, during which the second wireless device cannot receive data packets transmitted from the first wireless device in response to commands issued by the processor; and Based on the received information, an execution plan is determined for the first wireless device to transmit the data packet from the first wireless device to the second wireless device.

14. The processor of claim 13, wherein the execution plan includes determining, based on the received information, to adjust the duration of the transmission opportunity period (TXOP) during which the data packet is transmitted from a planned TXOP duration to an adjusted TXOP duration, wherein the second wireless device may be used to receive the data packet for the adjusted TXOP duration.

15. The processor of claim 13, wherein the processor is further configured to perform additional operations including: Transmit an Initial Control Frame (ICF) to the second wireless device, the ICF indicating a Transmission Opportunity Period (TXOP) for transmitting data packets to the second wireless device; and In response to receiving the ICF from the second wireless device, an Initial Control Response (ICR) is received from the second wireless device, wherein the ICR indicates the unavailability period.

16. The processor of claim 15, wherein the processor is further configured to perform an additional operation, the additional operation including, after receiving the ICR: Send an acknowledgment to the second wireless device that the ICR has been received; Transmit a CF-END frame to the second wireless device; or Transmit to another wireless device.

17. The processor of claim 13, wherein the processor is further configured to perform additional operations including: Transmit an Initial Control Frame (ICF) to the second wireless device, the ICF indicating the duration of a planned Transmission Opportunity Period (TXOP) for transmitting data packets to the second wireless device; and In response to receiving the ICF from the second wireless device, an Initial Control Response (ICR) is received from the second wireless device, wherein the ICR update indicates the information of the unavailability period.

18. A wireless device, the wireless device comprising: One or more antennas; One or more radio components, said one or more radio components being operatively coupled to said one or more antennas; and A processor, the processor being operatively coupled to the one or more radio components; The wireless device is configured as follows: Receive information from the second wireless device indicating an unavailability period during which the wireless device cannot receive data packets transmitted from the wireless device to the second wireless device; as well as Based on the received information, an execution plan for sending the data packets to the second wireless device is determined.

19. The wireless device of claim 18, wherein the execution plan includes determining, based on received information, to adjust the duration of a transmission opportunity period (TXOP) during which the data packet is transmitted from a planned TXOP duration to an adjusted TXOP duration, wherein the second wireless device may be used to receive the data packet for the adjusted TXOP duration.

20. The wireless device of claim 18, wherein the wireless device is further configured to: Transmit an Initial Control Frame (ICF) to the second wireless device, the ICF indicating a Transmission Opportunity Period (TXOP) for transmitting data packets to the second wireless device; and In response to receiving the ICF from the second wireless device, an Initial Control Response (ICR) is received from the second wireless device, wherein the ICR updates the unavailability period.

Images