Multi-RU / Multi-AP transmission in WLAN systems

Abstract

The present invention provides a method and apparatus for operation in a multi-access point (AP) wireless network. [Solution] The method performed by the AP may include using a set of resources to send a Multi-AP Transmit Ready (RTS) frame to at least one other AP and multiple stations (STAs). The method may include using a portion of the set of resources to send another frame. The method may include using a portion of the set of resources to receive a Transmit Ready (CTS) frame from at least one of the multiple STAs in response to another frame. The method may include using a portion of the set of resources to send a data frame to at least one STA. The Multi-AP RTS frame may include resource allocation information for at least one other AP and multiple STAs.

Description

[Technical Field]

[0001] (Cross-reference of related applications) This application claims the benefits of U.S. Provisional Patent Application No. 62 / 990,261, filed on 16 March 2020, the contents of which are incorporated herein by reference. [Background technology]

[0002] A Wireless Local Area Network (WLAN) in Infrastructure Basic Service Set (BSS) mode may include BSS access points (APs) and one or more associated stations (STAs). APs may have access to or interfaces with a Distribution System (DS) or another type of wired / wireless network that carries traffic within and outside the BSS. Traffic originating outside the BSS and associated with an STA may reach the STA through an AP and be delivered to the STA. Traffic originating from an STA and destined for an external destination may be transmitted to an AP and delivered to its respective destination. Traffic between STAs within the BSS may also be transmitted via an AP. For example, a source STA may transmit traffic to an AP, which may deliver the traffic to one or more destination STAs. A multi-access point (AP) wireless network may include multiple BSSs, multiple APs, and multiple associated STAs. [Overview of the project]

[0003] Methods and apparatus for operating in a multi-access point (AP) wireless network are described herein. A method performed by an AP may include using a set of resources to transmit a multi-AP ready-to-send (RTS) frame to at least one other AP and multiple stations (STAs). A method may include using a portion of the set of resources to transmit another frame. A method may include using a portion of the set of resources to receive a clear-to-send (CTS) frame from at least one of the multiple STAs in response to another frame. A method may include using a portion of the set of resources to transmit a data frame to at least one STA. A multi-AP RTS frame may include resource allocation information for at least one other AP and multiple STAs. [Brief explanation of the drawing]

[0004] A more detailed understanding can be obtained from the following description, which is given as an example in conjunction with the attached drawings, where similar reference numbers in the drawings indicate similar elements. [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2]This is a diagram of the preamble structure of an extremely high throughput (EHT) Physical Layer Convergence Procedure (PLCP) protocol data unit (PPDU). [Figure 3] This system diagram illustrates an exemplary procedure for a cooperative access point (AP) and / or non-AP station (STA) to report the Clear Channel Assessment (CCA) status for each subband, such as for each 20 MHz subband. [Figure 4] This is a system diagram illustrating an exemplary procedure for joint transmission with one or more CCA constraints on orthogonal resources. [Figure 5] This system diagram shows an example of a random access method, indicating the maximum number of resource units (RUs) that can be used for each STA. [Figure 6] This diagram illustrates an example of a multi-AP network where three access points (APs) work together to perform multi-AP operation across three different basic service sets (BSS). [Figure 7] This figure shows an exemplary design of the procedure for media reservation for a multi-AP operation protocol. [Figure 8] This is another diagram illustrating an exemplary design of the procedure for media reservation for a multi-AP operation protocol. [Figure 9] This is another diagram illustrating an example of the procedure for media reservation for a multi-AP operation protocol. [Modes for carrying out the invention]

[0005] Figure 1A shows 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, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use 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 filter OFDM, and filter bank multicarrier (FBMC).

[0006] As shown in FIG. 1A, 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, although it is understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can 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, which may all be referred to as stations (STAs), can be configured to transmit and / or receive wireless signals and can include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscriber-based units, pocket bells, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can also be referred to interchangeably as UEs.

[0007] The communication system 100 may also include base station 114a and / or base station 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be next-generation NodeBs such as base transceiver stations (BTS), NodeBs, eNode Bs (eNode B, eNB), home NodeBs, home eNode Bs, gNode Bs (gNB), new radio (NR) NodeBs, site controllers, access points (APs), and wireless routers. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0009] Base stations 114a, 114b can communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0010] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a of RAN 104 and WTRU 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) and may establish an air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

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

[0013] In one embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRU 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to and from multiple types of base stations (e.g., eNB and gNB).

[0014] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0015] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106.

[0016] RAN104 may communicate with CN106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs using the same RAT or a different RAT as RAN104. For example, in addition to being connected to RAN104 which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0017] CN106 may also function as a gateway to WTRU102a, 102b, 102c, and 102d for access to PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a public switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, which use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, Network 112 may include other CNs connected to one or more RANs that may use the same RAT as RAN 104 or different RATs.

[0018] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may use cellular-based radio technology, and base station 114b, which may use IEEE 802 radio technology.

[0019] Figure 1B is a system diagram showing an exemplary WTRU102. As shown in Figure 1B, the WTRU102 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 understood that the WTRU102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.

[0020] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple 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 functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which may be coupled to a transmit / receive element 122. Figure 1B shows the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0021] 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 one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one 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 both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0022] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize 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 radio signals via the air interface 116.

[0023] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0024] The processor 118 of the WTRU102 may be coupled to 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) and may receive user input from these. 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 any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. 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 in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in such memory.

[0025] The processor 118 may receive power from the power supply 134, but may also be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 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.

[0026] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via 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 understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

[0027] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripherals 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, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0028] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of a signal (for example, associated with specific subframes of both UL (for example, for transmission) and DL (for example, for reception) may occur simultaneously and / or together. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of a signal (for example, associated with specific subframes of either UL (for example, for transmission) or DL ​​(for example, for reception)).

[0029] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0030] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0031] Each of the eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling, etc., in UL and / or DL. As shown in Figure 1C, the eNode-B160a, 160b, and 160c may communicate with each other via the X2 interface.

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

[0033] The MME162 can be connected to each of the eNode-B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting gateways for specific services during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0034] The SGW164 can be connected to each of the eNode-B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during eNode-B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0035] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0036] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0037] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

[0038] In a typical embodiment, the other network 112 may be a WLAN.

[0039] A WLAN in Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with a Distribution System (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating outside the BSS and destined for an STA may reach and be delivered to the STA via an AP. Traffic originating from an STA to a destination outside the BSS may be sent to an AP and then delivered to its respective destination. Traffic between STAs within the BSS may be transmitted, for example, via an AP; a source STA may send traffic to an AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) via a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as the “ad hoc” communication mode.

[0040] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may have a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain typical embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. In the case of CSMA / CA, the STA, including the AP (e.g., all STAs), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA may be backed off. A single STA (e.g., only one station) may transmit at any given time on a given BSS.

[0041] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0042] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. The 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) and time-domain processing can be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be transmitted to Medium Access Control (MAC).

[0043] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications (MTC) such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for specific and / or limited bandwidths (e.g., support only for those bandwidths). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0044] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the 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 an STA from among all STAs operating in a BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and 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 state of the primary channel. For example, if the primary channel is busy, an STA (supporting only the 1 MHz operating mode) transmitting to the AP may consider the entire available frequency band to be busy, even if most of the available frequency band is idle.

[0045] In the United States, the available frequency band that can be used by 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 is 6MHz to 26MHz, depending on the country code.

[0046] Figure 1D is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via air interface 116 using NR radio technology. RAN104 can also communicate with CN106.

[0047] RAN104 may include gNB180a, 180b, and 180c, but it will be understood that RAN104 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0048] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with an expandable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or expandable lengths (e.g., varying numbers of OFDM symbols and / or varying durations of absolute time).

[0049] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0050] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slice support, interaction between DC, NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0051] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although the aforementioned elements are shown as part of CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may play roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of SMF183a and 183b for registration, management of registration areas, termination of non-access stratum (NAS) signals, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for MTC access. AMF182a, 182b may provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0053] SMF183a and 183b can be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a 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, etc.

[0054] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c in RAN104, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of DL packets, and mobility anchoring.

[0055] CN106 can facilitate communication with other networks. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. Furthermore, CN106 may provide WTRU102a, 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, WTRU102a, 102b, 102c may be connected to local DN185a, 185b via UPF184a, 184b through N3 interfaces to UPF184a, 184b and N6 interfaces between UPF184a, 184b and DN185a, 185b.

[0056] With regard to Figures 1A-1D and the corresponding descriptions in Figures 1A-1D, one or more of the functions described herein with respect to one or more of the WTRU102a-d, base stations 114a-b, eNode-B160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN185a-b, and / or any other devices described herein, one or more of the functions described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0057] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for the purpose of testing and / or performing testing using over-the-air radio communications.

[0058] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0059] Using the operating modes of the 802.11ac infrastructure, an AP may transmit beacons on a fixed channel, such as the primary channel. This channel may be 20 MHz wide and may be the operating channel of the BSS. This channel may also be used by an STA to establish a connection with the AP. Basic channel access in an 802.11 system is carrier-sensing multiple access (CSMA / CA) with collision avoidance. In this operating mode, all STAs, including the AP, can sense the primary channel. If the channel is detected or determined to be busy, the STA backs off. Therefore, only one STA can transmit at any given time on a given BSS.

[0060] In 802.11n, high-throughput (HT) STAs can also use 40 MHz wide channels for communication. This can be achieved by combining a primary 20 MHz channel with an adjacent 20 MHz channel to form a continuous 40 MHz wide channel.

[0061] In 802.11ac, very high throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and 160 MHz. 40 MHz and 80 MHz channels can be formed by combining consecutive 20 MHz channels, similar to 802.11n described above. 160 MHz channels can be formed, for example, by combining eight consecutive 20 MHz channels or two non-consecutive 80 MHz channels. This may also be referred to as an 80+80 configuration. In an 80+80 configuration, after channel coding, the data can pass through a segment parser that splits the data into two streams. IFFT and time-domain processing can be performed separately for each stream. The streams can then be mapped to two channels, and the data can be transmitted. At the receiver, this mechanism can be reversed, and the combined data can be transmitted to the MAC.

[0062] To improve spectral efficiency, 802.11ac may support downlink multi-user MIMO (MU-MIMO) transmission to multiple STAs within the same symbol time frame during a downlink OFDM symbol. The possibility of using downlink MU-MIMO may also be supported by 802.11ah. It is important to note that, as with 802.11ac, downlink MU-MIMO can use the same symbol timing to multiple STAs, so interference between waveform transmissions to multiple STAs may not be a problem. However, all STAs involved in MU-MIMO transmission using APs may need to use the same channel or bandwidth, which may limit the operating bandwidth to the minimum channel bandwidth supported by the STAs included in MU-MIMO transmission using APs.

[0063] 802.11ax defines physical layer and medium access control layer specifications that enable high-efficiency (HE) operation of 802.11 devices. 802.11ax is considered the next major generation of Wi-Fi after 802.11ac. 11ax may also support newer numerologies with smaller subcarrier spacings. DL / UL OFDMA is introduced in 11ax to achieve better spectral efficiency.

[0064] The IEEE 802.11ax specification may support four Physical Layer Convergence Procedure (PLCP) protocol data unit (PPDU) formats: High Efficiency (HE) Single User (SU) PPDU, HE Multi-User (MU) PPDU, HE Extended Range (ER) SU PPDU, and HE Transport Block (TB) PPDU. These PPDU formats are described below.

[0065] The HE SU PPDU format can be used for single-user transmissions. An example of HE SU PPDU is provided in Table 1 below.

[0066] [Table 1]

[0067] The HE MU PPDU format can be used to send to one or more users when the PPDU is not a response to a trigger frame. The HE-SIG-B field may be presented in this PPDU format. An example of the HE MU PPDU format is provided in Table 2 below.

[0068] [Table 2]

[0069] The HE ER SU PPDU format can be used for SU transmissions with extended range. In this format, the HE-SIG-A field may be twice the length of the HE-SIG-A field in other HE PPDUs. An example of the HE ER SU PPDU format is provided in Table 3 below.

[0070] [Table 3]

[0071] The HE TB PPDU format can be used for trigger frames or transmissions responding to frames that carry trigger response scheduling (TRS) control subfields from the trigger frame or AP. The duration of the HE-STF field in the HE TB PPDU is 8us, and the size of the HE-STF field in the HE PPDU can be twice that of the HE PPDU. An example of the HE TB PPDU format is provided in Table 4 below.

[0072] [Table 4]

[0073] The L-SIG field, HE-SIG-A field, and / or HE-SIG-B field may carry PHY layer control information in the PPDU. The L-SIG field may have legacy numerology and format so that all STAs can understand the L-SIG field. The HE-SIG-A and HE-SIG-B fields can be understood by HE STAs. An example of an L-SIG field is shown in Table 5. An example of an HE-SIG-A field in a different PPDU format is shown in Table 6.

[0074] [Table 5]

[0075] [Table 6]

[0076] Development of specifications for further generations of Wi-Fi in 802.11be is currently underway. An example of a PPDU design that may conform to the 802.11be specification is detailed in Figure 2 below.

[0077] Figure 2 shows an exemplary preamble structure for an ultra-high-throughput (EHT) physical layer convergence procedure (PLCP) protocol data unit (PPDU). The following 802.11 specifications, such as 11be, may support the EHT PPDU preamble structure shown in Figure 2. The Universal Signal Field (U-SIG) field 210 may include a version-independent field 211 and a version-dependent field 212. Bits in the version-independent field 211 may have static positions and bit definitions across different generations / PHY versions. Bits in the version-independent field 212 may include, among other information, a PHY version identifier, UL / DL flags, BSS color, TXOP duration, and bandwidth information. Version-dependent bits may carry data related to the PPDU type. In combination with the common field 221 in the EHT-SIG field 220, the version-dependent field may also carry data related to the modulation and coding scheme (MCS), the number of space-time streams, the GI+EHT-LTF side, coding, etc. A user-specific field 222 may be included in the EHT-SIG field and used in an MU configuration, for example. The 802.11be specification may not support separate PPDU formats for SU and MU, but may have a single PPDU format for both SU and MU.

[0078] Because different APs experience different levels of interference, an AP may not always be able to transmit to one or more STAs with the same time / frequency resources in a joint transmit. A procedure to address this issue may allow coordinating APs to organize a joint transmit by taking into account the clear channel evaluation (CCA) of different APs, as the time / frequency resources from different APs may differ.

[0079] EHT PPDU may allow the use of multiple resource units (RUs) to send data to or by the STA. To provide diversity, it may be advantageous to design procedures that allow RUs (or portions of RUs) to be used by different STAs and / or APs.

[0080] PPDUs transmitted from multiple APs on an orthogonal resource are coordinated by trigger frames from a coordinating AP and are transparent to the receiving STA; however, residual CFO drift and phase noise may differ between different APs. Therefore, it may be desirable to define a procedure that allows the STA to perform independent phase tracking from different transmitters.

[0081] The EHT enhancer may support multi-RU transmission, which may allow an STA to transmit using two or more RUs. In current trigger-based uplink transmission, the AP may assign RUs to the STA to perform trigger-based transmission, which may also be referred to as schedule-based transmission. In some embodiments, the AP may assign RUs to the STA to perform uplink random access, which may be referred to as random-based transmission. Both transmission methods may allow an STA to transmit with a single RU. If multi-RU UL transmission is permitted, the RU assignment and RU random access procedures may need to be modified.

[0082] Multi-AP and multi-link operation can be considered features supported by 802.11be devices. In a multi-AP scenario, multiple APs from different BSSs may cooperate to perform operations such as joint transmission or coordinated OFDMA, or they may share frequency-time resources with each other to improve overall network performance. Media reservation may be essential to enable such coordinated operation across APs and BSSs. In multi-link operation, link aggregation may also require media reservation and information sharing. One problem addressed by the embodiments described herein is how to design an efficient and effective media reservation mechanism for multi-AP and multi-link operation.

[0083] As shown in Figure 3, a coordinating AP may initiate a bandwidth query report (BQR) procedure for the coordinating AP and / or non-AP STA to report their CCA status for each subband (e.g., 20 MHz).

[0084] Figure 3 is a diagram of a BQR procedure involving a coordinating AP and a non-AP STA. This procedure may allow a coordinating AP to perform RU allocation for joint transmissions such that the transmitted symbols from the coordinating and coordinating APs do not violate the CCA constraint associated with any of the individual APs and / or non-AP STAs. For example, as shown in Figure 3, a BQR procedure may include a coordinating AP 310, at least one coordinating AP 320, and at least one non-AP edge STA 330. The coordinating AP 310, coordinating AP 320, and non-AP STA 330 may be configured to operate on a channel containing multiple subchannels 1-4. The coordinating AP 310 may initiate a BQR procedure, for example, by triggering the coordinating AP 320 and non-AP STA 330 to send a report. The coordinating AP 310 may initiate a BQR procedure by sending a frame requesting a report on the state of the subchannels observed by the coordinating AP 320 and non-AP STA 330. The coordinating AP 310 may also evaluate the state of the subchannels at its own location. Coordinated AP310 may observe that subchannel 1 is idle, uncoordinated AP320 may observe that subchannels 1, 2, and 4 are idle, and cell edge STA330 may observe that subchannels 1 and 4 are idle. Coordinated AP310 may schedule RUs to STA from itself to subchannel 1 and from the uncoordinated AP to subchannel 4. Such RU allocations may not violate any party's CCA constraints, and as shown in Figure 4, non-AP STA330 will not schedule transmissions to coordinated AP310 or uncoordinated AP320 to be performed on RUs reported as occupied.

[0085] Figure 4 illustrates a joint transmission with CCA constraints on orthogonal resources. In a scenario similar to that described with respect to Figure 3, the coordinating AP410 can communicate with the uncoordinated AP420 and the non-AP STA430. The coordinating AP410, uncoordinated AP420, and non-AP STA430 may be configured to operate on a channel that includes multiple subchannels 1-4. Resource-specific phase tracking may be used on the receiver side, for example, on the non-AP STA430 and / or the coordinated AP420. As shown in Figure 3, the coordinated AP410 may observe that subchannel 1 is idle, the coordinated AP420 may observe that subchannels 1, 2, and 4 are idle, and the cell edge STA430 may observe that subchannels 1 and 4 are idle. As shown in Figure 4, the coordinated AP410 may transmit a trigger frame (TF) that can be transmitted to initiate joint transmission from the coordinated AP410 and the coordinated AP420 to the non-AP STA430. Before or together with the TF to the coordinated AP420, the coordinated AP410 may signal uncoded or coded data to be transmitted by the coordinated AP420. Diversity or beamforming schemes may be utilized by transmissions from multiple APs. Coordinated AP410 may use RU242 to transmit data to non-AP STA430 via subchannel 1, while uncoordinated AP420 may use RU242 to transmit data to non-AP STA430 via subchannel 4. Non-AP STA430 may receive data transmitted from both coordinated AP410 and uncoordinated AP420.

[0086] In some cases, if time / frequency resources overlap in transmissions from APs, a space-time diversity scheme can be used to increase diversity. A precoder can be used to precode transmissions together for beamforming.

[0087] In some cases, a dual-carrier modulation (DCM) scheme may be used when time / frequency resources do not overlap (i.e., the resources are orthogonal resources), or when the same time / frequency resources are utilized by APs, but precoding is performed separately, for example, in joint transmissions from APs, via separate / orthogonal channel estimation signals from each AP. Alternatively, or additionally, the transmission of the coordinating AP may complement the transmission of the coordinating AP, such as by transmitting different redundant versions.

[0088] Since different APs, for example, coordinating AP410 and uncoordinated AP420, may have independent phase noise and residual CFO drift, a receiving STA, for example, a non-AP STA430 as shown in Figure 4, may perform independent phase tracking for transmissions from different APs.

[0089] An EHT preamble may indicate to the receiver that pilots in two regions of frequency resources are tracked independently. For example, the two regions could be two RUs from different APs. The EHT preamble may also indicate to the receiver that the pilot is not a single stream pilot (tracked per stream), but rather that the pilot tones in the training field are orthogonal, and channel estimation of the pilot tone is performed for each spatial stream. The above instructions may allow the receiving STA to perform phase correction independently for transmissions from different APs.

[0090] In some embodiments, a general trigger frame can be modified. For example, in some ways, the trigger frame may be similar to, for example, the one defined in 802.11, and for example, the trigger frame may include a common information field and multiple user information fields. Each user information field may assign one RU to one STA. However, there may be two or more user information fields associated with a single STA.

[0091] In some ways, the trigger frame may contain user information fields that allow one or more RUs to be assigned to the STA. Alternatively, or additionally, the user information fields may be used to assign combinations of RUs to the STA.

[0092] OFDMA-based multi-RU UL random access procedures can be used by STAs and APs. For single RU transmissions, a trigger frame can be used for trigger-based OFDMA UL random access. When multi-RU transmissions are permitted, the procedure may be modified as shown in Figure 5, which will be described in more detail in the following paragraphs.

[0093] An AP may send a trigger frame that may contain one or more information elements, including the trigger type, user information fields, and the maximum number of RUs per user. The trigger type in the common information field may indicate a multi-RU trigger.

[0094] If the AID12 subfield in the user information field indicates an allocation for UL random access, the reserved subfield and / or trigger-dependent user information subfield within the user information field may indicate that the allocated RU may be permitted as part of a multi-RU UL transmission. In some ways, existing subfields may be used to indicate this information. For example, an unused value in the UL MCS subfield within the user information field may be used to indicate whether the RU may be permitted for a multi-RU UL transmission.

[0095] The maximum number of RUs per user field may indicate the maximum number of RUs that can be selected for a user to perform UL random access. The application administrator (AP) may use this field to perform admission control. For example, if there are more users than a threshold in the BSS, the AP may indicate a smaller number of RUs per user. If there are fewer users in the BSS, for example, if the number of users is below a threshold, the AP may indicate a larger number of RUs per user. This field may be included in a common information or user information field.

[0096] An STA that can send or forward UL traffic may attempt to use a RU allocated for random access. An STA may have different criteria for selecting one or more RUs for random access. In this example, an STA may select two RUs for UL transmission. An exemplary random access method is described below with reference to Figure 5.

[0097] Figure 5 is a diagram illustrating an exemplary procedure for trigger-based UL OFDMA random access. A UL multi-RU random access method that considers combinations of RUs may include one or a combination of the following steps or procedures. For example, as shown in Figure 5, AP510 may initiate a trigger-based UL OFDMA random access procedure by sending a trigger frame 511 to STA520. STA520 then randomly draws a UL OFDMA backoff (OFDMA Backoff, OBO) counter N between [0, OCW]. O It may consist of the following: STA is field N, which indicates the Random Access Resource Unit (RA-RU) 521. RUs A trigger frame 511 that may include S can be received. The TA520 may be permitted to select one or more of the RA-RU521 for uplink transmission.

[0098] STA520 is N O -N RUs It is possible to check whether it is >0. In this case, STA520 is N O =N O -N RUs Set it, hold that transmission, and trigger later You may need to wait for a frame. Otherwise, you may need to prepare to select one or more RA-RUs for UL transmission and follow the steps below.

[0099] STA520 may form a table having combinations of all possible RUs based on information carried in the trigger frame 511 and / or other previously received management / control frames. In some ways, not all combinations of RUs are possible for multi-RU transmission, and the table may include only the possible combinations. The table may be formed using a standard method, e.g., one pre-defined or configured according to a standard specification, such that all STAs may form the table in the same way in the same order when receiving the same trigger frame. STA520 may randomly select one combination from the table and perform the transmission. For example, as shown in FIG. 5, the STA may select RU1 and RU2 from the available RA-RU521.

[0100] STA521 may need to sense the channel before transmitting on the selected RUs. If the STA senses that one or more RUs within the selected combination of RUs may be busy, it may hold the transmission and wait for the next trigger frame. Alternatively, or additionally, the STA may truncate the PPDU and transmit on the available RUs.

[0101] STA521 may perform coding across all RUs. Alternatively, or additionally, the STA may perform per-RU coding, which means that the coded bits on each RU may be individually encoded and / or protected by a cyclic redundancy check (CRC), and thus RU-based acknowledgments and retransmissions may be possible.

[0102] If the combination of RUs does not have sufficient subcarriers N SCS,needed to cover the required subcarriers, the STA uses a pre-defined or predetermined function, e.g., , N SCS,needed = F(N SCS,needed ) to obtain the required subcarriers The number of carriers can be reduced. The STA can prepare corresponding methods for fragmenting frames. For example, the STA can fragment a frame uniformly by 2 by applying the function F(x) = x / 2. The STA can repeat any such step until it finds a RU or combination of RUs and can transmit a frame or a fragment of a frame.

[0103] A UL multi-RU random access method that considers RU combinations and traffic size may include one or more of the following steps: STA is randomly drawn between [0, OCW] OBO counter N O It can be composed of N RU s A trigger frame may be received that may contain a number of Random Access Resource Units (RA-RUs). The STA may be permitted to select one or more RA-RUs for uplink transmission.

[0104] STA is N O -N RUs You can check if it is >0. If so, STA is N O =N O -N RUs Set it, hold the transmission, and wait for the next trigger frame. You may do so. Otherwise, you may prepare to select one or more RA-RUs for UL submission and follow the steps or procedures described in the following paragraphs.

[0105] The STA can use the UL MCS and UL spatial streams assigned in the received trigger frame to calculate the expected number of subcarriers per stream needed to carry the entire frame / A-MPDU to be transmitted.

[0106]

number

[0107] Here, APEP_length can be the PSDU length in bytes. serv ice This can be the number of bits in the service field. tail If necessary, It could be the number of bits. ss This is the number of spatial streams assigned to the user. To obtain. N IBPSCS This is a spatial story using a given MCS assigned to the user. This could be the number of information bits per subcarrier per unit. add If necessary, In addition to APEP_length, it may refer to additional PHY / Mac padding. For example, if per-RU coding is used, PHY layer padding may be required to enable per-RU coding and error detection.

[0108] One or more RUs or combinations of RUs are sufficient to cover the required subcarriers N SCS,needed If it has a valid RU or RU A combination table may be generated, which may contain valid combinations. The STA may randomly select one RU or combination of RUs from the table and transmit a frame or A-MPDU.

[0109] The STA may need to sense the channel before transmitting on the selected RU. If the STA senses that one or more RUs in the selected RU combination may be busy, it may hold the transmission and wait for the next trigger frame. Alternatively, or additionally, the STA may truncate the PPDU and transmit on an available RU.

[0110] The STA may perform coding across all RUs. Alternatively, or additionally, the STA may perform coding on a per-RU basis, meaning that the coded bits on each RU may be individually encoded and / or protected by the CRC, and thus RU-based acknowledgments and retransmissions may be possible.

[0111] After a UL-triggered transmission, the STA can expect an acknowledgment. If the units of acknowledgment and retransmission are not RU-based, when the STA receives an acknowledgment, the STA will have OCW=OCW min Set STA to CW=min(2×OC W+1, OCW max ) can be set.

[0112] If the units of acknowledgment and retransmission are RU-based, the STA may update the OCW according to one or more of the following procedures or steps. In some cases, if all acknowledgments received by the STA are affirmative, the STA will update OCW = OCW min of Set STA is OCW=min(2×OCW+1,OCW max ) It is possible to set this. In some cases, if the STA receives at least one acknowledgment, the STA will have OCW=OCW min Set STA to OCW= min(2×OCW+1,OCW max ) can be set.

[0113] Multi-RU UL transmissions can be schedule-based. A trigger frame can assign multiple RUs or combinations of RUs to the STA for a UL transmission. Under certain conditions, for example, a subfield in the trigger frame may be set that requires carrier sensing (CS), meaning the STA may need to perform carrier sensing before responding with a TB PPDU. With multiple RUs, it may be possible for several RUs or partial RUs to be available for a UL transmission, but not all of the multiple RUs may be available. A trigger-based transmission rule may be set in such cases, which may be called a partial response. An STA operating based on a partial response rule may perform a transmission on all available RUs, perform a transmission on a subset of the available RUs, or hold the transmission and wait for a later opportunity.

[0114] The conditions under which an STA can transmit on a subset of RUs assigned by an AP, or the conditions under which it can partially respond with a HE TB PPDU, may depend on physical and / or virtual carrier sensing results.

[0115] In some cases, the partial response may include PHY layer signaling so that the receiver (e.g., AP) knows that UL transmission may be performed differently than the method assigned in the trigger frame. The PHY layer signaling may include STA identification and information that can be modified by the STA, such as MCS, spatial stream, and RU allocation. RU allocation information may indicate the RU to be used for UL transmission. In some cases, RU allocation may include user information field indices shown in the trigger frame. For example, in the trigger frame, k1 st k2 nd , and k3 rd The user information fields are: STA can carry RU allocation information. STA is k1 st and k2 nd User information fee It may be possible to transmit RUs allocated by the RU, and the STA may use k1 and k2 to indicate the RUs used for PHY layer signaling. In some cases, the STA may use the RU allocation field defined in the user information field within the trigger frame.

[0116] PHY layer signaling can be transmitted over RUs that carry the data field of the STA. Such RUs are sometimes referred to as data RUs. One or more signaling fields may be located after the narrowband STF / LTF transmitted over the data RU, but before the data field. One or more signaling fields may be independently coded and protected by their own CRCs. Signaling can be modulated into one RU and replicated to the rest of the RU. Each or more signaling fields may carry the RU allocation for all data RUs.

[0117] In some embodiments, wireless media may be reserved for multi-AP and multi-link operation. Media reservation for multi-AP operation can be performed using multiple media reservation designs as follows:

[0118] Figure 6 is a diagram of an exemplary network of a multi-AP set. In the exemplary multi-AP network 610 of Figure 6, three APs, AP0, AP1, and AP2, can work together to perform multi-AP operation across three different BSSs. Multiple STAs, STA1, STA2, STA3, and STA4 can also be configured to operate within the multi-AP network. Multi-AP operation may include coordinated OFDMA, coordinated beamforming, joint transmit, and other operation types. Each of the three different BSSs can be initiated by its respective AP, i.e., AP0, AP1, or AP2. STA1 may be associated with AP0. STA2 may be associated with AP1, and STA3 and STA4 may be associated with AP2. Without loss of generality, AP0 can be assumed to be a coordinating AP or a shared AP in a multi-AP set. AP0 may be a previously assigned coordinating AP or may be selected as a coordinating AP in a multi-AP set. AP0 may also be a shared AP that has just acquired a transmit opportunity (TXOP) and is willing to share it with other APs.

[0119] Figure 7 is a diagram illustrating an exemplary design of media reservation for multi-AP operation. The multi-AP system shown in Figure 7 may include three different APs associated with three different BSSs and four different STAs, similar to the system shown in Figure 6 and substantially described above. AP0 may be a cooperative AP. The cooperative or shared AP0 may send a multi-AP Request-To-Send (RTS) frame 710 to one or more shared or cooperative APs, e.g., AP1 and AP2. The multi-AP RTS frame 710 may also be received by one or more STAs operating in the associated BSSs, e.g., STA1-4.

[0120] The multi-AP RTS frame 710 may be implemented as a modified version of the MU-RTS frame or trigger frame. For example, a new value in the trigger type subfield may be used to indicate that an MU-RTS or trigger frame may be a multi-AP RTS frame. Alternatively or additionally, bits in the MU-RTS frame may be set to indicate that it is a multi-AP RTS frame. In some cases, a new frame format may be designed for multi-AP RTS frames.

[0121] A multi-AP RTS frame 710 may contain one or more AP addresses or AP identifiers such as a multi-AP APID. A multi-AP RTS frame may also contain frequency channel or RU allocations for APs in a multi-AP set. A multi-AP RTS frame may also contain information about a transmitting AP, e.g., AP0. This information may be used by other APs in a multi-AP set configured to advertise the frequency allocation of the transmitting AP. APs identified by a multi-AP frame may use their allocated frequency channels or RUs to send response frames, such as multi-AP Clear-To-Send (CTS) frames 720 and 730. APs identified by a multi-AP frame may consider the allocated frequency channels or RUs assigned to them for use in subsequent multi-AP communications, e.g., coordinated OFDMA, coordinated beamforming, or shared transmit opportunity (TXOP). In addition, a multi-AP RTS frame may contain timing schedules used for each of the APs identified in the multi-AP RTS frame.

[0122] APs identified in a multi-AP RTS frame (e.g., AP0, AP1, and / or AP2) may respond with a multi-AP CTS frame indicated by element 730. For example, AP1 and / or AP2 may each transmit a multi-AP CTS frame 730 after receiving a multi-AP RTS frame 710. AP1 and / or AP2 may wait for a duration of period P1, which may be an SIFS period, for example, after receiving a multi-AP RTS frame and before transmitting a multi-AP CTS 730. Such a multi-AP CTS frame may be transmitted on an allocated frequency channel or RU, as indicated in the received multi-AP RTS frame 710. APs identified in a multi-AP RTS frame may only respond on an allocated frequency channel or RU where the medium is free. A responding AP may use the response to reserve medium for its own BSS. The reserved medium may be a portion of the bandwidth used by AP0 for transmitting the multi-AP RTS frame 710. If a time schedule is included in the multi-AP RTS frame 710, the responding multi-AP CTS frame 720 or 730 may be transmitted according to the time schedule.

[0123] A shared or cooperative AP, such as AP0, may simultaneously transmit a multi-AP CTS frame 720 while other responding APs in the multi-AP set save their own BSS medium reservation. The reserved medium may be a portion of the bandwidth used by AP0 for transmitting a multi-AP RTS frame 710. For example, AP0 may wait for a period P1 duration, which may be an SIFS period, such as after transmitting a multi-AP RTS frame 710.

[0124] Multi-AP CTS frames 720 and 730 may be modified versions of CTS frames or newly designed frames. Multi-AP RTS frames 720 and 730 may be modified versions of MU-RTS frames or trigger frames. A new value in the trigger type subfield may be used to indicate that an MU-RTS or trigger frame may be a multi-AP CTS frame. Alternatively or additionally, bits in an MU-RTS frame may be set to indicate that it is a multi-AP CTS frame. In another example, a new frame format may be designed for multi-AP CTS frames. A multi-AP CTS frame transmitted by an AP may contain one or more fields for one or more associated STAs or one or more unassociated STAs.

[0125] Multi-AP CTS frames 720 and / or 730 may contain one or more STA addresses or STA identifiers such as a Multi-AP AID or AID. Multi-AP CTS frames 720 and / or 730 may also contain frequency channel or RU allocations for STAs associated with the transmitting AP. STAs identified by the Multi-AP frames may use their allocated frequency channel or RU to transmit response frames such as Multi-AP CTS frames or simply CTS frames.

[0126] An STA receiving a multi-AP RTS frame 710 may monitor MU-CTS frames from the associated AP following period P1. For example, in period P2, which may be an SIFS period after receiving a multi-AP CTS frame, an STA identified in one of the multi-AP CTS frames 720 or 730 may respond with a multi-AP CTS frame or simply a CTS frame, as shown in Figure 7. Such a multi-AP CTS may be transmitted over an allocated frequency channel or RU, as indicated in the received multi-AP CTS frame. An STA identified in a multi-AP CTS frame may only respond on an allocated frequency channel or RU where the medium is free. If a time schedule is included in the multi-AP CTS frame, the response multi-AP CTS frame or CTS frame may be transmitted according to the time schedule.

[0127] As shown in Figure 8, other methods may also use the media reservation protocol. In such a method, similar to the scenario described with respect to Figure 7, a cooperating AP or shared AP may send a multi-AP RTS frame to one or more shared APs or cooperating APs, for example, AP1 and AP2.

[0128] Figure 8 shows an example of another design for media reservation for multi-AP operation. A multi-AP RTS frame 810 may include one or more AP addresses or AP identifiers such as a multi-AP APID. A multi-AP RTS frame 810 may also include frequency channel or RU allocations for APs in a multi-AP set. A multi-AP RTS frame 810 may also include information for a transmitting AP, e.g., AP0. This information can be used by other APs in a multi-AP set that are configured to advertise the frequency allocation of the transmitting AP. APs identified by a multi-AP RTS frame 810 may use the allocated frequency channel or RU to transmit response frames such as multi-AP CTS frames and / or MU-RTS frames, shown as element 830 in Figure 8. APs identified by a multi-AP frame may consider the allocated frequency channel or RU assigned to them and used for subsequent multi-AP communications, e.g., coordinated OFDMA, coordinated beamforming, or shared TXOP. In addition, a multi-AP RTS frame may include timing schedules used for each of the APs identified in the multi-AP RTS frame. The multi-AP RTS frame 810 may also be received by one or more STAs operating in the associated BSS, for example, STA1-4.

[0129] APs identified in a multi-AP RTS frame may respond with an MU-RTS frame. AP1 and / or AP2 may wait for a duration of period P1, which may be a SIFS period, for example, after receiving a multi-AP RTS frame 810 and before transmitting an MU-RTS frame 830. The MU-RTS frame 830 may be transmitted on an allocated frequency channel or RU, as indicated in the received multi-AP RTS frame. APs identified in a multi-AP RTS frame may respond only on an allocated frequency channel or RU where the medium is free. A responding AP may use its response to reserve medium for each of its own BSSs. The reserved medium may be a portion of the bandwidth used by AP0 for transmitting the multi-AP RTS frame 810. If a time schedule is included in the multi-AP RTS frame 810, the response MU-RTS 830 may be transmitted according to the time schedule.

[0130] A shared or coordinating AP, such as AP0, may transmit an MU-RTS frame 820 at the same time that other responding APs in the multi-AP set transmit their respective MU-RTS frames 830. The MU-RTS frame 820 may be used by shared AP0 or coordinating AP0 to reserve its own BSS medium. An STA receiving a multi-AP RTS frame 810 may monitor MU-RTS frames from associated APs following period P1. An STA identified in the MU-RTS frame may respond with a CTS frame following the MU-RTS / CTS protocol. For example, one or more of STA1-4 may wait for the duration of period P2, which may be an SIFS period, after receiving one or more MU-RTS frames 820 or 830, before transmitting a CTS frame 840. Such a CTS may be transmitted on an allocated frequency channel or RU, as indicated in the received MU-RTS frame.

[0131] Figure 9 is a diagram of another exemplary media reservation design for multi-AP operation. As shown in Figure 9, Cooperative AP0 or Shared AP0 may transmit a multi-AP RTS frame 910 to one or more shared or cooperative APs, e.g., AP1 and AP2. The multi-AP RTS frame 910 may also be received by one or more STAs operating in the associated BSS, e.g., STA1-4.

[0132] A multi-AP RTS frame 910 may contain one or more AP addresses or AP identifiers such as a multi-AP APID. The multi-AP RTS frame 910 may also contain frequency channel or RU allocations for APs in the multi-AP set. The multi-AP RTS frame 910 may also contain information about a transmitting AP, such as AP0. This information can be used by other APs in the multi-AP set that are configured to advertise the frequency allocation of the transmitting AP. APs identified by the multi-AP frame 910 may use their allocated frequency channels or RUs to send response frames, such as the multi-AP CTS frame shown as element 940 in Figure 9. APs identified by the multi-AP frame may consider the allocated frequency channels or RUs assigned to them and used in subsequent multi-AP communications, such as coordinated OFDMA, coordinated beamforming, or shared TXOP. In addition, the multi-AP RTS frame 910 may contain timing schedules used for each of the APs identified in the multi-AP RTS frame.

[0133] APs identified in a multi-AP RTS frame may respond with an aggregation frame that may include a multi-AP CTS frame 940 and a MU-RTS frame 950. AP1 and / or AP2 may wait for a duration of period P1, which may be a SIFS period, for example, after receiving a multi-AP RTS frame 910 and before transmitting an aggregation frame. Such an aggregation frame may be transmitted on an allocated frequency channel or RU, as indicated in the received multi-AP RTS frame. APs identified in the multi-AP RTS frame may respond only on an allocated frequency channel or RU, where the medium is free. If a time schedule is included in the multi-AP RTS frame 910, the response aggregation frame may be transmitted according to the time schedule.

[0134] A shared or cooperative AP, such as AP0, may transmit an aggregation packet containing a multi-AP CTS frame 920 and a MU-RTS frame 930 at the same time that other responding APs in the multi-AP set transmit their respective multi-AP CTS and MU-RTS frames 940 and 950. The multi-AP CTS frame 920 and MU-RTS frame 930 may be used by shared or cooperative AP0 to store its own BSS media reservation. AP0 may, for example, wait for the duration of a period P1, which may be an SIFS period, after transmitting a multi-AP RTS frame 910 and before transmitting the aggregation packet containing the multi-AP CTS frame 920 and MU-RTS frame 930.

[0135] A multi-AP CTS frame may be a modified version of a CTS frame or a newly designed frame.

[0136] In some designs, an AP identified in a multi-AP RTS frame may respond with a multi-AP CTS frame after a period following the reception of the multi-AP RTS frame (e.g., SIFS). After another period, e.g., SIFS, the AP may transmit an MU-RTS frame to reserve its own BSS medium. Both frames may be transmitted on an allocated frequency channel or RU as indicated in the received multi-AP RTS frame. An AP identified in a multi-AP RTS frame may only respond on an allocated frequency channel or RU where the medium is free. If a time schedule is included in the multi-AP RTS frame, the response frame may be transmitted according to the time schedule.

[0137] Shared APs or cooperative APs such as AP0 can transmit multi-AP CTS frames. After another SIFS period, AP0 may transmit MU-RTS frames simultaneously with other responding APs in the multi-AP set. AP0 may do this to save its own BSS media reservation.

[0138] Furthermore, with respect to Figure 9, considering the operation of STA1-4, which may also have received the first multi-AP RTS frame 910 from AP0, one or more of STA1-4 may wait for a first period P1 before monitoring response frames from one or more of the identified APs. For example, in accordance with the procedure shown in Figure 9, an STA configured to operate with a BSS associated with AP0 may receive the multi-AP RTS frame 910. The STA may wait for a first period P1 before receiving, for example, one or both of the multi-AP CTS frame 920 and the MU-RTS frame 930.

[0139] A multi-AP CTS transmitted by an AP may be intended to verify the multi-AP RTS frame and store the media reservation of the associated BSS. During a period following the reception of one or more MU-RTS frames (e.g., SIFS), an STA identified in one or more MU-RTS frames may respond with a CTS frame following the MU-RTS / CTS protocol. Such a CTS may be transmitted on an allocated frequency channel or RU as indicated in one or more of the received MU-RTS frames. For example, an STA identified in MU-RTS frame 930 and associated with AP0 may wait for the duration of period P2 before transmitting a CTS frame 960. The CTS frame may be transmitted on an allocated channel frequency or RU as indicated in MU-RTS frame 930.

[0140] Similar procedures may be performed by other STAs associated with AP1 or AP2. For example, an STA may wait for a first period P1 after AP0 has transmitted a multi-AP RTS frame 910 and before it receives one or both of the multi-AP CTS frame 940 and MU-RTS frame 950, which store the media of the associated BSS. An STA identified in the MU-RTS frame 950 and associated with AP1 or AP2 may wait for the duration of period P2 before transmitting one or more of the CTS frames 960. One or more CTS frames may be transmitted on an allocated channel frequency or RU, as shown in one of the received MU-RTS frames 950.

[0141] While features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) 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 internal 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 can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a cooperative AP in a multi-access point (AP) wireless local area network (WLAN), Receiving a Multi-AP Transmit Request (RTS) trigger frame from a cooperating AP, wherein the Multi-AP RTS trigger frame includes an identifier for the cooperating AP, resource allocation information indicating at least one resource allocated to the cooperating AP, an indication that the Multi-AP RTS trigger frame is for multi-AP cooperating operation, and a timing schedule for the cooperating AP, wherein the at least one allocated resource includes a frequency channel or resource unit (RU). Based on the identifier of the aforementioned cooperative AP, it is determined that the cooperative AP is addressed by the multi-AP RTS trigger frame, Based on the resource allocation information, it is determined that at least one allocated resource is allocated to the coordinating AP for communication during a shared transmission opportunity (TXOP), Transmittable (CTS) frames are transmitted on the at least one allocated resource in accordance with the timing schedule to the coordinating APs and in response to the multi-AP RTS trigger frame, wherein the CTS frames are transmitted for a short interframe time (SIFS) after the multi-AP RTS trigger frame has been received. During the shared TXOP, the coordinating AP will use at least one allocated resource as its frequency resource for subsequent communication. A method characterized by comprising:

2. The method according to claim 1, wherein the multi-AP RTS trigger frame includes identifiers of a plurality of cooperative APs, including the cooperative AP, and the timing schedule includes respective timing information for each of the plurality of cooperative APs.

3. The method according to claim 1, characterized in that the identifier of the cooperative AP includes an AP address or a multi-AP AP identifier (APID) assigned to the cooperative AP by the multi-AP RTS trigger frame.

4. The method according to claim 1, wherein the multi-AP RTS trigger frame further includes information identifying the coordinating APs, or information indicating the frequency allocation of the coordinating APs.

5. The method according to claim 1, wherein the instruction that the multi-AP RTS trigger frame is for the multi-AP coordinate operation includes a value in the trigger type subfield, or at least one bit in the multi-AP RTS trigger frame indicating that the multi-AP RTS trigger frame is a multi-AP RTS frame.

6. The method according to claim 1, characterized in that the response frame transmitted by the cooperating AP in response to the multi-AP RTS trigger frame is transmitted only when there is one or more allocated resources indicated by the resource allocation information and when the wireless medium is available.

7. The method according to claim 1, characterized in that the CTS frame reserves a wireless medium for the Basic Service Set (BSS) associated with the Cooperative AP.

8. The method according to 7, characterized in that the medium reserved for the BSS includes a portion of the bandwidth used by the coordinating APs that transmit the multi-AP RTS trigger frames.

9. The method according to claim 1, wherein the shared TXOP includes a TXOP acquired by the cooperating AP and shared with the cooperating AP, and the subsequent communication includes the transmission of one or more frames by the cooperating AP using the at least one allocated resource.

10. A cooperative AP configured for use in a multi-access point (AP) wireless local area network (WLAN), A processor and transceiver configured to receive a Multi-AP Transmit Request (RTS) trigger frame from a cooperating AP, wherein the Multi-AP RTS trigger frame includes an identifier for the cooperating AP, resource allocation information indicating at least one resource allocated to the cooperating AP, an indication that the Multi-AP RTS trigger frame is for multi-AP cooperating operation, and a timing schedule for the cooperating AP, wherein the at least one allocated resource includes a frequency channel or resource unit (RU). The processor and the transceiver are configured to determine, based on the identifier of the cooperative AP, that the cooperative AP is addressed by the multi-AP RTS trigger frame. The processor and the transceiver are configured to determine, based on the resource allocation information, that the at least one allocated resource is allocated to the coordinating AP for communication during a shared transmit opportunity (TXOP). The processor and the transceiver are configured to transmit a transmittable (CTS) frame on the at least one allocated resource in accordance with the timing schedule to the coordinating AP and in response to the multi-AP RTS trigger frame, the CTS frame being transmitted for a short interframe time (SIFS) after the multi-AP RTS trigger frame has been received. The processor and the transceiver are configured to use the at least one allocated resource as the frequency resource of the coordinating AP for subsequent communication between the shared TXOPs. A cooperative AP characterized by having the following features.

11. The cooperative AP according to claim 10, wherein the multi-AP RTS trigger frame includes identifiers of a plurality of cooperative APs, including the cooperative AP, and the timing schedule includes respective timing information for each of the plurality of cooperative APs.

12. The collaborative AP according to claim 10, characterized in that the identifier of the collaborative AP includes an AP address or a multi-AP AP identifier (APID) assigned to the collaborative AP by the multi-AP RTS trigger frame.

13. The cooperative AP according to claim 10, wherein the multi-AP RTS trigger frame further includes information identifying the cooperative AP, or information indicating the frequency allocation of the cooperative AP.

14. The coordinate AP according to claim 10, wherein the instruction that the multi-AP RTS trigger frame is for the multi-AP coordinate operation includes a value in the trigger type subfield, or at least one bit in the multi-AP RTS trigger frame indicating that the multi-AP RTS trigger frame is a multi-AP RTS frame.

15. The cooperative AP according to claim 10, wherein the response frame transmitted by the cooperative AP in response to the multi-AP RTS trigger frame is transmitted only when there is one or more allocated resources indicated by the resource allocation information and when the wireless medium is available.

16. The cooperative AP according to claim 10, characterized in that the CTS frame reserves a wireless medium for the basic service set (BSS) associated with the cooperative AP.

17. The cooperative AP according to 16, characterized in that the medium reserved for the BSS includes a portion of the bandwidth used by the cooperative APs that transmit the multi-AP RTS trigger frames.

18. The cooperating AP according to 10, wherein the shared TXOP is acquired by the cooperating AP and includes a TXOP shared with the cooperating AP, and the subsequent communication includes the transmission of one or more frames by the cooperating AP using the at least one allocated resource.

Images