System and method for multi-AP transmission with uniform coverage

Abstract

To provide a method for multiple access point (AP) transmission.SOLUTION: A method comprises receiving a repetition beacon from each of a plurality of APs. Each received repetition beacon comprises a common information part and an AP-specific information part. The method also comprises: decoding at least a subset of the received common information parts to obtain a first parameter; decoding the received AP-specific information parts to obtain a second parameter for each of the plurality of APs; performing a calculation based on the first parameter, the obtained second parameters and a number of the plurality of APs to obtain a calculation result; and transmitting a feedback based on the calculation result to the plurality of APs.SELECTED DRAWING: Figure 19

Description

Technical Field

[0001] Cross - Reference to Related Applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 815,753, filed on March 8, 2019, the content of which is incorporated herein by reference.

Summary of the Invention

[0002] Summary

[0002] Disclosed is a method for multi - access point (AP) transmission. The method includes receiving iterative beacons from each of a plurality of APs, wherein each received iterative beacon includes a common information part and an AP - specific information part; decoding at least a subset of the received common information part to obtain a first parameter; decoding the received AP - specific information part to obtain a second parameter for each of the plurality of APs; performing calculations based on the first parameter, the obtained second parameters, and the number of the plurality of APs to obtain a calculation result; and transmitting feedback based on the calculation result to the plurality of APs.

[0003]

[0003] Disclosed is a wireless transmit - receive unit (WTRU) for multi - access point (AP) transmission. The WTRU includes a transceiver configured to receive iterative beacons from each of a plurality of APs, wherein each received iterative beacon includes a common information part and an AP - specific information part; and a processor configured to decode at least a subset of the received common information part to obtain a first parameter, decode the received AP - specific information part to obtain a second parameter for each of the plurality of APs, perform calculations based on the first parameter, the obtained second parameters, and the number of the plurality of APs to obtain a calculation result, and the transceiver is further configured to transmit feedback based on the calculation result to the plurality of APs.

[0004] Brief Description of the Drawings A more detailed understanding can be obtained from the following description, which is presented as an example in relation to the accompanying drawings, where like reference numerals in the figures indicate like elements.

Brief Description of the Drawings

[0005]

Figure 1A

[0005] FIG. 1A is a system diagram showing an example of a communication system in which one or more disclosed embodiments can be implemented.

Figure 1B

[0006] FIG. 1B is a system diagram showing an example of a wireless transmit / receive unit (WTRU) that can be used within the communication system shown in FIG. 1A, according to one embodiment.

Figure 1C

[0007] FIG. 1C is a system diagram showing an example of a radio access network (RAN) and an example of a core network (CN) that can be used within the communication system shown in FIG. 1A, according to one embodiment.

Figure 1D

[0008] FIG. 1D is a system diagram showing a further example of a RAN and a further example of a CN that can be used within the communication system shown in FIG. 1A, according to one embodiment.

Figure 2

[0009] FIG. 2 shows an example of coordinated OFDMA fractional frequency reuse (FFR).

Figure 3

[0010] FIG. 3 shows an example of resource allocation related to coordinated OFDMA FFR.

Figure 4

[0011] FIG. 4 shows an example of a scenario of coordinated nulling / coordinated beamforming (CN / CB).

Figure 5

[0012] FIG. 5 shows an example of a scenario of SU joint precoded multi-AP transmission or coordinated SU beamforming.

Figure 6

[0013] FIG. 6 shows an example of a scenario of MU joint precoded multi-AP transmission or coordinated MU beamforming.

Figure 7

[0014] An example of a scenario regarding the beacon transmission coverage of a cell-edge STA is shown.

Figure 8

[0015] An architecture is shown in which a STA can associate with an AP in a conventional manner or via a virtual AP.

Figure 9

[0016] An architecture is shown in which a STA associates only with a virtual AP.

Figure 10

[0017] A multi-AP repeated beacon that is sequentially transmitted within different time slots is shown.

Figure 11

[0018] A multi-AP repeated beacon that is transmitted simultaneously is shown.

Figure 12

[0019] An example is shown in which the leading AP can start the transmission of a multi-AP repeated beacon.

Figure 13

[0020] An example is shown in which the leading AP can transmit a multi-AP beacon trigger frame.

Figure 14

[0021] An example of a sequential transmission scheme with multiple channels is shown.

Figure 15

[0022] An example of flexible repeated beacon transmission with a repeated beacon transmission interval is shown.

Figure 16

[0023] An example of a TBTT / beacon window and t_i is shown.

Figure 17

[0024] An example of a reservation / pad signal is shown.

Figure 18

[0025] An example of the measurement and feedback of a repeated beacon is shown.

Figure 19

[0026] An example of a flowchart of a method according to an embodiment of the present application is shown.

Figure 20

[0027] An example of an aggregated beacon structure is shown.

Figure 21

[0028] An example of a separated beacon structure is shown.

Figure 22

[0029] An example of an allowable transmission window for preventing duplication of AP-specific beacons is shown.

Figure 23

[0030] An example of a non-allowable transmission window for preventing duplication of AP-specific beacons is shown.

Figure 24

[0031] An example of single / multi-AP feedback polling / triggering is shown.

Best Mode for Carrying Out the Invention

[0006] Detailed Description

[0032] FIG. 1A is a diagram showing an example of a communication system 100 in which one or more disclosed embodiments can be implemented. The communication system 100 can be a multi-connection system that provides content such as voice, data, video, messaging, and broadcast to a plurality of wireless users. The communication system 100 can enable a plurality of wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 can 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 filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0007]

[0033] As shown in FIG. 1A, the communication system 100 can 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 should be 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 within a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, each of which can be referred to as a station (STA), can be configured to transmit and / or receive wireless signals and can include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscriber per se 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, a head-mounted display (HMD), a vehicle, a drone, a medical device and medical applications (e.g., telesurgery), an industrial device and industrial applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated process chain), a home electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to without distinction as a UE.

[0008]

[0034] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to assist access to one or more communication networks such as CN106, Internet 110, and / or other network 112. By way of example, base stations 114a, 114b may be a base transceiver station (BTS), NodeB, eNode B (eNB), Home Node B, Home eNode B, next generation NodeB, e.g., gNode B (gNB), new radio (NR) NodeB, site controller, access point (AP), wireless router, etc. Although base stations 114a, 114b are each shown as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0009]

[0035] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown) such as a base station controller (BSC), radio network controller (RNC), relay node, 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 cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a particular geographic area that may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, base station 114a may use 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.

[0010]

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

[0011]

[0037] More specifically, as described above, the communication system 100 can be a multi-connection system and can use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c within the RAN 104 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish the air interface 116 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High Speed Downlink (DL) Packet Access (HSDPA) and / or High Speed Uplink (UL) Packet Access (HSUPA).

[0012]

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

[0013]

[0039] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR radio access that can establish the air interface 116 using NR.

[0014]

[0040] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c can implement LTE radio access and NR radio access together using, for example, the principle of dual connectivity (DC). Accordingly, the air interface utilized by the WTRUs 102a, 102b, 102c can be characterized by transmissions that occur between multiple types of radio access technologies and / or multiple types of base stations (such as eNBs and gNBs).

[0015]

[0041] 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 1X, 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), etc.

[0016]

[0042] The base station 114b in FIG. 1A can be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity within a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by, e.g., drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless 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 pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 in some cases.

[0017]

[0043] RAN 104 can communicate with 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 WTRUs 102a, 102b, 102c, 102d. The data can have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, mobile location-based services, prepaid calls, Internet connections, video distribution, etc., and / or can perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs using the same RAT or a different RAT as RAN 104. For example, in addition to being connected to RAN 104 that can utilize New Radio (NR) radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0018]

[0044] CN 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, 102d to access the Public Switched Telephone Network (PSTN) 108, the Internet 110, and / or other networks 112. PSTN 108 can include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). Internet 110 can include a worldwide system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) within the TCP / IP Internet protocol suite. Network 112 can include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 can include another CN connected to one or more RANs that can use the same RAT or a different RAT as RAN 104.

[0019]

[0045] Some or all of the WTRUs 102a, 102b, 102c, 102d within the communication system 100 may include a multi-mode function (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with various wireless networks over various wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may use a cellular-based wireless technology and a base station 114b that may use an IEEE 802 wireless technology.

[0020]

[0046] FIG. 1B is a system diagram showing an example of a WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmission / reception element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a removable memory 130, a detachable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 may include any sub-combination of the above elements while remaining in accordance with the embodiments.

[0021]

[0047] The processor 118 may be a general-purpose processor, a dedicated 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 can perform signal encoding, data processing, output control, input / output processing, and / or any other function that enables the WTRU 102 to operate within a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmission / reception element 122. Although FIG. 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated within an electronic package or chip.

[0022]

[0048] The transmission / reception element 122 may be configured to transmit or receive signals with a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmission / reception element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmission / reception 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 transmission / reception element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmission / reception element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0023]

[0049] In FIG. 1B, the transmission / reception element 122 is shown as a single element, but the WTRU 102 may include any number of transmission / reception elements 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmission / reception elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0024]

[0050] The transceiver 120 may be configured to modulate signals transmitted by the transmission / reception element 122 and to demodulate signals received by the transmission / reception element 122. As described above, the WTRU 102 may have a multimode function. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate by multiple RATs such as NR and IEEE 802.11, for example.

[0025]

[0051] The processor 118 of the WTRU 102 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 data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may access information in any suitable type of memory, such as a non-removable memory 130 and / or a removable memory 132, and may store data in such memory. The non-removable memory 130 may include a random access memory (RAM), a 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, etc. In other embodiments, the processor 118 may access information in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown), and may store data in such memory.

[0026]

[0052] The processor 118 may obtain power from a power source 134 and may be configured to distribute and / or control power to other components within 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 cells (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), a solar cell, a fuel cell, etc.

[0027]

[0053] Processor 118 may also be coupled to a GPS chipset 136 configured to provide position information (e.g., longitude and latitude) regarding the current location of WTRU 102. In addition to or instead of information from GPS chipset 136, WTRU 102 may receive position information on air interface 116 from a base station (e.g., base stations 114a, 114b), and / or may determine its position based on the timing of signals received from two or more nearby base stations. It will be understood that WTRU 102 may obtain position information by any suitable positioning method while remaining consistent with the embodiments.

[0028]

[0054] Processor 118 may further be coupled to other peripheral devices 138 that may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, peripheral devices 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television receiver, a hands-free headset, a Bluetooth® module, a frequency modulation (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, etc. Peripheral devices 138 may include one or more sensors, and the sensors may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geographical location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0029]

[0055] The WTRU102 may include a full-duplex radio in which transmission and reception of some or all of the signals associated with a particular subframe, for example, both UL (e.g., for transmission) and DL (e.g., for reception), can be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference by hardware self-interference (e.g., choke) or signal processing by a processor (e.g., by a separate processor (not shown) or by processor 118). In one embodiment, the WTRU102 can include a half-duplex radio and transmit and receive some or all of the signals (e.g., associated with a particular subframe of UL (e.g., for transmission) or DL (e.g., for reception)).

[0030]

[0056] FIG. 1C is a system diagram showing a RAN104 and a CN106 according to one embodiment. As described above, the RAN104 can use E-UTRA radio technology to communicate with the WTRU102a, 102b, 102c on the air interface 116. The RAN104 can also communicate with the CN106.

[0031]

[0057] The RAN104 may include eNode-Bs 160a, 160b, 160c, but it will be understood that the RAN104 may include any number of eNode-Bs while remaining in accordance with the embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRU102a, 102b, 102c on the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, for example, the eNode-B 160a can transmit and / or receive radio signals with the WTRU102a using multiple antennas.

[0032]

[0058] Each of eNode-Bs 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle decisions for radio resource management, handover decisions, scheduling of users in UL and / or DL, etc. As shown in FIG. 1C, eNode-Bs 160a, 160b, and 160c can communicate with each other on the X2 interface.

[0033]

[0059] CN106 shown in FIG. 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the above elements are shown as part of CN106, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0034]

[0060] MME162 can be connected to each of eNode-Bs 162a, 162b, and 162c in RAN104 via the S1 interface and can act as a control node. For example, MME162 can be responsible for user authentication of WTRU102a, 102b, 102c, activation / deactivation of bearers, selection of a specific serving gateway during the initial connection of WTRU102a, 102b, 102c, etc. MME162 can provide a control plane function for switching between RAN104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0035]

[0061] SGW164 can be connected to each of eNode Bs 160a, 160b, and 160c in RAN104 via the S1 interface. SGW164 can generally route and transfer user data packets between WTRU102a, 102b, and 102c. SGW164 may also perform other functions such as user plane anchoring during handover between eNode Bs, triggering paging when DL data is available for WTRU102a, 102b, 102c, and management and storage of the context of WTRU102a, 102b, 102c.

[0036]

[0062] SGW164 can be connected to PGW166, and PGW166 can provide access to a packet switched network such as the Internet 110 to WTRU102a, 102b, 102c and facilitate communication between WTRU102a, 102b, 102c and an IP-enabled device.

[0037]

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

[0038]

[0064] In FIGS. 1A - 1D, the WTRU is shown as a wireless terminal, but in certain representative embodiments it is contemplated that such a terminal can use a wired communication interface to the communication network (e.g., temporarily or permanently).

[0039]

[0065] In a representative embodiment, other network 112 can be a WLAN.

[0040]

[0066] A WLAN within an 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 an access or interface to a Distribution System (DS) that carries traffic inside and outside the BSS or to another type of wired / wireless network. Traffic to an STA originating from outside the BSS can arrive via the AP and can be delivered to the STA. Traffic originating from an STA to a destination outside the BSS can be sent to the AP so as to be delivered to their respective destinations. Traffic between STAs within the BSS can be sent via the AP. For example, a source STA can send traffic to the AP, and the AP can deliver that traffic to the destination STA. Traffic between STAs within the BSS can be regarded as and / or called peer-to-peer traffic. Peer-to-peer traffic can be sent (e.g., directly) between a source STA and a destination STA using a Direct Link Setup (DLS). In certain representative embodiments, the DLS can use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all of the STAs) can communicate directly with each other. Communication in the IBSS mode may also be referred to herein as "ad hoc" mode communication.

[0041]

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

[0042]

[0068] For example, through a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel, a High - Throughput (HT) STA can use the 40 MHz wide channel for communication.

[0043]

[0069] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 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 - consecutive 80 MHz channels, which can be referred to as an 80 + 80 configuration. In the 80 + 80 configuration, the channel - encoded data can be passed through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time - domain processing can be performed separately for each stream. The streams can be mapped onto two 80 MHz channels and data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the above 80 + 80 configuration can be reversed and the combined data can be transmitted to the Medium Access Control (MAC).

[0044]

[0070] Operation in the sub - 1 GHz mode is supported by 802.11af and 802.11ah. Compared to those used in 802.11n and 802.11ac, the channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz within the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non - TVWS spectrum. According to an exemplary embodiment, 802.11ah can support Meter - Type Control / Machine - Type Communication (MTC) such as MTC devices within a macro - coverage area. The MTC devices can have limited capabilities including specific functions, for example, support for specific and / or limited bandwidths (e.g., support only for those). The MTC devices can include a battery having a battery life exceeding a threshold (e.g., for maintaining a very long battery life).

[0045]

[0071] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah can include channels that can be designated as primary channels. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs within a BSS. The bandwidth of the primary channel can be set and / or limited by an STA among all STAs operating within a BSS that can support a minimum bandwidth operation mode. In an example of 802.11ah, even if an AP and other STAs within a BSS support operation modes of 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidths, for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only that), the primary channel can be 1 MHz wide. Carrier sensing and / or the setting of the Network Allocation Vector (NAV) can depend on the state of the primary channel. For example, if the primary channel is busy when an STA (supporting only the 1 MHz operation mode) transmits to an AP, all available frequency bands can be considered busy even if most of the available frequency bands remain unused.

[0046]

[0072] In the United States, the available frequency band that can be used by 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. Depending on the country code, the total available bandwidth for 802.11ah is from 6 MHz to 26 MHz.

[0047]

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

[0048]

[0074] RAN 104 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 104 may include any number of gNBs while remaining in line with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c over air interface 116. In one embodiment, gNBs 180a, 180b, and 180c can implement MIMO technology. For example, gNBs 180a and 180b can utilize beamforming to transmit and / or receive signals between gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a can transmit and / or receive wireless signals with WTRU 102a using multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement multi-point cooperation (CoMP) technology. For example, WTRU 102a can receive coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0049]

[0075] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using scalable cryptographic-related transmissions. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval can vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using sub-frames or transmission time intervals (TTIs) of various lengths or scalable lengths (e.g., including different numbers of OFDM symbols and / or having a variable-length absolute time duration).

[0050]

[0076] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (such as eNode-Bs 160a, 160b, 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as a mobility anchor point. In a stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement the principle of DC to communicate with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c almost simultaneously. In a non-stand-alone configuration, eNode-Bs 160a, 160b, and 160c can serve as a mobility anchor for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0051]

[0077] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown), and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Function (UPF) 184a, 184b, routing of control plane information to Access and Mobility Management Function (AMF) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, and 180c can communicate with each other over the Xn interface.

[0052]

[0078] CN 106 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and according to some, data networks (DN) 185a, 185b. Although the above elements are shown as part of CN 106, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0053]

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

[0054]

[0080] 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 management and allocation of the UE's IP address, management of the PDU session, policy enforcement and QoS control, provision of DL data notifications, etc. The type of PDU session can be IP-based, non-IP-based, Ethernet-based, etc.

[0055]

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

[0056]

[0082] CN106 can facilitate communication with other networks. For example, CN106 can include an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN106 and the PSTN108, or can communicate with such an IP gateway. Additionally, CN106 can provide access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers, to WTRU102a, 102b, 102c. In one embodiment, WTRU102a, 102b, 102c can be connected to local DN185a, 185b via UPF184a, 184b through the N3 interface to UPF184a, 184b and the N6 interface between UPF184a, 184b and DN185a, 185b.

[0057]

[0083] In view of FIGS. 1A-1D and the corresponding descriptions of FIGS. 1A-1D, one or more of the functions described herein with respect to one or more of WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DNs 185a-b, and / or any other device 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 or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate the functions of a network and / or a WTRU.

[0058]

[0084] An emulation device may be designed to perform one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more emulation devices may perform one or more or all of the functions while being fully or partially implemented and / or introduced as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all of the functions while being temporarily implemented / introduced as part of a wired and / or wireless communication network. An emulation device may be directly coupled to another device for testing and / or may use wireless communication to perform the test.

[0059]

[0085] One or more emulation devices can perform one or more functions, including all, without being implemented / introduced as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario within a test laboratory and / or a non-introduced (e.g., test) wired and / or wireless communication network to conduct tests on one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication by an RF circuit (which may include one or more antennas, for example) can be used by the emulation device to transmit and / or receive data.

[0060]

[0086] In a typical 802.11 network, a STA associates with a single AP and conducts transmissions with that AP with little or no coordination with transmissions within neighboring BSSs. A STA can follow overlapping BSS (OBSS) transmissions based on a completely independent CSMA protocol between BSSs. The 802.11ax system can support some degree of coordination between OBSSs by a spatial reuse procedure (using an OBSS packet detection (PD) procedure) to enable OBSS transmissions based on an adjusted energy detection threshold, or by knowledge of the amount of interference that can be tolerated by the receiving OBSS STA (using a spatial reuse parameter (SRP) procedure). In this application, the terms STA and WTRU may be used interchangeably unless otherwise specified.

[0061]

[0087] Some embodiments enable further coordination between OBSSs, for example, by enabling transmissions from multiple APs to a single or multiple STAs. In particular, this can be distinguished from coordinated multipoint (CoMP) transmissions in 3GPP LTE Release 10. For example, coordination between OBSSs can be implemented using an unlicensed band and can be specific to the 802.11 protocol.

[0062]

[0088] In CoMP, multiple eNBs can transmit to the same or multiple WTRUs within the same time and frequency resources using joint processing / transmission for the purpose of improving the overall throughput of the WTRUs under consideration. Dynamic cell selection can be treated as a special case of joint processing where only one of a set of eNBs actively transmits data at any given point in time. On the other hand, for the purpose of reducing the interference received by each WTRU, multiple eNBs can transmit to different WTRUs within the same time and frequency resources using coordinated beamforming / scheduling (each eNB serves its own WTRU). CoMP within LTE can achieve significant improvement in cell average and / or cell-edge throughput. It can be considered that multiple transmission antennas are available for each base station. Spatial domain signal processing at each base station can perform co-interference suppression (for other WTRUs) and optimization of signal quality (for the desired WTRU).

[0063]

[0089] Generally, it can be considered that to some extent channel state information is available at the base station, for example, by explicit feedback. Furthermore, some degree of timing and / or frequency synchronization can be assumed so as to avoid more complex signal processing for dealing with inter-carrier interference (or inter-symbol interference). Additionally, the level of cooperation between eNBs may affect specific CoMP schemes that may be possible.

[0064]

[0090] Multi-AP transmission schemes within a WLAN can be classified, for example, as cooperative OFDMA, cooperative nulling / cooperative beamforming (CN / CB), and / or cooperative SU / MU transmission. In the case of cooperative SU transmission, multiple APs transmit to a STA within one resource unit (RU). Cooperative SU transmission may include one or more of (in order of complexity) dynamic point selection, cooperative SU beamforming, and / or cooperative MU beamforming. In the case of dynamic point selection, the transmission can be dynamically selected from among one of a set of APs. Note that this may include HARQ. In the case of cooperative SU beamforming, the transmission can be performed simultaneously from multiple APs, and the transmission can be beamformed. In the case of cooperative MU beamforming, multiple APs transmit and receive data on one RU with multiple STAs.

[0065]

[0091] In cooperative OFDMA, each group of RUs can be used by only one AP to transmit and receive data. The information may be beamformed on each RU or may have MU-MIMO. The complexity can be expressed as relatively low to medium. In a simple cooperative OFDMA scheme, for example, with each AP restricted to specific RUs, the APs can divide the OFDMA RUs among themselves in a cooperative manner. A more sophisticated scheme can arise that allows a STA that is not affected by interference or does not otherwise cause interference to utilize the full bandwidth while restricting access for STAs that may be affected. This scheme can be called fractional frequency reuse (FFR). Figure 2 shows an example of cooperative OFDMA FFR. Figure 3 shows an example of resource allocation related to cooperative OFDMA FFR.

[0066]

[0092] In Coordinated Nulling / Coordinated Beamforming (CN / CB), each AP can apply precoding to transmit and receive information with its desired STAs and to suppress interference with other STAs. FIG. 4 shows an example of a CN / CB scenario. As shown in FIG. 4, AP1 can transmit and receive information with its desired STA, i.e., STA1, and AP2 can transmit and receive information with its desired STA, i.e., STA2. AP1 can suppress interference with STA2, and AP2 can suppress interference with STA2. In this case, it should be noted that data for each STA may only be required at its associated AP, but in some implementations, channel information from the other STA may be required at both APs.

[0067]

[0093] In Coordinated SU or MU (SU / MU) transmission, multiple APs can cooperate to simultaneously transmit and receive information with a single STA or multiple STAs. In this case, both channel information and data for the STAs may be required at both APs. Coordinated SU / MU transmission may include Coordinated SU transmission and / or Coordinated MU beamforming.

[0068]

[0094] In coordinated SU transmission, multiple APs can transmit to a STA within one RU. Coordinated SU transmission may include (in complex order) dynamic point selection, and / or coordinated SU beamforming, or joint precoding. In dynamic point selection, the transmission can be dynamically selected from among one of a set of APs. This selection may incorporate HARQ. In coordinated SU beamforming or joint precoding, the transmission can be simultaneous from multiple APs and can be beamformed or precoded to a desired STA on one or more RUs. FIG. 5 shows an example of an SU joint precoded multi-AP transmission or coordinated SU beamforming scenario. As shown in FIG. 5, there are two APs (AP1 and AP2) and only one STA (STA1). AP1 and AP2 can simultaneously transmit to STA1, and the transmission can be beamformed or precoded to STA1 on one or more RUs.

[0069]

[0095] In coordinated MU beamforming, multiple APs can transmit and receive data with multiple STAs on one or more RUs. FIG. 6 shows an example of an MU joint precoded multi-AP transmission or coordinated MU beamforming scenario. As shown in FIG. 6, there are two APs (AP1 and AP2) and two STAs (STA1 and STA2). Each AP can transmit and receive data with the two STAs.

[0070]

[0096] Some of the embodiments discussed in this specification are directed to joint multi-AP transmission scenarios. The following description sets forth some problems and technical solutions for solving those problems in accordance with the present application. The following description first sets forth the technical problems to be solved by the present application.

[0071]

[0097] Problem 1: Some of the embodiments discussed in this specification relate to overhead in multi-AP transmission. Using a multi-AP communication network, data to an STA can be transmitted simultaneously from multiple APs within the downlink, and data from an STA can be transmitted simultaneously to multiple APs within the uplink. To enable this capability, it may be necessary to associate an STA with multiple APs to enable simultaneous multi-AP transmission / reception. Conventional AP-STA association protocols do not facilitate this function because each STA can only be associated with one AP at a given point in time. Therefore, it may be desirable to develop a more efficient method for realizing multi-AP association.

[0072]

[0098] Problem 2: In some embodiments, multiple APs can cooperate to achieve higher peak throughput, increased efficiency, and better BSS edge coverage (e.g., a multi-AP scheme can be used to reach cell-edge STAs). Preferably, some embodiments can address fairness for cell-edge STAs and coverage of cell-edge STAs. In a single-AP scenario, an STA can typically only listen to beacons from one AP, and for an STA at the edge of the coverage area, the AP may typically have difficulty decoding beacon transmissions. Therefore, with respect to multi-AP capabilities within a network, it may be desirable to provide a scheme and mechanism for extending the coverage range for beacon transmission and reception. FIG. 7 shows an exemplary scenario regarding beacon transmission coverage of a cell-edge STA. In FIG. 7, the STA at the cell edge is indicated by an arrow. In some implementations, an STA can be reached by joint transmission. In some implementations, an STA may or may not be able to receive normal beacons.

[0073]

[0099] Problem 3: Some of the embodiments discussed in this specification relate to time synchronization (e.g., TSF) when receiving from multiple APs. In multi-AP transmission, when the cell-edge STA simultaneously receives joint transmissions from all APs within the virtual AP set regarding beacon frames, the time synchronization function at the STA can operate in the same way as a legacy STA. However, each AP has its own busy / idle medium state at the target beacon transmission time (TBTT), and it is possible that not all APs can perform joint transmission at the desired time. In that case, the transmission times of beacon frames from various APs can be shifted. Even if joint transmission can be transmitted from all APs within the virtual AP set / multi-AP set, the cell-edge STA may still not be able to receive such transmission, for example, due to local interference from an OBSS. In that case, it may be beneficial for the AP to intentionally shift its own beacon transmission in terms of time, for example, to increase diversity regarding interference.

[0074]

[0100] When beacons are transmitted at different times, the timestamp fields among them are different. Given that the rest of the content is the same among beacons within the same BI, different timestamp fields create different PSDUs. This prevents the PHY method from effectively combining signals.

[0075]

[0101] In some embodiments, to overcome this problem, all APs can use the timestamp of a specific beacon frame (e.g., the first beacon transmitted within the BI) within their own transmission beacon frames. However, this form may require that both the AP and the STA can at least detect the transmission of this beacon frame, and it may be necessary for the AP to be able to decode this specific frame. This approach may result in multiple beacons transmitted at different times. However, if the STA cannot detect the first beacon (e.g., due to a collision), the Timing Synchronization Function (TSF) may not be updated within this Beacon Interval (BI), or may be updated based on the second or later beacons. This may prevent the time diversity object from transmitting multiple beacons within the time, due to this weakness of a specific transmission at the moment of the timestamp, for example.

[0076]

[0102] Problem 4: Some embodiments discussed herein relate to multi-AP spatial puncturing. Multi-AP transmission and reception may include a group of APs that communicate with the STA. In some cases, not all APs within the group may need to participate in a specific transmission to or reception from the STA. In some implementations, the STA may facilitate the group of APs within a dynamic AP selection scheme such that only a subset of the APs are utilized.

[0077]

[0103] The following description first presents methods and procedures for solving the above-mentioned problem 1. That is, the methods and procedures disclosed herein address the above-mentioned problems regarding overhead in multi-AP transmission. To enable multi-AP transmission, multiple APs or groups of APs can form a "virtual AP" with a shared virtual basic service set identifier (vBSSID) and / or virtual service set identifier (vSSID). A STA can use the vBSSID and / or vSSID to associate without knowing that it is a group of APs. FIGS. 8 and 9 illustrate an exemplary virtual AP architecture. FIG. 8 shows an architecture in which a STA can associate with an AP in a conventional manner or with a group of APs via a virtual AP. FIG. 9 shows an architecture in which a STA can associate with a group of APs only via a virtual AP.

[0078]

[0104] In the example of FIG. 8, each AP can have its own BSS. In addition, a group of APs can have a virtual AP. A STA can associate with a conventional single AP or a virtual AP. As shown in FIG. 8, a STA located at the edge of the BSS coverage area can associate with the virtual AP, and a STA not located in the BSS coverage area can associate with an AP in a conventional manner.

[0079]

[0105] In the example of FIG. 9, each AP may not have its own BSS. A group of APs can have a virtual AP. A STA can associate with the virtual AP. When multi-AP spatial puncturing is permitted, a STA does not always have to communicate with all APs within the virtual AP group. Instead, it can communicate with a subset of the APs, and the remaining APs within the group can be considered punctured.

[0080]

[0106] A STA associated with a virtual AP may have an association identifier (AID) assigned by the virtual AP. The group of APs can use this AID to refer to the STA. When a larger number of STAs associate with the virtual AP, the number of bits representing the AID may increase. In some embodiments, a basic AID and an AID extension can be used to uniquely represent the STAs within a BSS. The basic AID can be the same size as the current AID discussed above, and the AID extension can be used when the number of STAs within the BSS exceeds a threshold.

[0081]

[0107] In DL virtual AP transmission from the virtual AP to the STA, the traffic to the STA can be communicated to all APs involved. The APs involved can include all APs within the virtual AP group or a subset of the APs used to communicate with the STA. In this way, preparations can be made to transmit the traffic from multiple APs to the STA. It should be noted that the above-described embodiments regarding DL virtual AP transmission are merely examples and are not intended to be exclusive or limiting to the present application. The DL virtual AP transmission can be implemented in any other available way as long as it follows the principles and guidelines discussed above.

[0082]

[0108] In the UL virtual AP transmission from the STA to the virtual AP, packets transmitted from the STA (e.g., received Physical Layer Convergence Protocol (PLCP) Protocol Data Units (PPDUs)) can be received by all or a subset of the relevant APs. Each AP can partially process the packet, can forward the packet to the backhaul, where more PHY layer processes can be performed. In some embodiments, each AP can identify that the reception can involve multiple APs, and thus the AP can forward the packet to the backhaul. The backhaul can perform the combination and decoding of all valid received packets. In some embodiments, each AP can identify that the reception can involve multiple APs, and thus the AP can perform channel estimation and demodulation, and can forward the demodulated soft bits (e.g., Log Likelihood Ratio (LLR)) to the backhaul. The backhaul can perform the combination of LLRs and channel decoding. In some embodiments, each AP can identify that the reception can involve multiple APs, and the AP can attempt to detect and decode the packet (e.g., PPDU). If the AP succeeds in detecting and decoding the packet, the AP can forward the decoded MAC packet to the backhaul, and in other cases, can forward the received packet or the demodulated soft bits to the backhaul. It should be noted that the above-described embodiments regarding UL virtual AP transmission are merely illustrative and are not intended to be exclusive or limiting to the present application. UL virtual AP transmission can be implemented in any other available manner as long as it follows the principles and guidelines discussed above.

[0083]

[0109] The above drawings and descriptions can assume a backhaul connection between APs. However, the APs can be connected and controlled by a central controller or in any suitable manner. In the case of a central controller, the backhaul can be replaced by the central controller. The connection can be wired or wireless. In the case of a wireless connection, the connection can share the same band / channel as the BSS's band / channel, or can use a different band / channel.

[0084]

[0110] The following technical solutions are aimed at solving the above-mentioned Problem 1 and Problem 2. That is, some of the embodiments disclosed below include multi-AP active scanning for solving the above-mentioned Problem 1 and Problem 2. The exemplary multi-AP active scanning procedure can proceed according to one or more of the following schemes.

[0085]

[0111] An AP (which can be part of a multi-AP set SSID and can be a master AP or a slave AP) can include the following information, namely a virtual BSSID, an SSID, a multi-AP beacon schedule, a preferred scanning method, and / or one or more of the members of the same multi-AP set, in its beacon, short beacon, FILS discovery frame, and / or (broadcast) probe response. The above-mentioned information will be further described as follows.

[0086]

[0112] The virtual BSSID can represent the entire multi-STA set SS. For the purpose of obtaining information or performing authentication and / or association with the multi-STA set SS, the virtual BSSID can be used by the STA to send a probe request or an authentication or association request.

[0087]

[0113] The SSID can represent the entire multi-STA set SS. For the purpose of obtaining information or performing authentication and / or association with the multi-STA set SS, the SSID can be used by the STA to send a probe request or an authentication or association request.

[0088]

[0114] A multi-AP beacon schedule can indicate a schedule in which beacons or multi-AP beacons, FILS discovery frames, and probe responses can be transmitted simultaneously or sequentially by one or more APs within a multi-AP set SS. The multi-AP beacon schedule can be indicated with respect to an offset to a TSF timer that may also be included in the probe response, or an offset with respect to the end of the current frame. The multi-AP beacon schedule can also or instead include a schedule of triggered multi-AP beacon frames, and / or multi-AP probe response frames, or FILS discovery frames.

[0089]

[0115] Preferred scanning methods can indicate preferred scanning methods including multi-AP active scanning, passive scanning, single-AP active scanning, etc. Members of the same multi-AP set can indicate one or more APs within the same multi-AP set. Alternatively or in addition, the AP can include this information in a reduced neighbor report, or in co-located or jointly hosted APs, along with an indication that they are, for example, within the same multi-AP set SS.

[0090]

[0116] It should be noted that the above-mentioned information that may be included in the beacon, short beacon, FILS discovery frame, and / or (broadcast) probe response of the AP is only shown as an example and is not intended to be exclusive or a limitation to this application. Any other available information can be included as long as it follows the principles and guidelines discussed above.

[0091]

[0117] The above information can be included in one or more of the following fields or elements, namely, the multi-AP element, the reduced neighbor report, the neighbor report, the multi-band report, the 6 GHz discovery element, and / or the out-of-band assisted discovery element. The information can be transmitted within a band or frequency channel other than the band or frequency in which the beacon is transmitted. Other neighboring APs or BSSs can include such information overhead from the information of other APs, for example, in their own multi-AP element, reduced neighbor report, neighbor report, or other fields.

[0092]

[0118] The STA can initiate the multi-AP active scanning procedure by transmitting a probe request frame that may include a multi-AP capability element. The multi-AP capability element can include a list of multi-AP functions that the STA is capable of in the uplink and / or downlink, such as multi-AP joint transmission, multi-AP MIMO, multi-AP MU-MIMO, multi-AP HARQ, multi-AP dynamic AP selection, multi-AP spatial puncturing, multi-AP spatial nulling, etc. The multi-AP capability element can also indicate the number of APs that the STA can support simultaneously.

[0093]

[0119] The probe request frame can include an SSID, a BSSID, or a virtual BSSID. The SSID, BSSID, or virtual BSSID can be used to identify a multi-AP set. A STA performing a scan may obtain information regarding the SSID, BSSID, or virtual BSSID through past associations, or through FILS discovery frames that can be transmitted by another AP and / or co-hosted or co-located APs, or transmitted on different channels or different bands, or from neighbor reports or reduced neighbor reports, or from 6 GHz discovery elements or auxiliary discovery elements, etc., based on pre-acquired knowledge. The probe request frame may include an indication indicating that it is requesting a multi-AP probe response or multi-AP response that may be included within a multi-AP capability element or multi-AP request element.

[0094]

[0120] If the AP is part of a multi-AP set SSID and can be a master AP or a slave AP, the AP can respond to the probe request in the following ways.

[0095]

[0121] If the probe request includes a multi-AP capability element and / or a multi-AP request element, and the probe request is not addressed to an SSID and / or virtual BSSID representing the entire multi-AP set SS, the AP can respond with a probe response frame that may include a multi-AP element. The multi-AP element can include all information regarding multiple APs within the same set, which can include one or more of a virtual BSSID, SSID, multi-AP beacon schedule, and / or preferred scan method. The above-mentioned information that may be included within the multi-AP element will be further described as follows.

[0096]

[0122] The virtual BSSID can represent all multi-STA set SSs. For the purpose of obtaining information or performing authentication and / or association with a multi-STA set SS, the virtual BSSID can be used by an STA to send a probe request or an authentication or association request.

[0097]

[0123] The SSID can represent all multi-STA set SSs. For the purpose of obtaining information or performing authentication and / or association with a multi-STA set SS, the SSID can be used by an STA to send a probe request or an authentication or association request.

[0098]

[0124] The multi-AP beacon schedule can indicate a schedule in which beacons or multi-AP beacons, FILS discovery frames, and probe responses can be transmitted simultaneously or sequentially by one or more APs within a multi-AP set SS. The multi-AP beacon schedule can be related to an offset referring to a TSF timer that may also be included in a probe response, or an offset referring to the end of the current frame. The multi-AP beacon schedule can also be a schedule for triggered multi-AP beacons and / or multi-AP probe responses, or FILS discovery frames.

[0099]

[0125] Preferred scanning methods can indicate preferred scanning methods including multi-AP active scanning, passive scanning, single-AP active scanning, etc.

[0100]

[0126] It should be noted that the above-mentioned information that can be included in a multi-AP element is only shown as an example and is not intended to be exclusive or a limitation to this application. Any other available information can be included as long as it follows the principles and guidelines discussed above.

[0101]

[0127] If the probe request includes a multi-AP capability element and / or a multi-AP request element, and the probe request is addressed to an SSID and / or a virtual BSSID representing all multi-AP set SSs, the AP can respond, for example, as follows in a probe response frame or a trigger frame.

[0102]

[0128] When the AP responds with a probe response frame, the probe response frame may include a multi-AP element. The multi-AP element can include all information regarding a plurality of APs within the same set that may include one or more of the following information as described above. The AP can then trigger one or more probe responses or beacon frames transmitted by one or more APs within the same multi-AP set SS. Additionally or alternatively, the AP can trigger the simultaneous transmission of a multi-AP beacon or a multi-AP probe response frame addressed to the STA performing the probe or a broadcast address. Triggering simultaneous or sequential multi-AP beacons and / or probe responses can follow the schedule of the multi-AP beacon. When the AP responds with a trigger frame to one or more APs within the same multi-AP set, the AP can trigger the simultaneous transmission of a multi-AP beacon or a multi-AP probe response frame addressed to the STA performing the probe or a broadcast address. Triggering simultaneous or sequential multi-AP beacons and / or probe responses can follow the schedule of the multi-AP beacon. The multi-AP beacon or the multi-AP probe response frame can be shared by the master AP with all other APs within the same multi-AP set SS. It should be noted that the above-described ways of responding with a probe response frame or a trigger frame are merely illustrative and are not intended to be exclusive or a limitation to this application. Any other available ways can be used as long as they comply with the principles and guidelines of this application discussed above.

[0103]

[0129] After receiving a probe response frame that may include a multi-AP element, the STA can perform further scanning and / or authentication / association according to the instructions included in the probe response frame. For example, when a preferred scanning method is shown as multi-AP active scanning, the STA can send a probe request that may also include a multi-AP element and / or a multi-AP request element to an SSID representing a multi-AP set SS and / or a virtual BSSID. When a preferred scanning method is shown as passive scanning, the STA can receive one or more beacons, probe responses, FILS discovery frames, and / or triggered beacons, probe responses, and FILS discovery frames according to a multi-AP beacon schedule. When a preferred scanning method is shown as single-AP active scanning, the STA can send a probe / authentication / association request to one or more APs included in the probe response frame or pre-acquired information.

[0104]

[0130] The following technical solutions are aimed at solving the above-mentioned problems 1 and 2. Some of the embodiments disclosed below include a multi-AP beacon. A multi-AP iterative beacon frame can be transmitted from a group of APs. In some embodiments, a plurality of APs can be grouped, and it is assumed that a backhaul connection can be used among the plurality of APs. In some embodiments, a plurality of APs or a group of APs can form a virtual AP, and those APs can share a common virtual BSSID (vBSSI) and / or a virtual SSID (vSSID) when transmitting a multi-AP iterative beacon frame. In some embodiments, a plurality of APs can form a group, and the group can be controlled by a master AP or the group can be controlled by a central controller. The group of APs can transmit a multi-AP iterative beacon using a common BSSID assigned by the master AP or the multi-AP central controller.

[0105]

[0131] The multi-AP iterative beacons transmitted from a group of APs can have the same MAC body as well as modulation and coding schemes so that the STA can combine the received signals. An indicator can indicate iterative transmission so that the receiver can combine the signals. For example, a multi-AP iterative transmission field can be set within, for example, a PLCP header, or a MAC header, or a beacon frame so that the receiving STA can combine the received signals.

[0106]

[0132] Multiple embodiments regarding multi-AP beacon transmission are shown in FIGS. 10 to 14. The following description details each of those embodiments.

[0107]

[0133] FIG. 10 shows multi-AP iterative beacons transmitted sequentially within different time slots. In this example, each AP can still transmit its own beacon for its BSS, shown in the figure as a normal beacon, whereby the STA can first decide to associate with those individual APs and later determine whether to associate with a multi-AP group according to its own ability to support multi-AP transmission. As shown in FIG. 10, AP1 can transmit a normal beacon B1, AP2 can transmit a normal beacon B2, AP3 can transmit a normal beacon B3, and AP4 can transmit a normal beacon B4. The multi-AP iterative beacon (B shown in FIG. 10) can be transmitted sequentially by a group of APs.

[0108]

[0134] In some embodiments, the first AP can start multi-AP iterative beacon transmission. The remaining APs in the group can follow an xIFS (any inter-frame spacing, such as a short IFS (SIFS), a point coordination function (PCF) IFS (PIFS), a distributed coordination function (DCF) IFS (DIFS), etc.). The transmission order can be negotiated when the APs join the group. Alternatively, the transmission order can be determined by the geometric position of the APs, the MAC address, the time of joining the group, etc.

[0109]

[0135] Figure 11 shows a multi-AP repeated beacon transmitted simultaneously. In this example, each AP can still sequentially transmit its own normal beacon for its BSS, such as the normal beacons shown in Figure 11 (e.g., B1, B2, B3, and B4). The multi-AP repeated beacon (B shown in Figure 11) can be transmitted simultaneously by a group of APs. The transitions of the multi-AP repeated beacon can be made exactly the same and fully synchronized so that the STA can decode the multi-AP repeated beacon.

[0110]

[0136] Figure 12 shows another method in which the leading AP (e.g., AP1) can start transmitting the multi-AP repeated beacon first. The remaining APs in the group can transmit the multi-AP repeated beacon frame simultaneously after a duration of xIFS has elapsed since receiving the transmission of the leading AP. In this method, the transmission of the leading AP can be regarded as a trigger frame for triggering the multi-AP simultaneous beacon transmission. As shown in Figure 12, in this method, the APs in the group can sequentially transmit their own normal beacons (e.g., B1, B2, B3, and B4).

[0111]

[0137] Figure 13 shows an example of another method in which the leading AP (e.g., AP1) can transmit a multi-AP beacon trigger frame (i.e., T shown in Figure 13). All APs in the group can transmit the multi-AP repeated beacon frame simultaneously after a duration of xIFS has elapsed immediately after the trigger frame.

[0112]

[0138] Multi-AP iterative beacons can be transmitted on multiple channels when those channels may be idle. It is possible to generalize both sequential and simultaneous transmissions for transmission cases on multiple channels. FIG. 14 shows an example of such a sequential transmission scheme. As shown in FIG. 14, each AP can still transmit its own normal beacon for its BSS, which can be shown as the normal beacons in FIG. 14, i.e., B11, B12, B21, B22, B31, B32, B41, and B42. In this example, the multi-AP iterative beacon can be sequentially transmitted on two channels in a non-overlapping format. AP1 can transmit the multi-AP iterative beacon on channel 1 within the first time slot shown in FIG. 14, and AP2 can transmit it on channel 2 within the first time slot. Similarly, AP3 and AP4 can transmit their respective multi-AP iterative beacons on channel 1 and channel 2 respectively within the second time slot. Alternatively, the leading AP may have to transmit a frame immediately before a set of multi-AP iterative beacon transmissions to synchronize the APs. The frame can be a trigger frame or a beacon frame. It should be noted that the above-described embodiments shown with respect to FIG. 14 are merely examples and are not intended to be exclusive or limiting to the present application. Multiple APs can transmit their multi-AP iterative beacons in any other different ways related to different time slots and different channels. For example, AP1 can transmit its multi-AP iterative beacon on channel 1 within the second time slot, AP2 can transmit its multi-AP iterative beacon on channel 2 within the second time slot, thus AP3 can transmit its multi-AP iterative beacon on channel 1 within the first time slot, and AP4 can transmit its multi-AP iterative beacon on channel 2 within the first time slot.

[0113]

[0139] At the end of the association process, a STA can associate with a group of APs in one channel and a different group of APs in a different channel. Some of the APs in the two groups can be physically the same. The STA may need to report back to the network regarding which APs it can hear on which channels. The network can then complete the association process using the available resources including the physical APs and channels.

[0114]

[0140] In some such methods, it can be assumed that each of the groups of APs can transmit beacons simultaneously. In some such methods, it can be assumed that the leading AP transmits and reserves the channel and the remaining APs can follow that transmission after the duration of the xIFS has elapsed.

[0115]

[0141] For example, if not all APs in a group can be used to transmit sequentially or simultaneously, e.g., due to hidden nodes or untruncated transmission, a technique as shown in FIG. 15 can be applied. As shown in FIG. 15, the iterative beacon transmission interval can be predefined or predetermined and can be known by the STA and the AP. All APs in a group can transmit a multi-AP iterative beacon within the iterative beacon transmission interval when the multi-AP iterative beacon becomes available. In some embodiments, the APs in a group cannot transmit a conventional beacon (their own beacon) within this interval. The iterative beacon transmission interval can be defined in one or more ways such as a static method, a semi-static method, and / or a dynamic method. These three methods will be described in detail with respect to specific embodiments as follows.

[0116]

[0142] In the static method, the repeating beacon transmission interval can be determined by a fixed start position and duration. The start position and duration of the interval can be default or predetermined, or can be announced within a past multi-AP repeating beacon. In one embodiment, the duration can be determined using a real-time unit such as microseconds. In another embodiment, the duration can be determined as a fractional of the beacon interval. As shown in FIG. 15, the beacon interval can be determined as the duration between two sets of different repeating beacons.

[0117]

[0143] In the semi-static method, the repeating beacon transmission interval can be determined using a fixed duration but with a dynamic start position. That is, the start position at which an AP can transmit its first frame within a multi-AP repeating beacon transmission sequence may not be a fixed position. The AP can be the leading AP. The first frame can be a beacon frame or a trigger frame. The duration of the repeating beacon transmission interval can be default or predetermined, or can be announced within a past multi-AP repeating beacon.

[0118]

[0144] In the dynamic method, the repeating beacon transmission interval can be determined as having both a dynamic start position and a dynamic duration. The start position can be the point in time when an AP transmits its first frame within a multi-AP repeating beacon transmission sequence. The duration of the interval can be adjustable due to the density of STAs within a BSS or virtual BSS. For example, in a densely deployed system, more transmissions and hidden nodes are expected, and a longer interval may be beneficial. In other cases, a shorter interval can be used. The duration of the interval can be announced within a past multi-AP repeating beacon. If the duration is not explicitly signaled, STAs and APs can reuse the same duration.

[0119]

[0145] It should be noted that the above three exemplary methods for determining the periodic beacon transmission interval are merely illustrative and are not intended to be exclusive or limiting to the present application. There may be other methods available for determining the periodic beacon transmission interval as long as the principles and guidelines discussed above are followed.

[0120]

[0146] The STA may expect to receive periodic beacons within a certain time interval. In some implementations, the time interval can be predefined / determined in advance / signaled by the AP. In some implementations, the time interval can be determined based on STA procedures. The time interval can be defined as having a start position (t0) and a duration (T). The duration can be determined, for example, using previously received periodic beacons or can be predefined by a standard, for example. The start position can be determined, for example, by a previously received periodic beacon or can be predefined by a standard if the position is fixed. In the case of a dynamic start position, the start position can be determined when the STA detects the first frame of the periodic beacon transmission. For example, in the case of a dynamic start position, the STA may face the possibility of misdetecting the start position (e.g., t1). The STA can then monitor the periodic beacon transmission interval from the misdetected start position [t1, t1 + T].

[0121]

[0147] The STA can start the iterative beacon timer at the start position t0. If the timer is less than the duration T, the STA can continue to monitor the channel for iterative beacon transmission. The STA can detect frame transmission. By checking the PLCP header of the frame, or the control trailer, or other separately encoded parts of other types, the STA can obtain transmitter identification information such as the MAC address, compressed MAC address, BSSID, compressed BSSID, BSS color, etc. The STA can recognize that the frame may be iterative transmission or HARQ transmission by detecting, for example, the iterative transmission field set to 1. If it is the first frame within the interval from the same transmitter ID, the STA can decode the frame. If decoding fails, the STA can save the frame in the buffer. If it is not the first frame from the same transmitter ID, the STA can combine the frame with the data saved in the buffer. If the frame is not successfully decoded, the STA can save the combined data in the buffer and continue to monitor the channel. If the timer exceeds the duration T, the STA can clear the buffer.

[0122]

[0148] STAs that may be associated with a BSSID carried by a multi-AP iterative beacon can be considered STAs that can communicate with a group of APs or a virtual AP. In iterative beacon transmission, a group of APs or a virtual AP can select a modulation and coding scheme (MCS) that can be supported by all of the STAs. The MCS selected can be higher than the lowest MCS supported. Although various techniques herein are discussed with respect to iterative beacon transmission schemes, similar concepts can be applied to the transmission of probe response frames and association response frames. Information elements and fields are discussed in other embodiments. It is noted that in each of FIGS. 10-14, each AP within a group can transmit one multi-AP iterative beacon within a beacon interval. However, this form can be easily extended to a general case where each AP can be permitted to transmit from 0 to N iterative beacons within a beacon interval. In one case, a group of APs can include only one AP, and that AP can still transmit multiple iterative beacons within a beacon interval. It is noted that the terms iterative beacon, multi-AP iterative beacon, and multi-AP beacon can be used interchangeably. In FIGS. 10-14, beacon frames can be used to illustrate iterative transmission from multiple APs. These schemes can be easily extended by using other control / management / data frames. For example, the beacon frame can be replaced with a sounding frame, a high-reliability data transmission frame, etc.

[0123]

[0149] The following technical solutions are aimed at solving the above problem 3. Some embodiments address the TSF for iterative beacons. Such some embodiments can address the time synchronization problem when receiving from multiple APs. In this example, it is considered that the TSFs of the APs within a virtual AP set are synchronized and a multi-AP iterative beacon transmission procedure is used.

[0124]

[0150] In some embodiments, the TSF can be signaled within the preamble of each beacon such that each iteration has its own self - contained TSF timer. The timestamp field can be 8 bytes, which size may increase the size of the preamble. An increase in size may reduce the range and reliability of the preamble and may prevent the repeating beacon from being detected by the cell - edge STA. Thus, in some embodiments, instead of the beacon's timestamp, the target beacon transmission time (TBTT) of the signal is within the beacon frame. The preamble is used to signal the time offset between the repeating beacon and the TBTT. In this approach, the preamble of repeating beacon_i can provide the receiver with the offset between the TBTT and the time of beacon_i as t_i. After a single repeating beacon or after combining multiple repeating beacons, the content of the beacon is decoded and the value of the TBTT becomes known to the receiver. Based on t_i and the receiver's built - in clock at the time of reception of beacon_i, the receiver can map the TBTT to its own built - in clock.

[0125]

[0151] Some embodiments have the advantage that all repeating beacons within the same BI have the same TBTT value in the payload, and thus can be combined (such as for HARQ transmissions). Further, the repeating beacons of the same BI must finish their transmissions within the beacon window after the TBTT, so the range of t_i is restricted by the repeating beacon transmission interval defined in the above paragraphs with respect to the beacon window or the multi-AP beacon. This window can be made smaller than the range of the timestamp values. Therefore, it may be more suitable for the offset t_i to be carried within the preamble of each repeating beacon. t_i can be conceptualized as the least significant bit (LSB) or the most significant bit (MSB) of the 64-bit timestamp of each repeating beacon. For example, if the beacon window is 10 ms, an example of t_i can be approximately the 14 LSBs of the timestamp. FIG. 16 shows an example of the TBTT / beacon window and t_i. It should be noted that the above-mentioned beacon window and timestamp are only shown as examples and are not intended to be exclusive or limiting to the present application.

[0126]

[0152] Some embodiments include further optimizations to further reduce the information representing t_i. In some embodiments, t_i is quantized at the granularity of Δt. For example, if Δt = 64 us and the beacon window is 10 ms, t_i can be represented by 8 bits within the preamble. This form may introduce ambiguity (such as an ambiguity of 64 us in this example). One way to resolve this ambiguity is to instruct the AP to always start or end the transmission of the repeating beacon at the boundary of the Δt interval, and t_i indicates the time from the TBTT to the start or end of the repeating beacon. Starting or ending at the Δt interval each presents various difficulties.

[0127]

[0153] For example, since the boundary may coincide with a medium busy period while the non-boundary duration may coincide with a medium idle time, starting at the boundary may limit the channel access opportunity. To increase the channel access opportunity, in some embodiments, a reservation signal can be used. For example, a reservation signal (or dummy signal) can be inserted before (e.g., immediately before) the actual beacon transmission so that the channel is occupied. The actual beacon transmission can start from the boundary of the Δt interval. However, the length of the reservation signal may not be an integer multiple of the OFDM symbol. Similarly, ending at the boundary may require the application of padding, and the padding may not be an integer multiple of the OFDM symbol.

[0128]

[0154] FIG. 17 shows an example of a technique for resolving this ambiguity while keeping the reservation / pad signal an integer multiple of the OFDM symbol. These symbols can be used to carry extra parity bits or training fields for protecting the PPDU, unlike an arbitrary-length busy signal that cannot be utilized by the receiver.

[0129]

[0155] As shown in FIG. 17, the pad is shown at the end of the PPDU. Alternatively, the pad can be placed at the beginning of the PPDU for use as a reservation signal. Alternatively, the pad can be placed at a predefined position within the PPDU. The pad can be used to bring the end (or start) of the PPDU within 1 OFDM symbol of the nearest Δt interval boundary. In some embodiments, the length of the PPDU signaled in the preamble is the length up to the end of the pad. The extra information in the pad can include additional parity bits or training symbols. In some embodiments, the length of the PPDU signaled in the preamble is the length up to the end of the pad, but there is no actual signal transmitted within the pad.

[0130]

[0156] To resolve the ambiguity within the OFDM symbol, one or more pairs of Short Training Field (STF) or Long Training Field (LTF) symbols can be used, for example, one without any phase adjustment and the other with a linear phase shift corresponding to the time offset between the end of the pad symbol and the boundary of the closest Δt interval. Based on the difference in the linear phase shift between the two symbols, the receiver can determine the time of the boundary of the closest Δt interval from the end time of the pad. From the time of the boundary of the closest Δt interval, the receiver can derive the TBTT using the quantized t_i (an integer multiple of Δt, 4Δt in the following example) from the preamble. In some embodiments, the duration of the pad may be fixed and can be one or more pairs of dedicated and / or longer LTFs with T_sym = Δt. In this case, it may no longer be necessary to pad the PPDU with an integer multiple of the normal OFDM symbol up to the boundary of the closest Δt interval. This may enable the direct estimation of the start / end time of the packet up to the boundary of the closest Δt interval. In various embodiments, some of the time-related parameters such as the offset t_i, quantized t_i, etc. are included within the preamble. Alternatively, those parameters may be included within any other separately encoded and CRC-protected portion.

[0131]

[0157] The following technical solutions are aimed at solving the above-mentioned problem 4. Some embodiments address multi-AP spatial puncturing transmission. In some embodiments, multi-AP transmission and reception may include a group of APs that communicate with a STA. In other embodiments, a group of APs or a virtual AP for communicating with a STA may be formed. It may not be necessary for all APs in the group to participate in a specific transmission to the STA or reception from the STA, or it may not be efficient to use all of the APs in the group for communicating with the STA. In some implementation forms, the STA may facilitate a group of APs within a dynamic AP selection scheme (e.g., a multi-AP spatial puncturing transmission scheme) such that only a subset of the APs is utilized. In other words, a multi-AP spatial puncturing transmission scheme may be used, for example, to enable a subset of the APs in the group to communicate with the STA. In that case, the STA can communicate with the subset of APs and the remaining APs in the group can be considered punctured. That is, some of the APs in the group that do not communicate with the STA can be considered "punctured" from the communication within the spatial region.

[0132]

[0158] To enable spatial puncturing transmission, a group of APs or a virtual AP can determine a subset of the APs for use in communicating with the STA. In some embodiments, a modified multi-AP iterative beacon transmission scheme is used such that the STA measures the received signal output from each AP and provides feedback to the group of APs or the virtual AP. The following description relates to such a multi-AP iterative beacon transmission scheme according to a preferred embodiment of the present application with reference to FIGS. 18 and 19. Note that the multi-AP iterative beacon transmission scheme is used as an example. This scheme can be extended to a multi-AP iterative transmission scheme by using any other frame such as a management frame, a control frame, or a data frame instead of a beacon frame.

[0133]

[0159] FIG. 18 shows the overall process of a multi-AP iterative beacon transmission scheme according to an embodiment of the present application. As shown in FIG. 18, it is assumed that AP1, AP2, AP3, and AP4 cooperate to form a multi-AP transmission / reception group or a multi-AP transmission set or a virtual AP. Each of the APs can transmit an iterative beacon including both a common information part (i.e., the common part shown in FIG. 18) and an AP-specific information part (i.e., the specific part shown in FIG. 18). Thus, as shown in FIG. 18, there are a total of four common information parts and a total of four AP-specific information parts. The common information parts are assumed to be transmitted from or transmitted (and received) by a plurality of APs and can be identical to enable combined decoding at the STA. The AP-specific information parts that can be transmitted (and received) are different for each AP in order for the STA to identify the specific AP transmitting the AP-specific information part or (discussed below) for the STA to perform AP-specific measurements. Based on decoding the common information part and the AP-specific information part, the STA can provide feedback information to the multi-AP transmission set (i.e., the multi-AP group) to assist future multi-AP transmissions, such as the selection of APs and STAs, the multi-AP scheme, the MCS, the output, etc. The common information part and the AP-specific information part can be encoded separately and protected using different CRCs.

[0134]

[0160] Note that FIG. 18 only shows the overall process of an exemplary multi-AP iterative beacon transmission scheme, and its detailed embodiment will be described below with respect to FIG. 19. In the present application, the terms "common information part" and "common part" may be used interchangeably without distinction, and the terms "AP-specific information part" and "AP-specific part" may be used interchangeably without distinction unless otherwise specified.

[0135]

[0161] In some embodiments, it should be noted that the common information part can also be referred to as the "common beacon", and the AP-specific information part can also be referred to as the "AP-specific beacon". The repeating beacon can actually be transmitted by two separate parts, one of the two parts is used for the common information part, and the other is used for the AP-specific information part. For example, in a certain scenario, the common information part and the AP-specific information part can be transmitted separately. In that case, the common information part can be called the "common beacon", and the AP-specific information part can be called the "AP-specific beacon".

[0136]

[0162] Preferably, within each repeating beacon, the common information part and the AP-specific information part can be transmitted together with a frame interval therebetween. In that case, the common information part can also be called the "common beacon", and the AP-specific information part can also be called the "AP-specific beacon". Therefore, the terms that can be used for different parts of the repeating beacon (i.e., the common part and the AP-specific part) can vary according to different embodiments.

[0137]

[0163] FIG. 19 shows a flowchart of a method 1900 for multi-AP transmission according to the present application. As shown in FIG. 19, method 1900 includes, at 1901, receiving a plurality of repeating beacons, one from each of a plurality of APs, each of the plurality of repeating beacons including a common information part and an AP-specific information part; at 1902, decoding at least one of the plurality of common information parts or a combination of one or more of the plurality of common information parts to obtain a first parameter; at 1903, decoding the plurality of AP-specific information parts to obtain a plurality of second parameters respectively related to one of the plurality of APs; at 1904, generating feedback based on the first parameter, the plurality of second parameters, and the number of the plurality of APs; and at 1905, transmitting the feedback to at least one of the plurality of APs.

[0138]

[0164] Accordingly, a WTRU according to the present application can include a transceiver configured to receive a plurality of repeating beacons, one from each of a plurality of APs, each of the plurality of repeating beacons including a common information portion and an AP-specific information portion, and a processor configured to decode at least one of the plurality of common information portions or a combination of one or more of the plurality of common information portions to obtain a first parameter, decode the plurality of AP-specific information portions to obtain a plurality of second parameters respectively associated with one of the plurality of APs, and generate feedback based on the first parameter, the plurality of second parameters, and the number of the plurality of APs, wherein the transceiver is further configured to transmit the feedback to at least one of the plurality of APs.

[0139]

[0165] The following description details the above processes and components of the WTRU from 1901 to 1905. Some embodiments may refer to the example shown in FIG. 18 for reference.

[0140]

[0166] The process in 1901 is discussed as follows. As shown in FIG. 19, method 1900 can include, at 1901, receiving a plurality of repeating beacons, one from each of a plurality of APs, each of the plurality of repeating beacons including a common information portion and an AP-specific information portion. Accordingly, the transceiver can be configured to receive a plurality of repeating beacons, one from each of the plurality of APs, each of the plurality of repeating beacons including a common information portion and an AP-specific information portion.

[0141]

[0167] A repeating beacon can also be referred to as a multi - AP repeating beacon or a multi - AP repeating beacon frame. As discussed above with respect to FIGS. 10 - 14, a multi - AP repeating beacon can be transmitted from a group of APs. In some embodiments, a plurality of APs or a group of APs can form a virtual AP, and those APs can share a common virtual BSSID (vBSSI) and / or virtual SSID (vSSID) and / or virtual BSS color when transmitting a multi - AP repeating beacon frame. In some embodiments, a plurality of APs can form a group, and the group can be controlled by a master AP or the group can be controlled by a central controller. The group of APs can transmit a multi - AP repeating beacon using a common BSSID assigned by the master AP or the multi - AP central controller.

[0142]

[0168] The multi - AP repeating beacon can be transmitted in various ways as shown in FIGS. 10 - 14. For example, as shown in FIG. 10, the multi - AP repeating beacon can be transmitted sequentially within different time slots. As shown in FIG. 11, the multi - AP repeating beacon can be transmitted simultaneously. In one embodiment shown in FIG. 12, the leading AP can start transmitting the multi - AP repeating beacon first, and the remaining APs in the group can transmit the multi - AP repeating beacon simultaneously after a duration of xIFS has elapsed since the reception of the leading AP's transmission. In the embodiment shown in FIG. 13, the leading AP can transmit a multi - AP beacon trigger frame, and all APs in the group can transmit the multi - AP repeating beacon simultaneously after a duration of xIFS has elapsed immediately after the trigger frame.

[0143]

[0169] The multi-AP iterative beacon transmitted from a group of APs may have a common information portion including the MAC body as well as modulation and coding schemes so that the STA can combine the received signals. A dedicated indicator may be required to indicate iterative transmission so that the receiver can combine the signals. A dedicated indicator such as a PLCP header, or a MAC header, or a multi-AP iterative transmission field within a beacon frame can be set so that the receiving STA can combine the received signals.

[0144]

[0170] In some embodiments, the common information portion may include the same information among a group of APs. For example, the common beacon can carry information discussed above such as a virtual BSSID, an SSID, a multi-AP beacon schedule, a preferred scanning method, members of the same multi-AP group, and other information normally carried within a beacon frame. The information carried by the common beacon can be understood with respect to the above paragraphs regarding the multi-AP scanning scheme. It should be noted that the above-described information within the common information portion is merely illustrative and is not intended to be exclusive or a limitation to the present application. The common information portion can include any available information based on the above principles of the present application as long as the information may be useful in realizing such principles.

[0145]

[0171] The AP-specific information part may include one or more of a field for the AP ID, a field for the total number of repeated beacons, a field for the repeated transmission ID, decoding parameters (e.g., decoding metrics), and / or a field for the remaining number of repeated beacons to be transmitted. The AP ID field can be used to uniquely identify an AP within a group of APs / virtual APs. The total number of repeated beacons field can be used to indicate the number of the total repeated beacons. Alternatively, this information may be carried within the common beacon part. The repeated transmission ID field can be set to k to indicate that the current transmission may be the k-th repeated transmission within a beacon set. It should be noted that the above fields within the specific information part are merely illustrative and are not intended to be exclusive or limiting to the present application. The AP-specific information part can include any available information / fields based on the above principles of the present application as long as the information / fields may be useful for implementing such principles.

[0146]

[0172] The common information part and the AP-specific information part can be implemented and transmitted using multiple different ways. The following description discusses some preferred ways for implementing and transmitting the common information part and the AP-specific information part.

[0147]

[0173] In some embodiments, the repeated beacons (i.e., multi-AP repeated beacons) can be aggregated with normal 802.11 beacons and each beacon transmitted in a coordinated manner, for example, at each AP's TBTT. In that case, the common information part and the AP-specific information part can be aggregated with the normal beacon.

[0148]

[0174] In some embodiments, the repeated beacons can be transmitted as separate beacons together with the common and AP-specific components, i.e., the common information part and the AP-specific information part. Preferably, the common information part and the AP-specific information part can be transmitted in the ways shown in FIGS. 10 to 25). The following description further discusses those ways with respect to FIGS. 10 to 25.

[0149]

[0175] Preferably, within each repeating beacon, the common information portion and the AP-specific information portion can be aggregated together without an inter-frame gap therebetween. This preferred embodiment can be implemented by the following four different scenarios shown by the four elements in FIG. 20.

[0150]

[0176] In the first scenario, the common information portion and the AP-specific information portion can be transmitted as an aggregated PPDU (A-PPDU) together with a separate preamble. As shown in the first element of FIG. 20, the common information portion 2003 can be transmitted together with the legacy preamble 2001 and the EHT preamble 2002, and the AP-specific information portion 2006 can be transmitted together with the legacy preamble 2004 and the EHT preamble 2005. There is no inter-frame gap between the common information portion 2003 and the AP-specific information portion 2006. The sequence of the common information portion and the AP-specific information portion shown by the first element is merely exemplary. For example, in one embodiment, item 2003 may represent the AP-specific information portion while item 2006 may represent the common information portion. It should be noted that the first element of FIG. 20 is shown only as an example and is not intended to be exclusive or a limitation to this application. For example, the common information portion and the AP-specific information portion can be transmitted together with a HE / EHT or later version preamble.

[0151]

[0177] In a second scenario, they can be transmitted with a single legacy preamble but with separate EHT preambles. As shown in the second element of FIG. 20, the common information portion 2013 can be transmitted with the EHT preamble 2012, the AP-specific information portion 2015 can be transmitted with the EHT preamble 2014, and the common information portion 2013 and the AP-specific information portion can be transmitted with the legacy preamble 2011. There is no inter-frame gap between the common information portion 2013 and the AP-specific information portion 2015. The sequence of the common information portion and the AP-specific information portion shown by the second element is merely illustrative. For example, in one embodiment, item 2013 may represent the AP-specific information portion while item 2015 may represent the common information portion. It should be noted that the second element of FIG. 20 is merely shown as an example and is not intended to be exclusive or a limitation to the present application. For example, the common information portion and the AP-specific information portion can be transmitted with HE / EHT or a later version preamble.

[0152]

[0178] In a third scenario, the AP-specific information can be transmitted to the common AP as a control trailer. As shown in the third element of FIG. 20, the AP-specific information portion can be carried within the control trailer 2024. The common information portion 2023 and the AP-specific information portion 2024 can be transmitted with the legacy preamble 2021 and the EHT preamble 2022. There is no inter-frame gap between the common information portion 2023 and the AP-specific control trailer 2024. The sequence of the common information portion and the AP-specific information portion shown by the third element is merely illustrative. For example, in one embodiment, item 2023 may represent the AP-specific information portion while item 2024 may represent the control trailer carrying the common information portion. It should be noted that the third element of FIG. 20 is merely shown as an example and is not intended to be exclusive or a limitation to the present application. For example, the common information portion and the AP-specific information portion can be transmitted with HE / EHT or a later version preamble.

[0153]

[0179] In the fourth scenario, the AP-specific information portion can be placed in a specific region within the PLCP header. As shown in the fourth element of FIG. 20, the AP-specific information portion can be the AP-specific header 2033. In that case, the common information portion 2034 and the AP-specific header can be transmitted together with the legacy preamble 2031 and the EHT preamble 2032. The sequence of the common information portion and the AP-specific information portion shown by the fourth element is merely illustrative. For example, in one embodiment, item 2033 can represent a common header as the common information portion, while item 2034 can represent the AP-specific information portion.

[0154]

[0180] The above description has discussed the separation between the common information portion and the AP-specific information portion. It should be noted that such separation may be necessary to enable the STA to perform repetitions, combinations, etc. with respect to the common preamble. It should also be noted that the preamble of the AP-specific portion may have different transmission parameters (e.g., MCS) from the preamble of the common information portion. For example, the AP-specific information portion can be coded and modulated at a lower data rate so that the STA can decode the AP-specific information portion without performing the repetition combinations as done for the common information portion.

[0155]

[0181] Preferably, the common information part and the AP specific information part can be transmitted together with an xIFS placed therebetween. In that case, the common information part and the AP specific information part must have separate preambles. FIG. 21 shows an exemplary separated structure for this preferred embodiment. As shown in FIG. 21, the common information part 2103 can be transmitted together with the legacy preamble 2101 and the EHT preamble, and the AP specific information part 2106 can be transmitted together with the legacy preamble 2104 and the EHT preamble 2105, and there is an xIFS interval between the common information part 2103 and the legacy preamble 2104. The sequence of the common information part and the AP specific information part shown in FIG. 21 is merely exemplary. For example, in one embodiment, item 2103 may represent the AP specific information part while item 2106 may represent the common information part. For example, the common information part and the AP specific information part can be transmitted together with the HE / EHT or a later version preamble.

[0156]

[0182] Preferably, the common information part and the AP specific part can be transmitted separately as two different beacons. That is, the common information part can be transmitted as a common beacon, and the AP specific part can be transmitted as an AP specific beacon. In that case, each AP can transmit a common beacon and an AP specific beacon, and the common beacon and the AP specific beacon can form a repeating beacon together.

[0157]

[0183] In some embodiments, the common beacon and the AP specific beacon can be transmitted separately with different TBTTs.

[0158]

[0184] In some embodiments, the common beacons are grouped and the AP specific beacons are grouped. The STA can implicitly identify the AP that transmits the common beacon based on its own transmission time for the transmission of the AP specific beacon. Such some embodiments enable the normal beacon to be used as the AP specific beacon. The order of the beacons can be signaled within the common beacon, and the order can be static, semi-static, or dynamic.

[0159]

[0185] In some embodiments, while the STA needs the AP to transmit at separate times in order to be able to decode the AP-specific part of the iterative beacon, there may be cases where the AP is located such that the Extended Distributed Channel Access (EDCA) does not prevent the AP from transmitting simultaneously. Therefore, it may be necessary to coordinate the transmission of the iterative beacon. A transmission window can be defined to ensure that the AP-specific parts of the iterative beacon do not overlap, and the AP is permitted to transmit according to its own window (for example, transmit only within its own window or not transmit within its own window). Therefore, by not overlapping multiple windows with each other, the APs can cooperate to ensure that the iterative beacons of the APs do not overlap. Therefore, both the common part and the AP-specific part of the iterative beacon can be successfully decoded. FIGS. 22 to 23 show two examples of the above-described windows. The following description will describe the windows in more detail with respect to each example.

[0160]

[0186] FIG. 22 shows an example of the above-described window. In this example, each AP is permitted to transmit the iterative beacon only within the window assigned to itself. As shown in FIG. 22, B1 represents the iterative beacon transmitted by AP1, and AP1 can transmit its own iterative beacon only within window 2201 of B1. B2 represents the iterative beacon transmitted by AP2, and AP2 can transmit its own iterative beacon only within window 2202 of B2. B3 represents the iterative beacon transmitted by AP3, and AP3 can transmit its own iterative beacon only within window 2203 of B3. B4 represents the iterative beacon transmitted by AP4, and AP4 can transmit its own iterative beacon only within window 2204 of B4.

[0161]

[0187] As shown in FIG. 22, the B1 window 2201, B2 window 2202, B2 window 2203, and B4 window 2204 cannot overlap with each other. In one embodiment, there may be no time interval between adjacent windows. In other words, the windows assigned to different APs can be connected end to end. For example, as shown in FIG. 22, there is no time interval between the B1 window 2201 and the B2 window 2202. The remaining windows can be designed in the same way. As shown in FIG. 22, AP1 can transmit the second repeated beacon only after the B4 window (indicated by 2205). That is, the duration (e.g., TBTT) between two consecutive windows assigned to AP1 can exceed the length of the windows assigned to AP2, AP3, and AP4.

[0162]

[0188] In another embodiment, there may be a time interval between two adjacent windows. For example, there may be a duration (not shown in FIG. 22) between the B1 window of AP1 and the B2 window of AP2. The remaining windows can be designed in the same way. In that case, AP1 can transmit the second repeated beacon only after the B4 window. That is, the duration (e.g., TBTT) between two consecutive windows assigned to AP1 can exceed the length of the windows assigned to the remaining APs in the group plus the time intervals between each two adjacent windows.

[0163]

[0189] It should be understood that the above-described embodiments and the examples shown in FIG. 22 are merely illustrative and are not intended to be exclusive or limiting to the present application. For example, there may be more than four (or less than four) APs in the group, and as long as the repeated beacons of those APs can be transmitted separately without overlapping with each other, the windows of those APs can be designed in the same way as discussed above.

[0164]

[0190] Figure 23 shows another example of the above-mentioned window. In this example, each AP is permitted to transmit the repeating beacon only within the window assigned to itself. As shown in Figure 23, B1 represents the repeating beacon transmitted by AP1, and "No B1 Tx" represents the window assigned to AP1. AP1 may not be permitted to transmit its repeating beacon within "No B1 Tx". B2 represents the repeating beacon transmitted by AP2, and "No B2 Tx" represents the window assigned to AP2. AP2 may not be permitted to transmit its repeating beacon within "No B2 Tx". B3 represents the repeating beacon transmitted by AP3, and "No B3 Tx" represents the window assigned to AP3. AP3 may not be permitted to transmit its repeating beacon within "No B3 Tx". B4 represents the repeating beacon transmitted by AP4, and "No B4 Tx" represents the window assigned to AP4. AP4 may not be permitted to transmit its repeating beacon within "No B4 Tx".

[0165]

[0191] As shown in Figure 23, the repeating beacons (e.g., B1, B2, B3, and B4) can be transmitted separately without overlapping each other. On the other hand, the duration of the window "No B1 Tx" can be long enough for the remaining APs (e.g., AP2, AP3, and AP4) to complete their respective repeating beacon transmissions. Further, the duration of the window "No B2 Tx" can be long enough for the remaining APs (e.g., AP3 and AP4) to complete their respective repeating beacon transmissions. Further, the duration of the window "No B3 Tx" can be long enough for the remaining AP (e.g., AP4) to complete its repeating beacon transmission.

[0166]

[0192] As shown in FIG. 23, the windows may share the same length. For example, window "No B1 Tx" may have the same length as window "No B2 Tx". As shown in FIG. 23, AP1 can transmit a second repeated beacon only after window "No B4 Tx" (indicated by 2301). That is, the duration between two consecutive repeated beacon transmissions (e.g., TBTT) may exceed the duration from the start point of window "No B2 Tx" to the end point of window "No B4 Tx".

[0167]

[0193] It should be understood that the above-described embodiments and the examples shown in FIG. 23 are merely illustrative and are not intended to be exclusive or limiting to the present application. For example, there may be more than (or less than) four APs in a group, and as long as their repeated beacons can be transmitted separately without overlapping with each other, their windows can be designed in the same way as discussed above. In another example, the windows shown in FIG. 23 may not share the same length. In that case, AP1 can transmit a second repeated beacon only after the end point of window "No B4 Tx".

[0168]

[0194] The process in 1902 is discussed as follows. As shown in FIG. 19, method 1900 may include, at 1902, decoding at least one of a plurality of common information portions or a combination of one or more common information portions to obtain a first parameter. Accordingly, the processor is configured to decode at least one of a plurality of common information portions or a combination of one or more common information portions to obtain a first parameter.

[0169]

[0195] As discussed above, the common information portion may contain the same information among groups of APs. Therefore, decrypting a subset of the common information portion can obtain the required information necessary for other processes after the process in 1902. In one embodiment, it may be sufficient to decrypt only one of all the received common information portions. For example, if the transceiver receives four common information portions from each of our APs and the four common information portions are identical, the processor can use only one of the common information portions (any one of the four common information portions) to obtain the first parameter. In another embodiment, one or more of the received common information portions can be buffered, combined, and decrypted to obtain the first parameter. For example, if the transceiver receives the first common information portion from AP1, the second common information portion from AP2, and the third common information portion from AP3, the processor can decrypt the combination of the first common information portion and the second common information portion to obtain the first parameter. The processor can also decrypt the combination of all three of the above common information portions to obtain the first parameter. The method of decrypting the combination of multiple common information portions will be further described below with respect to the process for obtaining the total number of APs within the group.

[0170]

[0196] Preferably, the process in 1902 may further include buffering a plurality of common information portions, combining the plurality of common information portions, and decrypting the combined common information portions. Therefore, in order to decrypt at least one common information portion to obtain the first parameter, the processor may be configured to buffer a plurality of common information portions, combine the plurality of common information portions, and decrypt the combination of the common information portions.

[0171]

[0197] The first parameter can indicate the maximum number of APs that can be selected to perform multi-AP transmission. Generally, method 1900 can return feedback indicating a desired combination of APs for multi-AP transmission to a group of APs, and the group of APs can use that feedback to select one or more APs for multi-AP transmission. Thus, the maximum number of APs selected to perform multi-AP transmission can also represent the number of APs that the desired combination of APs can have at most. In other words, the first parameter can indicate the maximum number of APs that a STA can select for calculation to obtain a desired combination of APs. For example, the first parameter can indicate that the maximum number of APs that can be selected for multi-AP transmission is M. In other words, there can be at most M APs in the desired combination of APs. Preferably, M is 2. That is, in a preferred embodiment, the first parameter can indicate that up to two APs in the group can be selected for multi-AP transmission. The first parameter shall be less than or equal to the total number of APs in the group. The following description further describes this first parameter with respect to the detailed embodiments below. It should be noted that in this application, the terms "AP combination" and "combination of AP(s)" may be used interchangeably without distinction unless otherwise specified.

[0172]

[0198] The first parameter can indicate a preferred multi-AP scheme that enables the STA to perform calculations in subsequent processes, such as the 1904 process. The preferred multi-AP scheme can indicate how to estimate a decoding metric (e.g., the second parameter described later). It should be noted that the decoding metric may be independent of the multi-AP scheme, and the way of selecting an AP by a group of APs may depend on the implementation form. It should also be noted that the first parameter may not be the only parameter obtained from the common information part. As long as it can help realize the principle of this application, other parameters may be obtained from the common information part. For example, the fourth parameter (described below) can be obtained from a combination of one or more common information parts.

[0173]

[0199] The process in 1903 is discussed as follows. As shown in FIG. 19, method 1900 may include, in 1903, decoding a plurality of AP-specific information parts to obtain a plurality of second parameters respectively related to one of the plurality of APs. Accordingly, the processor may be configured to decode a plurality of AP-specific information parts to obtain a plurality of second parameters respectively related to one of the plurality of APs.

[0174]

[0200] The STA can identify a specific AP by decoding the AP-specific information. The second parameter can be a decoding metric that can be used to represent the capabilities of an AP that supports multi-AP transmission with the STA. Preferably, the second parameter can include any one of the following parameters, namely, signal-to-noise ratio (SNR), signal-to-interference-plus-noise ratio (SINR), reference signal received power (RSRP), and reference signal received quality (RSRQ). The above-exemplified second parameters can be regarded as indicators related to network quality. Accordingly, the STA can perform calculations based on the network quality, thereby providing the result of a desired combination of APs.

[0175]

[0201] The above description has already set forth some examples of the second parameter, but they are not intended to be exclusive nor to be limitations on this application. As long as it can help to implement the principle of this application, the second parameter can also be any other decoding metric or parameter. The following description further sets forth the second parameter with respect to detailed embodiments.

[0176]

[0202] Discuss the process in 1904 as follows. As shown in FIG. 19, method 1900 may include generating feedback in 1904 based on a first parameter, a plurality of second parameters, and the total number of a plurality of APs. Accordingly, the processor may be configured to generate feedback based on the first parameter, the plurality of second parameters, and the number of the plurality of APs.

[0177]

[0203] The STA can obtain the total number of APs in the group by decrypting the common information part from the AP. For example, as shown in FIG. 18, the STA (or transceiver) can receive one packet or transmission (e.g., the common information part from AP1), and then the STA can attempt to decrypt the packet or transmission. If the STA fails to decrypt the packet or transmission and knows that more repeated transmissions may continue, the STA can put the received packet or transmission (e.g., the log-likelihood ratio (LLR) or the received demodulated complex number) into the buffer. Then, the receiver can continue to receive subsequent repeated transmissions, e.g., the common information part from AP2. When the receiver receives a signal that may be a repeated transmission of the buffered one, the STA can combine the received signal (e.g., the common information part from AP2) with the buffered signal (e.g., the common information part from AP1), and then decrypt it. If the STA fails to decrypt the combined signal and knows that more repeated transmissions are expected, the STA can put the updated signal (e.g., the combination of the common information parts from AP1 and AP2) into the buffer. Then, until the STA successfully decrypts the combined signal, the STA can receive, buffer, and combine more signals (e.g., the common information parts from AP3 and AP4) in the same way. In this way, the STA can know the parameter (e.g., the first parameter described above) obtained by decrypting the common information part. Further in this way, the processor can know the total number of APs in the group. For example, if the processor buffers, combines, and decrypts four common information parts, the processor can know that the total number of APs in the group is 4. In one embodiment, the total number of repetitions is within the PHY layer signaling and can be decrypted before decrypting the common information part. In another embodiment, the processor can obtain the number of APs in the group by decrypting the received AP-specific information part. For example, if the processor decrypts four AP-specific information parts, the processor knows that the total number of APs in the group is 4.

[0178]

[0204] The above-described embodiments and examples regarding the number of APs are merely illustrative and are not intended to be exclusive or limiting to the present application. It should be understood that the number of APs within a group can be obtained by any other available method as long as it can help realize the principles of the present application.

[0179]

[0205] Preferably, the process in 1904 may include the following two sub-processes, namely performing calculations based on the first parameter, a plurality of second parameters, and the number of APs to obtain a calculation result, and generating feedback based on the calculation result.

[0180]

[0206] The processor can perform calculations based on the first parameter, the acquired second parameter (i.e., the decoding metric), and the number of APs. After the calculation, one or more combinations of APs can be obtained. Based on the above-described first parameter, the desired combination of APs can include up to M APs. Therefore, among each combination of APs obtained, there can be only one AP or multiple APs (i.e., M or fewer APs). The calculation is mainly performed on the decoding metric, whereby a new decoding metric can be obtained. In the present application, those new decoding metrics obtained by calculation can be referred to as the third parameter. Preferably, the calculation result can include one or more combinations of APs. Preferably, the calculation result can further include the third parameter for each of the multiple combinations of APs. The following description further describes the combination of APs and its third parameter with respect to a detailed embodiment. In this method, the above-described calculation can be executed on the STA side, and the STA can feedback the combination of APs proposed to the AP.

[0181]

[0207] In one embodiment, the processor can perform calculations by averaging the values of the second parameter of the APs in each combination of APs. In this embodiment, calculations can be performed based on the following equation (1)

Number

[0182]

[0208] In equation (1), x n represents the value of the second parameter of the AP, n represents the number of APs in the combination of APs, and Z represents the average value of the values of the second parameter of the APs in the combination of APs.

[0183]

[0209] In another embodiment, the processor can perform the calculation by calculating the difference between the average value of the values of the second parameter of the APs in the combination of APs and the overall average value of the values of the second parameter of the APs within the group. In this embodiment, the calculation can be performed based on the following equation (2)

Number

[0184]

[0210] In equation (2), x n and x m represent the value of the second parameter of the AP, n represents the number of APs in the combination of APs, and m represents the total number of APs within the group.

[0185]

[0211] The following description details the calculations performed by the STA with respect to three examples.

[0186]

[0212] In the first example, the following assumptions are made: the first parameter (M) is 2, indicating a maximum of two APs out of the desired combination of APs; the total number of APs is 4; the second parameter is the SINR value of each AP; the SINR value of AP1 is 6; the SINR value of AP2 is 12; the SINR value of AP3 is 18; and the SINR value of AP4 is 24. Note that since there are a maximum of two APs in the desired combination of APs, the desired combination can include either only one AP or a maximum of two APs. All potential eligible combinations of APs should be considered. Based on the first parameter and the number of APs, there are four ways to select a single AP from the four APs and six ways to select two APs from the four APs (i.e., [Number] ) i.e., a total of ten different combinations of APs, namely (1) AP1, (2) AP2, (3) AP3, (4) AP4, (5) AP1 + AP2, (6) AP1 + AP3, (7) AP1 + AP4, (8) AP2 + AP3, (9) AP2 + AP4, and (10) AP3 + AP4. For combinations of APs that include two APs, the STA can obtain the SINR value of the combination of APs by averaging the two SINR values of the two APs in the combination of APs based on the above equation (1). For example, the SINR value of the combination of APs that includes AP2 and AP3 is 15. Therefore, after the calculations discussed above, the STA can obtain Table 1 below. As shown in Table 1, those obtained SINR values shown in the second row are the third parameter of the obtained combinations of APs shown in the first row.

[0187] [Table 1]

[0188]

[0213] As shown in Table 1, the calculation results include the combinations of multiple APs shown in the first row and the multiple SINR values (i.e., the third parameter) corresponding to each combination of APs.

[0189]

[0214] In the second example, the same assumptions as in the first example above are made. That is, the first parameter is 2, indicating that there are at most two APs in the desired combination of APs. The number of APs is 4, the second parameter is the SINR value of each AP, the SINR value of AP1 is 6, the SINR value of AP2 is 12, the SINR value of AP3 is 18, and the SINR value of AP4 is 24. The difference between the second example and the first example is the way of calculation. In the second example, the STA can perform the calculation based on the above equation (2). After the calculation, the STA can obtain the following combinations of APs with the SINR values shown in Table 2.

[0190]

Table 2

[0191]

[0215] In the third example, there are the following assumptions: the first parameter is 3, indicating that there are at most three APs in the desired combination of APs, and the other assumptions are the same as in the first example above. The STA can perform the calculation based on the above equation (1). After the calculation, the STA can obtain the following combinations of APs with the SINR values shown in Table 3.

[0192]

Table 3

[0193]

Table 4

[0194]

[0216] The above description has set forth several examples of calculations and two equations that can be used in the calculations, but it should be noted that they are neither exclusive nor intended to be a limitation to this application. As long as it can help to implement the principle of this application, the calculations can be performed based on any other available equations. For example, STA can perform calculations based on distributed, standard distributed, etc. It should also be noted that the above examples and their parameter values are merely illustrative and are not intended to be a limitation to this application.

[0195]

[0217] The following embodiments describe how to generate feedback based on the calculation results.

[0196]

[0218] In one embodiment, the feedback may include at least one of combinations of multiple APs based on the calculation results obtained from the process in 1904. In other words, the STA does not have to transmit all of the calculation results including all combinations of APs obtained from the calculations, and can transmit only a part of the combinations of APs.

[0197]

[0219] For example, when decrypting the common information portion, the processor can obtain a fourth parameter (K) indicating that the STA can feedback the combination of the K best APs for the group of APs. In the above first example according to Table 1, when K = 6, the feedback can include the following combinations of APs, namely AP4 (SINR value = 24), AP3 + AP4 (SINR value = 21), AP2 + AP4 (SINR value = 18), AP3 (SINR value = 18), AP2 + AP3 (SINR value = 15), and AP1 + AP4 (SINR value = 15). In this example, the AP that receives the feedback can select a specific combination of APs from the above six combinations of APs for multi-AP transmission. It should be noted that the above example of K is only shown as an example and is not intended to be a limitation to the present application. In one embodiment, the fourth parameter can be obtained by decrypting the common information portion. The method for obtaining the fourth parameter can be similar to the method for obtaining the above first parameter. For example, when the transceiver receives the first common information portion from AP1, the second common information portion from AP2, and the third common information portion from AP3, the processor can decrypt the combination of the first common information portion and the second common information portion to obtain the fourth parameter. The processor can also decrypt the combinations of all the above three common information portions to obtain the fourth parameter.

[0198]

[0220] In one embodiment, the feedback can include the calculation results obtained from the process in 1904. That is, in process 1905, the STA can transmit all the obtained calculation results to the APs within the group. As discussed above, the calculation results can include the combination of one or more APs and the new decryption metric (i.e., the third parameter) for each combination of APs. In this embodiment, the APs within the group that receive the feedback can select a specific combination of APs from all the combinations of multiple APs obtained from the calculation (such as the combinations of APs shown in Table 1) for multi-AP transmission.

[0199]

[0221] Preferably, the feedback may include both at least one of a plurality of combinations of APs obtained from the calculation and a third parameter associated with each of at least one of the plurality of combinations of APs. In the above first example according to Table 1, the feedback can be shown as in Table 4 below (assuming K = 6):

[0200]

Table 5

[0201]

[0222] The purpose of transmitting the SINR values (i.e., the third parameter) already obtained to the APs within the group is to inform the AP group of the third parameter for each combination of the obtained APs. Then, the AP group can select a desired combination of APs based on the third parameter for multi-AP transmission.

[0202]

[0223] In one embodiment, the feedback may include an AP bitmap based on the calculation result. The bitmap can be regarded as a punctured AP bitmap. In the punctured AP bitmap, the APs not selected among the combinations of APs are not displayed, or it is indicated that such APs are unavailable. In that case, such APs can be regarded as being punctured from the bitmap. The size of the bitmap can be the same as the number of APs in the group or the number of beacons in the repeated beacon transmission. In the above third example according to Table 3, when the STA wants to transmit feedback including the combination of APs AP2 + AP3 + AP4, the AP bitmap can be shown in Table 5 below:

[0203]

Table 6

[0204]

[0224] As shown in Table 5, each digit represents an AP, and there are four APs (AP1 to AP4 from left to right), where "0" indicates that AP1 is not present in this combination of APs. "1" indicates that AP2 to AP4 are present in this combination of APs. It should be understood that the bitmap included in the feedback can vary based on the APs in the combination of APs, and the above example of the bitmap shown in Table 5 is merely illustrative and is not intended to be a limitation to the present application.

[0205]

[0225] In one embodiment, the feedback can include a plurality of fields, and each of the plurality of fields can include an AP identifier that identifies a third parameter and a combination of APs. In other words, the STA can transmit a feedback that includes a plurality of fields, each of which can combine an identifier of an AP (or a set of APs) with a corresponding third parameter (e.g., a calculated SINR value). In the above first example according to Table 1, a 4-bit field AP identifier can be defined such that each bit can correspond to a specific AP within a group. For example, "1010" can indicate that AP1 and AP3 are selected in this combination of APs. The feedback transmitted by the STA in the above first example according to Table 1 can be shown as Table 6 below (assuming K = 6).

[0206]

Table 7

[0207]

[0226] As shown in Table 6, the fields are composed of pairs of an AP identifier and a SINR value. There are a total of six fields, each of which represents a combination of APs obtained from the calculation. It should be noted that the above Table 6 and the 4-bit field AP identifier indicating the APs in each combination of APs are merely illustrative and are not intended to be a limitation to the present application. Any other available identifier can be used to indicate the combination of APs as long as it can help realize the above principle of the present application.

[0208]

[0227] Preferably, the feedback can be ordered in a plurality of ways. That is, the combinations of APs in the calculation result can be ordered in a plurality of ways. For example, the combination of APs can be in descending order based on the SINR value. In the first example shown by Table 1 above, the feedback transmitted by the STA can be shown as Table 7 below (assuming K = 6).

[0209]

Table 8

[0210]

[0228] As shown in Table 7, these six combinations of APs are listed in descending order based on their SINR values. The order of the combinations of APs can implicitly identify the APs selected by the group of APs. That is, the group of APs can select APs based on the order of the combinations of APs transmitted in the feedback.

[0211]

[0229] It should be noted that the above Table 7 and the exemplary descending order are merely examples and are not intended to be exclusive or a limitation to this application. The combinations of APs in the feedback may be listed in ascending order based on the SINR value. In another embodiment, the combinations of APs in the feedback can be listed based on the number of APs in each combination of APs. For example, a combination of APs containing two APs can be listed before a combination of APs containing only one AP. It should be noted that the order of the combinations of APs is not necessarily limited to the order of the bitmap discussed above.

[0212]

[0230] In one embodiment, if a combination of APs is disqualified, the calculation result may indicate that the combination of APs is invalid. For example, in the second example shown in Table 2 above, a combination of APs with an SINR value less than "0" can be regarded as disqualified, and thus a combination of APs with an SINR value less than "0" can be shown as "invalid". In that case, in the second example above, the STA can obtain the following combinations of APs having the SINR values shown in Table 8.

[0213]

Table 9

[0214]

[0231] The process at 1905 is discussed as follows. As shown in FIG. 19, this method may include transmitting feedback to at least one of a plurality of APs at 1905. The AP that receives the feedback can select an AP or a plurality of APs from the group for multi-AP transmission.

[0215]

[0232] In some embodiments, a STA may be connectable to a single AP. In such some embodiments, the STA may be polled by a primary AP (i.e., the AP to which the STA is associated). The STA may be triggered by the primary AP for UL OFDMA / UL MU-MIMO or UORA. The primary AP can send an NDP feedback trigger to the STA, and any STA having the feedback to be sent can indicate that it has the feedback for transmission. The primary AP can then trigger or poll the STA. The STAs STA1 and STA2 shown in FIG. 24 can transmit feedback based on the above-described scheme. As shown in FIG. 24, AP1 can transmit a feedback (FB) pool 2401 to the STAs (STA1 to STA4), and then it is found that only STA1 has the feedback (FB) 2404 for transmission. Therefore, STA1 can transmit FB2404. Similarly, STAs STA2 and STA3 can transmit FB pool 2402 and FB pool 2403 respectively, and then it is found that only STA2 has the FB2405 for transmission. It should be noted that the above-described embodiments shown in FIG. 24 regarding the FB pool and FB transmission are merely examples and are not intended to be exclusive or limiting to the present application.

[0216]

[0233] In some embodiments, a STA may not be able to connect to a single STA. A set of APs may send a feedback pool or an NDP feedback trigger to a STA. Any STA that cannot hear a single AP but can hear this pool or trigger can transmit feedback to the AP. The STAs 3 and 4 shown in FIG. 24 can transmit feedback based on the above scheme. As shown in FIG. 24, the APs 1 and 2 can be regarded as a set of APs that transmit a feedback pool or an NDP feedback trigger. Both of them can transmit the same FB pool (2406, 2406’) to the STA, and then it is found that there is no STA having feedback for transmission. The APs 1 and 3 can be regarded as a set of APs that transmit a feedback pool or an NDP feedback trigger. Both of them can transmit the same FB pool (2407, 2407’) to the STA, and then it is found that the STA 3 has the FB 2408 for transmission. The APs 2 and 3 can be regarded as a set of APs that transmit a feedback pool or an NDP feedback trigger. Both of them can transmit the same FB pool (2409, 2409’) to the STA, and then it is found that the STA 4 has the FB 2410 for transmission.

[0217]

[0234] The AP can configure its multi-AP transmission based on the feedback. In some embodiments, the multi-AP advertisement frame may include the APs and STAs selected for a particular multi-AP transmission. In some embodiments, the above feedback and calculation results (e.g., the fields, AP identifiers, bitmaps discussed above) may be exchanged between the AP and the STA using a control frame, a management frame, the PLCP header of any frame, or the MAC header of any frame. After selecting an AP based on the feedback transmitted from the STA in process 1905, the selected AP can perform a multi-AP transmission (e.g., multi-AP data transmission) to the STA.

[0218]

[0235] In another embodiment, in 1904, the STA can transmit the first parameter, a plurality of second parameters, and the number of a plurality of APs to at least one AP in the group. Then the above calculations can be performed on the AP side. That is, the feedback generated by the processor in 1904 may include the first parameter, a plurality of second parameters, and the number of a plurality of APs. For example, the STA can obtain the first parameter indicating that among the desired combinations of APs, there are at most two APs, the total number of APs, i.e., 4, the second parameter is the SINR value of each AP, the SINR value of AP1 is 6, the SINR value of AP2 is 12, the SINR value of AP3 is 18, and the SINR value of AP4 is 24. Then, the AP that receives the feedback performs the above calculations and can obtain a desired combination of APs including one or more APs based on the calculations. In one way, the STA can directly feedback the quantized SINR value to the AP. In one way, the STA can calculate the average SINR value as SINR_average. Then, calculate the difference between SINR_average and the SINR value as SINR_diff_k = SINR_average - SINR_k. Here, k is the index of the AP. The STA can feedback the quantized SINR_diff_k value.

[0219]

[0236] Next, method 1900 may include, in 1906, receiving a multi-AP transmission from a combination of one or more APs. Accordingly, the transceiver may be further configured to receive a multi-AP transmission from a combination of one or more APs. Since the first parameter M indicates the maximum number of APs to be selected (i.e., there are at most M APs in the desired combination of APs), the multi-AP transmission may be performed by a plurality of APs in the group, that is, the number of APs selected for the multi-AP transmission (i.e., the number of APs in the selected combination of APs) should be less than or equal to M. Preferably, the multi-AP transmission can be performed by a combination of two or more APs.

[0220]

[0237] Furthermore, although the features and elements have been described above in specific combinations, one of ordinary skill in the art will understand that each feature and element can be used alone or in any combination with other features and elements. Additionally, the methods described herein can be implemented by 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 over a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, magnetic media such as read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, 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 station (STA), comprising: receiving a first frame from a first AP of a multi-AP set, the first frame including a virtual basic service set identifier (BSSID) associated with the multi-AP set and a beacon schedule associated with at least a second AP of the multi-AP set; transmitting an association request frame including the virtual BSSID to one of the first AP or the second AP of the multi-AP set; receiving an association response frame from the one of the first AP or the second AP of the multi-AP set, the association response frame including the virtual BSSID, the association response frame indicating successful association with the multi-AP set; receiving a downlink transmission from any AP of the multi-AP set, the downlink transmission using an assigned association identifier (AID) to refer to the STA; A method comprising:

2. The method of claim 1 , further comprising receiving a second frame from the second AP that includes the virtual BSSID associated with the multi-AP set.

3. The method of claim 1 , wherein the STA is one of a plurality of STAs associated with the multi-AP set.

4. The method of claim 1 , further comprising transmitting capability information regarding the number of APs the STA can simultaneously support.

5. The method of claim 2 , wherein the first frame and the second frame are beacon frames.

6. The method of claim 2 , wherein the first frame includes a common information portion and a first AP-specific information portion, and the second frame includes the common information portion and a second AP-specific information portion.

7. The method of claim 1 , further comprising transmitting a probe request frame to the first AP, wherein the first frame is a probe response frame from the first AP of the multi-AP set.

8. The method of claim 7 , wherein the probe response frame includes a multi-AP element indicating capability information associated with multiple APs of the multi-AP set.

9. 3. The method of claim 2, wherein the second frame is received at a target beacon transmission time (TBTT) offset from the first frame according to the beacon schedule included in the first frame.

10. The method of claim 3 , wherein the assigned AID uniquely represents the STA among the plurality of STAs associated with the multi-AP set.

11. A station (STA), a processor and a transceiver configured to receive, from a first AP of a multi-AP set, a first frame including a virtual basic service set identifier (BSSID) associated with the multi-AP set and a beacon schedule associated with at least a second AP of the multi-AP set; the processor and the transceiver are configured to transmit an association request frame including the virtual BSSID to one of the first AP or the second AP of the multi-AP set; the processor and the transceiver are configured to receive an association response frame from the one of the first AP or the second AP of the multi-AP set, the association response frame including the virtual BSSID, the association response frame indicating successful association with the multi-AP set; the processor and the transceiver are configured to receive downlink transmissions from any AP of the multi-AP set, the downlink transmissions using an assigned association identifier (AID) to refer to the STA; STA.

12. The STA of claim 11 , wherein the processor and the transceiver are further configured to receive a second frame from the second AP, the second frame including the virtual BSSID associated with the multi-AP set.

13. The STA of claim 11 , wherein the STA is one of a plurality of STAs associated with the multi-AP set.

14. The STA of claim 11 , wherein the processor and the transceiver are further configured to transmit capability information regarding a number of APs that the STA can simultaneously support.

15. The STA of claim 12 , wherein the first frame and the second frame are beacon frames.

16. The STA of claim 12 , wherein the first frame includes a common information portion and a first AP-specific information portion, and the second frame includes the common information portion and a second AP-specific information portion.

17. 12. The STA of claim 11, wherein the processor and the transceiver are further configured to transmit a probe request frame to the first AP, the first frame being a probe response frame from the first AP of the multi-AP set.

18. The STA of claim 17 , wherein the probe response frame includes a multi-AP element indicating capability information associated with at least the first AP of the multi-AP set.

19. 12. The STA of claim 11, wherein the second frame is received at a target beacon transmission time (TBTT) offset from the first frame according to the beacon schedule included in the first frame.

20. The STA of claim 13 , wherein the assigned AID uniquely represents the STA among the plurality of STAs associated with the multi-AP set.

Images