Method for enhancing WLAN using advanced HARQ design

Abstract

A method and apparatus for multiple hybrid automatic repeat request (HARQ) transmissions are provided. An access point (AP) may send multiple HARQ transmissions to multiple stations (STAs). The AP may receive H‑ARQ feedback responses from the multiple STAs. The H‑ARQ feedback may include a field for indicating that the H‑ARQ feedback is based on a codeword (CW) / CW group (CWG) confirmation. The H‑ARQ feedback may include a packet identifier (ID). The packet ID may be a HARQ transmission ID, a sequence number, an MPDU ID, or a PPDU ID. The packet ID may be carried in a PLCP header. The H‑ARQ feedback may be an aggregated CW / CWG confirmation. The H‑ARQ feedback may be carried in a null data packet (NDP). The PLCP header of the NDP packet may include a broadband PLCP header and a narrowband PLCP header.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of the following U.S. Provisional Applications, all of which are incorporated herein by reference: 62 / 757,512 filed November 8, 2018; 62 / 790,852 filed January 10, 2019; 62 / 846,215 filed May 10, 2019; and 62 / 900,084 filed September 13, 2019. Background Art

[0003] In the field of wireless communications, there are several different protocols that address different technologies and use cases. For example, the 802.11 protocol is primarily targeted at wireless local area networks. When new use cases emerge, these protocols may need to be modified and improved to target the new use cases. Summary of the invention

[0004] Methods and apparatus for multi-access point (multi-AP) hybrid automatic repeat request (HARQ) transmissions are provided. In one embodiment, a method includes: a station (STA) monitors a channel. The method further includes receiving a packet from a first AP on the channel. The first AP indicates that the packet is a multi-AP HARQ transmission. The method further includes determining that a received first AP identifier (AID) is associated with the first AP. The method further includes determining that the received packet is a multi-AP HARQ transmission. The method also includes determining that the received packet is a retransmission. The method also includes determining that a timer has not expired. The method also includes combining the received packet with a saved packet. The method also includes successfully decoding the combined packet. The method also includes stopping the timer. The method further includes sending an acknowledgment to the first AP based on an acknowledgment policy.

[0005] A method and apparatus for multi-hybrid automatic repeat request (multi-HARQ) transmission is provided. A method may include: an access point (AP) sends multiple HARQ transmissions to multiple stations (STAs). The multiple HARQ transmissions may include multiple transmissions to each of the multiple STAs for multiple H-ARQ processes. The method may include receiving H-ARQ feedback responses from the multiple STAs. The method may include the AP sending an H-ARQ feedback response trigger message to the multiple STAs. The method may include the AP receiving an H-ARQ feedback response based on the H-ARQ feedback response trigger message. The H-ARQ feedback response trigger message may include a STA identifier (ID). The H-ARQ feedback response trigger message may include a set of resource units (RUs) for use by the STA. The H-ARQ feedback response trigger message may include a resource unit (RU) factor indicating the number of RUs allowed for uplink transmission. The RU factor may include an RU purpose. The RU purpose may be repeated transmission. The RU purpose may be independent transmission.

[0006] The H-ARQ feedback may include a field for indicating that the H-ARQ feedback is based on a codeword (CW) / CW group (CWG) confirmation. The H-ARQ feedback may include a packet identifier (ID). The packet ID may be a HARQ transmission ID, a sequence number, a MAC protocol data unit (MPDU) ID, or a physical layer convergence protocol (PLCP) protocol data unit (PPDU) ID. The packet ID may be carried in a PLCP header. The H-ARQ feedback may be an aggregated CW / CWG confirmation. The H-ARQ feedback may be carried in a null data packet (NDP). The NDP packet may include a PLCP header. The PLCP header of the NDP packet may include a broadband PLCP header and a narrowband PLCP header. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0009] Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within a communication system is shown;

[0010] Figure 1C is a diagram showing that according to an embodiment, Figure 1AA system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown;

[0011] Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the communication system shown;

[0012] Figure 1E is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0013] Figure 2 is a transmission diagram showing an example of a parallel HARQ process of one or more STAs through OFDMA;

[0014] Figure 3 is a transmission diagram showing an example of a parallel HARQ process of multiple STAs through OFDMA;

[0015] Figure 4 is a transmission diagram showing an example of parallel RV transmission of one or more STAs through OFDMA;

[0016] Figure 5 is a flow chart showing an example of a multi-AP HARQ downlink process from the perspective of a STA;

[0017] Figure 6 is a transmission diagram illustrating an example of multi-AP HARQ downlink transmission;

[0018] Figure 7 is a transmission diagram illustrating an example of multi-AP HARQ downlink transmission;

[0019] Figure 8 is a transmission diagram illustrating an example of multi-AP HARQ downlink transmission;

[0020] Fig. 9 is a flow chart illustrating an example of a multi-AP HARQ uplink process from the perspective of a STA;

[0021] Fig.10 is a transmission diagram illustrating an example of multi-AP HARQ uplink transmission;

[0022] Fig.11 is a transmission diagram illustrating an example of multi-AP HARQ uplink transmission;

[0023] Fig.12is a SIG-B diagram illustrating an example of multi-AP HARQ acknowledgment;

[0024] Fig.13 is a packet diagram showing an example of an A-PPDU format sent over a backhaul of multiple STAs;

[0025] Fig.14A is a flow chart illustrating an example transmission process using a unique SIG-B field for each HARQ process;

[0026] Fig. 14B is a diagram showing an example of different levels / layers of transmission using a unique SIG-B field for each HARQ process;

[0027] Fig.15 is a grouping diagram illustrating an example in which a single SIG-B indicates HARQ information associated with all PHY subframes;

[0028] Fig.16 is a grouping diagram illustrating an example in which a single SIG-B indicates HARQ information associated with a group of PHY subframes;

[0029] Fig.17 is a SIG-B schematic diagram showing an example of a basic codeword (CW) / CW group (CWG) based acknowledgement frame format;

[0030] Fig.18 is a SIG-B schematic diagram showing an example of a frame format for aggregated codeword (CW) / CW group (CWG) based acknowledgement;

[0031] Fig.19 is a transmission diagram illustrating an example of a DL OFDMA transmission with a UL NDP CW-based acknowledgment;

[0032] Fig. 20 is a schematic diagram showing an example low density parity check (LDPC) encoding for a single codeword (CW);

[0033] Fig.21 is a schematic diagram showing an example of puncturing in LDPC coding;

[0034] Fig. 22 is a schematic diagram showing an example of padding in LDPC coding;

[0035] Fig.23 is a coding diagram showing an example of puncturing for IR-HARQ in LDPC coding;

[0036] Fig.24is a coding diagram showing an example of puncturing for IR-HARQ in the case of parity buffer wraparound;

[0037] Fig.25 is a coding diagram showing an example of puncturing for IR-HARQ with full buffer wraparound;

[0038] Fig.26 is a coding diagram showing an example of padding for IR-HARQ;

[0039] Fig. 27 is a coding diagram showing an example of padding for IR-HARQ;

[0040] Fig.28A is a schematic diagram showing an example of joint transmission from two APs to a single STA;

[0041] Fig.28B is a schematic diagram showing an example of joint transmission from two APs with a backhaul to a single STA; and

[0042] Fig.28C is a diagram showing an example of using a backhaul to correct a drift of an access link. DETAILED DESCRIPTION

[0043] Figure 1A 1 is a schematic diagram of an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources including wireless bandwidth. For example, the communication system 100 may 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-DTS-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

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

[0045] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., the CN 106, the Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of the WTRUs 102a, 102b, 102c, 102d. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation Node B such as a gNode B (gNB), a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. Although each of the base stations 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0046] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies called cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area that is relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Thus, in one scenario, the base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In one scenario, the base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals may be transmitted and / or received in a desired spatial direction.

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

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

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

[0050] In one scenario, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology that may use NR to establish the air interface 116, such as NR radio access.

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

[0052] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-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), and GSM EDGE (GERAN), among others.

[0053] Figure 1AThe base station 114b in the example may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a residence, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one scenario, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In one scenario, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In another scenario, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, and the like). Figure 1A As shown, the base station 114b may be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the CN 106.

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

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

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

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

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

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

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

[0061] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive component 122 and to demodulate signals received by the transmit / receive component 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0062] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a numeric 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 from these components. The processor 118 may also output user data to the speaker / microphone 124, the numeric keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store information in any suitable memory such as a non-removable memory 130 and / or a removable memory 132. 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, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as, for example, on a server or a home computer (not shown).

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

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

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

[0066] The WTRU 102 may include a full-duplex radio in which reception or transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous for the radio. A full-duplex radio may include an interference management unit that reduces and / or substantially eliminates self-interference by means of hardware (e.g., chokes) or by signal processing by a processor (e.g., a separate processor (not shown) or by the processor 118). In one scenario, the WTRU 102 may include a half-duplex radio that transmits and receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception).

[0067] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with one or more embodiments. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using an E-UTRA radio technology over the air interface 116. The RAN 104 may also communicate with the CN 106.

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

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

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

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

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

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

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

[0075] Although in Figures 1A-1E Although the WTRU is described as a wireless terminal, it should be appreciated that in certain typical embodiments, such a terminal may use a (eg, temporary or permanent) wired communication interface with a communication network.

[0076] Figure 1D 1 is a system diagram showing the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c using NR radio technology over the air interface 116. The RAN 104 may also communicate with the CN 106.

[0077] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one scenario, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b, 180c may use beamforming processing to transmit and / or receive signals to and / or from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. In one scenario, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers (not shown) to the 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 scenario, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0078] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or lasting different absolute time lengths).

[0079] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing other RANs (e.g., the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRU 102a, 102b, 102c may communicate / connect to the gNB 180a, 180b, 180c while communicating / connecting to another RAN (e.g., the eNode-B 160a, 160b, 160c). For example, the WTRU 102a, 102b, 102c may communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

[0080] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support network slicing, DC, implement interworking between NR and E-UTRA, route user plane data to user plane functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. Figure 1D As shown, gNB180a, 180b, and 180c can communicate with each other through the Xn interface.

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

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

[0083] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and may configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy implementation and QoS, and providing DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0084] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N3 interface, which can provide the WTRUs 102a, 102b, 102c with access to packet-switched networks (e.g., the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b can perform other functions, such as routing and forwarding packets, implementing user plane policies, supporting multi-host PDU sessions, processing user plane QoS, buffering DL packets, and providing mobility anchor processing, etc.

[0085] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one scenario, the WTRUs 102a, 102b, 102c may be connected to a local data network (DN) 185a, 185b via an N3 interface connected to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b and through the UPF 184a, 184b.

[0086] In view of Figures 1A-1E and about Figures 1A-1E , one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN185a-b, AP 190a-b, and / or one or more other any devices described herein. These simulation devices may be one or more devices configured to simulate one or more or all of the functions described herein. For example, these simulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0087] The simulation device can be designed to implement one or more tests about other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being implemented and / or deployed as part of a wired and / or wireless communication network in whole or in part to test other devices inside the communication network. The one or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to other devices to perform the test, and / or can use over-the-air wireless communication to perform the test.

[0088] One or more simulation devices can perform one or more functions, including all functions, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or a test scenario of a wired and / or wireless communication network that is not deployed (e.g., testing) to implement tests on one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication with the aid of RF circuits (e.g., which can include one or more antennas).

[0089] In some examples, Figure 1A The other network 112 may be a wireless local area network (WLAN), such as the WLAN defined by IEEE802.11. Figure 1E is a system diagram illustrating an example communication system (eg, a WLAN).

[0090] A WLAN in infrastructure basic service set (BSS) 191a and 191b mode may have access points (APs) 190a and 190b for BSS 191a and 191b, respectively, and one or more WTRUs 102a-e (e.g., STAs) associated with APs 190a, 190b. As discussed herein, a given BSS may be referred to as a network and may refer to communications occurring locally. APs 190a, 190b may have access or interfaces to a distribution system (DS) or another type of wired / wireless network that carries traffic entering and / or leaving the BSS (not shown). Traffic to a WTRU originating outside of a BSS (e.g., 191a, 191b) may arrive through an AP (e.g., 190a, 190b) and may be delivered to the WTRU. Traffic from WTRUs 190c-e to destinations outside of BSS 191a may be sent to AP 190a to be delivered to the respective destinations. Traffic between WTRUs 190c-e within a BSS 191a may be sent through AP 190a, for example, where a source WTRU 102c may send traffic to AP 190a, and the AP 190a may deliver the traffic to a destination STA 190d. Traffic between STAs (e.g., 190c-e) within a BSS (e.g., 191a) may be considered and / or referred to as point-to-point traffic. The point-to-point traffic may be sent using a direct link setup (DLS) between (e.g., directly between) a source WTRU and a destination WTRU. In certain exemplary embodiments, the DLS may use 802.11e DLS or 802.11z channelized DLS (TDLS).

[0091] In some cases, a WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. Here, the IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode.

[0092] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon on a fixed channel (e.g., a primary channel). The primary channel may have a fixed width (e.g., a bandwidth of 20 MHz) or a dynamically set width. The primary channel may be a working channel of the BSS and may be used by STAs to establish a connection with the AP. In some cases, carrier sense multiple access (CSMA / CA) with collision avoidance (e.g., in an 802.11 system) may be implemented. For CSMA / CA, STAs (e.g., each STA) including the AP may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. In a given BSS, one STA (e.g., only one station) may transmit at any given time.

[0093] A high throughput (HT) STA may communicate using a 40 MHz wide channel (eg, by combining a 20 MHz wide primary channel with a 20 MHz wide adjacent or non-adjacent channel to form a 40 MHz wide channel).

[0094] Very high throughput (VHT) STA can support channels with widths of 20MHz, 40MHz, 80MHz and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels or by combining two discontinuous 80MHz channels (this combination can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be transmitted and passed through a segment parser, which can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately on each stream. The stream can be mapped on the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0095] 802.11af and 802.11ah support working modes below 1 GHz. Compared with 802.11n and 802.11ac, the channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. In some cases, 802.11ah can support meter type control / machine type communication (MTC) (e.g., MTC devices in macro coverage areas). MTC devices can have certain capabilities, such as limited capabilities including support (e.g., only support) certain and / or limited bandwidths. The MTC device may include a battery, and the battery life of the battery is higher than a threshold (e.g., for maintaining a very long battery life).

[0096] A WLAN system that can support multiple channels and multiple channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) may include a channel that can be designated as a primary channel. The bandwidth of the primary channel may be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a certain STA, wherein the STA originates from all STAs operating in the BSS that supports the minimum bandwidth operating mode. In an example of 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz and / or other channel bandwidth operating modes, for STAs (such as MTC-type devices) that support (for example, only support) 1MHz mode, the width of the primary channel may be 1MHz. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy (for example, because a STA (which only supports the 1MHz operating mode) is transmitting to the AP), then all available frequency bands may be considered busy even if most of the available frequency bands remain idle.

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

[0098] In general, high-efficiency WLAN (HEW) can enhance the quality of service that all users experience for wide-spectrum wireless users in many usage scenarios, including high-density scenarios in the 2.4GHz, 5GHz, and 6GHz bands. Use cases that support dense deployment of APs and STAs and associated radio resource management (RRM) technologies can be introduced into HEW. Potential applications of HEW may include usage scenarios such as high user density scenarios (e.g., train stations, stadium events, enterprise / retail environments, etc.), which can address the increased reliance on video / data delivery and wireless services for medical applications. HEW can be implemented in 802.11ax.

[0099] In addition, 802.11ax can be used for various scenarios with short packets, including: virtual office; TPC ACK; video stream ACK, device / controller (mouse, keyboard, game control, etc.); access-probe request / response; network selection-probe request, ANQP; and network management-control frames.

[0100] 802.11ax may have multi-user (MU) features including UL and DL OFDMA and UL and DL MU-MIMO. In addition, there may be mechanisms for multiplexing UL random access for different purposes.

[0101] Hybrid Automatic Repeat Request (HARQ) is a transmission error control technique in wireless communication networks that relies on a combination of error correction codes and retransmissions. HARQ has been used in some communication systems such as 3GPP UMTS and LTE.

[0102] There are two popular types of HARQ combining schemes: append combining (CC) HARQ and incremental redundancy (IR) HARQ.

[0103] For the append-combining HARQ scheme, each retransmission may contain the same data and parity bits. The receiver may use maximum ratio combining (MRC) to combine the received packet with the previous transmission. Append-combining may be considered as repetition coding, where each retransmission increases the ratio of energy per bit to noise power spectral density (E / P) at the receiver. b / N0).

[0104] For IR HARQ schemes, each retransmission can use a different set of coded bits (e.g., a different redundancy version generated by puncturing the encoder output). For turbo codes, this means different systematic bits and parity bits. At each retransmission, the receiver can obtain additional information. The retransmission may contain only parity bits or may be self-decodable.

[0105] HARQ schemes can be classified as synchronous or asynchronous, with retransmissions in each case being either adaptive or non-adaptive. For synchronous HARQ, retransmissions of each process can occur at a predetermined time relative to the initial transmission. Therefore, there is no need to signal the HARQ process ID, which can be inferred from the retransmission timing. For asynchronous HARQ, retransmissions can occur at any time relative to the initial transmission. Therefore, explicit signaling is required to indicate the HARQ process ID to ensure that the receiver can correctly associate each retransmission with the corresponding previous transmission.

[0106] In LTE, the HARQ entity is located in the MAC layer, which is responsible for transmit / receive HARQ operations. The transmit HARQ operation includes the transmission and retransmission (one or more) of a transport block, and the reception and processing of ACK / NAK signaling. The receive HARQ operation includes receiving a transport block, combining the received data, and generating ACK / NAK signaling based on the decoding result. In order to achieve continuous transmission while decoding the previous transport block, up to eight parallel HARQ processes can be used to support multi-process "stop and wait" (SAW) HARQ operations. Multi-process HARQ can interleave several independent SAW processes in a timely manner so that all transmission resources can be used by one of these processes. Each HARQ process is responsible for a separate SAW operation and manages a separate buffer.

[0107] In LTE, asynchronous adaptive HARQ is used in the downlink and synchronous HARQ is used in the uplink, which may be adaptive or non-adaptive.

[0108] In LTE, the following signaling can be used to support HARQ: HARQ process ID (e.g., only for asynchronous HARQ); new data indicator (NDI), which can be toggled when a new packet transmission starts; redundancy version (RV) of the transport block (e.g., only for adaptive HARQ); and modulation and coding scheme (MCS) (e.g., only for adaptive HARQ).

[0109] In NR, the following HARQ features can be supported: multiple HARQ processes; dynamic and semi-static HARQ ACK codebooks; codeword block group CBG-level HARQ retransmissions; asynchronous and adaptive HARQ; and flexible timing between data transmission and HARQ ACK feedback.

[0110] In NR, there may be CBG-level HARQ retransmissions, where a transport block (TB) may contain one or more CBGs, which may have their own HARQ ACK bits. Therefore, the transmitter may retransmit part of the TB. Two CBG-related signaling fields, CBG Transmission Information (CBGTI) and CBG Clear Information (CBGFI), may be carried by the downlink control information (DCI). The CBGTI indicates the CBG(s) carried by the (re)transmission. When the CBGFI is set to "0", it may indicate that an earlier received instance of the same CBG being transmitted may be corrupted. When the CBGFI is set to "1", it may indicate that the CBG being retransmitted may be combined with a previously received instance of the same CBG.

[0111] In NR unlicensed (NR-U) (where the device operates in one or more unlicensed or shared frequency resources or in some combination of licensed and unlicensed bands), HARQ feedback can be sent on unlicensed bands. NR-U can utilize multiple mechanisms to support flexible triggering and multiplexing of HARQ feedback for one or more DL HARQ processes. By introducing multiple mechanisms for providing multiple and / or complementary time domain and / or frequency domain transmission opportunities, NR-U can handle reduced HARQ ACK / NAK transmission opportunities for a given HARQ process due to LBT failure. In addition, NR-U can have HARQ ACK / NAK transmissions for corresponding data in the same shared channel occupancy / occupancy time (COT). In some cases, the HARQ ACK / NAK must be sent in a COT separate from the COT in which the corresponding data is sent.

[0112] For Extremely High Throughput (EHT), increased peak throughput and improved efficiency of 802.11 networks can be addressed. Use cases for EHT can include applications that require high throughput and low latency, such as WLAN video, augmented reality (AR), and virtual reality (VR). EHT can employ one or more of the following features: multiple APs; multiple bands; 320MHz bandwidth; 16 spatial streams; HARQ; full-duplex (in both time and frequency domains); AP coordination; semi-orthogonal multiple access (SOMA); and new designs for 6GHz channel access.

[0113] HARQ for EHT can be used to combat weak link adaptation. The HARQ can combine aggressive MCS and other PHY features to provide enhanced performance for BSS edge coverage (e.g., coverage for STAs that are physically far away from the nearest transmission source (e.g., an AP or another STA) and may be at the farthest possible distance from the transmission source). HARQ can be used in EHT situations, such as MU PPDU or trigger-based (TB) PPDU. HARQ can provide a 10-30% gain using append combining, and can potentially provide higher throughput gains if incremental redundancy is used.

[0114] Although the processes, devices, and systems involving the techniques discussed herein generally relate to HARQ implementations in EHT scenarios, these techniques are also applicable to other wireless technologies and scenarios, and the examples and instances described are not intended to limit how, where, when, or for what these techniques may be applied.

[0115] In some use cases of EHT involving low-latency applications (e.g., gaming, augmented reality, virtual reality, etc.), STAs may need to transmit many small packets with low latency and high reliability. In one approach, UL / DL OFDMA can be used with HARQ to support these low-latency and high-reliability (e.g., ultra-reliable) applications. In one example, HARQ transmissions can be performed concurrently on multiple resource units (RUs). As discussed herein, a RU can be a basic transmission unit of resources (e.g., time, frequency, etc.). A RU can be replaced by a subchannel or a resource of a channel. For example, in 802.11, a subchannel can be a 20MHz channel.

[0116] Figure 2 201 and 202. The AP 211 may assign multiple RUs to a single STA1 among multiple STAs 212. The AP 211 may assign N RUs to STA1. At 201 and 202, the AP 211 may concurrently send multiple parallel transmissions with different HARQ process IDs to STA1, where each transmission is on a different RU: on RU1, the AP 211 may send a first transmission for HARQ process ID 1 (e.g., HARQ ID 1Tx1 to STA1); on RU2, the AP 211 may send a first transmission for HARQ process ID 2 (e.g., HARQ ID 2Tx 1 to STA1); and, on RU N, the AP may send a first transmission for HARQ process ID N.

[0117] At 202, there may be a HARQ trigger frame (TRF) for each HARQ part to trigger a HARQ response from each STA, such as STA1 (e.g., and any other STA 212), and the TRF may be included in the same PPDU containing the HARQ transmission. For example, TRF on RU1 to STA1 HARQ ID 1, TRF on RU2 to STA1 HARQ ID2, and so on, up to TRF on RU N to STA1 HARQ ID N.

[0118] In some cases, the AP may send a trigger frame for the HARQ process ID before it transmits HARQ data on one or more RUs (eg, where 202 precedes 201).

[0119] At 203, a HARQ response may be sent from STA 212 (e.g., STA1), such as one or more acknowledgements (ACKs), negative acknowledgements (NAKs), or block acknowledgements (BAs) for a given HARQ process (e.g., ACK / NACK HARQ ID 1 sent in the RU assigned in the HARQ trigger frame). Note that for each RU, there may be no HARQ response, such as the empty boxes shown at 203, where each box corresponds to one RU.

[0120] The one or more STAs 212 may indicate their HARQ response time to the AP 211, and vice versa. The one or more STAs 212 may indicate the HARQ response time when they are associated with an AP (e.g., AP 211), and the AP 211 may include its HARQ response time in an element (e.g., an EHT capability element, or a HARQ element, etc.). Such an indication may be included in a probe request / response frame, a beacon and short beacon frame, a (re)association request / response frame, a FILS discovery frame, or other types of control management frames.

[0121] At 204 and 205, the HARQ process may continue as needed, depending on whether the STA 212 received the previous HARQ transmission (e.g., at 201). Thus, in some cases, a second transmission (Tx2) may be needed, but it will have the same HARQ ID (e.g., HARQ ID 2Tx2 to STA1). In other cases, if the transmission is successful, a new first transmission (Tx 1) with a new HARQ ID may be used in the resource, and the previously used HARQ ID may be incremented (e.g., HARQ ID N+1Tx 1 to STA1), and this will continue until a certain value k or the need is met (e.g., HARQ ID N+k Tx 1 to STA1). At 205, one or more parts of the process may be repeated (e.g., continued HARQ transmissions, acknowledgments, etc.).

[0122] In some cases, such as in the presence of known HARQ response times as described herein, at a scheduled time or when the transmitting AP 211 acquires the channel and any HARQ response time has expired (e.g., see 206), the transmitting AP 211 may send a multi-HARQ ID block acknowledgement request (BAR) to solicit responses for one or more HARQ process IDs to one or more receiving STAs 212. The multi-HARQ ID BAR may indicate the HARQ process IDs for which responses are solicited.

[0123] At 207, in the event that a multiple HARQ ID BAR is sent, the one or more receiving STAs 212 may then transmit a multiple HARQ block acknowledgement (BA) to provide a response to the status of the HARQ operation for the indicated HARQ process ID.

[0124] Although Figure 2 The example of is shown as having a transmitting AP and a receiving STA, but in some cases, the transmitting AP (eg, AP 211) may be replaced by a transmitting STA, and / or the receiving STA may be replaced by an AP.

[0125] Before the indicated HARQ response time expires, a STA performing HARQ operation with another STA may not request HARQ ACK / NAK / BA from the other STA, where the indicated HARQ response time starts at the end of the PPDU containing the HARQ transmission. The response may be in the RU as indicated by the trigger frame or over the entire channel bandwidth. In addition, the HARQ ACK / NAK / BA may be implemented using several confirmation response options, such as: ACK, NAK, not ready, no signal detected, conflict, interference, and request to restart the HARQ process. For the ACK confirmation option, the response may indicate that the HARQ transmission and / or its RV has been correctly received and decoded. For the NAK confirmation option, the response may indicate that the HARQ transmission and / or its RV has been received, but the decoding failed. NAK may also include additional feedback information, such as a recommended RV, a recommended MCS, a recommended RU / channel, a recommended retransmission, etc. For the not ready confirmation option, the response may indicate that the receiving STA has detected the signal of the HARQ transmission and / or its RV, however, it has not yet completed decoding and needs more time before an ACK / NAK can be provided; the response option may also include an expected response time. For the signal not detected confirmation option, the response may indicate that the receiving STA has not detected the HARQ transmission and / or its RV; this may be due to channel attenuation, destructive addition of signals, low transmit power or other reasons. For the conflict confirmation option, the response may indicate that the HARQ transmission and / or its RV has experienced a collision with another packet or frame on the wireless medium; this may mean that the received signal may be useful for future combination and processing, and a new transmission should be sent. For the interference confirmation option, the response may indicate that there is strong interference, such as high-power microwave energy or NR-U transmission on the same frequency band; the response may imply that the received signal may be useful for future combination and processing, and a new transmission should be sent. For the request to restart the HARQ process acknowledgment option, the response may indicate that the receiver finds it more valuable to restart the HARQ process rather than continue with additional RVs or retransmissions, which may be due to poor signal, poor received signal, poor channel conditions, or poor interference or collisions.

[0126] The transmitting STA that receives these responses (e.g., ACK, NAK, not ready, no signal detected, conflict, interference, or request to restart the HARQ process) can perform different operations. When an ACK is received, the transmitting STA can delete the cached copy for the HARQ process ID and continue with the next HARQ process ID. When a NAK is received, the transmitting STA can decide to send another copy of the same frame, or send an RV for the same HARQ process ID to continue the HARQ operation for the HARQ process ID. If the number of retransmissions and / or RVs has reached a threshold, the transmitting STA can stop or abandon the HARQ process. When a not ready response is received, the transmitting STA can send another HARQ block ACK request (BAR) or trigger frame or MU HARQ BAR to the receiving STA after a certain time expires to solicit a response to the current HARQ process ID. Such a time can be indicated by the receiving STA (e.g., HARQ response time) or indicated in the not ready response. When a response is received that no signal, collision or interference is detected, the transmitting STA may retransmit the packet / frame or send another RV for the HARQ process ID. This may occur on a different RU or channel, or using a different transmit power, which may be recommended by the receiving STA in a previous response.

[0127] When a response requesting the restart of a HARQ process is received, the transmitting STA may restart the current HARQ process as if a previous transmission for the current HARQ process ID had never occurred. This process may occur on a different RU or channel, or by using a different transmit power, which may be recommended or indicated by the receiving STA in the previous response. Scheduling of responses for the HARQ process ID may be done in the header of the transmitted HARQ frame.

[0128] Figure 3 is a transmission diagram showing an example of parallel HARQ processes of multiple STAs through OFDMA. Figure 3 and Figure 2 can be similar, except Figure 3 An example of multiple HARQ transmissions for multiple STAs is shown. At 301 and 302, AP 311 may send concurrent transmissions of multiple HARQ process IDs for multiple STAs 312 (e.g., STA1, STA2, STA3, etc.). For example, 301 shows an initial portion of a packet transmission, where a TRF may follow, as shown in 302. As shown, there may be a transmission of HARQ ID1Tx 1 to STA 1, and another concurrent transmission of a different HARQ ID to the same STA1, and multiple concurrent HARQ transmissions for multiple HARQ IDs to STA2.

[0129] At 302, a HARQ trigger frame (TRF) for each HARQ ID may trigger a HARQ response from each STA 312 (e.g., STA1), and the TRF may be included in the same PPDU containing the HARQ transmission. For example, a TRF may be sent to STA1 with HARQ IDs 1 (e.g., TRF to STA1 HARQ ID 1) to K, and TRFs for HARQ IDs 1 to N may be sent to STA2 concurrently. Here, K and N are some integers.

[0130] At 303, the responses of the parallel HARQ processes for multiple STAs 312 may be Figure 2 The method is similar to that described in the example of , and may be triggered by a trigger frame, or scheduled by a response scheduling field in a header of a HARQ transmission, or triggered by a multi-STA multi-HARQ ID BAR frame, wherein in the multi-STA multi-HARQ ID BAR frame, resources may be allocated for STAs to send their responses for HARQ processes in the uplink. The trigger frame, the response scheduling header, and / or the multi-STA multi-HARQ ID BAR frame may identify each tuple, which may contain one or more of the following: a service ID (TID), a STA ID, or a HARQ process ID for each RU on which a HARQ process response may be triggered.

[0131] At 304 and 305, the HARQ process may continue as needed, depending on whether the STA received the previous HARQ transmission (e.g., at 301). In the case where the transmission is unsuccessful, there may be a second transmission (Tx2) with the same HARQ ID (e.g., HARQ ID 1Tx 2 to STA 2, or HARQ ID K Tx 2 to STA 1). In the case where the transmission is successful, there may be a new transmission with a new HARQ ID (e.g., HARQ ID K+1Tx 1 to STA 1). At 305, one or more steps of the process may be repeated (e.g., continuing HARQ transmissions, confirmations, etc.).

[0132] In some cases, such as in the presence of known HARQ response times as described herein, at the scheduled time or when the transmitting AP 311 acquires the channel and any HARQ response time has expired, the transmitting AP 311 may send a multi-HARQ ID block acknowledgement request (BAR) to one or more receiving STAs 312 to solicit responses regarding one or more HARQ process IDs (e.g., see 306). The multi-HARQ ID BAR may indicate the HARQ process IDs of the solicited responses. The response at 307 may contain one or more of a HARQ process ID, a STA ID, or a TID. The STA ID may be a MAC address or an association ID (AID), or a compressed form of these or other IDs.

[0133] In some cases, a trigger frame (TRF) may be used by the AP to trigger the transmission of multiple HARQ process IDs concurrently from the same or multiple STAs in the uplink. The trigger frame may indicate the STA ID. For example,

[0134] In some cases, the AP may use a trigger frame to trigger transmissions from multiple STAs concurrently in the uplink, and the trigger frame indicates the RU set for the transmitting STA and announces the RU factor Z, which indicates the number of RUs allowed for uplink transmission. The AP may also indicate the purpose of the factor (e.g., repeated or independent transmission). The AP may determine the transmission method for the STA in each allocated RU. For example, the AP may assign MCS, HARQ ID, RV, etc. The AP may allow the STA to determine the transmission method, such as MCS, HARQ ID, RV, etc.

[0135] Typically, a STA can be an associated STA (e.g., a STA associated with a network / AP / BSS) or an unassociated STA, and can randomly access the channel to reduce latency. The transmitting STA can randomly select Z RUs. If the purpose of the factor is independent transmission, each transmitting STA can create a HARQ ID for each selected RU, or if the purpose of the factor is repetition, each transmitting STA can use the same HARQ ID, where the STA can repeat the information content (i.e., information bits) or composite symbols (e.g., symbols in frequency) of the RU on Z RUs.

[0136] In some cases, the STA may use different RVs from RU to RU. For example, RUx and RUy may be assigned for repeated transmissions. The STA may use the same HARQ ID for the two RUs, but RUx may use RV0 and RUy may use RV1. The STA may use different MCSs for different RUs, which may be based on the multipath channel response on the RU in the downlink. The STA may use a different channel encoder structure for each RU and may set the rate differently. In the case where the PPDU lengths of different RUs are unequal, the shorter PPDU may be padded to maintain equal length. The UL PPDU length may be determined by the AP and may be carried in the trigger frame.

[0137] Typically, the AP can decode the content in the advertised RU(s). If the AP is able to decode the packet, it can send an ACK for each RU or a BA for all RUs. If the AP cannot decode the packet, it can send a NACK. The AP can indicate during the NACK transmission why it cannot decode the packet (e.g., collision, interference, and low SNR).

[0138] Figure 4 is a transmission diagram showing an example of parallel RV transmission of one or more STAs through OFDMA. In this example, different RVs of the same HARQ process may be sent concurrently for the same or multiple STAs.

[0139] At 401, AP 411 may send parallel RVs of one or more HARQ IDs to one or more STAs 412 (e.g., STA 1, STA 2, STA 3, etc.) via OFDMA. AP 411 may send RV0 of HARQ ID 1 to STA 1 on RU1, then send RV 1 of HARQ ID 1 to STA 1 on RU 2 (not shown), and this may continue until RV L of HARQ ID 1 is sent to STA 1 on another RU, where L is the number of RVs assuming that a new RV is sent in each RU. The RUs (one or more) selected for transmission may not be consecutive. Similarly, for STA 2, AP 411 may concurrently send RV0 of HARQ ID 1 to STA 2 on another RU. This method may also be repeated for each HARQ ID of a given STA (e.g., HARQ2, 3, etc.). This process may continue for all STAs 412. In this example, the last concurrent transmission may be HARQ ID K RV 2STA 2.

[0140] At 402, for example, after the HARQ response time has expired, the AP 411 may send a trigger frame to trigger a HARQ response from the STA 412. The trigger frame may identify RU resources for the STA 412 to send its response for one or more HARQ process IDs at 403. Alternatively, such a response 403 may be triggered by a response scheduling header carried in a HARQ transmission frame or other type of transmission.

[0141] At 404, the AP may send multiple RVs to multiple STAs, where the RV number is incremented based on the previously sent transmission (depending on whether the initial transmission was successful). For example, assuming that HARQ is unsuccessful for STA1 and HARQ ID 1, AP 411 may send HARQ ID 1 along with RV L+1 to STA1, where L is the last RV sent for HARQ ID 1 of STA 1. This may continue for STA 1, and in this example, it may continue until RV L+3. Similarly, the transmission may be unsuccessful for STA2 HARQ ID 1, so AP 411 may transmit an increased RV, such as RV 3. If the transmission is successful, the HARQ may be increased. For example, HARQ ID K may be successful, so AP 411 may send some HARQ ID K+2, which simply represents some other HARQ ID processes besides HARQ ID K, because HARQ ID K was successfully sent (e.g., this may be determined based on the STA2 response at 403).

[0142] At 405, one or more steps of the process may be repeated (eg, continuing HARQ transmissions, acknowledgments, etc.).

[0143] At 406, a multi-STA multi-HARQ ID BAR may trigger or solicit a HARQ response 407, where the RU may be identified for each tuple that may contain one or more of a HARQ process ID, a STA ID, or a TID.

[0144] One feature of EHT is multi-AP, where multiple APs are deployed in the same service set (e.g., BSS), such as in a home or work environment. The multiple APs can be coordinated and collaborated at certain levels to achieve higher peak throughput and improved efficiency. In order to achieve better BSS edge coverage, multiple APs can use HARQ operations with one or more STAs. To achieve this, an effective design of HARQ operations must be performed between one or more STAs and multiple APs.

[0145] Multi-AP HARQ transmission can enable more than one AP to send packets to one STA. The APs can send packets asynchronously. In other words, the multiple transmissions can be performed in a TDD manner and use different time slots to achieve the transmission of the packets to one STA.

[0146] The AP may include a multi-AP capability field / subfield or a multi-AP HARQ capability field / subfield in a beacon, a probe response frame, a (re)association response frame, and / or other control / management frames. The AP may also advertise a list of neighboring APs that can work together to perform multi-AP HARQ transmissions.

[0147] The STA may include a multi-AP capability field / subfield or a multi-AP HARQ capability field / subfield in its probe request frame, (re)association request frame, and / or other control / management frame. In this field / subfield, the STA may include its HARQ buffer capability / limit. The HARQ buffer capability / limit may include a buffer lifespan, which may give a suggestion of how long a damaged packet may be kept in the buffer. This may be a time value, such as microseconds (μs), milliseconds (ms), or seconds (s). There may be a list of valid buffer lifespan predefined / predetermined values. The STA may select one or more values ​​from the list, and the value index may be included and sent to the AP. The valid buffer lifespan may depend on the number of APs used to transmit asynchronously to the STA and the maximum number of transmissions expected from these APs. The HARQ buffer capability / limit may include a buffer size that may imply the maximum size that the HARQ buffer can handle. This may be a value in bits or bytes. There may be a list of predefined / predetermined values ​​for valid sizes. The effective maximum buffer size may depend on the type of HARQ retransmission, such as whether repetition or incremental redundancy is used. The STA may select one or more values ​​from the list, and the value index may be included and sent to the AP.

[0148] STA may include information about neighbor (unassociated) APs (including APs advertised by associated APs and other APs), such as AP identifiers, capability information, channel information, measurement information, context information, or other related information. For example, the information that the STA may include may be: SSID, BSSID, MAC address, other AP identifiers; channel number, operation class or PHY type; received channel power indicator (RCPI), channel width, channel center frequency segment 0, channel center frequency segment 1, beacon interval, clear channel assessment (CCA), received power indicator (RPI), channel load, noise histogram, beacon, frame, STA statistics, location configuration information (LCI) [latitude, longitude, altitude], transmission flow / class measurement, multicast diagnostics, location city (Civic), location identifier, directional channel quality, directional measurement, directional statistics, fine timing measurement range; and any other neighbor AP information. The STA may also include any additional type of information.

[0149] For a multi-AP HARQ configuration (wherein a master AP manages multiple HARQ processes), a STA may be associated with an AP, and the AP may become or has become a master AP, and may manage HARQ traffic to and from the associated STA. The master AP may provide the STA with a list of APs that may send and / or receive HARQ packets. The master AP may request the associated STA to measure characteristics of other APs. The master AP may receive the measured characteristics from the STA. The master AP may consider the measured characteristic information when managing HARQ APs. The master AP may inform the STA which APs it should monitor to receive multi-AP HARO packets.

[0150] For the HARQ packets sent to the STA, the master AP can generate HARQ redundant packets and provide them to the AP that the master AP has determined to send the packets. The master AP can provide the AP with the data to be sent and which HARQ redundant version should be used to create the expected HARQ packet for transmission. Based on this information, the AP can create the expected HARQ redundant packet that the master AP has determined that it should send. Once the AP has received or generated a HARQ packet, the master AP can request (trigger) the AP to send the packet by sending a trigger packet. The request can be sent in the air (e.g., wirelessly) through AP to AP signaling via a defined protocol. The request can be sent via a wired AP to AP network connection. The master AP can specify a transmission time to the AP, which can occur when the data or HARQ redundant packet is sent to the AP or at any time before the expected transmission time.

[0151] The STA may receive HARQ packets sent by the master AP and other APs, and may process the packets using a standard HARQ process until the packets are successfully received.

[0152] The STA may send HARQ packets to the master AP and / or other APs as directed by the master AP. The HARQ packets may be specifically addressed to an AP. The master AP and the other APs may attempt to receive packets sent by the STA that are not specifically addressed to them (e.g., the AP) but to any of them (e.g., any one of the APs that sent the packet, or any AP in the network). This may enable the HARQ packets sent by the STA to be detected by multiple APs. These detected packets may be forwarded to the master AP to be HARQ combined, or they may be combined independently at each AP or in any combination of APs.

[0153] For a multi-AP HARQ configuration (wherein a STA is associated with multiple APs controlled using a distributed HARQ process), a STA may be associated with multiple APs. The STA and the associated multiple APs may manage HARQ traffic to and from the associated STA. The STA may inform the multiple APs which APs it has associated with, and the multiple APs may coordinate with the STA and each other to determine which AP or APs may send HARQ packets, which redundancy version should be sent, and when the packets should be sent. The multiple APs may request the associated STAs to measure characteristics of other APs. The multiple APs may receive the measured characteristics from the STA. The multiple APs may consider the measured characteristic information when managing the HARQ process, or suggest that the STA associate with other APs.

[0154] For HARQ packets sent to STAs, the multiple APs may independently generate various agreed HARQ redundant packets assuming that the multiple APs are aware of the data to be sent, or the multiple APs may coordinate among themselves on how to generate the packets and which AP or APs should send the packets. The STA may provide feedback to the multiple APs. The multiple APs may use the feedback to coordinate how the packets may be sent. The multiple APs may coordinate wirelessly, via a wired network, or via any combination of the two.

[0155] The STA may receive the HARQ packets transmitted by the plurality of APs and may process the packets using a standard HARQ process until the packets are successfully received.

[0156] The STA may send HARQ packets to any of the multiple APs as indicated and agreed by the multiple APs and the STA. HARQ packets may be specifically addressed to an AP. Multiple APs may attempt to receive packets sent by the STA that are not addressed to them but to other APs participating in the process. This may enable detection of HARQ packets sent by the STA at multiple APs. These detected packets may be forwarded to one of the multiple APs to be HARQ combined, or they may be combined independently at each AP or in any agreed combination of APs.

[0157] For a multi-AP HARQ configuration with a virtual BSS and a master AP that manages the HARQ process, an AP (e.g., the master AP) may define a virtual BSS to which all APs that support the HARQ process of a STA may belong. A STA associated with an AP may request multi-AP HARQ support; the AP may become the master AP and may create a virtual BSS for a multi-AP that supports the multi-AP HARQ process that the STA will use. The master AP may request the associated STA to measure characteristics of other APs. The master AP may receive the measured characteristics from the STA. The master AP may consider the measured characteristic information when managing and creating a virtual BSS. Once the master AP has selected the APs that will support the virtual BSS and has coordinated with these APs on what the virtual BSS configuration is (e.g., SSID, MAC address, and all other BSS parameters), the master AP may inform the STA of the BSS parameters and the STA may associate with the BSS. The STA may maintain its association with the master AP for non-multi-AP HARQ traffic. The master AP may manage HARQ traffic to and from the STAs associated with the virtual BSS. The STAs may not need to know which APs constitute the virtual BSS, as all transmissions from these APs may appear as if they are from a single BSS. The master AP or the virtual BSS may inform the STA which APs it should provide measurement information about so that the master AP can manage the virtual BSS.

[0158] For the HARQ packets sent to the STA, the master AP can generate HARQ redundant packets and provide them to multiple APs that the master AP has determined to send the packets using a virtual BSS identifier. The master AP can provide the multiple APs with the data to be sent and which HARQ redundant version should be used to create the desired HARQ packets for transmission. Based on this information, the AP can create the desired HARQ redundant packets that the master AP has determined that it should send using the virtual BSS identifier. Once an AP has received or generated the HARQ packet, the master AP can request (trigger) the AP to send the packet by sending a trigger packet. The request can be sent over a wireless medium via a defined AP-to-AP protocol. The request can be sent via a wired AP-to-AP network connection. The master AP can specify a transmission time to the AP, which can occur when the data or HARQ redundant packet is sent to the AP or at any time before the desired transmission time.

[0159] The STA may receive HARQ packets sent by any of the plurality of APs using the virtual BSS identifier and process the packets using a standard HARQ process until the packet is successfully received. ACK and NACK packets may be sent to the virtual BSS and may be received by one or all APs in the virtual BSS.

[0160] The STA may send the HARQ packets to multiple APs in the virtual BSS by addressing the HARQ packets to the virtual BSS. All APs or any subset of APs in the virtual BSS may attempt to receive packets sent by the STA. This may enable all HARQ packets sent by the STA to be detected at multiple APs. These detected packets may be forwarded to the master AP for HARQ combining, or they may be combined independently at each AP in the virtual BSS, or at any combination of APs configured by the master AP.

[0161] For a multi-AP HARQ configuration with a STA that manages the HARQ process, the STA can be associated with multiple APs and can manage the multiple APs to provide multi-AP HARQ services. The STA can request one of the associated APs to be its primary AP. If the AP agrees to this role, the AP can become the primary AP, and as a distributed system (DS), the primary AP can route STA traffic to its destination, and the AP can coordinate with other APs requested by the STA to form a multi-AP group to support the STA's multi-AP service. The primary AP can assume a role similar to the "primary AP" described above, except that the STA can manage which APs are in the multi-AP group. The primary AP can notify the STA of the presence of other APs that the primary AP believes the STA should consider adding to the multi-AP group. The STA can provide a request to the primary AP about which APs should send which redundancy version of the HARQ packets and which order is preferred for sending the packets. The primary AP may generate various HARQ redundancy packets and provide them to multiple APs that it has determined to send them, or the primary AP may provide multiple APs in the multi-AP group with data to be sent and which HARQ redundancy version should be used to create the expected HARQ packet for transmission. Based on this information, the AP may create the expected HARQ redundancy packet that the primary AP has requested it to send. Once the AP has received or generated the HARQ packet, the primary AP may request (e.g., trigger) the AP to send the packet by sending a trigger packet. The trigger packet may be sent wirelessly via AP-to-AP signaling via a defined protocol. The trigger packet may be sent via a wired AP-to-AP network connection. The primary AP may specify a transmission time to the AP, which may occur when the data or HARQ redundancy packet is sent to the AP or at any time before the expected transmission time.

[0162] The STA may send HARQ packets to the multiple APs in the multi-AP group as desired. All APs or any subset of APs in the multi-AP group may attempt to receive any packet sent by the STA. The HARQ packet sent by the STA may be detected at multiple APs or only at the AP addressed by the STA. This configuration may be controlled by the configuration requested by the STA for the multi-AP group and may be requested by the primary AP. These detected packets may be forwarded to the primary AP for HARQ combining, or they may be independently combined at each AP in the multi-AP group, or combined at any combination of APs configured at the request of the STA and requested by the primary AP.

[0163] In general, during any multi-AP HARQ situation, there may be multiple features or actions related to a STA and multiple APs that may be applicable to scenarios related to downlink (DL) transmissions. In such a scenario, a STA may associate and / or negotiate with multiple APs (e.g., a first AP and a second AP), then one or more of the APs may send transmissions, the STA may or may not receive all transmissions, after which the HARQ process may resolve incomplete / complete reception of the data transmissions. The transmissions sent by the APs may include indications such as BSSID / Color, Access Point Identifier (AID), multi-AP HARQ transmissions, ACK policies, and / or HARQ related information.

[0164] The BSSID / color may be indicated in a field that may carry the BSSID or a compressed version of the BSSID or BSS color, which may be a locally unique ID for the BSS / AP. The AP may indicate the AID in a field. This field may be carried in the PLCP header so that the STA may know if it is the intended receiver of the packet.

[0165] The multi-AP HARQ transmission indication may be indicated in a field that the AP may use to explicitly or implicitly indicate that the transmission is a multi-AP HARQ transmission, which may allow the STA to combine received packets with different receive AIDs. The multi-AP HARQ field may be carried in the PLCP header. A specific value in the HARQ type field may be used to indicate that the upcoming transmission is a multi-AP HARQ transmission. A specific value in the HARQ process ID may be used to indicate that the upcoming transmission is a multi-AP HARQ transmission. Explicit or implicit multi-AP HARQ signaling may be carried in the PLCP header or the MAC header.

[0166] The AP may indicate the ACK policy in the PLCP header or MAC header. Different ACK policies may be generated by different AP / STA frame exchange processes. The ACK policy may be carried in the PLCP header or MAC header together with the multi-AP HARQ data packet. The ACK policy may be negotiated and determined before multi-AP HARQ data transmission.

[0167] In the example ACK policy, after each transmission, an immediate acknowledgement is sent along with ACK / NAK / NTX. Here, ACK / NAK are positive acknowledgement / negative acknowledgement, respectively. NTX is for no transmission, which may occur when the entire packet is lost, and the STA may not send an acknowledgement.

[0168] In an example ACK policy, an immediate ACK is sent after all configured transmissions. For example, two transmissions may be configured for a STA (eg, multi-APHARQ transmissions). The STA may send an acknowledgment when the first AP and the second AP complete their transmissions to the STA.

[0169] In an example ACK strategy, a delayed ACK may be sent. In this case, the ACK may be sent in a delayed version. A single HARQ process may be sent repeatedly before a delayed ACK is received. More than one HARQ process may be supported and sent before a delayed ACK is received.

[0170] In an example ACK policy, a triggered / polled ACK may be sent. When this is set, the transmission of the ACK may need to be triggered or polled by the peer STA using a control / management frame.

[0171] In the example ACK policy, multiple AP ACKs may be sent. When this field is set, the STA can send multiple AP ACKs back to the multiple APs. When this field is not set, the STA may send to a single AP at a time. In the case where STA transmission is not omnidirectional, a single ACK returned to the primary AP may be advantageous. In the case where multiple APs may request the ACK, multiple ACK frames may be sent sequentially or using an inter-frame space (xIFS).

[0172] In an example ACK policy, a value may be sent that indicates that there is no acknowledgment between AP repetitive transmissions. In this case, the AP may also send to the STA the number of APs that may perform multi-AP HARQ transmissions. The AP may signal the number of APs that may transmit after this transmission and before an acknowledgment is expected. The AP may signal the total number of APs that may transmit in a multi-AP HARQ transmission. The AP(s) may signal, for example, the number of total AP transmissions and the number of remaining AP transmissions before an acknowledgment.

[0173] The first AP may indicate HARQ related information, such as a HARQ process identifier (ID), a redundancy version (RV), a modulation and coding scheme (MCS), and a retransmission indication.

[0174] Based on the transmission, the STA may make one or more determinations, and / or take one or more actions. After receiving the packet, the STA may check the AID and BSSID / color field indication / information (e.g., in the PLCP header sent and received with the packet) and compare it with the AID assigned to the STA in the corresponding BSS (e.g., configured during association / negotiation). If the AID matches, the STA may assume that it is the intended receiver of the packet. The STA may continue to check other indications / information (e.g., PLCP header) and may determine that the transmission is for multi-AP HARQ. The STA may determine that this is a new transmission or retransmission for multi-AP HARQ. The STA may know the maximum number of transmissions expected from the corresponding AP during the negotiation phase. The STA may save a transmission ID or HARQ process ID, which may be used to identify transmissions of the same packet. The STA may determine and save the RV of the transmission, which may be used with a previously received transmission with the same transmission ID.

[0175] Once the packet is received, the STA can decode the packet. If the packet is successfully decoded, the STA can transmit an acknowledgment based on the ACK policy, as discussed herein. The STA can send a multi-AP acknowledgment back to both the first AP and the second AP, or only to the master / primary AP (e.g., the first AP). If the packet is not successfully decoded, the STA can start a HARQ timer. The STA can store the damaged packet in its buffer. Based on the ACK policy, the STA can determine whether it can send a NAK. In some cases, the STA may not send anything back, or if the entire packet is lost, the STA may send an NTX.

[0176] After the initial signal from the first AP is sent along with the packet, there may be a time period for response. The second AP may not receive any positive acknowledgment from the STA during this time period and may start its multi-AP HARQ retransmission. This waiting period for the second AP may be predefined or predetermined and known to all parties. The period may be sufficient to cover the ACK transmission and the short frame interval (SIFS) duration plus the distributed coordination function (DCF) interframe space (DIFS) duration. For example, the second AP may need to wait for the extended interframe space (EIFS) duration to prepare for the retransmission. The second AP may carry the same set of control signaling as the first AP, or the second AP may carry a subset of the control signaling carried by the first AP. The second AP may assign its BSSID / color and AID to the STA, which may be different from that carried by the first AP.

[0177] Upon receiving the packet sent by the second AP, the STA may check the AID and BSSID / color fields in the PLCP header and compare them with its assigned AID in the corresponding BSS. If the AID matches, the STA may consider it to be the intended receiver of the packet. The STA may continue to check the PLCP header. The STA may determine that the transmission is for multi-AP HARQ. The STA may determine that this is a retransmission for multi-AP HARQ. The STA may check the corresponding HARQ timer. If the timer expires, the STA may treat the transmission as a new transmission. If the timer does not expire, the STA may combine the received packet with the packet stored in its buffer. More than one HARQ process may be allowed. The STA may check its buffer and select a packet with the correct AID and HARQ process ID to combine. The STA may have different AIDs associated with different APs. The STA may know the relationship between the AID and the corresponding AP. The STA may have different HARQ process IDs in different APs. The STA may know the HARQ process ID and the corresponding AP during the negotiation phase. The STA may consider the RV of a transmission when combining it with transmissions stored in its buffer.The STA may know the maximum number of transmissions expected from the corresponding AP during the negotiation phase.

[0178] Figure 5Flowchart showing an example of a multi-AP HARQ downlink process from the perspective of a STA. For the purposes of this example, it may be assumed that any general multi-HARQ scenario features / actions described herein may apply even if not explicitly stated. As a result of negotiation between the STA and two APs for a multi-HARQ scenario, as described herein, at 501, the STA may monitor a channel. At 502, the STA may receive a packet in a signal from one of the associated APs (e.g., a first AP) on the monitored channel. The STA may determine that the AP AID matches the configured (e.g., during association / negotiation). At 503, the STA may determine that the signal is a multi-HARQ signal (e.g., based on a PLCP header). At 504, the STA may determine that the signal is a new transmission (e.g., not a retransmission). If the signal is a new transmission, then at 505, the STA determines whether the packet can be successfully decoded. If the packet can be successfully decoded, then at 506, the STA may generate an ACK and send or broadcast the ACK to the associated AP(s). If the STA determines at 505 that the packet cannot be successfully decoded, then the STA starts a timer at 508. Then, at 510, the STA saves the packet in a buffer and then returns to the beginning of the process 501 to wait for retransmission. In some cases, if the packet can be partially decoded (e.g., still unsuccessful), the STA may send a NACK and return to the beginning of the process 501 to wait for retransmission (not shown). At 504, if the STA determines that the received multiple HARQ signal is not a new transmission (e.g., a retransmission), the STA determines at 507 whether the timer has expired. If the timer has expired, the STA starts the timer at 508 and continues from there as described above. If the timer has not expired, at 509, the STA may combine the received packet with the packet stored in the buffer. Then, at 511, the STA determines whether the packet has been successfully decoded (e.g., the STA has decoded the entire packet). If the STA has successfully decoded the packet, at 512, the STA stops the timer and then continues to broadcast an ACK to the associated AP at 506. If, at 511, the packet has not been successfully decoded, the STA saves the packet in a buffer at 510 and continues the process from there. Note that the determination at 511 as to whether to decode the packet is only for retransmissions.

[0179] Figure 65 is a transmission diagram showing an example of multi-AP HARQ downlink transmission. It can be assumed that for this example, any of the general or example multi-HARQ scenario features / actions described herein can be applied even if not explicitly stated. STA 503 can be associated with more than one AP (e.g., AP601 and AP602). AP601, AP602, and STA603 can negotiate to perform downlink (DL) multi-AP HARQ transmission (e.g., processes 511-515). As a result of the negotiation, STA603 may have been indicated / notified that AP601 has AID1 and AP602 has AID2. AP601 can be the main / primary / master AP of STA603, and AP602 can be the secondary / servant AP of STA603. In this example, the ACK policy can be not responding if a packet is not received or if a packet is received but not fully decoded.

[0180] After the association, AP601, AP602, and STA603 may negotiate to perform multi-AP HARQ transmission (e.g., PPDU transmission from AP601 and AP602 to STA603). The negotiation may occur at any time before the initial multi-AP HARQ transmission, where the initial multi-AP HARQ transmission occurs at 611, when AP601 sends a multi-AP HARQ packet to STA603 (e.g., sends a PPDU with AID1), which may include information / indications as disclosed herein (e.g., BSSID / color, access point identifier (AID), multi-AP HARQ transmission, ACK policy, HARQ related information, etc.). In this example, at 612, STA603 may not receive the packet (e.g., decoding failure), and therefore will not send an acknowledgment after the packet transmission.

[0181] After a certain time period 613, AP602 may not receive any acknowledgment from STA603 and may start its multi-AP HARQ retransmission at 614. The waiting period of AP602 may be predefined or predetermined. The period may be sufficient to cover the ACK transmission and the short frame interval (SIFS) duration plus the distributed coordination function (DCF) interframe space (DIFS) duration. For example, AP602 may need to wait for an extended interframe space (EIFS) duration to prepare for the retransmission, as shown at 613. AP602 may provide the same set of control signaling as AP601, or AP602 may carry a subset of the control signaling provided by AP601. AP602 may provide its BSSID / color and AID (e.g., AID2) to STA603, which may be different from that provided by AP501.

[0182] STA 603 may successfully decode the retransmission sent from AP 602. Based on the preconfigured ACK policy, STA 603 may prepare to acknowledge the transmission. At 615, STA 603 may send a multi-AP ACK back to AP 601 and AP 602 for a duration of one xIFS from the end of the packet.

[0183] Figure 7 is a transmission diagram showing an example of multi-AP HARQ downlink transmission. As can be seen, Figure 7 is a schematic diagram showing an example of a multi-AP HARQ transmission process with explicit NAK transmission, and Figure 6 is an example of a multi-AP HARQ transmission process without explicit NAK transmission. It can be assumed that, in order Figure 7 For purposes of the examples shown in , any of the general or example multi-HARQ scenario features / actions described herein may apply even if not explicitly stated. Similar to the general process described herein for the multi-HARQ scenario, AP701, AP702, and STA703 may negotiate multi-HARQ transmissions. AP701 may have AID1 and AP702 may have AID2. In this example, the ACK policy may be set to a value indicating that ACK / NAK / NTX is acknowledged immediately after each transmission. Here, ACK / NAK may be positive / negative acknowledgement, respectively.

[0184] At 711, AP701 may send a packet (e.g., PPDU) with AID1 to STA703. At 712, if the packet is not successfully decoded, STA703 may start a HARQ timer. STA703 may save the damaged packet in its buffer. STA703 may know the maximum number of transmissions expected from the corresponding AP during the negotiation phase. Depending on the ACK policy, at 713, STA703 may send a NAK to AP701 and / or AP702. STA703 may send a control / management frame to AP701 and / or AP702. Alternatively, STA703 may send a frame to AP702 to trigger a retransmission. In the control / management frame, STA703 may indicate preferred or recommended HARQ retransmission parameters. AP702 may receive the NAK from STA703, which may trigger its multi-AP HARQ retransmission at 714, where AP702 sends a packet (e.g., a retransmission) with AID2. AP 702 may carry the same set of control signaling as AP 701, or AP 702 may carry a subset of the control signaling carried by AP 701. AP 702 may assign its BSSID / color and AID to STA 703, which may be different from that carried by AP 701. At 715, after the STA successfully decodes the retransmitted packet of 714, STA 703 may prepare an acknowledgment transmission based on the ACK policy, and then STA 703 may send a multi-AP ACK back to AP 701 and AP 702 within a xIFS duration from the end of the packet.

[0185] Figure 8 803 is a transmission diagram showing an example of a multi-AP HARQ downlink transmission. In this example, there may be repeated transmissions so that for the ACK policy, there is no need to wait for a period (e.g., EIFS) or confirmation (e.g., ACK / NACK). It can be assumed that for this example, any of the general or example multi-HARQ scenario features / actions described herein may apply even if not explicitly stated. AP801, AP802, and STA803 may negotiate to enable multi-AP HARQ transmission, which may occur at any time before multi-AP HARQ transmission 811. During the negotiation, an ACK policy may be indicated. The ACK policy may be set to a value indicating that there is no confirmation between repeated AP transmissions. The STA803 may receive an indication of one or more of the following: the number of APs that may perform multi-AP HARQ transmissions; the number of APs that may transmit after the transmission and before the expected confirmation; the total number of APs that may transmit in the multi-AP HARQ transmission; and / or the number of total AP transmissions and the number of remaining AP transmissions before confirmation.

[0186] At 811, AP801 may send a multi-AP HARQ packet to STA803. At 812, STA803 may note that there is an indication that no ACK is required between multi-AP HARQ transmissions. If decoding fails, STA803 may continue with the process disclosed herein for reception / decoding failure. If reception is successful (e.g., STA803 is able to successfully decode the MAC body), STA803 may ignore any future repeated transmissions. At 813, AP802 may start multi-AP HARQ retransmissions after sending from AP801 without waiting for a period of time or confirmation.

[0187] Once all transmissions are sent, STA 803 may prepare an acknowledgment transmission at 814. STA 803 may send a multi-AP ACK back to AP 801 and AP 802 starting within a xIFS duration from the end of the packet (eg, during the broadcast ACK frame).

[0188] Figure 8 The example can be extended to the case where there are repeated transmissions for each AP. For example, AP801 can send a packet more than once (e.g., twice), and AP802 can send a packet more than once (e.g., twice), and then STA803 can send back an acknowledgment after all repetitions are completed.

[0189] As discussed herein, the physical resource allocation for each transmission in the HARQ process may be different to achieve frequency diversity. For example, a first transmission may use RU set 1, while a second transmission may use RU set 2. RU set 1 and RU set 2 may completely overlap or may not completely overlap or may partially overlap. Even though RU set 1 may overlap RU set 2, the mapping of modulated symbols to physical resources may be different for each transmission.

[0190] exist Figure 6 , 7 In the examples shown in FIG. 8 , for simplicity of explanation, there are two APs transmitting to one STA, however, these examples can be extended to the case where more than two APs transmit to one STA. In addition, these examples of multi-AP HARQ processes can be used in multi-band HARQ situations.

[0191] In general, during any multi-AP HARQ situation, there may be multiple features or actions related to STA and multiple APs, which may be applicable to scenarios related to uplink (UL) transmissions. In such a scenario, the STA may receive a trigger from one or more APs (e.g., a first AP and a second AP). The first AP may be a primary / master AP, and the second AP may be a secondary / slave AP. The STA may then send a HARQ transmission to the two APs using one resource for the two APs or using different resources for each AP. The STA may then receive an acknowledgment from one or both APs.

[0192] Initially, the STA may need to determine resources for uplink multi-AP HARQ transmission. In one case, the STA may be allocated common resources about the two APs (e.g., allocated in a trigger) and a single HARQ RV may be sent to the two APs simultaneously. In order to perform joint uplink HARQ combining, the AP may decode the packet using a combination of both append combining and IR combining. The information of the packets sent from the STA at a specific time collected by the two APs may be append combined together. Additional RV versions of packets sent at other times may be IR combined with the originally received packets.

[0193] In another case, the STA may be allocated different resources for each AP. The resources may be separated by frequency (eg, RU) or time. In this case, the AP may IR combine information from different resources of different APs.

[0194] In the case where the AP is directed, the STA may be allocated one resource for the two APs, or different resources for each AP. In one example, a single master trigger frame (from the master AP) may assign the STA resources for the two APs. The STA may read the master trigger and send information to the multiple APs based on the HARQ ID, RV, transmit power, and resources for the two APs. In another example, separate trigger frames may be sent independently by each AP.

[0195] In the case of an autonomous STA, the STA can independently acquire HARQ transmission resources for the necessary AP(s) and send to the desired AP(s). This can be achieved through EDCA or by responding to a UL OFDMA random access (UORA) trigger frame. The STA packet may indicate the address of the desired AP(s).

[0196] Once the resources for the STA have been determined, the STA may send a transmission with packets, and the multiple APs may receive the transmissions on the allocated resources and process them independently or jointly.

[0197] In an example, the backhaul may be used to implement HARQ combining of information arriving at different APs (eg, joint uplink HARQ combining).

[0198] In one example, each AP may independently decode the information, performing local HARQ combining (e.g., separate uplink HARQ combining). In this example, communication between APs may be limited to whether there is a successful decoding and how the success or failure of the decoding process will be sent to the STA.

[0199] Once the transmission is processed, the AP(s) needs to send a multi-AP HARQ response to the STA. ACK / NAK responses may be sent independently from each AP, or may be sent by a designated master AP.

[0200] In the event that the AP response may need increased reliability, the two APs may send the response independently. This may be sent on the same resources (e.g., to provide additional diversity, such as multi-AP shift diversity, where the diversity comes from different channels to the STAs, or from one AP intentionally delaying the transmission of its ACK to provide more channel variation due to increased frequency selectivity of the channel) or on different resources.

[0201] In the scenario where the primary AP performs the HARQ combining, the primary AP may send the ACK / NAK. Alternatively, the primary AP may perform the decoding and send the feedback status to the secondary AP. Each AP may then opportunistically send the response to the STA.

[0202] In general, any features or actions described herein for the multiple HARQ downlink scenario may be applied in the opposite manner to the uplink case, even if not explicitly recited in the examples.

[0203] Fig. 9Flowchart showing an example of a multi-AP HARQ uplink process from the perspective of a STA. For the purposes of this example, it may be assumed that any general multi-HARQ scenario features / actions described herein may apply even if not explicitly stated. Initially, a STA may be associated with multiple APs and negotiate with these APs for a multi-HARQ configuration. At 901, the STA may monitor a channel (e.g., as a result of the negotiation). In one option, at 902a, the STA may receive an uplink HARQ trigger from one of the associated APs and determine an AID match. In another option, at 902b, the STA may receive a UORA trigger from the primary AP. In either case, at 903, the STA may be indicated UL uplink multi-AP HARQ resources by the trigger. At 904, the STA may send an uplink multi-AP HARQ transmission (e.g., including HARQ ID, RV, etc.) on the indicated resources. At 905, the STA may listen for multi-AP acknowledgments from the AP(s).

[0204] In some cases, acknowledgment frames may be sent from a STA to multiple APs. Fig. 9 In the example of , the multi-AP confirmation may include a confirmation for one HARQ transmission, but the confirmation may need to be delivered to more than one AP. Therefore, one or more or all of the following information may be required in the confirmation frame: confirmation type, such as multi-AP HARQ ACK; one or more AP IDs for indicating the AP; HARQ ID; and / or the confirmation.

[0205] Fig.101 is a transmission diagram showing an example of a multi-AP HARQ uplink transmission. For the purpose of this example, it can be assumed that any general multi-HARQ scenario features / actions described herein can be applied even if not explicitly stated. There can be AP1001, AP1002, and STA1003, which negotiate to perform multi-AP HARQ uplink transmission. At 1011, AP1001 (e.g., the primary AP) can send a single master trigger frame for UL multi-AP HARQ transmission, which assigns resources for all APs (e.g., AP1001 and AP1002) to STA1003. The trigger can indicate information related to HARQ ID, RV, transmit power, and resources for the two APs. STA1002 can send packets to the multiple APs based on the trigger (e.g., with a single RV). In some cases, each AP can independently send a separate trigger frame (not shown). At 1013, the AP can receive the packet on a common resource. In some cases, the multiple APs can independently decode the packet (not shown). In another case, the multiple APs may use a backhaul / controller for HARQ combining, wherein the multiple APs may decode the packets using a combination of append and IR combining. Information from the two APs about packets sent at a particular time may be append combined together. At 1014 and 1015, each AP may independently send an acknowledgment (e.g., an ACK using shift diversity).

[0206] Fig.11 1 is a transmission diagram illustrating an example of a multi-AP HARQ uplink transmission. For the purposes of this example, it may be assumed that any general multi-HARQ scenario features / actions described herein may apply even if not explicitly stated. There may be AP1 101, AP1 102, and STA1103 that negotiate to perform multi-AP HARQ uplink transmission. At 1111, AP1101 (e.g., the primary AP) may send a single master trigger frame for UL multi-AP HARQ transmission that assigns resources for all APs (e.g., AP1101 and AP1102) to STA1103. The trigger may indicate information related to HARQ ID, RV, transmit power, and resources for the two APs. At 1112 and 1113, the STA1103 may transmit one to each AP using different resources. The resources may be separated by frequency (e.g., RU) or time. At 1114, AP1 101 and AP1102 may IR combine information from different resources for different APs, as described herein. At 1115, an ACK / NAK response may be sent from AP 1101 (eg, the primary / master AP) based on all AP information.

[0207] Fig.12 is a SIG-B diagram showing an example of multi-AP HARQ acknowledgment. In general, a multi-STA BA (e.g., as defined in 802.11ax) can be modified to implement multi-AP acknowledgment. In this way, each AP can have its own acknowledgment portion. For example, Fig.12 As shown, one or more fields may be used. One field may be a BA type field 1212, where the BA type may be used to indicate a multi-AP HARQ acknowledgment. Another field may be a BSSID11 field 1251, which may be defined in the AID TID information field. The BSSID11 may be used to indicate the AP ID. Another field may be a HARQ ID field 1242, which may be defined in each per-AID TID information field. The HARQ ID may be different from AP to AP, however, the multiple APs may use the HARQ ID and BSSID11 together to identify the acknowledged packet; this field may be optional in the case where only one HARQ ID is used.

[0208] In some cases, a wired backhaul may not be available, and thus a wireless backhaul may need to be utilized. In the case of multi-AP HARQ with wireless backhaul, the multiple APs may share data payloads between each other prior to one or more multi-AP transmissions (e.g., inter-AP communications). Such communication between the multiple APs may be considered overhead unless it is reused by one or more STAs. The one or more STAs are able to receive signals on the channel used for inter-AP communications.

[0209] For this wireless backhaul scenario, there may be two communication phases: a backhaul transmission phase, in which one AP shares the STA's payload with one or more APs; and a multi-AP transmission phase, in which one or more APs may coordinate to transmit to the STA. In order to allow data payload sharing between APs to be reused at the STA side, the data payload sharing (e.g., backhaul transmission phase) may use one or more algorithms: single STA data sharing; and / or multi-STA data sharing.

[0210] For single STA data sharing, an AP can pack data destined for a STA in a packet and share the data with one or more APs. The packet can be sent in an aggregated PPDU format so that each PPDU is individually encoded and can be independently sent to the STA later. The packet can have a special SIG field that can contain one or more information fields.

[0211] One information field may be a backhaul transmission indication, where the field may indicate that the transmission is a backhaul transmission between APs to share data payload for STAs.

[0212] The one or more information fields may be a source AP ID, a destination AP ID, and an expected STA ID. The source / destination AP ID may indicate the transmitter and receiver IDs. The expected STA ID may indicate that the data carried in the PPDU may belong to the STA. The ID may be a MAC address, BSSID, AID, or other type of compressed or uncompressed ID.

[0213] One or more information fields may be multi-AP HARQ related information, such as HARQ process ID, new transmission indication, etc. In some instances, the same HARQ process ID may be used for the same packet sent in the backhaul transmission phase and the multi-AP transmission phase of the STA, so that the STA can determine whether it can perform HARQ combining on the receiver side when it receives the packet in the multi-AP transmission phase.

[0214] Fig.13 is a packet diagram showing an example of an A-PPDU format sent for multiple STAs on the backhaul. For multi-STA data sharing, an AP may package data intended for one or more STAs in a packet and share the data with one or more APs. The packet may be sent in an aggregated PPDU format so that each PPDU is individually encoded and may be independently sent to the STA later. For example, the packet may contain 2 PPDUs to STA1301 and 3 PPDUs to STA1302. In one example, the SIG field may be STA-specific and inserted before the PPDU belonging to the STA, such as Fig.13 As shown, in another example, the SIG field may be PPDU specific and inserted before each PPDU (not shown). The SIG field may include one or more information fields.

[0215] One information field may be a backhaul transmission indication, where the field may indicate that the transmission is a backhaul transmission between APs to share data payload for STAs. Alternatively, the field may be carried in a common SIG field in the PLCP header.

[0216] The one or more information fields may be a source AP ID, a destination AP ID, and an expected STA ID. The source / destination AP ID may indicate the transmitter and receiver IDs. The expected STA ID may indicate that the data carried in the PPDU may belong to the STA. The ID may be a MAC address, BSSID, AID, or other type of compressed or uncompressed ID.

[0217] One or more information fields may be multi-AP HARQ related information, such as HARQ process ID, new transmission indication, etc. In some instances, the same HARQ process ID may be used for the same packet sent in the backhaul transmission phase and the multi-AP transmission phase of the STA, so that the STA can determine whether it can perform HARQ combining on the receiver side when it receives the packet in the multi-AP transmission phase.

[0218] One information field may be a Next SIG field, which may be used to indicate the location of the next SIG field in the A-PPDU.

[0219] For the wireless backhaul scenario, the STA may be allowed to send an acknowledgment during or after the backhaul transmission to indicate that it has detected a PPDU for it. The acknowledgment transmission from the STA may be after the xIFS time after the last acknowledgment between the APs. Alternatively, the acknowledgment transmission from the STA may be based on polling. For example, an AP may send a polling frame to one or more STAs before a multi-AP transmission, and if the acknowledgment from the STA can be successfully received by one of the multiple APs, the multi-AP transmission phase may not be required.

[0220] For the case where the STA can send an acknowledgment in the backhaul channel(s), the STA can initially monitor the backhaul channel(s). If the STA successfully detects the SIG field in the received packet, the STA can check whether it is a backhaul transmission and whether the STA ID matches its own ID. If both checks pass, the STA can attempt to decode the subsequent PPDU(s). If the STA successfully decodes the PPDU(s), the STA can confirm to the multiple APs. If the STA does not successfully decode the PPDU(s), the STA can save the received signal in a buffer and continue to monitor its working channel. Thereafter, if the STA detects that the transmission to it has the same HARQ ID, the STA can combine and decode the received signal with the signal stored in the buffer. The STA may also perform any other steps as described herein.

[0221] Fig.14A is a flow chart illustrating an example transmission process using a unique SIG-B field for each HARQ process. Fig. 14B is a diagram illustrating example different levels / layers of a transmission scenario using a unique SIG-B field for each HARQ process. Fig.14A The description can be applied to Fig. 14B , and the examples shown in these two figures can be referred to as Fig.14A and Fig. 14B Example. There may be a HARQ-based PPDU transmission where each STA has Mp HARQ processes, and the transmission may contain information that may include a PLCP service data unit (PSDU) (e.g., the MPDU observed from the physical layer), service field bits, and padding bits. The information may be divided into M≤Mp segments, and each segment may be transmitted together with a unique SIG-B field associated with the corresponding PHY subframe and one or more independent codewords (CWs). For example, a PSDU may include K A-MPDU subframes and an end of frame (EOF) (e.g., see Fig. 14B The following may then be applied to transmit the PSDU to enable segment-based HARQ transmission with multiple SIG-B fields (e.g., Fig. 14B 1422PHY layer, 1423 bit level and 1423 signal level in). This process can be performed by a STA or an AP.

[0222] At 1401, the PSDU and service field bits may be concatenated and filled with N pad_PSDU bits, which can produce N as the information bits to be sent bits The bits in the information content may be scrambled using a scrambler or may be interleaved using an interleaver.

[0223] In 1402, N bits The information bits can be divided into segments, where each segment consists of N segment In some cases, distributed segmentation may be performed, where the information bits are grouped into M segments and padding is applied to each segment (e.g., Fig. 14B Distributed Segmentation at 1425). For example, the number of padding bits can be evenly distributed among the segments so that each segment has N pad_PSDU As an alternative, the padding bits may first be grouped into a number of bytes, and the number of bytes may be evenly distributed in the segments except the last segment. The segments may be a function of the LDPC codeword size.

[0224] Based on the previously failed segments and the newly available segments, the segments may be assigned to different HARQ processes at 1403. Each HARQ process may send the same segment until the transmission is complete and until all redundant versions of the same segment may have been sent.

[0225] At 1404, the original data of each HARQ process may be filled with N pad_preFEC bits, and may be appended with N phyCRC CRC bits, which generates N block =Nsegment +N pad_preFEC +N phyCRC The bits in each block may be scrambled by a scrambler. The bits in each block may be interleaved by an interleaver.

[0226] At 1405, each block may be divided into M message messages, each of which can contain N message Bit.

[0227] At 1406, an encoder such as an LPDC encoder or a BCC encoder may be used to generate a code rate of To encode each message, this can generate a length N cw bit codeword. message codewords to generate a coding block, where the size of the coding block can be N encodedBlock =M message N cw .

[0228] At 1407, N pad_postFEC The zero-filled coding blocks are used to generate the corresponding PHY subframes at the bit level, which results in a bit-level length of N for each PHY subframe. PHYsubframe =N encodedBlock +N pad_postFEC Bit.

[0229] At 1408, N cw Coded bits or N encodedBlock Bit or N PHYsubframe The bits are interleaved at the bit level.

[0230] For the mth PHY subframe, a unique SIG-B field may be prepared with the following contents: Segmentation indicator a new segment indicator (1 bit), which may indicate whether the content of the following PHY subframe is new (e.g., if it is 0, it is the same segment (e.g., Fig. 14B a redundancy version index, which may indicate a redundancy version of the segment (e.g., if it is 3, a third redundancy version of the indicated segment is sent in a subsequent PHY subframe); the number of pre-FEC padding bits that may be used in a subsequent PHY subframe Number of post-FEC padding bits that can be used in the following PHY subframe The number of PSDU padding bits that can be used in the following PHY subframe Modulation coding index that can be used in subsequent PHY subframes; segment length, which can indicate the size of information bits that can be used before encoding, where the size can be in bytes, and this field can indicate the size of the original block and FEC pre-padding bits, and / or this field can indicate the size of the original block.

[0231] At 1409, the bits in each PHY subframe may be mapped to modulation symbols, which may result in N modsymbol =N PHYsubffame / log2S, where modulation S may be the modulation order (eg, for 64-QAM, S=6).

[0232] The symbol-level interleaver can be applied to N modSymbol As an alternative, the symbol-level interleaver can be applied to each OFDM symbol.

[0233] At 1410, the modulation symbols may then be mapped to time and frequency resources in an OFDM symbol along with reference symbols, and the resulting OFDM symbols may generate a corresponding PHY subframe in a signal level.

[0234] At 1411, a corresponding SIG-B field of the mth PHY subframe may be converted into a signal by using OFDM transmission.

[0235] The mth SIG-B field associated with the mth PHY subframe may be transmitted back-to-back.

[0236] In one case, N can be chosen uniformly for each block pad_preFEC , which can simplify the receiver design. In another case, except for the last transmitted block, N pad_preFEC Set to 0 to reduce overhead. For example, bits can be evenly distributed to cells (pre-FEC padding in each cell) or evenly distributed to byte level in each cell, and the last cell may need pre-FEC padding.

[0237] The EHT-MARK field may also contain signature information related to the HARQ PPDU. It may be a rotated version of the RL-SIG. For example, the EHT-MARK may be 1i*RL-SIG.

[0238] The segmentation calculation can be based on the codeword length. For example, for LPDC, various parity check matrices with different sizes can be considered, which may produce different codeword lengths. To solve this problem, the N bits The information bits can be divided into M = N CW，totalAfter CRC addition, each group can be encoded into multiple codewords (i.e., blocks). CW，total It can be determined based on the size of the selected parity check matrix.

[0239] Fig.15 1 is a schematic diagram of a packet diagram showing an example, in which a single SIG-B indicates HARQ information related to all PHY subframes. In order to reduce the PPDU duration, the SIG-B field may include multiple OFDM symbols, and the multiple OFDM symbols may include information related to multiple PHY subframes. For this one PPDU, EHT-SIG-B 11508 may provide information of PHY subframe 11509, PHY subframe 21510, etc., until the Mth PHY subframe 1516.

[0240] Fig.16 1608 is a schematic diagram showing an example of a packet, in which a single SIG-B indicates HARQ information related to a PHY subframe group. Here, for a PPDU, a single SIG-B 1608 may indicate M information related to the information. r PHY subframes, and the subsequent PHY subframes are indicated by another SIG-B 1613 together with the LTF.

[0241] In some cases, in order to enhance the channel estimation performance of long packets with HARQ retransmissions, the Mth r Retransmit the LTF after M PHY subframes. r =4, then the LTF may be retransmitted between the fourth PHY subframe and the fifth PHY subframe.

[0242] In one method, there may be a segmented transmission with a single HARQ process ID. A PPDU transmission may have a single HARQ process ID and up to M max PHY subframes, where M max It can be predefined / predetermined. Alternatively, the value can be dynamically determined by the AP and signaled in a management / control frame such as a beacon frame, or a trigger frame. For each STA, the information content including the PSDU, service field bits, and padding bits can be divided into M≤M maxThe HARQ process ID may be used for all segments that may be generated by one PSDU, and each segment may have its own segment ID. It is possible that in one transmission or A-PPDU, PHY subframes may have different HARQ process IDs. For example, some PHY subframes may be used for retransmissions with HARQ process ID x, and some PHY subframes may be used for new transmissions with HARQ process ID y. The segment ID and the HARQ process ID together may uniquely identify the PHY subframe / segment.

[0243] This process can be compared with Fig.14A Same as discussed, however, the signaling part may be modified. In the case where the SIG-B field may be carried before each PHY subframe, for the mth PHY subframe, the SIG-B field may be prepared with a HARQ process ID, which may indicate the HARQ process ID of the PHY subframe. The SIG-B field may be prepared with a segment ID, which may indicate what segment is carried on the subsequent PHY subframe, wherein the field may have Bit or The SIG-B field may be prepared with a segment indicator (1 bit) which may indicate whether the content of the subsequent PHY subframe is a new transmission (e.g., if it is 0, it may be the same segment (e.g., Fig. 14B The SIG-B field may be prepared with a redundancy version index that may indicate a redundancy version of the segment (e.g., if it is 3, a third redundancy version of the indicated segment may be sent in a subsequent PHY subframe). The SIG-B field may be filled with the number of pre-FEC padding bits used in a subsequent PHY subframe. The SIG-B field can be filled with the number of FEC bits used in the subsequent PHY subframe. The SIG-B field can be filled with the number of bits of the PSDU used in the subsequent PHY subframe. The SIG-B field may be prepared with a modulation coding index used in a subsequent PHY subframe. The SIG-B field may be prepared with a segment length, which may indicate the size of information bits before encoding, wherein the size may be in bytes, and the field may indicate the size of the original block and the FEC front padding bits, and / or the field may indicate the size of the original block.

[0244] Fig.171721 is a SIG-B schematic diagram showing an example of a frame format for a basic codeword (CW) / CW group (CWG) based acknowledgement. Typically, a basic CW / CWG based acknowledgement can be used to carry a CW / CWG based acknowledgement for a packet with a packet ID 1721. The packet ID can be a HARQ transmission ID, a sequence number, a MAC protocol data unit (MPDU) ID, or a PPDUID. The packet ID 1721 can be used to uniquely identify a packet within a time period. The packet ID can be carried in a PLCP header, and the content of the packet can be carried in a data field. The packet can consist of one or more codewords. The maximum number of CW / CWs can be predetermined, predetermined, or configured.

[0245] The value in the BA type field 1712 may indicate a basic CW / CWG based acknowledgement. By detecting this field, the receiver may expect the BA information field 1706 to contain fields such as the packet ID field 1721 and the CW / CWG bitmap field 1722.

[0246] The packet ID field 1721 may be used to carry the ID of the confirmed packet. The packet ID may be a HARQ transmission ID, a sequence number, an MPDU ID, or a PPDU ID. The packet ID may be used to uniquely identify a packet within a time period.

[0247] The CW / CWG bitmap field 1722 may carry a CW or CWG confirmation for the packet. The size of the bitmap may be determined by the maximum number of CWs / CWGs allowed for the packet. The maximum number of CWs / CWGs per packet may be predetermined, predefined, or configured. In one case, the maximum number of CWs / CWGs per packet may be related to a traffic identifier (TID) value. For example, for TID 1, n1 CWs / CWGs may be allowed, while for TID 2, n2 CWs / CWGs may be allowed. The k-th bit in the bitmap may indicate whether the k-th CW or CWG may be correctly decoded.

[0248] Fig.18 1 is a SIG-B schematic diagram showing an example of a frame format of an aggregated codeword (CW) / CW group (CWG) based acknowledgement. Here, an aggregated CW / CWG based acknowledgement may be used to carry a CW / CWG based acknowledgement for one or more group IDs. The acknowledgement may be an aggregated acknowledgement.

[0249] The value in the BA Type 1812 field may indicate an aggregated CW / CWG based acknowledgment. By detecting this field, the receiver may expect the BA Information 1806 field to contain fields such as a Packet ID field 1831 and a CW / CWG bitmap field 1832. The BA Information field 1806 may carry one or more per-packet information fields (e.g., 1821, 1822, 1823). Each per-packet information field may carry a Packet ID field 1831 and a CW / CWG bitmap field 1832.

[0250] In some cases, the confirmation may be a PHY layer confirmation and carry limited information. Such information may be carried in a Null Data Packet (NDP), which may have a PLCP header and no MAC body.

[0251] The CW-based NDP ACK may have one or more fields. The CW-based NDP ACK may include a wideband PLCP header, which may include L-STF, L-LTF, L-SIG, or RL-SIG fields, etc. The transmission of these fields may be performed over the entire operating frequency band.

[0252] The CW-based NDP ACK may include a narrowband PLCP header with an NDP confirmation, which may include an EHT-STF, an EHT-LTF, and a CW sequence. The transmission of these fields may be performed over the entire frequency band or over a designated RU (eg, narrowband).

[0253] There may be a resource unit (RU) based CW sequence defined for acknowledgment. In one case, two sequences may be defined and one sequence may indicate a positive ACK while the other sequence may indicate a negative ACK. In another case, three sequences may be defined, one sequence may indicate a positive ACK while the second sequence may indicate a negative ACK; the third sequence may be used to pad the transmission to the same boundary.

[0254] Fig.19 FIG. 1 is a transmission diagram showing an example of a DL OFDMA transmission with a UL NDP based on a CW confirmation. Typically, a CW sequence may be sent on an assigned RU and N OFDM symbols. The RU may be assigned explicitly or implicitly. For implicit assignment, the RU may be used to carry a CW ACK and may be the same set of RUs used for the confirmed data transmission. In one case, a RU-based CW sequence may be repeated on an assigned RU.

[0255] N can be determined by the maximum number of allowed CWs or the maximum number of CWs in confirmed data transmissions between all users. For example, if four CWs are allowed for data transmission, N can be 4n, as shown in a transmission with four CWs from AP1903 to STA1901 (e.g., see 1915, which shows 4 CWs and 2 padding). The first n OFDM symbols can be used to carry a CW sequence corresponding to the first CW. The second n OFDM symbols can be used to carry a CW sequence corresponding to the second CW, and so on. Here, n can be a predefined, predetermined, or configured integer; for example, n=1. At the transmission to STA1902, there can be six CWs (e.g., see 1917 showing 6CWs), so N=6n.

[0256] Low-density parity check (LDPC) can be used as one of the coding schemes for WLAN. An aggregate packet may contain multiple LDPC codeword groups. Due to channel and interference variations, some codeword groups may be decoded correctly while others may not be decoded correctly. Therefore, there is a need for improved LDPC coding for WLAN packets to enable more efficient HARQ transmission, thereby achieving higher peak throughput.

[0257] Fig. 20 is a schematic diagram showing an example LDPC encoding for a single CW. In LDPC encoding and decoding incremental redundancy (IR) HARQ, such as in 802.11, the bits selected for each redundancy version may be different. In this example process, at 2001, data bits are input. Next, at 2002, shortened bits are inserted before LDPC encoding to fit the coded bit length at 2003. Then, at 2004, the shortened bits are discarded. If necessary, at 2005 and 2006, puncturing and repetition may then be performed to generate the final CW.

[0258] Fig.21 is a schematic diagram showing an example of puncturing in LDPC coding. Generally, in LDPC coding, the punctured bits can be evenly distributed over all NCW codewords, where the first N punc mod NCW codewords are punctured one bit more than the remaining codewords. The number of punctured bits per codeword can be defined as N ppcw =floor(N punc / N cw ). If N ppcw > 0, then the last N coded packets can be discarded ppcwIn this example, there is an RV1 coded packet 2111 having data bits 2101 and parity bits 2102. Puncturing may be performed by dropping the last P1 2103 parity bits 2102 from the end of the coded RV1 packet 2111.

[0259] Fig. 22 is a schematic diagram showing an example of padding in LDPC coding. In general, for padding, the number of coded bits per codeword can be defined as N to be repeated. rep , and N rep is calculated. The number of coded bits to be repeated can be equally distributed over all codewords, wherein one or more bits may be repeated for the first codeword compared to the remaining codewords. The coded bits to be repeated for any codeword may be copied from the codeword itself (e.g., copying repeated bits 2204a-2204b), which may start with information bit i(0) (e.g., the first bit) and sequentially continue through information bits (e.g., data bits 2201), and, if necessary, continue to parity bits (e.g., 2202) until the desired number of repeated bits is obtained for the codeword. After the shortening bits have been removed, the repeated bits (e.g., 2203) may be copied from the codeword. In order to implement different redundancy versions in the process, it may be necessary to select specific bits for removal (e.g., in puncturing) or repetition (e.g., in padding) for use in IR-HARQ.

[0260] For IR-HARQ, an additional redundancy version (RV) may be selected by changing the puncturing bits or the starting index of the bits selected from the data bits used for padding. The rest of the LDPC encoding process may remain the same.

[0261] Fig.23 2303 and 2312 for puncturing in IR-HARQ. For puncturing of IR-HARQ, the starting index of the punctured bits (e.g., P12303 and 2312) may be changed for each RV, as shown for RV22300 and RV32310. Note that the parity bits 2303 of RV22300 start at a different time than the parity bits 2312 of RV32310.

[0262] Fig.24is a coding diagram showing an example of puncturing for IR-HARQ with parity buffer wraparound. When the start of the bits to be punctured is such that the punctured bits are some of the data bits 2401, the parity buffer can be wrapped around so that the bits to be punctured are at the beginning and end of the parity bit buffer 2403; see P12402 and P22404 wrapping around parity bits 2403. This ensures that data bits 2401 are not affected and can ensure that the system is self-decoding.

[0263] Fig.25 2500, when the start of the bits to be punctured is such that the punctured bits P1 2502 are some of the data bits 2501 and the parity bits 2503, then the full wraparound can be used. At RV4 2510, the wraparound is shown with P1 2511 at the start position and P2 2514 at the (e.g., wraparound) end position.

[0264] Fig.26 2600, the starting index at 2604a may be copied to the repeated bit 2603 at 2604b, and at RV3 2610, the starting index 2614a may be moved forward relative to RV2 2600, where the repeated bit 2613 goes to 2614b.

[0265] Fig. 27 2700, the start index exceeds the size of the combined data 2701 and parity bit buffer 2702, which may be wrapped (e.g., bit 2 is copied from the data bit 2701 to the end of the repeat bit 2703, and bit 1 is copied from the end of the parity bit to the beginning of the repeat bit 2703).

[0266] The duration field in the MAC header may indicate the duration from the end of a physical layer convergence protocol (PLCP) protocol data unit (PPDU) to the end of a transmission opportunity (TXOP), which may include response frames and / or multiple exchanges between a transmitter and a receiver. The duration field in the first HARQ transmission and the HARQ retransmission may be different. In the case where the HARQ transmissions may be in different TXOPs, the TXOP formats may be different so that the duration field may carry different values. In the case where multiple HARQ transmissions may be in a single TXOP, each duration field carried by the HARQ transmission may indicate the duration from the end of the PPDU carrying the duration field to the end of the TXOP. Therefore, the duration field may be different from one HARQ transmission to another.

[0267] If the Duration field is not the same, the MAC frames may be different. The first transmission and retransmission may carry different information bits, which may cause problems with HARQ combining. The Duration field may be used by unintended STAs to set the Network Allocation Vector (NAV), which may force the same Duration field, which may cause problems.

[0268] In a method for solving the above problem, a TXOP duration field carried by a signal (SIG) field and a duration field carried by a MAC header can jointly signal a potential TXOP duration with multiple HARQ transmissions. The method can be applicable to any transmitter and receiver, any of which can be a STA or an AP.

[0269] For HARQ transmissions, the transmitter may set a transmission indicator in the PLCH header or SIG field that indicates whether the transmission is the first transmission. The transmitter may set a TXOP duration field in the PLCH header or SIG field that may indicate a quantized TXOP duration from the end of the PPDU to the end of the TXOP; since the TXOP duration may be long and require many bits, a quantized TXOP may be required, and the SIG field has limited space, so some quantization of the TXOP may be required. The TXOP duration field may be different for each HARQ transmission for the same data packet.

[0270] For HARQ transmissions, the transmitter may set the duration field in the MAC header carried in the PPDU data field. For the first transmission of a HARQ transmission sequence, the duration field may indicate the TXOP duration from the end of the PPDU to the end of the TXOP. For retransmissions of a HARQ transmission sequence, the duration field may be set to the same value as the duration field in the first HARQ transmission, and thus may be the same among all HARQ transmissions for the same data packet.

[0271] A receiving STA, including an expected and an unexpected receiving STA, may check the PLCP header. If the receiving STA successfully detects the PLCP header and the SIG field, the receiving STA may check for a new transmission indication and continue the decoding process as discussed herein. If the receiving STA does not successfully detect the PLCP header, the receiving STA may stop decoding. If the new transmission indicates a new transmission (e.g., the first transmission of a HARQ transmission sequence), the receiving STA may save the value in the TXOP duration field and continue to check the data field. If the data field is successfully decoded and the receiving STA is not the expected receiving STA, the receiving STA may set the NAV based on the duration field carried in the MAC header. If the data field is successfully decoded and the receiving STA is the expected receiving STA, the receiving STA may prepare for confirmation when necessary. If the data field is not successfully decoded, the receiving STA may set the NAV based on the TXOP duration field carried in the PLCP header.

[0272] If the new transmission indication indicates retransmission, the receiving STA may save the value in the TXOP duration field and continue to check whether the STA is the expected receiving STA. If the STA is the expected receiving STA, the STA may continue to decode the data field. HARQ combining may be performed. If the STA is not the expected receiving STA, the STA may use the TXOP duration value carried in the PLCP header to set or update the NAV.

[0273] In some cases, the fields to be carried in the MAC header may be divided into two groups. Fields that may change from one HARQ transmission to another are placed in the first group, and other fields may be placed in the second group. For example, the first group may include a duration field, a retry field, and / or a receive address field. The first group may be carried in the HARQSIG field, which may be present in the PPDU. For HARQ transmission or HARQ retransmission, the second group of information may be used to replace the MAC header. In some instances, the format of the MAC header may not change, and the content of the MAC header may not be modified from the xth HARQ transmission to the yth HARQ transmission. Here, x and y may be from 1 to N. max Any integer, and N max It may be the maximum allowed HARQ transmission. Upon receiving the HARQ retransmission, the receiver may focus on the HARQ SIG field and the second set of information carried by the MAC header to obtain control information for the packet.

[0274] The presence of the HARQ SIG field may be optional and may be signaled through a HARQ SIG presence field in a general SIG field such as a SIG-A or SIG-B field.

[0275] In the case of CW-based HARQ transmission, the HARQ SIG field may include information for the receiver to identify the CW. For example, the HARQ SIG field may have a MAC address, a compressed MAC address, an AID, a compressed AID, or other types of IDs of (one or more) transmitters and (one or more) receivers. The HARQ SIG field may include a packet ID, such as an MPDU ID, a PPDU ID, so that the receiver can know that the received CW belongs to the MPDU or PPDU. The MPDUID may be a sequence number. The entire MAC header may be moved to the HARQ SIG field together with other HARQ related information.

[0276] Fig.28A 2801. It is a schematic diagram showing an example of joint transmission from two APs to a single STA. In MU-MIMO joint transmission from the perspective of a single STA, a slave trigger may be sent from anchor AP 2802 to slave AP 2803 before performing a joint transmission to STA 2801. The trigger may synchronize the carrier and symbol frequencies between APs (e.g., 2802 and 2803) to approximately match the situation when STA 2802 uses CSI before the joint transmission.

[0277] When the slave trigger is received by the slave AP, noise may be added to the slave trigger. After the carrier frequency offset (CFO) correction / synchronization of the slave trigger, it may not be guaranteed that the carrier / symbol frequency at the slave AP 2803 can be exactly the same as that of the anchor AP 2802. In addition, the clocks of the multiple APs may drift during the joint transmission after the synchronization, and the synchronization frequency between the multiple APs may also have an offset relative to the STA 2801 carrier / symbol frequency. Therefore, residual CFO correction on the receiving / non-AP STA side may be required.

[0278] In some 802.11 protocols, when a STA receives a PPDU, the transmitter of one spatial stream may be a single entity with a single clock. Based on this assumption, the receiving STA may correct the initial and residual CFO / sampling frequency offset (SFO) based on the estimation of the short training frame (STF) and / or long training frame (LTF) and / or pilot.

[0279] In joint transmission, the transmitter of a spatial stream may be multiple APs, and each AP may have its own clock. Using STF / LTF to estimate the initial CFO may not be ideal, because signals from different APs may use the same STF / LTF sequence for the same spatial stream, which may not be separable at the receiver side. In addition, data portions sent from different APs for the same spatial stream may also not be separable at the receiver side (e.g., joint transmission to a single antenna STA). This may make it problematic for the receiver to apply specific corrections to signals from a specific AP.

[0280] Since the joint transmission process may be transparent to STA 2801 (for example, when the STA may not be aware that more than one AP is involved in the beamforming transmission), an indication may be signaled in the preamble of the joint transmission PPDU to indicate that it is a joint transmission PPDU, so that the STA may not use the CFO / SFO correction process or other receiver processes applied to the PPDU from a single entity.

[0281] For example, if a STA receives a PPDU over two spatial streams with a joint transmission indication, it may assume that the two streams have a different frequency offset than its own clock. Based on this, it may perform CFO / SFO correction for each stream separately based on the STF / LTF / pilot of each stream, rather than combining these reference signals from the 2 streams to jointly determine a single CFO / SFO correction for the two streams.

[0282] Fig.28B28 is a diagram showing an example of a joint transmission from two APs with a backhaul to a single STA. The two APs may have a backhaul 2804 link operating on band B (eg, a different band than that used for joint transmission to the STA).

[0283] Fig.28C is a diagram showing an example of using a backhaul to correct a drift of an access link.

[0284] In one case, the anchor AP 2803 may signal the slave AP 2803 that its backhaul link transmitter and access link transmitter have the same clock source, or that the carrier / symbol frequencies on the two links are correlated.

[0285] In another case, the anchor AP 2802 can signal to the slave AP 2803 how the drift of its backhaul link and access link carrier / symbol frequency on the two links is related. For example, if the backhaul link from the anchor AP 2802 has a CFO / SFO of X ppm, then the access link from the anchor AP 2802 also has a CFO / SFO of X ppm, where X is some number. For example, if the source clock is 3 ppm slower than normal, then a 5 Hz carrier frequency can be slowed down by 5 GHz*3 ppm, and a 2.4 GHz carrier frequency can be slowed down by 2.4 GHz*3 ppm.

[0286] The slave AP 2803 may indicate to the anchor AP 2802 that it may use the above indication to perform frequency synchronization on the access link based on the observation of the backhaul link 2804. The slave AP 2803 may also enable the backhaul link and the access link to share the same clock source, or the slave AP 2803 may be able to observe its own clock difference between the backhaul link and the access link in real time. Once the anchor AP 2802 has collected this information from all slave APs (e.g., 2803), it may decide to indicate to all slave APs (e.g., 2803) that backhaul assisted frequency correction is activated during joint transmission, and / or that the joint transmission does not require the transmission of a midamble.

[0287] If there is reception on the backhaul, the slave AP (e.g., 2803) may derive the backhaul CFO / SFO initially based on the estimated LTF / STF, and additionally based on pilot tracking later during reception. The observed CFO / SFO may be used to correct the received backhaul signal. For example, the AP may apply a symbol-dependent phase offset to all OFDM tones of the same symbol to compensate for the CFO, and / or shift the window of time domain samples before the FFT for the OFDM symbol to compensate for the SFO.

[0288] After activating the backhaul assisted CFO / SFO correction, during joint transmission, if there is reception on the backhaul, the slave AP 2803 may determine the CFO / SFO correction at the access link at the slave AP 2803 when the signal is transmitted, using the CFO / SFO estimate of the backhaul at that time and possibly the frequency correlation between the backhaul link and the access link provided by the anchor AP 2802. For example, the AP may apply a symbol-dependent phase offset to all OFDM tones of the same symbol to compensate for the CFO, and / or adjust the time domain waveform after IFFT to compensate for the SFO.

[0289] Upon reception of the joint transmission, the STA 2801 may perform CFO / SFO corrections as if it were receiving a beamformed transmission from an antenna from a single AP to compensate for the frequency error between the STA 2801 and the anchor AP 2802. Ideally, the slave AP(s) 2803 may have performed the above process to match the frequency of the anchor AP 2802 and behave as if they were the antennas of the anchor AP 2802.

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

[0291] Although the solution described herein considers 802.11 specific protocols, it should be understood that the solution described herein is not limited to this scenario and may also be applied to other wireless systems.

[0292] Although in the examples of designs and procedures, SIFS is used to indicate various inter-frame spacings, all other inter-frame spacings, such as RIFS, AIFS, DIFS, or other agreed time intervals, may be applied in the same solution.

[0293] Although four RBs per triggered TXOP are shown as an example in some figures, the actual number of RBs / channels / bandwidth utilized may vary.

Claims

1. A method implemented by a station STA, the method comprising: receiving an indication of a multi-access point AP transmission regarding a first AP and a second AP; receiving a first packet having a first association ID, a first BSSID, and a hybrid automatic repeat request (HARQ) process ID from the first AP, wherein the first packet is received in a first 802.11 Wi-Fi transmission, and wherein the first association ID is carried in a first physical layer consistency procedure (PLCP) header and indicates that the STA is an intended receiver of the first packet, wherein the first BSSID is a locally unique identifier of the first AP; comparing a first association ID associated with the first packet based on information received from the first AP; receiving a second packet having a second association ID, a second BSSID, and a HARQ process ID from the second AP, wherein the second packet is received in a second 802.11 Wi-Fi transmission, and wherein the second association ID is carried in a second PLCP header and indicates that the STA is an intended receiver of the second packet, wherein the second BSSID is a locally unique identifier of the second AP; combining the first packet with the second packet based on matching the HARQ process ID of the second packet with the HARQ process ID of the first packet; and A response is broadcast to the first AP and the second AP.

2. The method according to claim 1, further comprising: decoding the first packet; as well as Start the timer.

3. The method according to claim 2, further comprising: decoding the second packet; as well as If the timer has not expired, combining the first packet and the second packet to create a combined packet, and decoding the combined packet; or If the timer has expired, it is determined that the second packet contains a new transmission, and the second packet is decoded. 4 . The method of claim 3 , further comprising verifying information related to the second packet based on information received from the second AP, wherein the information includes the second association ID.

5. The method of claim 4, wherein the response is based on whether the second packet is determined to complete the first packet and whether the timer has expired.

6. The method of claim 1, wherein the second packet is received after an extended interframe space (EIFS) period.

7. The method according to claim 1, wherein the first AP and the second AP are a virtual AP.

8. The method of claim 1, wherein the response comprises feedback of one or more resource units for the first grouping or the second grouping.

9. A station STA, comprising: transceiver; as well as a processor operatively coupled to the transceiver, wherein the processor and the transceiver are configured to receive an indication of a multi-access point AP transmission of a first AP and a second AP; The processor and the transceiver are configured to receive a first packet having a first association ID, a first BSSID, and a hybrid automatic repeat request (HARQ) process ID from the first AP, wherein the first packet is received from a first 802.11 Wi-Fi transmission, and wherein the first association ID is carried in a first physical layer consistency procedure (PLCP) header and indicates that the STA is an intended receiver of the first packet, wherein the first BSSID is a locally unique identifier of the first AP; The processor and the transceiver are configured to compare a first association ID associated with the first packet based on information received from the first AP; The processor and the transceiver are configured to receive a second packet having a second association ID, a second BSSID, and a HARQ process ID from the second AP, wherein the second packet is received from a second 802.11 Wi-Fi transmission, and wherein the second association ID is carried in a second PLCP header and indicates that the STA is an intended receiver of the second packet, wherein the second BSSID is a locally unique identifier of the second AP; combining the first packet with the second packet based on matching the HARQ process ID of the second packet with the HARQ process ID of the first packet; and The processor and the transceiver are configured to broadcast a response to the first AP and the second AP.

10. The STA according to claim 9, wherein The processor and the transceiver are further configured to decode the first packet; and The processor and the transceiver are also configured to start a timer.

11. The STA according to claim 10, wherein The processor and the transceiver are further configured to decode the second packet; and If the timer has not expired, the processor and the transceiver are further configured to combine the first packet and the second packet to create a combined packet, and decode the combined packet; or If the timer has expired, the processor and transceiver are further configured to determine that the second packet contains a new transmission and to decode the second packet.

12. The STA of claim 11, wherein the processor and the transceiver are further configured to verify information related to the second packet based on information received from the second AP, wherein the information includes the second association ID.

13. The STA of claim 12, wherein the response is based on whether the second packet is determined to complete the first packet and whether the timer has expired.

14. The STA of claim 9, wherein the second packet is received after an extended interframe space (EIFS) period.

15. The STA according to claim 9, wherein the first AP and the second AP are one virtual AP.

16. The STA of claim 9, wherein the response comprises feedback for one or more resource units of the first packet or the second packet.

Images