Latency reduction through controller transmit opportunity sharing
The system allows TXOP holder devices to share their TXOP duration with non-TXOP devices, facilitating efficient transmission of latency-sensitive traffic, reducing delays and collisions, and complying with regulatory standards.
Patent Information
- Application Number
- JP2025015818
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-10-28
- Filing Date
- 2025-02-03
- Publication Date
- 2025-08-27
Smart Images

Figure 2025125521000001_ABST
Abstract
Description
[Technical Field]
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to Indian Provisional Patent Application No. 202421010608, filed February 15, 2024, and Indian Provisional Patent Application No. 202421036114, filed May 7, 2024, both of which are incorporated herein by reference in their entirety.
[0002] Field of the Disclosure The present disclosure generally relates to systems and methods for improving performance of latency-sensitive traffic through various TXOP sharing mechanisms that allow latency-sensitive traffic to preempt or follow ongoing frame exchanges in a TXOP in a controlled manner.
[0003] background In wireless communications, time-based scheduling can be used to control transmissions between devices. For example, the MAC layer function used in IEEE 802.11-based wireless local area networks (WLANs) can be called a Transmission Opportunity (TXOP). The amount of time a station has to transmit a frame after reaching contention for the transmission medium can be defined by the TXOP. Other devices on the WLAN may have low-latency traffic for transmission.
[0004] Summary of the Disclosure The technical solution provides a system and method for transmission opportunity (TXOP) sharing for latency-sensitive traffic of non-TXOP holder devices within a TXOP. In various wireless communications, such as with respect to an exemplary wireless local area network (WLAN), a wireless communication device that is granted a TXOP with a specific TXOP duration during which the device can transmit their communications may be referred to as a TXOP holder device. During the TXOP granted to the TXOP holder device, non-TXOP devices (e.g., nearby devices that are not holding the TXOP) may have latency-sensitive traffic that should be transmitted immediately but may be deferred until the next opportunity. However, because the TXOP is granted to the specific TXOP holder device, it may be difficult for the non-TXOP devices to transmit their latency-sensitive traffic during the same TXOP duration. The technical solution of the present disclosure enables the TXOP holder device to share a portion of the TXOP duration with the non-TXOP devices, facilitating the transmission of the latency-sensitive traffic of the non-TXOP devices during the TXOP granted to the TXOP holder device.
[0005] At least one aspect of the technical solution is directed to a system. The system may include a first device, such as a device in a wireless local area network (WLAN). The first device may be granted a transmission opportunity (TXOP) for transmission during a TXOP period. The first device may be configured to identify a first portion of the TXOP period for one or more transmissions of the first device via the WLAN. The first device may be configured to determine that a remaining portion of the TXOP period after the first portion is available for data transmission for one or more other devices in the WLAN. The first device may be configured to transmit, via the WLAN, an indication of availability regarding the remaining portion of the TXOP period for data transmission to one or more other devices. In response to one or more responses to the indication from the one or more other devices, the first device may be configured to allocate the remaining portion of the TXOP period to a second device of the one or more other devices for transmitting data for the second device during a portion of the remaining portion of the TXOP period.
[0006] The first device may be configured to schedule transmission of data of the first device during a first portion of the TXOP period, and in response to determining that the scheduled transmission occupying the first portion of the TXOP period is to complete before the start of the remaining portion, the first device may be configured to determine that the remaining portion of the TXOP period is available for one or more other devices to transmit low latency data during the remaining portion.
[0007] The first device may be configured to determine, based on one of the one or more responses of the second device, that the data of the second device is low latency data. The first device may be configured, in response to the data of the second device being low latency data, to allocate the remainder to the second device.
[0008] The first device may be configured to identify that first data of one or more transmissions of the first device is of a first priority. The first device may be configured to identify that second data of a second one or more transmissions to be transmitted by the first device is of a second priority that is lower than the first priority. The first device may be configured to determine to transmit an indication of availability in response to the second data being of the second priority.
[0009] The first device may be further configured to schedule transmission of the second device's data, the data being low latency data, to the second device for at least a first portion of the remainder of the TXOP period. The first device may be further configured to schedule transmission of the third device's data, the low latency data, to a third device, one or more other devices of the WLAN, for at least a second portion of the remainder of the TXOP period, the second portion following the first portion.
[0010] The first device may be configured to transmit the indication to one or more other devices via one or more physical layer protocol data units (PPDUs). The first device may be configured to receive one or more block acknowledgements (BAs) from the one or more other devices in response to the one or more PPDUs. The one or more BAs may include one or more responses indicated using one or more bits in one or more fields of the one or more BAs. The first device may be configured to select the second device based on one or more bits in one or more fields of the one or more BAs.
[0011] The first device may be configured to identify, for a plurality of the one or more other devices, a corresponding plurality of random delays within the TXOP period, each random delay of the plurality of random delays for each device of the one or more other devices being different from each other random delay of the plurality of delays for each other device of the one or more other devices.
[0012] The first device may be configured to select a second device from one or more other devices based on the random delays of the respective second devices. The first device may be configured to allocate a remaining portion of the TXOP period to the second device in response to the selection. Each of the plurality of random delays may correspond to a timing for transmitting a respective response of one or more responses by a respective device of the one or more other devices. The selection of the second device may be based on the timing of each of the random delays of the second devices, such that a response from the second device is received by the first device before each other respective response of each of the other remaining devices.
[0013] The first device may be configured to determine that the second device has completed transmission of data for the second device during a first portion of the remaining portion of the TXOP period. The first device may be configured to determine to transmit a second transmission or transmissions of the first device over the WLAN during a second portion of the remaining portion of the TXOP period. The second portion may follow the first portion. The first device may include a WLAN access point (AP) device, and the second device may include a client device associated with the WLAN AP device.
[0014] The first device may include a client device of a WLAN access point (AP) device, and the second device may include a WLAN AP device. The first device may be further configured to identify uplink data of the first device for transmission to the second device. The first device may be configured to determine, based on the uplink data, to allocate a remaining portion of the TXOP period to the second device so that the second device transmits downlink data to the first device.
[0015] The first device may be configured to determine to allocate a remaining portion of the TXOP period to the second device based on an amount of uplink data that meets a threshold.
[0016] The first device can include a first client device associated with a WLAN access point (AP) device, and the second device can include a second client device associated with the WLAN AP device. The first device can be further configured to allocate a remaining portion of the TXOP period to the second device for peer-to-peer communication.
[0017] One aspect of the technical solution relates to a method. The method may include, by a first device in a wireless local area network (WLAN) that has been granted a TXOP for transmission during a transmission opportunity (TXOP) period, identifying a first portion of the TXOP period for one or more transmissions of the first device over the WLAN. The method may include, by the first device, determining that a remaining portion of the TXOP period after the first portion is available for data transmission of one or more other devices of the WLAN. The method may include, by the first device, transmitting, via the WLAN, an indication of availability regarding the remaining portion of the TXOP period for data transmission to one or more other devices. The method may include, in response to one or more responses to the indication from the one or more other devices, allocating, by the first device, the remaining portion of the TXOP period to a second device of the one or more other devices for transmitting data for the second device during a portion of the remaining portion of the TXOP period.
[0018] The method can include scheduling, by a first device, a transmission of data for the first device during a first portion of a TXOP period. In response to determining that the scheduled transmission occupying the first portion of the TXOP period is to complete before a start of the remaining portion, the method can include determining, by the first device, that the remaining portion of the TXOP period is available for one or more other devices to transmit low latency data during the remaining portion.
[0019] The method can include determining, by the first device, that the data of the second device is low latency data based on one of the one or more responses of the second device. The method can include, in response to the data of the second device being low latency data, allocating, by the first device, the remainder to the second device.
[0020] The method may include identifying, by a first device, first data of one or more transmissions of the first device to be a first priority. The method may include identifying, by the first device, second data of a second one or more transmissions to be transmitted by the first device to be a second priority lower than the first priority. The method may include determining, by the first device, to transmit an indication of availability in response to the second data being the second priority. The method may include scheduling transmission of data of the second device, the data being low latency data, to the second device for at least a first portion of a remainder of the TXOP period.
[0021] One aspect of the technical solution relates to a non-transitory computer-readable medium. The non-transitory computer-readable medium can store instructions that, when executed by at least one processor of a first device in a wireless local area network (WLAN) that has been granted a TXOP for transmission during a TXOP period, can cause the at least one processor to identify a first portion of the TXOP period for one or more transmissions of the first device over the WLAN. When executed by the at least one processor, the at least one processor can determine that a remaining portion of the TXOP period after the first portion is available for data transmission by one or more other devices in the WLAN. When executed by the at least one processor, the at least one processor can transmit an indication of the availability of the remaining portion of the TXOP period for data transmission to one or more other devices over the WLAN. When the instructions are executed by at least one processor, the at least one processor can allocate a remaining portion of the TXOP period to a second device of the one or more other devices for transmitting data of the second device during a portion of the remaining portion of the TXOP period in response to one or more responses to instructions from the one or more other devices.
[0022] Various objects, aspects, features, and advantages of the present disclosure will become more apparent and will be better understood by reference to the detailed description taken in conjunction with the accompanying drawings, in which like reference numbers identify corresponding elements throughout and generally indicate identical, functionally similar, and / or structurally similar elements. [Brief explanation of the drawings]
[0023] [Figure 1] FIG. 1 illustrates an exemplary communication environment according to a communication system, according to one or more embodiments.
[0024] [Figure 2]1 is a simplified block diagram of a computing system, according to one embodiment.
[0025] [Figure 3] 1 is an example of a system for providing transmission opportunity (TXOP) sharing for latency-sensitive traffic of non-TXOP holder devices.
[0026] [Figure 4] An access point device, a TXOP holder device, and a STA device are examples of devices involved in TXOP sharing.
[0027] [Figure 5] An example in which the AP, the TXOP holder device, and the STA are involved in TXOP sharing.
[0028] [Figure 6] 1 is an exemplary method for providing TXOP sharing for latency-sensitive traffic of non-TXOP holder devices within a TXOP granted to a TXOP holder device.
[0029] The details of various embodiments of the methods and systems are set forth in the accompanying drawings and the description below.
[0030] Detailed Description The following IEEE standard(s), including any draft of the IEEE standard(s), are incorporated herein by reference in their entirety and made a part of this disclosure for all purposes: the Wi-Fi Alliance standard, and the IEEE 802.11 standards, including but not limited to the IEEE 802.11a standard, the IEEE 802.11b standard, the IEEE 802.11g standard, the IEEE P802.11n standard, the IEEE P802.11ac standard, and the IEEE P802.11be draft D3.0 standard, including any draft of the IEEE standard(s). While this disclosure may refer to aspects of these standard(s), this disclosure is in no way limited by these standard(s).
[0031] The following disclosure provides many different embodiments or examples for implementing different features of the provided subject matter. Specific example components and configurations are described below to simplify the disclosure. These are, of course, merely examples and are not intended to be limiting. For example, in the following description, a first feature or device in communication with or communicatively coupled to a second feature or device may include embodiments in which the first feature is in direct communication with or directly coupled to the second feature, and may also include embodiments in which additional features may intervene between the first and second feature elements, such that the first feature is in indirect communication with or indirectly coupled to the second feature. Furthermore, the disclosure may repeat reference numerals and / or letters in various examples. This repetition is for the purposes of brevity and clarity and does not, in itself, affect the relationship between the various embodiments and / or configurations being described.
[0032] Various embodiments disclosed herein may relate to one or more apparatus, devices and / or systems including a transmitter and / or receiver and one or more processors, and may be configured, constructed or implemented to communicate using any IEEE 802.11 standard, such as 902.11n, 802.11AC, 802.11ax, and 802.11be or other versions, and any encoding processes and techniques defined or supported by embodiments of the IEEE 802.11 standard.
[0033] A TXOP (Transmission Opportunity) may refer to a time interval during which a device in a wireless network may be granted the right or ability to transmit data without contention (e.g., without competing with other devices for access to the network). TXOPs may be granted through an Enhanced Distributed Channel Access (EDCA) mechanism. This technical solution allows the low latency (low delay) traffic of other devices (e.g., not holding the TXOP) on a wireless network, such as a WLAN, Bluetooth, cellular network, Zigbee, mesh network, or other, to preempt an ongoing frame exchange of a TXOP holder device (e.g., a device granted the TXOP). The technical solution may utilize a mechanism in a Wi-Fi system (e.g., 11bn) for a TXOP holder device (e.g., a Wi-Fi AP or a STA) to enable a STA associated with the TXOP holder and not granted the TXOP to preempt the TXOP holder's frame exchange sequence in favor of delivery of low-latency traffic by the STA (e.g., a non-TXOP holder device). In such a case, the TXOP holder device may utilize a portion of the TXOP for its own transmission, while simultaneously allowing the non-TXOP holder to use the remaining portion (e.g., other portion) of the TXOP for transmission by the non-TXOP holder STA. To enable such a preemption mechanism, one or more policies may be set or determined for the TXOP holder.
[0034] The technical solution enables preemption by a TXOP holder device through inserting a Point Coordinate Function (PCF) Interframe Space (PIFS) gap before a preemptable transmission. The technical solution then enables low latency traffic to be transmitted by the preempting device using a Shortest Interface Spacing (SIFS) gap. Upon detecting this transmission after the SIFS gap, the TXOP holder can abort its intended transmission.
[0035] The technical solution enables a device to transmit low latency traffic within a TXOP acquired by or granted to another device (e.g., a TXOP holder). The technical solution may take into account various factors, such as whether the TXOP holder is an AP or a non-AP, whether the TXOP holder has more traffic (even lower priority) to transmit in its current TXOP (or further schedule in the case of an AP), and whether low latency transmissions are allowed only from the TXOP responder(s) or even from other device(s) in the Basic Service Set (BSS).
[0036] Based on such considerations, embodiments of the technical solution may utilize techniques that can be classified into two categories: when the TXOP holder device is an AP, and when the TXOP holder device is not an AP (e.g., a STA). The technical solution may be used to share medium access even between technologies such as UWB (Ultra-Wide Band) or high-priority Bluetooth to preempt an ongoing transaction provided by a Wi-Fi TXOP. For Wi-Fi embodiments and standards, low latency (low delay) traffic may be a goal, and the proposed solution can achieve this goal with minimal or reduced product complexity.
[0037] The advantage of the technical solution is that it enables TXOP sharing in a controlled manner that minimizes collisions and minimizes product complexity, thereby enabling low latency (low delay) services. The technical solution may provide dynamic allocation opportunities based on desired requirements and may have the benefit or advantage of complying with applicable regional regulations, such as EU regulations.
[0038] Referring to FIG. 1, a diagram illustrating an exemplary communication environment 100 including communication systems (or communication devices) 105, 108 according to one or more embodiments is shown. In one embodiment, communication system 105 includes baseband circuitry 110 and transmitter circuitry 120, and communication system 108 includes baseband circuitry 150 and receiver circuitry 140. In one aspect, communication system 105 is considered a transmitting communication system, and communication system 108 is considered a receiving communication system. These components operate together to exchange data (e.g., messages or frames) over a wireless medium. These components, in one or more embodiments, are embodied as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any combination thereof. In some embodiments, communication systems 105, 108 include more, fewer, or different components than those shown in FIG. 1. For example, each of communication systems 105, 108 includes transceiver circuitry to enable bidirectional communication between communication systems 105, 108 or with other communication systems. In some embodiments, each of the communication systems 105, 108 may have a configuration similar to the computing system 200 shown in FIG.
[0039] The baseband circuitry 110 of the communication system 105 generates baseband data 115 for transmission. The baseband data 115 includes information data (e.g., signal(s)) at baseband frequencies for transmission. In one approach, the baseband circuitry 110 includes an encoder 130 that encodes data and generates or outputs parity bits. In one aspect, the baseband circuitry 110 (or the encoder 130) obtains a generator matrix or parity check matrix, or uses a previously generated generator matrix or parity check matrix, and encodes the information data by applying the information data to the generator matrix or parity check matrix to obtain a codeword. In some embodiments, the baseband circuitry 110 stores one or more generator matrices or one or more parity check matrices that comply with any IEEE 802.11 standard for WLAN communications. The baseband circuitry 110 retrieves the stored generator matrix or parity check matrix in response to detecting information data to be transmitted or in response to receiving an instruction to encode the information data. In one approach, the baseband circuitry 110 generates parity bits according to a portion of a generator matrix or using a parity check matrix, appends the parity bits to the information bits to form codewords, generates baseband data 115 including the codewords for the communication system 108, and provides the baseband data 115 to the transmitter circuitry 120.
[0040] The transmitter circuitry 120 of the communication system 105 includes or corresponds to circuitry that receives baseband data 115 from the baseband circuitry 110 and transmits radio signals 125 in accordance with the baseband data 115. In one configuration, the transmitter circuitry 120 is coupled between the baseband circuitry 110 and an antenna (not shown). In this configuration, the transmitter circuitry 120 upconverts the baseband data 115 from the baseband circuitry 110 to a carrier signal to generate radio signals 125 at an RF frequency (e.g., 10 MHz to 60 GHz) and transmits the radio signals 125 via the antenna.
[0041] The receiver circuit 140 of the communication system 108 is a circuit that receives the radio signal 125 from the communication system 105 and obtains baseband data 145 from the received radio signal 125. In one configuration, the receiver circuit 140 is coupled between the baseband circuit 150 and an antenna (not shown). In this configuration, the receiver circuit 140 receives the radio signal 125 via the antenna and downconverts the radio signal 125 to an RF frequency in accordance with a carrier signal to obtain the baseband data 145 from the radio signal 125. The receiver circuit 140 then provides the baseband data 145 to the baseband circuit 150.
[0042] The baseband circuitry 150 of the communication system 108 includes or corresponds to circuitry that receives baseband data 145 from the receiver circuitry 140 and obtains information data from the received baseband data 145. In one embodiment, the baseband circuitry 150 includes a decoder 160 that extracts information bits and parity bits from the baseband data 145. The decoder 160 decodes the baseband data 145 to obtain the information data generated by the baseband circuitry 110 of the communication system 105.
[0043] In some embodiments, each of baseband circuitry 110 (including encoder 130), transmitter circuitry 120, receiver circuitry 140, and baseband circuitry 150 (including decoder 160) may exist as one or more processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any combination thereof.
[0044] FIG. 2 is a simplified block diagram of a computing system 200 according to one embodiment. The illustrated exemplary computing system 200 may include one or more processors 201 in direct or indirect communication with a memory 206 via a communication system 204 (e.g., a bus), at least one network interface controller 203 with a network interface port for connecting to a network (not shown), and other components (e.g., input / output (“I / O”) components 205). Generally, the processor(s) 201 may execute instructions (e.g., computer code or programs) received from a memory (e.g., 206 or 202). The illustrated processor(s) 201 may incorporate or be connected to a cache memory 202. In some cases, instructions are read from the memory 206 into the cache memory 202 and executed from the cache memory 202 by the processor(s) 201. Computing system 200 may not necessarily include all of the components shown in FIG. 2, and may include other components not shown in FIG.
[0045] More specifically, the processor(s) 201 may be any logic circuitry that processes instructions (e.g., instructions fetched from memory 206 or cache 202). In many implementations, the processor(s) 201 is a microprocessor unit or a special-purpose processor. The computing device 205 may be based on any processor or set of processors capable of operating as described herein. The processor(s) 201 may be a single-core processor(s) or a multi-core processor(s). The processor(s) 201 may be multiple different processors.
[0046] The memory 206 may be any device suitable for storing computer-readable data. The memory 206 may be a device with permanent storage or a device for reading removable storage media. Examples include all forms of volatile memory (e.g., RAM), non-volatile memory, media and memory devices, semiconductor memory devices (e.g., EPROM, EEPROM, SDRAM, and flash memory devices), magnetic disks, magneto-optical disks, and optical disks (e.g., CD-ROM, DVD-ROM, Blu-ray disc). The computing system 200 may have any number of memory devices 206.
[0047] Cache memory 202 is a type of computer memory that is generally located in close proximity to processor(s) 201 for fast read times. In some implementations, cache memory 202 is part of processor(s) 201 or is on the same chip as processor(s) 201. In some implementations, there are multiple levels of cache 202 (e.g., an L2 cache layer and an L3 cache layer).
[0048] The network interface controller 203 manages data exchange through network interfaces (sometimes called network interface ports). The network interface controller 203 handles the physical and data link layers of the OSI model for network communication. In some implementations, some of the network interface controller's tasks are handled by one or more processors 201. In some implementations, the network interface controller 203 is part of the processor 201. In some implementations, the computing system 200 has multiple network interfaces 203 controlled by a single controller. In some implementations, the computing system 200 has multiple network interface controllers 203. In some implementations, each network interface is a connection point for a physical network link (e.g., a cat-5 Ethernet link). In some implementations, the network interface controller 203 supports wireless network connectivity, and the interface port is a wireless (e.g., radio) receiver or transmitter (e.g., for either the IEEE 802.11 protocol, Near Field Communication "NFC," Bluetooth, ANT, or any other wireless protocol). In some implementations, the network interface controller 203 implements one or more network protocols, such as Ethernet. Generally, the computing device 205 exchanges data with other computing devices over a physical or wireless link via a network interface. The network interface may link to another device directly or through an intermediate device (e.g., a network device such as a hub, bridge, switch, or router) to connect the computing device 200 to a data network, such as the Internet.
[0049] Computing system 200 may include or provide interfaces for one or more input or output ("I / O") devices. Input devices include, but are not limited to, keyboards, microphones, touch screens, foot pedals, sensors, MIDI devices, and pointing devices such as mice or trackballs. Output devices include, but are not limited to, video displays, speakers, refreshable Braille terminals, lights, MIDI devices, and 2D or 3D printers.
[0050] Other components may include I / O interfaces, external serial device ports, and any additional coprocessors. For example, computing system 200 may include interfaces (e.g., a Universal Serial Bus (USB) interface) for connecting input devices, output devices, or additional memory devices (e.g., a portable flash drive or external media drive). In some implementations, computing device 200 includes additional devices such as coprocessors, e.g., a mathematical coprocessor, that can assist processor 201 with high-precision or complex calculations.
[0051] Components 209 may be configured to interface with external media, display 207, input devices 208, or any other components within computing system 200, or combinations thereof. Display 207 may be a liquid crystal display (LCD), an organic light emitting diode (OLED) display, a flat panel display, a solid state display, a cathode ray tube (CRT) display, a projector, a printer, or other display device now known or later developed for outputting determined information. Display 207 may serve as an interface for a user to ascertain the functionality of processor(s) 201, or specifically with software stored in memory 206.
[0052] Input device 208 may be configured to allow a user to interact with any of the components of computing system 200. Input device 208 may be a cursor control device such as a pad, keyboard, mouse, or joystick, a remote control, a touchscreen display (which may be a combination of display 207 and input device 208), or any other device operative in conjunction with computing system 200 to interact with computing system 200 (e.g., any device operative in conjunction with computing system 200 to act as an interface between a user and computing system 200).
[0053] FIG. 3 illustrates an example system 300 for providing transmit opportunity (TXOP) sharing for latency-sensitive traffic of non-TXOP holder devices. System 300 may incorporate, utilize, or be implemented using any combination of features of communication environment 100 of FIG. 1 or computing system 200 of FIG. 2. System 300 may include a TXOP holder device 305 and one or more non-TXOP devices 350 (e.g., devices 350A, 350B, 350C, or 350D) that can communicate with each other over a wireless network, such as a wireless local area network (WLAN) 302 or any other wireless network or technology, such as Bluetooth, Zigbee, a cellular network, or a mesh net. The TXOP holder device 305 can include one or more transmit opportunities (TXOPs) 310, which can include one or more transmit opportunity (TXOP) periods 312. Each TXOP period 312 can include any number (e.g., multiple) of transmit opportunity (TXOP) portions 314. A TXOP portion 314 can include a time period, subsection, or portion of time within the TXOP 310 during which one or more transmissions (e.g., by the TXOP holder device 305 or by one or more other non-TXOP devices 350) can be performed (e.g., transmitted over a WLAN).
[0054] The TXOP holder device 305 may include one or more data type determiners 320 for determining various data types 322 that may be transmitted. The TXOP holder device 305 may include one or more transmission managers 324 for managing or implementing various transmissions 326. The TXOP holder device 305 may include one or more TXOP portion allocators 340 for allocating various TXOP portions 314 to various WLAN devices (e.g., the TXOP holder device 305 or any of the non-TXOP devices 350 (e.g., 350A-350D)). The TXOP holder device 305 may include one or more availability determiners 330 for generating, processing, or providing availability indications 332 and receiving or processing availability responses 334 from the various non-TXOP devices 350 along with or according to any response delays 336 of such availability responses 334.
[0055] Each non-TXOP device 350 (e.g., 350A-350D) may include one or more transmit managers 324 for managing the non-TXOP device's 350 transmissions 326 and one or more data type determiners 320 for determining the non-TXOP device's 350 data type 322. The non-TXOP device 350 may include one or more availability responders 360 that may receive one or more availability indications 332 (e.g., from the TXOP holder device 305) and generate one or more availability responses 334 (e.g., in response to such availability indications 332) along with response delays 336 for such responses 334 for the non-TXOP device 350. In response to dynamic changes or grants of TXOPs 310 that may be granted or assigned to any of the devices, the TXOP holder 305 may change into a non-TXOP device 350, and vice versa, depending on the implementation.
[0056] The TXOP holder device 305 may be a device of the WLAN 302 that has been granted a transmit opportunity (TXOP) 310 for use in transmitting (e.g., transmitting from the TXOP holder device 305) during the TXOP period 312 of the TXOP 310. The TXOP holder device 305 may include a WLAN access point (AP) device or a client device (e.g., a STA) associated with a WLAN AP device. The TXOP 310 may be granted to the TXOP holder device 305 by the WLAN access point (AP) or by another TXOP holder device 305 (e.g., a station). The TXOP holder device 305 may identify a first TXOP portion 314 of the TXOP period 312 for one or more transmissions over the WLAN 302 of the TXOP holder device 305. The first TXOP portion 314 of the TXOP may be the initial portion of the TXOP 310 through which the TXOP holder device 305 may transmit network traffic for the TXOP holder device 305. The TXOP holder device 305 may utilize an availability determiner 330 to identify, detect, or determine that the remaining TXOP portions 314 of the TXOP period 312 following the first TXOP portion 314 are available for data transmission for one or more other (e.g., non-TXOP) devices 350 of the WLAN 302.
[0057] The TXOP holder device 305 may include a client device (e.g., a STA) of a WLAN access point (AP) device, and the non-TXOP device 350 may include a WLAN AP device. The TXOP holder device 305 may identify uplink data of a first device (e.g., 305) for transmission to a second device (e.g., 350). Based on the uplink data, the TXOP holder device 305 may determine to allocate the remaining portion of the TXOP period 312 (e.g., remaining TXOP portion 314) to the second device (e.g., 350) so that the second device transmits downlink data to the first device (e.g., 305). The remaining TXOP portion 314 may include any portion of the TXOP 310 granted to the TXOP holder device 305 after the first TXOP portion 314 through which the non-TXOP device 350 may transmit their network traffic. A first device (e.g., 305) can be configured to determine to allocate the remaining portion of the TXOP period 312 to a second device (e.g., 350) based on an amount of uplink data that meets a threshold. For example, the threshold can include an amount of uplink data that is met (e.g., exceeded) by the uplink data. The TXOP holder device 305 can include a first client device associated with a WLAN access point (AP) device, and the second device can include a second client device associated with the WLAN AP device, in which case the first device can allocate the remaining portion of the TXOP period 312 (e.g., 314) to the second device for peer-to-peer communication.
[0058] The TXOP holder device 305 may utilize the availability determiner 330 to generate and transmit an indication of availability (e.g., availability indication 332) to one or more other (e.g., non-TXOP) devices 350 via the WLAN 302. The availability indication (e.g., 332) may include any indication, message, or transmission signal that may indicate to the non-TXOP devices 350 the availability of the remaining TXOP portion 314 of the TXOP 310 for transmission by the non-TXOP devices 350. For example, in response to determining that a low latency transmission has completed or is about to complete, the TXOP holder device 305 may decide to generate the availability indication 332 to the non-TXOP devices 350 on the WLAN 302 to ascertain whether any of the non-TXOP devices 350 have a low latency transmission signal to transmit via the WLAN 302 during the remaining TXOP portion 314 of the TXOP 310.
[0059] The TXOP holder device 305 may receive one or more availability responses 334 to the availability indication 332 in response to an availability indication 332 sent by the TXOP holder device 305 to one or more other devices. In response to the received one or more availability responses 334, the TXOP holder device 305 may utilize a TXOP portion allocator 340 to determine, select, or allocate a remaining portion (e.g., 314) of the TXOP period 312 to a second device (e.g., non-TXOP device 350) of one or more other (e.g., non-TXOP) devices. The second device may use the remaining TXOP portion 314 to transmit its data during at least a portion of the remaining portion of the TXOP period 312.
[0060] The wireless local area network (WLAN) 302 may include any network that enables devices (e.g., 305 or 350) to connect and communicate wirelessly within a limited area, using, for example, Wi-Fi technology. The WLAN 302 may include any implementation of a wireless local area network that enables communication between multiple networked devices within a local area, such as a home, office, or campus. The WLAN 302 may facilitate data exchange between devices, including TXOP holder devices 305 and non-TXOP devices 350, using wireless transmission methods, such as those conforming to standards including IEEE 802.11. The WLAN 302 may enable these devices to connect, share transmit opportunities (TXOPs), and manage data transmission through a structured and controlled environment. The WLAN 302 may support various types of data communications, including voice, video, and best-effort traffic, depending on the needs and configuration of the communicating devices. The wireless nature of WLAN 302 can provide flexibility and mobility to devices, allowing such devices (eg, 305 or 350) to communicate without the constraints of physical cables.
[0061] A transmit opportunity (TXOP) holder device 305 may include any combination of hardware and software (e.g., a network device) that has acquired or been granted a TXOP 310 to control or transmit data over a network during a designated TXOP period. A TXOP holder device 305 may include any device configured to communicate over a wireless local area network (WLAN) 302 that has gained control over a transmit opportunity (TXOP). A TXOP holder device 305 may be responsible for managing and allocating a TXOP period 312 to itself or other devices within the WLAN 302. A TXOP holder device 305 may facilitate or regulate communications to enable efficient use of the available TXOP period 312. For example, the TXOP holder device 305 may include a Wi-Fi access point (AP) device or a client (e.g., a smartphone, tablet, or computer) wireless communication device that can acquire a TXOP 310 for managing network traffic over one or more TXOP periods 312 or over one or more TXOP portions 314 of the TXOP period 312.
[0062] The non-TXOP devices 350 may include any devices within the WLAN 302 that do not currently hold the TXOP 310 but that can receive a transmission signal during the TXOP period 312 and respond to the availability indication 332 for possible low-latency transmissions. The non-TXOP devices 350 (e.g., devices 350A, 350B, 350C, or 350D) may include devices within the WLAN 302 that do not initially hold the TXOP 310. The non-TXOP devices 350 can communicate with the TXOP holder device 305 and with each other. The non-TXOP devices 350 can rely on the TXOP holder device 305 to allocate a portion of the TXOP period 312 (e.g., one or more TXOP portions 314) to be used for transmissions by the non-TXOP devices 350. The non-TXOP devices 350 may include various client devices, such as smartphones, laptop computers, and IoT devices, that can participate in network communications under the coordination of the TXOP holder device 305.
[0063] A transmission opportunity (TXOP) 310 may represent one or more specific time intervals during which a TXOP holder device 305 may transmit data over the WLAN 302. The TXOP 310 may be used to manage network traffic by sequencing communications to avoid communication collisions. The TXOP 310 may allow the TXOP holder to control the flow of information within a specified time interval. The TXOP 310 may allow the TXOP holder device 305 to have exclusive access to the wireless medium, reducing collisions and optimizing network performance, as well as allowing other non-TXOP devices 350 to transmit data.
[0064] A transmit opportunity (TXOP) period 312 can include a subdivision of any time interval within a TXOP 310. A TXOP period 312 can provide a subdivision of one or more TXOPs 310 during which a particular network device (e.g., a TXOP holder device 305 or a non-TXOP device 350) can transmit or receive data. Each TXOP period 312 can include a defined time slot, which can be further divided into multiple portions (e.g., TXOP portions 314) that can be used or allocated for different types of transmissions. The TXOP period 312 can be used to synchronize or time data transmissions within the WLAN 302, allowing each device to have sufficient time to transmit its data.
[0065] The transmission opportunity (TXOP) portion 314 can include any portion or segment within the TXOP period 312. The TXOP portion 314 can be allocated by the TXOP holder device 305 for a particular transmission, such as a transmission of a particular data type 322 or a transmission by a particular device (e.g., 305 or 350). The TXOP portion 314 allows for partial or fine-grained allocation of sections of the TXOP period 312 to different devices or types of data (e.g., low latency transmissions or high priority transmissions), allowing for improved or optimized use of available bandwidth. For example, the TXOP portion 314 can be allocated for video data transmission, while another portion can be reserved for voice or best-effort traffic.
[0066] The data type determiner 320 may include any combination of hardware or software within a device (e.g., the TXOP holder device 305 or the non-TXOP device 350) that can identify and classify types of data. The data type determiner 320 may include functionality to detect, identify, or sense any type of data to be transmitted over the WLAN 302. The data type determiner 320 may identify or distinguish low latency (low delay) data from other data that can tolerate longer delays. The data type determiner 320 may evaluate the nature of the data, such as video, voice, or best-effort traffic, and help prioritize transmission based on the data type. Such classification may be utilized to facilitate latency-sensitive data, such as video data, being transmitted immediately while other data (e.g., voice) may be transmitted with some delay.
[0067] The data types 322 may include any type and format of data that may be transmitted over the WLAN 302. The data types 322 may include various categories of data that may be transmitted by the TXOP holder device 305 or the non-TXOP device 350. The data types 322 may include various priority levels of data, such as high-priority data (e.g., augmented reality data, control signals, gaming data, or video streaming) and low-priority data that can tolerate a higher threshold of latency (e.g., Internet of Things (IoT) routine updates, background synchronization of collaboration data). The data types 322 may include video (VI), voice (VO), best-effort (BE) traffic, gaming data, sensor data, control signals, financial transactions, emergency calls, virtual or augmented reality data, IoT data, or collaboration data. The data types 322 may include various types of high-priority or low-latency data (e.g., control signals, gaming data, video streaming).
[0068] The transmit manager 324 may include any combination of hardware and software for managing the execution of transmissions 326 by the TXOP holder device 305 or non-TXOP devices 350. The transmit manager 324 may oversee the scheduling, initiation, and completion of data transmissions, such as transmissions of low-latency data, high-latency data, or any transmissions carried over the WLAN 302. The transmit manager 324 may include functionality that enables each device to efficiently transmit its data within its assigned TXOP portion. For example, the transmit manager 324 may schedule a video data transmission during a high-priority TXOP portion while deferring less important data transmissions to a later transmission.
[0069] The transmit manager 324 may schedule the transmission 326 of the first device's data during a first portion (e.g., first TXOP portion 314) of the TXOP period 312. The first portion (e.g., first TXOP portion 314) of the TXOP period 312 may be allocated by the transmit manager 324 to a non-TXOP device 350 to be reclaimed or reused by the TXOP holder device 305 during a second portion 314 following the first portion. For example, the TXOP holder may determine that the data to be transmitted by the TXOP holder is stale, should be refreshed, or can be updated, and therefore more time may pass before the TXOP holder device 305 is ready to transmit its own data. Depending on such a determination, the TXOP holder 305 may allocate, grant, or schedule the first TXOP portion 314 to the second device once the updated or refreshed data arrives and is ready for transmission, and may schedule the second TXOP portion 314 to the TXOP holder 305 to follow the first TXOP portion 314.
[0070] A first apparatus (e.g., the TXOP holder apparatus 305) may be configured to schedule a transmission 326 of the second apparatus's data, which is low latency data, to a second device (e.g., a non-TXOP apparatus 350) for at least a first portion of the remainder of the TXOP period. For example, the first apparatus (e.g., the TXOP holder apparatus 305) may be configured to schedule a transmission 326 of the third apparatus's data, which is low latency data, to a third apparatus (e.g., another non-TXOP apparatus 350) among one or more other apparatuses of the WLAN 302 for at least a second portion (e.g., 314) of the remainder of the TXOP period 312. The second portion (e.g., the second TXOP portion 314) of the TXOP period 312 may follow the first portion (e.g., the first TXOP portion 314) of the TXOP period.
[0071] A transmission 326 may include any act of transmitting or sending data over the WLAN 302 by a TXOP holder device 305 or a non-TXOP device 350. A transmission 326 may occur during an allocated TXOP portion 314 of a TXOP period 312. A transmission 326 may be managed by a transmission manager 324. The actual transmission 326 may vary depending on the data type 322, where each type utilizes specific processing for efficient and timely delivery.
[0072] The availability determiner 330 may include any combination of hardware and software for the TXOP holder device 305 to determine, detect, or identify the availability of one or more TXOP portions 314 for non-TXOP devices 350 to utilize for the transmission of their communications (e.g., low latency or high priority communications). The availability determiner 330 may identify or detect TXOP portions 314 within the TXOP period 312 to offer for the transmission of their network traffic (e.g., low latency or high priority transmissions) to non-TXOP devices 350.
[0073] The availability determiner 330 may generate, process, or provide an availability indication 332 to the non-TXOP device 350. The availability determiner 330 may handle receiving and processing an availability response 334 (e.g., generated by the non-TXOP device 350 in response to the availability indication 332). The availability determiner 330 may take into account any response delay 336. The availability determiner 330 plays a key role in regulating the use of the remaining TXOP period by assessing which devices are immediately available to transmit and how much time is available.
[0074] The availability determiner 330 may determine that the remaining portion of the TXOP period 312 (e.g., the next TXOP portion 314) is available for one or more other (e.g., non-TXOP) devices 350 to transmit low latency data during the remaining portion. For example, the availability determiner 330 may determine that the remaining TXOP portion 314 is available for transmission 326 by one or more non-TXOP devices 350 in response to determining that a scheduled transmission 326 occupying a first portion of the TXOP period 312 is to be completed before the start of the remaining portion (e.g., 314).
[0075] The availability determiner 330 may determine the data type 322 of the transmission 326 based on the response of one or more availability responses 334 of the second device (e.g., non-TXOP device 350). For example, the availability determiner 330 may determine that the data of the second device is high priority data or low latency data based on the availability response 334. The availability determiner 330 may identify that one or more transmissions of the first data of the first device are of a first priority. The availability determiner 330 may identify that one or more second transmissions of the second data to be transmitted by the first device are of a second priority that is lower than the first priority, and may determine to transmit an availability indication 332 in response to the second data being of a second priority.
[0076] The availability determiner 330 may transmit an availability indication 332 to one or more other (e.g., non-TXOP) devices 350 via one or more physical layer protocol data units (PPDUs). The availability determiner 330 may receive one or more block acknowledgments (BAs) from one or more other devices (e.g., non-TXOP devices 350) in response to the one or more PPDUs. The one or more BAs may include one or more responses (e.g., availability responses 334) that may be indicated using one or more bits in one or more fields of the one or more BAs. For example, the non-TXOP device 350 may indicate that it has a low latency type transmission 326 to transmit in the TXOP portion 314 made available by the TXOP holder device 305 using a bit in a field of the BA. The availability determiner 330 may select a second device (e.g., a non-TXOP device 350) for transmitting during the remaining TXOP portion 314 based on one or more bits in one or more fields of one or more BAs.
[0077] The availability determiner 330 may identify a corresponding plurality of random response delays 336 within the TXOP period 312 for a plurality of the one or more other (e.g., non-TXOP) devices 350. Each random response delay 336 of the plurality of random delays for each device of the one or more other (e.g., non-TXOP) devices 350 may be different from each other random response delay 336 of the plurality of delays for each other non-TXOP device 350 of the one or more other devices. Each random response delay 336 may identify a non-TXOP device 350 associated with the given response delay 336.
[0078] The availability determiner 330 may select a second device (e.g., a non-TXOP device 350) for use in transmitting 326 via the TXOP portion 314 from one or more other devices (e.g., 350) based on the second device's respective random delay (e.g., response delay 336). For example, the availability determiner 330 of the TXOP holder device 305 may select a particular non-TXOP device 350 from multiple non-TXOP devices 350 to grant the TXOP portion 314 for transmission. This selection may be made based on the response delay 336 of the particular non-TXOP device 350. For example, the availability determiner 330 may select a particular non-TXOP device 350 based on the response delay 336 of this non-TXOP device 350 being the shortest among multiple response delays 336 whose availability responses 334 indicated that low latency data should be transmitted. The TXOP portion allocator 340 may then allocate the remaining portion of the TXOP period 312 to a second device (e.g., the selected non-TXOP device 350) in response to the selection, depending on the selection by the availability determiner 330.
[0079] Each of the plurality of random delays 336 (e.g., each of the plurality of availability responses 334) can correspond to a timing for transmitting a respective availability response 334 of one or more responses by a respective non-TXOP device 350 of one or more other non-TXOP devices 350. Selection of a second device (e.g., a non-TXOP device 350 to utilize the remainder of the TXOP portion 314) can be based on the timing of each of the second device's random response delays 336 (e.g., of the availability responses 334), such that the availability response 334 from the second device is received by the first device (e.g., the TXOP holder device 305) before each of the other respective responses of each of the other remaining devices.
[0080] The availability determiner 330 may determine that a second device (e.g., a non-TXOP device 350 to be selected to transmit via the TXOP portion 314) has completed transmission 326 of the second device's data during a first portion of the remaining portion of the TXOP period 312. The availability determiner 330 may determine to transmit a second one or more transmissions of the first device over the WLAN 302 during a second portion of the remaining portion of the TXOP period 312. The second portion of the remaining portion of the TXOP period 312 may follow the first portion.
[0081] The availability indication 332 may include any signal or message transmitted by the TXOP holder device 305 to inform the non-TXOP devices 350 that the remaining TXOP portions 314 of the TXOP period 312 are available for transmission by the non-TXOP devices 350. The availability indication 332 may be transmitted by the TXOP holder device 305 to indicate to the non-TXOP devices 350 that a low latency transmit signal by the non-TXOP devices 350 may be transmitted during one or more next TXOP portions 314. The availability indication 332 may be used to regulate transmission by the non-TXOP devices 350 during the remaining TXOP period (e.g., the TXOP portions 314 that remain available for transmission by the non-TXOP devices 350 within the TXOP 312). The availability indication 332 transmitted by the TXOP holder device 305 may enable the non-TXOP devices 350 to respond and potentially acquire access rights for their wireless transmissions (e.g., the remaining TXOP portions 314).
[0082] The availability response 334 may include any response or reply by the non-TXOP device 350 in response to receiving the availability indication 332 from the TXOP holder device 305. The availability response 334 may indicate whether the non-TXOP device is ready to use the remaining TXOP period for low-latency transmissions. The availability response 334 may be generated according to a particular device-specific delay (e.g., response delay 336) to avoid collisions with other responding devices. The TXOP holder device 305 can use the availability response 334 from the non-TXOP device 350 to determine or decide how to effectively allocate the remaining TXOP period (e.g., TXOP portion 314) to the other non-TXOP devices 350.
[0083] The response delay 336 may include any timing delay associated with the availability response 334 transmitted by the non-TXOP device 350. Each non-TXOP device 350 may have a unique response delay 336 for transmitting its availability response 334 to the availability indication 332 of the TXOP holder device 305. The response delay 336 may correspond to a unique time interval between the transmission or reception of the availability indication 332 and the transmission time of the non-TXOP device's 350's availability response 334. For example, a first non-TXOP device 350 may have a first response delay 336 for transmitting its first availability response 334 to the availability indication 332 of the TXOP holder device 305. For example, a second non-TXOP device 350 may have a second response delay 336 (e.g., different from the first response delay 336 of the first non-TXOP device 350) for transmitting its second availability response 334 to the same availability indication 332. Based on the difference in time duration between the two response delays 336, one of the availability responses 334 may be sent before the second response to avoid collisions and prioritize some of the non-TXOP devices 350 over others. The response delay 336 may affect how quickly the TXOP holder device 305 receives and processes the availability responses, which may affect the scheduling of transmissions within the remaining TXOP period 312. The availability determiner 330 may manage the response delay 336 to facilitate allocation of the remaining transmission time (e.g., allocating TXOP portions 314 to particular non-TXOP devices 350).
[0084] The TXOP portion allocator 340 may include any combination of hardware and software for distributing the TXOP portions 314 to various WLAN devices, including both the TXOP holder device itself and any non-TXOP devices 350 (e.g., 350A-350D). The TXOP portion allocator 340 may facilitate each device receiving its appropriate share of the TXOP duration based on factors such as data type, priority, and device capabilities. The TXOP portion allocator 340 may include functionality for distinguishing and identifying non-TXOP devices 350 with the highest priority data to transmit (e.g., low latency data), thereby prioritizing the transmission of these higher priority non-TXOP devices over others. In response to a second device (e.g., non-TXOP device 350) having low latency data, the TXOP portion allocator 340 may allocate the remaining TXOP portions 314 to the second device (e.g., for transmission during one or more TXOP portions 314).
[0085] The availability responder 360 may include any combination of hardware and software within the non-TXOP device 350 that can receive the availability indication 332 (e.g., from the TXOP holder device 305) and generate an availability response 334. The availability responder 360 may generate the availability response 334 for the non-TXOP device 350 based on a response delay 336 specific to that non-TXOP device 350. The availability responders 360 for multiple non-TXOP devices 350 may generate unique response delays 336 for the availability responses 334, thereby allowing each of the availability responses 334 to be transmitted within a unique delay window from the availability indication 332. The availability responder 360 may indicate whether the non-TXOP device is ready to use the remaining portion of the TXOP period 312 (e.g., the TXOP portion 314) for transmission (e.g., a low latency transmission).
[0086] Technical solutions may be directed to improving performance of latency-sensitive traffic through various TXOP sharing mechanisms, where latency-sensitive traffic is allowed to preempt or follow an ongoing frame exchange in a TXOP in a controlled manner. TXOP holder devices can be Wi-Fi AP devices or non-AP devices (e.g., STAs). TXOP holders can have traffic to transmit, including higher or lower priority than non-TXOP devices. Low-latency transmissions can be granted from TXOP responders or from other devices within the BSS.
[0087] When an AP is a TXOP holder device 305 and the AP has no more data to transmit or schedule in its TXOP 310 and wants to share the remaining portion of the TXOP 312, the TXOP holder can use one or more solutions to share a portion of the TXOP with non-TXOP devices. For example, the device can use TXOP sharing (TXS) modes 1 and 2 defined in 11be. However, these schemes may have the limitation that the AP can only share its TXOP with one client. Such sharing may be based on information received from the client about possible UL or P2P transmissions, but without any accurate estimation of traffic volume. This may not allow the AP to share the remainder of the TXOP in a non-dedicated manner (i.e., when the identity of potential transmitters of low latency (LL) traffic is unknown to the AP).
[0088] The AP can schedule LL traffic indications and then schedule LL traffic based on the response(s) to the LL traffic indication. For TXOP responders, the LL traffic indication can be implemented by overloading the reserved bit in the BA or by using the QoS control or Buffer Status Report (BSR) control subfield in the same PPDU as the BA. For non-TXOP responders, a scheme similar to Uplink Orthogonal Random Access (UORA) can be used, where the AP indicates a latency-sensitive group AID and allows all clients with latency-sensitive TIDs to contend and gain access to UORA resources based on probability, indicating only the presence of LL traffic. Following such an indication of LL traffic from that client, the AP can trigger the client with LL traffic in a dedicated manner.
[0089] As an optimization, clients may use orthogonal codes (to be defined) to transmit their respective LL traffic indications on the same resources. The AP (e.g., TXOP holder) may directly schedule LL traffic. For example, the AP may use a scheme similar to UORA, where the AP indicates a latency-sensitive group AID, allowing all clients with latency-sensitive TIDs to randomly compete and transmit their traffic for the remaining duration of the TXOP. Such transmission of LL traffic by clients can be at single-user (SU) or multi-user (MU) or resource unit (RU) resolution, without any dedicated scheduling by the AP.
[0090] The SU option can have the advantage that the AP can reclaim ownership of a TXOP (through PIFS-based recovery) if the client is unable to utilize all of the remaining TXOPs. In this case, the AP can reallocate the TXOP for the same purpose or use it for some newly arrived latency-sensitive traffic. The MU option allows the AP to specify a common period (common duration) and allows clients to pad their LL transmissions to the common duration to avoid misaligned transmissions. Non-TXOP devices can indicate the presence of LL traffic to either the AP or its peers, and the AP's resource sharing can follow. The AP can use PIFS-based recovery of a TXOP for either of the above methods if a client does not have enough LL traffic to utilize (e.g., fully or partially) a TXOP shared by the AP.
[0091] In one configuration, an AP can be configured as a TXOP holder device 305, and the AP has more data to transmit or schedule in its TXOP. However, the TXOP holder may decide it is okay to pause (suspend) to allow latency-sensitive traffic from other clients in its BSS. When scheduling a MU-BA, the AP can also include a dedicated allocation of LL traffic indications in the UORA manner, so that it can subsequently yield the TXOP. The AP can yield the TXOP by scheduling those specific clients that have indicated the presence of LL traffic. The AP can yield the TXOP by indicating that it will pause transmission in this TXOP, so that the potential transmitter of LL traffic takes over after a SIFS gap. The AP can use this option when receiving LL traffic indications from a small number of clients, as this may reduce the likelihood of collisions. Clients can indicate the presence of LL traffic to either the AP or its peers, and the AP's resource sharing can proceed accordingly.
[0092] In some configurations, the TXOP holder device 305 can include a non-AP device, such as a STA. In such configurations, the client device may be unable to receive DL data due to the hidden node, may no longer have UL data to send, or may no longer intend to send UL data in the TXOP. The client may not be able to receive DL data because the AP may not have knowledge of the hidden node's period of activity, which prevents the client from responding with a Clear To Send (CTS) or an Acknowledgement (ACK). The client may be aware of this hidden node's activity. The client can obtain the TXOP and pass it to the AP to send DL data to the AP.
[0093] In some configurations, a client may no longer have UL data to send in the TXOP and may decide to share the remainder of the TXOP. The client may indicate that it has finished transmitting, along with the access category in which it acquired the TXOP and the remaining duration of the TXOP. How the remainder is used may be determined by AP or client policy. For example, the remainder may be used only for transmissions to the specific client that shared the TXOP. For example, the remainder may be used for latency-sensitive control traffic to other clients. For example, the remainder may be used for any traffic of equal or higher priority than the indicated Access Category (AC) but up to a threshold duration.
[0094] In some configurations of non-AP TXOP holders, a client may no longer have data to send in the TXOP but may pause to allow latency-sensitive traffic from other devices in the BSS. Similar to when the AP is the TXOP holder, the client may grant LL traffic indication opportunities from the AP or even from other clients in the BSS. The transmission of LL traffic indications by any of these devices may be based on random probability, with whichever one obtains the LL indication. Opportunities for non-TXOP responders may be as Frequency Division Multiplexing (FDM) RUs in the BA transmitted by the AP or as the time slot immediately following the BA. LL traffic indications sought from TXOP responder(s) may be provided by overloading reserved bits in the BA. Based on this, the client may pause its transmission. For example, based on random probability, another device may take over. For example, the AP may take over and schedule other clients. The AP may not have detected other clients that sent LL traffic indications during its own BA transmission. So a client that relinquishes its TXOP can include this information while doing so.
[0095] In some configurations, a non-AP device configured as a TXOP holder may include a client that has P2P traffic to send and wants to use the remaining TXOP for that purpose instead of yielding it for LL transmission by the AP or other device in the BSS. In this case, the client can send an indication to the AP that the remaining TXOP will be used for a P2P exchange. This approach can be more efficient than if the client had to send PM=1 to its AP and initiate a new EDCA process to acquire the channel and communicate over the P2P link.
[0096] In some configurations, the low latency traffic indication can be implemented in various ways. For example, a general LL indication can include a transmitted (e.g., BA) bit to indicate the presence or absence of LL traffic. In some situations, LL traffic may not be associated with a corresponding high access priority class, such as AC_VO or AC_VI. However, the LL traffic indication can specify the access priority class(es) of traffic that can use such a shared TXOP. If resources are randomly allocated, the identity of the device having the LL traffic can also be part of the indication. LL traffic can be intended for the TXOP holder or for another client or peer.
[0097] Traffic can be marked as low latency in a variety of ways. As enhancement schemes are defined to improve the performance of latency-sensitive traffic, this may also warrant appropriately marking traffic as latency-sensitive. For some technologies, traffic may be appropriately marked as latency-sensitive before using these schemes. The user priority and access category of a flow may not match the latency requirements of the traffic. Voice packets may use AC_BE, resulting in a user priority, and a rogue application / user may mark low-priority best-effort traffic as AC_VO. SCS parameters and QoS characteristic element values can be used to determine the latency tolerance and flow rate of a flow and mark it accordingly as latency-sensitive, regardless of user priority or access category.
[0098] 4 illustrates an example 400 in which an access point (AP) 405, a TXOP holder device 305, and a STA (e.g., a client or station device) 410 are engaged in sharing a TXOP 310. The example 400 illustrates a series of communication events in a WLAN 302 involving the access point (AP) 405, the TXOP holder device 305 (e.g., a first station, STA1), and a second STA 410 (e.g., a second station, a P2P device). The timeline for each device shows the TXOP holder device 305 first transmitting data labeled "Data (VI)" (e.g., video data) on its line, followed by the AP 405 responding with a block acknowledgement "BA (VO for STA1)" (e.g., audio data for STA1 or the TXOP holder device 305) on its line. The TXOP holder device 305 can then transmit another "Data (VI)" frame (e.g., video data), after which the STA 410 (e.g., STA2) can respond with a block acknowledgment "BA (BE for STA1)," indicating STA1's best-effort traffic category. Finally, STA1's timeline shows a "TBD" event with an arrow to the AP's line, indicating that STA1 shares the remaining TXOP with the AP. This sequence illustrates how STA1, as the TXOP holder, manages data transmission and coordinates with the AP and STA2 to optimize the use of transmission opportunities.
[0099] Technical solutions may include allowing a TXOP holder to explicitly decide whether to share a TXOP. TXOP sharing may be enabled bidirectionally between APs and non-AP STAs, as well as between IBSS STAs and P2P STAs. To facilitate this, a mechanism may be provided for a STA to indicate its interest in obtaining a shared TXOP, potentially by embedding information in a Block ACK frame.
[0100] TXOP sharing in UHR can be enhanced by embedding information in the Block-ACK to help the TXOP holder further inform the sharing decision. The proposed information in the Block-ACK can include details such as the highest priority AC pending transmission and whether the traffic is intended for the STA receiving the BA or for another STA, potentially using reserved bits in the BA Control field.
[0101] FIG. 5 illustrates an example 500 in which an access point (AP) 405, a TXOP holder device 305, and a STA (e.g., client or station device) 410 are engaged in sharing a TXOP 310. The example 500 depicts a data transmission and acknowledgment sequence involving three devices: the AP 405, the TXOP holder device 305, and the STA 410. Each device has its own timeline that illustrates the sequence of communication events. The first event occurs in the TXOP holder device 305's (e.g., STA1) timeline, where "Data (VI)" is transmitted, indicating a video transmission. Following this, in the AP 405 timeline, there is a box labeled "BA (BE not for STA1)," indicating that the AP 405 is transmitting a block acknowledgment (BA) for best-effort (BE) traffic that is not intended for STA1. The next event on the timeline of the TXOP holder 305 (e.g., STA1) is another "Data (VI)" transmission, indicating a continuation of the video data transmission. Following this, STA2 can respond with a "BA (VI for STA1)" acknowledging the video data (VI) received from STA1. Finally, in STA1's timeline, there is a box labeled "TBD" with an arrow pointing down towards STA2's timeline, indicating that STA1 is sharing its transmit opportunity (TXOP) with STA2 and that the AP can communicate with STA2 within the same TXOP period.
[0102] Some configurations may include a scheme that can take advantage of defer signal (DS)-based distributed access enforcement. The TXOP holder, which can be a UHR AP or a UHR non-AP, can transmit a special trigger frame at the end of its frame exchange in the TXOP to enable transmission by the owner of LL traffic within a special contention period immediately following the special trigger (e.g., 1 SIFS after it). A UHR non-AP may be able to transmit this special trigger frame if authorized by its UHR AP to do so. The special trigger frame can identify which owner of LL traffic is authorized to transmit during the special contention period following the special trigger, for example, by restricting it to devices within the BSS, by authorizing OBSSS devices, or by announcing one of various pre-determined groups of devices as authorized.
[0103] In some cases, the above special trigger frame may be transmitted by an AP after a short gap G=SIFS+N*slots from the end of an UL TXOP initiated by a non-AP (a non-AP can be UHR or pre-UHR / legacy in its BSS). In such cases, N may be predetermined (zero or non-zero) or selected such that N≦N_MAX, in which case N_MAX may be predetermined. The selection may be predetermined in the standard or as a network configuration parameter (which may be communicated to all devices).
[0104] Technical solutions may include improvements to distributed access. For example, this special trigger frame can explicitly reserve the medium for a special contention period by setting the NAV for SIFS+x (e.g., one or more) slots from the end of the trigger frame. If the special trigger frame reserves x slots, the candidate LL traffic owner can count down a random number K between 0 and x-1 and send an LL packet directly in SIFS+K* slots without having to send a DS.
[0105] In some configurations, a special trigger frame may not reserve the medium for any additional period, and the candidate LL traffic-owning device transmits a DS either in SIFS or PIFS after the end of the trigger frame (using this trigger frame for alignment). The special trigger frame may serve the purpose of time and frequency alignment, including correcting for various frequency offsets for the transmission of the DS. This may alleviate concerns that the DS may not be properly detected by other devices. The DS may be a CTS2SELF message with a predetermined duration value (e.g., EIFS). After transmitting the DS, i.e., from the end of the DS, the device that transmitted the DS may count down a random number of slots (e.g., between 0 and 7) and transmit an LL packet.
[0106] FIG. 6 illustrates an example method 600 for providing sharing of transmit opportunities (TXOPs) for latency-sensitive traffic of non-TXOP holder devices within a TXOP granted to a TXOP holder device. Method 600 may be implemented, for example, using systems 100-300 of FIGS. 1-3 or any of the functionality described in connection with FIGS. 1-5. Method 600 may include operations 605-620. At 605, the method may include identifying a first TXOP portion for transmission by the TXOP holder device. At 610, the method may include determining that the remaining TXOP portion is available for transmission by another device. At 615, the method may include transmitting an indication of availability of the remaining TXOP portion. At 620, the method may include allocating the remaining TXOP portion to a second device in response to the availability response.
[0107] At 605, the method can include identifying a first transmit opportunity (TXOP) portion for a transmission of a TXOP holder device. The method can include a first device (e.g., a TXOP holder device) configured to identify a first portion of a TXOP period for one or more transmissions of the first device that are transmitted or to be transmitted over a wireless local area network (WLAN). The first device can be a TXOP holder network device of the WLAN that has been granted a TXOP for transmitting a transmission signal to another device (e.g., a non-TXOP device) over the WLAN during a designated TXOP period, an assigned TXOP period, or a granted TXOP period (e.g., a TXOP time period).
[0108] In some implementations, a first device may determine to allocate, grant, or schedule a first portion of the TXOP period to another device (e.g., a second device). The first device may determine that the first device does not include data ready for immediate transmission within the first portion of the TXOP period. For example, the first device may identify whether the data to be transmitted by the first device is stale, stale, or needs to be refreshed. The first device may determine that, given the first device's data for transmission, the first portion of the TXOP period will not be fully utilized by the first device. In response to such a determination, the first device may allocate a first portion of the TXOP holder to the second device and allocate, grant, or schedule a second portion of the TXOP period following the first portion to the first device for the first device's transmission.
[0109] The first device may be a TXOP holder device and may include a WLAN access point (AP) device such as a Wi-Fi router. The first device may contact another device (e.g., a non-TXOP device), such as a second device, which may include a station (e.g., an STA) or any other client device (e.g., a smartphone, tablet, or computer device that communicates with a WLAN AP). The second device may be associated with or wirelessly communicate with the TXOP holder device (e.g., a WLAN AP device or the first device). In some implementations, the first device may be or include a STA or client device (e.g., a smartphone, tablet, or computer), which is communicatively coupled to the second device, which may be or include a WLAN AP device (e.g., a Wi-Fi router device) that is a TXOP holder device and a non-TXOP device.
[0110] A first device (e.g., a TXOP holder device) can schedule a communication. For example, the first device can schedule a transmission of the first device's data during a first portion of a TXOP period. The TXOP holder device can schedule one or more transmissions from the first device to one or more non-TXOP devices over the course of one or more TXOP portions of one or more TXOP periods. The TXOP holder device can schedule and perform one or more transmissions from or to the TXOP holder device over the course of a TXOP granted to the TXOP holder device. The one or more transmissions can be performed in response to the TXOP holder device prioritizing a low-latency transmission (e.g., high-priority data) over other data. The one or more transmissions can be low-latency or high-priority data or transmissions.
[0111] At 610, the method can determine that a remaining TXOP portion is available for transmission by other devices. For example, the method can include determining that a remaining portion of a TXOP duration following a first portion (e.g., in which the TXOP holder device transmitted its own transmission) is available for data transmission by one or more other devices of the WLAN. The one or more other devices can be non-TXOP holder devices of the WLAN, such as other Wi-Fi APs, STAs, or clients on the WLAN that are not the TXOP holder device designed for the given TXOP. The remaining portion of the TXOP duration can include one or more TXOP portions that can be used for one or more transmissions by the non-TXOP devices.
[0112] The method may include determining, in response to determining that a scheduled transmission occupying a first portion of the TXOP period should complete before the start of the remaining portion, that the remaining portion of the TXOP period is available for one or more other devices to transmit low latency data during the remaining portion. The method may include the TXOP holder device identifying first data of one or more transmissions of the first device to be of a first priority. The TXOP holder device may identify second data of a second one or more transmissions to be transmitted by the first device to be of a second priority that is lower than the first priority. The TXOP holder device may decide to transmit an indication of availability in response to the second data being of the second priority.
[0113] At 615, the method may include transmitting an availability indication of the remaining TXOP portion. The method may include the TXOP holder device transmitting, via the WLAN, to one or more other devices (e.g., non-TXOP devices) one or more indications of the availability of the remaining portion of the TXOP period for data transmission. The TXOP holder device may determine that the TXOP holder device's low-latency transmission is completed during the first portion of the TXOP period and that the remaining portion of the TXOP period (e.g., after the first portion) may be used for low-latency transmission by the non-TXOP device. In response to such a determination, the TXOP holder device may transmit one or more availability indications to inform the non-TXOP device that the remainder of the TXOP period is available for the non-TXOP device's high-priority or low-latency traffic.
[0114] The method may include transmitting an availability indication via one or more Physical Layer Protocol Data Units (PPDUs) to one or more other (e.g., non-TXOP) devices. The indication may include, for example, one or more data bits in one or more fields of the PPDU used to indicate the availability indication. The TXOP holder device may receive one or more Block Acknowledgments (BAs) from the one or more other devices in response to the one or more PPDUs. The one or more BAs may include one or more availability responses from the one or more non-TXOP devices. The one or more responses may indicate whether the non-TXOP devices are interested in the TXOP portion made available by the TXOP holder device. The one or more responses may be indicated using one or more bits in one or more fields of the one or more BAs. Upon receiving one or more BAs (e.g., availability responses) in response to one or more PPDUs (e.g., availability indications), the TXOP holder device can select a second device based on one or more bits in one or more fields of the one or more BAs. The second device can be a non-TXOP device that transmits its data (e.g., low latency traffic) over the TXOP portion enabled by the TXOP holder device.
[0115] The method may include identifying corresponding random delays within the TXOP period for a plurality of devices among the one or more other devices. Each random delay of the plurality of random delays for each device of the one or more other (e.g., non-TXOP) devices may be different from each other random delay of the plurality of delays for each other device of the one or more other devices. For example, a first non-TXOP device may respond to the TXOP holder device's availability indication with a first availability response having a first response delay length of a first time period delay, while a second non-TXOP device may respond to the same availability indication with a second availability response having a second response delay length of a second time period delay that is different (e.g., longer or shorter) than the first time period length. The length of the time period delay may be unique to each non-TXOP device and may be randomly assigned to each device on the WLAN.
[0116] The TXOP holder device can select a specific second device from one or more other (e.g., non-TXOP) devices to which a transmission signal will be transmitted during the remaining TXOP portion based on the random delay of each of the second devices. For example, the TXOP holder device can select a specific non-TXOP device based on multiple response delays of multiple availability responses from multiple non-TXOP devices. A specific non-TXOP device can be selected based on an availability response identifying a non-TXOP device indicating that it has low-latency traffic to transmit during the TXOP portion. An availability response identifying low-latency traffic from a specific non-TXOP device can be received before other availability responses are received by the TXOP holder device. For example, a second device can be selected based on the response delay of the second device's availability response that is the earliest positive response received in response to an availability indication.
[0117] The TXOP holder device can allocate the remaining portion of the TXOP duration to the second device, upon selection. Each of the plurality of random delays can correspond to a timing for transmitting a respective one of the one or more responses by a respective one of the one or more other devices. The selection of the second device can be based on the timing of each of the second device's random delays, such that a response from the second device is received by the first device before each of the other respective responses of each of the other remaining devices.
[0118] At 620, the method may include allocating a remaining TXOP portion to the second device in response to the availability response. The method may include allocating a remaining portion of the TXOP duration to the second device from the one or more other devices in response to one or more responses to the indication from the one or more other devices, and transmitting data for the second device during the remaining portion of the TXOP duration. The TXOP holder device may receive one or more availability responses to the availability indication and identify, from the plurality of responses, those responses that indicate the presence of low-latency traffic that may be transmitted by non-TXOP devices. The TXOP holder device may select from the identified responses that indicate low-latency traffic, those responses that arrive first, or the response with the greatest amount of low-latency traffic to transmit.
[0119] The TXOP holder device may select a second device from one or more other devices based on the second device's respective random delay. The TXOP holder device may allocate the remaining portion of the TXOP duration to the second device in response to the selection. The TXOP holder device may select a second device from one or more other devices based on the amount of low latency or high priority network traffic indicated by a response to be transmitted by a non-TXOP device.
[0120] The TXOP holder device may determine, based on the response of the one or more responses of the second device, that the data of the second device is low latency data. In response to the second device's data being low latency data, the TXOP holder device may allocate the remaining portion to the second device. The first device (e.g., the TXOP holder device) may be configured to schedule, to the second device, a transmission of the second device's data that is low latency data. Such a transmission may be scheduled for at least a first portion of the remaining portion of the TXOP period. The first device may be configured to schedule, to a third device, one or more other devices of the WLAN, a transmission of the third device's data that is low latency data, for at least a second portion of the remaining portion of the TXOP period. The second portion of the TXOP period may be a TXOP portion following the first portion of the TXOP period in which the second device transmitted its low latency traffic.
[0121] The TXOP holder device may determine that the second device has completed transmitting data for the second device during a first portion of the remaining portion of the TXOP duration. The TXOP holder device may determine to transmit a second one or more transmission signals for the first device over the WLAN during a second portion of the remaining portion of the TXOP duration (the second portion following the first portion). The TXOP holder device may identify uplink data of the first device for transmission to the second device and, based on the uplink data, determine to allocate the remaining portion of the TXOP duration to the second device so that the second device transmits downlink data to the first device. The first device may be configured to determine to allocate the remaining portion of the TXOP duration to the second device based on an amount of uplink data that meets a threshold. The threshold may be a threshold amount of uplink data. The first device may include a first client device associated with a WLAN access point (AP) device, and the second device may include a second client device associated with the WLAN AP device. The first device may be configured to allocate the remaining portion of the TXOP period to the second device for peer-to-peer communication (eg, Bluetooth® communication).
[0122] References to "or" may be construed as inclusive, such that any term described with "or" may refer to one, more than one, or all of the described terms. Reference to at least one of a conjunctive list of terms may be construed as an inclusive or to refer to one, more than one, or all of the described terms. For example, a reference to "at least one of 'A' and 'B'" can include "A" alone, "B" alone, and both "A" and "B." Such references used in conjunction with "comprises" or other open-ended terminology can include additional items.
[0123] It should be noted that certain passages of this disclosure may refer to terms such as "first" and "second" in connection with a subset of transmission spatial streams, sound frames, responses, and devices to identify or distinguish one from the other(s). These terms are not intended to merely relate entities temporally or sequentially (e.g., first device and second device), although in some cases these entities may include such a relationship. Nor do these terms limit the number of possible entities (e.g., STAs, APs) that may operate within a system or environment. It should be understood that the systems described above may provide multiples of any or each of these components, and that these components may be provided on standalone machines or, in some embodiments, on multiple machines in a distributed system. Furthermore, bit field positions may be varied and multi-bit words may be used. Additionally, the systems and methods described above may be provided as one or more computer-readable programs or executable instructions embodied on one or more articles of manufacture (e.g., floppy disks, hard disks, CD-ROMs, flash memory cards, PROMs, RAMs, ROMs, or magnetic tapes). The programs may be implemented in any programming language, such as LISP, PERL, C, C++, C#, or any byte-code language, such as JAVA. The software programs or executable instructions may be stored on one or more articles of manufacture as object code.
[0124] While the above description of the method and system will enable one skilled in the art to make and use the embodiments, one skilled in the art will understand and recognize that there are variations, combinations, and equivalents of the specific embodiments, methods, and examples herein. Accordingly, the present method and system should not be limited by the embodiments, methods, and examples described above, but by all embodiments and methods within the scope and spirit of the present disclosure.
Claims
1. 1. A system comprising: a first device in a wireless network that has been granted a transmission opportunity (TXOP) for transmission during a TXOP period, the first device comprising: Identifying a first portion of the TXOP period for one or more transmissions of the first device over the wireless network; determining that a remaining portion of the TXOP period after the first portion is available for data transmission by one or more other devices of the wireless network; transmitting, via the wireless network, an indication of availability for the remaining portion of the TXOP period for the data transmission to the one or more other devices; In response to one or more responses to the instruction from the one or more other devices, allocate a remaining portion of the TXOP period to a second device among the one or more other devices for transmitting data of the second device during the remaining portion of the TXOP period.
2. The first device is scheduling transmission of data of the first device during a first portion of the TXOP period; 2. The system of claim 1, further configured: in response to determining that the scheduled transmission occupying a first portion of the TXOP period is to complete before a start of the remaining portion, determine that the remaining portion of the TXOP period is available for the one or more other devices to transmit low latency data during the remaining portion.
3. The first device is determining, based on one response of the one or more responses of the second device, that the data of the second device is low latency data; The system of claim 1 , further configured to allocate the remaining portion to the second device in response to the second device's data being low latency data.
4. The first device is Identifying first data of one or more transmissions of the first device as being of a first priority; identifying second data of a second transmission or transmissions to be transmitted by the first device as being of a second priority lower than the first priority; The system of claim 1 , further configured to determine to transmit an indication of availability depending on the second data being of the second priority.
5. 2. The system of claim 1, wherein the first device is further configured to schedule transmission of data of the second device, the data being low latency data, to the second device for at least a first portion of the remaining portion of the TXOP period.
6. 6. The system of claim 5, wherein the first device is further configured to schedule transmission of data of the third device, the data being low latency data, to a third device among the one or more other devices of the wireless network for at least a second portion of the remaining portion of the TXOP period, the second portion following the first portion.
7. The first device is transmitting the indication to the one or more other devices via one or more physical layer protocol data units (PPDUs); receiving one or more Block Acknowledgments (BAs) from the one or more other devices in response to the one or more PPDUs, the one or more BAs including one or more responses indicated using one or more bits in one or more fields of the one or more BAs; The system of claim 1 , further configured to select the second device based on one or more bits in one or more fields of the one or more BAs.
8. The first device is identifying, for a plurality of the one or more other devices, a corresponding plurality of random delays within the TXOP period, wherein each random delay of the plurality of random delays for each device of the one or more other devices is different from each other random delay of each other device's plurality of delays of the one or more other devices; selecting a second device from the one or more other devices based on the random delay of each of the second devices; The system of claim 1 , further configured to allocate a remaining portion of the TXOP period to the second device in response to the selection.
9. 9. The system of claim 8, wherein each of the plurality of random delays corresponds to a timing for transmitting a respective response of the one or more responses by a respective device of the one or more other devices, and wherein the selection of the second device is based on the respective timing of the random delay of the second device, so that a response from the second device is received by the first device before each other respective response of each other remaining device.
10. The first device is determining that the second device has completed transmitting its data during a first portion of the remaining portion of the TXOP period; 2. The system of claim 1, further configured: determining to transmit a second one or more transmissions of the first device over the wireless network during a second portion of the remaining portion of the TXOP period, the second portion following the first portion.
11. 2. The system of claim 1, wherein the first device comprises a wireless local area network (WLAN) access point (AP) device and the second device comprises a client device associated with the WLAN AP device.
12. The first device comprises a client device of a wireless local area network (WLAN) access point (AP) device, the second device comprises the WLAN AP device, and the first device comprises: Identifying uplink data of the first device for transmission to the second device; 2. The system of claim 1, further configured to: determine, based on the uplink data, to allocate a remaining portion of the TXOP period to the second device so that the second device transmits downlink data to the first device.
13. 13. The system of claim 12, wherein the first device is configured to determine to allocate a remaining portion of the TXOP period to the second device based on an amount of the uplink data that meets a threshold.
14. 10. The system of claim 1, wherein the first device comprises a first client device associated with a wireless local area network (WLAN) access point (AP) device, and the second device comprises a second client device associated with the WLAN AP device, and the first device is further configured to allocate a remaining portion of the TXOP period to the second device for peer-to-peer communications.
15. 1. A method comprising: identifying, by a first device in a wireless local area network (WLAN) that has been granted a transmit opportunity (TXOP) for transmission during the TXOP period, a first portion of the TXOP period for one or more transmissions of the first device over the WLAN; determining, by the first device, that a remaining portion of the TXOP period after the first portion is available for data transmission by one or more other devices in the WLAN; transmitting, by the first device, via the WLAN to the one or more other devices, an indication of availability regarding the remaining portion of the TXOP period for the data transmission; allocating, by the first device, in response to one or more responses to the instruction from the one or more other devices, a remaining portion of the TXOP period to a second device of the one or more other devices for transmitting data of the second device during the remaining portion of the TXOP period.
16. scheduling, by the first device, transmission of data of the first device during a first portion of the TXOP period; 16. The method of claim 15, comprising: determining, by the first device, in response to determining that the scheduled transmission occupying a first portion of the TXOP period is to complete before the start of the remaining portion, that the remaining portion of the TXOP period is available for the one or more other devices to transmit low latency data during the remaining portion.
17. determining, by the first device, based on one of the one or more responses of the second device, that the data of the second device is low latency data; 16. The method of claim 15, comprising allocating, by the first device, the remaining portion to the second device in response to the second device's data being low latency data.
18. identifying, by the first device, first data of one or more transmissions of the first device as being of a first priority; identifying, by the first device, second data of a second transmission or transmissions to be transmitted by the first device as a second priority lower than the first priority; 16. The method of claim 15, comprising determining, by the first device, to transmit an indication of availability in response to the second data being of the second priority.
19. 16. The method of claim 15, comprising scheduling transmission of the second device's data, the second device being low latency data, for at least a first portion of the remaining portion of the TXOP period.
20. 1. A non-transitory computer-readable medium storing instructions that, when executed by at least one processor of a first device in a wireless local area network (WLAN) that has been granted a transmit opportunity (TXOP) for transmission during a TXOP period, cause the at least one processor to: Identifying a first portion of the TXOP period for one or more transmissions of the first device over the WLAN; determining that a remaining portion of the TXOP period after the first portion is available for data transmission by one or more other devices of the WLAN; transmitting, via the WLAN, an indication of availability of the remaining portion of the TXOP period for data transmission to the one or more other devices; In response to one or more responses to the instruction from the one or more other devices, allocating a remaining portion of the TXOP period to a second device among the one or more other devices for transmitting data of the second device during the remaining portion of the TXOP period.