Low latency session setup and use

Abstract

The invention relates to a method for low latency session setup and use in a wireless local area network. A pair of wireless devices may perform a low latency session setup that establishes one or more low latency session parameters for a low latency session between the wireless devices. During the low latency session, a low latency traffic indication may be provided in a non-low latency data frame and control response frame exchange, the low latency traffic indication being usable to indicate whether the wireless device receiving the non-low latency data frame has a low latency request.

Description

Technical Field

[0001] This application relates to wireless communication, including techniques and devices for establishing, using, and tearing down low-latency sessions in a wireless local area network.

[0002] Description of Related Technologies

[0003] Wireless communication systems are ubiquitous. Additionally, wireless communication technologies have evolved from voice-only communication to also include the transmission of data such as Internet and multimedia content.

[0004] A mobile electronic device or station (STA) or user equipment device (UE) may take the form of a smart phone or tablet device that a user typically carries. One aspect of wireless communication that may typically be performed by a mobile device may include, for example, wireless networking via a wireless local area network (WLAN), which may include devices operating according to one or more communication standards in the IEEE 802.11 standard family. In a wireless local area network, certain traffic may be delayed when other communications in the network are being performed. At least in some cases, this may potentially lead to performance degradation of traffic for which low latency is important. Therefore, improvements in this area are desired. Summary of the Invention

[0005] Embodiments of systems, apparatuses, and methods are presented herein for, among other things, establishing, using, and tearing down low-latency sessions in a wireless local area network by a device.

[0006] A wireless device may include: one or more antennas; one or more radio components operatively coupled to the one or more antennas; and a processor operatively coupled to the one or more radio components. The wireless device may be configured to establish a connection with an access point via a wireless local area network (WLAN) over one or more wireless links, or may be an access point configured to establish a connection with one or more other wireless devices via a WLAN over one or more wireless links. The wireless device may operate in each of the plurality of wireless links using a respective radio component of the one or more radio components.

[0007] According to the techniques described herein, a wireless device can establish a low-latency session with low-latency session parameters configured to support latency-sensitive flow requirements. The low-latency session parameters can include parameters that limit the target length of non-low-latency data frames, which can allow for more frequent opportunities to send low-latency frames. Additionally or alternatively, the low-latency session parameters can support preemption of transmission opportunities being used for non-low-latency communication to perform low-latency communication. Once the low-latency session is no longer desired, it is possible for any wireless device in the low-latency session to tear down the low-latency session.

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

[0009] This summary is intended to provide a brief overview of some of the subject matter described in this document. Accordingly, it should be understood that the above features are merely examples and should not be construed in any way as narrowing the scope or essence of the subject matter described herein. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following detailed description, the drawings, and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0011] Figure 1 An example wireless communication system including wireless devices is illustrated in accordance with some embodiments;

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

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

[0014] Figure 4 is a flowchart illustrating an example method for establishing, using, and tearing down a low-latency session in a wireless local area network in accordance with some embodiments;

[0015] Figures 5 to 6 An example scenario in which TX shortening may occur is illustrated in accordance with some embodiments, including PPDU burst examples and TXOP duration limit examples;

[0016] Figure 7 Illustrates example aspects of a scenario in which a STA experiences a channel access delay while waiting for a TXOP to complete, according to some embodiments;

[0017] Figure 8 Is a timing diagram that illustrates example aspects of a possible low-latency session setup and tear-down, according to some embodiments;

[0018] Figure 9 Is a signal flow diagram that illustrates example aspects of a possible low-latency session setup and tear-down communication, according to some embodiments;

[0019] Figure 10 Illustrates example aspects of a low-latency session scenario in which a TXOP initiator pre-empts its own TXOP to send low-latency data to a TXOP responder, according to some embodiments;

[0020] Figure 11 Illustrates aspects of an example low-latency session scenario in which TXOP bursts are each limited to one PPDU, according to some embodiments;

[0021] Figure 12 Illustrates example aspects of a possible low-latency session scenario in which a TXOP is shared by a TXOP initiator and a TXOP responder to allow the TXOP responder to send low-latency data to the TXOP initiator, according to some embodiments;

[0022] Figures 13 to 16 Illustrates examples of the use of possible low-latency session characteristics during an uplink communication scenario, according to various embodiments;

[0023] Figures 17 to 20 Illustrates examples of the use of possible low-latency session characteristics during a downlink communication scenario, according to various embodiments;

[0024] Figures 21 to 23 Illustrates example aspects of a possible low-latency session scenario in which a TXOP initiator may optionally reject a pre-emption request from a TXOP responder, according to some embodiments;

[0025] Figures 24 to 25 Illustrates example aspects of a possible low-latency session scenario in which a STA requests TXOP detachment, according to some embodiments;

[0026] Figures 26 to 28 Illustrates example aspects of a possible low-latency session scenario in which TXOP pre-emption is used for P2P communication, according to some embodiments;

[0027] Figure 29 Illustrates example aspects of a possible low-latency session scenario in which TXOP preemption occurs at the start of a TXOP, according to some embodiments;

[0028] Figures 30 to 31 Illustrates example aspects of a possible low-latency session scenario in which BA feedback is not received, according to some embodiments;

[0029] Figure 32 Illustrates example aspects of a possible update to the BA frame format to support low-latency feedback in a low-latency session, according to some embodiments;

[0030] Figures 33 to 34 Illustrates example aspects of a possible multi-STA BA frame that can be used to support low-latency feedback in a low-latency session; and

[0031] Figures 35 to 38 Illustrates example aspects of a possible low-latency session setup and tear-down frame element format, according to some embodiments.

[0032] Although the features described herein are susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are described in detail herein. However, it should be understood that the drawings and the detailed description thereof are not intended to be limiting to the particular form disclosed, but on the contrary, are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the subject matter as defined by the appended claims. Detailed Description

[0033] Terms

[0034] The following are definitions of terms used in this disclosure:

[0035] Memory medium—any of various types of non-transitory memory devices or storage devices. The term “memory medium” is intended to include any computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media, e.g., a hard disk drive or an optical storage device; registers or other similar types of memory elements, etc. The term “memory medium” may include two or more memory media that may reside in different locations (e.g., in different computer systems connected by a network). The memory medium may store program instructions (e.g., embodied as a computer program) executable by one or more processors.

[0036] Carrier media - such as the memory media described above, and physical transmission media such as buses, networks, and / or other physical transmission media that convey signals (such as electrical, electromagnetic, or digital signals).

[0037] Computer system - any of a variety of types of computing or processing systems, including personal computer systems (PCs), server-based computer systems, wearable computers, network appliances, Internet appliances, smart phones, television systems, grid computing systems, or other devices or combinations of devices. Generally speaking, the term "computer system" can be broadly defined to cover any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0038] User Equipment (UE) (or "UE device") - any of a variety of types of computer systems or devices that are mobile or portable and perform wireless communication. Examples of UE devices include mobile phones or smart phones (e.g., phones based on iPhone TM , Android TM ), portable gaming devices, laptop computers, wearable devices (e.g., smart watches, smart glasses), portable Internet devices, music players, data storage devices, or other handheld devices, automobiles and / or motor vehicles, unmanned aerial vehicles (UAVs) (e.g., drones), UAV controllers (UAC), etc. Generally speaking, the term "UE" or "UE device" can be broadly defined to cover any electronic device, computing device, and / or telecommunications device (or combination of these devices) that is easily transportable by a user and capable of performing wireless communication.

[0039] Wireless device or station (STA) - any of a variety of types of computer systems or devices that perform wireless communication. The wireless device can be portable (or mobile), or it can be stationary or fixed in a certain location. The terms "station" and "STA" are used similarly. A UE is an example of a wireless device.

[0040] Communication device - any of a variety of types of computer systems or devices that perform communication, where the communication can be wired or wireless. The communication device can be portable (or mobile), or it can be stationary or fixed in a certain location. A wireless device is an example of a communication device. A UE is another example of a communication device.

[0041] Base station or access point (AP) - The term "base station" (also referred to as "eNB" or "gNB") has the full breadth of its ordinary meaning and includes at least a wireless communication station installed at a fixed location and used for communication as part of a wireless communication system. The term "access point" (or "AP") is typically associated with Wi-Fi-based communication and is used similarly.

[0042] Processing element (or processor) - refers to various elements or combinations of elements that are capable of performing functions in a device (e.g., a communication device or a network infrastructure device). A processor may include, for example: a processor and associated memory, circuitry such as an ASIC (application specific integrated circuit), portions or circuitry of individual processor cores, entire processor cores, processor arrays, programmable hardware devices such as field programmable gate arrays (FPGAs) and / or larger portions of a system that includes multiple processors, and any combination of the above elements in various combinations.

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

[0044] Configured to - various components may be described as "configured to" perform one or more tasks. In such contexts, "configured to" is a broad statement generally meaning "having" the "structure" to perform one or more tasks during operation. Thus, even when the component is not currently performing a task, the component may be configured to perform the task (e.g., a collection of electrical conductors may be configured to electrically connect a module to another module even when the two modules are not connected). In some contexts, "configured to" may be a broad statement generally meaning "having" the "circuitry" to perform one or more tasks during operation. Thus, even when the component is not currently powered on, the component may be configured to perform the task. Generally, the circuitry that forms the structure corresponding to "configured to" may include hardware circuitry.

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

[0046] Figures 1 to 2 —Wireless communication system

[0047] Figure 1 Illustrates an example of a wireless communication system. It should be noted that Figure 1Represents one possibility among many possibilities and can implement the features of the present disclosure through any one of various systems as needed. For example, the embodiments described herein can be implemented in any type of wireless device. The wireless embodiments described below are an example embodiment.

[0048] As shown, an exemplary wireless communication system includes an access point (AP) 102 that communicates with one or more wireless devices 106A, 106B, etc. via a transmission medium. The wireless devices 106A and 106B can be user devices, such as a station (STA), a non-AP STA, or a WLAN device.

[0049] The STA 106 can be a device with wireless network connectivity, such as a mobile phone, a handheld device, a wearable device, a computer or a tablet computer, an unmanned aerial vehicle (UAV), an unmanned aircraft controller (UAC), an automobile, or almost any type of wireless device. The STA 106 can include a processor (processing element) configured to execute program instructions stored in a memory. The STA 106 can execute any of the method embodiments described herein by executing such stored instructions. Alternatively or additionally, the STA 106 can include programmable hardware elements, such as an FPGA (field programmable gate array), an integrated circuit, and / or any one of various other possible hardware components configured to execute (e.g., individually or in combination) any of the method embodiments described herein or any part of any of the method embodiments described herein.

[0050] The AP 102 can be a stand-alone AP or an enterprise AP and can include hardware capable of enabling wireless communication with the STA devices 106A and 106B. The AP 102 can also be equipped to communicate with a network 100 (e.g., a WLAN, an enterprise network, and / or another communication network connected to the Internet, and various possible networks). Thus, the AP 102 can facilitate communication between the STA devices 106 and / or communication between the STA devices 106 and the network 100. In other embodiments, the AP 102 can be configured to provide communication through one or more wireless technologies, such as any one, any combination, or all of the following: 802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ad, 802.11ax, 802.11ay, 802.11be, and / or other 802.11 versions, or cellular protocols, such as 5G or LTE, including in unlicensed bands (e.g., LAA, NR-U).

[0051] The communication area (or coverage area) of AP 102 may be referred to as a basic service area (BSA) or a cell. AP 102 and STA 106 may be configured to communicate via a transmission medium using any one of various radio access technologies (RATs) or wireless communication technologies such as Wi-Fi, LTE, advanced LTE (LTE-A), 5G NR, ultra-wideband (UWB), etc.

[0052] Accordingly, AP 102 and other similar access points (not shown) operating according to one or more wireless communication technologies may be set up as a network that can provide continuous or nearly continuous overlapping services to STA devices 106A to 106B and similar devices in a geographical area via, for example, one or more communication technologies. The STA may roam directly from one AP to another or may transition between an AP and a cellular network cell.

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

[0054] As shown, the exemplary wireless communication system may further include an access point (AP) 104 that communicates with the wireless device 106B via a transmission medium. AP 104 also provides a communication connection to the network 100. Accordingly, according to some embodiments, the wireless device may be capable of connecting to one or both of AP 102 (or a cellular base station) and access point 104 (or another access point) to access the network 100. For example, the STA may roam from AP 102 to AP 104 based on one or more factors such as coverage, interference, and capabilities. Note that AP 104 may also allow access to a network different from the network to which AP 102 allows access (e.g., an enterprise Wi-Fi network, a home Wi-Fi network, etc.).

[0055] STA 106A and STA 106B may include handheld devices such as smart phones or tablet devices, wearable devices such as smart watches or smart glasses, and / or may include any device of various types having cellular communication capabilities. For example, one or more of STA 106A and / or STA 106B may be wireless devices intended for fixed or nomadic deployments such as home appliances, measurement devices, control devices, etc.

[0056] STA 106B may also be configured to communicate with STA 106A. For example, STA 106A and STA 106B may be capable of performing direct device-to-device (D2D) communication. In some embodiments, such direct communication between STAs may also be referred to as or alternatively referred to as peer-to-peer (P2P) communication. The direct communication may be supported by AP 102 (e.g., AP 102 may facilitate discovery and various possible forms of assistance), or may be performed in a manner not supported by AP 102. According to various embodiments, such P2P communication may be performed using any one of the communication technologies such as 3GPP-based D2D communication technology, Wi-Fi-based P2P communication technology, UWB, BT, and / or various other direct communication technologies.

[0057] STA 106 may include one or more devices or integrated circuits for facilitating wireless communication, which may potentially include a Wi-Fi modem, a cellular modem, and / or one or more other wireless modems. The wireless modem may include one or more processors (processor elements) and various hardware components as described herein. STA 106 may execute any of the method embodiments (or any part thereof) described herein by executing instructions on one or more programmable processors. For example, STA 106 may be configured to perform techniques for establishing, using, and / or tearing down low-latency sessions in a wireless communication system according to various embodiments described herein. Alternatively or additionally, one or more processors may be one or more programmable hardware elements such as FPGAs (field-programmable gate arrays), application-specific integrated circuits (ASICs), or other circuits configured to execute any of the method embodiments described herein or any part of any of the method embodiments described herein. The wireless modems described herein may be used for STA devices as defined herein, wireless devices as defined herein, or communication devices as defined herein. The wireless modems described herein may also be used for APs, base stations, pico cells, femto cells, or other similar network-side devices.

[0058] STA 106 may include one or more antennas for communicating using two or more wireless communication protocols or radio access technologies. In some embodiments, STA 106 may be configured to communicate using a single shared radio component. The shared radio component may be coupled to a single antenna or may be coupled to multiple antennas (e.g., for MIMO) for performing wireless communication. Alternatively, STA 106 may include two or more radio components, each radio component being configured to communicate via a respective wireless link. Other configurations are also possible.

[0059] Figure 2 – Example block diagram of a STA device

[0060] Figure 2 Illustrates a possible block diagram of a STA device such as STA device 106. In some cases, STA 106 may alternatively be referred to as UE 106. STA 106 may also be referred to as non-AP STA 106. As shown, STA 106 may include a system-on-chip (SOC) 300, which may include one or more parts configured for various purposes. Some or all of the various illustrated components (and / or other device components not illustrated, e.g., in variations and alternative arrangements) may be "communicatively coupled" or "operatively coupled", and these terms may be used herein to denote components that can communicate directly or indirectly when the device is in operation.

[0061] As shown, SOC 300 may include a processor 302 and a display circuit 304. The processor may execute program instructions for STA 106, and the display circuit may perform graphics processing and provide a display signal to a display 360. SOC 300 may also include a motion sensing circuit 370, which may detect the motion of STA 106 using, for example, a gyroscope, an accelerometer, and / or any one of various other motion sensing components. One or more processors 302 may also be coupled to a memory management unit (MMU) 340, which may be configured to receive addresses from one or more processors 302 and translate these addresses into locations in a memory (e.g., memory 306 and read-only memory (ROM) 350, flash memory 310). MMU 340 may be configured to perform memory protection and page table translation or setup. In some embodiments, MMU 340 may be included as part of processor 302.

[0062] As shown, SOC 300 may be coupled to various other circuits of STA 106. For example, STA 106 may include various types of memory (e.g., including NAND flash 310), a connector interface 320 (e.g., for coupling to a computer system, a docking station, a charging station, etc.), a display 360, and a wireless communication circuit 330 (e.g., for LTE, LTE-A, 5G NR, Bluetooth, Wi-Fi, NFC, GPS, UWB, etc.).

[0063] STA 106 may include at least one antenna and in some embodiments may include multiple antennas 335a and 335b for performing wireless communication with a base station and / or other devices. For example, STA 106 may use antennas 335a and 335b to perform wireless communication. As described above, STA 106 may be configured to perform wireless communication using multiple wireless communication standards or radio access technologies (RATs) in some embodiments.

[0064] The wireless communication circuit 330 may include a Wi-Fi modem 332, a cellular modem 334, and a Bluetooth modem 336. The Wi-Fi modem 332 is used to enable the STA 106 to perform Wi-Fi or other WLAN communications, for example, on an 802.11 network. The Bluetooth modem 336 is used to enable the STA 106 to perform Bluetooth communications. The cellular modem 334 may be a cellular modem capable of performing cellular communications according to one or more cellular communication technologies, for example, according to one or more 3GPP specifications.

[0065] As described herein, the STA 106 may include hardware components and software components for implementing the embodiments of the present disclosure. For example, one or more components of the wireless communication circuit 330 of the STA 106 (e.g., the Wi-Fi modem 332, the cellular modem 334, the BT modem 336) may be configured to implement part or all of the methods for low-latency session establishment and use described herein, for example, by a processor that executes program instructions stored in a memory medium (e.g., a non-transitory computer-readable memory medium), a processor configured as an FPGA (field programmable gate array), and / or using dedicated hardware components that may include an ASIC (application specific integrated circuit).

[0066] Figure 3 – Block diagram of the access point

[0067] Figure 3 An example block diagram of an access point (AP) 104 according to some embodiments is illustrated. In some cases (e.g., in the context of 802.11 communications), the AP 104 may also be referred to as a station (STA) and may more specifically be referred to as an AP STA. Note that Figure 3 the AP shown is merely one example of a possible access point. As shown, the AP 104 may include a processor 404 that can execute program instructions for the AP 104. The processor 404 may also be coupled to a memory management unit (MMU) 440 or other circuits or devices, which may be configured to receive addresses from the processor 404 and translate these addresses into locations in a memory (e.g., memory 460 and read-only memory (ROM) 450).

[0068] The AP 104 may include at least one network port 470. The network port 470 may be configured to be coupled to a telephone network and provide access to the telephone network to multiple devices such as the STA device 106, as described above in Figure 1 above.

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

[0070] The AP 104 may include one or more radio components 430A to 430N and at least one antenna 434 (and may include multiple antennas), and each radio component may be coupled to a corresponding communication link. One or more antennas 434 may be configured to operate as a wireless transceiver and may be further configured to communicate with UE devices 106 / 107 via the radio components 430. Antennas 434A to 434N communicate with their corresponding radio components 430A to 430N via communication links 432A to 432N. The communication link 432 may be a receive link, a transmit link, or both. The radio components 430A to 430N may be configured to communicate according to various wireless communication standards, including but not limited to LTE, LTE-A, 5G NR, UWB, Wi-Fi, BT, etc. The AP 104 may be configured to operate on multiple wireless links using one or more radio components 430A to 430N, where each radio component is used to operate on a corresponding wireless link.

[0071] The AP 104 may be configured to perform wireless communication using multiple wireless communication standards. In some cases, the AP 104 may include multiple radio components that may enable a network entity to communicate according to multiple wireless communication technologies. For example, as one possibility, the AP 104 may include a 4G or 5G radio component for performing communication according to 3GPP wireless communication technologies and a Wi-Fi radio component for performing communication according to Wi-Fi. In this case, the AP 104 may be capable of operating as both a cellular base station and a Wi-Fi access point. As another possibility, the AP 104 may include a multi-mode radio component capable of performing communication according to any of multiple wireless communication technologies (e.g., 5G NR and Wi-Fi, 5G NR and LTE, etc.). As another possibility, the AP 104 may be configured to specifically function as a Wi-Fi access point, e.g., in the absence of cellular communication capabilities.

[0072] As further described herein, the AP 104 may include hardware and software components for implementing or supporting the specific implementation of the features described herein (such as setting up, using and / or tearing down low latency sessions in a wireless communication system). The processor 404 of the AP 104 may be configured to implement or support implementing part or all of the methods described herein, for example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium) to operate multiple wireless links using multiple corresponding radio components. Alternatively, the processor 404 may be configured as a programmable hardware element, such as an FPGA (field programmable gate array), or an ASIC (application-specific integrated circuit), or a combination thereof. Alternatively (or in addition), in combination with one or more of the other components 430, 432, 434, 440, 450, 460, 470, the processor 404 of the AP 104 may be configured to implement or support implementing part or all of the features described herein.

[0073] Figure 4 - Low latency session establishment, use, and tear down

[0074] Figure 4 is a flow chart illustrating a method for supporting low latency session setup, use, and teardown in a WLAN according to some embodiments. In various embodiments, some of the elements of the method shown may be performed simultaneously in an order different from the order shown, may be replaced by other method elements, or may be omitted. Additional method elements may also be performed as needed.

[0075] Figure 4 Aspects of the method may be performed by a wireless device (such as, Figures 1 to 3 The method may be implemented by the AP 104 or STA 106 shown and described in relation to these figures, or more generally, may be implemented in combination with any of the computer circuits, systems, devices, elements or components shown in the figures as desired. For example, a processor (and / or other hardware) of such a device may be configured to cause the device to perform any combination of the illustrated method elements and / or other method elements.

[0076] Note that although the present invention is described in a manner that relates to the use of communication techniques and / or features associated with IEEE 802.11 specification documents, Figure 4 but this description is not intended to limit the present disclosure, and Figure 4 The various aspects of the method can be used in any suitable wireless communication system as needed. As shown in the figure, the method can be operated as follows.

[0077] At least two wireless devices may establish a wireless association (452). According to various embodiments, any wireless communication technology among Wi-Fi, wireless communication technologies at least partially based on Wi-Fi, and / or various other wireless communication technologies may be used to establish the wireless association. For example, as one possibility, an access point (AP) wireless device may provide a beacon transmission including information for associating with the AP wireless device, and one or more other wireless devices (e.g., non-AP wireless devices) may use the information provided in the beacon transmission to request to associate with the AP wireless device. Such an association may also be referred to as an infrastructure link. As another example, two peer wireless devices may perform signaling to establish a peer-to-peer (P2P) communication session. Such an association may also be referred to as a P2P link. Variations and / or other techniques for establishing an association are also possible.

[0078] At least according to some embodiments, the wireless association may be used by the associated wireless devices to perform wireless local area network communication between the associated wireless devices. As part of the wireless local area network functionality, depending on the general provisions of the wireless communication technology used by the wireless local area network (e.g., Wi-Fi, as one possibility) and / or network-specific parameters configured by the AP wireless device or negotiated by peer devices, it is possible for wireless devices to compete for medium access and to perform wireless transmissions on one or more wireless communication channels (each of which may include multiple sub-channels). For example, in some embodiments, data transmission may include competing for medium access (e.g., to avoid collisions and potential interference), and once medium access is obtained, a physical layer (PHY) protocol data unit (PPDU) (which may also be referred to as an uplink frame or a downlink frame, depending on the traffic direction) is sent to the destination wireless device. The frame may include physical layer signaling (e.g., including: a preamble for frame detection, timing, and frequency synchronization, channel estimation, etc., and header information indicating packet configuration, format, data rate, channel occupancy time, and / or other control information) and data (which in turn may include one or more higher layer packets, such as a medium access control (MAC) protocol data unit (MPDU)).

[0079] Wireless devices (for ease of understanding, referred to herein as "a first wireless device" and "a second wireless device") may establish a low-latency session (454). Performing low-latency session establishment may include establishing one or more low-latency session parameters for a low-latency session between the first wireless device and the second wireless device. For example, a low-latency session establishment request and response exchange may be performed by the first wireless device and the second wireless device. The low-latency session establishment request may be sent by either the first wireless device or the second wireless device, and may indicate desired parameters for the low-latency session. The low-latency session establishment response may be sent by the other of the first wireless device or the second wireless device, and may indicate whether the low-latency session establishment request is accepted or rejected. Thus, according to various embodiments, the first wireless device may send a low-latency session establishment request to the second wireless device and receive a low-latency session establishment response from the second wireless device, or the first wireless device may receive a low-latency session establishment request from the second wireless device and send a low-latency session establishment response to the second wireless device.

[0080] In the case where the low-latency session establishment request is rejected, the low-latency session establishment response indicates that one or more proposed low-latency session parameters different from the one or more low-latency session parameters indicated in the low-latency session establishment request are possible. In such a scenario, the originator of the low-latency session establishment request may follow up with a second low-latency session establishment request that may indicate desired parameters for a low-latency session different from the first low-latency session establishment request, where the desired parameters may be selected, for example, at least in part based on the low-latency session parameters proposed by the low-latency session establishment response (e.g., to match the proposed parameters, or otherwise based on the proposed parameters). If desired, multiple such exchanges may occur between the wireless devices to negotiate a set of acceptable low-latency session parameters. Alternatively, for example, if no agreement can be reached between the wireless devices on the low-latency session parameters, it may not be possible to establish the low-latency session establishment.

[0081] Low latency session parameters can include any one of a variety of possible parameters. One possible aspect of low latency session parameters can include a set of one or more traffic identifiers (TIDs) that are configured for latency-sensitive traffic flows of a low latency session for one or more of a downlink or uplink traffic direction. According to various embodiments, the TIDs configured for latency-sensitive traffic flows can be the same for both traffic directions, or can be different for the downlink traffic direction and the uplink traffic direction. At least according to some embodiments, designating one or more TIDs and traffic directions as latency-sensitive and one or more other TIDs and traffic directions as non-latency-sensitive can be used to determine whether a transmission opportunity (TXOP) preemption can be performed by a wireless device establishing a low latency session during the low latency session. For example, at least in some cases, the arrival of low latency data (e.g., data associated with a TID configured for a latency-sensitive traffic flow for a given traffic direction) can provide a basis for the wireless device to preempt a TXOP that is being used for non-low latency data (e.g., data associated with a TID not configured for a latency-sensitive traffic flow for a given traffic direction) during the low latency session.

[0082] Another possible aspect of low latency session parameters can include a target physical layer protocol data unit (PPDU) length limit for non-low latency traffic during a low latency session. At least according to some embodiments, such a target limit can be used to prevent a wireless device participating in a low latency session from transmitting a non-low latency PPDU that is longer than the target PPDU limit, such that opportunities to preempt a TXOP for latency-sensitive data communication are available at a sufficient frequency to meet the latency requirements of latency-sensitive data.

[0083] Yet another possible aspect of low latency session parameters can include enabling or disabling PPDU bursting during a TXOP during a low latency session. At least according to some embodiments, such a parameter can provide additional control over medium contention and / or the frequency at which TXOP preemption opportunities are available during a low latency session.

[0084] Once the low-latency session setup is complete, the wireless device can perform data communication (456) using the low-latency session parameters during the low-latency session. As a possibility, such communication can include non-low-latency data frame and control response frame exchanges. In such a scenario, the length of the non-low-latency data frame can be determined at least in part based on the target PPDU length limit for non-low-latency traffic during the low-latency session. Additionally or alternatively, the control response frame can include a low-latency traffic indication that can indicate whether the device sending the control response frame has a low-latency request. As another possibility, it may be possible to have TXOP preemption / sharing at the start of the TXOP. For example, an initial control frame (e.g., a Block Acknowledgment Request (BAR) frame, a Quality of Service (QoS) Null frame, a Multi-User Transmit Request (MU-RTS) frame, a Buffer Status Report Poll (BSRP), etc.) can be used to solicit a BA or other control response frame that can include a low-latency request or other preemption indication.

[0085] According to some embodiments, the low-latency traffic indication can be used to indicate any of a plurality of possible meanings. For example, various values of the low-latency traffic indication field can be possible, where each such value has a defined meaning. The low-latency traffic indication can, for example, indicate any of the following: a request to send low-latency traffic to the wireless device that is the TXOP initiator in the TXOP; a request to send low-latency traffic to a wireless device that is not the TXOP initiator in the TXOP; a request to detach from the TXOP; a request for the amount of time of the TXOP; or no low-latency request. As needed, other types of low-latency traffic indications can be additionally or alternatively possible.

[0086] According to various embodiments, the low-latency traffic indication can be provided in a BA frame, a Multi-Station (M-STA) BA frame, or another type of control response frame. For example, according to various embodiments, certain reserved bits of an existing BA frame format can be defined to provide the low-latency traffic indication, a variant of the existing BA frame format (such as M-STA BA, as an example) can be used, or a new type of BA frame format can be defined to include one or more fields or sub-fields for providing the low-latency traffic indication.

[0087] The TXOP initiator (e.g., the first wireless device or the second wireless device, depending on various possible scenarios) may determine whether it notices a low latency traffic indication. For example, the TXOP initiator may determine to continue the TXOP, or share the TXOP, or terminate the TXOP, at least in part based on the low latency traffic indication. In the case of sharing the TXOP, a control frame indicating the shared TXOP may be sent to the TXOP responder. The TXOP responder may perform low latency communication during the shared TXOP (e.g., send a low latency data frame to the TXOP initiator or another wireless device). If there is any remaining duration in the TXOP, the TXOP responder may send a control frame to the TXOP initiator after performing the low latency communication (e.g., after the duration of the TXOP shared with the TXOP responder) to return the TXOP to the TXOP initiator.

[0088] In the case of TXOP termination, a control frame indicating that the TXOP is terminating may be sent to the TXOP responder, or possibly, the TXOP initiator may release the wireless medium without sending any such control frame. The termination of the TXOP may allow the TXOP responder or another device competing for the wireless medium to initiate a new TXOP, which may facilitate low latency communication including one of the wireless devices in the low latency session. For example, if the TXOP responder expects to receive low latency data from another device, it may be useful to request the termination of the TXOP to allow that other device to attempt to obtain medium access to send a low latency transmission.

[0089] If the TXOP responder uses the low latency traffic indication to provide a request to disassociate from the TXOP, it is possible that the TXOP initiator may continue the TXOP without the TXOP responder. For example, the TXOP initiator may send one or more SU or MU PPDUs to other wireless devices. At least in some cases, the TXOP responder may use such an indication if it expects to send or receive low latency data with another device on another link.

[0090] The low latency session (458) may be torn down at a later time. According to some embodiments, either wireless device in the low latency session may be capable of tearing down the low latency session. For example, the first wireless device may send a low latency session teardown message to the second wireless device, or the second wireless device may send a low latency session teardown message to the first wireless device. Thus, it is possible that the low latency session teardown may be unilaterally decided and indicated by either party. At least in some embodiments, once the low latency session ends, the wireless device may no longer be bound by the low latency session parameters.

[0091] Note that a wireless device may be able to be in multiple low-latency sessions simultaneously. For example, it is possible for an AP wireless device to be in low-latency sessions with multiple non-AP wireless devices associated with the AP wireless device, or for a non-AP wireless device to be in low-latency sessions with an AP wireless device associated with it and a peer wireless device. In such scenarios, at least according to some embodiments, it may be the case that if a PPDU is to be sent to all these wireless devices (e.g., during multi-user transmission), when selecting a target PPDU length for non-low-latency traffic, the lowest target PPDU length limit among the active low-latency sessions for the wireless device is used. Similarly, for other low-latency session parameters, it may be the case that the lowest requirements of all low-latency sessions are considered when determining the behavior of the wireless device.

[0092] Thus, according to Figure 4 the method, it is possible to establish low-latency sessions with low-latency session parameters that support pre-empting non-low-latency transmission opportunities in favor of low-latency communication, including various scenarios regarding whether the pre-empted and pre-empting communications are for uplink or downlink traffic directions and / or on an infrastructure or P2P link. At least according to some embodiments, such techniques may provide improved latency for a target traffic type, and / or provide any one of various other possible benefits.

[0093] Figures 5 to 38 and additional information

[0094] Figures 5 to 38 Illustrates other aspects that can be used in combination with Figure 4 the method if desired. However, it should be noted that the exemplary details illustrated and described with respect to these figures are not intended to limit the present disclosure as a whole: Many variations and alternatives of the details provided below are possible and should be considered within the scope of the present disclosure. Figures 5 to 38

[0095] In a Wi-Fi-based communication setup, a client station (STA) may be able to support only 5GHz / 6GHz single-link operation, while its associated access point (AP) supports simultaneous transmission and reception (STR) using both a 5GHz link and a 6GHz link. The low-latency application in this example scenario may have a latency bound as low as ≤2 ms. If the client in this scenario is restricted to using the current link to serve the application, in various cases, techniques that better support the uplink (UL), downlink (DL), and peer-to-peer (P2P) low-latency traffic of the client STA may be beneficial.

[0096] In some cases, the over-the-air (OTA) transmission of a physical layer protocol data unit (PPDU) can be on the order of about 5.4 ms. A long TXOP can be even longer. Then, in order to be able to meet a ≤2 ms latency bound, it may help if such a long PPDU can or is required to be “abruptly interrupted” or “ended early” so that low-latency data can be transmitted. In the discussion here, the method of abruptly interrupting a short PPDU or ending a long PPDU early can also be referred to as “TX shortening” or “TX short,” for example, in the sense that this can facilitate the likelihood of other STAs having an opportunity to access the medium.

[0097] Figures 5 to 6 Illustrative example scenarios in which TX shortening may occur, according to some embodiments, include PPDU burst examples and transmission opportunity (TXOP) duration limit examples. In Figure 5 the example of, the burst period can be interrupted (shortened) to allow transmission of low-latency data before burst resumption. In Figure 6 the example of, a short TXOP can be used for (e.g., non-low-latency) data transmission, which can allow for a TXOP to be obtained for (e.g., higher-priority) low-latency data transmission. After the low-latency TXOP, the medium may be available again for competing STAs.

[0098] In some embodiments, if the transmitter of a low-latency (LL) PPDU is the TXOP holder, a PPDU burst may be sufficient to allow the LL PPDU to be transmitted in a timely manner. In the case where another transmitter is the source of the LL PPDU, it may be useful to limit the TXOP duration, for example such that the other transmitter has a higher probability of accessing the medium, unless TXOP sharing is used. This can be useful for situations such as when a transition from an ongoing infrastructure link to a P2P link for LL data reception (“ongoing infrastructure link to LL P2P link”) is needed, or when a transition from an ongoing P2P link to an infrastructure link for LL data reception (“ongoing P2P link to LL infrastructure link”) is needed. Examples of such scenarios can include an AP sending best effort (BE) traffic to a client STA, and a P2P peer of the client STA having LL data for the client STA.

[0099] In at least some embodiments, it may be useful to provide a framework for when to allow a wireless device to shorten TX. As an example, as part of such a framework, if the current PPDU itself contains low-latency data (e.g., data in the voice (VO) or video (VI) access category), shortening TX may not make sense because the ongoing transmission may also need to meet its corresponding latency bounds. Thus, in some embodiments, it may be the case that for higher-priority VO or VI traffic, only low-priority PPDUs (e.g., PPDUs carrying BE or background (BK) traffic) may be shortened.

[0100] Such a framework can also be extended to whether the PPDUs of other STAs can be shortened to allow an STA to transmit its low-latency PPDUs. In at least some cases, shortening other PPDUs unconditionally has the potential to disrupt the performance of existing applications. Thus, the actions taken by a client STA to improve its low-latency traffic flow may be restricted such that the performance of other STAs is not degraded.

[0101] With such a policy as a framework, it may be the case that a client can only attempt to shorten the low-priority PPDUs it is transmitting or receiving. In such a scenario, four cases may need to be considered.

[0102] The first case may include when the client is transmitting BE / BK data and needs to transmit LL data.

[0103] The second case may include when the client is transmitting BE / BK data and needs to receive LL data.

[0104] The third case may include when the client is receiving BE / BK data and needs to transmit LL data.

[0105] The fourth case may include when the client is receiving BE / BK data and needs to receive LL data. For each such case, there may also be four sub-cases depending on the traffic session involved (e.g., infrastructure or P2P).

[0106] In some cases, when the channel is congested or blocked by other BSS or OBSS STA TXOPs, an STA with low-latency traffic may be able to use a different link (or sub-channel). When an STA with LL traffic participates in transmitting or receiving non-low-latency traffic, it may be necessary to wait for the TXOP to terminate to compete for channel access for LL traffic. Figure 7Exemplary aspects of such scenarios are illustrated in which a STA experiences a channel access delay while waiting for a TXOP to complete. A method for addressing such scenarios may desirably cover the previously mentioned use cases, including: when a STA needs to transmit LL traffic while transmitting non-LL traffic; when a STA needs to transmit LL traffic while receiving non-LL traffic; when a receiver needs to transmit LL traffic to a STA while the STA is transmitting non-LL traffic; and when a receiver needs to transmit LL traffic to a STA while the STA is receiving non-LL traffic. Shortening the TXOP limit to enable LL traffic access may impact medium efficiency. At least according to some embodiments, it may be desirable for the technology addressing such scenarios to be scalable and not degrade traditional performance.

[0107] One possible method for improving the handling of LL traffic in a wireless communication system may include supporting low-latency sessions in Wi-Fi 8. According to some embodiments, in such a method, a link may be shared between legacy devices and Wi-Fi 8 devices. When no low-latency traffic is available in a Wi-Fi 8 device, all STAs in the system may use "regular" channel access. When a Wi-Fi 8 device has low-latency traffic, it may request the establishment of a low-latency session. Figure 8 Exemplary aspects of such low-latency session establishment and tear-down are illustrated according to some embodiments. The LL session initiator STA may transmit an LL setup request frame to the LL session responder STA. The frame may include a request to establish an LL session and the requested parameters for the LL session. The LL session responder STA may transmit an LL session setup response frame in response to the request. The frame may include a response to the request and possibly recommended parameters, such as in the case where the request is rejected.

[0108] A Wi-Fi 8 STA having an active LL session may be able to tear down the LL session by transmitting an LL session tear-down indication to the STA associated with it. In various embodiments, the STA transmitting the tear-down frame may be the LL session initiator STA or the LL session responder STA. During an LL session, it may be the case that a Wi-Fi 8 STA having an active LL session has special channel access rules, such as to enable low-latency traffic. Legacy devices and Wi-Fi 8 STAs without an active LL session may continue to use regular channel access rules.

[0109] Figure 9FIG. 0 is a signal flow diagram illustrating example aspects of possible LL session establishment communication. When low latency data is expected between a STA and its associated STA, the STA may request to establish an LL session. The LL session initiator and the LL session responder may agree to enable preemption. The STA may exchange LL session establishment request and response frames to negotiate preemption parameters. Any non-LL TXOP in an LL session initiated by either STA having an active LL session may be expected to follow the LL session rules. As previously mentioned, traditional devices and Wi-Fi 8 devices without an active LL session may keep their channel access rules unchanged, and it is possible that the LL session does not affect the performance of these devices.

[0110] STAs having an active LL session may exchange LL setup frames to agree on LL session parameters (e.g., PPDU limit, LL TID, whether to enable bursts, etc.). If the STAs have different LL requirements, it may be expected that the LL session parameters of both sides are symmetric, e.g., including PPDU target limits and other parameters in both directions, which may affect the latency of both STAs. An agreement may be reached to meet the minimum requirements of both sides.

[0111] After receiving an LL mode response accepting the LL channel access mode, the UHR STA may switch to the LL mode. Any non-LL TXOP initiated by the STA in the LL session may be able to be preempted after approval by the TXOP initiator. The UHR LL STA enabling the LL mode may limit the PPDU size for its non-LL traffic and may allow feedback of LL traffic indication from the TXOP responder. When preemption is requested from the TXOP responder, the UHR TXOP initiator STA enabling the LL mode may allow sharing of their TXOP with the TXOP responder. When requested by the TXOP responder, the UHR TXOP initiator STA enabling the LL mode may terminate its TXOP with the TXOP responder.

[0112] When sending non-LL traffic, the TXOP initiator may divide a large PPDU into smaller PPDUs, for example, with a target length determined based on the value agreed upon during LL session establishment. For example, as a possibility, a target length of 1 ms may be used. Other target lengths are also possible. At least in some cases, the TXOP initiator may be able to preempt its own TXOP to send low latency to the TXOP responder or any other STA (e.g., via infrastructure or P2P link). Figure 10 Example aspects of such scenarios according to some embodiments are illustrated. Specifically, Figure 10Aspects of an example scenario are illustrated in which a TXOP initiator preempts its own TXOP to send low-latency data to a TXOP responder. The TXOP responder may transmit a response frame after each PPDU with an LL traffic indication. The TXOP responder may request to preempt an ongoing TXOP, and the TXOP initiator may allow the preemption based on such a request. In some implementations, the TXOP initiator and responder may be able to agree to limit a burst to one PPDU to enable channel access for other STAs. Figure 11 Aspects of such an example scenario are illustrated in which TXOP bursts are each limited to one PPDU.

[0113] As previously described, the TXOP initiator may have a target PPDU+BA duration limit that is equal to an agreed-upon value (such as 1 ms) at session establishment when sending non-LL traffic. The TXOP responder may transmit an LL traffic indication to the TXOP initiator in a control response frame to request preemption. Multiple types of preemption requests may be possible. As an example, a request to send LL traffic to the TXOP initiator in the same TXOP (e.g., LL indicator = 1, as one possibility) may be included in the control response frame. As another example, a request to send LL traffic to an STA that is not the TXOP initiator in the same TXOP (e.g., LL indicator = 2, as one possibility) may be included in the control response frame. As yet another example, a request to break out of the current TXOP (e.g., LL indicator = 3, as one possibility) may be included in the control response frame. An LL indicator value (e.g., LL indicator = 4, as one possibility) may be used to indicate that no request is available. As yet another example, a request for a certain time in the current TXOP (e.g., LL indicator = 5, as one possibility) may be included in the control response frame, and the duration of the possible request may also be indicated in that response frame.

[0114] The TXOP initiator may respond to the TXOP responder request in any of a variety of ways. As one possibility, the TXOP may be shared with the TXOP responder. As another possibility, the TXOP initiator may continue to burst to the TXOP responder. As another possibility, the TXOP initiator may stop traffic to the STA in the current TXOP. As yet another possibility, the TXOP initiator may terminate the TXOP. At least according to some implementations, it may be agreed that the TXOP initiator should accept reverse traffic from the TXOP responder in an active LL session. Once the TXOP responder has finished using the TXOP, the TXOP responder may transmit a control frame to return the TXOP to the TXOP initiator. The TXOP initiator may also be able to use the LL indication for future scheduling decisions.

[0115] It is possible that any non-LL TXOP in an LL session initiated by any STA in an STA having an active LL session is preemptable. An LL TXOP can be a TXOP in which the primary AC is the AC associated with a TID defined as an LL TID. The LL TID can be defined at the time of LL session establishment, such as during the exchange of LL session establishment requests and responses. According to various embodiments, other mechanisms can also or alternatively be used to define what is LL and non-LL traffic during an LL session.

[0116] Figure 12 Illustrative aspects of an example scenario in which a TXOP is shared by a TXOP initiator and a TXOP responder to allow the TXOP responder to send LL data to the TXOP initiator in response to a request to do so from the TXOP responder. The control frame (CTF) for sharing the TXOP with the TXOP responder can be any of a variety of possible frames. If the STA is capable of transmitting a MU-RTS TXS frame, one possibility can include the MU-RTS TXS. Another possibility can include a CTS frame transmitted to the TXOP responder. A newly defined frame transmitted to the TXOP responder can also be used. The CTF can include an indication of the duration to be shared with the TXOP responder, such as indicating that the duration to be shared is until the end of the TXOP, until the LL session PPDU target limit, or until a duration requested by the TXOP responder, and various possibilities. Once the TXOP responder finishes using the TXOP, the TXOP responder can return the remainder of the TXOP to the TXOP initiator, for example, by transmitting a CTF to the TXOP initiator.

[0117] Figures 13 to 16 Illustrates an example of the use of LL session characteristics during an uplink communication scenario according to various embodiments. In Figure 13 the example scenario, a UHR LL STA is sending non-LL traffic to an AP. The AP can request to transmit DL LL traffic to the TXOP initiator. The UHR STA can transmit a control frame to enable reverse traffic. The AP can transmit LL DL traffic to the UHR STA. Then, the AP can transmit a control frame to give the remainder of the TXOP to the TXOP initiator (e.g., optionally). In Figure 14 the example scenario, a UHR LL STA 1 is sending non-LL traffic to an AP. The AP can request to transmit DL Ll traffic to a different STA (“UHR STA 2”). The UHR STA 1 can transmit a control frame to enable reverse traffic (alternatively, the UHR STA can terminate the TXOP). The AP can transmit LL DL traffic to the UHR STA 2. Then, the AP can transmit a control frame to give the remainder of the TXOP to the TXOP initiator (e.g., optionally). InFigure 15 In an example scenario, UHR LL STA 1 is sending non-LL traffic to the AP. The AP may request a burst of LL traffic to a different STA (“UHR STA 2”). UHR STA 1 may transmit a control frame to enable reverse traffic (alternatively, UHR STA may terminate the TXOP). The AP may transmit a trigger frame (TF) to solicit LL UL traffic from UHR STA 2. Then, the AP may transmit a control frame to hand over the remainder of the TXOP to the TXOP initiator after a burst of UL traffic (e.g., optionally). In Figure 16 an example scenario, UHR LL STA 1 is sending non-LL traffic to the AP. The AP may request a burst of LL traffic to a different STA (“UHR STA 2”). UHR STA 1 may terminate the TXOP. The AP may contend for medium control to transmit a TF to solicit LL UL traffic (or transmit DL traffic) from UHR STA 2. Thus, at least according to some embodiments, it is possible to interrupt UL non-LL transmission with LL DL traffic, enable the AP to trigger UL traffic for other STAs during a non-LL TXOP when the AP knows the LL traffic characteristics, and / or enable scheduling of LL DL traffic after UL Ll transmission.

[0118] Figures 17 to 20 illustrates examples of the use of LL session characteristics during a downlink communication scenario according to various embodiments. In Figure 17 an example scenario, the AP transmits single-user (SU) DL non-LL data and receives a BA with an LL request from one of the STAs. The AP may transmit a CTF for the requested STA and may terminate the TXOP or continue the burst based on feedback. The AP may also be able to transmit LL DL traffic to another STA during the TXOP. In Figures 18 to 19 an example scenario, the AP transmits multi-user (MU) DL non-LL data and receives a BA with an LL request from the STA. The AP may schedule a TF for the requested STA, terminate the TXOP, or continue the burst based on feedback. The AP may trigger the STA to request LL UL transmission for a predefined data burst, where the time of the TBPPDU may be one PPDU with a target burst size, or equal to the duration left for the TXOP, and various possibilities. If the AP knows the UL traffic characteristics, the AP may adjust the resource allocation for the known traffic. As Figure 19 shown, in some cases, the AP may transmit a buffer status report poll (BSRP) to obtain the status of the buffer at the requested STA, and based on that status, the AP may trigger an uplink transmission with the correspondingly selected resources. In Figure 20In an example scenario, the AP transmits multi-user (MU) DL non-LL data and receives a BA with an LL request from the STA. The AP may provide CTF transmissions to the requesting STAs in sequence based on the feedback (or may terminate the TXOP or continue the burst). Each CTF may solicit a PPDU transmission with a target PPDU length (e.g., as agreed upon). Thus, at least according to some embodiments, it is possible to enable LL UL traffic to interrupt non-LL DL transmissions, and / or enable LL DL traffic to interrupt non-LL Dl transmissions to other STAs.

[0119] In some embodiments, it may be agreed that when one or more of the multiple STAs have an active LL session, the AP that schedules MU-DL or MU-UL PPDUs with the multiple STAs should adjust the PPDU duration limit to the minimum of the required PPDU duration limits of all STAs with active LL sessions involved in the transmission. The AP may enable preemption by any of the STAs receiving MU-DL with an active LL session. For example, if needed, the AP may have the opportunity to transmit DL Ll traffic after scheduling MU-UL with a PPDU limit. If the STA receives a TF for any access category from the AP, the STA may be able to transmit LL data. It is possible that when a STA with an active LL session is not scheduled in the MU-DL frame, the AP does not follow the PPDU limit for the MU-DL PPDU.

[0120] It is possible that the TXOP initiator may choose to reject a preemption request from the TXOP responder. Figures 21 to 23 Examples illustrate example aspects of various such possible scenarios according to some embodiments. In Figure 21 an example scenario, the TXOP responder may request to use the TXOP to communicate with another STA. The TXOP responder may be, for example, an AP and need to send LL traffic to a STA different from the TXOP initiator, or the TXOP responder may be a non-AP STA and need to send LL traffic to a peer STA that is not the TXOP initiator (AP). As another possibility, as Figure 22 illustrated in an example scenario, the TXOP responder may request to terminate the TXOP, and the TXOP initiator may decide to continue the transmission. As another possibility, the TXOP initiator may be able to choose to reject the request but consider it for future scheduling. The TXOP responder may also be able to transmit feedback to the TXOP initiator at the end of the TXOP, for example, to notify the initiator of the responder's pending LL traffic, as Figure 23 illustrated in an example scenario. The AP that receives a TXOP preemption request from the STA at the end of the TXOP may use this information to transmit a TF in another TXOP.

[0121] Figures 24 to 25 Illustrates example aspects of possible scenarios in which a STA requests TXOP detachment according to some embodiments. In such scenarios, the TXOP responder may need to switch the channel for infrastructure traffic or P2P traffic on another link, or may need to start a new TXOP to another STA other than the TXOP initiator. The TXOP responder may request in a feedback frame to stop sending to it and end the data burst during this TXOP. As Figure 24 shown in the scenario of, the TXOP initiator may accept such a request and terminate the TXOP. The TXOP responder may have the opportunity to compete for and obtain channel access for data transmission, or switch to another channel. As Figure 25 shown in the scenario of, it is also possible for the TXOP initiator to continue using the TXOP (e.g., with one or more other users) and not transmit or allocate resources to the TXOP responder that requests to stop the traffic.

[0122] Figures 26 to 28 Illustrates example aspects of possible scenarios in which TXOP preemption for P2P communication is used according to some embodiments. In Figure 26 the example scenario of, UL traffic may be preempted for P2P data. As shown in the figure, a STA may have a non-LL TXOP to an AP with an LL session. The STA may preempt its own non-LL TXOP to transmit P2P data to a peer STA in the same TXOP. The STA may resume UL traffic after ending the P2P traffic (e.g., if there is still time remaining in the TXOP). In Figure 27 the example scenario of, DL traffic may be preempted for P2P data. As shown in the figure, an AP may have a non-LL TXOP to a STA with an LL session. The STA may provide a request to the AP to preempt the TXOP to transmit data to another STA. If the AP accepts the request, the AP may transmit a CTF (e.g., MU-RTS TXS or any frame in various other possible frames) to grant the TXOP to the requesting STA. The requesting STA may use the TXOP for P2P data. Once the requesting STA ends the P2P data exchange, the STA may return the TXOP to the AP again by transmitting a control frame to the AP (e.g., if there is still time remaining in the TXOP). In some embodiments, the TXOP initiator and responder may agree to limit the burst to one PPDU to enable channel access for other STAs. This may limit the TXOP length of the STA requesting the LL session, such as in Figure 28 the illustrated scenario of, for example, such that other (e.g., P2P) devices are not prevented from transmitting to these STAs.

[0123] In some embodiments, a STA (e.g., an AP or a non-AP STA) may enable preemption at the start of a TXOP. In such cases, the ICF may be used at the start of the TXOP to solicit a BA with a preemption indication. Figure 29 Aspects of one possible example scenario in which this method may be used are illustrated. As shown, a STA may transmit a BAR at the start of a TXOP to solicit a BA with an LL indication, and the STA may decide to continue the TXOP or share the TXOP with the TXOP responder. As another possibility, an AP / STA may transmit a MU-RTS or any other ICF indicating that it expects to receive a BA with an LL indication as a response, and the AP may decide to continue the TXOP or share the TXOP with the TXOP responder. The STA may also potentially transmit a QoS null frame to solicit a BA with an LL indication. Another possibility may include using a buffer status report poll (BSRP) as an ICF to request a preemption indication. In some cases, when a hidden node blocks DL traffic from the STA side, the STA may reuse the same mechanism to solicit DL traffic; the STA may contend for channel access and transmit a BAR to the AP (at least in some cases, optionally starting with an RTS / CTS), the AP may indicate in the BA whether LL data is available, and the STA may share the TXOP with the AP (if it determines to do so). After any such TXOP sharing, the TXOP initiator may continue to send the target PPDU and receive the corresponding BA.

[0124] At least in some cases, it may be useful to define the behavior of scenarios in which BA feedback is not received. Figures 30 to 31 Example aspects of such possible scenarios according to some embodiments are illustrated. In Figure 30 the example scenario, if the TXOP initiator does not receive a BA (e.g., the TXOP responder does not send), the TXOP initiator may perform a point coordination function space (PIFS) recovery and transmit a BA request (BAR) to solicit a BA from the TXOP responder, and the burst duration may be extended to the target PPDU + BAR + BA. Alternatively, the TXOP initiator may terminate the TXOP. In Figure 31 the illustrated scenario, the BA may not be received by the TXOP initiator due to interference or a collision. In such a case, it may be the case that the TXOP cannot perform a PIFS recovery (e.g., because the medium may be busy). Thus, the TXOP responder may not receive a control frame indicating to send LL data and may contend for access to the channel.

[0125] The TXOP responder may provide LL feedback to the TXOP initiator in a response control frame such as a BA frame. The TXOP responder may require two or more bits to add various request options. In at least some embodiments, the TXOP responder may additionally add the duration of the required TXOP, which may, for example, use one octet, at least as a possibility. Figure 32 An example aspect of a possible update to the BA frame format to support such feedback in accordance with some embodiments is illustrated. Reserved bits in the BA control field may be used, for example, to provide 2-bit LL feedback. As another possibility, one of the predefined BA frame variants (e.g., multi-STA BA, as a possibility) may be reused. As a further possibility, a new type of BA may be defined, e.g., having a specified number of bits for LL feedback and duration requests in addition to BA information. The TXOP responder may also use a new response control frame, which may contain LL feedback information. As another possibility, the TXOP responder may aggregate LL feedback (e.g., in a QoS null frame or HT control, as some possibilities) information into the BA in an aggregated media access control protocol data unit (AMPDU).

[0126] Figure 33 Example aspects of a possible multi-STA BA frame that can be used to carry additional control information, such as in addition to BA bitmap information, to acknowledge A-MPDUs and / or MPDUs are illustrated. For example, such indication information may be transmitted in an M-STA BA frame to provide a low latency preemption indication. As shown, the BA frame may be reused with a BA type (11) indicated as multi-STA BA. A new per-AID information field may be used to add the indication information. The AID11 field may use a special value to indicate that it carries a preemption indication and / or otherwise carries non-BA bitmap information. The AID11 field may use the peer STA AID. A combination of ACK type and TID may be selected to indicate that it carries a preemption indication. Some or all of the remaining fields in the per-AID TID information field may be used to carry preemption indication information. As another example, Figure 34 Example aspects of such per-AID TID information fields that can be used to carry preemption indication information are illustrated. In the example illustrated, the LL indication may carry different feedback transmitted from the TXOP responder to the TXOP initiator. The duration may carry the duration of the preemption request. The remainder of the subfield may be reserved for future use.

[0127] Figures 35 to 38Illustrates example aspects of a possible LL session setup and teardown frame element format according to some embodiments. According to the illustrated frame format, a new low latency session setup action frame can be used to carry low latency session setup elements. The low latency session setup element field can include an element ID and a length field, which can be defined according to the IEEE 802.11 baseline. The LL setup request field, if set to 1, can indicate that the element is for an LL setup request transmitted by the LL setup initiator, and if set to 0, can indicate that the element is for an LL setup response transmitted by the LL setup responder. If PPDU bursting is enabled during the TXOP, the burst disable can be set to 0, otherwise only one PPDU with the target length can be allowed (e.g., PPDU bursting can be disabled). If one MPDU transmission is enabled when a single MPDU exceeds the agreed target PPDU size, the single MPDU transmission can be set to 1. In some embodiments, this can also be set by default without negotiation. If the LL session is to be terminated, the teardown can be set to 1 by the LL setup initiator or responder. In some embodiments, when this field is set to 1, all other fields can be retained. Otherwise, this field can be set to 0. The LL request status code can contain the result of the LL setup request and can include one of the status codes specified in the IEEE 802.11 baseline. When the element is included in the LL setup request, this field can be retained. When the status code is REJECTED_WITH_SUGGESTED_CHANGES, the LL setup responder can fill other element fields with suggested values to accept future requests. The target PPDU limit field can be specified as an unsigned integer in units of the maximum size request of 32 μs. When non-LL traffic is sent between two STAs, this field can indicate the target of the PPDU limit. The LL DL TID bitmap and LL UL TID bitmap subfields can specify the TIDs identified by the STA requesting the LL session as latency-sensitive traffic flows in the downlink and uplink directions. A value of 1 at bit position k in either bitmap can indicate that TID k is classified as a latency-sensitive traffic flow for the direction corresponding to the bitmap. A value of 0 at bit position k in either bitmap can indicate that TID k is not classified as a latency-sensitive traffic flow for the direction corresponding to the bitmap.

[0128] It is well known that the use of personally identifiable information should follow privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and disposed of to minimize the risk of inadvertent or unauthorized access or use, and the nature of the authorized use should be clearly explained to the user.

[0129] In addition to the above exemplary embodiments, further embodiments of the present disclosure may be implemented in any of a variety of forms. For example, some embodiments may be implemented as computer-implemented methods, computer-readable memory media, or computer systems. Other embodiments may be implemented using one or more custom-designed hardware devices such as ASICs. Other embodiments may be implemented using one or more programmable hardware elements such as FPGAs.

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

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

[0132] Although the above embodiments have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. It is intended that the following claims be interpreted to cover all such variations and modifications.

Claims

1. A method, the method comprising: Performing, by a first wireless device and a second wireless device, a low latency session setup that establishes one or more low latency session parameters for a low latency session between the first wireless device and the second wireless device.

2. The method according to claim 1, wherein the method further comprises, by the first wireless device: Preempting an ongoing transmission of lower priority traffic to start a transmission or reception of low latency traffic, at least in part based on the low latency session between the first wireless device and the second wireless device, wherein the first wireless device is a transmitter or a receiver of the ongoing transmission.

3. The method according to claim 1, wherein the low latency session setup further comprises: A low latency session setup request and response exchange that includes an acceptance indication associated with the low latency session setup request.

4. The method according to claim 1, wherein the low latency session setup further comprises: A low latency session setup request and response exchange that includes a rejection of the low latency session setup request, the low latency session setup request indicating proposed low latency session parameters different from one or more low latency session parameters indicated in the low latency session setup request.

5. The method according to claim 1, wherein the one or more latency session parameters established for the low latency session include one or more of the following: One or more traffic identifiers (TIDs) associated with a latency sensitive uplink traffic flow or a latency sensitive downlink traffic flow for the low latency session; A target physical layer protocol data unit (PPDU) length limit for non-low latency traffic during the low latency session; or An indicator of whether to enable a PPDU burst of non-low latency traffic during a transmit opportunity (TXOP) during the low latency session.

6. The method according to claim 1, wherein the method further comprises: Performing, by the first wireless device during a transmit opportunity (TXOP), an initial control frame and control response frame exchange and / or a non-low latency data frame and control response frame exchange with the second wireless device, wherein the control response frame includes a low latency traffic indication.

7. The method according to claim 6, wherein the low latency traffic indication: Sends a request for low latency traffic to the wireless device that is the TXOP initiator in the TXOP; Sends a request for low latency traffic to the wireless device that is not the TXOP initiator in the TXOP; A request to detach from the TXOP; A request for the amount of time of the TXOP; or No low latency request.

8. The method according to claim 6, The control response frame including the low latency service indication includes a multi-station (M-STA) block acknowledgment (BA) frame, wherein each association identifier (AID) traffic identifier (TID) information field of the M-STA BA frame includes low latency service indication information.

9. The method according to claim 1, wherein the method further comprises, after establishing the low latency session: Performing low latency session tear-down for the low latency session between the first wireless device and the second wireless device.

10. A first wireless device, the first wireless device comprising: One or more antennas; Radio components, the radio components being operably coupled to the one or more antennas; And A processor, the processor being operably coupled to the radio components; Wherein the first wireless device is configured to: Send a first low latency session request to a second wireless device, the first low latency session request including an indication of one or more low latency session parameters for a low latency session; and Receive a first low latency session response for the low latency session from the second wireless device.

11. The first wireless device according to claim 10, wherein the one or more low latency session parameters include one or more of the following: One or more traffic identifiers (TIDs), the one or more TIDs being associated with a latency-sensitive uplink traffic flow or a latency-sensitive downlink traffic flow for the low latency session; A target physical layer protocol data unit (PPDU) length limit for non-low latency services during the low latency session; or An indicator of whether to enable a physical layer protocol data unit (PPDU) burst of non-low latency services during a transmit opportunity (TXOP) during the low latency session.

12. The first wireless device according to claim 10, Wherein the first low latency session setup response includes an indication that the first low latency session setup request is rejected and a suggested change, Wherein the first low latency session setup response includes an indication of suggested low latency session parameters different from one or more low latency session parameters indicated in the first low latency session setup request.

13. The first wireless device according to claim 12, wherein the first wireless device is further configured to: Select one or more low latency session parameters for a second low latency session setup request at least partially based on the suggested low latency session parameters indicated in the first low latency session setup response, wherein at least one low latency session parameter is different between the first low latency session setup request and the second low latency session setup request; Send the second low latency session setup request to the second wireless device; and Receive a second low latency session setup response for the low latency session from the second wireless device.

14. The first wireless device according to claim 10, wherein the first wireless device is further configured to: Initiate a transmit opportunity (TXOP) with the second wireless device; Transmit a non-low latency data frame during the TXOP; Receive a control response frame during the TXOP, the control response frame including a low latency traffic indication; Determine to share the TXOP based at least in part on the low latency traffic indication; And Transmit a control frame indicating the duration of the TXOP shared with the second wireless device.

15. An apparatus comprising a processing circuit and a memory, the memory being configured to cause the processing circuit to: Receive low latency session request signaling, the low latency session request signaling including an indication of one or more low latency session parameters for a low latency session between a first wireless device and a second wireless device; and Generate low latency session response signaling associated with the low latency session.

16. The apparatus according to claim 15, wherein the one or more low latency session parameters include one or more of the following: One or more traffic identifiers (TIDs), the one or more TIDs being associated with a latency-sensitive uplink traffic flow or a latency-sensitive downlink traffic flow for the low latency session; A target physical layer protocol data unit (PPDU) length limit for non-low latency traffic during the low latency session; or An indicator of whether to enable PPDU bursts of non-low latency traffic during a transmit opportunity (TXOP) during the low latency session.

17. The apparatus according to claim 15, wherein the memory is further configured to cause the processing circuit to: Receive a non-low latency data frame during a transmit opportunity (TXOP) during the low latency session; and Generate control response frame signaling including a low latency traffic indication.

18. The apparatus according to claim 17, wherein the low latency traffic indication indicates: A request to send low latency traffic to the TXOP initiator in the TXOP; A request to send low latency traffic to a wireless device that is not the TXOP initiator in the TXOP; A request to detach from the TXOP; A request for the amount of time of the TXOP; or No low latency request.

19. The apparatus according to claim 17, wherein the memory is further configured to cause the processing circuit to: Receive a control frame indicating TXOP sharing; and Generate low latency data frames configured for communication during the duration of the shared TXOP.

20. The apparatus according to claim 19, wherein the memory is further configured to cause the processing circuit to: Generate control frame signaling including an indication to return to the TXOP after the duration of the shared TXOP.

Images