Low latency traffic protection in wireless networks

Abstract

A first access point (AP) for facilitating communications in a wireless network. The first AP receives, from a second AP, a first request frame requesting coordination such that the first AP and one or more stations (STAs) in a basic service set (BSS) of the first AP avoid using a first resource unit (RU), where the first RU is dedicated for low latency traffic transmissions, and the first request frame includes a first duration for the coordination. The first AP sends, to the second AP, a first response frame accepting the request of the first request frame.

Description

Technical Field

[0001] This disclosure generally relates to wireless communication systems, and more specifically, for example, but not limited to, to low-latency service transmission in wireless networks. Background Technology

[0002] Since the late 1990s, Wireless Local Area Network (WLAN) technology has evolved towards higher data rates and has continued to grow in various markets such as homes, businesses, and hotspots. WLAN 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 series of standards aims to improve speed and reliability and extend the operational range of wireless networks.

[0003] There is a growing demand for WLAN devices to support a wide range of latency-sensitive or real-time applications, such as augmented reality (AR), robotics, artificial intelligence (AI), cloud computing, and autonomous vehicles. To achieve the extremely low latency and extremely high throughput required by such applications, multi-link operation (MLO) has been proposed for WLANs. A WLAN is formed by WLAN devices within a limited area such as a home, school, apartment, or office building. Each WLAN device can have one or more stations (STAs), such as access point (AP) STAs and non-access point (non-AP) STAs.

[0004] MLO enables non-AP multi-link devices (MLDs) to establish multiple links with AP MLDs. Each of these links can independently enable channel access and frame switching between the non-AP MLD and the AP MLD, which can reduce latency and increase throughput.

[0005] The fact that certain descriptions are set forth in the Background section should not be construed as prior art. The Background section may describe aspects or embodiments of this disclosure. Summary of the Invention

[0006] Solution to the problem

[0007] This disclosure may be intended to improve wireless communication systems, and more specifically, to provide mechanisms and processes for low-latency resource protection.

[0008] This disclosure provides a first access point (AP) for facilitating communication in a wireless network. The first AP includes a memory and a processor coupled to the memory. The processor is configured to: receive a first request frame from a second AP, the first request frame requesting coordination such that the first AP and one or more stations (STAs) in the first AP's basic service set (BSS) avoid using a first resource unit (RU), wherein the first RU is dedicated to low-latency service transmission, and the first request frame includes a first duration for coordination. The processor is also configured to: send a first response frame to the second AP accepting the request of the first request frame.

[0009] In one embodiment, the first request frame includes an identifier for the STA designated to use the first RU for low-latency service transmission.

[0010] In this embodiment, the first request frame is a Flow Classification Service (SCS) request frame, which includes classification information and parameters provided by one or more STAs associated with the first AP. The first response frame is an SCS response frame.

[0011] In an embodiment, the processor is further configured to: send a third request frame to the second AP, the third request frame requesting coordination so that the second AP and one or more STAs in its BSS avoid using the second RU, wherein the second RU is dedicated to low-latency service transmission. The processor is also configured to: receive a fourth response frame from the second AP accepting the request of the third request frame.

[0012] In an embodiment, the processor is further configured to: send a second request frame to one or more STAs, the second request frame requesting the one or more STAs to avoid using the first RU for a first duration. The processor is also configured to: receive a second response frame from at least one of the one or more STAs accepting the request of the second request frame.

[0013] In an embodiment, the first response frame includes a second duration for setting the network allocation vector (NAV) in the BSS of the first AP, the second duration being determined based on the first duration.

[0014] In this embodiment, the processor is further configured to: send a third response frame to the second AP in response to the first request frame, the third response frame delaying acceptance of the first request frame for a period of time. The processor is also configured to: perform communication with one or more STAs. The processor is further configured to: send a first response frame to the second AP accepting the request of the first request frame.

[0015] In one embodiment, the first request frame includes information indicating the presence of low-latency service on the first RU.

[0016] This disclosure provides a first access point (AP) for facilitating communication in a wireless network. The first AP includes a memory and a processor coupled to the memory. The processor is configured to: send a first request frame to a second AP, the first request frame requesting coordination so that the second AP and one or more STAs in its BSS (Browser Service Subsystem) avoid using a first RU (Runner Root), wherein the first RU is dedicated to low-latency service transmission. The processor is also configured to: receive a first response frame from the second AP accepting the request of the first request frame.

[0017] In one embodiment, the first request frame includes an identifier for the STA designated to use the first RU for low-latency service transmission.

[0018] In this embodiment, the first request frame is an SCS request frame, which includes classification information and parameters provided by one or more STAs associated with the first AP. The first response frame is an SCS response frame.

[0019] In an embodiment, the processor is further configured to: receive a second request frame from the second AP, the second request frame requesting coordination to prevent the first AP and one or more STAs in the first AP's BSS from using the second RU, wherein the second RU is dedicated to low-latency service transmission. The processor is also configured to: send a second response frame to the second AP accepting the request of the second request frame.

[0020] In an embodiment, the processor is also configured to send frames indicating information associated with a second RU to one or more STAs.

[0021] In an embodiment, the processor is further configured to: receive a third request frame from a STA associated with the first AP requesting an RU for low-latency service transmission. The processor is also configured to: send a third response frame to the STA associated with the first AP, the third response frame accepting the third request and allocating the first RU.

[0022] In one embodiment, the first request frame includes information indicating the presence of low-latency service on the first RU.

[0023] This disclosure provides a method performed by a first access point (AP) in a wireless network. The method includes: receiving a first request frame from a second AP, the first request frame requesting coordination such that the first AP and one or more STAs in its BSS (Broadband Service Subsystem) avoid using a first RU (Run-on Root), wherein the first RU is dedicated to low-latency service transmission, and the first request frame includes a first duration for coordination. The method further includes: sending a first response frame to the second AP accepting the request of the first request frame.

[0024] In one embodiment, the first request frame includes an identifier for the STA designated to use the first RU for low-latency service transmission.

[0025] In this embodiment, the first request frame is a Flow Classification Service (SCS) request frame, which includes classification information and parameters provided by one or more STAs associated with the first AP. The first response frame is an SCS response frame.

[0026] In one embodiment, the method further includes: sending a third request frame to the second AP, the third request frame requesting coordination so that the second AP and one or more STAs in the second AP's BSS avoid using the second RU, wherein the second RU is dedicated to low-latency service transmission. The method further includes: receiving a fourth response frame from the second AP accepting the request of the third request frame.

[0027] In one embodiment, the method further includes: sending a second request frame to one or more STAs, the second request frame requesting the one or more STAs to avoid using the first RU for a first duration. The method also includes: receiving a second response frame from at least one of the one or more STAs accepting the request of the second request frame. Attached Figure Description

[0028] Figure 1 An example of a wireless network according to an embodiment is shown.

[0029] Figure 2A shows an example of an AP according to an embodiment.

[0030] Figure 2B shows an example of a STA according to an embodiment.

[0031] Figure 3 An example of multi-link communication operation according to an embodiment is shown.

[0032] Figure 4 An example multi-AP (MAP) network with P2P groups is shown according to an embodiment.

[0033] Figure 5 An example scenario is shown according to an embodiment: when an RTA service arrives, the RU dedicated to the RTA service is occupied by the OBSS STA.

[0034] Figure 6 An example multi-AP (MAP) network with OBSS STA according to an embodiment is shown.

[0035] Figure 7 An example frame exchange is shown, according to an embodiment, by the coordinating AP utilizing an immediate response.

[0036] Figure 8 An example of stream processing using NAV according to an embodiment is shown.

[0037] Figure 9 An example frame exchange is shown, according to an embodiment, by the coordinated AP utilizing an immediate response.

[0038] Figure 10 An example of stream processing using LL requests or instructions according to an embodiment is shown.

[0039] Figure 11 An example frame exchange using a delayed response by a coordinated AP is shown according to an embodiment.

[0040] Figure 12 An example frame exchange between two APs with LL services in their respective BSSs is shown according to an embodiment.

[0041] Figure 13 An example LL negotiation process between the coordinating AP and the coordinated AP according to an embodiment is shown.

[0042] Figure 14 An example frame exchange is shown to indicate LL information to a P2P group according to an embodiment.

[0043] Figure 15 An example process for coordinating the AP-side negotiation process is shown according to an embodiment.

[0044] Figure 16 An example process for the coordinated AP-side negotiation process is shown according to an embodiment.

[0045] In one or more implementations, not all components depicted in each figure may be required, and one or more implementations may include additional components not shown in the figures. The arrangement and type of components may be varied without departing from the scope of this disclosure. Within the scope of this disclosure, additional components, different components, or fewer components may be used. Detailed Implementation

[0046] The specific embodiments described below with reference to the accompanying drawings are intended to describe various implementations and are not intended to represent only the implementations in which the subject matter can be practiced. Rather, the specific embodiments include detailed descriptions to provide a thorough understanding of the subject matter of the invention. As those skilled in the art will recognize, the described implementations can be modified in various ways without departing from the scope of this disclosure. Therefore, the drawings and descriptions should be considered illustrative rather than restrictive. The same reference numerals denote the same elements.

[0047] This disclosure relates to wireless communication systems, and more specifically to wireless local area network (WLAN) technology. WLAN 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 series of standards is designed to improve speed and reliability and extend the operational range of wireless networks.

[0048] The demand for wireless data services is rapidly increasing due to the growing popularity of smartphones and other mobile data devices such as tablets, laptops, netbooks, e-book readers, and machine-type devices among consumers and businesses. To address the ever-increasing bandwidth requirements of wireless communication systems, various solutions are being developed to allow multiple user terminals to communicate with a single access point while sharing channel resources, thus achieving high data throughput. Multiple-input multiple-output (MIMO) technology represents one approach that has become widely adopted. MIMO has been adopted by several wireless communication standards, such as 802.11ac, 802.11ax, etc.

[0049] Before proceeding with the following specific description, it may be advantageous to clarify the definitions of certain words and phrases used throughout this patent document. The term “couple” and its derivatives refer to any direct or indirect communication between two or more elements, regardless of whether these elements are physically in contact with each other. The terms “transmit,” “receive,” and “communicate,” and their derivatives encompass both direct and indirect communication. The terms “include” and “comprise,” and their derivatives imply non-restrictive inclusion. The term “or” is inclusive, meaning and / or. The phrase “associated with,” and its derivatives imply including, being included within, interconnected with, containing, being contained within, connected to or connected with, coupled to or coupled with, able to communicate with, cooperate with, interleaved, juxtaposed, proximate, combined with or combined with, having, possessing the properties of, having a relationship to, or having a relationship with, etc. The term "controller" refers to any device, system, or part thereof that controls at least one operation. Such a controller can be implemented in hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller can be centralized or distributed, whether local or remote. When the phrase "at least one of" is used with a list of items, it means that different combinations of one or more of the listed items can 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.

[0050] 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 appropriate 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, optical disc (CD), digital video disc (DVD), or any other type of storage. "Non-transitory" computer-readable media excludes wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media includes media that permanently store data as well as media that store data and subsequently rewrite data, such as rewritable optical discs or erasable storage devices.

[0051] This patent document also provides definitions for certain other words and phrases. Those skilled in the art will understand that, in many cases (if not most), such definitions apply to both prior and future use of the defined words and phrases.

[0052] The accompanying drawings discussed below, as well as the various embodiments used to describe the principles of this disclosure in this patent document, are for illustrative purposes only and should not be construed as limiting the scope of this disclosure in any way. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

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

[0054] like Figure 1 As shown, the wireless network 100 includes access points (APs) 101 and 103. APs 101 and 103 communicate with at least one network 130, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network. AP 101 provides wireless access to network 130 to multiple stations (STAs) 111-114 within its coverage area 120. APs 101-103 can communicate with each other and with STAs 111-114 using WiFi or other WLAN communication technologies.

[0055] 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 patent document to refer to a network infrastructure component that provides wireless access to remote terminals. In WLANs, since APs also compete for wireless channels, they may also be referred to as STAs. 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 device." For convenience, the terms "station" and "STA" are used in this patent document to refer to a remote wireless device that wirelessly accesses an AP or competes for a wireless channel in a WLAN, regardless of whether the STA is a mobile device (e.g., a mobile phone or smartphone) or is generally considered a fixed device (e.g., a desktop computer, AP, media player, fixed sensor, television, etc.).

[0056] exist Figure 1 In the diagram, the dashed lines indicate the approximate extent of coverage areas 120 and 125, which are shown as approximately circular for illustrative and explanatory purposes. It should be clearly understood that the coverage areas associated with the AP (e.g., coverage areas 120 and 125) may 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.

[0057] As described in more detail below, one or more APs may include circuitry and / or programming for managing MU-MIMO and OFDMA channel detection in a WLAN. 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 arranged in any suitable manner. Furthermore, AP 101 can communicate directly with any number of STAs and provide these 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).

[0058] Figure 2A illustrates an example AP 101 according to this disclosure. The embodiment of AP 101 shown in Figure 2A is for illustrative purposes only, and Figure 1AP 103 in the figure can have the same or similar configuration. However, APs have a wide variety of configurations, and Figure 2A does not limit the scope of this disclosure to any particular implementation of the AP.

[0059] As shown in Figure 2A, AP 101 includes multiple antennas 204a-204n, multiple RF transceivers 209a-209n, transmit (TX) processing circuitry 214, and receive (RX) processing circuitry 219. AP 101 also includes a controller / processor 224, a memory 229, and a backhaul or network interface 234. RF transceivers 209a-209n receive incoming RF signals from antennas 204a-204n, such as signals transmitted by STAs in network 100. RF transceivers 209a-209n down-convert the incoming RF signals to generate intermediate frequency (IF) or baseband signals. The IF or baseband signals are sent to RX processing circuitry 219, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. RX processing circuitry 219 sends the processed baseband signals to controller / processor 224 for further processing.

[0060] TX processing circuit 214 receives analog or digital data (e.g., voice data, network data, email, or interactive video game data) from controller / processor 224. TX processing circuit 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 circuit 214 and up-convert the baseband or IF signal into an RF signal transmitted via antennas 204a-204n.

[0061] The controller / processor 224 may include one or more processors or other processing devices that control the overall operation of the AP 101. For example, the controller / processor 224 may control the reception of forward channel signals and the transmission of reverse channel signals through RF transceivers 209a-209n, RX processing circuitry 219, and TX processing circuitry 214, based on known principles. The controller / processor 224 may also support additional functions, such as more advanced wireless communication capabilities.

[0062] For example, controller / processor 224 can support beamforming or directional routing operations, wherein outgoing signals from multiple antennas 204a-204n are weighted differently to effectively direct the outgoing signals in a desired direction. Controller / processor 224 can also support OFDMA operations, wherein outgoing signals are assigned to different subsets of subcarriers for different receivers (e.g., different STA111-114). Controller / processor 224 can support any of a variety of other functions in AP 101, including combining DL MU-MIMO and OFDMA in the same transmission opportunity. In some embodiments, controller / processor 224 includes at least one microprocessor or microcontroller. Controller / processor 224 is also capable of executing programs and other processes, such as an operating system, residing in memory 229. Controller / processor 224 can move data into or out of memory 229 as needed for the execution of the process.

[0063] The controller / processor 224 is also coupled to a backhaul or network interface 234. The backhaul or network interface 234 enables the AP 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(s). For example, interface 234 enables the AP 101 to communicate via a wired or wireless local area network or via a wired or wireless connection to a larger network, such as the Internet. Interface 234 includes any suitable architecture supporting communication via wired or wireless connections, such as Ethernet or an 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.

[0064] As described in more detail below, AP 101 may include circuitry and / or programming for managing the channel sounding process in a WLAN. While Figure 2A shows an example of AP 101, various changes can be made to Figure 2A. For example, AP 101 may include any number of each of the components shown in Figure 2A. As a specific example, the access point may include multiple interfaces 234, and the controller / processor 224 may support routing functionality for routing data between different network addresses. As another specific example, although shown as a single instance including TX processing circuitry 214 and a single instance including RX processing circuitry 219, AP 101 may include multiple instances of each (e.g., one instance per RF transceiver). Alternatively, only one antenna and RF transceiver path may be included, as in a conventional AP. Furthermore, the various components in Figure 2A may be combined, further subdivided, or omitted as needed, and additional components may be added.

[0065] Figure 2B illustrates an example STA 111 according to this disclosure. The embodiment of STA 111 shown in Figure 2B is for illustrative purposes only, and Figure 1 STAs 111-115 in the figure can have the same or similar configurations. However, STAs have a wide variety of configurations, and Figure 2B does not limit the scope of this disclosure to any particular implementation of the STA.

[0066] As shown in Figure 2B, STA 111 includes antenna(s) 205, radio frequency (RF) transceiver 210, TX processing circuitry 215, microphone 220, and receiver (RX) processing circuitry 225. STA 111 also includes speaker 230, controller / processor 240, input / output (I / O) interface (IF) 245, touchscreen 250, display 255, and memory 260. Memory 260 includes operating system (OS) 261 and one or more applications 262.

[0067] RF transceiver 210 receives incoming RF signals transmitted by the AP of network 100 from antenna(s) 205. 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).

[0068] TX processing circuitry 215 receives analog or digital voice data from microphone 220, or other outgoing baseband data (such as network data, email, or interactive video game data) from controller / processor 240. TX processing circuitry 215 encodes, multiplexes, and / or digitizes the output 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(s) 205.

[0069] 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 STA 111. In one such operation, the main controller / processor 240 controls the reception of forward channel signals and the transmission of reverse channel signals via RF transceiver 210, RX processing circuitry 225, and TX processing circuitry 215 according to known principles. The main controller / processor 240 may also include processing circuitry configured to provide management of the channel probing process in the WLAN. In some embodiments, the controller / processor 240 includes at least one microprocessor or microcontroller.

[0070] The controller / processor 240 is also capable of executing other processes and programs residing in the memory 260, such as operations for managing channel sounding processes in the WLAN. The controller / processor 240 can move data into or out of the memory 260 as needed for the execution of processes. In some embodiments, the controller / processor 240 is configured to execute multiple applications 262, such as applications for channel sounding, including feedback calculations based on received Null Data Packet Announcements (NDPA) and Null Data Packets (NDP), and sending beamforming feedback reports in response to trigger frames (TF). The controller / processor 240 can run 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 STA 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.

[0071] The controller / processor 240 is also coupled to the touchscreen 250 and the display 255. The operator of STA 111 can use the touchscreen 250 to input data into STA 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 (e.g., graphics from a website). Memory 260 is coupled to the controller / processor 240. A portion of memory 260 may include random access memory (RAM), and another portion of memory 260 may include flash memory or other read-only memory (ROM).

[0072] While Figure 2B shows one example of STA 111, various changes can be made to Figure 2B. For example, various components in Figure 2B can be combined, further subdivided, or omitted as needed, and additional components can be added. In a specific example, STA 111 may include any number(s) of antennas 205 for MIMO communication with AP 101. In another example, STA 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 shows STA 111 configured as a mobile phone or smartphone, STA can be configured to operate as other types of mobile or fixed devices.

[0073] As shown in Figure 2B, in some embodiments, STA 111 may be a non-AP MLD comprising multiple STAs 203a-203n. Each STA 203a-203n is attached to the non-AP MLD 111 and includes antenna(s) 205, RF transceiver 210, TX processing circuitry 215, and RX processing circuitry 225. Each STA 203a-203n can communicate independently with the controller / processor 240 and other components of the non-AP MLD 111. Figure 2B shows each STA 203a-203n having a separate antenna, but each STA 203a-203n can share antenna 205 without separate antennas. Each STA 203a-203n can represent the physical (PHY) layer and the underlying media access control (MAC) layer.

[0074] Figure 3 An example of multi-link communication operation according to an embodiment is shown. Multi-link communication operation can be used in the IEEE 802.11be standard and any future revisions to the IEEE 802.11 standard. Figure 3 In the middle, AP MLD 310 can be Figure 1 Wireless communication devices 101 and 103, and non-AP MLD 220 can be Figure 1 One of the wireless communication devices 111-114 in the series.

[0075] like Figure 3As shown, AP MLD 310 may include multiple auxiliary APs, such as AP 1, AP 2, and AP 3. Each auxiliary AP may include a PHY interface to the wireless medium (Link 1, Link 2, or Link 3). AP MLD 310 may include a single MAC Service Access Point (SAP) 318, through which the auxiliary APs of AP MLD 310 communicate with higher layers (Layer 3 or network layer). Each auxiliary AP of AP MLD 310 may have a different MAC address (lower-layer MAC address) than any other auxiliary AP of AP MLD 310. AP MLD 310 may have an MLD MAC address (upper-layer MAC address), and the auxiliary APs share the single MAC SAP 318 to Layer 3. Therefore, the auxiliary APs share a single IP address, and Layer 3 identifies AP MLD 310 by assigning this single IP address.

[0076] A non-AP MLD 320 may include multiple affiliated STAs, such as STA 1, STA 2, and STA 3. Each affiliated STA may include a PHY interface to the wireless medium (Link 1, Link 2, or Link 3). A non-AP MLD 320 may include a single MAC SAP 328, through which affiliated STAs communicate with higher layers (Layer 3 or network layer). Each affiliated STA of a non-AP MLD 320 may have a different MAC address (lower-layer MAC address) than any other affiliated STA of the non-AP MLD 320. A non-AP MLD 320 may have an MLD MAC address (upper-layer MAC address), and affiliated STAs share the single MAC SAP 328 to Layer 3. Therefore, affiliated STAs share a single IP address, and Layer 3 identifies the non-AP MLD 320 by assigning this single IP address.

[0077] The AP MLD 310 and non-AP MLD 320 can establish multiple links between their associated APs and STAs. In this example, AP 1 and STA 1 can establish Link 1, operating in the 2.4 GHz band. Similarly, AP 2 and STA 2 can establish Link 2, operating in the 5 GHz band, and AP 3 and STA 3 can establish Link 3, operating in the 6 GHz band. Each link can independently enable channel access and frame switching between the AP MLD 310 and the non-AP MLD 320, which can improve throughput and reduce latency. When associated with an AP MLD (link establishment) on a set of links, each non-AP device is assigned a unique Association Identifier (AID).

[0078] The following documents are incorporated herein by reference in their entirety, as if fully set forth herein: i) IEEE 802.11-2020, “Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specification”; ii) IEEE 802.11ax-2021, “Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specification”; and iii) IEEE P802.11be / D5.0, “Part 11: Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) Specification – Revision 8: Ultra High Throughput (EHT) Enhancement”.

[0079] In infrastructure wireless LAN networks, a Basic Service Set (BSS) typically refers to a network topology that includes an Access Point (AP) or AP Modem (MLD) and all non-AP devices associated with that AP or AP MLD. The BSS defines the operational bandwidth, which indicates the frequency resources available for transmission by devices belonging to the BSS, and defines the rules for how BSS devices compete for that operational bandwidth. Specifically, a wireless LAN network BSS defines one of its 20 MHz channels within its operational bandwidth as the primary channel, and any device in that BSS is allowed to initiate transmission if the primary channel is sensed to be idle (IDLE) after performing the required random backoff. Transmission is typically limited to this primary 20 MHz, and the duration of transmission is called the Transmission Opportunity (TXOP) duration. However, if any non-primary channel of the BSS (such as a 20 MHz channel within the operational bandwidth but not a primary channel) is also sensed to be idle for the Priority Inter-Frame Spacing (PIFS) duration prior to the start time of the wireless LAN network device's transmission opportunity on the primary channel, then that device can also transmit on that non-primary channel. This mechanism is called channel bonding and is further enhanced by the concept of preamble puncturing.

[0080] For any channel, whether primary or secondary, wireless LAN network devices employ two channel sensing mechanisms to detect channel status. The channel status is determined as idle / busy. The first sensing mechanism is preamble detection, where the wireless LAN network device determines the 20 MHz channel as busy if it successfully detects a preamble with received power higher than -82 dBm. The second sensing mechanism is power detection, where the wireless LAN network device determines the 20 MHz channel as busy if it senses any power higher than -62 dBm on the 20 MHz channel. When neither preamble detection nor power detection determines the 20 MHz channel as busy, the wireless LAN network device determines the 20 MHz channel as idle.

[0081] Recent discussions surrounding the latest generation WiFi standard, IEEE 802.11bn, have focused heavily on reducing channel access latency for low-latency services required by real-time applications (RTAs). In fact, the PARs approved by IEEE 802.11bn aim to define at least one mode of operation that improves latency distribution tails and jitter compared to extremely high-throughput MAC / PHY operations. The growing RTA demands in 11bn necessitate lower latency. Therefore, more stringent requirements are needed to meet the needs of new applications such as metaverse, augmented and virtual reality, robotics, industrial automation for the Industrial Internet of Things, logistics, and smart agriculture. Lower latency will lead to a better customer experience, especially where latency / jitter is critical. Low-latency communication has become increasingly important, forming a fundamental building block of RTAs. For example, as shown in Table 1, some use cases require latency of at least 5 ms and jitter of less than 2 ms.

[0082] Table 1 shows the characteristics of low-latency services in the use cases.

[0083] [Table 1]

[0084]

[0085] The need to deliver low-latency services as quickly as possible to support RTA STA stems from the negative impact of high latency on RTA services in the current network. For example, an ongoing PHY Protocol Data Unit (PPDU) can reach its maximum duration, such as aPPDUMaxTime lasting 5.484 ms. If an RTA service fails to compete for a Resource Unit (RU), this can severely delay the earliest time when low-latency services can be delivered.

[0086] Figure 4 An example multi-AP (MAP) network with P2P groups is shown according to an embodiment. Figure 4 The MAP network depicted is used for explanatory and illustrative purposes. Figure 4 This disclosure is not intended to limit the scope to any particular implementation.

[0087] Reference Figure 4The MAP network includes coordinated AP1 and AP2. AP1 is a shared AP. AP2 is a shared AP. Two STAs (STA1 and STA2) are associated with AP1. STA1 is a latency-tolerant STA, while STA2 is a low-latency (LL) STA or RTA STA. STA3 is associated with AP2. A peer-to-peer (P2P) group exists nearby, and one of the peering STAs can also have P2P traffic with STA3. To reduce latency for RTA traffic, a dedicated RU specifically for LL can be assigned to STA2. AP1 can schedule the dedicated RU and / or piggyback on ongoing traffic with STA1.

[0088] A key issue is that when no signal is transmitted on a reserved RU before the RTA traffic reaches the buffer, the dedicated RU may be occupied by other STAs, who may not be aware that these RUs were reserved for the RTA. Overlapping BSS (OBSS) STAs or P2P groups may occupy dedicated RUs without knowing about the reservation. Through channel bonding and preamble puncturing, OBSS STAs may observe that these RUs are idle and include them in their own transmissions. P2P groups may also sense the channel and make it a potential off-channel for channel switching. This is likely to happen because BSSs often lose synchronization and use energy detection instead of preamble detection to perform inter-BSS backoff. Using energy detection, adjacent BSSs cannot set the Network Assignment Vector (NAV) for transmission and may therefore occupy a reserved 20 MHz of idle channel.

[0089] Figure 5 An example scenario is shown according to an embodiment: when an RTA service arrives, the RU dedicated to the RTA service is occupied by the OBSS STA. Figure 5 The scenes depicted are for explanatory and illustrative purposes. Figure 5 This disclosure is not intended to limit the scope to any particular implementation.

[0090] Reference Figure 5 The Time-Frequency Resource Unit (TFRU) comprises a RU in the lower half of the TFRU designated for regular transmission, and a dedicated RU in the upper half reserved for RTA services. When an RTA service arrives, the dedicated RU is occupied by the OBSS STA, resulting in a delay in the RTA service.

[0091] A solution is needed to protect the dedicated RU from being occupied by the OBSS STA from RTA services.

[0092] When acquiring channel resources, wireless LAN network devices (such as access points) can reserve a portion of their bandwidth for transmitting low-latency services to and / or receiving from the RTA device. This reserved bandwidth can be discontinuous and can comprise multiple RUs, which can be referred to as Low Latency Resource Units (LL-RUs).

[0093] In an embodiment, the AP in the MAP architecture can also be a non-co-located AP, where one or more APs can be logical entities.

[0094] In an embodiment, the sharing AP can be a coordinating AP used to schedule LL requests, and the shared AP can be a coordinated AP used to respond to LL requests.

[0095] In an embodiment, the shared AP can be a coordinating AP used to schedule LL requests, and the sharing AP can be a coordinating AP used to respond to LL requests.

[0096] In an embodiment, the coordinating AP that can schedule LL requests can send notifications or make instructions to the coordinated APs about the LL-RU, so that other coordinated APs and their BSSs can avoid using the LL-RU.

[0097] Figure 6 An example multi-AP (MAP) network with OBSS STA according to an embodiment is shown. Figure 6 The MAP network depicted is used for explanatory and illustrative purposes. Figure 6 This disclosure is not intended to limit the scope to any particular implementation.

[0098] Reference Figure 6 The MAP network includes coordinated AP1 and AP2. AP1 is a shared AP. AP2 is a shared AP. Two STAs (STA1 and STA2) are associated with AP1. STA1 is a latency-tolerant STA, while STA2 is a low-latency (LL) STA or RTA STA. STA3 and STA4 are associated with AP2. STA3 and STA4 are OBSS STAs. A dedicated RU can be reserved for STA2 for LL traffic. If the dedicated RU is idle for too long, either STA3 or STA4 can occupy the dedicated RU.

[0099] In an embodiment, the coordinating AP can send LL-RU request frames to other coordinated APs. The LL-RU request frame may include RUs reserved for LL purposes, reserved AID12 subfields for the User Info field of LL STAs, etc., as shown in Table 2. LL-RUs may be new reserved RUs with new association identifiers (AIDs). They may also be RUs for which no STA has been assigned.

[0100] Table 2 shows the information items in the LL-RU request frame.

[0101] [Table 2]

[0102]

[0103] In one embodiment, the coordinating AP may have LL service and intend to send to the RTA STA on the LL-RU. In another embodiment, the AP may receive LL requests from the RTA STA. In yet another embodiment, the AP may instruct the use of the LL-RU within one or more TXOPs or service periods (SPs).

[0104] The new LL-RU request frame may consider one or more of the fields mentioned above. The User Info List may include one or more RTA STAs with reserved AID12. RU allocation may include RUs that the RTA STA can support. The LL-RU request frame may also consider integrating one or more elements from the Stream Classification Service (SCS) frame (such as User Priority (UP) or intra-class Category PriorityElement) to indicate the priority of the RTA STA's services.

[0105] In embodiments, the main information elements of the LL-RU request frame (e.g., LL information elements) may be incorporated into management frames such as beacon, probe, and (re)association frames. In embodiments, the information may be incorporated into control frames such as MU-RTS frames.

[0106] In an embodiment, the main information elements of the LL-RU request frame may be considered in a portion of the SCS frame or as a whole of the SCS frame.

[0107] In this embodiment, SCS frame coordination between APs is as follows: An SCS is a service that an AP can provide to its associated STAs that support the SCS. In the SCS, the AP classifies incoming separately addressed Media Access Control (MAC) Service Data Units (MSDUs) based on parameters provided by non-AP STAs. Coordination of Quality of Service (QoS) elements between APs can be sent via Restricted Target Wake-Up Time (R-TWT) or Coordination TWT. In the coordinated SCS between APs, the coordinated SCS (C-SCS) is a service that a coordinating AP can provide to nearby coordinated APs that support the C-SCS. In the C-SCS, the coordinated AP classifies incoming separately addressed MSDUs based on parameters provided by the coordinating AP. Furthermore, the C-SCS includes information and parameters provided by non-AP STAs associated with the coordinating AP.

[0108] In an embodiment, TWT-based LL-RU protection can be considered. During the TWT SP period, LL-RUs can be reserved for LL services. LL-RU reservation can be provided by a trigger-based TWT that includes a modified RARU specifically for LL services.

[0109] In an embodiment, the new SCS descriptor element may require the coordination AP to exchange and negotiate C-SCS request frames and C-SCS response frames within the QoS requirements of the coordinating AP. In an embodiment, the BSSID for each BSS in the coordinated AP and the coordinating AP's BSS may need to be included in the C-SCS frames, such as C-SCS request frames and C-SCS response frames, which are variations of the SCS request and response frames. In an embodiment, the bits of the C-SCS BSSID may also be included in the SCS descriptor list in the SCS request frame. A new Direction field in the ControlInfo field of the QoS Characteristics element of the SCS descriptor element may include an uplink from the coordinating AP to the coordinated AP, a downlink from the coordinated AP to the coordinating AP, or a direct link where MSDUs or A-MSDUs are transmitted via a peer-to-peer link (such as soft AP to soft AP).

[0110] In this embodiment, a C-SCS frame with LL-RU is defined between APs. One or more information items from Table 2 may be included in the C-SCS frame. In this embodiment, LL information may be included in a C-SCS request frame sent from the coordinating AP to the coordinating AP.

[0111] LL information can be included in the QoS feature element field, which can be included in the SCS procedure or the restricted TWT. In an embodiment, LL information can be considered in the control information field of the QoS feature element field, where reserved bits can be assigned to LL-RUs reserved for RTA STAs.

[0112] In an embodiment, when there are two or more APs, the coordinating AP can send a request frame with LL information elements to each AP, and each coordinated AP can respond to the corresponding AP. In an embodiment, the coordinated AP can broadcast a beacon with LL information elements to all APs during the coordination phase.

[0113] When the coordinating AP acquires a TXOP, it can send a request frame to (or more) coordinated APs. This frame may contain information such as the dedicated RU, AID, and time duration that an RTA STA might require. After the coordinating AP has sent its request to the coordinated APs and the coordinated APs have sent their responses, thus establishing an agreement, the coordinated APs can take actions to notify their own BSS, thereby propagating the LL information request to other BSSs. Specifically, this propagation reaches OBSS STAs, which may have the opportunity to use idle LL-RUs if no indication that an RU is held.

[0114] In this embodiment, the coordinating AP can implicitly or explicitly notify the coordinated AP of the presence of LL service. For example, the coordinating AP can notify the coordinated AP RTA STA of the presence of LL service by indicating the presence of LL service in an LL-RU request frame. The LL-RU request frame can be located on the same channel as its associated AP, or on any primary or secondary channel.

[0115] In an embodiment, when the coordinated AP agrees to avoid using LL-RU and prevent the OBSS STA from using LL-RU, it does not need to notify its BSS by sending a specific frame; it can send a response frame with NAV settings. The response frame can be a clear-to-send (CTS) frame.

[0116] By responding to the coordinating AP, (multiple) coordinating APs may need to set up NAV for their own BSS to protect TXOP and LL-RU from being used. Figure 7 An example is shown. In this embodiment, the response frame may be a CTS frame.

[0117] Figure 7 An example frame exchange is shown, according to an embodiment, by the coordinating AP utilizing an immediate response. Figure 7 The frame switching described herein is for explanatory and illustrative purposes. Figure 7This disclosure is not intended to limit the scope to any particular implementation.

[0118] Reference Figure 7 AP1 acquires a TXOP on the radio medium. AP1 then sends an LL-RU request frame (LL-RU request (LL-RU req.)) to AP2, requesting AP2 to avoid using the LL-RU and prevent OBSS STAs from using the LL-RU. In some aspects, the LL-RU can be dedicated to STA 2 in AP1's BSS. In response, AP2 sends an LL-RU response frame (Resp.) to AP1, instructing AP2 to accept AP1's request. AP2 then sets the NAV for its BSS so that STA3 and STA4 do not occupy the LL-RU reserved for STA2's LL service. In some aspects, the LL-RU response frame includes a duration field indicating duration information. Upon receiving the LL-RU response frame, STA 3 and STA 4 in AP2's BSS can set or update their NAV timers based on the duration information indicated in the LL-RU response frame. The LL-RU response frame can be a CTS frame.

[0119] Stream processing between the client and the AP, such as Figure 8 As shown. Phase 0 is the negotiation phase in BSS1, where client A can send an LL request frame to its AP. In an embodiment, an AP can initiate coordination between multiple APs. In an embodiment, an AP can preemptively reserve the LL-RU. If the AP chooses to use the MAP method, then phase 1 is considered.

[0120] Figure 8 An example of stream processing using NAV according to an embodiment is shown. Figure 8 The stream processing described herein is for explanatory and illustrative purposes. Figure 8 This disclosure is not intended to limit the scope to any particular implementation.

[0121] Reference Figure 8 There are two STAs, STA2 (client A) and STA3 (client B), and two APs, AP1 and AP2. STA2 is an RTA STA with LL transmission. STA2 is associated with AP1, and STA3 is associated with AP2. AP1 is the coordinating AP, and AP2 is the coordinated AP. There are two phases, phase 0 and phase 1.

[0122] In Phase 0, STA2 and AP1 negotiate STA2's LL transmission request. STA2 sends a first LL request frame (LL request transmission) to AP1, requesting AP1 to support STA2's LL transmission. The LL request frame can be, for example, a Flow Classification Service (SCS) request or a Quality of Service (QoS) element. AP1 processes the LL request from STA2 and enters Phase 1 to request nearby APs to prevent OBSS STAs from using the LL-RU reserved for STA2's LL transmission. After AP1 has completed Phase 1, AP1 sends a first LL response frame (LL response transmission) to STA2, instructing AP1 to accept STA2's LL request.

[0123] In Phase 1, negotiation exists between AP1 and AP2. More than one AP can be coordinated. AP1 sends a second LL request frame (LL Request for Client A) to AP2, requesting AP2 to agree to avoid using and prevent the OBSS STA from using the LL-RU for the Phase 0 LL request. The second LL request frame can take the form of, for example, a Coordinated SCS (C-SCS) request, a QoS element, or a Coordinated Restricted Target Wake-Up Time (CR-TWT). In response, AP2 sets the NAV value for STA3 to prevent STA3 from using the LL-RU for the specified duration associated with the second LL request frame. Subsequently, AP2 sends a second LL response frame (LL Response for Client) to AP1, instructing AP2 to accept AP1's request. The second LL response frame can take the form of a C-SCS response, a QoS element, or a CR-TWT. AP2 can set the NAV value for STA3 via a third LL request frame or an indication frame. In response to the third LL request frame or indication frame, STA3 can send a third LL response frame or an acknowledgment frame to AP2.

[0124] In this embodiment, the coordinated AP may not schedule any service on the LL-RU for any STA in the subsequent TXOP or SP suggested in the LL request frame. The coordinated AP has committed in its LL response to the LL request frame to avoid and prevent OBSS STAs from using the LL-RU.

[0125] In an embodiment, the coordinated AP can also notify associated STAs to avoid occupying the LL-RU by sending an LL indication frame. The indication frame may include one or more of the information items described above, such as those in Table 2. In an embodiment, the LL-RU indication frame may include the BSSID from the coordinated BSS and the AID of the RTA STA (e.g., STA2), so that the STA associated with AP2 can be aware of the RTA STA with the LL request.

[0126] In this embodiment, the STA associated with the coordinated AP can respond to the request. The coordinated AP can send a response to the requested AP or the coordinating AP regarding the receipt of an LL-RU request frame. The response frame can contain information such as the status code ACCEPT or DECLINE. A response frame with ACCEPT or AGREE indicates that the STA is aware of one or more of the following: LL-RU, AID of an RTA STA, or location information of an RTA STA.

[0127] In an embodiment, the coordinated AP may send an immediate response to the coordinating AP regarding the receipt of an LL-RU request frame. The immediate response frame may include information such as the status code ACCEPT or DECLINE. A response frame with ACCEPT or AGREE indicates that the coordinated AP is aware of one or more of the following: the LL-RU, the ID of the RTA STA, or the location of the RTA STA. A response frame with the code DECLINE indicates that the coordinated AP may not be willing to accept the coordinating AP's request. Reasons could include: the coordinated AP will also use the same RU for one or more OBSS STAs or legacy STAs in its BSS for another purpose during the next or upcoming service period; or the coordinated AP has not yet established coordination with the coordinating AP and does not recognize the frame; or the coordinated AP cannot guarantee that all associated STAs will also accept the request. The coordinated AP does not need to guarantee that all associated STAs will prevent the use of the LL-RU.

[0128] In this embodiment, the coordinated AP can avoid using different time / frequency resources by scheduling them accordingly. If necessary, the coordinated AP can perform channel handover or coordinated spatial multiplexing (CSR) on the RU.

[0129] In an embodiment, the coordinated AP may send a delayed response frame to the coordinating AP. The delayed response frame may include information such as the status code DELAY, HOLDING, or PENDING. The delayed response can provide an estimated time for negotiation or notification between the coordinated AP and its associated STA. During the hold period indicated in the hold response frame, the coordinated AP may check with its associated STA to confirm the LL request. The coordinated AP may confirm and process the request with its associated STA, and then respond to the coordinating AP.

[0130] In this embodiment, the coordinated AP can guarantee or provide that its associated STA does not need to use LL-RU.

[0131] When the coordinating AP coordinates information about the LL-RUs to be used with the coordinated AP, the coordinated AP can respond immediately in Phase 1. The coordination between the coordinating AP and the coordinated AP in Phase 1 can occur periodically or aperiodically. The coordinated AP can broadcast RUs that will be used for LL service purposes. In an embodiment, the coordinated AP can also notify STA3 of LL-RUs reserved by the coordinating AP for the RTA STA.

[0132] Figure 9 An example frame exchange is shown, according to an embodiment, by the coordinated AP utilizing an immediate response. Figure 9 The frame switching described herein is for explanatory and illustrative purposes. Figure 9 This disclosure is not intended to limit the scope to any particular implementation.

[0133] Reference Figure 9 AP 1 and AP 2 participate in multi-AP (MAP) coordination. AP 1 is the coordinating AP, and AP 2 is the coordinated AP. AP 1 is associated with STA 2 as an RTA STA. AP 2 is associated with STA 3 as an OBSS STA.

[0134] In Phase 1, AP1 sends an LL-RU request frame (LL-RU request (LL-RU req.)) to AP2, requesting AP2 to avoid using LL-RU and prevent the OBSS STA from using LL-RU, and identifying the LL-RU used for transmission. In response, AP2 sends a response frame (response (Resp.)) to AP1, instructing AP2 to accept AP1's request.

[0135] Subsequently, in phase 2, AP2 sends an LL-RU indication frame (LL-RUInd.) to STA3 in AP2's BSS, requesting STA3 to avoid using the LL-RU identified in the LL-RUInd. frame. In response, STA3 sends an acknowledgment frame (Conf.) to AP2 to confirm AP2's request.

[0136] Stream processing between the client and the AP, such as Figure 10 As shown. Phase 0 is the negotiation phase in BSS1, where client A (STA2) can send an LL request frame to the coordinating AP (AP1). In one embodiment, AP1 can initiate coordination between multiple APs. In another embodiment, AP1 can preemptively reserve the LL-RU. AP1 can enter Phase 1 when it chooses to use the MAP method described below. Similarly, when AP2 accepts AP1's LL request, the coordinating AP (AP2) can enter Phase 2 after receiving the LL request frame from AP1.

[0137] Figure 10 An example of stream processing using LL requests or instructions according to an embodiment is shown. Figure 10 The stream processing described herein is for explanatory and illustrative purposes. Figure 10 This disclosure is not intended to limit the scope to any particular implementation.

[0138] Reference Figure 10 There are two STAs, STA2 (client A) and STA3 (client B), and two APs, AP1 and AP2. STA2 is an RTA STA with LL transmission. STA3 is associated with AP2. STA2 and AP1 form BSS1, and STA3 and AP2 form BSS2. AP1 is the coordinating AP, and AP2 is the coordinated AP. There are three phases: Phase 0, Phase 1, and Phase 2.

[0139] In Phase 0, negotiation exists between STA2 and AP1 regarding STA2's LL transmission request. STA2 sends a first LL request frame (LL request transmission) to AP1, requesting AP1 to support STA2's LL transmission. The first LL request frame can take the form of, for example, an SCS request or a QoS element. AP1 processes the LL request from STA2 and enters Phase 1 to request nearby APs to prevent OBSS STAs from using the LL-RU reserved for STA2's LL transmission. After AP1 has completed Phase 1, AP1 sends a first LL response frame (LL response transmission) to STA2, instructing AP1 to accept STA2's LL request.

[0140] In Phase 1, negotiation exists between AP1 and AP2. More than one AP can be coordinated. AP1 sends a second LL request frame (LL Request for Client A) to AP2, requesting AP2 to avoid using LL-RU and prevent OBSS STAs from using LL-RU. The second LL request frame can take the form of, for example, a C-SCS request, a QoS element, or a CR-TWT. In response, AP2 enters Phase 2 to request STA3 not to use LL-RU. After AP2 has completed Phase 2, AP2 sends a second LL response frame (LL Response for Client) to AP1, instructing AP2 to accept AP1's request. The second LL response frame can take the form of, for example, a C-SCS response, a QoS element, or a CR-TWT.

[0141] In Phase 2, AP2 sends a third LL request frame or indication frame from BSS1 to STA3, requesting STA3 to avoid using the LL-RU identified in the third request frame or indication frame. In response, STA3 sends an LL response frame to AP2, agreeing not to use the LL-RU used by STA2. Alternatively, STA3 may send an acknowledgment frame to AP2, agreeing not to use the LL-RU.

[0142] LL-RU reservation or protection can be configured for long-term reservation or protection, for example, by setting the RU to LL-RU specific. Operations for non-LL services can exclude the RU by indicating information that it is not in use, such as setting a bit in the Disabled Subchannel Bitmap subfield bitmap to 1 to indicate that the LL-RU is punched.

[0143] In this embodiment, the coordinated AP can respond to the coordinating AP after phase 2 is completed. A third phase, either phase 3 or a pending phase 1, is then considered. The coordinating AP can send an LL-RU, prompting the coordinated AP to respond with a delayed response in which the coordinated AP agrees to support the LL transmission of STA2. When STA3 responds to the coordinated AP with an acceptance response to the LL-RU indication, the coordinated AP subsequently responds to the coordinating AP with an acceptance response. The stream processing in this embodiment is as follows: Figure 10 As shown, this includes phases 1, 2, and 3, as follows: Figure 10 As shown in the example.

[0144] In this embodiment, a delayed response frame or a response frame with a hold requirement is sent during phase 1. The delayed response frame may include information such as the status code DELAY, HOLDING, or PENDING. The delayed response frame may include a configured timeout, i.e., the maximum time required for the coordinating AP to receive the response frame. Otherwise, a retransmission may be necessary. The retransmission time may also be limited. This frame may extend the expiration time of the coordinating AP's response frame.

[0145] In this embodiment, the delayed response frame may also be an ACK frame, which indicates an extended wait or delay in responding to the coordinating AP, or it may be an implicit ACK constructed in the PHY header of the LL-RU indication frame. Once the coordinating AP receives a delayed response frame including an explicit ACK or an implicit ACK, the coordinating AP will extend the expiration time for receiving the response frame.

[0146] In this embodiment, a response frame is sent in phase 3. This response frame can provide a final decision from the coordinated AP and its associated STAs, allowing them to avoid using the LL-RU at the request of the coordinating AP. Information items such as those in Table 2 can be considered. If multiple STAs or multiple coordinated APs agree to avoid using the LL-RU, multiple User Info Lists are required. In this embodiment, the response frame may also include STAs and APs that may not support information such as the user's AID or reason code.

[0147] In an embodiment, the coordinating AP may request only the OBSS STA to avoid using the LL-RU, thereby interfering with the coordinating AP's BSS LL requirement for resources. The request and response frames may include only information about the OBSS STA (such as STA3). This information may include one or more items, such as the STA's AID, BSSID, or RSSI.

[0148] In one embodiment, an LL-RU acknowledgment frame is sent. This acknowledgment frame, from the coordinated AP to the coordinating AP, confirms information about the supported STA and the coordinated AP.

[0149] In a current-phase implementation based on 11bn, coordination between APs can also occur during the backhaul, where phases 1 and 3 can take place via wired connections. However, negotiation between the coordinated AP and its associated STA needs to be performed wirelessly.

[0150] Figure 11 An example frame exchange using a delayed response by a coordinated AP is shown according to an embodiment. Figure 11 The frame switching described herein is for explanatory and illustrative purposes. Figure 11 This disclosure is not intended to limit the scope to any particular implementation.

[0151] Reference Figure 11 AP1 and AP2 participate in MAP coordination. AP1 is the coordinating AP, and AP2 is the coordinated AP. AP1 is associated with STA2 as an RTA STA. AP2 is associated with STA3 as an OBSS STA.

[0152] In Phase 1, AP1 sends an LL-RU request frame (LL-RY request (LL-RU req.)) to AP2, requesting AP2 to avoid using the LL-RU and prevent the OBSS STA from using the LL-RU, and identifying the LL-RU used for transmission. In response, AP2 sends a response frame (Resp. For holding) to AP1, indicating that AP2 does not reject the request, but needs a period of time to respond. The response frame may include the time period during which AP2 responds.

[0153] In Phase 2, AP2 sends an LL-RU broadcast frame to STA3, instructing STA3 to avoid using the LL-RU identified in the LL-RU request. Phase 2 can end without AP2 sending an LL broadcast frame when the time period indicated in Phase 1 expires.

[0154] In Phase 3, which is a continuation of Phase 1, AP2 sends a response frame (Resp.) to AP1, indicating that AP2 agrees to avoid using LL-RU and prevent the OBSS STA from using LL-RU. In response, AP1 sends an LL-RU acknowledgment frame (LL-RU conf.) to AP2.

[0155] In this embodiment, the coordinated AP and the coordinating AP can share dedicated LL-RU information for the RTA STA between their BSSs. In this case, the LL STA can utilize multiple LL-RUs.

[0156] In this embodiment, the coordinated AP and the coordinating AP can perform a negotiation process that includes LL-RU information sharing. Figure 6 In this context, STA3 can also be an RTA STA. If STA3 is an RTA STA, AP1 and AP2 can negotiate LL-RU information based on the needs in their respective BSSs, and each BSS will respect the other BSSs. For example, AP1 assigns RU1 to STA2 (RTA STA), and AP2 assigns RU2 to STA3 (RTA STA). The two APs share this information and are aware of the LL-RUs. Figure 12Consider the following example of frame switching. AP1 has an LL request from its own BSS and sends an LL-RU request frame to AP2. AP2 also has an LL request, so it responds to AP1 and adds its own LL request to the response frame. AP1 receives the LL-RU response frame and acknowledges the coordination.

[0157] Figure 12 An example frame exchange between two APs with LL services in their respective BSSs is shown according to an embodiment. Figure 12 The frame switching described herein is for explanatory and illustrative purposes. Figure 12 This disclosure is not intended to limit the scope to any particular implementation.

[0158] Reference Figure 12 AP1 and AP2 participate in MAP negotiation. AP1 is the coordinating AP, and AP2 is the coordinated AP. AP1 is associated with STA2, which is an RTA STA. AP2 is associated with STA3, which is an RTA STA.

[0159] During MAP negotiation, AP1 sends an LL negotiation request frame to AP2, requesting AP2 to avoid and prevent the OBSS STA from using the LL-RU for STA2. In response, AP2 sends an LL negotiation response frame to AP1, indicating that AP2 agrees to avoid and prevent the OBSS STA from using the LL-RU for STA2 and the LL request for STA3. In response, AP1 sends an LL negotiation confirmation frame to AP2, indicating that AP1 agrees to avoid and prevent the OBSS STA from using the LL-RU for STA3.

[0160] After the MAP negotiation ends, AP1 sends a Co-LL-RU Info Indication Frame (Co-LL-RU Info ind.) to STA2, indicating that AP1 agrees to support STA2's LL transmission and the existence of STA3's LL request. AP2 sends a Co-LL-RU Info Indication Frame (Co-LL-RU Info ind.) to STA3, indicating that AP2 agrees to support STA3's LL transmission and the existence of STA2's LL request.

[0161] In an embodiment, the coordinating AP may send LL negotiation request frames to other coordinated APs. The LL-RU request frame may include RUs reserved for LL purposes, similar to the RUs shown in Table 2. In an embodiment, the LL negotiation request frame may also include some information items shown in Table 3. For example, user priority (UP), preemption capability, or preemption enabled fields.

[0162] [Table 3]

[0163]

[0164] In this embodiment, the coordinated AP can respond to AP1 in an LL negotiation response frame. The LL negotiation response frame may also include information from Table 3, so the AP can compare UPs and assign LL-RUs to the most urgent services. If UPs from different BSSs are the same, contention-based or preemption-based approaches can be considered when LL-RUs and LL TXOPs completely overlap.

[0165] In an embodiment, the coordinated AP and the coordinating AP can select a common RU for LL-RU purposes, and the coordinated AP can select an RU from the LL RU list and use it as a common LL-RU.

[0166] In this embodiment, the acknowledgment negotiation frame from the coordinating AP to the coordinated AP is used to confirm the UP and preemption capabilities, RU information, or common RU shown in Table 3.

[0167] Figure 13 An example LL negotiation process between the coordinating AP and the coordinated AP according to an embodiment is shown. Figure 13 The negotiation process described herein is used for explanation and illustration purposes. Figure 13 This disclosure is not intended to limit the scope to any particular implementation.

[0168] Reference Figure 13AP1 and AP2 perform MAP negotiation. AP1 is the coordinating AP, and AP2 is the coordinated AP. AP1 and AP2 have BSSs with LL requirements. AP1 sends an LL negotiation request frame to AP2, requesting AP2 to avoid using and prevent the OBSS STA from using AP1 to determine the LL-RU for its BSS's LL requirements. The LL negotiation request frame may include information indicating the operational LL RU, the LL RU list, user priority, and preemption capability. The operational LL RU is the LL-RU for AP1's BSS's LL requirements. The LL RU list includes multiple LL-RUs that can be used for the LL requirements. User priority indicates the priority of AP1's BSS on the LL-RU. Preemption capability indicates that preemption on the LL-RU is possible. In response, AP2 sends an LL negotiation response frame to AP1, accepting AP1's request and indicating that AP2 needs LL-RUs for its BSS's LL requirements. The LL negotiation response frame may include the operation of the LL RU, the LL RU list, user priority, and preemption capability. This information carries the same information as described in the LL negotiation request frame. In response, AP1 sends an LL negotiation confirmation frame to AP2, accepting AP2's response. Through this negotiation, AP1 and AP2 agree to coordinate so that the STAs of the two BSSs do not interfere with the LL request of the other BSS.

[0169] In this embodiment, information from the LL negotiation process can also be embedded in the SCS request and response frames from the AP. In this embodiment, information can also be embedded in the Coordinated Target Wake-Up Time (TWT) process, where the duration, start time, or service period (SP) can also be considered and negotiated.

[0170] In this embodiment, after the negotiation process between APs, the coordinating AP and the coordinated AP can notify their associated STA and RTA STA of the LL-RU and the negotiation result, such as LL-RU, UP, or preemption capability, via a coordination LL-RU information indication frame. The negotiation process can have various states and outcomes.

[0171] In one embodiment, coordinating APs and coordinated APs from different BSSs can avoid transmitting in a dedicated RU during the scheduling time. For example, if a conflict exists, the coordinated AP can reschedule an RU or TXOP for its STA. In another example, if a conflict exists, the coordinating AP can reschedule an RU or TXOP for its STA and indicate this in the acknowledgment frame.

[0172] In this embodiment, the negotiation process indicates that RTA STAs from different BSSs can exist in different LL-RUs and different TXOPs. In this case, there are no conflicts between RTA STAs.

[0173] In this embodiment, the negotiation process indicates that RTA STAs from different BSSs can exist in the same LL-RU but different TXOPs. In this case, there is no conflict between RTA STAs.

[0174] In one embodiment, the negotiation process indicates that RTA STAs from different BSSs can exist in different LL-RUs but the same TXOP. An RTA STA can use its assigned LL-RU without any conflict. In another embodiment, if an RTA STA is not detected in the coordinating LL-RU, the LL STA can use its own LL-RU or both to maximize utilization efficiency.

[0175] In this embodiment, the negotiation process indicates that RTA STAs from different BSSs can coexist in the same LL-RU and the same TXOP. In this embodiment, when the uptime of RTA STAs is the same, contention-based channel access can be considered. In this embodiment, preemption can be considered. For example, an RTA STA with a higher uptime can preempt an RTA STA with a lower uptime.

[0176] In an embodiment, the representative STA or group owner (GO) in the P2P group associated with the coordinated AP can deliver the LL information considered above to the P2P group.

[0177] Figure 14 An example frame exchange is shown to indicate LL information to a P2P group according to an embodiment. Figure 14 The frame switching described herein is for explanatory and illustrative purposes. Figure 14 This disclosure is not intended to limit the scope to any particular implementation.

[0178] Reference Figure 14 AP1 and AP2 participate in MAP coordination. AP1 is the coordinating AP, and AP2 is the coordinated AP. AP1 is associated with STA2 as an RTA STA. AP2 is associated with STA3 as a representative STA or GO in the P2P group.

[0179] In Phase 1, AP1 sends an LL-RU request frame (LL-RU request (LL-RU req.)) to AP2, requesting AP2 to avoid and prevent the OBSS STA from using the LL-RU for STA2. In response, AP2 sends a response frame (Resp.) to AP1, agreeing to avoid and prevent the OBSS STA from using the LL-RU for STA2. Subsequently, AP2 sends an LL-RU indication frame (LL-RU Ind.) to STA3, indicating the LL information associated with AP1's request. In response, STA3 sends an acknowledgment frame (Conf.) to AP2, acknowledging receipt of the LL information.

[0180] In phase 2, STA3 sends an LL-RU indication frame (LL-RU Ind.) to the P2P group, indicating the LL information associated with AP1's request. The LL information may include the identifier of the LL-RU and the time period during which the STAs in the P2P group should avoid using the LL-RU.

[0181] Figure 15 An example process for coordinating the AP-side negotiation process is shown according to an embodiment. Figure 15 The process described in the text is used for explanation and illustration purposes. Figure 15 This disclosure is not intended to limit the scope to any particular implementation.

[0182] Reference Figure 15 Procedure 1500 begins with operation 1501. In operation 1501, the coordinating AP receives an LL-RU request frame from the RTA STA for LL transmission on a dedicated RU. More than one dedicated RU may exist for LL services.

[0183] In Operation 1503, the coordinating AP sends an LL-RU request frame to the coordinated AP. This LL-RU request frame requests the coordinated AP to avoid using and prevent the OBSS STA from using a dedicated RU intended for an RTA STA. The coordinated AP is the AP associated with the BSS, which includes STAs that might occupy a dedicated RU. The coordinating AP's request frame may include dedicated LL-RU information. Alternatively, the coordinating AP may send an LL-RU negotiation request frame, indicating information items related to LL-RU operation.

[0184] In Operation 1505, the coordinating AP receives an LL-RU response frame from the coordinated AP. The LL-RU response frame indicates that the coordinated AP agrees to avoid using and prevent the OBSS STA from using a dedicated RU for an RTA STA. The coordinated AP can comply with the coordinating AP's request by setting a NAV for the STA in its BSS or by requesting the STA to avoid using a dedicated RU. If the coordinating AP sends an LL-RU negotiation request frame, the coordinating AP can receive an LL-RU negotiation response frame. Furthermore, the LL-RU negotiation response frame can indicate that the coordinated AP also has an LL requirement in its BSS, and the coordinating AP will respond accordingly with an acknowledgment frame.

[0185] In Operation 1507, the coordinating AP sends an LL response frame to the RTA STA, indicating that the coordinating AP accepts the RTA STA's request. The coordinating AP may include dedicated LL-RU information.

[0186] Figure 16 An example process for the coordinated AP-side negotiation process is shown according to an embodiment. Figure 16 The process described in the text is used for explanation and illustration purposes. Figure 16 This disclosure is not intended to limit the scope to any particular implementation.

[0187] Reference Figure 16 Procedure 1600 begins with operation 1601. In operation 1601, the coordinated AP receives an LL-RU request frame from the coordinating AP. The LL-RU request frame requests the coordinated AP to avoid using and prevent the OBSS STA from using a dedicated RU. The LL-RU request frame may include dedicated LL-RU information. Alternatively, the coordinated AP may receive an LL-RU negotiation request frame.

[0188] In Operation 1603, the coordinated AP sends an LL-RU request frame to the associated STA, requesting the associated STA to avoid using a dedicated LL-RU. Alternatively, the coordinated AP can send an LL-RU indication frame conveying the same dedicated LL-RU information. The coordinated AP can set a NAV for the associated STA to avoid using a dedicated LL-RU, or indicate information about a dedicated LL-RU to prevent the associated STA from using a dedicated LL-RU.

[0189] In operation 1605, the coordinated AP receives an LL-RU response frame from the associated STA. The LL-RU response frame indicates that the associated STA agrees to avoid using a dedicated RU. Alternatively, the coordinated AP may receive an acknowledgment frame, which confirms that the associated STA has received the coordinated AP's request. The LL-RU response frame may indicate that the associated STA has an LL requirement, or that the coordinated AP may already be aware of the LL requirement in the BSS.

[0190] In Operation 1607, the coordinated AP sends an LL-RU response frame to the coordinating AP, indicating that the coordinated AP accepts the RTA STA request. Alternatively, the coordinated AP may send an LL-RU negotiation response frame and receive an acknowledgment frame from the coordinating AP. Furthermore, the LL-RU negotiation response frame may indicate that the coordinated AP has an LL requirement and provide LL information to the coordinating AP.

[0191] This disclosure provides negotiation mechanisms and procedures for dedicated RU protection in MAP networks, such as coordinating APs and coordinated APs coordinating so that the BSS of the coordinated AP does not occupy the LL-RU that the RTA STA associated with the coordinating AP will use.

[0192] Various exemplary frames, units, modules, components, methods, operations, instructions, items, and algorithms can be implemented or executed using processing circuitry.

[0193] Unless explicitly stated otherwise, mentioning an element in the singular is not intended to indicate one and only one, but rather one or more. For example, a “one” module can refer to one or more modules. Without further restriction, elements beginning with “a,” “an,” “the,” or “an” do not preclude the existence of additional identical elements.

[0194] Titles and subtitles (if any) are used for convenience only and do not limit the technical scope of this subject matter. The term "exemplary" is used to indicate that it is an example or illustration. Within the scope of the use of the terms "include," "have," "carry," "contain," etc., the term is intended to be inclusive in a manner similar to the interpretation of "comprise" when used as a transitional word in the claims. Relational terms such as "first" and "second" may be used to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between these entities or actions.

[0195] Phrases such as "one aspect," "the aspect," "on the other hand," "some aspects," "one or more aspects," "one implementation," "the implementation," "another implementation," "some implementations," "one or more implementations," "an embodiment," "the embodiment," "another embodiment," "some embodiments," "one or more embodiments," "a configuration," "the configuration," "another configuration," "some configurations," "one or more configurations," "the subject matter," "this disclosure," "the content of this disclosure," and "other variations thereof" are used for convenience and do not imply that the disclosure associated with such phrase(s) is essential to the subject matter or that such disclosure applies to all configurations of the subject matter. The disclosure associated with such phrase(s) may apply to all configurations or one or more configurations. The disclosure associated with such phrase(s) may provide one or more examples. Phrases such as "one aspect" or "some aspects" may refer to one or more aspects, and vice versa, and this also applies to other phrases mentioned above.

[0196] The phrase "at least one of..." preceding a list of items, where any item is separated by the terms "and" or "or", modifies the entire list, not each member of the list. The phrase "at least one of..." does not require the selection of at least one item; rather, it allows for the following meanings: including at least one of any of the items, and / or at least one of any combination of the items, and / or at least one of each of the items. For example, each of the phrases "at least one of A, B, and C" or "at least one of A, B, or C" refers to only A, only B, or only C; any combination of A, B, and C; and / or at least one of each of A, B, and C.

[0197] It should be understood that the specific order or hierarchy of the disclosed steps, operations, or processes is an illustration of exemplary methods. Unless otherwise expressly stated, it should be understood that a specific order or hierarchy of steps, operations, or processes may be performed in a different order. Some steps, operations, or processes may be performed simultaneously, or may be performed as part of one or more other steps, operations, or processes. The appended method claims (if any) present elements of various steps, operations, or processes in an exemplary order and are not intended to be limited to the specific order or hierarchy presented. These steps, operations, or processes may be performed serially, linearly, in parallel, or in a different order. It should be understood that the described instructions, operations, and systems can generally be integrated together in a single software / hardware product or packaged in multiple software / hardware products.

[0198] This disclosure is provided to enable any person skilled in the art to practice the various aspects described herein. In some cases, well-known structures and components are shown in block diagram form to avoid obscuring the concepts of the subject matter. This disclosure provides various examples of the subject matter, and the subject matter is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the principles described herein can be applied to other aspects.

[0199] All structural and functional equivalents of the elements described throughout this disclosure, whether known to those skilled in the art or hereafter known, are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be made public, whether or not such disclosure is expressly stated in the claims. Unless a claim element expressly uses the phrase "means for," or, in the case of a method claim, uses the phrase "step for," a claim element should not be interpreted in accordance with 35 USC §112, paragraph 6.

[0200] The title, background art, brief description of the drawings, abstract, and drawings are incorporated herein by reference and are provided as illustrative examples of this disclosure, not as limiting descriptions. It is understood at the time of filing that they are not intended to limit the scope or meaning of the claims. Furthermore, in the detailed description, the description may provide illustrative examples, and various features may be grouped together in various implementations for the purpose of simplification. This approach to disclosure should not be construed as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, the inventive subject matter exists in fewer than all features of a single disclosed configuration or operation. The following claims are incorporated herein by reference, wherein each claim exists independently as a separate claimed subject matter.

[0201] These embodiments are provided merely as examples for understanding the invention. They are not intended, nor should they be construed, as limiting the scope of the invention in any way. While certain embodiments and examples have been provided, it will be apparent to those skilled in the art, based on the disclosure herein, that changes may be made to the illustrated embodiments and examples without departing from the scope of the invention.

[0202] The claims are not intended to be limited to the aspects described herein, but should be given the full scope consistent with the language of the claims and to cover all legal equivalents. Nevertheless, no claim is intended to cover subject matter that does not meet the requirements of applicable patent law, nor should it be interpreted in this way.

Claims

1. A first access point (AP) in a wireless network, comprising: Memory; as well as A processor coupled to the memory, the processor being configured such that: A first request frame is received from the second AP, the first request frame requesting coordination such that the first AP and one or more stations (STAs) in the basic service set (BSS) of the first AP avoid using the first resource unit (RU), wherein the first RU is dedicated to low-latency service transmission, and the first request frame includes a first duration for the coordination. as well as Send a first response frame to the second AP to accept the request of the first request frame.

2. The first AP according to claim 1, wherein, The first request frame includes an identifier for the STA designated to use the first RU for low-latency service transmission.

3. The first AP according to claim 1, wherein: The first request frame is a Stream Classification Service (SCS) request frame, which includes classification information and parameters provided by one or more STAs associated with the first AP; and The first response frame is an SCS response frame.

4. The first AP according to claim 1, wherein, The processor is also configured such that: A third request frame is sent to the second AP, requesting coordination so that the second AP and one or more STAs in the second AP's BSS avoid using the second RU, wherein the second RU is dedicated to low-latency service transmission; and Receive a fourth response frame from the second AP to accept the request of the third request frame.

5. The first AP according to claim 1, wherein, The processor is also configured such that: Send a second request frame to one or more STAs, the second request frame requesting the one or more STAs to avoid using the first RU during the first duration; as well as Receive a second response frame from at least one of the one or more STAs, accepting the request of the second request frame.

6. The first AP according to claim 5, wherein, The first response frame includes a second duration for setting the network allocation vector (NAV) in the BSS of the first AP, the second duration being determined based on the first duration.

7. The first AP according to claim 5, wherein, The processor is also configured such that: In response to the first request frame, a third response frame is sent to the second AP, wherein the third response frame delays the acceptance of the first request frame for a period of time; Perform communication with the one or more STAs; as well as Send the first response frame to the second AP, requesting acceptance of the first request frame.

8. The first AP according to claim 1, wherein, The first request frame includes information indicating that low-latency service exists on the first RU.

9. A first access point (AP) in a wireless network, comprising: Memory; as well as A processor coupled to the memory, the processor being configured such that: Send a first request frame to the second AP, the first request frame requesting coordination so that the second AP and one or more stations (STAs) in the basic service set (BSS) of the second AP avoid using the first resource unit (RU), wherein the first RU is dedicated to low-latency service transmission. as well as Receive a first response frame from the second AP that accepts the request of the first request frame.

10. The first AP according to claim 9, wherein, The first request frame includes an identifier for the STA designated to use the first RU for low-latency service transmission.

11. The first AP according to claim 9, wherein: The first request frame is a Stream Classification Service (SCS) request frame, which includes classification information and parameters provided by one or more STAs associated with the first AP; and The first response frame is an SCS response frame.

12. The first AP according to claim 9, wherein, The processor is also configured such that: The second request frame is received from the second AP, which requests coordination to prevent the first AP and one or more STAs in the first AP's BSS from using the second RU, wherein the second RU is dedicated to low-latency service transmission. Send a second response frame to the second AP accepting the request frame from the second request frame; and Send a frame indicating information associated with the second RU to one or more STAs.

13. The first AP according to claim 9, wherein, The processor is also configured such that: Receive a third request frame from the STA associated with the first AP, the third request frame requesting a RU for low-latency service transmission; and A third response frame is sent to the STA associated with the first AP, the third response frame accepting the third request and allocating the first RU.

14. The first AP according to claim 9, wherein, The first request frame includes information indicating that low-latency service exists on the first RU.

15. A method performed by a first access point (AP) in a wireless network, the method comprising: A first request frame is received from a second AP, requesting coordination to prevent the first AP and one or more stations (STAs) in the first AP's Basic Service Set (BSS) from using a first Resource Unit (RU), wherein the first RU is dedicated to low-latency service transmission, and the first request frame includes a first duration for the coordination; and Send a first response frame to the second AP to accept the request of the first request frame.

Images