Multi-ap setup and transmission procedure for wlan systems

Abstract

Methods and apparatuses for multi-access point (multi-AP) sounding procedures in wireless local area networks (WLANs) are described herein. A coordinating AP (CAP) can receive one or more indications from one or more member APs in a multi-AP set (MAPS) that the one or more member APs are capable of performing a multi-AP sounding during a transmission opportunity (TXOP). The CAP can transmit a CAP TXOP indication (CTI) frame indicating that the multi-AP sounding is to be performed during a TXOP acquired by the CAP. The CAP can receive a CAP TXOP request (CTR) frame indicating that the one or more member APs of the MAP are willing to perform a multi-AP sounding during the TXOP. The CAP can transmit a CAP TXOP AP schedule (CTAS) frame indicating a transmission schedule for one or more sounding frames to be transmitted by the one or more member APs during the TXOP.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 073,200, filed September 1, 2020, and U.S. Provisional Application No. 63 / 077,994, filed September 14, 2020, the contents of which are incorporated herein by reference. Background Art

[0003] In order to perform coordinated multi-access point (AP) transmissions, such as coordinated orthogonal frequency division multiple access (OFDMA), coordinated spatial reuse (SR), joint transmission, and coordinated beamforming, it is important to be able to perform detection from multiple APs concurrently. Without concurrent multi-AP detection from multiple APs, coordinated multi-AP transmission schemes will not work. Currently, no such concurrent multi-AP detection protocol has been defined. Summary of the Invention

[0004] This document describes methods and apparatus for a multi-access point (multi-AP) detection procedure in a wireless local area network (WLAN). For example, a coordination AP (CAP) may receive one or more indications from one or more member APs in a multi-AP set (MAPS) indicating that the one or more member APs are capable of performing multi-AP detection during a transmission opportunity (TXOP). The CAP may transmit a CAP TXOP indication (CTI) frame to the one or more member APs, indicating that multi-AP detection will be performed during the TXOP obtained by the CAP. The CAP may receive a CAP TXOP request (CTR) frame from one or more member APs in the MAPS, indicating that one or more member APs of the MAP are willing to perform multi-AP detection during the TXOP obtained by the CAP. The CAP may transmit a CAP TXOP AP schedule (CTAS) frame to the one or more member APs, indicating a transmission schedule for one or more detection frames to be transmitted by the one or more member APs to one or more stations (STAs) associated with the one or more member APSs during the TXOP for multi-AP detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be obtained from the following description given by way of example with reference to the accompanying drawings in which like reference numerals indicate like elements and in which:

[0006] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0007] Figure 1B It is shown that according to one embodiment, Figure 1AA system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0008] Figure 1C It is shown that according to one embodiment, Figure 1A a system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) for use within the illustrated communication system;

[0009] Figure 1D It is shown that according to one embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the illustrated communication system;

[0010] Figure 2A is a diagram illustrating an exemplary High Efficiency (HE) Single User (SU) Physical Layer Convergence Procedure (PLCP) Protocol Data Unit (HESU PPDU);

[0011] Figure 2B is a diagram illustrating an exemplary High Efficiency (HE) Multi-User (MU) Physical Layer Convergence Procedure (PLCP) Protocol Data Unit (HEMU PPDU);

[0012] Figure 2C is a diagram illustrating an exemplary High Efficiency (HE) Extended Range (ER) Single User (SU) Physical Layer Convergence Procedure (PLCP) Protocol Data Unit (HE SU PPDU);

[0013] Figure 2D is a diagram illustrating an exemplary High Efficiency (HE) Triggered (TB) Physical Layer Convergence Procedure (PLCP) Protocol Data Unit (HETB PPDU);

[0014] Figure 3 is a diagram illustrating exemplary sequential sounding and joint channel sounding in multiple APs;

[0015] Figure 4 is a diagram illustrating an exemplary full-duplex transmission opportunity (FDTXOP) via contention testing in a single basic service set (BSS);

[0016] Figure 5 is a diagram showing an exemplary design of a Multiple AP Set (MAPS) element;

[0017] Figure 6 is a diagram illustrating an exemplary coordinated MAP sounding procedure;

[0018] Figure 7A is a diagram illustrating an exemplary AP sounding frame transmission schedule employing frequency resource partitioning;

[0019] Figure 7Bis a diagram illustrating an exemplary AP sounding frame transmission schedule employing time resource partitioning;

[0020] Figure 7C is a diagram illustrating an exemplary AP sounding frame transmission schedule employing frequency and time resource partitioning;

[0021] Figure 7D is a diagram illustrating an exemplary AP sounding frame transmission schedule with orthogonal sequences;

[0022] Figure 8 is a diagram illustrating an exemplary coordinated multi-AP transmission procedure;

[0023] Figure 9 is a diagram illustrating another exemplary coordinated multi-AP transmission procedure;

[0024] Figure 10 is a diagram showing an exemplary frame interaction between APs;

[0025] Figure 11 is a diagram illustrating an exemplary spatial reuse (SR) coverage map when a predetermined minimum required SNR is set to 5 dB;

[0026] Figure 12 is a diagram illustrating an exemplary SR coverage map when a predetermined minimum required SNR is set to 10 dB;

[0027] Figure 13 is a diagram illustrating an exemplary throughput comparison between different scheduling schemes;

[0028] Figure 14 is a diagram illustrating an exemplary scenario in which a set of multiple APs coordinate and operate as full-duplex APs;

[0029] Figure 15 is a diagram showing an example of multiple APs with wired backhaul connections; and

[0030] Figure 16 is a diagram illustrating an example of a channel probing procedure with a wired backhaul. DETAILED DESCRIPTION

[0031] Figure 1Ais a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0032] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated process chain environments), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the UEs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0033] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an evolved NodeB (eNB), a Home NodeB, a Home evolved NodeB, a next generation NodeB such as a gNodeB (gNB), a New Radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0034] Base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, base station 114a may include three transceivers, one for each sector of the cell. In an embodiment, base station 114a may employ multiple-input, multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0035] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0036] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

[0037] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0038] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using NR.

[0039] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access, for example, using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0040] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0041] Figure 1A The base station 114b in the FIG. 10 example can be a wireless router, Home Node B, Home eNode B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity access by the WTRUs 102c, 102d. The base station 114b and the WTRUs 102c, 102d can utilize a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). The base station 114b and the WTRUs 102c, 102d can utilize a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106. Figure 1A

[0042] The RAN 104 can be in communication with the CN 106, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in the FIG. 9, a Figure 1A ​Although not shown in the figures, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0043] The CN 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) from the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0044] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0045] Figure 1B is a system diagram illustrating an exemplary WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0046] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0047] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive RF and light signals. It should be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0048] Although the transmit / receive element 122 is Figure 1B Although depicted as a single element in FIG1 , the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0049] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0050] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0051] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0052] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0053] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0054] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0055] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0056] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0057] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, etc. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0058] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0059] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0060] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0061] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0062] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0063] Even though the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communications interface with a communications network.

[0064] In a representative embodiment, the other network 112 may be a WLAN.

[0065] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating from outside the BSS and destined for a STA can reach the AP and be delivered to the STA. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the destination. Traffic between STAs within a BSS can be sent through the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within a BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between a source and destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0066] When using an 802.11 ac infrastructure mode of operation or similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems. For CSMA / CA, a STA (e.g., each STA), including the AP, can listen to the primary channel. If the primary channel is sensed / detected as busy by a particular STA, the particular STA can back off. Only one STA can transmit in a given BSS at any given time.

[0067] High Throughput (HT) STAs can use 40 MHz wide channels to communicate, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0068] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be parsed by a segment parser that can divide the data into two streams. Each stream can be independently subjected to inverse fast Fourier transform (IFFT) processing and time domain processing. The streams can be mapped to the two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0069] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0070] WLAN systems that support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (that supports the minimum bandwidth operating mode) from among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., an MTC-type device) that supports (e.g., only supports) 1 MHz mode, the primary channel may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because a STA (that only supports 1 MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the available frequency band remains idle.

[0071] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah ranges from 6MHz to 26MHz, depending on the country code.

[0072] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0073] The RAN 104 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0074] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmit spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths).

[0075] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate or connect with the gNBs 180a, 180b, 180c while also communicating or connecting with other RANs, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0076] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, interworking between DC, NR, and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0077] Figure 1DThe CN 106 shown in FIG may include at least one AMF 182 a, 182 b, at least one UPF 184 a, 184 b, at least one session management function (SMF) 183 a, 183 b, and possibly a data network (DN) 185 a, 185 b. Although the aforementioned elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0078] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of services used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on enhanced Mobile Broadband (eMBB) access, services for MTC access, etc. The AMFs 182 a and 182 b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0079] The SMFs 183a and 183b can connect to the AMFs 182a and 182b in the CN 106 via the N11 interface. The SMFs 183a and 183b can also connect to the UPFs 184a and 184b in the CN 106 via the N4 interface. The SMFs 183a and 183b can select and control the UPFs 184a and 184b and configure traffic routing through the UPFs 184a and 184b. The SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0080] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface. These gNBs may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0081] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the local DNs 185a, 185b through the UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the local DNs 185a, 185b.

[0082] Given that Figures 1A to 1D as well as Figures 1A to 1D As described herein, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein. An emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulated device may be used to test other devices and / or simulate network and / or WTRU functions.

[0083] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or in a carrier network environment. For example, the one or more emulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0084] The one or more emulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation device can be used in a test scenario in a test lab and / or in a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. The one or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0085] A WLAN in infrastructure basic service set (BSS) mode has an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP typically has access to or an interface with a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic originating from outside the BSS and destined for a STA arrives through the AP and is delivered to the STA. Traffic originating from a STA and destined for a destination outside the BSS is sent to the AP for delivery to the destination. Traffic between STAs within the BSS can also be sent through the AP, with the source STA sending traffic to the AP, and the AP delivering the traffic to the destination STA.

[0086] When using the 802.11ac infrastructure mode of operation, the AP transmits a beacon on a fixed channel (typically the primary channel). This channel can be 20 MHz wide and is the operating channel of the BSS. This channel is also used by STAs to establish connections with the AP. The basic channel access mechanism in 802.11 systems is Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA). In this mode of operation, each STA, including the AP, senses the primary channel. If the channel is detected to be busy, the STA "backs off." Therefore, only one STA can transmit in a given BSS at any given time.

[0087] In 802.11n, high-throughput (HT) STAs can also communicate using 40 MHz wide channels. This is achieved by combining a primary 20 MHz channel with an adjacent 20 MHz channel to form a 40 MHz wide contiguous channel.

[0088] In 802.11ac, Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and 160 MHz wide channels. 40 MHz and 80 MHz channels are formed by combining contiguous 20 MHz channels similar to the 802.11n described above. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels (this is also referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data is passed through a segment parser that divides the data into two streams. IFFT and time domain processing are performed separately on each stream. The streams are then mapped to the two channels and the data is transmitted. At the receiver, this mechanism is reversed, and the combined data is sent to the MAC.

[0089] To improve spectral efficiency, 802.11ac introduces the concept of downlink multi-user MIMO (MU-MIMO) transmissions to multiple STAs in the same symbol time frame, such as during a downlink OFDM symbol. The possibility of using downlink MU-MIMO is currently also being considered for 802.11ah. It should be noted that since downlink MU-MIMO uses the same symbol timing for multiple STAs when used in 802.11ac, interference with waveform transmissions for multiple STAs is not a problem. However, all STAs involved in a MU-MIMO transmission with an AP may need to use the same channel or frequency band, which limits the operating bandwidth to the minimum channel bandwidth supported by the STAs included in the MU-MIMO transmission with the AP.

[0090] 802.11ax defines physical and media access control layer specifications for high-efficiency (HE) operation of 802.11 devices. 802.11ax is considered the next generation of Wi-Fi after 802.11ac. 11ax defines new numerologies with smaller subcarrier spacing. 11ax introduces DL / UL OFDMA for improved spectral efficiency.

[0091] In IEEE 802.11ax, four PPDU formats are supported: HE SU PPDU, HE MU PPDU, HE ER PPDU, and HE TB PPDU.

[0092] Figure 2AAn exemplary high-efficiency (HE) single-user (SU) physical layer convergence procedure (PLCP) protocol data unit (HE SU PPDU) 200 is shown, which can be used in connection with any of the other embodiments described herein. As shown, Figure 2A The HE SU PPDU can include, but is not limited to, L-STF 205, L-LTF 210, L-SIG 215, RL-SIG 220, HE-SIG-A 225, HE-STF 230, HE-LTF 235, 240, data 245, and PE 250. The HE SU PPDU format 200 can be used for single-user transmissions.

[0093] Figure 2B An exemplary high-efficiency (HE) multi-user (MU) physical layer convergence procedure (PLCP) protocol data unit (HE MU PPDU) 201 is shown, which can be used in connection with any of the other embodiments described herein. As shown, Figure 2B The HE MU PPDU can include, but is not limited to, L-STF 206, L-LTF 211, L-SIG 216, RL-SIG 221, HE-SIG-A 226, HE-SIG-B 231, HE-STF 236, HE-LTF 241, 251, data 256, and PE 261. The HE MU PPDU format 201 can be used for transmissions to one or more users if the PPDU is not a response to a trigger frame. The HE-SIG-B field 231 is present in this PPDU format.

[0094] Figure 2C An exemplary high-efficiency (HE) extended range (ER) single-user (SU) physical layer convergence procedure (PLCP) protocol data unit (HE SU PPDU) 202 is shown, which can be used in connection with any of the other embodiments described herein. As shown, Figure 2C The HE ER SU PPDU can include, but is not limited to, L-STF 207, L-LTF 212, L-SIG 222, RL-SIG 227, HE-SIG-A 232, HE-STF 237, HE-LTF 242, 247, data 252, and PE 257. The HE ER SU PPDU format 202 can be used for SU transmissions with extended range. In this format, the HE-SIG-A field 232 is twice as long as the HE-SIG-A field in other HE PPDUs.

[0095] Figure 2DAn exemplary high-efficiency (HE) trigger-based (TB) physical layer convergence procedure (PLCP) protocol data unit (HE TB PPDU) 203 is shown, which can be used in connection with any of the other embodiments described herein. As shown, the HE TB PPDU can include, but is not limited to, an L-STF 208, an L-LTF 213, an L-SIG 223, an RL-SIG 228, an HE-SIG-A 233, an HE-STF 238, HE-LTFs 243, 248, data 253, and a PE 258. The HE TB PPDU format 203 can be used for transmissions in response to a trigger frame or a frame carrying a TRS control subfield from an AP. The duration of the HE-STF field 238 in the HE TB PPDU 203 is 8us, which is twice the size of the field in HE PPDUs. Figure 2D

[0096] The L-SIG field, the HE-SIG-A field, and the HE-SIG-B field can carry PHY layer control information for the PPDU. The L-SIG field can have a legacy parameter set and format so that all STAs understand the L-SIG field. The HE-SIG-A field and the HE-SIG-B field can be understood by HE STAs. The L-SIG field is given in Table 1. The HE-SIG-A field for different PPDU formats is given in Table 2.

[0097] Table 1: L-SIG fields

[0098] Field Bit rate 4 length 12 CRC 1 tail 6

[0099] Table 2: HE-SIG-A fields with different PPDUs

[0100]

[0101]

[0102] Coordinated multi-AP (C-MAP) transmissions can be supported in IEEE 802.11be. The schemes can include, but are not limited to, coordinated multi-AP OFDMA, coordinated multi-AP TDMA, coordinated multi-AP spatial reuse, coordinated beamforming / null steering, and / or joint transmission. These schemes can include joint NDP probes (e.g., sequential probes) for C-MAP.

[0103] ​In one embodiment, 802.11be may include a mechanism to determine whether an AP is part of a candidate set of APs and can participate as a shared or member AP in coordinated AP transmissions initiated by a shared or coordinated AP. Procedures may be defined for an AP to share its acquired transmission resources (e.g., frequency and / or time) for a TXOP with a set of APs. An AP that intends to use resources (e.g., frequency or time) shared by another AP can indicate its resource requirements to the AP sharing the resources. Coordinated OFDMA may be supported in 802.11be, and in coordinated OFDMA, DL OFDMA and its corresponding UL OFDMA acknowledgment are allowed.

[0104] For example, channel sounding in 802.11n and 802.11ac can be performed using two different schemes: explicit or implicit. In explicit channel sounding, the AP transmits a Null Data Packet (NDP) to a STA with a preamble that allows the STA to measure its own channel and send CSI feedback to the AP. In implicit channel sounding, the STA sends the NDP and the AP measures the STA's channel (assuming the channel is peer-to-peer).

[0105] 802.11be may support up to 16 spatial streams for SU-MIMO and for MU-MIMO, where the maximum number of spatial streams allocated to each MU-MIMO scheduled non-AP STA is limited to 4.

[0106] The maximum number of users spatially multiplexed for DL ​​transmissions may be 8 per RU / MRU.

[0107] 802.11be supports two modes of channel sounding among multiple APs: sequential sounding and joint sounding. In sequential sounding, each AP transmits an NDP independently, with no overlapping sounding cycles per AP. Joint sounding is also available as an optional mode for multiple APs, where fewer than or equal to a total of eight antennas at an AP have all antennas active on all LTF tones and use the 82.11ax P matrix across OFDM symbols.

[0108] CSI feedback collection can be performed using a 4-step probing sequence (NDPA+NDP+BFRP TF+CSI reporting) similar to 802.11ax in multi-AP to collect feedback from both intra-BSS STAs and OBSS STAs.

[0109] In sequential probing for multiple APs, the STA may process NDPA frames and BFRP trigger frames received from the OBSS APs, and if the STA is polled by a BFRP TF from the OBSS AP, may respond to the OBSS AP with corresponding CSI.

[0110] Figure 3 FIG. 3 shows an exemplary sequential sounding and joint channel sounding 300 among multiple APs, which may be used in conjunction with any of the other embodiments described herein. Figure 3 As shown, the shared AP 301a may transmit an NDPA frame to the shared APs 1-2 301b, 301c. In sequential sounding, each AP in a coordination group or multi-AP set (MAPS) (i.e., shared AP 301a, shared AP 1 301b, shared AP 2 301c) may transmit NDP frames 310, 315, 320 to all STAs 302a, 302b, 302c in the coordination group or MAPS at different, non-overlapping times (i.e., time multiplexing). In joint sounding, the shared AP 301a and the shared APs 1-2 301b, 301c may simultaneously transmit NDP frames 325, 330, 335, with different LTF tones spanning the entire bandwidth and spatially multiplexed or using orthogonal codes. Additionally or alternatively, the LTF tones may be sent on selected tones for each AP. Shared AP 301a may transmit (eg, multicast or broadcast) a beamforming report (BFRP) trigger frame (BFRP TF) for feedback. After SIFS, STAs 1, 2, 3 may respond to the feedback with compressed BFRP / CQI 345, 350, 355.

[0111] When a STA receives an NDP, it can measure the channel and prepare a CSI feedback report. Three different implementations can be used to collect CSI from STAs: (1) each AP collects all CSI, including feedback from stations within the BSS and OBSS; (2) each AP collects CSI only from its associated STAs; and (3) a shared AP collects CSI for all shared APs in the coordination group.

[0112] In general, channel probing in multi-APs may need to consider: (1) the inability of the probing STAs to hear the coordinating AP (or master AP); (2) the synchronization of APs in multi-AP coordination; (3) the overhead, complexity, and performance of different probing schemes; (4) the variants of NDP transmission in explicit and implicit probing; and (5) feedback collection and reduction.

[0113] This disclosure describes embodiments for the formation of coordinated multi-AP sets (MAPS). In order to perform coordinated multi-AP transmissions, such as coordinated OFDMA, coordinated spatial reuse, joint transmission, coordinated beamforming, and shared TXOPs for TDMA and / or OFDMA, it is beneficial to establish candidate multi-AP sets. An efficient protocol is needed to establish multi-AP sets and communicate parameters to be used during any future multi-AP transmissions.

[0114] This disclosure describes an embodiment for coordinated multi-AP detection. In many transmission scenarios that can be provided by coordinated multi-AP transmission (such as coordinated OFDMA, coordinated SR, coordinated beamforming, and coordinated joint transmission), it is important to be able to perform detection from multiple APs simultaneously. Without a multi-AP detection procedure, the coordinated transmission scheme may not work. An effective and efficient multi-AP detection protocol with limited overhead is needed.

[0115]

[0014] Embodiments are described in this disclosure for a Multiple AP Set (MAPS) that is a full-duplex AP. Figure 4 An exemplary full-duplex transmission opportunity (FD TXOP) via collision test 400 in a single basic service set (BSS) is shown, which can be used in combination with any of the other embodiments described herein. For a full-duplex TXOP for a BSS, the AP (e.g., AP 401) is full-duplex on the channel, while the STAs (e.g., STA 1, 2 402a, 402b) are half-duplex on the same channel. A full-duplex AP can fully utilize its capabilities to initiate a full-duplex TXOP to allow different STAs to transmit and receive simultaneously. Figure 4 As shown, AP 401 may transmit MU-RTS 405 to STA 1 402a and STA 2 402b and receive CTS 415 from STA 2 402b. After transmitting a trigger frame (TF) 410 to STA 1 402a, AP 401 may transmit a DL 420 to STA 2 402b while receiving a TB PPDU 425 from STA 1 402a during an FD TXOP. AP 401 may then transmit a block acknowledgment (BA) 430 to STA 1 402a. STA 2 402b may transmit a BA 435 to AP 401.

[0116] In WLANs, the radios on APs are typically not full-duplex. However, in a multiple AP set (MAPS) deployment, two or more APs in the set can perform the roles of transmitter and receiver, respectively, and as long as the transmitting AP does not interfere with the receiving AP, the multiple AP set (MAPS) can effectively behave as a single full-duplex AP. Additional procedures may be required to adapt this implementation to multiple AP sets.

[0117] This disclosure describes implementations for multiple (e.g., two) NAV updates during multi-AP set sounding / TXOPs. For example, in 11ax, two NAVs, the intra-BSS NAV and the basic NAV, are available for non-AP STAs. Currently, when a STA responds to a trigger frame (TF, which can be a beamforming report poll / BFRP) with the CS set to 1, it cannot transmit a TB-PPDU if the basic NAV indicates busy.

[0118] In 802.11be, STAs can perform measurements on the NDP of an OBSS AP and respond to the BFRP of the OBSS AP. In this case, the basic NAV may be set by the OBSS AP, and STAs following the 11ax rules may not be able to respond to the BFRP of the OBSS AP.

[0119] This disclosure describes an implementation for a coordinated multi-AP transmission procedure. There are a variety of coordinated multi-AP transmission schemes, such as coordinated spatial reuse (C-SR), coordinated OFDMA (C-OFDMA), coordinated TDMA (C-TDMA), etc. The combination of these schemes can provide a more flexible and efficient procedure for the system, and may require the use of sounding results to schedule more efficient C-MAP transmission.

[0120] This disclosure describes an implementation for buffered traffic reporting (BSR). The BSR in 802.11ax supports access category (AC) granularity. Within each AC, there can be multiple TIDs. In 802.11be, TIDs can be mapped to different links (e.g., frequency bands). It is desirable for the scheduler on a particular link (for a MAP or a single BSS) to have information about the traffic that can be transmitted on that link.

[0121] For example, AP 2 may participate in a shared TXOP on link x. Based on the BSR from STA 2, AP 2 may know that it has UL traffic for access category y (ACy). However, TID z corresponding to STA 2's ACy may not be mapped to link x. Before AP 2 can decide whether to join a shared TXOP or a shared TXOP, more information about the buffered traffic that can be sent on the link may be needed.

[0122] Furthermore, a BSR A control may be the maximum size of an HE control and therefore difficult to scale, which means that creating a new A control of the same size may not convey more information.

[0123] The present disclosure describes an implementation scheme for channel sounding with a wired backhaul. In all coordinated multi-AP transmission schemes, information needs to be exchanged between APs, such as requests / responses when forming a multi-AP transmission set, RSSI or CSI within the BSS and between the OBSS, confirmation at the end of multi-AP establishment and data transmission, etc. If the same resources / channels / bands are used for data transmission, all these information exchanges can be regarded as overhead, which can lead to low system throughput and complexity when the process of information exchange is interrupted by other inference / collision sources. In many deployment scenarios (for example, corporate offices / buildings), APs are already connected by cables / wires in the ceiling / walls. These connections typically have wider bandwidth and are more reliable. Therefore, many high-overhead processes such as multi-AP detection may rely on such connections. It is necessary to define specific steps for multi-AP channel detection when a wired backhaul link is available.

[0124] This document describes implementations for a coordinated multi-AP set management procedure.

[0125] First, this document describes an implementation for Multiple AP Set (MAPS) setup.

[0126] A multiple AP set (MAPS) may include one or more coordinating APs and one or more coordinated APs. A coordinating AP may also be referred to as a shared AP, a primary AP, or a master AP. A coordinating AP or a shared AP may be an AP that obtains a TXOP and decides to share it with multiple other APs in its vicinity. In another example, a coordinating AP may be pre-assigned by an upper layer or by configuration in a given area or for a group of APs or for a multiple AP set (MAPS). These terms coordinating AP, shared AP, or master AP may be used interchangeably throughout this disclosure. A coordinated AP may also be referred to as a shared AP, a member AP, a participating AP, an auxiliary AP, or a slave AP. A coordinated AP may be an AP that wishes to share a TXOP obtained and is willing to share by a coordinating AP or a sharing AP. A coordinating AP may be assigned to each of the coordinated APs by an upper layer or by configuration. The terms coordinated AP, shared AP, member AP, participating AP, or slave AP may be used interchangeably throughout this disclosure.

[0127] A Multiple AP Set (MAPS) can be dynamic or static. In a static MAPS, the number of APs can be fixed. A coordinating AP can be assigned to a static MAPS. However, the number or subset of APs participating in each MAP transmission can be different. In a dynamic MAPS, the number of APs and / or APs that can be part of a dynamic MAPS can change from time to time or vary depending on the TXOP in which the MAPS transmits.

[0128] In another example, the set of MAPS may vary depending on the type of multi-AP transmission being performed.

[0129] Second, embodiments for multi-AP set elements and information are described herein.

[0130] Figure 5 An exemplary design of a multi-AP set (MAPS) element 500 is shown, which can be used in conjunction with any of the other embodiments described herein. An AP can include the MAPS element 500 in its beacon, short beacon, FILS discovery frame, probe request or probe response frame, association request or association response frame, public action frame, MAPS capability frame, or another type of frame it transmits.

[0131] The MAPS element 500 can include, but is not limited to, one or more of the following fields and information: element ID 505 and element ID extension 515, length 510, MAPS capability 520, and MAPS action field 525.

[0132] The element ID 505 and element ID extension 515 together can indicate that the current element is a MAPS element 500.

[0133] The length field 510 can indicate the length of the MAPS element.

[0134] The MAPS capability field 520 can indicate the capability for coordinated MAP transmission by the transmitting STA. The MAPS capability field 520 can include, but is not limited to, one or more of the following subfields or information: coordinated AP capability 530, coordinated AP capability 535, coordinated scheme capability 540, and coordinated MAPS parameters 545.

[0135] The coordinated AP capability subfield 530 can indicate whether the transmitting STA is capable of being a coordinating AP in a MAPS.

[0136] The coordinated AP capability subfield 535 can indicate whether the transmitting STA is capable of being a coordinated AP in a MAPS.

[0137] The coordinated scheme capability subfield 540 may indicate one or more coordinated transmission schemes that the transmitting STA is capable of, such as coordinated OFDMA, coordinated TDMA, coordinated SR, shared TXOP TDMA, shared TXOP OFDMA, joint transmission, and coordinated beamforming. The coordinated scheme capability 540 may be implemented as a bitmap in which each bit corresponds to the above-mentioned coordinated scheme. In one example, a MAPS ID may be included to identify the coordinated scheme capabilities for a specific MAPS ID. In another example, there are multiple coordinated scheme capability subfields 540 and coordinated MAPS parameter subfields 545, each associated with a MAPS ID. The MAPS ID may be implemented as the MAC address of the coordinating AP. For example, the group bit in the MAC address of the coordinating AP may be set to 1 to indicate that it is a MAPS ID. The MAPS ID may also be a BSS color that identifies the MAPS. Alternatively, the MAPS ID may be any other agreed-upon ID.

[0138] The coordinated MAPS parameters field 545 may indicate parameters associated with the advertised MAPS. These parameters may include, but are not limited to, the MAPS ID, the BSS color for the advertised MAPS, bandwidth, number of links, and preferred channels / RUs. Additionally, this parameter subfield may include one or more APs that may be coordinated APs in the MAPS. Additionally, there may be an indicator of which AP is the coordinating AP.

[0139] The MAPS action field 525 may indicate the requested action associated with the indicated MAPS. The MAPS action field may include an action field 550 and a MAPS action parameter field 555. One or more MAPS action fields 525 may be included in the MAPS element 500 to indicate the desired action or actions. One or more of the following subfields or information may be included: action field 550, request to establish a MAPS, request to join a MAPS, request to leave a MAPS, request to disband a MAPS, and response.

[0140] The action field 550 may indicate the details of the requested action. The action field 550 may include a token field for indicating a request and response sequence. Some requested actions may be: a request to establish a MAPS, a request to join a MAPS, a request to leave a MAPS, a request to disband a MAPS, and a response.

[0141] The request to establish a MAPS may be used to request another STA to become a coordinating AP to establish a new MAPS.

[0142] The request to join MAPS can be used to request the STA to join MAPS as a coordinated AP and can also indicate the MAPS ID.

[0143] A request to leave a MAPS can be used by a coordinated AP to request to leave a MAPS. This request can be sent by the coordinated AP to the coordinating AP of the MAPS. The MAPS ID can also be indicated. This request can also be used by the coordinating AP to announce that the MAPS as a coordinating AP will be disbanded. The receiving STA can remove the entry of such a MAPS from the memory.

[0144] The Disband MAPS action can be used to disband an established MAPS. This action can be sent by the coordinating AP of the MAPS or another STA to announce that the MAPS starting with the transmitting AP will be disbanded. The MAPS ID can also be indicated. Receiving STAs that are part of the MAPS can remove the entry for such MAPS from the memory.

[0145] A response action may be used by a STA to respond to a requested action received from another STA. Response actions may include acceptance, rejection, confirmation, etc. In another example, a response may be transmitting a frame, such as an action frame, to perform a requested action, such as establishing a new MAPS, requesting to join a MAPS, announcing the release of a current MAPS, etc.

[0146] The MAPS action parameters subfield 555 may indicate parameters of the requested action, which may include but are not limited to: MAPS ID, preferred channel / RU, preferred MAPS operation, MAPS transmission parameters, etc.

[0147] The MAPS ID subfield may indicate the ID of the identified MAPS.

[0148] The Preferred Channel / RU subfield may indicate that the requesting STA is requesting / assigning a preferred channel or RU for future scheduling assignments as part of MAPS coordinated or joint transmission / reception, depending on the action detailed in the MAPS action.

[0149] The preferred MAPS operation field may include one or more MAPS operation modes, such as coordinated OFDMA, coordinated TDMA, shared TXOP OFDMA / TDMA, joint transmission, coordinated beamforming, coordinated spatial reuse, etc. This subfield may include a bitmap in which each bit is associated with a specific MAPS operation. The MAPS operation mode may be requested or indicated depending on the action detailed in the MAPS action field.

[0150] The MAPS transmission parameter subfield may indicate maximum TXOP sharing duration, bandwidth, number of links, etc.

[0151] It is worth noting that all or any information or a subset thereof may be included in any existing element, or new element, or any part of any existing frame or new frame, or MAC or PLCP header, or SIG or SIG-A, SIG-B, or U-SIG field.

[0152] Third, this document describes an implementation for a multi-AP set establishment procedure.

[0153] The Multiple AP Set (MAPS) establishment procedure may include, but is not limited to, one or more of the following steps:

[0154] Each STA or AP capable of performing MAPS transmissions may include a MAPS capability element in its beacon, short beacon, probe request or probe response frame, association request or association response frame, FILS discovery frame, other types of management, control or data frames, action frames, or public action frames. A STA or AP may indicate which MAPS operations it is capable of.

[0155] In one example, each STA or AP may advertise one or more MAPSs, which are part of a MAPS that includes MAPS operating parameters (including MAPS ID, MAPS BSS color). In one example, an AP may only advertise the MAPS of which it is a coordinating AP. An AP that is part of a MAPS may indicate all member APs of the MAPS, thereby indicating which APs are coordinated APs and which APs are coordinating APs, or which APs are shared APs in a shared TXOP OFDMA / TDMA MAPS.

[0156] An AP or a coordinating AP or a shared AP may request one or more APs to join MAPS by sending a MAPS setup request frame. This may be after the transmitting AP discovers that the receiving AP is capable of MAPS operation, for example, by receiving a frame from an AP containing a MAPS element that advertises its MAPS capabilities. The MAPS setup request frame may include a MAPS element in which the MAPS action field contains a request to join. The same MAPS element or frame may also include a MAPS ID and other MAPS operation parameters. The request to join action may also include whether to request the receiving AP to become a coordinating or coordinated AP or a sharing AP or a shared AP.

[0157] When an AP or STA receives a MAPS Setup Request frame, it may respond with a MAPS Setup Response frame or any other frame that may include a MAPS element including a MAPS Action field that includes a MAPS response. A MAPS response action may include accepting an invitation to join the MAPS, or rejecting the invitation. The AP may indicate its MAPS operation mode in the MAPS, and whether the AP will be a shared AP, a coordinating AP, or a coordinated AP. In another example, when an AP or STA receives a MAPS Setup Request frame, it may respond by sending a MAPS Setup Request frame and including a Request to Join action in the MAPS element to request to join the MAPS where the AP is a coordinating or shared AP. The AP may indicate its MAPS operation mode in the MAPS, and whether the AP will be a shared AP, a coordinating AP, or a coordinated AP.

[0158] As another example, an AP may request to join a MAPS after receiving a frame including an announcement of one or more MAPSs, which may be transmitted by a member AP of the MAPS or a coordinating or sharing AP. The AP may transmit a MAPS setup request frame or any other frame including a MAPS element in the MAPS action field indicating the request to join. The requesting AP may indicate whether it wishes to act as a coordinating AP, a sharing AP, or only a coordinated AP. Once the AP receives the MAPS setup request frame or a frame including a request to join action, the AP may respond with a MAPS setup response frame or another frame including a MAPS element that may include a response action such as accept, reject, etc. The MAPS setup response frame may include one or more MAPS operating parameters, such as a MAPS ID, a MAPS BSS color, a MAPS operating mode, whether the intended receiving AP is a coordinating AP, a sharing AP, a shared AP of a TXOP, or only a coordinated AP or a shared AP. It may also indicate the operating link, operating bandwidth, channel, or possibly assigned channel, link, or RU during any coordinated MAPS transmission or shared or shared TXOP.

[0159] An AP joining a MAPS can announce its membership of a MAPS in a MAPS element or can include in any other element or frame such as a beacon, short beacon, probe request frame, probe response frame, association request frame, association response frame, FILS discovery frame, MAPS frame, Action or Public Action frame, etc. The MAPS element can include information of MAPS operating parameters such as MAPS ID, MAPS BSS color, MAPS operating mode, whether the AP is a coordinating AP, a sharing AP, a sharing AP of TXOP, or just a coordinated or shared AP. It can also indicate the operating link, operating bandwidth, channel or possibly assigned channel, link or RU during any coordinated MAPS transmission or shared or shared TXOP. It can also indicate to its associated STAs or non-AP MLDs that they are expected to switch to a different channel or RU during any coordinated MAPS transmission or shared or shared TXOP. It can also indicate to its associated STAs that they need to monitor transmissions identified by one or more MAPS BSS colors and these STAs can consider transmissions of the one or more MAPS BSS colors indicated in the MAPS element as intra-BSS PPDUs and / or PPDUs that the STAs need to decode. In addition, one or more member AP or coordinating or sharing AP ID addresses such as MAC addresses or MLD IDs can also be indicated by the AP in the MAPS element and / or one or more MAPS IDs can be included in any transmitted frames such as CAP TXOP indication (CTI) frame, CAP TXOP request (CTR) frame, CAP TXOP AP schedule (CTAS) frame, CAP TXOP local schedule (CTLS) frame, or other types of frames such as trigger frame, NDP announcement (NDPA) frame, or other types of frames. The associated STAs or non-AP MLDs need to monitor transmissions identified by the one or more MAPS IDs or member AP IDs or sharing AP IDs and these STAs can consider transmissions of the one or more MAPS IDs or member AP IDs included in the MAPS element as intra-BSS PPDUs and / or PPDUs that the STAs need to decode.

[0160] In one example, when joining MAPS, the AP may request a range of MAPS AIDs (or IDs representing MAPS) from its associated STAs. The MAPS AID (or MAPS ID) range of a member AP may be assigned by a coordinating AP or a shared AP. The MAPS AID (or MAPS ID) range may begin with one or more bits that identify the AP. Once the range of MAPS AIDs (or MAPS IDs) is assigned to a member AP, the AP may subsequently announce the MAPS AIDs (or MAPS IDs) for its associated STAs. The MAPS AID (or MAPS ID) for the associated STA may be the AID (or ID) that has been assigned to the associated STA in addition to the one or more bits that identify the member AP to which it is associated. A STA associated with a member AP of MAPS may respond to a trigger frame that includes the MAPS ID and / or MAPS AID assigned to it. A STA associated with a member AP of MAPS may respond to a frame that includes the MAPS ID and / or MAPS AID assigned to it.

[0161] A member AP, coordinated AP, coordinating AP, or shared AP that is already a member of a MAPS may send a MAPS setup request frame or any frame that includes a MAPS element that includes a request to leave action in the MAPS action field to request to leave the MAPS. The MAPS setup request frame may be sent to a coordinating AP or a shared AP of a MAPS. Upon receiving a MAPS setup request frame or any other frame that includes a MAPS element indicating that the AP is requesting to leave the MAPS, the AP may respond with a MAPS setup response frame that includes a MAPS action such as acceptance or rejection. If a member AP has left the MAPS, it may remove information related to the MAPS from its MAPS element or stop transmitting MAPS elements in the frames it transmits. It may also issue any management frame, control frame, action frame, or public action frame that declares that it is no longer associated with one or more MAPSs. Any associated STA that receives the frame may remove all stored information associated with the identified MAPS from its memory.

[0162] In one example, an AP may send a MAPS setup request frame to another AP or STA to request that the AP establish a MAPS. The receiving AP or STA may respond with a MAPS setup response frame or simply start advertising a new MAPS.

[0163] Fourth, this document describes an implementation for a multi-AP group disbanding procedure.

[0164] For example, the MAPS dissolution procedure could be as follows:

[0165] The coordinating AP or the sharing AP or the member AP may issue a MAPS setup request frame or any other frame including a MAPS element indicating disbanding MAPS in a MAPS action frame to announce that the AP is disbanding MAPS.

[0166] The MAPS setup request frame or any other frame may also include an end time to indicate the time when the MAPS is expected to be disbanded.

[0167] At the time indicated in the MAPS setup request frame or other frame, or upon receiving a MAPS setup request frame or any other frame including a MAPS element indicating the disbanding of a MAPS in a MAPS action frame, all member APs or STAs may remove entries for the MAPS from their memory, including the MAPS BSS color, etc. In addition, all members of the MAPS may transmit a MAPS termination notification to all of its associated STAs. This frame may identify one or more MAPSs being terminated. All associated STAs that have received this frame may remove all information related to the identified MAPSs from their memory.

[0168] Implementations for a coordinated multi-AP detection procedure are described herein.

[0169] First, an embodiment of a coordinated multi-AP probing procedure using a shared TXOP is described herein.

[0170] If one of the MAPS operation modes is shared TXOP, or shared TXOP OFDMA, or shared TXOP TDMA, the coordinated multi-AP detection procedure for such MAPS may be as follows:

[0171] Member APs of a MAPS may have advertised that they can perform shared TXOP operation, which may be shared TXOP OFDMA, shared TXOP TDMA, or other types of shared TXOP operation, or shared TXOP sounding. In another example, a MAPS may not be pre-established.

[0172] Member APs of the MAPS may have indicated to their associated STAs or multi-link devices (MLDs) that they may perform shared TXOP operations or shared TXOP probing procedures.

[0173] The coordinated AP or shared AP can start the multi-AP detection procedure by sending a CTI frame after obtaining a TXOP. The CTI frame can indicate the purpose of the shared TXOP. The purpose of the shared TXOP may include but is not limited to: performing multi-AP detection, performing data transmission, performing low-latency / higher priority service data transmission, performing MAPS coordination functions, performing multi-AP detection feedback, and combined multi-AP detection and feedback.

[0174] The CTI frame may indicate one or more member APs that are being requested to participate in the shared TXOP.

[0175] One or more member APs of the MAPS or APs willing to participate in multi-AP detection or transmission may respond with a CTR frame after receiving a CTI frame indicating that it wants to participate in a shared TXOP. A member AP may also send a request frame to one or more APs in the MAPS before receiving a CTI frame to request a certain type of shared TXOP operation, such as shared TXOP data transmission, shared TXOP low-latency data transmission, shared TXOP multi-AP detection, or shared TXOP feedback.

[0176] After receiving a CTR from one or more member APs, the coordinating AP or shared AP may transmit a CTA with a schedule for the member APs to transmit sounding frames, such as NDP frames. In one example, all member APs are scheduled to transmit sounding frames or NDP frames simultaneously over the entire bandwidth and / or on all links. In one example, the CTAS may include an orthogonal sequence assigned to each member AP for use during the upcoming sounding procedure. In another example, each of the member APs is assigned to a separate channel / RU / link. In yet another example, each of the member APs is assigned to a separate time interval and / or channel / RU / link and / or orthogonal sequence. In another example, multiple member APs may be allocated on the same resources. The CTAS frame may also include the type of desired feedback for the upcoming sounding.

[0177] In another example, the coordinated AP or shared AP may transmit NDPA instead of CTAS. The NPDA frame may include an indication that it is used for multi-AP detection. The NDPA may include a schedule for member APs to transmit detection frames such as NDP frames. In one example, all member APs are scheduled to transmit detection frames or NDP frames simultaneously over the entire bandwidth and / or on all links. In one example, the CTAS or NDPA may include an orthogonal sequence assigned to each member AP for use during the upcoming detection procedure. In another example, each of the member APs is assigned to a separate channel / RU / link. In yet another example, each of the member APs is assigned to a separate time interval and / or channel / RU / link and / or orthogonal sequence. In another example, multiple member APs may be allocated on the same resources. The CTAS or NDPA frame may also include the type of desired feedback for the upcoming detection.

[0178] After receiving the CTAS or NDPA frame, the member AP or the AP that has indicated its willingness to participate in the shared TXOP and has been assigned a schedule in the received frame (i.e., participating AP) may transmit a CAP TXOP Local Schedule (CTL) or NDPA frame. The CTL or NDPA frame may include an indication that the upcoming TXOP will be used for multi-AP detection. The CTL or NDPA frame may include a detection transmission schedule for one or more member APs participating in multi-AP detection. The CTL or NDPA may also include the type of desired feedback. The CTL or NDPA may also include a listening schedule for associated STAs. The listening schedule for the associated STA may include time, channel / RU / link, and multiple APs on which one or more associated STAs can perform monitoring. One or more associated STAs may be explicitly identified in the CTL or NDPA. The terms CTL and CAP TXOP Local Advertisement (CTLA) may be used interchangeably throughout this disclosure.

[0179] At a time after the CTAS or NDPA frame, eg, a SIFS time after the end of the CTL or NDPA, the member APs may follow the sounding schedule to transmit their sounding frames or NDP frames on the channel / RU and / or link during that time.

[0180] STAs associated with member APs may receive the probe frames based on the multi-AP probe schedule or multi-AP listening schedule assigned to them by their APs. They may calculate feedback based on the indicated desired feedback type.

[0181] In another MAPS transmission or shared TXOP or within the same shared TXOP, a coordinating AP or shared AP that may be in the same group of MAPS may indicate that the shared TXOP is intended for performing multi-AP feedback in a transmitted multi-AP feedback poll frame or CTI. Multi-AP detection and feedback for feedback collection or combination may also occur during a shared TXOP data transmission session. Multi-AP feedback poll frames or CTIs may be addressed to one or more APs, which may be member APs in the same MAPS.

[0182] After receiving a multi-AP feedback poll or CTI, member APs of the same MAPS or APs willing to participate in feedback collection can respond with a CTR or another frame. The CTR indicates that they are willing to participate in the shared TXOP feedback collection. The APs can indicate the preferred channel, time interval, and RU they want to use for collecting sounding feedback.

[0183] The coordinated or shared AP may respond to the CTR with a CTAS that may include a polling schedule for each of the AP and its BSS. The polling schedule may indicate a schedule, channel, RU, and / or link on which the AP may send a multi-AP detection feedback poll frame to one or more associated STAs of one or more BSS' associated with one or more member APs participating in multi-AP detection feedback. In one example, the CTR may include a response schedule for the BSS of one or more APs to provide their feedback for multi-AP detection, including a time range, channel, time slot, RU, link, etc.

[0184] After receiving a CTAS from a coordinating AP, a member AP or a scheduled AP in the CTAS may indicate to its associated STAs in a CTL frame or perform multi-STA detection feedback polling on a polling schedule for one or more associated STAs. The polling schedule may include which AP may perform feedback polling and the resources used, such as RUs, channels, time intervals, links, etc. In one example, the CTL frame may include a response schedule for one or more associated STAs. The response schedule may include resources on which one or more associated STAs may send their feedback for multi-AP detection, including time, channel, time slot, RU, link, etc. In another example, the response schedule may include resources on which one or more associated STAs may monitor trigger frames to solicit their feedback for multi-AP detection, including time, channel, time slot, RU, link, etc. The response schedule may include an indication of triggered access. The polling schedule or response schedule may be based on the assignment received from the shared AP or the coordinating AP.

[0185] A coordinated AP, member AP, or shared AP that receives a polling schedule from a coordinated or shared AP may send a multi-AP sounding feedback poll frame using the indicated resources to solicit sounding feedback from one or more associated STAs from one or more of the coordinated or shared APs.

[0186] The STA or MLD receiving the response schedule may use the indicated resources to send the sounding feedback. Additionally or alternatively, the STA or MLD receiving the response schedule may switch to the resources indicated to monitor the multi-AP sounding feedback poll to provide the requested feedback.

[0187] It is worth noting that the specific types of frames described are merely examples, and these frames may be any type of management frames, control frames, action frames, data frames, public action frames, or other types of frames.

[0188] Figure 6An exemplary multi-AP detection procedure 600 is shown, which can be used in conjunction with any of the other embodiments described herein. At step 610, one or more member APs in a multi-AP set (MAPS) may indicate to a coordinating AP (CAP) that the one or more member APs participate in concurrent or coordinated multi-AP detection in a shared TXOP. In one example, one or more member APs in a MAPS may transmit or may have transmitted one or more indications indicating that the one or more member APs are capable of performing multi-AP detection during a shared TXOP. The one or more indications may be included in a management frame, a control frame, an action frame, a data frame, a public action frame, or any other type of frame. At step 620, the coordinating AP may obtain a TXOP (or a shared TXOP) and send or broadcast a CAP TXOP indication (CTI) to one or more member APs. Part of a TXOP or the entire TXOP (or a shared TXOP) may be shared with one or more APs and / or the coordinating AP. The CTI may indicate the purpose of the shared TXOP. The purpose of the shared TXOP may include, but is not limited to, multi-AP detection, multi-AP detection feedback, and data transmission or a combination of multi-AP detection and multi-AP detection feedback. The coordinating AP may obtain a TXOP (or a shared TXOP) through, for example, EDCA or other channel access methods. The CTI may be a management frame, a control frame, an action frame, a data frame, a public action frame, or any other type of frame. In one example, the CTI may include one or more indications, such as an indication of multiple APs probing a TXOP, an indication of probing feedback a TXOP, etc.

[0189] At step 630, one or more member APs may transmit a CAP TXOP request (CTR) to the coordinating AP in response to the CTI. The CTR may indicate that one or more member APs (e.g., transmitting APs) are willing to perform the activity indicated by the CTI during the shared TXOP. For example, the CTR may indicate that one or more member APs of the MAPS are willing to perform multi-AP detection or multi-AP detection feedback during the shared TXOP. The one or more member APs may be interchangeably referred to as participating APs. The participating APs may be a subset of the MAPS or all member APs in the MAPS. For example, in a MAPS including four member APs, three of the member APs may transmit a CTR to indicate that they are willing to participate in the activities (e.g., detection or feedback) in the shared TXOP. The CTR may be a management frame, a control frame, an action frame, a data frame, a public action frame, or any other type of frame.

[0190] At step 640, the coordinating AP may transmit or broadcast a CAP TXOP AP Schedule (CTAS) or Null Data Packet Advertisement (NDPA) to one or more member APs. The CTAS or NDPA may indicate the transmission schedule and resource allocation to be performed by the one or more member APs during the shared TXOP. In one example, the CTAS may indicate the transmission schedule for one or more sounding frames to be transmitted by the one or more member APs during the shared TXOP. The CTAS or NDPA may also be transmitted to one or more STAs associated with the one or more member APs. In other words, the one or more STAs associated with the one or more member APs may overhear the transmission of the CTAS or NDPA, allowing them to provide additional assurance for activities to be performed during the shared TXOP (e.g., sounding or feedback). The CTAS may be a management frame, a control frame, an action frame, a data frame, a public action frame, or any other type of frame. Alternatively or additionally, the CTAS may be transmitted within a management frame, a control frame, an action frame, a data frame, a public action frame, or any other type of frame. The CTAS frame may include AP sounding frame transmission resources and / or an AP sounding frame transmission orthogonal sequence.

[0191] The transmission schedule may indicate the scheduling of one or more member APs (or the scheduling of the coordinating AP) or resource allocation for activities performed by one or more member APs (or the coordinating AP) during a shared TXOP. For example, the transmission schedule may indicate the scheduling of one or more member APs (or the scheduling of the coordinating AP) for sounding performed by one or more member APs (or the coordinating AP) during a shared TXOP. In one example, during a shared TXOP, AP 1, which is the coordinating AP, may transmit sounding frames according to the transmission schedule, and APs 2-4, which are member APs in a MAPS, may transmit sounding frames according to the transmission schedule. The transmission schedule and resource allocation for multiple member APs (and the coordinating AP) may be the same or different, depending on: (1) the geographic location of the member APs, STAs, or coordinating APs; and / or (2) a coordinated multi-AP transmission scheme, such as coordinated spatial reuse, coordinated OFDMA, coordinated TDMA, coordinated beamforming / nulling, joint transmission. For example, some member APs may receive a portion / subset of the transmission schedule based on their geographic location or transmission scheme, and other member APs may receive a different portion / subset of the transmission schedule based on their geographic location or transmission scheme. In another example, some member APs may receive the transmission schedule, but other member APs may not receive any transmission schedule, depending on their geographic location and / or their transmission scheme.

[0192] The CTAS or NDPA may include at least one transmission resource indicating a transmission schedule for activities to be performed by one or more member APs (or coordinating APs) during a shared TXOP. For example, the CTAS or NDPA includes transmission resources for a sounding frame transmission schedule performed by one or more member APs during a shared TXOP. Specifically, one or more member APs may transmit sounding frames to one or more STAs associated with the one or more member APs according to the transmission schedule during a shared TXOP. Transmission resources may include, but are not limited to, time, frequency, channel, resource unit, time interval, link, and orthogonal sequence. The coordinating AP may determine the transmission schedule based on the transmission resources. For example, the coordinating AP may determine the sounding frame transmission schedule based on time information and / or frequency information of the transmission resources. Alternatively or additionally, the coordinating AP may determine the sounding frame transmission schedule based on an orthogonal sequence included in the transmission resource. The orthogonal sequence may be a P matrix or code that can identify different signals / frequencies / times of different users (e.g., member APs, STAs, or coordinating APs). Orthogonal sequences that can identify different signals / frequencies / times of different users (eg, member APs, STAs, or coordinating APs) can be constructed by the Kronecker product of a seed sequence and an orthogonal matrix or code.

[0193] At step 650, one or more member APs (or participating APs) may transmit a CAP TXOP Local Advertisement (CTLA) or NDPA to one or more STAs associated with the one or more member APs. The CTLA may indicate to the one or more STAs that the shared TXOP will be used for activities performed by the one or more member APs. For example, for activities performed during the shared TXOP (e.g., probing), the CTLA may include a probing transmission schedule for the one or more member APs and / or a listening schedule for the one or more STAs associated with the one or more member APs. Based on the transmission schedule and / or listening schedule in the CTLA, the one or more STAs associated with the one or more member APs may understand on which channel, time, time period, frequency, order, and / or orthogonal sequence the one or more STAs receive transmissions (e.g., probing frames) from the one or more member APs.

[0194] At step 660, the one or more member APs (or participating APs) can transmit frames (e.g., probe frames) according to the transmission schedule for the shared TXOP period. The one or more member APs can transmit the frames (e.g., probe frames) using the transmission resources indicated by the coordinating AP. In the example where the member APs 1-4 are in the MAPS, the channel is 80 MHz, and the shared TXOP is 4 ms, the coordinating AP can allocate the entire 80 MHz channel to the member AP 1 during the first 1 ms of the shared TXOP. The coordinating AP can allocate the entire 80 MHz channel to each of the member APs 2, 3, 4 during the second, third, and fourth 1 ms of the shared TXOP, respectively. Each of the member APs 1-4 can transmit probe frames to its associated STAs according to the transmission schedule as described above. In another example where the member APs 1-4 are in the MAPS, the channel is 80 MHz, and the shared TXOP is 4 ms, the coordinating AP can allocate the entire 4 ms of the shared TXOP to the member AP 1 to transmit frames on the first 20 MHz. The coordinating AP can allocate the entire 4 ms of the shared TXOP to each of the member APs 2, 3, 4 to transmit frames on the second, third, and fourth 20 MHz, respectively. Each of the member APs 1-4 can transmit probe frames to its associated STAs according to the transmission schedule as described above.

[0195] At step 670, the one or more STAs associated with the one or more member APs can monitor for frames (e.g., probe frames) according to the indicated transmission schedule and / or transmission resources (e.g., multi-AP probe schedule and / or probe frame transmission resources). The one or more STAs can receive the probe frames from the one or more member APs and then compute feedback indicating channel state. At step 680, the coordinating AP can acquire another TXOP for other actions or activities to be performed by the one or more member APs during the TXOP. For example, once the coordinating AP acquires another shared TXOP, the coordinating AP can transmit another CTI frame to the one or more member APs in the MAPS indicating that multi-AP probe feedback is to be performed during the other shared TXOP.

[0196] Figure 7A An example AP probe frame transmission schedule 701 employing frequency resource partitioning is shown, which can be used in conjunction with any of the other embodiments described herein. As shown, the schedule 701 can include a first 20 MHz subchannel 702, a second 20 MHz subchannel 704, a third 20 MHz subchannel 706, and a fourth 20 MHz subchannel 708. The schedule 701 can be used in conjunction with the example described above where the member APs 1-4 are in the MAPS, the channel is 80 MHz, and the shared TXOP is 4 ms. In this example, the coordinating AP can allocate the entire 80 MHz channel to the member AP 1 during the first 1 ms of the shared TXOP. The coordinating AP can allocate the entire 80 MHz channel to each of the member APs 2, 3, 4 during the second, third, and fourth 1 ms of the shared TXOP, respectively. Each of the member APs 1-4 can transmit probe frames to its associated STAs according to the transmission schedule as described above. Figure 7AAs shown, the coordinating AP can determine the transmission schedule by allocating the entire TXOP to APs 1-4 and by dividing the entire frequency to each AP 1-4 to transmit frames on the divided frequency during the TXOP. For example, if APs 1-4 are member APs in a MAPS, the entire frequency is 80 MHz, and the shared TXOP is 4 ms, the coordinating AP can allocate the entire 4 ms of the TXOP to AP 1 to transmit one or more frames on the first 20 MHz channel 705. The coordinating AP can allocate the entire 4 ms of the TXOP to AP 2 to transmit one or more frames on the second 20 MHz channel 710. The coordinating AP can allocate the entire 4 ms of the TXOP to AP 3 to transmit one or more frames on the third 20 MHz channel 715. The coordinating AP can allocate the entire 4 ms of the TXOP to AP 4 to transmit one or more frames on the fourth 20 MHz channel 720.

[0197] Figure 7B An exemplary AP sounding frame transmission schedule 702 employing time resource partitioning is shown, which can be used in conjunction with any of the other embodiments described herein. Figure 7B As shown, the coordinating AP may determine a transmission schedule by allocating the entire frequency to APs 1-4 and by dividing the TXOP into each AP 1-4 to transmit frames on the entire frequency during the divided time periods. For example, if APs 1-4 are member APs in a MAPS, the entire frequency is 80 MHz, and the shared TXOP is 4 ms, the coordinating AP may allocate the entire 80 MHz frequency to AP 1 to transmit one or more frames during a first time period (e.g., 1 ms) of TXOP 725. The coordinating AP may allocate the entire 80 MHz frequency to AP 2 to transmit one or more frames during a second time period (e.g., 1 ms) of TXOP 730. The coordinating AP may allocate the entire 80 MHz frequency to AP 3 to transmit one or more frames during a third time period (e.g., 1 ms) of TXOP 735. The coordinating AP may allocate the entire 80 MHz frequency to AP 4 to transmit one or more frames during a fourth time period (e.g., 1 ms) of TXOP 740.

[0198] Figure 7C An exemplary AP sounding frame transmission schedule 703 employing frequency and time resource partitioning is shown, which can be used in conjunction with any of the other embodiments described herein. Figure 7BAs shown, the coordinating AP can determine the transmission schedule by allocating the first half of the frequencies to AP 1-2 and the second half of the frequencies to AP 3-4 and by equally dividing the entire TXOP to AP 1-2 and AP 3-4 to transmit frames on the allocated frequencies during the divided time periods. For example, in a case where AP 1-4 are member APs in a MAP, the entire frequency is 80 MHz, and the TXOP being shared is 4 ms, the coordinating AP can allocate one 40 MHz channel to AP 1 to transmit one or more frames during the first time period (e.g., 2 ms) of TXOP 745. The coordinating AP can allocate another 40 MHz channel to AP 2 to transmit one or more frames during the first time period (e.g., 2 ms) of TXOP 750. The coordinating AP can allocate one 40 MHz channel to AP 3 to transmit one or more frames during the second time period (e.g., 2 ms) of TXOP 755. The coordinating AP can allocate another 40 MHz channel to AP 4 to transmit one or more frames during the second time period (e.g., 2 ms) of TXOP 760.

[0199] Figure 7D An example AP probe frame transmission schedule 704 with orthogonal sequences is shown, which can be used in conjunction with any of the other embodiments described herein. As shown, APs 1-4 can be allocated the entire frequency and the entire TXOP, but APs 1-4 can transmit frames based on orthogonal sequences. Note that the transmission schedules and / or transmission resources herein are not limited to those shown in FIG. 7, and can include other various transmission schedules and / or transmission resources depending on the multi-AP transmission scheme and / or the geographic locations of the coordinating AP, member APs, and / or STAs. Figure 7D 7A to 7D

[0200] Embodiments for coordinated multi-AP transmission procedures are described herein.

[0201] Figure 8 An example coordinated multi-AP transmission procedure 800 is shown, which can be used in conjunction with any of the other embodiments described herein. As shown, APs 1-4 can be allocated the entire frequency and the entire TXOP, but APs 1-4 can transmit frames based on orthogonal sequences. Note that the transmission schedules and / or transmission resources herein are not limited to those shown in FIG. 8, and can include other various transmission schedules and / or transmission resources depending on the multi-AP transmission scheme and / or the geographic locations of the coordinating AP, member APs, and / or STAs. Figure 8 ​​As shown, at step 805, an AP (e.g., AP 1) may become a shared AP. At step 810, the shared AP may select one or more shared APs in a multi-AP set (MAPS). At step 815, each shared AP may determine its receiving STAs. At step 820, the shared AP may obtain path loss, RSSI, SINR, or other measurements between each pair of shared APs / shared and STAs, and at step 825, determine a set of minimum required MCS levels. Step 825 may include feedback / reporting from the STA to its associated AP and / or from the shared AP to the sharing AP. In this step, the sharing AP and the shared AP may exchange full or limited information for the upcoming MAPS transmission. At step 830, for each minimum required MCS level, the shared AP may determine an SR table and resource allocation scheme for all STAs. At step 835, the shared AP selects an SR table (e.g., spatial reuse scenario) and a corresponding resource allocation scheme that requires a minimum transmission duration or number of PPDUs. At step 840, for each STA, the shared AP may determine an effective MCS based on the actual SR level on the allocated resources. The detailed coordinated multi-AP transmission procedure is as follows. It is assumed that the APs can hear each other.

[0202] An AP can acquire a channel through channel sensing. An AP can determine to share a channel with all APs or a subset of APs in an AP candidate set or a multiple AP set (MAPS). Such an AP can be referred to as a shared AP.

[0203] The shared AP may determine the multi-AP transmission setting through frame exchange between APs and / or backhaul information exchange between APs.

[0204] In one embodiment, frame exchange between APs can be part of a TXOP so that settings can vary from TXOP to TXOP. In one embodiment, frame exchange can occur before a TXOP, and in the case where multiple MAPSs can be formed, a MAP setting can be identified by a temporary ID. The temporary ID can be referenced in the TXOP so that the AP and STA can know the MAPS used for the TXOP. Alternatively or additionally, a multi-AP setting can be identified by an AP candidate set ID, an AP ID in an AP candidate set, and / or an AP bitmap.

[0205] The multi-AP transmission settings may include: AP, potential STA, SINR / path loss and / or predetermined minimum required MCS level (PMRM).

[0206] Specifically, the AP may participate in coordinated multi-AP transmission in a TXOP.

[0207] Potential STAs can be part of a coordinated multi-AP transmission in a TXOP. In one example, each AP can determine its receiving STAs. In one example, each AP can determine its receiving STAs and exchange this information with other APs.

[0208] The SINR or path loss between each AP-STA pair can be obtained from the above-described detection procedure. In one example, each STA can measure the SINR, path loss, RSSI, or other types of channel quality measurements from each AP and report them to its associated AP. In one example, each STA can measure the SINR, path loss, RSSI, or other types of channel quality measurements from each AP and report them to its associated AP and unassociated APs. Alternatively or additionally, each AP can collect measurements from its associated STAs and exchange this information between each other. Alternatively or additionally, each AP can collect measurements from its associated STAs and report this information to a shared AP.

[0209] A predetermined minimum required MCS (PMRM) level can be associated with possible multi-AP scheduling scenarios. For example, a lower PMRM level can allow for more opportunities for multi-AP spatial reuse, while a higher PMRM level can allow for less opportunities. A shared AP can prepare several PMRMs with their desired scheduling goals and select the optimal scheduling scenario using specific criteria (e.g., maximizing overall throughput, reducing latency for certain services, etc.).

[0210] The shared AP can traverse all PMRMs and is specific to each PMRM.

[0211] A potential spatial reuse table (SR table) for all STAs can be determined for PMRM. Table 3 shows an example SR table. Each STA can have one entry in this table. This entry includes the APs that are allowed to perform spatial sharing. For example, STA1 can be associated with AP1 and, at the minimum required MCS level, still be able to decode reception from AP1 using PMRM even when AP2, AP3, and AP4 are performing concurrent or spatially reused transmissions. STA2 can be associated with AP2 and be able to decode when AP4 is transmitting.

[0212] Table 3: Example SR table for PMRM 1

[0213] STA1 {AP2, AP3, AP4} STA2 {AP4} … …

[0214] Based on the SR table and the association table (for example, the association table may indicate the transmitting AP / associated AP for each STA in the coordinated MAP transmission / spatial reuse MAP transmission), the AP may determine the resource allocation plan for all STAs with this PMRM. The resource allocation may be implementation-dependent. In one approach, the AP may reuse resources in the spatial domain as much as possible. The output resource allocation may be performed via one or more PPDUs with shared subchannels, as shown in Table 4. In this example, resource allocation in one PPDU with 4 subchannels is given. If one PPDU may not be sufficient to carry traffic for all STAs, more PPDUs may be scheduled. AP1 and AP4 may perform spatial reuse transmissions to STA1 and STA4, respectively, on channel 1. AP2 and AP4 may perform spatial reuse transmissions to STA2 and STA6, respectively, on channel 2. AP3 may transmit to STA5 on channel 3, and so on.

[0215] Table 4: Example resource allocation table for PMRM 1 and PPDU 1

[0216] PMRM 1, PPDU 1 Ch1 Ch2 Ch3 Ch4 AP1 STA1 … AP2 STA2 … AP3 STA5 … AP4 STA4 STA6 …

[0217] Based on the resource allocation table and the SINR / path loss / RSSI between each AP-STA pair, the shared AP can estimate the effective SINR of each STA and, therefore, the MCS of each STA. The AP can also estimate the number of OFDMA symbols required to carry data for each STA and, therefore, the PPDU duration.

[0218] The AP may iterate over all PMRMs and pick a resource allocation scheme based on certain criteria (eg, shortest PPDU duration).

[0219] The shared AP may transmit resource allocation information to the shared APs, and the shared AP may carry it in a multi-AP trigger frame or other types of frames.

[0220] Figure 9 Another exemplary coordinated MAP transmission procedure 900 is shown, which may be used in conjunction with any of the other embodiments described herein. Figure 9As shown, at step 905, an AP (e.g., AP 1) may become a shared AP. At step 910, the shared AP may select one or more shared APs in the MAPS. At step 915, each shared AP may determine a possible receiving STA. At step 920, the shared AP may obtain the path loss or RSSI or SINR or other measurement results between each pair of shared APs and STAs, and share the information with other APs or coordinated APs. At step 925, the shared AP may traverse all possible SR modes / tables. At step 930, the shared AP may select a possible MCS for the SR mode. If the lowest MCS cannot be supported, the SR mode may not be used. At step 935, the shared AP may determine the SR mode and allocated resources to maximize system throughput or minimize system latency. The detailed coordinated multi-AP transmission procedure is described below. It is assumed that the APs can hear each other.

[0221] An AP may share its candidate STAs with appropriate MCS information in a spatial reuse (SR) mode that is different from other APs in the coordinated AP set. A centralized AP or a shared AP or APs may construct an allocation table such as that in Table 4. The construction of the allocation may be an optimization problem with certain constraints and objectives to be solved. For example, a constraint may be that some STAs may not be scheduled in certain SR modes due to excessive interference, or a minimum allocation for each candidate STA. The objective may be to maximize the throughput of the coordinated AP set, such as Figure 9 As shown in .

[0222] If the allocation table is computed in a distributed manner by each AP, the objective or constraint can include an ordering criterion. For example, a binary decision variable (whether each STA will be scheduled on a channel) can be represented by a number x to jointly reflect the scheduling of the channels, and the constraint can enforce an order where the x value for one channel is greater than or equal to the x value for the next channel. This ordering ensures that the SR pattern of scheduling decisions made by different APs is consistent with decisions made by other APs.

[0223] and Figure 8 Compared to the illustrated embodiment, the scheduling AP / shared AP can know all information about each STA, such as traffic volume, RSSI / SINR / path loss, etc. The scheduling AP / shared AP can iterate through all possible SR modes. For each STA, the AP can select the MCS for that STA based on the effective SINR estimated using the SR mode. The AP can determine a set of SR modes for the STA using a resource allocation plan that maximizes local system throughput or minimizes transmission duration.

[0224] This article describes an implementation for a coordinated multi-AP detection and establishment procedure. In order to perform the above-mentioned coordinated multi-AP transmission, it may be necessary to exchange certain information between the AP and the STA or between the AP and the AP. In this implementation, as an example, the following two-step detection and setup procedure can be used:

[0225] Each STA can measure channel measurements / SINR / SNR / RSSI / path loss from its neighboring AP using frames transmitted at a known transmit power. For example, beacon frames, probe frames, etc. The STA can report this information to its associated AP (as shown in the table below). The report can be carried in the MAC header, for example, in the control field, etc., and transmitted along with any frame that can carry a control field. Alternatively or additionally, it can be carried in a control frame / action frame / management frame. It should also be noted that other types of measurement results related to signal strength, channel quality, and / or interference level can be used here.

[0226] Table 5: Example SNR / RSSI / PL measurement results

[0227] AP1 AP2 AP3 AP4 STA 1 SNR / RSSI / PL SNR / RSSI / PL SNR / RSSI / PL SNR / RSSI / PL

[0228] Figure 10 FIGURE 2 shows an exemplary frame exchange between APs, which may be used in conjunction with any of the other embodiments described herein. Figure 10 As shown, a shared AP (e.g., AP 1 1001a) can send resource allocations to STAs. Shared APs (e.g., AP 2 1001b and AP 3 1001c) can send back information about visible APs (or SR tables) or the SNR-per-STA from visible APs. The detailed frame exchange between APs is described below.

[0229] The AP may determine to participate in the coordinated multi-AP transmission as a shared AP. The AP may exchange necessary information for sharing the AP to perform multi-AP scheduling. The frame exchange between the APs may include the following steps.

[0230] A shared AP may transmit a frame to one or more shared APs to request information about the coordinated multi-APs. The shared AP may carry the following information:

[0231] The sharing AP may set a desired spatial reuse (SR) level so that the shared APs may provide spatial reuse tables accordingly. The desired SR level may be a predetermined minimum required MCS (PMRM) level.

[0232] A sharing AP may request information from a shared AP. The sharing AP may indicate what information it may request. For example, the sharing AP may request SINR / SNR / path loss measurements between each AP-STA pair. Alternatively or additionally, the sharing AP may request an SR table that may indicate potential SR APs allowed by the STAs. Alternatively or additionally, the sharing AP may provide a list of potential shared APs and request an MCS table that may indicate potential allowed MCSs when the AP's mode is transmitting at a certain power. For example, for shared AP 2 and other potential shared APs 3 and 4 that share AP 1, as well as STAs 2-1 and 2-2 associated with shared AP 2 that AP 2 intends to schedule, the appropriate MCS for the AP TX mode with transmit powers (AP 2), (AP 1, AP 2), (AP 3, AP 2), (AP 1, AP 2, AP 3), ... may be reported to AP 1 by AP 2 for STAs 2-1 and 2-2.

[0233] The shared AP may indicate the channels being shared. The shared AP may request each shared AP to report available channels. For example, the shared AP may indicate that it can acquire {ch1, ch2, ch3, ch4} for coordinated multi-AP transmission and request the shared AP to indicate availability on these channels.

[0234] The shared AP may respond with potential receiving STAs associated with the AP in an upcoming coordinated multi-AP transmission.

[0235] If a shared AP can request an SR table report, one or more SR tables based on the PMRM can be set by the shared AP. The SR table can be shown in Table 3. Alternatively or additionally, it can be shown in Table 6. A value of 1 can indicate that the STA can allow the AP to transmit when it can receive its desired AP. For example, STA 1 and STA 2 are potential receiving STAs from AP 2 (e.g., they are both associated with AP 2). Table 6 can be a report from AP 2 to the shared AP. In this table, AP 2 can indicate that when STA 1 receives a transmission from AP 2, it can allow SR transmissions from AP 1 and AP 3. When STA 2 receives a transmission from AP 2, it can allow SR transmissions from AP 3 and AP 4.

[0236] Table 6: SR table transmitted from shared AP to sharing AP for a given PMRM

[0237] AP1 AP2 AP3 AP4 STA1 1 1 1 0 STA2 0 1 1 1

[0238] If a shared AP can request a complete SNR / path loss / RSSI measurement report, an SNR / path loss / RSSI table can be transmitted from the shared AP to one or more shared APs. The SNR / path loss / RSSI table can be shown in Table 7. In this example, STA 1 and STA 2 are potential receiving STAs from AP 2 (e.g., they are both associated with AP 2). Each entry in Table 7 can indicate the SNR / path loss / RSSI between an AP-STA pair. For example, a value of 0 can be used to indicate that the link quality between the pair is below a predefined threshold. In other words, the STA may not receive transmissions from the AP. It should also be noted that other types of measurements related to signal strength, channel quality, and / or interference level can be used here.

[0239] Table 7: SNR / path loss / RSSI from the shared AP to the shared AP

[0240]

[0241] If the shared AP can request MCS reporting, the MCS table can be sent from the shared AP to the shared AP.

[0242] For example, AP 1 is a sharing / computing AP, and APs 2, 3, and 4 are potential shared APs. AP 2 intends to schedule associated STAs 2-1...STA 2-N. Shared AP 2 may send the following Table 8.

[0243] Table 8: MCS table for transmission from a shared AP to one or more shared APs

[0244] AP mode STA2-1 MCS / rate … STA2-N MCS / rate AP2 MCS_1,1 … MCS_1,N AP1+AP2 MCS_2,1 … MCS_2,N … … … … AP1+AP2+AP3+AP4 MCS_K,1 … MCS_K,N

[0245] In the table, for example, MCS_K,1 is the best / suitable rate for STA 2-1 in AP TX mode with all APs 1, 2, 3, 4 transmitting at known power.

[0246] If the transmitting AP's power deviates from the known power, the shared AP can use this information to further derive the appropriate MCS for a particular AP TX mode. For example, MCS_1,1 = x corresponds to an SNR threshold SNR_x and MCS_2,1 = SNR_y. If AP 2 increases its transmit power by mdB and AP 1 decreases its transmit power by ndB, then based on x and y, the shared AP can calculate another set of MCSs for STA 2-1 at the adjusted powers of AP 1 and AP 2.

[0247] Furthermore, if the reporting STA is experiencing different fading channels, the shared AP can report outer-loop rate control information for the reporting STA. For example, MCS_K,1=x may correspond to the SNR threshold SNR_x,1 for STA 2-1, but MCS_K,N=x may correspond to a different SNR threshold SNR_x,N for STA 2-N. The SNR threshold SNR_{MCS}_{STA id} may be reported, or a value representing the mapping.

[0248] Furthermore, if the reporting STA is experiencing different fading channels, the shared AP can report outer-loop rate control information for the reporting STA. For example, MCS_K,1=x may correspond to the SNR threshold SNR_x,1 for STA 2-1, but MCS_K,N=x may correspond to a different SNR threshold SNR_x,N for STA 2-N. The SNR threshold SNR_{MCS}_{STA id} may be reported, or a value representing the mapping.

[0249] In addition, each entry in the table may be accompanied by an SNR margin for the MCS value of that entry. For example, (MCS_K,1,ydB) may mean that the SNR of STA 2-1 may be further reduced by y dB, but STA 2-1 can still correctly receive the PPDU with a high probability using MCS_K,1.

[0250] A shared AP may respond with channel availability. Given a channel acquired by a shared AP, each shared AP may indicate channel / subchannel availability. For example, a shared AP may acquire {ch1, ch2, ch3, ch4} for coordinated multi-AP transmission. Each AP may report channel availability. In one embodiment, a shared AP may report available or unavailable channels, which may be a subset of the acquired channels. In one embodiment, a shared AP may report a bitmap. In this example, the bitmap may have a length of n (e.g., a length of 4), and each bit may indicate whether a channel is available to the AP.

[0251] like Figure 10As shown, a shared AP (e.g., AP 1 1001a) may execute a resource allocation / scheduling algorithm and send a schedule to shared APs (e.g., AP 2 1001b and AP 3 1001c). Table 4 shows an example of a schedule. The shared AP may also indicate the transmit power to be used by each shared AP in the upcoming coordinated multi-AP transmission. Transmit power settings may be per-AP and / or per-frequency resource and / or per-STA. For example, as shown in Table 4, frequency resource channel 1 is assigned to AP 1 for transmission to STA 1 and assigned to AP 4 for transmission to STA 4. In one embodiment, the shared AP may assign transmit powers to AP 1 and AP 4 on channel 1. In one embodiment, the shared AP may allow AP 1 and AP 4 to transmit using the same transmit power. The transmit power may be selected to be the minimum power that can cover the expected receiving STAs. In one embodiment, the shared AP may set different powers for AP 1 and AP 4 based on information exchanged between the APs, such as traffic information and SNR / SINR / path loss information. For example, AP 1 can be assigned a higher transmit power than AP 4, allowing it to transmit at a higher MCS. The shared AP can carefully select power so that AP 4 can still transmit to STA 4 using the base MCS. Power control can be part of the scheduling algorithm. Therefore, the scheduling method can generate a schedule and power allocation.

[0252] The shared AP may determine the MCS for its desired STAs based on the schedule and the transmit power set by the sharing AP.

[0253] Simulation results are described here. In a largely coordinated OFDMA scenario, if a subchannel (or RU) is occupied by one AP, other APs in the AP candidate set may not use that subchannel to maintain perfect orthogonality in the frequency domain if zero inter-BSS interference cannot be achieved. However, perfect zero interference may not be necessary, as long as a specific SNR level that provides spatial reuse opportunities can be achieved for the desired MCS level.

[0254] Figure 11 and Figure 12 Example spatial reuse (SR) coverage maps 1100 and 1200 when the predetermined minimum required SNR is set to 5 dB and 10 dB, respectively, which can be used in combination with any of the other embodiments described herein. In a multi-AP scenario, an AP's "SR coverage" can have many different patterns in terms of the number of other APs (or which other APs) that can transmit simultaneously, such as Figure 11 and Figure 12As shown in . In these figures, the predetermined minimum required SNR is set to 5dB and 10dB respectively. Assume that multiple (e.g., four) APs have the following simulation assumptions:

[0255] Scene: Office Space

[0256] There are 4 APs on a 3m high ceiling

[0257] Transmit power from each AP: 20dBm, omnidirectional

[0258] Path loss model

[0259] PL(d)=40.05+20*log10(fc / 2.4)+20*log10(min(d,10))+(d>10)*35*log10(d / 10)

[0260] fc=5GHz

[0261] AWGN channel, NF = 7dB

[0262] Total 80MHz channel bandwidth with four 20MHz RUs

[0263] DL transmission

[0264] Business Type: Full Buffer

[0265] The scheduler manages resource usage at the shared AP

[0266] Each AP randomly selects two associated STAs before scheduling. Each STA has one antenna and can therefore support one data stream transmission.

[0267] Figure 11 and Figure 12 10dB, respectively. STAs located in circular areas 1105, 1205 with the legend sr = 0 do not allow any non-associated AP to transmit simultaneously with their associated AP. STAs located in cross-regions 1110, 1210 with the legend sr = 1 may allow one non-associated AP to transmit simultaneously with its associated AP. STAs located in square areas 1115, 1215 with the legend sr = 2 may allow two non-associated APs to transmit simultaneously with their associated AP. STAs located in triangular areas 1120, 1220 with the legend sr = 3 may allow three non-associated APs to transmit simultaneously with their associated AP.

[0268] The detailed SR coverage map may depend on the transmit power, required MCS level, relative distance between APs, RF radiation pattern, etc. Figure 11 and Figure 12 In

[15] , it is assumed that the transmit power from each AP is the same (e.g., 20 dBm). It is observed that the spatial reuse area can be larger. Therefore, when coordinated OFDMA (C-OFDMA) is enabled, combining it with coordinated SR (C-SR) can enhance the overall system throughput performance.

[0269] Figure 13 An exemplary throughput comparison 1300 between different scheduling schemes is shown, which may be used in conjunction with any of the other embodiments described herein. Figure 13 As shown, three different scheduling methods are compared:

[0270] In coordinated OFDMA 1305, each AP can allocate a 20 MHz sub-channel to one user.

[0271] In coordinated SR and coordinated OFDMA using the optimal method 1315, all possible SR modes, MCS levels, and resource allocations can be considered. The SR mode and resource allocation that maximizes the overall rate are determined and constrained by the following conditions: for each PPDU, one RU can be allocated to at most one STA within the BSS; and if the SINR is too low to achieve MCS0, SR will not be scheduled for the STA. Integer programming techniques can be used.

[0272] In coordinated SR and coordinated OFDMA using suboptimal method 1310, based on a simple SR table (including logic "0" or "1") received from the shared AP, a resource allocation scheme can be determined for a medium MCS level (e.g., MCS4) that can provide a good compromise between pure SR and pure OFDMA.

[0273] Based on this simulation, in the case of coordinated OFDMA, all STAs can use the highest MCS for a single data stream. If coordinated SR is added on top of coordinated OFDMA, the total throughput improves by up to 25% in 50% of cases. Suboptimal implementations (i.e., low overhead) can also provide improvements (median 12%) with limited measurement and feedback.

[0274] This document describes an implementation for multiple AP sets acting as full-duplex APs.

[0275] Figure 14 An exemplary scenario 1400 is shown in which a set of multiple APs coordinate and operate as full-duplex APs, which can be used in conjunction with any of the other embodiments described herein. Figure 14The extension of the multiple AP set shown as full-duplex APs is applicable to Figure 4 In this example scenario 1400, AP 2 1401b is transmitting and AP 1 1401a is receiving at the same time-frequency resources. Figure 14 The embodiments described in or associated with this figure may be applied to other embodiments of the system to achieve full-duplex TXOP.

[0276] like Figure 14 As shown, AP 2 1401b (as a TXOP holder / responder or a multi-AP coordinator / coordinated party) may send a setup frame such as a MU-RTS / RTS frame 1405, or a separate setup frame before or after the MU-RTS / RTS frame 1405. The setup frame may not be transmitted with any precoding matrix. The setup frame may include precoding matrix information V2 or a set of precoding matrices to be used by AP 2 1401b for subsequent data transmission. AP 1 1401a, knowing the MIMO channel H12 from AP 2 1401b to AP 1 1401a, may derive a new channel matrix H12B=H12*V2, which may be the interference channel during the data transmission duration that AP 2 1401b may transmit to its target STA (e.g., STA 2 1402b). AP 1 1401a may derive a precoding matrix V1 or a set of precoding matrices to place beamforming nulls at AP 2 1401b for use during the data transmission duration. For example, AP 1 1401a may derive V1 as a subset of the null space of (H12B)' or by using other techniques such as a MUSIC / PCA algorithm based on the column vectors of H12B.

[0277] Alternatively or additionally, V2 may not be explicitly signaled, but an additional training field / pilot sent with the setup frame will identify H12B. For example, AP 2 1401b may transmit an initial frame (e.g., a MU-RTS / RTS frame) with two reference symbols. The first reference symbol may not be precoded and may be used for channel estimation (e.g., an LTF symbol). The second reference symbol may be precoded with V2 or a matrix set (e.g., the second reference symbol may be inserted into the PPDU or appended to the end of the PPDU). By comparing the channels estimated using the two reference symbols, the receiver (e.g., AP1) can estimate the precoding matrix V2 or multiple precoding matrices.

[0278] AP 1 1401a may transmit a trigger frame (TF) 1410 using the derived V1 beamforming / precoding, so that AP 2 1401b is not interfered with by this transmission. Alternatively or additionally, AP 1 1401a may have a priori CSI information about its associated STAs, allowing AP 1 1401a to know which STAs (e.g., STA 1 1402a and / or STA 2 1402b) are reachable by the beamformed TF 1410. AP 1 1401a may transmit the TF using a precoding scheme that boosts transmit power in the direction of the target STA while simultaneously de-asserting it in the direction of AP 2 1401b. TF 1410 may then schedule UL transmissions for a subset of these STAs (e.g., STA 1 1402a and / or STA 2 1402b). Alternatively or additionally, TF 1410 may schedule a UORA RU so that STAs (e.g., STA 1 1402a and / or STA 2 1402b) capable of receiving TF 1410 can perform UL random access on the UORA RU. Because TF 1410 is beamformed / precoded, it may not interfere with AP2's reception of a CTS (response) frame from STA 2 1402b. The CTS (response) frame 1415 may be power-controlled based on the path loss between AP 2 1401b and STA 2 1402b, or may be transmitted at a predetermined power.

[0279] STA 1 1402a may perform a test (e.g., based on the reception quality of the TF, channel reciprocity, and / or a priori information about the transmit power of STA 2 1402b's CTS / response frames) to determine whether its transmission will interfere with STA 2 1402b's reception. If not, it may continue to respond to TF 1410. The response TB-PPDU 1430 may be power controlled based on path loss information between STA 1 1402a / AP 1 1401a and / or STA 1 1402a / STA 2 1402b.

[0280] AP 1 1401a may then switch to receive mode (e.g., receive the TB PPDU 1420) and may use V1 as a decorrelator to separate the signal of the TB-PPDU from STA 1 1402a from interference from the DL data from AP 2 1401b. AP 2 1401b may switch to transmit mode (e.g., transmit DL data 1425) and may use V2 as a precoder to avoid interference with AP 2 1401b's reception and beamform the DL data to STA 2 1402b. STA 2 1402b may receive DL data 1435 from AP 2 1401b. AP 1 1401a may transmit a block acknowledgment (BA) 1445 to STA 1 1402a. STA 2 1402b may transmit a BA 1440 to both APs 1401a and 1401b.

[0281] The above embodiments assume that transmitter AP 2 1401b provides V2 to receiving AP 1 1401a, and AP 1 1401a can use the resulting channel to derive V 1. Alternatively or additionally, receiving AP 1 1401a can provide V 1 to transmitter AP 2 1401b (e.g., explicitly signaling V 1 or using training fields / pilots as described above) and transmitter AP 2 1401b can use the resulting channel to derive V 2.

[0282] This document describes an implementation for a NAV setup procedure.

[0283] STAs may continue to use multiple (e.g., two) NAV timers, one for intra-BSS and one for inter-BSS. When participating in a TXOP whose holder is an OBSS AP, a STA may check both the intra-BSS NAV and the basic / inter-BSS NAV before responding to a TF, e.g., not responding if either NAV is busy. The terms inter-BSS NAV and basic NAV may be used interchangeably throughout this disclosure.

[0284] An OBSS AP that intends to perform a frame exchange with a STA not associated with itself may provide the STA with a list of zero or more NAV values ​​corresponding to multiple APs, and / or a list of BSSIDs / colors associated with these NAVs, for comparison with the STA's base NAV. These NAVs may be the most recent BSS (intra) NAV values ​​for its own BSS and neighboring BSSs that the STA may ignore when responding to the OBSS AP's TF. If no NAV and associated BSS color are provided, the STA may assume that there are no pending NAVs from the OBSS AP's BSS prior to the OBSS TXOP.

[0285] In one example, if the STA's basic NAV matches one of the NAV values ​​in the list, or the last frame / PPDU that updated the basic NAV came from the BSS of the OBSS AP or one of the BSSs identified in the list, the STA may reset the basic NAV to 0 (i.e., the basic NAV indicates idle).

[0286] In another example, if the STA's basic NAV is greater than any NAV value in the list provided by the AP, which may include the NAV of the OBSS AP, the STA may maintain the value of the basic NAV and continue counting down (ie, the basic NAV indicates busy).

[0287] In another example, if the STA's basic NAV is less than at least one of the NAV values ​​in the list, the STA may reset the basic NAV to 0. If the most recently updated basic NAV is due to a frame sent by a transmitter that does not belong to the BSSID / BSS color list provided by the OBSS AP, the STA may maintain the basic NAV value to continue counting down.

[0288] When receiving a frame / PPDU with a BSSID / color belonging to an OBSS AP that is the TXOP holder and the STA is participating in a TXOP, the STA may not keep the Basic NAV updated. The STA may keep its intra-BSS NAV updated while participating in the OBSS AP's TXOP. If required by the CS, the STA may respond to the OBSS AP's TF subject to both intra-BSS and Basic NAV checks (e.g., after updating the Basic NAV in the above procedure). When responding to a TF with the CS set to 1, the OBSS AP may request that the STA check only the Basic NAV or the intra-BSS NAV. In this case, the STA may not perform other NAV checks before responding. Frames from the OBSS AP that is the TXOP holder may include a signature from the AP to which the STA is associated. When requesting to ignore the intra-BSS NAV / Basic NAV or other Basic NAVs by comparison, the STA may check the validity of such signatures before responding with a TB-PPDU or resetting the Basic NAV. Upon completing the frame exchange with the OBSS AP, if its duration is greater than the current basic NAV value, the STA may update its basic NAV to a value based on the latest OBSS frame.

[0289] When participating in the TXOP of an OBSS AP, the STA's basic NAV may not be updated by frames / PPDUs from the BSS of the OBSS AP, but may be updated by frames / PPDUs from other OBSSs.

[0290] Implementations for buffer status reporting (BSR) are described herein.

[0291] A new A control field may be defined to support BSR with TID granularity. The new A control may have a similar structure to the current BSR control. New or existing A controls may be used for BSR or traffic indication for DL ​​or UL.

[0292] The new A widget may have a bitmap that provides at least a binary indication of whether traffic for each TID is buffered.

[0293] In one example, the new A-control field may carry buffer status information / reports for one or more links. Throughout this disclosure, the term link may refer to a frequency band and / or a channel. In the new A-control, a subfield may identify the mode of TID link mapping. For example, 1001 indicates that TIDs mapped to link 1 and link 4 are reported in the new A-control. Alternatively or additionally, the subfield may identify a link so that the TID mapped to that link is reported in the new A-control.

[0294] The subfields in this new A control may identify the TID, and the queue size field may indicate the queue size for the TID.

[0295] The TID of a QoS frame (e.g., a QoS null frame with a TID signaled in a QoS control) may implicitly signal the TID for the queue size subfield in a new or existing BSR A control. In this case, the queue size field may indicate the queue size of the TID.

[0296] A set of bits in the QoS control (eg, bits 8 to 15) may be combined with the A control to form a new control, providing more detailed buffer status with higher granularity related to a subset or all TIDs.

[0297] In a QoS null frame, a set of bits (e.g., bits 8 to 15) in the QoS control or sequence control may be combined with the A control to form a new control, providing more detailed buffer status with higher granularity related to a subset or all TIDs.

[0298] In a trigger frame or a PPDU carrying a trigger frame, an indication may be signaled that UORA access in response to a trigger frame on a link carrying the trigger frame may be (e.g., partially) restricted / prohibited for an MLD having another enabled / reachable link. The identification of the other link may be signaled in the trigger frame / PPDU. Alternatively or additionally, such restriction and / or identification may be signaled in a broadcast frame preceding the trigger frame. In a trigger frame or a PPDU carrying a trigger frame, an indication may be signaled that UORA access in response to a trigger frame may be (e.g., partially) restricted / prohibited for certain MLDs. Alternatively or additionally, such restriction may be signaled in a broadcast frame preceding the trigger frame. The UORA TB-PPDU may be used to carry a frame including the new or existing BSR described above.

[0299] MU-EDCA timers can be defined at the TID granularity. MU-EDCA timers for a TID / AC can be applied at the MLD level, so that all links to which the TID / AC is mapped can use the same MU-EDCA timer instance for EDCA access for that TID / AC. MU-EDCA timers for a TID / AC can be applied at the per-link level, so that each link to which the TID / AC is mapped has a different MU-EDCA timer instance for EDCA access for that TID / AC.

[0300]

[0014] Described herein are implementations of a coordinated multi-AP probing procedure for a wired backhaul. Figure 15 An example of a Wi-Fi network or multiple APs with a wired backhaul connection is shown. Figure 15 As shown, a domain controller 1505, which acts as a server, can be connected to APs 1, 2, 3, 1501a, 1501b, and 1501c via wired links, which can be used in combination with any of the other embodiments described herein. The domain controller 1505 can also be connected to a gateway 1501 and the Internet 1515 via wired links. Each of the multiple APs 1, 2, 3, 1501a, 1501b, and 1501c can be connected to STAs 1502a, 1502b, 1502c, 1502d, 1502e, and 1502f via wireless links.

[0301] Assume that AP 1 1501a acquires the medium through a contention process and becomes the TXOP owner. It may then transmit a "Coordination Request" frame to other shared AP candidates in the AP candidate set in the network (e.g., AP 2 1501b, AP 3 1501c) via a wired backhaul. Simultaneously or after a time offset, AP 1 1501a may send an NDP sequence via a wireless link to allow all STAs in the network (e.g., STAs 1502a, 1502b, 1502c, 1502d, 1502e, 1502f) to perform measurements and keep the medium busy. The length of the NDP may be included in a "Coordination Request" frame sent by AP 1 1501a, which may be forwarded to all STAs (e.g., STAs 1502a, 1502b, 1502c, 1502d, 1502e, 1502f) via their associated AP 1 (e.g., APs 1501a, 1501b, 1501c). The length of the NDP may be specific to a STA (e.g., STAs 1502a, 1502b, 1502c, 1502d, 1502e, 1502f) and its associated AP (e.g., APs 1501a, 1501b, 1501c) to set the timing (e.g., frequency or time) for measurement feedback in an orthogonal manner between the BSSs of the shared APs (e.g., APs 2 1501b, AP 3 1501c). After each shared AP candidate (e.g., AP 2 1501b, AP 3 1501c) receives channel measurement results from its associated STAs (e.g., STAs 1502c, 1502d, 1502e, 1502f), it may choose not to participate in the coordinated transmission in that TXOP. Otherwise, it may send the channel measurement information received from its associated STAs (e.g., STAs 1502a, 1502b) to the shared AP (e.g., AP1 1501a) or the network controller for resource allocation and other decisions.

[0302] The above procedure may be repeated for each shared AP candidate (e.g., AP 1501b, 1501c) that may have committed to participate in the coordinated transmission during the process, starting with sending an NDP sequence to allow all STAs in the network under those committed shared AP candidates to perform channel measurements. The order of the repeated process for the shared AP candidates may be predetermined in the "Coordination Request" frame. However, any shared AP candidate may be dropped from the candidate set (i.e., become a non-committed shared AP candidate due to excessive interference), thereby changing the order of the repeated process that may be communicated between APs via the backhaul link.

[0303] Figure 16An example of a channel sounding procedure 1600 with a wired backhaul is shown, which may be used in conjunction with any of the other embodiments described herein. Figure 16 As shown, AP 1 1601a as a shared AP may transmit a coordinated multi-AP request frame 1605 to AP 2 1601b as a shared AP via a wired link. The coordinated multi-AP request frame may include information about the order of AP transmission of NDPs that can be used for channel measurement of all STAs associated with different APs, as well as the length of the NDP. Figure 16 In the example shown, AP 1 1601a transmits the NDP first, and AP 2 1610b transmits the NDP second. Before AP 1 1601a transmits the NDP, AP 2 1601b transmits a measurement trigger 1615 to its associated STAs so they are ready to measure the channel by receiving the NDP transmitted from the other AP (e.g., AP 1 1601a). AP 1 1601a may transmit one or more NDPs 1620 via a wireless link to all STAs (e.g., STA 1 1602a and STA 2 1602b), which may measure the channel 1625 and 1630, respectively. Any STA (e.g., STA 1 1602a and STA 2 1602b) that measures the channel based on the NDP sent from AP 1 1601a may send feedback of the channel measurement to its associated AP (e.g., STA 1 1602a to AP 1 1601a and STA 2 1602b to AP 2 1601b) via a wireless link. AP 1 1601a may send a measurement trigger frame 1645 to STA 1 1602a via a wireless link, so that STA 1 1602a will be ready to measure the channel by receiving the NDP sent from AP 2 1601b. AP 2 1601b may send one or more NDPs 1655 to all STAs that can measure the channel (e.g., STA 1 1602a and STA 2 1602b) via a wireless link. STA 2 1602b may measure its channel 1660 and transmit feedback for the channel measurement 1670 to AP 2 1601b via a wireless link. STA 1 1602a may measure its channel 1650 and transmit feedback for the channel measurement 1665 to AP 1 1601a via a wireless link.

[0304] exist Figure 16 In this example, only one shared AP and one STA under each AP are considered, but the number of APs and STAs is not limited. Figure 16As shown in Figure 1, “measurement trigger” → “measurement channel” → “feedback channel” is repeated from AP to AP. Since all APs share the same backhaul link, there is no need to exchange channel measurements between those APs via wireless channels, although they can be considered as additional links to achieve higher reliability or low latency. Note that Figure 16 It is shown that the channel feedback from the STA to the AP occurs simultaneously. In some embodiments, the channel feedback from the STA to the AP may occur sequentially, for example, based on TDMA principles, using different frequency resources and / or based on OFDMA principles.

[0305] Note that a "coordination request" may be a "probe request" that starts a probe procedure given an AP coordination set including one sharing AP and one or more shared APs.

[0306] Note that in this embodiment, the "wired" link between APs may be another wireless link / channel / frequency band than the wireless link / channel / frequency band used between the APs and STAs.

[0307] Although features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for use in a coordinated access point (CAP), the method comprising: receiving, from one or more member access points (APs) in a multi-AP set (MAPS) comprising a plurality of member APs, one or more indications that the one or more member APs are capable of performing multi-AP probing during a transmission opportunity (TXOP) acquired by the CAP; transmitting a CAP TXOP indication (CTI) frame to the one or more member APs in the MAPS, the frame indicating that the multi-AP detection will be performed during the TXOP acquired by the CAP; receiving a CAP TXOP request (CTR) frame from the one or more member APs, the frame indicating that the one or more member APs of the MAPS will perform the multi-AP sounding during the TXOP obtained by the CAP; as well as A CAP TXOP AP Schedule (CTAS) frame is transmitted to the one or more member APs, the frame indicating a transmission schedule for one or more sounding frames to be transmitted by the one or more member APs during the TXOP for the multi-AP sounding.

2. The method of claim 1, wherein the CTAS frame is transmitted in response to the CTR frame.

3. The method of claim 1, wherein the CTAS frame is transmitted to one or more stations (STAs) associated with the one or more member APs. 4 . The method according to claim 1 , wherein the CTAS frame comprises at least one transmission resource, the at least one transmission resource comprising at least one of time information or frequency information allocated for the transmission schedule of the one or more sounding frames.

5. The method of claim 1, wherein the CTAS frame comprises at least one transmission resource comprising an orthogonal sequence for the transmission schedule of the one or more sounding frames.

6. The method according to claim 1, further comprising: The transmission schedule of the one or more sounding frames is determined based on at least one of time information, frequency information, or an orthogonal sequence, wherein the time information, the frequency information, and the orthogonal sequence are included in the CTAS frame.

7. The method according to claim 1, further comprising: Another CTI frame is transmitted to the one or more member APs in the MAPS, the frame indicating that multi-AP detection feedback will be performed during another TXOP acquired by the CAP.

8. The method of claim 1, wherein the TXOP is a shared TXOP, the shared TXOP being a time period during which the one or more member APs are to transmit the one or more sounding frames according to the transmission schedule.

9. A coordination access point (CAP), the CAP comprising: processor; Receiver; and transmitter, The processor and the receiver are configured to receive, from one or more member APs in a multi-AP set (MAPS) comprising a plurality of member access points (APs), one or more indications that the one or more member APs are capable of performing multi-AP probing during a transmission opportunity (TXOP) acquired by the CAP; The processor and the transmitter are configured to transmit a CAP TXOP indication (CTI) frame to the one or more member APs in the MAPS, the frame indicating that the multi-AP detection will be performed during the TXOP acquired by the CAP; The processor and the receiver are configured to receive a CAP TXOP request (CTR) frame from the one or more member APs, the frame indicating that the one or more member APs of the MAPS will perform the multi-AP sounding during the TXOP acquired by the CAP; and The processor and the transmitter are configured to transmit a CAP TXOP AP Schedule (CTAS) frame to the one or more member APs, the frame indicating a transmission schedule for one or more sounding frames to be transmitted by the one or more member APs during the TXOP for the multi-AP sounding.

10. The CAP of claim 9, wherein the CTAS frame is transmitted in response to the CTR frame.

11. The CAP of claim 9, wherein the CTAS frame is transmitted to one or more stations (STAs) associated with the one or more member APs.

12. The CAP of claim 9, wherein the CTAS frame comprises at least one transmission resource including at least one of time information or frequency information allocated for the transmission schedule of the one or more sounding frames.

13. The CAP of claim 9, wherein the CTAS frame comprises at least one transmission resource comprising an orthogonal sequence for the transmission schedule of the one or more sounding frames.

14. The CAP according to claim 9, wherein the processor is configured to determine the transmission schedule of the one or more detection frames based on at least one of time information, frequency information, or an orthogonal sequence, wherein the time information, the frequency information, and the orthogonal sequence are included in the CTAS frame.

15. The CAP of claim 9, wherein the processor and the transmitter are configured to transmit another CTI frame to the one or more member APs in the MAPS, the frame indicating that multi-AP sounding feedback will be performed during another TXOP acquired by the CAP.

16. The CAP of claim 9, wherein the TXOP is a shared TXOP, the shared TXOP being a time period during which the one or more member APs are to transmit the one or more sounding frames according to the transmission schedule.

Images