Quality of service procedure for wireless local area networks

Abstract

Methods and apparatus for facilitating quality of service (QoS) enhancements to support low latency operation in a wireless local area network (WLAN). A station (STA) includes a processor and a transceiver operably coupled to the processor. The transceiver is configured to obtain a transmission opportunity (TXOP). The processor is configured to determine that at least a portion of the TXOP will not be used by the STA, and hand over the unused portion of the TXOP to an access point (AP).

Description

Technical Field

[0001] This disclosure generally relates to low-latency operation in wireless communication systems. Embodiments of this disclosure relate to methods and apparatus for enhancing quality of service to support low-latency operation in wireless local area network communication systems. Background Technology

[0002] Wireless Local Area Network (WLAN) technology allows devices to access the Internet in the 2.4 GHz, 5 GHz, 6 GHz, or 60 GHz frequency bands. WLAN is based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. The IEEE 802.11 standard family is designed to improve speed and reliability and extend the operational range of wireless networks.

[0003] Next-generation Ultra High Throughput (EHT) Wi-Fi systems (e.g., IEEE 802.11 be) support multiple operating bands known as links, through which access points (APs) and non-AP devices can communicate with each other. Therefore, both APs and non-APs can communicate on different bands / links, a phenomenon known as multi-link operation (MLO). Wi-Fi devices that support MLO are called multi-link devices (MLDs). Using MLO, a non-AP MLD can discover, authenticate, associate with, and establish multiple links with an AP MLD. Channel access and frame switching can occur on each link established between an AP MLD and a non-AP MLD. The component of the MLD responsible for transmitting and receiving on a single link is called a station (STA). By aggregating bandwidth across multiple channels / bands, MLO offers significant gains in throughput and latency performance compared to single-link operation in the previous generation (802.11 ax).

[0004] The Ultra High Reliability Study Group (UHRSG), the research group responsible for the design of the next-generation Wi-Fi standard (IEEE 802.11 bn), has set several goals for the design of next-generation Wi-Fi networks. The group aims to achieve ultra-high reliability by reducing latency to extremely low levels, increasing throughput at different signal-to-noise ratio (SNR) levels, and enhancing power savings. Summary of the Invention

[0005] Technical issues

[0006] Embodiments of this disclosure provide methods and apparatus for enhancing Quality of Service (QoS) to support low-latency operation in WLANs.

[0007] In one embodiment, the wireless STA device includes a transceiver and a processor operatively coupled to the transceiver. The transceiver is configured to acquire a transmission opportunity (TXOP). The processor is configured to determine that at least a portion of the TXOP will not be used by the STA, and to hand over the unused portion of the TXOP to the AP.

[0008] In one embodiment, the method performed by the wireless STA device includes the following steps: obtaining a TXOP, determining that at least a portion of the TXOP will not be used by the STA, and transferring the unused portion of the TXOP to the AP.

[0009] Other technical features will be obvious to those skilled in the art based on the following figures, description and claims.

[0010] Before proceeding with the detailed description below, it may be advantageous to define certain words and phrases used throughout this patent document. The term “coupled” and its derivatives refer to any direct or indirect communication between two or more elements, whether or not these elements are physically in contact with each other. The terms “transmit,” “receive,” and “communicate,” and their derivatives, cover both direct and indirect communication. The terms “comprising” and “including,” and their derivatives, mean including but not limited to. The term “or” is inclusive, meaning and / or. The phrase “associated with,” and its derivatives, mean including, being included in, interconnected with, containing, being contained within, connected to or connected to, coupled to or coupled with, able to communicate with, cooperate with, interleaved, juxtaposed, proximate, bound to or bound to, having, possessing the properties of, having a relationship to or with, etc. The term “controller” means any device, system, or part thereof that controls at least one operation. Such a controller may be implemented in hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller may be centralized or distributed, either local or remote. The phrase “at least one of…” when used with a list of items means that different combinations of one or more of the listed items may be used, and it may be necessary to use only one item from the list. For example, “at least one of A, B, and C” includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C. As used herein, terms such as “first” and “second” or “first” and “second” can be used simply to distinguish corresponding components from one other component and do not limit the components in other respects (e.g., importance or order). It should be understood that if an element (e.g., a first element) is referred to as “coupled,” “coupled to,” “connected to,” or “connected to” another element (e.g., a second element) with or without the terms “operably” or “communically”, it means that the element can be coupled to the other element directly (e.g., wired), wirelessly, or via a third element.

[0011] As used herein, the term "module" can include a unit implemented in hardware, software, or firmware, and is used interchangeably with other terms such as "logic," "logic block," "component," or "circuit." A module can be a single integrated component or its smallest unit or portion adapted to perform one or more functions. For example, according to an embodiment, a module can be implemented as an application-specific integrated circuit (ASIC).

[0012] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each computer program being formed by computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof suitable for implementation in suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, compact disc (CD), digital video disc (DVD), or any other type of storage. "Non-transitory" computer-readable medium excludes wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable medium includes media in which data can be permanently stored and media in which data can be stored and later rewritten, such as rewritable optical discs or erasable memory devices.

[0013] The following references are incorporated into this paper in their entirety through citation:

[0014] [1]IEEE P802.11be / D2.0, 2022.

[0015] [2]IEEE Std 802.11-2020.

[0016] [3]IEEE 802.11 Real Time Applications TIG Report,IEEE 802.11-18 / 2009r6.

[0017] Definitions of certain other words and phrases are provided throughout this patent document. Those skilled in the art will understand that, in many cases (if not most), such definitions apply to the prior and future use of the words and phrases defined in this way. Attached Figure Description

[0018] To gain a more complete understanding of this disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, wherein like reference numerals denote like parts:

[0019] Figure 1 An example wireless network according to an embodiment of the present disclosure is shown;

[0020] Figure 2a An example AP according to an embodiment of this disclosure is shown;

[0021] Figure 2bAn example STA is shown according to an embodiment of the present disclosure;

[0022] Figure 3 An example process for an AC transmission queue according to an embodiment of the present disclosure is shown;

[0023] Figure 4 An example set of EDCA parameters according to an embodiment of this disclosure is shown;

[0024] Figure 5 An example process for TXOP handover performed by a STA according to an embodiment of this disclosure is shown;

[0025] Figure 6 An example process for processing a TXOP handed over by a STA, performed by an AP according to an embodiment of this disclosure, is shown;

[0026] Figure 7 An example process is shown, performed by the AP according to an embodiment of the present disclosure, to explicitly notify the AP that the STA needs to hand over the TXOP;

[0027] Figure 8 An example process, performed by a STA according to an embodiment of the present disclosure, for responding to an explicit TXOP handover request / notification from an AP using a handover frame;

[0028] Figure 9 An example process, performed by a STA according to an embodiment of this disclosure, for handing over a TXOP in response to an explicit TXOP handover request / notification from an AP without sending a notification to the AP;

[0029] Figure 10 An example process for establishing an explicit agreement for participating in the TXOP handover, performed by an AP according to an embodiment of this disclosure, is shown;

[0030] Figure 11 An example process, performed by a STA in response to a request from an AP to participate in a TXOP handover, is shown according to an embodiment of this disclosure.

[0031] Figure 12 An example process for participating in TXOP handover solely for its own DL LL services, performed by a STA according to an embodiment of this disclosure, is shown.

[0032] Figure 13 An example process is shown, performed by an AP according to an embodiment of this disclosure, to announce its ability to participate in the TXOP handover;

[0033] Figure 14 An example process is shown, performed by the STA according to an embodiment of this disclosure, to notify its ability to participate in the TXOP handover;

[0034] Figure 15 An example timing diagram is shown illustrating the delay encountered by downlink packets from AP to STA according to an embodiment of this disclosure;

[0035] Figure 16 An example timing diagram is shown illustrating the delay encountered by uplink packets from STA to AP according to an embodiment of this disclosure;

[0036] Figure 17 An example process for requesting an uplink latency report from a STA, performed by an AP according to an embodiment of this disclosure, is shown.

[0037] Figure 18 An example process for reporting uplink latency to an AP, performed by a STA according to an embodiment of this disclosure, is shown;

[0038] Figure 19 An example process for authorizing a STA to perform uplink latency reporting, performed by an AP according to an embodiment of this disclosure, is shown;

[0039] Figure 20 An example process is shown, performed by an AP according to an embodiment of the present disclosure, for taking action to reduce STA-side latency in response to an uplink latency report provided by a STA;

[0040] Figure 21 An example process for cross-link request / authorization performed by an AP MLD for uplink latency reporting performed by a non-AP MLD, according to an embodiment of this disclosure, is shown.

[0041] Figure 22 An example process for reporting cross-link uplink delay to an AP MLD, performed by a non-AP MLD according to an embodiment of the present disclosure, is shown.

[0042] Figure 23 An example process is shown, performed by an AP according to an embodiment of the present disclosure, for announcing its ability to support uplink latency reporting on the STA side;

[0043] Figure 24 An example process is shown, performed by a STA according to an embodiment of the present disclosure, for announcing its ability to support STA-side uplink latency reporting;

[0044] Figure 25 An example frame format of a variant of the control subfield of the A-control subfield according to an embodiment of the present disclosure is shown;

[0045] Figure 26 Example operations using the above-described A-control subfield according to embodiments of this disclosure are shown;

[0046] Figure 27 An example frame format of a control frame according to an embodiment of the present disclosure is shown;

[0047] Figure 28 An example format of per-stream report according to an embodiment of this disclosure is shown;

[0048] Figure 29 Example operations using the above-described control frame according to embodiments of this disclosure are shown;

[0049] Figure 30 An example element format of a new element according to an embodiment of this disclosure is shown;

[0050] Figure 31 An example format of per-stream report according to an embodiment of this disclosure is shown;

[0051] Figure 32 Example operations using the novel elements described above according to embodiments of this disclosure are shown;

[0052] Figure 33 An example format of a new block ACK frame carrying a service report according to an embodiment of this disclosure is shown;

[0053] Figure 34 Example operations using the new block ACK described above according to embodiments of this disclosure are shown;

[0054] Figure 35 An example frame format of a variant of the control subfield of the A-control subfield according to an embodiment of the present disclosure is shown;

[0055] Figure 36 Example operations using the above-described A-control subfield according to embodiments of this disclosure are shown;

[0056] Figure 37 An example frame format for a control frame for a service information request according to an embodiment of the present disclosure is shown;

[0057] Figure 38 An example format for a business information request according to an embodiment of this disclosure is shown;

[0058] Figure 39 An example operation of requesting a service report using the control frame described above, according to an embodiment of this disclosure, is shown;

[0059] Figure 40 An example format for a new element for a business information request according to an embodiment of this disclosure is shown;

[0060] Figure 41An example format of a modified block ACK carrying a service information request according to an embodiment of this disclosure is shown;

[0061] Figure 42 An example format of a stream-to-link mapping element according to an embodiment of this disclosure is shown;

[0062] Figure 43 An example format of the flow-to-link mapping control field according to an embodiment of this disclosure is shown;

[0063] Figure 44 An example format of the flow-to-link mapping field according to an embodiment of this disclosure is shown;

[0064] Figure 45 Example operations including a stream-to-link mapping request frame according to embodiments of the present disclosure are shown;

[0065] Figure 46 Example operations including a stream-to-link mapping request and response frame are shown according to embodiments of this disclosure;

[0066] Figure 47 Example operations of stream-to-link mapping teardown according to embodiments of this disclosure are shown; and

[0067] Figure 48 An example process for facilitating QoS enhancement to support low-latency operation, according to one embodiment of the present disclosure, is shown. Detailed Implementation

[0068] The following discussion Figures 1 to 48 The various embodiments used to describe the principles of this disclosure in this patent document are merely illustrative and should not be construed in any way as limiting the scope of this disclosure. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

[0069] Embodiments of this disclosure recognize that QoS enhancement is one of the key goals of next-generation Wi-Fi systems in order to support new use cases with extremely low latency applications. Such applications may have last-hop latency requirements on the order of milliseconds, and for some of these applications, near-lossless performance is also expected.

[0070] Accordingly, embodiments of this disclosure provide processes and apparatus for facilitating QoS enhancements to support such low-latency (e.g., ultra-low-latency) operation. Embodiments of this disclosure include TXOP handover processes, latency reporting processes, traffic flow information reporting processes, and traffic processing processes based on flow IDs.

[0071] Figure 1 An example wireless network 100 according to one embodiment of the present disclosure is shown. Figure 1The illustrated embodiment of the wireless network 100 is for illustrative purposes only. Other embodiments of the wireless network 100 may be used without departing from the scope of this disclosure.

[0072] Wireless network 100 includes access points 101 and 103. Access points 101 and 103 communicate with at least one network 130, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network. Access point 101 provides wireless access to network 130 to multiple STAs 111-114 within its coverage area 120. Access points 101-103 can communicate with each other and with STAs 111-114 using Wi-Fi or other WLAN communication technologies.

[0073] Depending on the network type, other well-known terms may be used instead of "access point" or "AP," such as "router" or "gateway." For convenience, the term "AP" is used in this disclosure to refer to a network infrastructure component that provides wireless access to remote terminals. In a WLAN, assuming that the AP also competes for the wireless channel, the AP may also be referred to as a STA (e.g., AP STA). Furthermore, depending on the network type, other well-known terms may be used instead of "station" or "STA," such as "mobile station," "subscriber station," "remote terminal," "user equipment," "wireless terminal," or "user equipment." For convenience, the terms "station" and "STA" are used in this disclosure to refer to a wireless access AP or a remote wireless device competing for the wireless channel in a WLAN, whether the STA is a mobile device (such as a mobile phone or smartphone) or is generally considered a fixed device (such as a desktop computer, AP, media player, fixed sensor, television, etc.). This type of STA may also be referred to as a non-AP STA.

[0074] In one embodiment of this disclosure, each of APs 101 and 103 and each of STAs 111-114 may be an MLD. In such an embodiment, APs 101 and 103 may be AP MLDs, and STAs 111-114 may be non-AP MLDs. Each MLD is attached to more than one STA. For ease of explanation, AP MLDs are described herein as being attached to more than one AP (e.g., more than one AP STA), and non-AP MLDs are described herein as being attached to more than one STA (e.g., more than one non-AP STA).

[0075] The dashed lines indicate the approximate extent of coverage areas 120 and 125, which are shown as approximately circular for illustrative and explanatory purposes only. It should be clearly understood that coverage areas associated with an AP, such as coverage areas 120 and 125, can have other shapes, including irregular shapes, depending on the AP's configuration and variations in the radio environment associated with natural and man-made obstacles.

[0076] although Figure 1 An example of a wireless network 100 is shown, but more details can be found on other wireless networks. Figure 1 Various modifications can be made. For example, wireless network 100 can include any number of APs and any number of STAs in any suitable arrangement. Furthermore, AP 101 can communicate directly with any number of STAs and provide those STAs with wireless broadband access to network 130. Similarly, each AP 101-103 can communicate directly with network 130 and provide STAs with direct wireless broadband access to network 130. Additionally, AP 101 and / or 103 can provide access to other or additional external networks, such as external telephone networks or other types of data networks.

[0077] Figure 2a An example AP 101 according to an embodiment of the present disclosure is shown. Figure 2a The embodiment of AP 101 shown is for illustrative purposes only, and Figure 1 AP 103 can have the same or similar configuration. In the embodiments discussed below, AP 101 is an AP MLD. However, APs have a wide variety of configurations, and Figure 2a This disclosure is not intended to limit the scope of any particular implementation of AP.

[0078] AP MLD 101 is associated with multiple APs 202a-202n (which may be referred to as, for example, AP1-APn). Each of the associated APs 202a-202n includes multiple antennas 204a-204n, multiple RF transceivers 209a-209n, transmit (TX) processing circuitry 214, and receive (RX) processing circuitry 219. AP MLD 101 also includes a controller / processor 224, a memory 229, and a backhaul or network interface 234.

[0079] The components shown for each of the attached APs 202a-202n can represent the Physical (PHY) layer and the lower Media Access Control (LMAC) layer in an Open Systems Interconnection (OSI) network model. In such an embodiment, the components shown for AP MLD 101 represent a single Upper MAC (UMAC) layer and other higher layers in the OSI model, which are shared by all attached APs 202a-202n.

[0080] For each affiliated AP 202a-202n, RF transceivers 209a-209n receive incoming RF signals from antennas 204a-204n, such as signals transmitted by STAs in network 100. In some embodiments, each affiliated AP 202a-202n operates at a different bandwidth (e.g., 2.4 GHz, 5 GHz, or 6 GHz), and therefore the incoming RF signals received by each affiliated AP may be at different RF frequencies. RF transceivers 209a-209n down-convert the incoming RF signals to generate an IF or baseband signal. The IF or baseband signal is sent to RX processing circuitry 219, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signal. RX processing circuitry 219 sends the processed baseband signal to controller / processor 224 for further processing.

[0081] For each associated AP 202a-202n, TX processing circuitry 214 receives analog or digital data (such as voice data, web data, email, or interactive video game data) from controller / processor 224. TX processing circuitry 214 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. RF transceivers 209a-209n receive the outgoing processed baseband or IF signal from TX processing circuitry 214 and up-convert the baseband or IF signal into an RF signal transmitted via antennas 204a-204n. In embodiments where each associated AP 202a-202n operates at a different bandwidth (e.g., 2.4 GHz, 5 GHz, or 6 GHz), the outgoing RF signal transmitted by each associated AP may be at a different RF frequency.

[0082] The controller / processor 224 may include one or more processors or other processing devices that control the overall operation of the AP MLD 101. For example, the controller / processor 224 may control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceivers 209a-209n, the RX processing circuitry 219, and the TX processing circuitry 214 according to known principles. The controller / processor 224 may also support additional functions, such as more advanced wireless communication functions. For example, the controller / processor 224 may support beamforming or directional routing operations, where outgoing signals from multiple antennas 204a-204n are weighted differently to effectively direct outgoing signals in a desired direction. The controller / processor 224 may also support OFDMA operations, where outgoing signals are assigned to different subsets of subcarriers for different receivers (e.g., different STAs 111-114). The controller / processor 224 may also facilitate QoS enhancements to support low-latency operation in WLANs. The controller / processor 224 may support any of a wide variety of other functions in the AP MLD 101. In some embodiments, the controller / processor 224 includes at least one microprocessor or microcontroller. The controller / processor 224 is also capable of executing programs and other processes residing in the memory 229, such as operations for facilitating QoS enhancements to support low-latency operation in the WLAN. The controller / processor 224 can move data into or out of the memory 229 as needed for the execution of the process.

[0083] The controller / processor 224 is also coupled to a backhaul or network interface 234. The backhaul or network interface 234 allows the AP MLD 101 to communicate with other devices or systems via a backhaul connection or over a network. Interface 234 can support communication via any suitable wired or wireless connection. For example, interface 234 can allow the AP MLD 101 to communicate with a larger network (such as the Internet) via a wired or wireless local area network or via a wired or wireless connection. Interface 234 includes any suitable architecture supporting communication via a wired or wireless connection, such as an Ethernet or RF transceiver. Memory 229 is coupled to the controller / processor 224. A portion of memory 229 may include RAM, and another portion of memory 229 may include flash memory or other ROM.

[0084] although Figure 2a An example of AP MLD 101 is shown, but it is possible to compare it with other models. Figure 2a Various changes can be made. For example, APMLD 101 can include any number of... Figure 2aEach component shown. As a specific example, AP MLD 101 may include multiple interfaces 234, and controller / processor 224 may support routing functionality to route data between different network addresses. As another specific example, although each of the attached APs 202a-202n is shown as a single instance including TX processing circuitry 214 and a single instance of RX processing circuitry 219, AP MLD 101 may include multiple instances of each of one or more of the attached APs 202a-202n (such as one instance per RF transceiver). Alternatively, only one antenna and RF transceiver path may be included in one or more of the attached APs 202a-202n, as in a conventional AP. Furthermore, Figure 2a The various components can be combined, further subdivided, or omitted, and additional components can be added as needed.

[0085] Figure 2b An example STA 111 according to one embodiment of the present disclosure is shown. Figure 2b The embodiment of STA 111 shown is for illustrative purposes only, and Figure 1 STAs 111-115 can have the same or similar configurations. In the embodiments discussed below, STA 111 is a non-AP MLD. However, STAs can have a wide variety of configurations, and Figure 2b This disclosure is not intended to limit the scope of any particular implementation of STA.

[0086] The non-AP MLD 111 is attached to multiple STAs 203a-203n (which may be referred to as, for example, STA1-STAn). Each of the attached STAs 203a-203n includes an antenna 205, a radio frequency (RF) transceiver 210, TX processing circuitry 215, and receive (RX) processing circuitry 225. The non-AP MLD 111 also includes a microphone 220, a speaker 230, a controller / processor 240, an input / output (I / O) interface (IF) 245, a touchscreen 250, a display 255, and a memory 260. The memory 260 includes an operating system (OS) 261 and one or more applications 262.

[0087] The components of each of the attached STAs 203a-203n shown can represent the PHY layer and LMAC layer in the OSI network model. In such an embodiment, the components of the non-AP MLD 111 shown represent a single UMAC layer and other higher layers in the OSI model, which are shared by all attached STAs 203a-203n.

[0088] For each associated STA 203a-203n, RF transceiver 210 receives incoming RF signals transmitted by the AP of network 100 from antenna 205. In some embodiments, each associated STA 203a-203n operates at a different bandwidth (e.g., 2.4 GHz, 5 GHz, or 6 GHz), and therefore the incoming RF signals received by each associated STA may be at different RF frequencies. RF transceiver 210 down-converts the incoming RF signals to generate an intermediate frequency (IF) or baseband signal. The IF or baseband signal is sent to RX processing circuitry 225, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signal. RX processing circuitry 225 sends the processed baseband signal to speaker 230 (e.g., for voice data) or to controller / processor 240 for further processing (e.g., for web browsing data).

[0089] For each associated STA 203a-203n, TX processing circuitry 215 receives analog or digital voice data from microphone 220, or other outgoing baseband data (such as web data, email, or interactive video game data) from controller / processor 240. TX processing circuitry 215 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. RF transceiver 210 receives the outgoing processed baseband or IF signal from TX processing circuitry 215 and up-converts the baseband or IF signal into an RF signal transmitted via antenna 205. In embodiments where each associated STA 203a-203n operates at different bandwidths (e.g., 2.4 GHz, 5 GHz, or 6 GHz), the outgoing RF signal transmitted by each associated STA may be at different RF frequencies.

[0090] The controller / processor 240 may include one or more processors and executes a basic OS program 261 stored in memory 260 to control the overall operation of the non-AP MLD 111. In one such operation, the main controller / processor 240 controls the RF transceiver 210, RX processing circuitry 225, and TX processing circuitry 215 to receive forward channel signals and transmit reverse channel signals according to known principles. The main controller / processor 240 may also include processing circuitry configured to facilitate QoS enhancement to support low-latency operation in the WLAN. In some embodiments, the controller / processor 240 includes at least one microprocessor or microcontroller.

[0091] The controller / processor 240 is also capable of executing other processes and programs residing in the memory 260, such as operations for facilitating QoS enhancements to support low-latency operation in the WLAN. The controller / processor 240 can move data into or out of the memory 260 as needed for the execution process. In some embodiments, the controller / processor 240 is configured to execute multiple applications 262, such as applications for facilitating QoS enhancements to support low-latency operation in the WLAN. The controller / processor 240 can operate the multiple applications 262 based on the OS program 261 or in response to signals received from the AP. The main controller / processor 240 is also coupled to an I / O interface 245, which provides the non-AP MLD 111 with the ability to connect to other devices such as laptops and handheld computers. The I / O interface 245 is the communication path between these accessories and the main controller 240.

[0092] The controller / processor 240 is also coupled to the touchscreen 250 and the display 255. An operator of the non-AP MLD 111 can use the touchscreen 250 to input data into the non-AP MLD 111. The display 255 may be a liquid crystal display, a light-emitting diode display, or other display capable of displaying text and / or at least limited graphics from a website. Memory 260 is coupled to the controller / processor 240. A portion of the memory 260 may include random access memory (RAM), and another portion of the memory 260 may include flash memory or other read-only memory (ROM).

[0093] although Figure 2b An example of a non-AP MLD 111 is shown, but it is possible to compare... Figure 2b Make various changes. For example, you can combine, further subdivide, or omit. Figure 2b Various components are included, and additional components can be added as needed. In a specific example, one or more of the attached STAs 203a-203n may include any number of antennas 205 for MIMO communication with AP 101. In another example, the non-AP MLD 111 may not include voice communication, or the controller / processor 240 may be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Furthermore, although Figure 2b A non-AP MLD 111 configured as a mobile phone or smartphone is shown, but the non-AP MLD can be configured to operate as other types of mobile or fixed devices.

[0094] Table 1 below shows some of the new ultra-low latency applications that the UHR group has considered to support next-generation Wi-Fi networks. For each application category, the table below shows the requirements for latency within the BSS (Basic Service Set), which is the time it takes to transmit frames from the AP to the STA and vice versa, jitter variance, packet loss, and data rate (in Mbps).

[0095] [Table 1]

[0096]

[0097]

[0098] To meet the voice and video streaming requirements of 802.11 WLANs, support for Quality of Service (QoS) services provides differentiated channel access for frames belonging to different priorities. This feature considers eight different user priorities and derives four Access Classes (ACs) from these priorities for traffic prioritization. The four supported Access Classes are Backstage (AC_BK), Best-effort (AC_BE), Video (AC_VI), and Voice (AC_VO). User priorities 1 and 2 are mapped to AC_BK, user priorities 0 and 3 to AC_BE, user priorities 4 and 5 to AC_VI, and user priorities 6 and 7 to AC_VO.

[0099] Figure 3 An example process 300 for an AC transmission queue according to an embodiment of this disclosure is shown. For example... Figure 3 As shown, the QoS features consider a separate transmission queue for each AC, where each queue is represented as a separate competing entity characterized by its own set of Enhanced Distributed Channel Access (EDCA) parameters.

[0100] Figure 4 An example EDCA parameter set 400 according to an embodiment of this disclosure is shown. Figure 4 The diagram illustrates an overview of the EDCA parameter set element parameter values ​​for different ACs in the 802.11 standard. The EDCA parameter set specifies the minimum and maximum values ​​of the Contention Window (CW), the Arbitration Inter-Frame Interval (AIFSN) value, and the Transmission Opportunity (TXOP) limit. When a particular AC completes its backoff and gains channel access, the STA can perform data transmission within the time limit defined by TXOP. By providing a larger TXOP value to AC_VI (e.g., in...), Figure 4 As shown in most cases, this standard is designed to increase the throughput of high-priority data such as video.

[0101] like Figure 4As described in the document, except for the case described in Clause 23, the four ACs have different TXOP values. Clause 23 assigns a TXOP limit of 2.528 ms for AC_BK and AC_BE, a TXOP limit of 2.080 ms for AC_VO, and a TXOP limit of 4.096 ms for AC_VI. However, to support higher throughput of video data, AC_VI has been assigned a higher TXOP limit. Therefore, for these access categories, when a STA gains channel access, it can transmit as many aggregate frames as possible while remaining within the TXOP limit.

[0102] Some applications considered for next-generation Wi-Fi standards may have extremely low latency requirements, which could make it difficult to support such applications in Wi-Fi in scenarios where this level of latency is only encountered in channel access. Therefore, this disclosure provides processes for creating more opportunities to reduce latency to support ultra-low latency applications in Wi-Fi.

[0103] Each device receives a TXOP with an equal probability of channel access, but the TXOP can be much larger than the device actually needs. For example, in a scenario where a device is performing video downloads, the downlink traffic backlog can be much larger than the uplink traffic backlog. Furthermore, a STA might only send higher-level control frames (e.g., a 20-byte TCP ACK), which may not require the entire TXOP, leaving the remainder of the TXOP underutilized. A STA could terminate the TXOP early, but this would open the channel for contention. Instead, these underutilized TXOPs can be used to create opportunities for ultra-low latency application frame transmission by allowing devices with ultra-low latency applications to transmit earlier using another STA's TXOP, thereby reducing latency for ultra-low latency applications.

[0104] The process of handing over TXOPs captured by a STA can serve several purposes. For example, it can enable an AP to either serve the low-latency service of the STA or the low-latency service of other STAs in the network. In another example, it can enable a relay to send uplink frames from a STA to the AP.

[0105] Therefore, this disclosure provides several procedures to facilitate the TXOP handover from STA to AP. One embodiment of the procedures and signaling for handover based on explicit AP-side notification is provided; another embodiment of the procedures and signaling for handover without AP-side indication; a third embodiment of the procedures and signaling for handover of STA's own services; a fourth embodiment of the procedures and signaling for handover of services used only by other STAs; an fifth embodiment of AP-side procedures and signaling for notifying other STAs of the handover; and a sixth embodiment of procedures and signaling for both AP and STA to announce support for TXOP handover through capability announcements. STA and AP-side behaviors are presented as necessary for each of the above scenarios.

[0106] According to one embodiment, a STA may transfer its TXOP or a portion thereof to its associated AP. Further according to this embodiment, the TXOP or a portion thereof transferred by the STA to the AP may be a TXOP or a portion thereof that the STA does not need to use for sending its own data (i.e., the unused portion of the TXOP). For example, the STA may have a very small backlog and may not need the entire TXOP it has already acquired. In such a case, the STA may transfer the remaining (unused) portion of its TXOP to the AP.

[0107] Figure 5 An example process 500 for TXOP handover performed by a STA according to an embodiment of the present disclosure is shown. The STA may be, for example, one of STAs 111-114. For ease of disclosure, it should be understood that reference to STA in further embodiments of the present disclosure refers to one of STAs 111-114.

[0108] Figure 6 An example process 600, performed by an AP according to an embodiment of the present disclosure, for processing a TXOP handed over by a STA, is illustrated. The AP may be, for example, one of AP 101 or 103. For the sake of convenience of disclosure, it should be understood that reference to AP in further embodiments of the present disclosure refers to one of AP 101 or 103.

[0109] like Figure 6 As shown, an AP can use a TXOP or a portion of a TXOP that has been handed over to it to serve its own (downlink) traffic or to serve the uplink traffic of other STAs. Furthermore, according to this embodiment, the downlink and / or uplink traffic served within the remaining (i.e., unused) portion of a STA's TXOP can be traffic corresponding to low-latency services. This can help reduce the latency faced by low-latency services, which might otherwise have to compete for channel access and face channel access delays.

[0110] According to one embodiment, the AP can send a notification / request to the STA to inform the STA that the AP needs the unused portion of the TXOP that the STA has already acquired—for example, the portion remaining in the TXOP after the STA has completed the transmission of its own data.

[0111] Figure 7 An example process 700, performed by the AP according to an embodiment of this disclosure, to explicitly notify the STA that a TXOP handover is required. The notification / request sent by the AP to the STA may contain one or more of the information items indicated in Table 2 below.

[0112] [Table 2]

[0113]

[0114] When the AP needs the TXOP or a portion thereof from the STA, the AP may send one or more of the aforementioned information items to the STA in a frame it sends to the STA. This frame may be a standalone frame or an existing frame in the standard (e.g., a block ACK).

[0115] For example, if the AP sends one or more of the aforementioned information items in a block ACK, the AP can send the information to the STA in a block ACK sent as a response to the STA's own uplink transmission. In another example, when the aforementioned frame can be sent independently, the AP can send the frame after / piggyback on the block ACK sent as a response to the STA's own uplink transmission.

[0116] According to one embodiment, when the STA receives a handover request from the AP, the STA may send a frame to the AP in response. This frame is referred to herein as a handover frame.

[0117] Figure 8 An example process 800, performed by a STA according to an embodiment of this disclosure, for responding to an explicit TXOP handover request / notification from an AP using a handover frame. According to this embodiment, the handover frame may contain one or more of the information items indicated in Table 3.

[0118] [Table 3]

[0119]

[0120]

[0121] One or more of the above information items may be sent in a separate frame (e.g., a handover frame) or in any existing frame in the standard.

[0122] According to one embodiment, when the STA receives a request for handover from the AP, the STA can hand over the TXOP or a portion thereof to the AP without any explicit notification.

[0123] Figure 9 An example process 900, performed by a STA according to an embodiment of this disclosure, is shown for handing over a TXOP in response to an explicit TXOP handover request / notification from an AP without sending a notification to the AP. The AP may use the remaining portion of the TXOP as needed (e.g., to send DL LL services and / or UL LL services). Upon completion of its use, the AP may terminate the TXOP (e.g., by sending a CF end frame).

[0124] According to other embodiments, the AP may request the STA to hand over its TXOP or a portion thereof to the AP without sending any notification. According to this embodiment, an agreement regarding participation in the handover may exist between the AP and the STA. Further according to this embodiment, the agreement may be explicit or implicit.

[0125] In embodiments where the AP and STA may have an explicit agreement to participate in the TXOP handover arrangement, the AP may send a frame to the STA to request the STA's participation.

[0126] Figure 10 An example process 1000, performed by an AP according to an embodiment of this disclosure, for establishing an explicit agreement to participate in the TXOP handover. Frames sent by the AP may contain one or more of the information items indicated in Table 4 below.

[0127] [Table 4]

[0128]

[0129] The above information can be transmitted by the AP in a separate frame, or in any frame that exists in the standard.

[0130] When the STA receives the above frame from the AP, the STA can respond with a response frame. The response frame may contain one or more of the information items indicated in Table 5 below.

[0131] [Table 5]

[0132]

[0133] One or more of the above information items may be transmitted in a separate frame or in any frame that exists in the standard.

[0134] Figure 11An example process 1100, executed by a STA in response to a request to participate in a TXOP handover from an AP, is illustrated according to an embodiment of this disclosure. If the STA agrees to the AP's request, the STA can perform a TXOP handover to the AP, such as... Figure 11 As shown.

[0135] If the AP receives such a response from the STA, the AP can rely on the STA's assistance to provide additional support for the LL service. Therefore, when providing latency guarantees / probability to devices with such services (e.g., via the SCS (Stream Classification Service) request and response framework), the AP can utilize its knowledge of how many other STAs have agreed to participate in the TXOP handover process.

[0136] In one embodiment, when the AP sends a frame to request the STA's participation, the STA does not send a response but needs to participate in the TXOP handover from that point onwards.

[0137] In embodiments where there is an implicit agreement between the AP and STA, certain STAs may be required to participate in the TXOP handover. For example, if an STA has its own LL service, it can support other LL services of other STAs and receive support in return from such STAs. In another example, if an STA has high DL PPDU reception that may cause delays in LL services, it may be necessary for the STA to compensate for that delay by providing assistance in the TXOP handover.

[0138] In one embodiment, there may be no agreement between the AP and the STA regarding participation in TXOP handover. According to this embodiment, the STA can decide for each TXOP whether it wants to hand over the unused or remaining portion of the TXOP. The STA can send a handover frame to the AP to notify the AP when it will hand over the TXOP or a portion thereof to the AP. The handover to the AP can be performed with or without a handover frame, similar to the procedures described above. Figure 8 and Figure 9 The discussion process.

[0139] If a handover frame is used, it can be sent at a point where other STAs can also hear the handover frame (e.g., at the beginning of the TXOP). Therefore, other STAs that receive services from the AP because their services are served during the TXOP handover can be expected to remain awake to receive services from the AP (if scheduled).

[0140] According to one embodiment, the STA can participate in the TXOP handover to receive its DL LL services independently.

[0141] Figure 12An example process 1200, performed by a STA according to an embodiment of this disclosure, for participating in a TXOP handover solely for its own DL LL service is illustrated. According to this embodiment, the STA can perform a handover to the AP when it knows it has DL LL service from the AP. The AP can then send a DL LL PPDU (or any portion of that PPDU) within the remainder of the STA's TXOP.

[0142] According to one embodiment, an STA can compete for a channel and, if successful, hand over its TXOP (Transmission Optimization Point) to an AP to support LL (Limited Access) services. This STA may not have its own service and may only compete for TXOPs to support the services of other LL STAs. This feature can, for example, be used to implement special equipment that can be deployed in an area to assist LL service STAs. This equipment can capture the channel and, where possible, hand it over to the AP to help the AP support LL service latency requirements.

[0143] According to one embodiment, after the AP receives a STA's TXOP, the AP can send a frame to notify other STAs that the AP has received a portion of a STA's TXOP. This frame can also be used to wake up other STAs or notify them that they will receive frames within other STAs' TXOPs.

[0144] An AP that supports participation in TXOP handover can advertise this capability. According to this embodiment, the AP can advertise its capability in one or more frames (e.g., management frames such as beacons) that it sends to STAs. STAs receiving the frames can discover the AP's support for this capability.

[0145] Figure 13 An example process 1300, performed by an AP according to an embodiment of this disclosure, to announce its ability to participate in the TXOP handover, is shown.

[0146] A STA capable of participating in TXOP handover can announce this capability. According to this embodiment, the STA can announce its capability in one or more frames it sends to the AP (e.g., management frames such as probe request frames). The AP receiving such a frame from the STA can then discover the STA's support for the capability and act accordingly.

[0147] Figure 14 An example process 1400, performed by a STA according to an embodiment of this disclosure, to announce its ability to participate in the TXOP handover, is shown.

[0148] While some of the procedures described above explain AP and STA behavior within the context of single-link operation, they should not be construed as limiting them to single-link operation in any way. The above procedures can also be applied to multi-link operation. When the procedure is used for MLO, the frames described in this disclosure may also carry a link ID indicator, which can indicate the link to which the request and response / handover frames are addressed. For example, this could be a link bitmap, where the bits corresponding to each link in the response are set to 1. Alternatively, this could be a list of link IDs or individual link IDs. Furthermore, frames can be transmitted on any link established between an AP MLD and a non-AP MLD.

[0149] Although the above procedures and signaling are described for the purpose of reducing latency and supporting ultra-low latency applications, they can be used for purposes other than latency reduction (e.g., interference reduction in multi-AP scenarios).

[0150] Ensuring that STAs with ultra-low latency applications do not experience poor latency in real time is likely essential for supporting such applications in next-generation Wi-Fi networks. For example, if a STA is running a cloud gaming application with a latency sensitivity of 5ms, it may be important for the AP to ensure that the STA's latency is within this limit. To reduce the latency experienced by the STA, the AP needs to know the latency encountered by the STA's services and the root cause of poor latency performance. This knowledge allows the AP to take appropriate actions to reduce the STA's latency.

[0151] For public purposes, consider two types of delay: downlink delay, which is the time from when a packet is queued at the AP to when it is received by the STA, and uplink delay, which is the time from when a packet is queued at the STA to when it is received by the AP.

[0152] Figure 15 An example timing diagram 1500 illustrates the delay encountered by downlink packets from an AP to a STA according to an embodiment of this disclosure. Figure 15 As shown, downlink delay includes queuing delay, channel access delay, and TX delay. Downlink delay is the total time from when a packet is enqueued at the AP to when the STA receives the packet.

[0153] Upon enqueuing, a packet first faces queuing delay as it passes through the packet queue for a given access class. Channel access delay is the time to gain access to a channel and successfully transmit, which includes contention time (contention delay), delays when the AP postpones transmissions from other devices on the channel, and delays due to unsuccessful transmissions (if any). TX delay is the time to transmit a frame, which includes the time to send MAC layer frames, block ACKs, any overhead, inter-frame intervals, etc.

[0154] Table 6 shows the analysis of downlink latency and the observability of its components on the AP side.

[0155] [Table 6]

[0156]

[0157] As shown in Table 6, when performing downlink transmission operations at the AP, the AP can directly observe and calculate the downlink delay and its components. The AP can also assess the root causes and components of the downlink delay because it can directly observe the factors hindering its transmission. For example, if the AP faces a large delay, it can assess whether the delay is caused by transmissions in the BSS or neighboring BSSs. Therefore, knowledge of the delay components provides the AP with insights into why the downlink delay is high, which component causes it to be high, and the reasons for the high component delay. This allows the AP to take appropriate actions to reduce downlink delay and to verify whether the actions taken by the AP have produced the desired effect based on future observations of the delay values.

[0158] Figure 16 An example timing diagram 1600 illustrates the delay encountered by uplink packets from a STA to an AP according to an embodiment of this disclosure. Figure 16 As shown, uplink delay can be decomposed into components similar to downlink delay—queueing delay, channel access delay, and TX delay.

[0159] Table 7 shows the analysis of the observability (or lack thereof) of downlink latency and its components on the AP side.

[0160] [Table 7]

[0161]

[0162]

[0163] As shown in Table 7, the AP is unaware of the total uplink latency and its components. This lack of knowledge can pose challenges for the AP from the perspective of latency reduction and support for ultra-low latency applications. For example, the AP doesn't know which STAs are experiencing large uplink latency, and therefore doesn't know which STAs require its assistance—while providing assistance to all STAs might waste resources without requiring AP support, offering unclear benefits to each STA. Furthermore, the AP doesn't know the reasons for the STAs' large uplink latency. This is essential for the AP to assess which actions best help the STAs.

[0164] Embodiments of this disclosure provide several processes to facilitate latency reporting in order to address the aforementioned problems. A framework for uplink latency, decomposition, and cause reporting is presented, featuring AP and STA-side procedures for reporting. An AP-side authorization process is described, enabling the AP to authorize specific STAs to provide reports. AP-side actions based on STA-side reports are described, including cross-link request and reporting procedures, and capability announcement procedures on both the AP and STA sides.

[0165] The framework used for uplink latency, breakdown, and cause reporting can be referred to as virtual ping. According to one embodiment, an AP can request uplink latency reports from its associated STA.

[0166] Figure 17 An example procedure 1700, performed by an AP to request an uplink latency report from a STA, according to an embodiment of this disclosure, is illustrated. According to this embodiment, the request from the AP may include one or more information items described in Table 8 below.

[0167] [Table 8]

[0168]

[0169] The aforementioned frames can be standalone frames or any frames that exist in the standard (e.g., measurement request frames).

[0170] The STA can send an uplink latency report to the AP independently (e.g., if the STA is experiencing poor uplink latency and needs assistance from the AP to improve its latency) or upon request from the AP.

[0171] Figure 18 An example process 1800, performed by a STA for reporting uplink latency to an AP according to an embodiment of this disclosure, is shown. The uplink latency report may include one or more information items mentioned in Table 9 below.

[0172] [Table 9]

[0173]

[0174] The above information can be sent by the STA to the AP in a separate frame or in any frame that exists in the standard (e.g., a measurement response frame, a control subfield variant of the A-control subfield).

[0175] According to one embodiment, the AP can authorize the STA to report the aforementioned statistical information to the AP. The AP can authorize the STA itself based on standards (e.g., the STA may have ultra-low latency services), or it can authorize the STA based on a request from the STA.

[0176] Figure 19An example procedure 1900, performed by an AP according to an embodiment of the present disclosure, for authorizing a STA to perform an uplink latency report. The AP may authorize the STA to send an uplink latency report to it in a frame sent by the AP to the STA. The frame may contain one or more of the information items indicated in Table 10 below.

[0177] [Table 10]

[0178]

[0179] The AP can send the above information to the STA in a separate frame or in any frame in the standard (e.g., a beacon frame).

[0180] According to one embodiment, the STA can transmit an auxiliary indicator to the AP to report assistance in reducing latency. For example, this could be a bit in a frame sent by the STA to the AP, which could be set to 1 when the STA is facing high latency and set to 0 when the STA is facing low latency. When the AP receives such a frame with the indicator bit set to 1, the AP can take action to reduce the STA's latency—for example, by triggering an action on the uplink.

[0181] When the AP receives an uplink delay report from the STA, it can take action to reduce the STA-side latency.

[0182] Figure 20 An example procedure 2000 performed by an AP according to an embodiment of this disclosure is illustrated, which takes action to reduce STA-side latency in response to an uplink latency report provided by a STA. The actions taken may depend on the statistics and causes reported by the STA. Some example actions from the AP side are listed in Table 11.

[0183] [Table 11]

[0184]

[0185] According to one embodiment, in the case of MLO, the AP MLD can request the aforementioned information from the non-AP MLD on any link established between the AP MLD and the non-AP MLD. According to this embodiment, information for statistical information used on any link established between the AP MLD and the non-AP MLD can be requested.

[0186] Figure 21An example procedure 2100 is illustrated, performed by an AP MLD for a cross-link request / authorization of uplink latency reporting performed by a non-AP MLD, according to an embodiment of this disclosure. The non-AP MLD may be, for example, one of non-AP MLDs 111-114. For ease of disclosure, it should be understood that in further embodiments of this disclosure, reference to a non-AP MLD refers to one of non-AP MLDs 111-114. An AP MLD may be, for example, one of AP MLDs 101 or 103. For ease of disclosure, it should be understood that in further embodiments of this disclosure, reference to an AP MLD refers to one of AP MLDs 101 or 103.

[0187] Considering that an AP MLD has two APs (AP1 and AP2) attached to it, and an associated non-AP MLD (which has two non-AP STAs (STA1 and STA2) attached to it), and the AP MLD and non-AP MLD establish two links (Link 1 and Link 2), the AP MLD can request a report for Link 2 from STA2 of the non-AP MLD by sending a request to STA1 via AP1 on Link 1. It should be understood that embodiments of this disclosure can be implemented using an AP MLD with any suitable number of attached APs or a non-AP MLD with any suitable number of attached non-AP STAs.

[0188] According to one embodiment, the above information can be sent from a non-AP MLD to an AP MLD on any link established between an AP MLD and a non-AP MLD.

[0189] Figure 22 An example process 2200, performed by a non-AP MLD according to an embodiment of this disclosure, for reporting cross-link uplink latency to an AP MLD. According to this embodiment, information regarding statistics about any link established between the AP MLD and the non-AP MLD can be reported. Consider regarding... Figure 21 In the scenario discussed, a non-AP MLD can report STA2's statistics on link 2 by sending information from STA1 to AP1 on link 1.

[0190] When such cross-link reporting occurs, the link identifier can be included along with the information in the report. The link identifier can indicate which link the information corresponds to; for example, if information is reported for multiple links, the link identifier can be a link ID or a link ID bitmap. When using a link ID bitmap, the bit corresponding to the link in the reported information can be set to 1.

[0191] According to one embodiment, an AP supporting this STA-side reporting process can advertise its capabilities to a STA in one or more frames it sends to the STA. Further, according to this embodiment, a STA receiving such a frame can understand that the AP supports such capabilities.

[0192] Figure 23 Example process 2300, performed by an AP according to an embodiment of this disclosure, for announcing its ability to support uplink latency reporting on the STA side. The AP may announce its capability in a separate frame or in any frame it sends to the STA (e.g., a management frame such as a beacon).

[0193] Similarly, a STA that supports this uplink latency reporting can advertise its capability to the AP in one or more frames it sends to the AP. When the AP receives such a frame, it can understand that the STA supports this capability.

[0194] Figure 24 An example process 2400, performed by a STA according to an embodiment of this disclosure, for announcing its ability to support STA-side uplink latency reporting. The STA may announce its capability in a separate frame or in any frame it sends to the AP (e.g., a management frame such as a probe response frame).

[0195] The traffic flow of an STA can be broadly divided into two categories: periodic traffic and aperiodic traffic. Periodic traffic is characterized by the periodicity or predictability of packet arrivals. If the AP (Application Processor) knows in advance traffic characteristics such as periodicity and burst length, the AP can understand when an STA might have a backlog. Aperiodic traffic is characterized by event-based or unpredictable packet arrivals. In this case, the AP cannot assess whether an STA has a backlog on its own. Therefore, an STA can have a backlog at any time, and the AP may not be aware of this situation.

[0196] Current service information reporting methods have several limitations. For MLO, because the framework used for service information reporting was designed prior to 11be, reporting is done on a per-link basis and on the same link corresponding to the information. Cross-link support is unavailable. The current service information reporting framework also completes reporting on a per-TID (Service Identifier) ​​basis—while flow IDs were introduced in next-generation Wi-Fi to support enhanced reporting and meet QoS requirements, the concept of flow IDs is absent in the current service information reporting framework.

[0197] These limitations may lead to inefficiencies in new features introduced in next-generation Wi-Fi networks. For example, in terms of power savings on the AP side, an AP attached to an AP MLD could benefit from knowing whether a STA already has a backlog on a given link before entering sleep mode. However, current methods do not facilitate this because reporting can only be done on the same link.

[0198] As another example, to allow low-latency traffic to be sent in the uplink / downlink during an ongoing TXOP (e.g., during preemption), the AP's knowledge of the STA's traffic backlog and which flow the backlog belongs to allows the AP to efficiently serve uplink traffic by scheduling time / frequency resources. However, current methods can limit the AP's collection (or STA's reporting) of information within the ongoing TXOP itself, thus wasting already limited TXOP time. This can be inefficient if the STA's traffic is aperiodic LL traffic.

[0199] As another example, if a STA wants to be scheduled for uplink transmission via a triggered TXOP share (e.g., due to the arrival of aperiodic LL traffic) after a TXOP has started, the STA cannot notify the AP of such arrival unless the TXOP belongs to the STA or the STA is polled by the AP via, for example, Buffer Status Report Polling (BSRP). However, since the STA's traffic is aperiodic, the AP may not be aware of the traffic arrival, and polling each STA in the TXOP may be inefficient, resulting in wasted resources.

[0200] These inefficiencies could impact support for ultra-low latency applications in next-generation Wi-Fi networks. Therefore, a faster, cross-link-oriented service statistics reporting protocol could be beneficial for new features considered in UHR. Accordingly, this disclosure provides several processes to facilitate service information reporting in addressing the above issues. For example, various processes and signaling are provided for service information reporting, as well as various processes and signaling for service information requests, negotiation processing, and capability announcements.

[0201] According to one embodiment, service information can be reported in a cross-link manner, that is, information corresponding to a link can be reported on different links. The report may contain one or more of the information items indicated in Table 12.

[0202] [Table 12]

[0203]

[0204] The above information items can be carried in a single frame or multiple frames. One or more of the above information items can be carried in a newly defined frame or in an existing frame in the standard. Reports can be generated upon request or unsolicited (e.g., to help the report recipient make decisions). Some examples are as follows:

[0205] As an example, the above information from Table 12 can be reported in a variant of the control subfield of the A-control subfield.

[0206] Figure 25 An example frame format 2500 of a variant of the control subfield of the A-control subfield according to embodiments of the present disclosure is shown. The flow information subfield may indicate the flow identifier (e.g., SCSID) to which the reported information belongs. When this field is not used, a reserved value (e.g., value 0) may exist for this field. Alternatively, the transmitter may insert invalid flow information into this field. When the receiver receives an A-control field with invalid flow information, it can understand that the field is not used.

[0207] ACI bitmap subfields can indicate the AC for which the report is being generated. Each bit in the ACI bitmap can correspond to an AC. For example, bit 0 can correspond to AC_BE, bit 1 to AC_BK, bit 2 to AC_VI, and bit 3 to AC_VO.

[0208] The scaling factor subfield can indicate the unit SF (in octets) of the Queue Size All subfield. Example encodings for the scaling factor subfield are shown in Table 13 below.

[0209] [Table 13]

[0210]

[0211] The queue size subfield indicates the buffered traffic volume of the AC (in SF octets), identified by the ACI bitmap subfield. The link ID subfield indicates the link to which this information belongs.

[0212] Figure 26 Example operation 2600 using the above-described A-control subfield according to an embodiment of this disclosure is shown. For example... Figure 26 As shown, AP2 has acquired the TXOP on link 2 and is sending data. STA2 wants to be allocated a portion of AP2's TXOP (e.g., via preemption, triggered TXOP sharing, etc.) because it has one or more frames corresponding to an ultra-low latency application.

[0213] However, because AP2 is transmitting, STA2 cannot transmit its service information on link 2. Instead, STA1 can send an A-control subfield to AP1 on link 1 (either during an ongoing transmission or in a QoS empty frame). This A-control subfield contains information about the flow to which the frame queued at STA2 corresponds. Once the information is received at AP1, AP MLD can internally pass the information to AP2. AP2 can then take action based on this information (e.g., allocate a portion of its TXOP to STA2 on link 2, or trigger STA2 to transmit on the uplink of link 2).

[0214] According to another example, the business information in Table 12 can be reported in a new control frame.

[0215] Figure 27 An example frame format 2700 of a control frame according to an embodiment of the present disclosure is shown. The control frame may contain a service information report for each flow identifier, which, for ease of discussion, is referred to herein as a per-flow report.

[0216] Figure 28 An example format 2800 of a per-stream report according to an embodiment of this disclosure is shown. A service information report using control frame 2700 may include one or more of these per-stream reports 2800.

[0217] refer to Figure 28 The Stream ID subfield identifies the stream to which the information belongs (e.g., SCSID). The TID bitmap subfield indicates the TID for the reported information. A value of 1 at bit position i in this bitmap indicates to the receiver that the transmitter is reporting service information for TID i in the service report. A value of 0 at bit position i in this bitmap indicates to the receiver that the transmitter is not reporting service information for TID i in the service report.

[0218] The timing information subfield can indicate the timing information (e.g., enqueue time) of the most urgent frame in the queue that belongs to one of the TIDs indicated in the TID bitmap. Alternatively, the timing information subfield can also indicate the delay timer for the most urgent frame. The most urgent frame can be the frame with the minimum delay timer, or the frame that is the first to exceed its delay limit among all frames that report its information in the report.

[0219] The scaling factor subfield can indicate the unit SF (in octets) of all subfields for the queue size. Example encodings for the scaling factor subfield are shown in Table 13 above.

[0220] The queue size subfield indicates the amount of buffered traffic in SF octets for the TID identified by the TID bitmap subfield. The link ID subfield indicates the link to which this information belongs. The air interface time requirement subfield indicates the amount of air interface time required for the reported backlog of transmissions.

[0221] Figure 29 Example operation 2900 using the above-described control frame according to an embodiment of this disclosure is shown. Figure 29 As shown, AP2 has acquired the TXOP on link 2 and is sending data. AP3 has acquired the TXOP on link 3 and is sending data. STA2 wants to be allocated a portion of AP2's TXOP (e.g., via preemption, triggered TXOP sharing, etc.) because it has frames corresponding to ultra-low latency applications. Similarly, STA3 wants to be allocated a portion of AP3's TXOP because it has frames corresponding to ultra-low latency applications.

[0222] However, because AP2 and AP3 are transmitting, STA2 and STA3 cannot transmit their service information on Link 2 and Link 3 respectively. Instead, STA1 can transmit on Link 1. Figure 27 The aforementioned control frame contains reports for STA2 on link 2 and STA3 on link 3. Once the information is received at AP1, AP MLD can internally pass the information to AP2 and AP3. AP2 and AP3 can then take action based on this information (e.g., allocate a portion of their TXOP to STA2 on link 2 and STA3 on link 3 respectively, or trigger STA2 and STA3 to perform uplink transmissions on link 2 and link 3 respectively).

[0223] According to another example, the business information of Table 12 can be reported in a newly defined element.

[0224] Figure 30 An example element format 3000 of a novel element according to an embodiment of the present disclosure is shown. Figure 30 The new element can contain a list of per-stream reports, which can contain one or more per-stream reports.

[0225] Figure 31 An example format 3100 for per-stream reports according to embodiments of this disclosure is shown. Figure 30 Each per-stream report in the new element can have format 3100.

[0226] refer to Figure 31The Flow Information subfield can indicate information about the flow (e.g., SCSID). The Scaling Factor subfield can indicate the unit SF (in octets) for all subfields of the Queue Size subfield. Example encodings for the Scaling Factor subfield can be shown in Table 13 above. The Queue Size All subfield can indicate the buffered traffic in SF octets for the TID identified by the TID Bitmap subfield. The Link ID subfield can indicate the link to which the reported information corresponds.

[0227] ACI bitmap subfields can indicate the AC for which the report is being generated. Each bit in the ACI bitmap can correspond to an AC. For example, bit 0 can correspond to AC_BE, bit 1 to AC_BK, bit 2 to AC_VI, and bit 3 to AC_VO.

[0228] The timing information list subfield can provide timing information about the traffic flow. For example, this could be timing information (e.g., queuing timestamp) of the header of the line packet for each of the ACs indicated in the ACI bitmap. In another example, this could be timing information that describes the arrival pattern of the traffic flow.

[0229] The air interface time requirement subfield can provide the amount of air interface time required to send the indicated information.

[0230] The L4S Presence Indicator subfield can indicate whether any L4S packets are present in the indicated backlog. In one example, this could be a bit set to 1 to indicate that there are backlogged L4S packets at STA. In another example, this could be a bitmap where each bit can indicate the AC queue for L4S packets to be enqueued. For example, if bit 2 is set to 1 in the ACI bitmap and bit 2 is set to 1 in the L4S Presence Indicator field, this could indicate that there are queued L4S packets in the AC_VI queue.

[0231] Figure 32 Example operation 3200 using the novel elements described above, according to an embodiment of this disclosure, is shown. For example... Figure 32 As shown, AP2 has a TXOP on link 2, and AP3 is in a dormant state. In this scenario, if STA2 and STA3 want to send service reports to their respective APs (e.g., if a packet arrives at STA2 after AP2 has captured a TXOP and started its transmission, and a packet arrives at STA3 after AP3 has entered a dormant state), STA2 might want some of AP2's TXOPs allocated on link 2, and STA3 might want AP3 to leave its dormant state so it can send frames.

[0232] In this example, STA1 can send a report to AP1 containing a list of per-flow reports for links 2 and 3, and the corresponding APs (AP2 and AP3) can then take action on this information. For example, AP2 can allocate a portion of its acquired TXOPs to STA2, and AP3 can revive and trigger STA3 to perform uplink transmissions.

[0233] According to another example, the business information in Table 12 can be reported in a newly defined acknowledgment frame (e.g., block ACK).

[0234] Figure 33 An example format 3300 of a new block ACK frame carrying a service report is shown according to an embodiment of this disclosure. Figure 33 The new block ACK includes a business report subfield, which may include Figure 25 , 28 And any combination of fields described in the example in 31.

[0235] Figure 34 An example operation 3400 using the new block ACK described above, according to an embodiment of this disclosure, is shown. For example... Figure 33 As shown, AP3 is in a sleep state. In this scenario, if STA3 wants to send a service report to AP3 so that AP3 can emerge from its sleep state and serve STA3, STA1 can include the service report in a BA (Block ACK), which is sent to AP1 as part of its ongoing transmission. This report can be internally passed to AP3 by AP MLD, and AP3 can then take action on it, for example, by emerging from its sleep state to trigger STA3 on the uplink.

[0236] Another example of a report could be based on a measurement response frame, which could include one or more of the fields previously described.

[0237] According to one embodiment, information about a service can be reported upon request from an entity (e.g., AP MLD). The request frame may contain one or more of the information items indicated in Table 14.

[0238] [Table 14]

[0239]

[0240] The above information items can be carried in a single frame or multiple frames. One or more of the above information items can be carried in a newly defined frame or in existing frames within the standard. Some examples are as follows:

[0241] As an example, the above information from Table 14 can be requested in a variant of the control subfield of the A-control subfield.

[0242] Figure 35 An example frame format 3500 is shown as a variant of the control subfield of the A-control subfield according to an embodiment of the present disclosure. The TID bitmap subfield can indicate the TID for which a report is being requested. A value of 1 in bit position i of the bitmap can indicate to the receiver that the requesting entity is requesting a report of a frame belonging to TID i from the STA, and a value of 0 can indicate that the requesting entity is not requesting a report of a frame belonging to TID i.

[0243] The L4S Presence Indicator can be set to 1 to indicate whether the requesting entity wants to know if there are any packets belonging to the L4S category backlog on the STA side. The Timing Information Request subfield can be set to 1 to indicate that the requesting entity is requesting timing information from the responding entity in the report. Otherwise, it can be set to 0. The Air Interface Timing Information Request subfield can be set to 1 to indicate that the requesting entity is requesting air interface timing information from the responding entity. The Link ID field can indicate the link for which the report is being requested (or in other words, the corresponding STA operating on the indicated link for MLD).

[0244] Figure 36 Example operation 3600 using the above-described A-control subfield according to an embodiment of this disclosure is shown. For example... Figure 36 As shown, AP2 has captured a TXOP on link 2. In this example, AP2 wants to allocate a portion of the captured TXOP to STA2, but it doesn't know if STA2 has a backlog or the necessary urgency. In advance, before the portion of the TXOP becomes available, AP1 can send an A control subfield (either in an ongoing transmission or as a QoS empty frame) to request a traffic report for STA2. Upon receiving the traffic report from STA2, AP2 can make a decision.

[0245] According to another example, the above information in Table 14 can be requested in a new control frame.

[0246] Figure 37 An example frame format 3700 for a control frame used for a service information request according to an embodiment of this disclosure is shown. Figure 37 As shown, a control frame may contain a business information request list field, which may contain one or more business information requests.

[0247] Figure 38 An example format 3800 for a business information request according to an embodiment of this disclosure is shown. Figure 37 Each business information request in the business information request list field of the control frame can have a format 3800.

[0248] refer to Figure 38The Stream Information subfield indicates whether the requesting entity is making a request corresponding to a specific stream. The TID Bitmap subfield indicates the TID for which a report is being requested. A value of 1 in bit position i of this bitmap indicates to the receiver that the requesting entity is requesting a report of a frame belonging to TID i from a report from the STA, and a value of 0 indicates that the requesting entity is not requesting a report of a frame belonging to TID i.

[0249] The Timing Information Request subfield can be set to 1 to indicate that timing information is being requested in the report. The Link ID subfield can indicate the link for which the report is being requested (or in other words, the corresponding STA operating on the indicated link in the MLD). The Air Interface Time Request subfield (or Air Interface Time Information Request subfield) can be set to 1 to indicate that the requesting entity is requesting air interface time information from the responding entity. The L4S Presence Indicator can be set to 1 to indicate whether the requesting entity wants to know if there are any packets belonging to the L4S category backlog on the STA side.

[0250] Figure 39 An example operation 3900 is shown, illustrating the use of the aforementioned control frame to request a service report according to an embodiment of this disclosure. For example... Figure 39 As shown, AP2 has captured the TXOP on link 2, and AP3 is in a dormant state. In this example, AP2 and AP3 want to request reports from STA2 and STA3 respectively in advance (e.g., AP2 wants to know STA2's service information before allocating a portion of the TXOP to STA2, and AP3 wants to know STA3's service information before exiting its dormant state). To achieve this, AP1 can send a control frame to STA1 carrying two service report requests.

[0251] According to another example, the above information from Table 14 can be requested in a newly defined element.

[0252] Figure 40 An example format 4000 for a new element for a business information request according to an embodiment of this disclosure is shown. Figure 40 As shown, the new element can contain a list field for business information requests, which can contain one or more business information requests. These business information requests can have... Figure 38 The format is 3800. Furthermore, operations using new elements can be similar to... Figure 39 Operation 3900, in which the action frame carries Figure 40 new elements instead Figure 37 The control frame.

[0253] According to another example, the aforementioned information in Table 14 can be requested in a modified acknowledgment frame (e.g., block ACK).

[0254] Figure 41 An example format 4100 of a modified block ACK carrying a service information request according to an embodiment of this disclosure is shown. Figure 41 The modified block ACK includes a service information request list field, which may contain one or more service information requests. These service information requests may have... Figure 38 The format is 3800.

[0255] As an example, the above information can be requested in the Modified Buffer Status Report Poll (BSRP).

[0256] According to one embodiment, a negotiation process may exist between the requesting entity and the responding entity. According to this embodiment, either entity may send a negotiation request frame to the other entity. Upon receiving the negotiation request frame, the other entity may process the request and, if the request is acceptable, send a response frame. The request frame may contain one or more of the information items indicated in Table 15.

[0257] [Table 15]

[0258]

[0259] The aforementioned information items can be carried in a single frame or in multiple frames. One or more of the aforementioned information items can be carried in a newly defined frame or in an existing frame within the standard.

[0260] A negotiation response may contain one or more of the information items indicated in Table 16.

[0261] [Table 16]

[0262]

[0263] The aforementioned information items can be carried in a single frame or in multiple frames. One or more of the aforementioned information items can be carried in a newly defined frame or in an existing frame within the standard.

[0264] According to one embodiment, an MLD that supports the traffic flow information reporting capabilities described in this disclosure may advertise its support in one or more frames it transmits. For example, if the MLD is an AP MLD, it may advertise its support in management frames such as beacons, probe responses, etc. If the MLD is a non-AP MLD, it may advertise its support in management frames such as probe requests, (re)association requests, etc.

[0265] The report request and response described above can occur between any two entities. For example, the requesting entity could be an AP MLD, and the responding entity could be a non-AP MLD as in the examples above. In another example, the requesting entity could be a peer, and the responding entity could also be a peer. In yet another example, the requesting entity could be an AP MLD, and the responding entity could also be an AP MLD. The requesting entity could be a non-AP MLD, and the responding entity could be an AP MLD.

[0266] The fields described in the examples in this disclosure are not limited to frames, elements, etc., in the context in which they are already described. They can be part of any frame, element, etc., in the standard specification, or they can be newly defined frames, elements, etc. Additionally, in each of the examples above, one or more fields / subfields may be absent. Furthermore, one or more additional fields not discussed in this disclosure may be present. The TID bitmap indicated in this disclosure may be 8-bit or 16-bit.

[0267] The QoS requirements for service flows are specified during SCS establishment and referenced by SCSIDs based on SCS request and response frames. However, service processing is done based on Access Class (AC) / TID, which may not provide good differentiation and QoS requirement satisfaction. This can be inefficient and may not lead to the desired results in many cases.

[0268] For example, a user can have multiple applications. Each application can generate multiple packets with different TIDs. Even if two packets belong to the same TID, their QoS requirements can be different because they can belong to two different traffic flows. If the AP MLD wants to map all traffic of a first traffic flow to a specific link (e.g., if the link has less congestion and can meet the QoS requirements of the first traffic flow), the current method of TID-to-link mapping can result in packets of other traffic flows being mapped to that link (e.g., if other traffic flows have some packets belonging to the same TID as the first traffic flow).

[0269] In addition, there may be other types of services that are not currently covered by 802.11 (e.g., L4S), which can be mapped to an AC / TID that also has groups that do not belong to the same service type but belong to the same AC / TID.

[0270] Additionally, if the AP MLD wants to trigger packets for the first service flow to meet its latency requirements, it's possible that if another flow belongs to the same TID / AC as the first service flow, packets for that other flow will also be triggered. This could lead to undesirable effects.

[0271] It is important that the process can be provided based on the flow to which the service belongs. Accordingly, this disclosure provides several processes to facilitate flow ID-based service processing to address the above issues. For example, various processes and signaling for flow-to-link mapping are provided, including processes and signaling for requests, responses, teardowns, and capability announcements related to flow-to-link mapping. In addition, flow-based triggering processes and related capability announcement processes and signaling are provided.

[0272] According to one embodiment, flow classification criteria can be explicitly specified by providing a classifier capable of classifying packets belonging to a specific flow. For example, this can be accomplished by explicitly providing a TCLAS (Traffic Classification) and a TCLAS processing element when referencing a specific flow.

[0273] According to one embodiment, a flow classification standard can be reused by referencing a SCSID allocated during the SCS request and response process. Classification standards based on TCLAS and TCLAS processing elements provided during the SCS request and response process can be reused based on SCSID references.

[0274] According to one embodiment, a flow-to-link mapping process can be performed. The final result of this process may be that packets belonging to a specific flow can be mapped to a specific link. To achieve this effect, a requester (e.g., a non-AP MLD) can send a request to a requested party (e.g., an AP MLD). The request may be in the form of one or more frames sent to the requested party. The frame may contain one or more information items as indicated in Table 17.

[0275] [Table 17]

[0276]

[0277] The above information items can be transmitted in one or more frames. These information items can be transmitted in newly defined frames or in any frame existing in the standard (e.g., A-control subfields, control frames, action frames, etc.). Some examples are as follows:

[0278] In one example, the newly defined element can carry the flow-to-link mapping request information from Table 17.

[0279] Figure 42 An example format 4200 of a stream-to-link mapping element according to an embodiment of the present disclosure is shown. The stream-to-link mapping element may include a stream-to-link mapping control field.

[0280] Figure 43An example format 4300 of the flow-to-link mapping control field according to an embodiment of this disclosure is shown. If the flow-to-link mapping element provides flow-to-link mapping information for frames transmitted in the downlink, the direction subfield can be set to 0. If the flow-to-link mapping element provides flow-to-link mapping information for frames transmitted in the uplink, it can be set to 1. If the flow-to-link mapping element provides flow-to-link mapping information for frames transmitted in both the downlink and uplink, it can be set to 2. It can be set to 3 to indicate that the flow-to-link mapping element provides flow-to-link mapping information for frames sent to peers.

[0281] The `Default Link Mapping` subfield can be set to 1 to indicate that the `Stream to Link Mapping` element represents the default `Stream to Link Mapping`. Otherwise, it can be set to 0. The `TID Link Mapping` subfield can be set to 1 to indicate that the mapping should follow the `TID` to `Link Mapping` instead of the new `Stream to Link Mapping`. Otherwise, it can be set to 0. The `Mapping Switch Time Existence` subfield can be set to 1 to indicate that the `Mapping Switch Time` field exists. Otherwise, it can be set to 0. The `Expected Duration Existence` subfield can be set to 1 to indicate that the `Expected Duration` field exists. Otherwise, it can be set to 0. The `Link Mapping Size` subfield can indicate the number of links for which a `Stream to Link Mapping` has already been provided in the `Stream to Link Mapping` element.

[0282] Refer again Figure 42 Example format 4200 for a stream-to-link mapping element: The mapping switch time field indicates when a new stream-to-link mapping can be established. The absence of this field indicates that a stream-to-link mapping has already been established when the element is received.

[0283] The Expected Duration field indicates the duration for which the suggested flow to the link mapping is expected to be effective. Time can be indicated in TU units. When the Mapping Switch Time field is present, the Duration field can be the duration starting from the time indicated by the Mapping Switch Time field. When this field is not present, the Duration field indicates the remaining time for which the flow to the link mapping is expected to be effective.

[0284] The per-link-map list field can include a list of flows to the link-map field.

[0285] Figure 44 An example format 4400 of a stream-to-link mapping field according to an embodiment of this disclosure is shown. Included in Figure 42 Each flow-to-link mapping field in the per-link mapping list field can have a format of 4400. The flow count subfield can indicate the number of flow identifiers present after the link ID subfield. The link ID subfield can indicate the link to which this information belongs. The SCSID following the link ID subfield can indicate the SCSID mapped to this link.

[0286] When the aforementioned information elements are sent by the AP MLD to indicate a mapping to a non-AP MLD, these information elements may exist in management frames such as beacon frames, probe response frames, etc. When transmitted in a beacon, an additional field may be present to indicate which device is the receiver of the element.

[0287] When the aforementioned information elements are sent by a non-AP MLD to indicate a mapping request to the AP MLD, the aforementioned information elements may exist in management frames such as (re)association requests, probe request frames, etc.

[0288] In another example, the new action frame can carry the flow-to-link mapping request information described in Table 17. The flow-to-link mapping request action frame can have fields in the format of Table 18 below.

[0289] [Table 18]

[0290]

[0291] The Category field indicates the category of the action frame. The Protected Action field allows for the differentiation of protected action frame formats. The Dialogue Token can be a non-zero value, which can be selected by the frame's sender to identify a request / response transaction. The Stream-to-Link Mapping field can contain one or more stream-to-link mapping elements as described above.

[0292] According to one embodiment, the request may not be negotiable—for example, if the request is made by an AP MLD, a non-AP MLD can only accept or reject it. According to one embodiment, the request may be negotiable—for example, if the request is made by a non-AP MLD, the AP MLD can respond with a response frame that can indicate the final configuration.

[0293] According to one embodiment, a response procedure may exist for a flow-to-link mapping request for flow ID-based service processing. The response procedure may indicate the response from the requested party to the requester. The response may contain one or more of the information items indicated in Table 19.

[0294] [Table 19]

[0295]

[0296] The above information items can be transmitted in one or more frames. These information items can be transmitted in newly defined frames or in any frame existing in the standard (e.g., A-control subfields, control frames, action frames, etc.). Some examples are as follows.

[0297] In one example, the newly defined element could carry the flow-to-link mapping response information from Table 19 above. This can be used with... Figure 42 The same element format described in [the previous section]. In this example, each field / subfield of the response element can indicate the response to the corresponding field / subfield of the request element. For example, a list of per-link maps can contain the final flow-to-link map determined by the requestee. Response elements can be carried in management frames exchanged between the requester and the requestee.

[0298] In another example, the new action frame can carry the flow-to-link mapping response information from Table 19 above. The flow-to-link mapping response action frame can have the same format as the flow-to-link mapping request action frame, which has the format shown in Table 18 above.

[0299] The Category field indicates the category of the action frame. The Protected Action field allows for the differentiation of protected action frame formats. The Dialogue Token can be a non-zero value, which can be selected by the frame sender to identify a request / response transaction. The Stream-to-Link Mapping field can contain one or more stream-to-link mapping elements as described above to indicate a response.

[0300] Figure 45 Example operation 4500, including a stream-to-link mapping request frame, is shown according to an embodiment of this disclosure. Figure 45 As shown, the AP MLD has three affiliated APs—AP1, AP2, and AP3. The non-AP MLD has three affiliated STAs—STA1, STA2, and STA3. Three links—Link 1, Link 2, and Link 3—are established between the AP MLD and the non-AP MLD.

[0301] In this example, the AP MLD wants to create flow-to-link mappings to enable the mapping of certain applications' traffic to certain links. For example, links 1 and 2 have lower congestion and better channel conditions, so the AP MLD wants to map flows with ultra-low latency requirements to links 1 and 2, as not indicated by the AP MLD in its SCS request and response setup. In this example, flow 1 (S1) is mapped to link 1 (L1), flow 2 (S2) is mapped to link 2 (L2), and flow 3 (S3) is mapped to link 3 (L3).

[0302] AP MLD sends action frames (for example, consider action frames, but other types of frames can also be used) to non-APMLDs. The action frame provides a request element with the requested flow-to-link mapping. At the indicated time, the mapping can take effect, whereby the corresponding flow is mapped to the indicated link.

[0303] Figure 46 Example operation 4600, including a stream-to-link mapping request and response frame, is shown according to an embodiment of this disclosure. Figure 46As shown, a non-AP MLD sends a request frame to the AP MLD on one of the links. The non-AP MLD proposes mapping flow 1 to link 1, flow 2 to link 2, and flow 3 to link 3. However, this mapping may be impossible (e.g., if AP2, attached to the AP MLD, faces self-interference from co-located non-Wi-Fi radios, if AP2 is about to enter sleep mode, if AP2 is receiving interference from a neighboring BSS on link 2, etc.). Therefore, the AP MLD sends a response frame indicating the modified mapping as shown. The mapping can take effect at the indicated time.

[0304] According to one embodiment, a flow-to-link mapping can be removed. The removal frame may include one or more of the information items indicated in Table 20.

[0305] [Table 20]

[0306]

[0307] The aforementioned information items can exist in one or more frames. They can exist in newly defined frames or in any frame that exists in the standard.

[0308] Based on an example, a new demolition action frame can be defined. Table 21 shows the example demolition action frame format.

[0309] [Table 21]

[0310]

[0311] The Category field indicates the category of the action frame. The Protected Action field allows for the differentiation of protected action frame formats.

[0312] Figure 47 An example operation 4700 of stream-to-link mapping removal according to an embodiment of this disclosure is shown. Figure 47 As shown, Flow 1, Flow 2, and Flow 3 have been mapped to Link 1, Link 2, and Link 3, respectively. The AP MLD sends a teardown frame to the non-AP MLD. After the teardown frame, the default mapping takes effect until a new mapping is set.

[0313] According to one embodiment, an AP MLD that supports flow-to-link mapping features can announce its support in one or more frames it transmits. In one example, these frames can be management frames, such as beacons, probe responses, (re)association responses, etc. Fields (e.g., bits) that can be set to specific values ​​(e.g., 1) to indicate supported features may exist.

[0314] According to one embodiment, a non-AP MLD that supports flow-to-link mapping features can announce its support in one or more frames during its transmission. In one example, these frames can be management frames, such as probe requests, (re)association requests, etc. Fields (e.g., bits) that can be set to specific values ​​(e.g., 1) may exist to indicate supported fields.

[0315] According to one embodiment, a frame belonging to a specific flow / service identifier can be triggered for transmission. For example, an AP attached to an AP MLD can send a trigger frame to a STA attached to a non-AP MLD to trigger the transmission of a frame belonging to a specific flow on the uplink. According to this embodiment, the trigger frame may contain one or more of the information items indicated in Table 22.

[0316] [Table 22]

[0317]

[0318] The above information may be included in an existing trigger frame, a newly defined trigger frame, or any other frame in the standard.

[0319] When a trigger frame is received, a frame identified by a service identifier or a flow identifier or both can be sent by the receiver of the trigger frame.

[0320] According to one embodiment, an AP MLD that supports stream-based triggering can announce its support in one or more frames it transmits. In one example, these frames can be management frames, such as beacon, probe response, (re)association response, etc. Fields (e.g., bits) that can be set to specific values ​​(e.g., 1) to indicate supported fields may exist.

[0321] According to one embodiment, a non-AP MLD that supports stream-based triggering can announce its support in one or more frames it sends. In one example, these frames can be management frames, such as probe requests, (re)association requests, etc. Fields (e.g., bits) that can be set to specific values ​​(e.g., 1) to indicate supported fields may exist.

[0322] The above process can be used by any device and is not limited to the device types described in this disclosure. One or more fields described in the example signaling may be included in any frame in the standard or in newly defined frames of other types. One or more fields described in the example may not exist.

[0323] Figure 48 An example process 4800 for facilitating QoS enhancement to support low-latency operation according to an embodiment of this disclosure is illustrated. Specifically, process 4800 facilitates a TXOP handover process, whereby the STA transfers the unused portion of its TXOP to the AP. Figure 48 The process 4800 is discussed as being executed by the STA, but it is understandable that the corresponding AP executes the corresponding process. Additionally, for convenience, Figure 48 The process is discussed as being performed by a Wi-Fi STA; however, it should be understood that any suitable wireless communication device can perform the process.

[0324] refer to Figure 48 In step 4805, the STA can obtain the TXOP. For example, the STA's transceiver can perform any appropriate channel access procedure to obtain the TXOP.

[0325] Next, the STA can determine that at least a portion of the TXOP will not be used by the STA (step 4810). For example, the STA can determine that it will be able to complete the transmission of the service backlog it acquired in the TXOP in less than the entire duration of the TXOP. This can include scenarios where the service transmission begins at the start of the TXOP and is completed before the end of the TXOP, and scenarios where the service transmission can begin at some time after the start of the TXOP and be completed before the end of the TXOP.

[0326] Finally, the STA transfers the unused portion of the TXOP to the AP (step 4815). That is, the STA performs the TXOP transfer process as described in any of the embodiments disclosed above.

[0327] In some embodiments, the STA receives an explicit request from the AP to hand over unused portions of the TXOP. For example, prior to step 4815, the STA may receive a request message from the AP instructing the AP to use unused portions of the TXOP, in response to which the STA may hand over the unused portions of the TXOP in step 4815. This can occur when the AP determines that the STA will not use the TXOP for the entire duration.

[0328] In some such embodiments, the STA may, in response to a request message, additionally send a handover message to the AP, indicating that the STA is handing over the unused portion of the TXOP to the AP. Such a handover message may include at least one of the following: an indication of the duration for which the STA is handing over the TXOP to the AP; an indication of whether the STA expects the AP to return the TXOP after the AP has finished using it; an indication of what the STA expects the AP to do after the AP has finished using the TXOP, either to return the TXOP or to terminate the TXOP; and a request for the AP to prioritize transmitting downlink traffic to the STA during the TXOP period.

[0329] In other such embodiments, based on the fact that a request message has been sent, the AP can assume that the TXOP has been handed over after the STA's transmission is complete. That is, the STA may not explicitly respond to the request message from the AP, but the AP can assume that the STA performed a TXOP handover in response to the request message.

[0330] In some embodiments, there is an agreement between the STA and the AP to participate in the TXOP handover process, and the STA hands over the unused portion of the TXOP to the AP in accordance with the agreement. That is, the STA performs the TXOP handover at step 4815 without any signaling from the AP to initiate the handover for that particular TXOP.

[0331] In some such embodiments, prior to step 4805, a pre-arranged agreement is made based on explicit signaling between the STA and the AP. For example, before obtaining the TXOP at step 4805, the STA may receive from the AP a request message instructing the AP to request the STA's participation in the TXOP handover process. The STA may then respond to the request message by sending a response message to the AP instructing the STA to agree to participate in the TXOP handover process.

[0332] In other such embodiments, the STA can be configured to participate in the TXOP handover process under predefined conditions, i.e., a pre-defined protocol is implicitly defined in the network without any signaling between the STA and the AP. The STA can then hand over the unused portion of the TXOP to the AP based on determining that the predefined conditions are met.

[0333] In some embodiments, the TXOP handover is initiated by the STA itself. That is, the STA determines whether to hand over the unused portion of the TXOP, and based on the determination of the unused portion of the TXOP, performs the handover to the AP. In such embodiments, the STA may also send a handover message to the AP indicating the determination of the unused portion of the TXOP (e.g., so that the AP can know about the handover).

[0334] In some such embodiments, the STA can send the handover message so that other STAs can inadvertently hear it. This allows the other STAs to anticipate downlink traffic from the AP during the TXOP period based on the unintentionally heard handover message.

[0335] The flowchart above illustrates an example method or process that can be implemented according to the principles of this disclosure, and various changes can be made to the method or process shown in the flowchart. For example, although shown as a series of steps, the various steps can overlap, occur in parallel, occur in different orders, or occur multiple times. In another example, a step can be omitted or replaced by another step.

[0336] Although this disclosure has been described with reference to exemplary embodiments, various changes and modifications may be suggested to those skilled in the art. This disclosure is intended to cover such changes and modifications that fall within the scope of the appended claims. None of the descriptions in this application should be construed as implying that any particular element, step, or function is an essential element that must be included within the scope of the claims. The scope of the patent subject matter is defined by the claims.

Claims

1. A wireless site STA device, comprising: The transceiver is configured to acquire a transmission opportunity (TXOP). and A processor, operatively coupled to the transceiver, is configured to: It is determined that at least a portion of the TXOP will not be used by the STA, and The unused portion of the TXOP is transferred to the access point (AP).

2. The STA according to claim 1, wherein: The transceiver is also configured to receive from the AP a request message instructing the AP to use the TXOP, and The processor is configured to, in response to the request message, transfer the unused portion of the TXOP to the AP.

3. The STA according to claim 1 or 2, wherein, The transceiver is also configured to send a handover message to the AP in response to the request message, the handover message indicating that the STA is handing over the unused portion of the TXOP to the AP.

4. The STA according to any one of the preceding claims, wherein the handover message includes at least one of the following: Indication of the duration during which the STA is transferring the TXOP to the AP. Regarding whether the STA expects the AP to return the TXOP after the AP has finished using the TXOP, The STA expects the AP to take an instruction after the AP has finished using the TXOP to either return to the TXOP or terminate the TXOP. The AP prioritizes the transmission of downlink services to the STA during the TXOP period.

5. The STA according to any one of the preceding claims, wherein, Based on the fact that the request message has been sent, the AP believes that the TXOP should be handed over after the STA's transmission is completed.

6. The STA according to any one of the preceding claims, wherein: There is an agreement between the STA and the AP regarding pre-arranged participation in the TXOP handover process, and The processor is configured to transfer the unused portion of the TXOP to the AP in accordance with the agreement.

7. The STA according to any one of the preceding claims, wherein the transceiver is further configured to: Before obtaining the TXOP, a request message instructing the AP to request the STA to participate in the TXOP handover process is received from the AP, and In response to the request message, a response message is sent to the AP instructing the STA to agree to participate in the TXOP handover process.

8. The STA according to any one of the preceding claims, wherein: The STA is configured to participate in the TXOP handover process under predefined conditions, and The processor is configured to transfer the unused portion of the TXOP to the AP based on determining that the predefined conditions are met.

9. The STA according to any one of the preceding claims, wherein: The processor is also configured to: Determine whether to transfer the unused portion of the TXOP; and Based on the determination of the unused portion of the TXOP to be transferred, the transfer to the AP is performed, and The transceiver is also configured to send a handover message indicating the determination to the AP based on the determination of the unused portion of the TXOP to be handed over.

10. The STA according to any one of the preceding claims, wherein: The transceiver is also configured to send the handover message so that other STAs can inadvertently hear the handover message. Other STAs can anticipate downlink traffic from the AP during the TXOP period based on accidentally hearing the handover message.

11. A method performed by a wireless site (STA) device, the method comprising: TXOP (Transmission Opportunity) It is determined that at least a portion of the TXOP will not be used by the STA; and The unused portion of the TXOP is transferred to the access point (AP).

12. The method of claim 11, further comprising: Receive a request message from the AP instructing the AP to use the TXOP; and In response to the request message, the unused portion of the TXOP is transferred to the AP.

13. The method according to claim 11 or 12, wherein: There is an agreement between the STA and the AP regarding pre-arranged participation in the TXOP handover process, and The method further includes: transferring the unused portion of the TXOP to the AP according to the agreement.

14. The method according to any one of claims 11 to 13, further comprising: Before obtaining the TXOP, a request message is received from the AP instructing the AP to request the STA to participate in the TXOP handover process; and In response to the request message, a response message is sent to the AP instructing the STA to agree to participate in the TXOP handover process.

15. The method according to any one of claims 11 to 14, wherein: The STA participates in the TXOP handover process under predefined conditions, and The method further includes: transferring the unused portion of the TXOP to the AP based on the determination that the predefined conditions are met.

Images