A method for enhancing WLANs using advanced HARQ designs

Abstract

A method and apparatus are provided for multiple hybrid automatic repeat request (HARQ) transmissions. An access point (AP) may transmit multiple HARQ transmissions to multiple stations (STAs). The AP may receive H-ARQ feedback responses from multiple STAs. The H-ARQ feedback may include a field to indicate that the H-ARQ feedback is a codeword (CW) / CW group (CWG)-based acknowledgment. The H-ARQ feedback may include a verify(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 acknowledgment. The H-ARQ feedback may be carried in a null data packet (NDP). The PLCP header of the NDP packet may include a wideband PLCP header and a narrowband PLCP header.

Description

[Technical field]

[0001] The present application relates to a method for enhancing WLANs with advanced HARQ designs. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of the following U.S. provisional patent 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.

[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 addresses wireless local area networks. As new use cases emerge, protocols may need to be adapted and improved to address the new use cases. Summary of the Invention

[0004] A method and apparatus are provided for multi-access point (AP) hybrid automatic repeat request (HARQ) transmission. In one embodiment, the method comprises a station (STA) monitoring a channel. The method further includes receiving a packet on the channel from a first AP. The first AP indicates that the packet is a multi-AP HARQ transmission. The method further includes determining that the received first AP identification (AID) is associated with the first AP. The method further includes determining that the received packet is a multi-AP HARQ transmission. The method further includes determining that the received packet is a retransmission. The method further includes determining that a timer has not expired. The method further includes combining the received packet with a stored packet. The method further includes successfully decoding the combined packet. The method further includes stopping the timer. The method further includes transmitting an acknowledgement to the first AP based on an acknowledgement policy.

[0005] A method and apparatus are provided for multiple hybrid automatic repeat request (HARQ) transmissions. The method may comprise an access point (AP) transmitting 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 an H-ARQ feedback response from the multiple STAs. The method may include an AP transmitting an H-ARQ feedback response trigger message to the multiple STAs. The method may include an 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 identification (ID). The H-ARQ feedback response trigger message may include a set of resource units (RUs) for the STA to use. The H-ARQ feedback response trigger message may include a resource unit (RU) factor indicating a number of RUs allowed for uplink transmission. The RU factor may include a RU purpose. The RU purpose may be a repetitive transmission. The RU purpose may be an independent transmission.

[0006] The H-ARQ feedback may include a field to indicate that the H-ARQ feedback is a codeword (CW) / CW group (CWG) based acknowledgement. The H-ARQ feedback may include a packet identification (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 acknowledgement. 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 wideband PLCP header and a narrowband PLCP header. [Brief description of the drawings]

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

[0008] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1A is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communications system shown in FIG. 1A, according to one embodiment. [Figure 1E] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Diagram 2] A transmission diagram illustrating an example of parallel HARQ processes over OFDMA for one or more STAs. [Diagram 3] A transmission diagram illustrating an example of parallel HARQ processes over OFDMA for multiple STAs. [Figure 4] A transmission diagram illustrating an example of parallel RV transmission for one or more STAs via OFDMA. [Diagram 5] 1 is a flow diagram illustrating an example of a multi-AP HARQ downlink process from the perspective of a STA. [Figure 6] A transmission diagram illustrating an example of a multi-AP HARQ downlink transmission. [Figure 7] A transmission diagram illustrating an example of a multi-AP HARQ downlink transmission. [Figure 8]A transmission diagram illustrating an example of a multi-AP HARQ downlink transmission. [Figure 9] 1 is a flow diagram illustrating an example of a multi-AP HARQ uplink process from the perspective of a STA. [Figure 10] FIG. 1 is a transmission diagram illustrating an example of a multi-AP HARQ uplink transmission. [Figure 11] FIG. 1 is a transmission diagram illustrating an example of a multi-AP HARQ uplink transmission. [Figure 12] FIG. 11 is a SIG-B diagram illustrating an example of a multi-AP HARQ acknowledgement. [Figure 13] A packet diagram illustrating an example of an A-PPDU format transmitted on the backhaul for multiple STAs. [Figure 14A] 1 is a flow diagram illustrating an example transmission process using a unique SIG-B field per HARQ process. [Figure 14B] FIG. 1 illustrates an example of transmission at different levels / layers using a unique SIG-B field per HARQ process. [Figure 15] FIG. 11 is a packet diagram illustrating an example where a single SIG-B illustrates HARQ information associated with all PHY subframes. [Figure 16] A packet diagram illustrating an example where a single SIG-B indicates HARQ information associated with a group of PHY subframes. [Figure 17] FIG. 1 is a SIG-B diagram illustrating an example of a frame format for basic codeword (CW) / CW group (CWG) based acknowledgment. [Figure 18] FIG. 1 is a SIG-B diagram illustrating an example of a frame format for aggregated codeword (CW) / CW group (CWG) based acknowledgment. [Figure 19] FIG. 13 is a transmission diagram illustrating an example of DL OFDMA transmission with UL NDP CW-based acknowledgment. [Figure 20] FIG. 1 illustrates an example low-density parity-check (LDPC) encoding for a single code (CW). [Figure 21] FIG. 1 illustrates an example of puncturing in LDPC coding. [Figure 22] FIG. 1 illustrates an example of padding in LDPC coding. [Figure 23] FIG. 1 is a coding diagram illustrating an example of puncturing for IR-HARQ in LDPC coding. [Figure 24] FIG. 13 is a coding diagram illustrating an example of puncturing for IR-HARQ with parity buffer wraparound. [Diagram 25] FIG. 13 is a coding diagram illustrating an example of puncturing for IR-HARQ with full buffer wraparound. [Figure 26] 1 is a coding diagram illustrating an example of padding for IR-HARQ. [Figure 27] 1 is a coding diagram illustrating an example of padding for IR-HARQ. [Figure 28A] 1 illustrates an example of joint transmission from two APs to a single STA. [Figure 28B] 1 illustrates an example of joint transmission from two APs to a single STA using backhaul. [Figure 28C]

[0023] FIG. 1 illustrates an example of using a backhaul to correct for drift in an access link. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] 1A is a system diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing 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 through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0010] 1A, the communications 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 will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may be equivalent to or include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a STA, a laptop computer, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), a consumer electronics device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c and 102d may be referred to interchangeably as a UE. As discussed herein, a WTRU may be interchangeably referred to as a STA, and a STA may be interchangeably referred to as a WTRU, and as discussed herein, a STA and a WTRU may be equivalent and / or the same.

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

[0012] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as, for example, a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. 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, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services to a particular geographic area, which may be 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 (e.g., one for each sector of the cell). In one scenario, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0013] 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 communications link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

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

[0015] 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 LTE Advanced (LTE-A) and / or LTE Advanced Pro (LTE-A Pro).

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

[0017] 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 implement both LTE radio access and NR radio access, e.g., using a dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0018] In other scenarios, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as, for example, IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Global Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856)), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and so forth.

[0019] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as an office, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, etc. In one scenario, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one scenario, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another scenario, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell utilizing a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0020] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, charging services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0021] The CN 106 may also serve 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 providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0022] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and a base station 114b, which may employ an IEEE 802 radio technology.

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

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

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

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

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

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

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

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

[0031] The processor 118 may further be coupled to other peripherals 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 peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality (VR) and / or augmented reality (AR) device, an activity tracker, etc. The peripherals 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.

[0032] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and DL (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce or substantially eliminate self-interference either through hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or via the processor 118). In one scenario, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or DL ​​(e.g., for reception).

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

[0034] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be appreciated that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 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 eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

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

[0036] 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are illustrated as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0037] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 is responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. 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.

[0038] The SGW 164 may be connected to each of the eNodeBs 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 perform other functions, such as anchoring the user plane during inter-eNodeB handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

[0040] 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 landline communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. The CN 106 may also 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.

[0041] Although the WTRU is illustrated in FIGS. 1A-1E as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

[0042] 1D is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may employ NR radio technology and communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

[0043] The RAN 104 may include gNBs 180a, 180b, 180c, although 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 for communicating over the air interface 116 with the WTRUs 102a, 102b, 102c. In one scenario, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, for example, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using multiple antennas. In one scenario, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on 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 multipoint (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or gNB 180c).

[0044] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including varying numbers of OFDM symbols and / or lasting varying lengths of absolute time).

[0045] 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 further access to other RANs (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with a gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may serve as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0046] 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, scheduling of users in the UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other over an Xn interface.

[0047] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are illustrated as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0048] 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, support for network slicing (e.g., handling different protocol data unit (PDU) sessions having different requirements), selecting a particular SMF 183a, 183b, managing registration realms, terminating non-access stratum (NAS) signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different applications, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0049] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 106 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0050] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, 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. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, etc.

[0051] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. The CN 106 may also 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 the local DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0052] 1A-1E and the corresponding description thereof, one or more, or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, APs 190a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network functions and / or WTRU functions.

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

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

[0055] In some examples, the other network 112 of Figure 1A may be a wireless local area network (WLAN), such as those defined by IEEE 802.11. Figure 1E is a system diagram illustrating an example communication system (e.g., a WLAN).

[0056] WLANs in infrastructure basic service set (BSS) 191a and 191b modes may each have an access point (AP) 190a and 190b for the BSS 191a and 191b, respectively, and one or more WTRUs 102a-e (e.g., STAs) associated with the APs 190a, 190b. As discussed herein, a given BSS may be referred to as a network and may refer to communications that occur locally. The APs 190a, 190b may have access or interfaces to a Distribution System (DS) or another type of wired / wireless network (not shown) that carries traffic into and / or out of the BSS. Traffic to a WTRU originating outside the BSS (e.g., 191a, 191b) may arrive through the APs (e.g., 190a, 190b) and be delivered to the WTRU. Traffic originating from WTRUs 190c-e destined for destinations outside of BSS 191a may be sent to AP 190a for delivery to the respective destination. Traffic between WTRUs 190c-e in BSS 191a may be sent through AP 190a, for example, where source WTRU 102c may send traffic to AP 190a, which may deliver traffic to destination STA 190d. Traffic between STAs (e.g., 190c-e) within a BSS (e.g., 191a) may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source WTRU and a destination WTRU using a direct link setup (DLS). In some cases, DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS).

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

[0058] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In some circumstances, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be in use, that STA may back off. One STA (e.g., only one station) may transmit at any given time within a given BSS.

[0059] A high-throughput (HT) STA may use a 40 MHz wideband channel for communication, for example, by combining a 20 MHz primary channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wideband channel.

[0060] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wideband channels. A 40 MHz and / or 80 MHz channel may be formed by combining adjacent 20 MHz channels. A 160 MHz channel may be formed by combining eight adjacent 20 MHz channels or by combining two non-adjacent 80 MHz channels, which may be referred to as an 80+80 configuration. In the case of the 80+80 configuration, the data may be passed to a segment parser that splits the data into two streams after channel coding. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately for each stream. The streams may be mapped onto two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the above-described operations for the 80+80 configuration may be reversed and the combined data may be sent to a medium access control (MAC).

[0061] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. In some circumstances, 802.11ah may support meter type control / machine type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities including support for certain and / or limited bandwidths (e.g., only these supports). MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0062] WLAN systems that support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, may include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. When the primary channel is in use, the entire available frequency band may be considered to be in use even if most of the available frequency band remains unused, e.g., due to a STA transmitting to the AP (e.g., this STA only supports a 1 MHz mode of operation).

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

[0064] In general, High Efficiency WLAN (HEW) can enhance the quality of service experienced by all users over a broad spectrum of wireless users in many usage scenarios, including high density scenarios in the 2.4 GHz, 5 GHz, and 6 GHz bands. Use cases that support dense deployment of APs and STAs and related radio resource management (RRM) technologies can be included in HEW. Possible applications for HEW can include usage scenarios of high user density scenarios (e.g., train stations, stadium events, enterprise / retail environments, etc.), and address the increased reliance on video / data delivery and wireless services for medical applications. HEW can be implemented in 802.11ax.

[0065] Also, 802.11ax can handle traffic for a wide variety of scenarios with short packets, including virtual office, TPC ACK, video streaming ACK, device / controller (mouse, keyboard, game controller, etc.), access-probe request / response, network selection-probe request, ANQP, and network management-control frames.

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

[0067] 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 several communication systems, such as 3GPP UMTS and LTE.

[0068] There are two popular types of HARQ combining schemes: Chase Combining (CC) HARQ and Incremental Redundancy (IR) HARQ.

[0069] For the Chase combining HARQ scheme, each retransmission may contain the same data and parity bits. The receiver may combine the received packet with the previous transmission using Maximal Ratio Combining (MRC). Chase combining is a technique that combines the energy per bit to noise power spectral density ratio (E b / N O ), which may be thought of as repetitive coding.

[0070] For IR HARQ schemes, each retransmission may 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 and parity bits. At each retransmission, the receiver may gain additional information. Retransmissions may contain only parity bits or may be self-decodable.

[0071] HARQ schemes can be classified as either synchronous or asynchronous, and retransmissions in each case are either adaptive or non-adaptive. For synchronous HARQ, retransmissions for each process can occur at a predefined time relative to the first transmission. Hence, 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 first transmission. Thus, explicit signaling is needed to indicate the HARQ process ID, to ensure that the receiver can correctly associate each retransmission with the corresponding previous transmission.

[0072] In LTE, the HARQ entity is located at the MAC layer, which is responsible for transmit / receive HARQ operations. Transmit HARQ operations include the transmission and retransmission of transport blocks, as well as the reception and processing of ACK / NAK signaling. Receive HARQ operations include the reception of transport blocks, the combination of received data, and the generation of ACK / NAK signaling based on the decoding results. To allow for continuous transmission while the preceding transport block is being decoded, up to eight parallel HARQ processes may be used to support multi-process "stop-and-wait" (SAW) HARQ operations. Multi-process HARQ interlaces several independent SAW processes in time, such that all transmission resources can be used by one of the processes. Each HARQ process is responsible for a separate SAW operation and manages a separate buffer.

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

[0074] In LTE, the following signaling may be used to support HARQ: HARQ process ID (e.g., for asynchronous HARQ only), New Data Indicator (NDI), which may be toggled every time a new packet transmission begins, Redundancy Version (RV), RV of the transmission block (e.g., for adaptive HARQ only), and Modulation and Coding Scheme (MCS) (e.g., for adaptive HARQ only).

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

[0076] In NR, there may be CBG-level HARQ retransmissions, where a transmission block (TB) may contain one or more CBGs, and one or more CBGs may have their own HARQ ACK bits. Thus, the transmitter may retransmit a partial TB. Two CBG-related signaling fields, namely, CBG transmission information (CBGTI) and CBG flushing out information (CBGFI), may be carried by the downlink control information (DCI). The CBGTI indicates the CBG that the (re)transmission carries. If the CBGFI is set to "0", it may indicate that a previously received instance of the same CBG being transmitted may be corrupted. If the CBGFI is set to "1", it may indicate that the CBG being retransmitted can be combined with a previously received instance of the same CBG.

[0077] In unlicensed NR (NR-U), where a device operates in one or more unlicensed or shared frequency resources, or in some combination of licensed and unlicensed bands, HARQ feedback may be transmitted on the unlicensed bands. NR-U may utilize mechanisms to support flexible triggering and multiplexing of HARQ feedback for one or more DL HARQ processes. NR-U may handle reduced HARQ ACK / NAK transmission opportunities for a given HARQ process due to LBT failures by including mechanisms to provide multiple and / or supplemental time and / or frequency domain transmission opportunities. NR-U may also have transmission of HARQ ACK / NAK for corresponding data in the same shared channel occupation / occupancy time (COT). In some cases, the HARQ ACK / NAK must be transmitted in a COT separate from the COT in which the corresponding data was transmitted.

[0078] Extremely High Throughput (EHT) can address increasing peak throughput and improve the efficiency of 802.11 networks. Use cases for EHT can include applications that require high throughput and low latency, such as Video-over-WLAN, Augmented Reality (AR), and Virtual Reality (VR). EHT can employ one or more of the following features: multi-AP, multi-band, 320MHz bandwidth, 16 spatial streams, HARQ, full duplex (in time and frequency domain), AP cooperation, Semi-Orthogonal Multiple Access (SOMA), and a new design for 6GHz channel access.

[0079] HARQ for EHT may be used to overcome weak link adaptation. This HARQ may combine aggressive MCS and other PHY features to provide enhanced performance for BSS edge coverage (e.g., coverage for STAs at the farthest possible distance, and possibly physically farthest from the nearest transmission source, such as an AP or another STA). HARQ may be utilized in EHT cases, such as MU or trigger-based (TB) PPDU. HARQ may provide 10-30% gains using chase combining, and potentially higher throughput gains if incremental redundancy is used.

[0080] Although the processes, apparatus, and systems relating to the techniques discussed herein are generally related to HARQ implementation in EHT scenarios, these techniques are also applicable to other wireless technologies and scenarios, and none of the illustrative examples and illustrations are intended to limit how, where, when, or to what these techniques may be applied.

[0081] In some use cases for EHT, including 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 may be used with HARQ to support these low-latency and high-reliability (e.g., ultra-reliable) applications. In one example, HARQ transmissions may occur simultaneously on multiple resource units (RUs). As discussed herein, a RU may be a basic transmission unit of resources (e.g., time, frequency, etc.). A RU may be replaced with a subchannel or a resource of a channel. For example, a subchannel may be a 20 MHz channel in 802.11.

[0082] FIG. 2 is a transmission diagram illustrating an example of parallel HARQ processes over OFDMA. First, AP 211 may assign multiple RUs to a single STA1 of multiple STAs 212. AP 211 may assign N RUs to STA1. At 201 and 202, AP 211 may simultaneously transmit multiple parallel transmissions with different HARQ process IDs to STA1, with each transmission on a different RU. On RU1, AP 211 may transmit a first transmission for HARQ process ID 1 (e.g., HARQ ID 1 Tx 1 to STA1). On RU2, AP 211 may transmit a first transmission for HARQ process ID 2 (e.g., HARQ ID 2 Tx 1 to STA1). And on RUN, AP may transmit a first transmission for HARQ process ID N.

[0083] At 202, there may be a HARQ trigger frame (TRF) for each HARQ portion to trigger a HARQ response from each STA, such as STA1 (e.g., and any other STAs 212), and the TRFs may be contained within the same PPDU containing the HARQ transmission. For example, a TRF for STA1 HARQ ID 1 on RU1, a TRF for STA1 HARQ ID 2 on RU2, up to a TRF for STA1 HARQ ID N on RUN, etc.

[0084] In some cases, the AP may send a trigger frame for the HARQ process ID before transmitting for HARQ data on one or more RUs (e.g., 202 would precede 201).

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

[0086] The STA 212 may indicate its HARQ response time to the AP 211, and vice versa. The STA 212 may indicate the HARQ response time at which the STA 212 is associated with an AP (e.g., the AP 211), and the AP 211 may include its HARQ response time in an element (e.g., an EHT capability element, a HARQ element, etc.). Such indications may be included in probe request / response frames, beacon and short beacon frames, (re)association request / response frames, FILS discovery frames, or other types of control management frames.

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

[0088] In some cases, such as when there is a known HARQ response time as described herein, the transmitting AP 211 may send a multi-HARQ ID block acknowledgment request (BAR) to the receiving STA 212 to solicit a response for one or more HARQ process IDs at a scheduled time or when the transmitting AP 211 has acquired the channel and any HARQ response time has elapsed (e.g., see 206). The multi-HARQ ID BAR may indicate the HARQ process ID for which the response is sought.

[0089] At 207, in the case where a multi-HARQ ID BAR is sent, the receiving STA 212 may then transmit a multi-HARQ block acknowledgment (BA) to provide a response regarding the status of HARQ operation for the indicated HARQ process ID.

[0090] Although the example of FIG. 2 is shown with a transmitting AP and a receiving STA, in some cases the transmitting AP (e.g., AP211) may be replaced by the transmitting STA and / or the receiving STA may be replaced by an AP.

[0091] A STA performing HARQ operation with another STA may not request a HARQ ACK / NAK / BA from the other STA before the indicated HARQ response time, which starts at the end of the PPDU containing the HARQ transmission, has elapsed. The response may be within an RU as indicated by a trigger frame, or over the entire channel bandwidth. Also, the HARQ ACK / NAK / BA may be implemented with several acknowledgement response options, such as ACK, NAK, not ready, not signal detected, collision, interference, and request to restart the HARQ process. In the case of the ACK acknowledgement option, the response may indicate that the HARQ transmission and / or its RV was correctly received and decoded. In the case of the NAK acknowledgement option, the response may indicate that the HARQ transmission and / or its RV was received but decoding failed. The NAK may also contain additional feedback information, such as a recommended RV, a recommended MCS, a recommended RU / channel, a recommended retransmission, etc. In the case of the not-ready acknowledgment option, the response may indicate that the receiving STA has detected the HARQ transmission and / or its RV signal, but that the receiving STA has not finished decoding and needs more time before an ACK / NAK can be provided. The response option may also include an expected response time. In the case of the no-signal-detection acknowledgment 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 fading, disruptive addition of signals, low transmit power, or other reasons. In the case of the collision acknowledgment 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 suggest that the received signal may be useful for future combining and processing, and that a new transmission should be sent. In the case of the interference acknowledgment option, the response may indicate that there is strong interference, such as high-power microwave energy or NR-U transmission, on the same band. The response may suggest that the received signal may be useful for future combining and processing, and that a new transmission should be sent.In the case of a request to restart the HARQ process acknowledgment option, the response may indicate that the receiver finds it more valuable to restart the HARQ process instead of continuing with additional RVs or retransmissions, which may be due to poor signal, poor received signal, poor channel conditions, or poor interference or collisions.

[0092] The transmitting STA receiving these responses (e.g., ACK, NAK, not ready, no signal detected, collision, interference, or request to restart the HARQ process) may take different actions. If an ACK is received, the transmitting STA may delete the buffered copy for the HARQ process ID and continue to the next HARQ process ID. If a NAK is received, the transmitting STA may decide to continue the HARQ operation for that HARQ process ID by sending either another copy of the same frame or an RV for the same HARQ process ID. If the number of retransmissions and / or RVs reaches a threshold, the transmitting STA may stop or abandon the HARQ process. If a not ready response is received, the transmitting STA may send another HARQ Block ACK Request (BAR), or a trigger frame, or an MU HARQ BAR to the receiving STA after some time has passed, asking for a response for the current HARQ process ID. Such a time may be indicated by the receiving STA as a HARQ response time, etc., or in the not ready response. If a signal non-detection, collision, or interference response is received, the transmitting STA may retransmit the packet / frame or send another RV for the HARQ process ID, which may occur on a different RU or channel, or using a different transmit power, which may be recommended by the receiving STA in a preceding response.

[0093] When receiving a response to a request to restart a HARQ process, the transmitting STA may restart the current HARQ process as if the previous transmission for the current HARQ process ID had not occurred. This process may occur on a different RU or channel, or using a different transmit power, which may have been recommended or indicated by the receiving STA in the previous response. Scheduling of the response for the HARQ process ID may be done in the header of the transmitted HARQ frame.

[0094] FIG. 3 is a transmission diagram illustrating an example of parallel HARQ processes through OFDMA for multiple STAs. FIG. 3 and FIG. 2 may be similar, except that FIG. 3 shows an example of multiple HARQ transmissions for multiple STAs. At 301 and 302, an AP 311 may transmit simultaneous transmissions of multiple HARQ process IDs for multiple STAs 312 (e.g., STA1, STA2, STA3, etc.). For example, 301 shows the first part of a packet transmission, where a TRF may follow as shown at 302. As shown, there may be a transmission of HARQ ID 1 Tx 1 to STA1, and another simultaneous transmission to the same STA1 of a different HARQ ID, and a simultaneous HARQ transmission to STA2 for multiple HARQ IDs.

[0095] At 302, a HARQ trigger frame (TRF) for each HARQ ID may trigger a HARQ response from each STA 312, such as STA1, and the TRFs may be contained within the same PPDU that contains the HARQ transmission. For example, a TRF may be sent to STA1 with HARQ IDs 1 through K (e.g., TRF to STA 1 HARQ ID 1), and at the same time, TRFs for HARQ IDs 1 through N may be sent to STA2, where K and N are some integers.

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

[0097] At 304 and 305, the HARQ process may continue as necessary depending on whether the STA receives a prior HARQ transmission (e.g., at 301). If the transmission is unsuccessful, there may be a second transmission (Tx 2) with the same HARQ ID (e.g., HARQ ID 1 Tx 2 to STA2, or HARQ ID K Tx 2 to STA1). If the transmission is successful, there may be a new transmission with a new HARQ ID (e.g., HARQ ID K+1 Tx 1 to STA1). At 305, one or more steps of the process may be repeated (e.g., continued HARQ transmission, acknowledgment, etc.).

[0098] In some cases, such as when there is a known HARQ response time as described herein, the transmitting AP 311 may send a multi-HARQ ID block acknowledgement request (BAR) to the receiving STA 312 at the scheduled time or when the transmitting AP 311 has acquired the channel and any HARQ response time has elapsed, asking for a response for one or more HARQ process IDs (e.g., see 306). The multi-HARQ ID BAR may indicate the HARQ process ID for which the response is asked. 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.

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

[0100] In some cases, the trigger frame may be used by the AP to trigger transmissions from multiple STAs simultaneously in the uplink, indicate a set of RUs for the transmitting STAs, and announce an RU factor Z that 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 assigned RU. For example, the AP may assign MCS, HARQ ID, RV, etc. The AP may let the STA determine the transmission method, such as MCS, HARQ ID, RV, etc.

[0101] In general, the STAs may be associated STAs (e.g., STAs associated with a network / AP / BSS) or unassociated STAs and may randomly access the channel to reduce delay. The transmitting STA may randomly choose Z RUs. If the objective of the factor is independent transmission, each transmitting STA may create a HARQ ID for each selected RU, or may use the same HARQ ID if the objective of the factor is repetition, where the STA may repeat the information content (i.e., information bits) or complex symbols (e.g., symbols in frequency) of the RU on the Z RUs.

[0102] In some cases, a STA may use different RVs for different RUs. For example, RUx and RUy may be assigned for repeated transmissions. A STA may use the same HARQ ID for both RUs, but RUx may use RV0 and RUy may use RV1. A STA may use different MCSs for different RUs based on the multipath channel response on that RU in the downlink. A STA may use different channel encoder structures for each RU, and the rates may be set differently. In case of unequal PPDU lengths for different RUs, the shorter PPDUs may be padded to maintain equal lengths. The UL PPDU length may be determined by the AP and may be conveyed in the trigger frame.

[0103] In general, the AP may decode the content in the announced RU. If the AP can decode the packet, it may send a per-RU or per-BA ACK for all RUs. If the AP cannot decode the packet, it may send a NACK. During the NACK transmission period, the AP may indicate the reason why the AP cannot decode the packet (e.g., collision, interference, and low SNR).

[0104] 4 is a transmission diagram illustrating an example of parallel RV transmission for one or more STAs via OFDMA. In this example, different RVs of the same HARQ process may be transmitted simultaneously to the same or multiple STAs.

[0105] In 401, the AP 411 may transmit parallel RVs of one or more HARQ IDs to one or more STAs 412 (e.g., STA1, STA2, STA3, etc.) through OFDMA. The AP 411 may transmit RV0 for HARQ ID 1 to STA1 on RU1, then transmit RV1 for HARQ ID 1 to STA1 on RU2 (not shown), and this may continue up to RVL for HARQ ID 1 to STA1 on another RU, where L is the number of RVs assuming a new RV is sent for each RU. The RUs chosen for transmission may not be consecutive. Similarly, for STA2, the AP 411 may transmit RV0 for HARQ ID 1 to STA2 simultaneously. This approach may also be repeated for each HARQ ID (e.g., HARQ2, 3, etc.) for a given STA. This process may continue for all STAs 412. In this example, the last simultaneous transmission may be with HARQ ID K RV 2 STA2.

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

[0107] At 404, the AP may transmit multiple RVs to multiple STAs, which may increment the RV number based on prior transmissions already sent depending on whether the first transmission was successful. For example, assuming HARQ is not successful for STA1 and HARQ ID 1, the AP 411 may transmit HARQ ID 1 to STA1 with RV L+1, where L is the last RV sent for HARQ ID 1 of STA1. This may continue for STA1, which in this example may continue to RV L+3. Similarly, transmission may not be successful for STA2 HARQ ID 1, and therefore the AP 411 may transmit an increased RV, such as RV3. If the transmission is successful, the HARQ may be increased. For example, HARQ ID K may be successful, and therefore AP 411 may transmit some HARQ ID K+2, which simply represents some other HARQ ID process other than HARQ ID K, since HARQ ID K was successfully transmitted (e.g., as determined from the STA2 response in 403).

[0108] At 405, one or more steps of the process may be repeated (eg, pending HARQ transmissions, acknowledging, etc.).

[0109] The HARQ response 407 may be triggered or prompted by a multi-STA multi-HARQ ID BAR in 406, where an RU is identified for each tuple, which may contain one or more of a HARQ process ID, a STA ID, or a TID.

[0110] One feature for EHT is multi-AP, where multiple APs are deployed within the same service set (e.g., BSS), e.g., in a home or work environment. Multiple APs may coordinate and have a certain level of cooperation to achieve higher peak throughput and increased efficiency. To achieve better BSS edge coverage, multiple APs may use HARQ operation with one or more STAs. To accomplish this, there must be an efficient design of HARQ operation between one or more STAs and multiple APs.

[0111] Multi-AP HARQ transmission may allow two or more APs to transmit packets to one STA. The APs may transmit packets asynchronously. In other words, the transmission may be performed in a TDD manner and may use different time slots to achieve the transmission of packets to one STA.

[0112] An 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 frame. An AP may also announce a list of neighboring APs that may work together to perform multi-AP HARQ transmissions.

[0113] 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 lifetime, which may give a suggestion for how long corrupted packets can be stored in the buffer. This may be a value in time, such as microseconds (μs), milliseconds (ms), or seconds (s). There may be a list of predefined / predefined values ​​of valid buffer lifetime. The STA may select one or more values ​​from the list, and a value index may be included and sent to the AP. The valid buffer lifetime may depend on the number of APs used to transmit asynchronously to the STA and the maximum number of transmissions expected from those APs. The HARQ buffer capability / limit may include a buffer size, which may suggest the maximum size the HARQ buffer can handle. This may be a value in bits or bytes. There may be a list of predefined / predefined values ​​of 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 a value index may be included and transmitted to the AP.

[0114] The STA may include information about neighboring (non-associated) APs, including both APs announced by the associated AP and other APs, such as AP identifiers, capability information, channel information, measurement information, context information, or other related information. For example, the information the STA may include may be SSID, BSSID, MAC address, other AP identifier, channel number, operating class, or PHY type, receive channel power indicator (RCPI), channel width, channel center frequency segment 0, channel center frequency segment 1, beacon interval, clear channel assessment (CCA), receive power indicator (RPI), channel load, noise histogram, beacon, frame, STA statistics, location configuration information (LCI) [latitude, longitude, altitude], transmit stream / category measurements, multicast diagnostics, location civic, location identifier, directional channel quality, directional measurements, directional statistics, fine timing measurement range, and any other neighbor AP information. The STA may also include any additional types of information.

[0115] For a multi-AP HARQ configuration in which a master AP manages the HARQ process, a STA may associate with an AP, which may become or already be the master AP, and 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 take the measured characteristic information into account when managing the HARQ AP. The master AP may inform the STA as to which AP the STA should monitor to receive multi-AP HARQ packets.

[0116] For HARQ packets sent to a STA, the master AP may generate a HARQ redundancy packet and provide it to the AP that the master AP has determined will transmit the packet. The master AP may provide the AP with the data to be sent and which HARQ redundancy version should be used to create the desired HARQ packet for transmission. From this information, the AP may create the desired HARQ redundancy packet that the master AP has determined the AP should send. When the AP receives or generates a HARQ packet, the master AP may request (trigger) the AP to send the packet by sending a trigger packet. The request may be sent over the air (e.g., wirelessly) by inter-AP signaling via a defined protocol. The request may also be sent via a wired inter-AP network connection. The master AP may specify to the AP the transmission time when the data or HARQ redundancy packet is sent to the AP, or any time prior to the desired transmission time.

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

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

[0119] In the case of a multi-AP HARQ configuration with a STA associated with multiple APs using distributed HARQ process control, the STA may be associated with multiple APs. The STA and associated AP may manage HARQ traffic to and from the associated STA. The STA may inform the AP of which AP the STA is associated with, and the AP may coordinate with the STA and with 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 AP may request the associated STA to measure characteristics of other APs. The AP may receive the measured characteristics from the STA. The AP may take the measured characteristic information into account when managing the HARQ process, or suggest the STA to associate with other APs.

[0120] For HARQ packets sent to STAs, the APs may generate various agreed-upon HARQ redundant packets independently, assuming they are all aware of the data to be sent, or the APs may coordinate among themselves as to how the packets are generated and which AP or APs should send the packets. The STAs may provide feedback to the APs. The APs may use the feedback in coordinating how the packets may be sent. The APs may coordinate wirelessly, over a wired network, or any combination of the two.

[0121] The STA may receive the HARQ packet sent by the AP and may process the packet using standard HARQ procedures until the packet is successfully received.

[0122] The STAs may send HARQ packets to any of the APs as directed and agreed upon by the AP and the STAs. The HARQ packets may be addressed specifically to the AP. The APs may attempt to receive packets sent by the STAs that are not addressed to them but are addressed to other APs participating in the process. This may allow the HARQ packets sent by the STAs to be detected at multiple APs. These detected packets may be forwarded to one of the APs to be HARQ combined, or they may be combined independently at each AP or at any agreed upon combination of APs.

[0123] In the case of a multi-AP HARQ configuration where the virtual BSS and the master AP manages the HARQ processes, an AP (e.g., the master AP) may define a virtual BSS to which all APs that support the HARQ processes for the STAs may belong. STAs associated with the AP may request multi-AP HARQ support. This AP may become the master AP and create a virtual BSS for the multiple APs that support the multi-AP HARQ processes that the STAs will use. The master AP may request the associated STAs to measure the characteristics of the other APs. The master AP may receive the measured characteristics from the STAs. The master AP may take the measured characteristic information into account when managing and creating the virtual BSS. Once the master AP has chosen 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 STAs on the BSS parameters, and the STAs may associate with the BSS. The STAs may maintain their association with the master AP for non-multi-AP HARQ traffic. The master AP may manage HARQ traffic to and from STAs associated with the virtual BSS. The STAs may not have knowledge of which AP comprises the virtual BSS, since all transmissions from these APs may appear as if they are coming from a single BSS. The master AP or the virtual BSS may inform the STAs as to which AP the STA should provide measurement information for, so that the master AP can manage the virtual BSS.

[0124] For HARQ packets sent to STAs, the master AP may generate HARQ redundancy packets and provide them to APs that the master AP has determined will send the packets using the virtual BSS identity. The master AP may provide the AP with the data to be sent and which HARQ redundancy version should be used to create the desired HARQ packet for transmission. From this information, the AP may create the desired HARQ redundancy packet that the master AP has determined the AP should send using the virtual BSS color identity. When the AP receives or generates a HARQ packet, the master AP may request (trigger) the AP to send the packet by sending a trigger packet. The request may be sent over the wireless medium via a defined AP-to-AP protocol. The request may also be sent over a wired AP-to-AP network connection. The master AP may specify to the AP the transmission time when the data or HARQ redundancy packet is sent to the AP, or any time prior to the desired transmission time.

[0125] The STA may receive HARQ packets sent by any of the APs using the virtual BSS identity and process these packets using standard HARQ procedures until the packets are 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.

[0126] A STA may send a HARQ packet to an AP in a virtual BSS by addressing the HARQ packet to the virtual BSS. All APs or any subset of APs in the virtual BSS may attempt to receive the packet sent by the STA. This may allow all HARQ packets sent by the STA to be detected at multiple APs. These detected packets may be forwarded to the master AP and HARQ combined, or they may be combined independently at each AP in the virtual BSS or at any combination of APs configured by the master AP.

[0127] In the case of a multi-AP HARQ configuration where the STA manages the HARQ process, the STA may associate with multiple APs and manage the APs to provide multi-AP HARQ services. The STA may request one of the associated APs to become the primary AP for the STA. If the APs agree to the role, the AP may become the primary AP, and as a distributed system (DS), the primary AP may route the STA's traffic to its destination, and the AP may cooperate with other APs requested by the STA to form a multi-AP group to support multi-AP services for the STA. The primary AP may assume a role similar to that of the "master AP" described above, except that the STA may manage which APs are in the multi-AP group. The primary AP may inform the STA of the existence of other APs that the primary AP believes the STA should consider adding to the multi-AP group. The STA may provide a request to the primary AP regarding which AP should send which redundancy version of the HARQ packet and which order is preferred for sending the packets. The primary AP may generate various HARQ redundancy packets and provide them to the APs that the primary AP has determined will send them, or the primary AP may provide the APs in the multi-AP group with the data to be sent and which HARQ redundancy version should be used to create the desired HARQ packet for transmission. From this information, the AP may create the desired HARQ redundancy packet that the primary AP has requested the AP to send. When the AP receives or generates a HARQ packet, the primary AP may request (trigger) the AP to send the packet by sending a trigger packet. The trigger packet may be sent wirelessly by AP-to-AP signaling via a defined protocol. The trigger packet may also be sent via a wired AP-to-AP network connection. The primary AP may specify to the AP the transmission time when the data or HARQ redundancy packet is sent to the AP, or any time prior to the desired transmission time.

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

[0129] In general, there may be many functions or actions regarding the STA and multiple APs that apply to a scenario regarding downlink (DL) transmission during any multi-AP HARQ situation. In such a scenario, the STA may associate and / or negotiate with multiple APs (e.g., a first AP and a second AP), and then one or more of the APs may send a transmission, all of which may or may not be received by the STA, after which the HARQ process may address incomplete / complete reception of the data transmission. The transmission sent by the AP may include an indication, such as BSSID / color, access point identifier (AID), multi-AP HARQ transmission, ACK policy, and / or HARQ-related information, etc.

[0130] 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 that may be carried in the PLCP header so that the STA knows if it is the intended receiver of the packet.

[0131] The multi-AP HARQ transmission indication may be indicated in a field, which the AP may use to explicitly or implicitly indicate that a transmission is a multi-AP HARQ transmission, which may allow a STA to combine received packets with different received AIDs. The multi-AP HARQ field may be carried in the PLCP header. A special value in the HARQ type field may be used to indicate that an incoming transmission is a multi-AP HARQ transmission. A special value in the HARQ process ID may be used to indicate that an incoming 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.

[0132] The AP may indicate the ACK policy in the PLCP header or the MAC header. Different ACK policies may result from different AP / STA frame exchange procedures. The ACK policy may be carried in the PLCP header or the MAC header with the multi-AP HARQ data packet. The ACK policy may be negotiated and determined before the multi-AP HARQ data transmission.

[0133] In an exemplary ACK policy, an immediate acknowledgment is sent after each transmission along with ACK / NAK / NTX, where ACK / NAK are positive / negative acknowledgments, respectively, and NTX is a no-transmission that may occur if an entire packet is lost, and the STA may not send a response.

[0134] In an exemplary ACK policy, an immediate ACK is sent after every configured transmission. For example, two transmissions (e.g., multi-AP HARQ transmissions) may be configured for a STA. When the first AP and the second AP have completed their transmissions to the STA, the STA may send an acknowledgment.

[0135] In an exemplary ACK policy, a delayed ACK may be sent. In this case, the acknowledgment may be transmitted in a delayed version. A single HARQ process may be repeatedly transmitted before the delayed ACK is received. More than one HARQ process may be supported and transmitted before the delayed acknowledgment is received.

[0136] In an exemplary ACK policy, a triggered / polled ACK may be sent. If this is configured, the transmission of the ACK may need to be triggered or polled by the peer STA using a control / management frame.

[0137] In an exemplary ACK policy, a multi-AP ACK may be sent. If this field is set, the STA may be able to send a multi-AP acknowledgment to the AP. If this field is not set, the STA may transmit to a single AP each time. A single acknowledgment to the master AP may be advantageous in cases where the STA transmission is not omnidirectional. Multiple acknowledgment frames may be transmitted consecutively with or without interframe spacing (xIFS) in cases where multiple APs may request an acknowledgment.

[0138] In an exemplary ACK policy, a value may be sent indicating that there is no acknowledgement between AP repeat transmissions. In this case, the AP may also signal the number of APs that may perform multi-AP HARQ transmissions to the STA. The AP may signal the number of APs that may transmit after this transmission and before the expected acknowledgement. The AP may signal the total number of APs that may transmit in a multi-AP HARQ transmission. The AP may, for example, signal both the total number of AP transmissions and the number of remaining AP transmissions before the acknowledgement.

[0139] 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), a retransmission indication, and so on.

[0140] Based on the transmission, the STA may make one or more decisions and / or take one or more actions. Upon receiving a packet, the STA may check the AID and BSSID / color field indication / information (e.g., in the received PLCP header sent with the packet) and compare it to the AID assigned to the STA in the corresponding BSS (e.g., configured during association / negotiation). If the AIDs match, the STA may consider itself 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 a retransmission for multi-AP HARQ. The STA may learn the maximum number of transmissions expected from the corresponding AP during the negotiation phase. The STA may save the transmission ID or HARQ process ID, which may be used to identify transmissions of the same packet. A STA may determine and store the RV of a transmission that may be used with a previously received transmission having the same transmission ID.

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

[0142] After the first signal transmission from the first AP with a packet, there may be a period for response. The second AP may not receive any positive response from the STA during this period and may initiate its multi-AP HARQ retransmission. This waiting period of the second AP may be predefined or predetermined and known to all parties. The period is sufficient to cover the ACK transmission and is a short inter-frame space (SIFS) duration plus a distributed coordinated function (DCF) inter-frame space (DIFS) duration. For example, the second AP may need to wait an extended inter-frame space (EIFS) duration to prepare a 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 not be the same as those carried by the first AP.

[0143] Upon receiving a packet transmitted by a second AP, the STA may check the AID and BSSID / Color fields in the PLCP header and compare it to its assigned AID in the corresponding BSS. If the AIDs match, the STA may consider itself the desired 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 has expired, the STA may treat the transmission as a new transmission. If the timer has not expired, 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 take the RV of a transmission into account when combining it with those stored in its buffer. The STA may know the maximum number of expected transmissions from the corresponding AP during the negotiation phase.

[0144] FIG. 5 is a flow diagram illustrating an example of a multi-AP HARQ downlink process from the perspective of a STA. For purposes of this example, it may be assumed that any of the general multi-HARQ scenario functions / 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., the first AP) on the monitored channel. The STA may determine that the AP AID matches one configured (e.g., during the association / negotiation period). At 503, the STA may determine (e.g., based on the PLCP header) that the signal is a multi-HARQ signal. 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, at 505, the STA determines whether the packet can be successfully decoded. If the packet can be successfully decoded, the STA may generate and transmit or broadcast an ACK to the associated AP at 506. If the STA determines at 505 that the packet cannot be successfully decoded, the STA may start a timer at 508. At 510, the STA may then store the packet in a buffer and then return to the beginning of process 501 to await 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 process 501 to await retransmission (not shown). If the STA determines at 504 that the received multi-HARQ signal is not a new transmission (e.g., a retransmission), the STA may determine at 507 whether the timer has expired. If the timer has expired, the STA may start the timer at 508 and continue from there as described above. If the timer has not expired, the STA may combine the received packet with the one stored in the buffer at 509.The STA then determines whether the packet was successfully decoded (e.g., the STA decoded the entire packet) at 511. If the STA successfully decodes the packet, the STA stops the timer at 512 and then proceeds to broadcast an ACK to the associated AP at 506. If the packet is not successfully decoded at 511, the STA stores the packet in a buffer at 510 and continues the process from there. Note that the determination at 511 of whether the packet is decoded is made only for retransmissions.

[0145] FIG. 6 is a transmission diagram illustrating an example of a multi-AP HARQ downlink transmission. For purposes of this example, it may be assumed that any of the general or example multi-HARQ scenario functions / actions described herein may apply, even if not explicitly stated. STA 503 may be associated with two or more APs (e.g., AP 601 and AP 602). AP 601, AP 602, and STA 603 may negotiate to perform a downlink (DL) multi-AP HARQ transmission (e.g., processes 511-515). As a result of the negotiation, STA 603 may have been indicated / informed that AP 601 has AID1 and AP 602 has AID2. AP 601 may be the main / primary / master AP for STA 603, and AP 602 may be the secondary / servant AP for STA 603. In this example, the ACK policy may be to not respond if a packet is not received, or if a packet is received but not fully decoded.

[0146] After association, the AP 601, AP 602, and STA 603 may negotiate to perform a multi-AP HARQ transmission (e.g., a PPDU transmission from both the AP 601 and the AP 602 to the STA 603). The negotiation may occur any time before the first multi-AP HARQ transmission, which occurs when the AP 601 transmits a multi-AP HARQ packet (e.g., sends a PPDU with AID1) to the STA 603 at 611, and the multi-AP HARQ packet 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, the STA 603 may not receive the packet (e.g., decoding fails) at 612, and therefore an acknowledgment following the transmission of the packet may not be sent.

[0147] After a certain period 613, the AP 602 may not receive any response from the STA 603 and may initiate its multi-AP HARQ retransmission at 614. The waiting period of the AP 602 may be predefined or predetermined. The period is sufficient to cover the ACK transmission and is a short interframe space (SIFS) duration plus a distributed coordination function (DCF) interframe space (DIFS) duration. For example, the AP 602 may need to wait an extended interframe space (EIFS) duration to prepare a retransmission, as shown at 613. The AP 602 may provide the same set of control signaling as the AP 601, or the AP 602 may carry a subset of the control signaling as provided by the AP 601. The AP 602 may provide its BSSID / color and AID (e.g., AID2) to the STA 603, which may not be the same as that provided by the AP 501.

[0148] The STA 603 may successfully decode the retransmission sent from the AP 602. Based on a preconfigured ACK policy, the STA 603 may prepare an acknowledgment transmission. At 615, the STA 603 may transmit a multi-AP ACK to both the AP 601 and the AP 602 at xIFS duration from the end of the packet.

[0149] FIG. 7 is a transmission diagram illustrating an example of a multi-AP HARQ downlink transmission. As can be seen, FIG. 7 illustrates an example of a multi-AP HARQ transmission procedure with an explicit NAK transmission, whereas FIG. 6 is an example of a multi-AP HARQ transmission procedure without an explicit NAK transmission. For the purposes of the example shown in FIG. 7, it may be assumed that any of the general or exemplary multi-HARQ scenario functions / actions described herein may be applied, even if not explicitly stated. Similar to the general process described herein for a multi-HARQ scenario, AP701, AP702, and STA703 may negotiate a multi-HARQ transmission. AP701 may have AID1, and AP702 may have AID2. In this example, the ACK policy may be set to a value indicating an immediate positive response with ACK / NAK / NTX after each transmission, where ACK / NAK may be a positive / negative response, respectively.

[0150] At 711, the AP 701 may transmit a packet (e.g., a PPDU) with AID1 to the STA 703. At 712, if the packet is not successfully decoded, the STA 703 may start a HARQ timer. The STA 703 may store corrupted packets in its buffer. The STA 703 may know the maximum number of expected transmissions from the corresponding AP during the negotiation phase. Depending on the ACK policy, at 713, the STA 703 may transmit a NAK to the AP 701 and / or the AP 702. The STA 703 may transmit a control / management frame to the AP 701 and / or the AP 702. Alternatively, the STA 703 may send a frame to the AP 702 to trigger a retransmission. In the control / management frame, the STA 703 may indicate preferred or proposed HARQ retransmission parameters. The AP 702 may receive a NAK from the STA 703, which may trigger its multi-AP HARQ retransmission at 714, and the AP 702 sends a packet (e.g., a retransmission) with AID2 at 714. The AP 702 may carry the same set of control signaling as the AP 701, or the AP 702 may carry a subset of the control signaling carried by the AP 701. The AP 702 may have its BSSID / color and AID assigned to the STA 703, which may not be the same as that carried by the AP 701. After the STA successfully decodes the retransmission packet at 714, the STA 703 may prepare an acknowledgment transmission based on the ACK policy, and then the STA 703 may send a multi-AP ACK to both the AP 701 and the AP 702 at xIFS duration from the end of the packet.

[0151] FIG. 8 is a transmission diagram illustrating an example of a multi-AP HARQ downlink transmission. In this example, there may be repeated transmissions, such as for an ACK policy, without the need to wait for a timer period (e.g., EIFS) or a response (e.g., ACK / NACK). For the purposes of this example, it may be assumed that any of the general or example multi-HARQ scenario features / actions described herein may apply, even if not explicitly stated. AP 801, AP 802, and STA 803 may negotiate to enable multi-AP HARQ transmission, which may occur any time before the multi-AP HARQ transmission 811. During the negotiation period, an ACK policy may be indicated. The ACK policy may be set to a value that does not indicate an acknowledgment between AP repeated transmissions. The STA803 may receive an indication regarding one or more of the number of APs that may perform a multi-AP HARQ transmission, the number of APs that may transmit after this transmission and before the expected acknowledgment, the total number of APs that may transmit in the multi-AP HARQ transmission, and / or the number of complete AP transmissions and the number of remaining AP transmissions before acknowledgment.

[0152] At 811, the AP 801 may transmit a multi-AP HARQ packet to the STA 803. At 812, the STA 803 may note that there is an indication that an ACK is not required between multi-AP HARQ transmissions. If the decoding fails, the STA 803 may proceed with the reception / decoding failure procedure as disclosed herein. If the reception is successful (e.g., the STA 803 can successfully decode the MAC body), the STA 803 may ignore any future repeat transmissions. At 813, the AP 802 may initiate a multi-AP HARQ retransmission after the transmission from the AP 801 without waiting for a time period or acknowledgment.

[0153] Once all transmissions have been sent, the STA 803 may prepare an acknowledgment transmission at 814. The STA 803 may transmit a Multi-AP ACK to both AP 801 and AP 802 within the xIFS duration (e.g., the Broadcast ACK frame period) from the end of the packet.

[0154] The example of Figure 8 can be extended to a situation where there are repeated transmissions per AP, for example, AP 801 may transmit a packet more than once (e.g., twice), AP 802 may transmit a packet more than once (e.g., twice), and STA 803 may transmit an acknowledgment after all the repetitions are completed.

[0155] As discussed herein, the physical resource allocation for each transmission in a HARQ process may be different to achieve frequency diversity. For example, a first transmission may use RU set 1, and a second transmission may use RU set 2. RU set 1 and RU set 2 may be fully overlapping, non-fully overlapping, or partially overlapping. Even if RU set 1 overlaps with RU set 2, the modulated symbol to physical resource mapping may be different for each transmission.

[0156] In the examples shown in Figures 6, 7, and 8, for simplicity of illustration, there are two APs transmitting to one STA, but these examples can be extended to situations where more than two APs transmit to one STA. Furthermore, these examples of multi-AP HARQ processes may be used in the case of multi-band HARQ.

[0157] In general, there may be many functions or actions for a STA and multiple APs that apply to scenarios for uplink (UL) transmissions during any multi-AP HARQ situation. 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 / servant AP. The STA may then transmit a HARQ transmission to both APs, using one resource for both, or using different resources for each AP. The STA may then receive an acknowledgment from one or both of the APs.

[0158] First, the STA may need to determine resources for uplink multi-AP HARQ transmission. In one case, the STA may be assigned common resources on both APs (e.g., at the trigger) and may transmit a single HARQ RV to both APs simultaneously. In the case of joint uplink HARQ combining, the AP may decode the packet using a combination of Chase combining and IR combining. Information from both APs collected from packets sent from a STA at a particular time may be Chase combined together. Additional RV versions of packets sent at other times may be IR combined with the originally received packet.

[0159] In another case, a STA may be assigned different resources on each AP. The resources may be separated by frequency (e.g., RU) or time. In this case, the AP may IR combine information from different resources for different APs.

[0160] In the case of AP instruction, the STA may be assigned one resource for both APs or different resources per AP. In one example, one single master trigger frame (from the master AP) may assign resources for both APs to the STA. The STA may read this master trigger and send information to the AP based on HARQ ID, RV, transmit power, and resources for both APs. In another example, separate trigger frames may be sent by each AP independently.

[0161] In the case of an autonomous STA, the STA may independently acquire HARQ transmission resources on the required AP and transmit to the desired AP, either by EDCA or by responding to a UL OFDMA Random Access (UORA) trigger frame. The STA packet may indicate the address of the desired AP.

[0162] Once the resources for the STAs are determined, the STAs may send transmissions with packets and the AP may receive the transmissions on the assigned resources and process them independently or jointly.

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

[0164] In one example, each AP may decode the information independently and perform local HARQ combining (e.g., separate uplink HARQ combining). In this example, communication between APs may be limited to whether there was successful decoding and how the success or failure of the decoding process will be transmitted to the STAs.

[0165] Once the transmission is processed, the AP must send a multi-AP HARQ response to the STA. The ACK / NAK responses may be sent independently from each AP or by a designated primary AP.

[0166] In scenarios where increased reliability may be required for AP responses, both APs may send responses independently, either on the same resource (e.g., to provide additional diversity, such as multi-AP shift diversity, which provides more channel variation due to diversity coming from different channels to the STAs, or from one AP intentionally delaying the transmission of its ACK, thereby increasing the frequency selectivity of the channel) or on different resources.

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

[0168] In general, any of the functions / actions of the multi-HARQ downlink scenarios described herein may be applied in a reciprocal manner to the uplink situation, even if not explicitly stated in the examples.

[0169] FIG. 9 is a flow diagram illustrating an example of a multi-AP HARQ uplink process from the perspective of a STA. For purposes of this example, it may be assumed that any of the general multi-HARQ scenario functions / actions described herein may apply, even if not explicitly stated. Initially, the STA may be associated with multiple APs and negotiate a multi-HARQ configuration with these APs. At 901, the STA may monitor the 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 that the AIDs 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 from 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 a multi-AP acknowledgment from the AP.

[0170] In some cases, an acknowledgement frame may be transmitted from a STA to multiple APs. In the example of FIG. 9, a multi-AP acknowledgement may contain an acknowledgement for one HARQ transmission, but the acknowledgement may need to be delivered to more than one AP. Thus, one or more or all of the following information may be required in the acknowledgement frame: acknowledgement type such as multi-AP HARQ ACK, AP ID as used to indicate the AP, HARQ ID, and / or acknowledgement.

[0171] FIG. 10 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 of the general multi-HARQ scenario functions / actions described herein may apply, even if not explicitly stated. There may be an AP 1001, an AP 1002, and a STA 1003 negotiating to perform a multi-AP HARQ uplink transmission. At 1011, the AP 1001 (e.g., a primary AP) may send one single master trigger frame for UL multi-AP HARQ transmission, which assigns resources for all APs (e.g., AP 1001 and AP 1002) to the STA 1003. The trigger may indicate information related to the HARQ ID, RV, transmit power, and resources for both APs. The STA 1002 may transmit a packet to the AP based on the trigger (e.g., having a single RV). In some cases, a separate trigger frame may be sent by each AP independently (not shown). At 1013, the AP may receive a packet on a common resource. In some cases, the APs may independently decode the packets (not shown). In other cases, the APs may HARQ combine using the backhaul / controller, where the APs may decode the packets using a combination of Chase combining and IR combining. Information from both APs about packets sent at a particular time may be Chase combined together. At 1014 and 1015, each AP may independently send an acknowledgment (e.g., an ACK using shift diversity).

[0172] FIG. 11 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 of the general multi-HARQ scenario functions / actions described herein may apply, even if not explicitly stated. There may be an AP 1101, an AP 1102, and a STA 1103 negotiating to perform a multi-AP HARQ uplink transmission. At 1111, the AP 1101 (e.g., the primary AP) may send one single master trigger frame for UL multi-AP HARQ transmission, which assigns resources for all APs (e.g., AP 1101 and AP 1102) to the STA 1103. The trigger may indicate information related to the HARQ ID, RV, transmit power, and resources for both APs. At 1112 and 1113, the STA 1103 may transmit one to each AP using different resources. The resources may be separated by frequency (e.g., RU) or time. At 1114, AP 1101 and AP 1102 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 (e.g., a primary / master AP) based on all the AP information.

[0173] FIG. 12 is a SIG-B diagram illustrating an example of a multi-AP HARQ acknowledgement. In general, a multi-STA BA (such as that defined in 802.11ax) may be modified to realize a multi-AP acknowledgement. In this way, each AP may have its own acknowledgement portion. For example, one or more fields may be adapted as shown in FIG. 12. One field may be a BA type field 1212, where the BA type may be used to indicate a multi-AP HARQ acknowledgement. Another field may be a BSSID11 field 1251, where the BSSID11 field 1251 may be defined in an AID TID information field. The BSSID11 may be used to indicate an AP ID. Another field may be a HARQ ID field 1242, where the HARQ ID field 1242 may be defined for each AID TID information field. The HARQ ID may vary by AP, but the AP may use the HARQ ID and BSSID11 together to identify the acknowledged packet. This field may be optional if only one HARQ ID is used.

[0174] In some cases, a wired backhaul may not be available, and thus a wireless backhaul may need to be utilized. In a multi-AP HARQ situation with wireless backhaul, APs may share data payloads between each other before multi-AP transmission (e.g., inter-AP communication). This communication between APs may be considered as overhead unless reused by the STA. The STA may be able to receive signals on the channel used for inter-AP communication.

[0175] For this wireless backhaul scenario, there may be two phases of communication: a backhaul transmission phase where one AP shares payload for a STA with one or more APs, and a multi-AP transmission phase where one or more APs may cooperate to transmit to the STA. To make data payload sharing between APs reusable 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.

[0176] For single STA data sharing, one AP may pack data intended for a STA into a packet and share it with one or more APs. The packet may be transmitted in an aggregated PPDU format such that each PPDU is individually coded, and may later be transmitted independently to the STA. The packet may have a special SIG field, which may contain one or more information fields.

[0177] One information field may be a backhaul transmission indication, which may indicate that the transmission is a backhaul transmission between APs sharing a data payload for a STA.

[0178] The one or more information fields may be Source AP ID, Destination AP ID, and Intended STA ID. Source AP ID / Destination AP ID may indicate the transmitter and receiver ID. Intended STA ID may indicate the STA to which the data carried in the PPDU may belong. The ID may be a MAC address, BSSID, AID, or other type of compressed or uncompressed ID.

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

[0180] FIG. 13 is a packet diagram illustrating an example of an A-PPDU format transmitted on the backhaul for multiple STAs. In the case of multi-STA data sharing, one AP may pack data intended for one or more STAs into a packet and share it with one or more APs. The packet may be transmitted in an aggregated PPDU format such that each PPDU is individually coded and later transmitted independently to the STAs. For example, a packet may contain two PPDUs to STA 1301 and three PPDUs to STA 1302. In one example, the SIG field may be STA specific and inserted before the PPDU belonging to the STA as shown in FIG. 13. In another example, the SIG field may be PPDU specific and inserted before each PPDU (not shown). The SIG field may contain one or more information fields.

[0181] One information field may be a backhaul transmission indication, which may indicate that the transmission is a backhaul transmission between APs for sharing data payload for STAs, or may be carried in a common SIG field in the PLCP header.

[0182] The one or more information fields may be Source AP ID, Destination AP ID, and Intended STA ID. Source AP ID / Destination AP ID may indicate the transmitter and receiver ID. Intended STA ID may indicate the STA to which the data carried in the PPDU may belong. The ID may be a MAC address, BSSID, AID, or other type of compressed or uncompressed ID.

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

[0184] One information field may be the next SIG field and may be used to indicate the location of the next SIG field within the A-PPDU.

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

[0186] In the case of a situation where the STA may transmit an acknowledgment on the backhaul channel, the STA may monitor the backhaul channel first. If the STA successfully detects the SIG field in the received packet, the STA may check if it is a backhaul transmission and if the STA ID matches the STA's own ID. If both checks pass, the STA may attempt to decode the subsequent PPDU. If the STA successfully decodes the PPDU, the STA may acknowledge the AP. If the STA does not successfully decode the PPDU, the STA may store the received signal in a buffer and continue to monitor its operating channel. If the STA subsequently detects a transmission to the STA with the same HARQ ID, the STA may combine and decode the received signal with the signal stored in the buffer. The STA may also perform any other steps as described herein.

[0187] FIG. 14A is a flow diagram illustrating an example transmission process using a unique SIG-B field per HARQ process. FIG. 14B is a diagram illustrating an example of a transmission scenario at different levels / layers using a unique SIG-B field per HARQ process. The description of FIG. 14A may be applied to FIG. 14B, and the example as illustrated in both figures may be referred to as the example of FIG. 14. p There may be a HARQ-based PPDU transmission with a HARQ process, and the transmission may contain information that may include a PLCP service data unit (PSDU) (e.g., an MPDU from the physical layer perspective), service field bits, and padding bits. This information is for M≦M pThe PSDU may be divided into K segments, each of which may be transmitted with a unique SIG-B field associated with a corresponding PHY subframe and one or more standalone codewords (CWs). For example, a PSDU may consist of K A-MPDU subframes and an end-of-frame (EOF) (see, e.g., 1421 MAC layer in FIG. 14B). The following may then be applied to transmit a PSDU to enable segment-based HARQ transmission with multiple SIG-B fields (e.g., 1422 PHY layer, 1423 bit level, and 1423 signal level in FIG. 14B). This process may be performed by a STA or an AP.

[0188] At 1401, the PSDU and the service field bits are concatenated to form N pad_PSDU bits, which gives a total of N bits The bits of the information content may be scrambled using a scrambler or interleaved using an interleaver.

[0189] In 1402, N bits The information bits may be divided into M segments, where each segment has N segment In some cases, distributed segmentation may be performed in which the information bits are grouped into M segments and padding is applied to each segment (e.g., distributed segmentation 1425 in FIG. 14B). For example, the number of padding bits may be such that each segment contains N pad_PSDU The padding bits may be uniformly distributed among the segments so that the segments have padding bits of 1000. Alternatively, the padding bits may be grouped into bytes first, and the number of bytes may be uniformly distributed among the segments except for the last. The segmentation may be a function of the LDPC codeword size.

[0190] At 1403, segments may be assigned to different HARQ processes based on the previous failed segments and the new available segments. Each HARQ process may transmit the same segment until transmission and until all redundant versions of the same segment have been transmitted.

[0191] In 1404, the raw data in each HARQ process is pad_preFEC padded with N bits phyCRC CRC bits, which is block =N segment +N pad_preFEC +N phyCRC bits. The blocks may include raw data, padding, and a CRC. The bits within each block may be scrambled using a scrambler. The bits within each block may be interleaved using an interleaver.

[0192] In 1405, each block is message M message The message may be divided into individual messages.

[0193] At 1406, each message is

[0194]

number

[0195] , which can be encoded using an encoder such as an LPDC encoder or a BCC encoder, cw The encoded block may generate a codeword of M message The encoded block may be generated by concatenating N encodedBlock =M message N cw It is possible.

[0196] In 1407, the corresponding PHY subframe at the bit level divides the coded block into N pad_postFEC , which may be generated by padding with zeros a length N PHYsubframe =N encodedBlock +N pad_postFEC Leads to bits.

[0197] At 1408, a bit level interleaver is cw coded bits, or N encodedBlock bits or N PHYsubframe This can be applied to bits.

[0198] For the mth PHY subframe, a unique SIG-B field may be prepared with the following content: A segment indicator that may indicate which segment is carried on the subsequent PHY subframe.

[0199]

number

[0200] (e.g., if it is 2, the PHY subframe contains information related to the second segment). A new segment indicator (1 bit) may indicate whether the content of the following PHY subframe is new or not (e.g., if it is 0, it is a retransmission of the same segment (e.g., segment X in FIG. 14B), and if it is 1, it means that a new segment is transmitted). A redundancy version index may indicate the redundancy version of the segment (e.g., if it is 3, the third redundancy version of the indicated segment is transmitted in the following PHY subframe). A number of pre-FEC padding bits

[0201]

number

[0202] may be used in subsequent PHY subframes.

[0203]

number

[0204] may be used in subsequent PHY subframes.

[0205]

number

[0206] may be used in the subsequent PHY subframe. A modulation coding index may be used in the subsequent PHY subframe. A segment length may be used, which may indicate the size of the information bits before coding, where the size may be in bytes, this field may indicate the size of the raw block and pre-FEC padding bits, and / or this field may indicate the size of the raw block.

[0207] At 1409, the bits in each PHY subframe may be mapped to modulation symbols, which may include N modSymbol =N PHYsubframe / log2S, where modulation S may be the modulation order (e.g., S=6 for 64QAM).

[0208] The symbol-level interleaver is modSymbol symbols, or the symbol-level interleaver may be applied to each OFDM symbol.

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

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

[0211] The mth SIG-B field associated with the mth PHY subframe may be transmitted consecutively.

[0212] In one case, N pad_preFEC may be chosen uniformly for each block, which may simplify the receiver design. pad_preFEC may be set to 0 except for the last block transmitted to reduce overhead. For example, bits may be distributed evenly across units (pre-FEC padding in each unit) or evenly across byte level across units, with the last unit requiring pre-FEC padding.

[0213] 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.

[0214] The segmentation calculation may be based on the codeword length. For example, various parity check matrices with different sizes may be considered for LPDC, which may result in different codeword lengths. To address this issue, bits The number of information bits is M=N CW,total After CRC addition, each group can be encoded into multiple codewords (i.e., blocks). Based on the size of the selected parity check matrix, N CW,total can be determined.

[0215] 15 is a packet diagram illustrating an example where a single SIG-B indicates HARQ information related to all PHY subframes. To reduce PPDU duration, the SIG-B field may be composed of multiple OFDM symbols that may contain information related to multiple PHY subframes. For this one PPDU, EHT-SIG-B1 1508 may provide information for PHY subframe 1 1509, PHY subframe 2 1510, etc., up to the Mth PHY subframe 1516.

[0216] FIG. 16 is a packet diagram illustrating an example where a single SIG-B indicates HARQ information related to a group of PHY subframes. Here, for one PPDU, a single SIG-B 1608 indicates HARQ information related to a group of PHY subframes. r This SIG-B1613 may indicate information related to this PHY subframe, and subsequent PHY subframes may be indicated by another SIG-B1613 along with the LTF.

[0217] In some cases, to enhance channel estimation performance for long packets using HARQ retransmissions, the LTF is set to M r For example, the Mth PHY subframe may be retransmitted after the Mth PHY subframe. r If = 4, the LTF may be retransmitted between the fourth and fifth PHY subframes.

[0218] In one approach, there can be a segmented transmission with a single HARQ process ID. A PPDU transmission can have a single HARQ process ID and up to M max PHY subframes, where M max M may be predefined / predetermined. Alternatively, the value may be dynamically determined by the AP and signaled in management / control frames, e.g., beacon frames, trigger frames, etc. For each STA, the information content, which may include PSDUs, service field bits, and padding bits, is determined such that M≦M maxThe PHY subframe may be divided into segments, each of which may be transmitted with a unique SIG-B field associated with the corresponding PHY subframe, and one or more standalone codewords. A single 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 may be 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 HARQ process ID together may uniquely identify a PHY subframe / segment.

[0219] The procedure may be the same as that discussed in connection with FIG. 14A, but the signaling part may be modified. In the case where a 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 for the PHY subframe. The SIG-B field may be prepared with a segment ID, which may indicate which segment is carried on the subsequent PHY subframe, which may be

[0220]

number

[0221] bits, or

[0222]

number

[0223] may have bits. The SIG-B field may be prepared using a segment indicator (1 bit), and the segment indicator may indicate whether the content of the subsequent PHY subframe is a new transmission (e.g., if it is 0, it may be a retransmission of the same segment (e.g., segment X in FIG. 14B), and if it is 1, it may indicate that a new segment is being transmitted). The SIG-B field may be prepared using a redundancy version index, and the redundancy version index may indicate the redundancy version of the segment (e.g., if it is 3, the third redundancy version of the indicated segment may be transmitted in the subsequent PHY subframe). The SIG-B field may be prepared using many pre-FEC padding bits

[0224] [Number]

[0225] used in the subsequent PHY subframe. The SIG-B field may be prepared using many post-FEC padding bits

[0226] [Number]

[0227] used in the subsequent PHY subframe. The SIG-B field may be prepared using many PSDU padding bits

[0228] [Number]

[0229] The SIG-B field may be prepared with a modulation coding index to be used in the subsequent PHY subframe. The SIG-B field may be prepared with a segment length, which may indicate the size of the information bits before coding, where the size may be in bytes, which may indicate the size of the raw block and pre-FEC padding bits, and / or which may indicate the size of the raw block.

[0230] FIG. 17 is a SIG-B diagram illustrating an example of a frame format for a basic codeword (CW) / CW group (CWG) based acknowledgment. In general, the basic CW / CWG based acknowledgment may be used to carry a CW / CWG based acknowledgment for a packet with a packet ID 1721. The packet ID may be a HARQ transmission ID, a sequence number, a MAC protocol data unit (MPDU) ID, or a PPDU ID. The packet ID 1721 may be used to uniquely identify a packet within a period. The packet ID may be carried in a PLCP header, and the contents of the packet may be carried in a data field. A packet may consist of one or more codewords. The maximum number of CWs / CWGs may be predefined, predetermined, or configured.

[0231] A value in the BA type field 1712 may indicate a basic CW / CWG-based acknowledgment. By detecting this field, the receiver may expect that the BA information field 1706 contains fields such as a packet ID field 1721 and a CW / CWG bitmap field 1722.

[0232] The packet ID field 1721 may be used to carry the ID of the acknowledged 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 period.

[0233] The CW / CWG bitmap field 1722 may carry the CW or CWG acknowledgment for the packet. The size of the bitmap may be determined by the maximum number of CWs / CWGs allowed for a 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 TID1, n1 CWs / CWGs may be allowed, and for TID2, n2 CWs / CWGs may be allowed. The kth bit in the bitmap may indicate whether the kth CW or CWG can be correctly decoded.

[0234] 18 is a SIG-B diagram illustrating an example of a frame format for an aggregated codeword (CW) / CW group (CWG) based acknowledgment, where the aggregated CW / CWG based acknowledgment may be used to carry a CW / CWG based acknowledgment for one or more packet IDs. The acknowledgment may be an aggregated acknowledgment.

[0235] A 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). The per-packet information fields may carry a packet ID field 1831 and a CW / CWG bitmap field 1832.

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

[0237] 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, RL-SIG fields, etc. Transmission of these fields may be over the entire operating band.

[0238] The CW-based NDP ACK may include a narrowband PLCP header with an NDP acknowledgement, which may include the EHT-STF, EHT-LTF, CW sequences. The transmission of these fields may be over the entire band or over an assigned RU (e.g., narrowband).

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

[0240] FIG. 19 is a transmission diagram illustrating an example of DL OFDMA transmission with UL NDP CW-based acknowledgment. In general, a CW sequence may be transmitted on the assigned RUs and on N OFDM symbols. The RUs may be explicitly assigned or implicitly assigned. With implicit assignment, the RUs may be used to carry the CW ACK and may be the same set of RUs for the acknowledged data transmission. In one case, the RU-based CW sequence may be repeated on the assigned RUs.

[0241] N may be determined by the maximum number of CWs allowed or the maximum number of CWs in acknowledged data transmissions among all users. For example, if four CWs are allowed for data transmission, then N may be 4n, as shown in the transmission from AP 1903 to STA 1901, which has four CWs (see, e.g., 1915, which shows four CWs and two pads). The first n OFDM symbols may be used to carry a CW sequence corresponding to the first CW. The second n OFDM symbols may be used to carry a CW sequence corresponding to the second CW, and so on. Here, n may be a predefined, predetermined, or configured integer, e.g., n=1. In the transmission to STA 1902, there may be six CWs (see, e.g., 1917, which shows six CWs), and therefore N=6n.

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

[0243] FIG. 20 illustrates an exemplary LDPC encoding for a single CW. In LDPC encoding and decoding Incremental Redundancy (IR) HARQ, for example in 802.11, the bits selected for each redundancy version may be different. In this exemplary process, data bits are input in 2001. Then, in 2002, shortened bits are inserted just before the LDPC encoding to fit the encoded bit length in 2003. Then, in 2004, the shortened bits are discarded. If necessary, puncturing and repetition may follow in 2005 and 2006 to generate the final CW.

[0244] FIG. 21 is a diagram illustrating an example of puncturing in LDPC coding. Generally, in LDPC coding, punctured bits are the first N punc The mod NCW codewords may be equally distributed over all NCW codewords, with each mod NCW codeword being punctured with one more bit than the remaining codewords. The number of punctured bits per codeword may be N ppcw =floor(N punc / N cw ) can be defined as N ppcw If >0, puncturing is performed on the last N ppcw Puncturing may be performed by discarding parity bits 2102 from the end of the last P1 2103 encoded RV1 packet 2111. In this example, there is an RV1 encoded packet 2111 having data bits 2101 and parity bits 2102. Puncturing may be performed by discarding the parity bits 2102 from the end of the last P1 2103 encoded RV1 packet 2111.

[0245] FIG. 22 is a diagram illustrating an example of padding in LDPC coding. In general, for padding, the number of coded bits per codeword is N rep and N repis calculated. The number of coded bits to be repeated may be distributed equally over all codewords, with one or more bits repeated for the first codeword than for 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), starting with information bit i(0) (e.g., the first bit), continuing consecutively through the information bits (e.g., data bits 2201), and, if necessary, into the parity bits (e.g., 2202) until the required number of repeated bits is obtained for that codeword. The repeated bits (e.g., 2203) may be copied from the codeword after the shortened bits have been removed. To allow for different redundancy versions in this process, certain bits may need to be selected for removal (e.g., in puncturing) or repetition (e.g., in padding) for IR-HARQ.

[0246] For IR-HARQ, an additional redundancy version (RV) may be selected by changing the starting index of the punctured bits or the bits selected from the data bits for padding. The rest of the LDPC coding procedure may remain the same.

[0247] 23 is a coding diagram illustrating an example of puncturing for IR-HARQ in LDPC coding. For puncturing for IR-HARQ, the starting index of the punctured bits (e.g., P1 2303 and 2312) may be changed for each RV, as shown for RV2 2300 and RV3 2310. Note that the parity bits 2303 for RV2 2300 start at a different time than the parity bits 2312 for RV3 2310.

[0248] Figure 24 is a coding diagram illustrating an example of puncturing for IR-HARQ with parity buffer wraparound. If the beginning of the bits to be punctured is such that the punctured bits are some of the data bits 2401, the parity buffer is wrapped around so that the bits to be punctured are at the beginning and end of the parity bit buffer 2403. See P1 2402 wrapping around the parity bits 2403 with P2 2404. This ensures that the data bits 2401 are not affected and may ensure that the system is self-decodable.

[0249] Figure 25 is a coding diagram illustrating an example of puncturing for IR-HARQ with full buffer wraparound. In RV4 2500, if the beginning of the bits to be punctured is such that the punctured bits P1 2502 are some of the data bits 2501 and parity bits 2503, full wraparound may be employed. In RV4 2510, wraparound is shown with P1 2511 at the beginning and P2 2514 at the end (e.g., wrapping around).

[0250] Figure 26 is a coding diagram illustrating an example of padding for IR-HARQ. To perform padding for IR-HARQ, the starting index of the padded bits may be changed for each redundancy version. For example, for RV2 2600, the starting index in 2604a may be copied to the repeated bits 2603 in 2604b, and in RV3 2610, the starting index 2614a may be moved forward compared to RV2 2600, and the repeated bits 2613 go to 2614b.

[0251] 27 is an encoding diagram illustrating an example of padding for IR-HARQ. For an RV such as RV1 2700 with a starting index that exceeds the size of the combined data 2701 and parity bit buffer 2702, the buffer may wrap around (e.g., bit 2 is copied from the data bits 2701 to the end of the repeated bits 2703, and bit 1 is copied from the end of the parity bits to the beginning of the repeated bits 2703).

[0252] The duration field in the MAC header may indicate a duration starting 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 a response frame and / or multiple exchanges between the transmitter and receiver. The duration fields in the first HARQ transmission and the HARQ retransmission may not be the same. In cases where the HARQ transmissions may be in different TXOPs, the TXOP formats may be different such that the duration field may carry different values. In cases where the HARQ transmissions may be in a single TXOP, each duration field carried by the HARQ transmission may indicate a duration from the end of the PPDU carrying the duration field to the end of the TXOP. Thus, the duration field may be different for each HARQ transmission.

[0253] If the duration fields are not the same, the MAC frames may be different. The first transmission and the retransmission may carry different information bits, which may cause problems for HARQ combining. The duration field may be used for unintended STAs to set the Network Allocation Vector (NAV), which may force the same duration field, which may cause problems.

[0254] In an approach to address the above problem, a TXOP duration field carried by a signal (SIG) field and a duration field carried by a MAC header may be used to jointly signal a potential TXOP duration along with a HARQ transmission. This approach may be applicable to any transmitter and receiver, either of which may be a STA or an AP.

[0255] For HARQ transmission, the transmitter may set a transmission indicator in the PLCH header or SIG field to indicate whether the transmission is the first transmission. The transmitter may set a TXOP duration field in the PLCH header or SIG field to indicate the quantized TXOP duration from the end of this PPDU to the end of the TXOP, and a quantized TXOP may be needed because the TXOP duration may be long and require many bits, whereas the SIG field has limited space and therefore some quantization of the TXOP may be needed. The TXOP duration field may be different for each HARQ transmission for the same data packet.

[0256] For a HARQ transmission, 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 this PPDU to the end of the TXOP. For a retransmission of a HARQ transmission sequence, the duration field may be set to the same value as in the first HARQ transmission and thus may be the same among all HARQ transmissions for the same data packet.

[0257] Receiving STAs, including desired and non-desired receiving STAs, may check the PLCP header. If the receiving STA successfully detects the PLCP header and SIG fields, the receiving STA may check for a new transmission indication and continue the decoding procedure as discussed herein. If the receiving STA does not successfully detect the PLCP header, the receiving STA may stop decoding. If the new transmission indication indicates a new transmission (e.g., a first transmission, HARQ transmission sequence), the receiving STA may save the value in the TXOP duration field and continue checking the data field. If the data field is successfully decoded and the receiving STA is not the desired 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 desired receiving STA, the receiving STA may prepare an acknowledgment, if 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.

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

[0259] In some cases, the fields to be carried in the MAC header may be split into two groups. Fields that may change for each HARQ transmission may be placed in a first group, and other fields may be placed in a second group. For example, the first group may include a duration field, a retry field, and / or a recipient address field. The first group may be carried in a HARQ SIG field that may be present in the PPDU. In case of a HARQ transmission or a HARQ retransmission, the second group 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, where x and y are from 1 to N. max may be any integer up to N max may be the maximum allowed HARQ transmission. Upon receipt of the HARQ retransmission, the receiver may look to the HARQ SIG field and the second group information carried by the MAC header to obtain control information for the packet.

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

[0261] In the case of CW-based HARQ transmission, the HARQ SIG field may contain information for the receiver to identify the CW. For example, the HARQ SIG field may have a MAC address, compressed MAC address, AID, compressed AID, or other type of ID of the transmitter and receiver. The HARQ SIG field may contain a packet ID such as MPDU ID, PPDU ID, etc., so that the receiver may know that the received CW belongs to an MPDU or PPDU. The MPDU ID may be a sequence number. The entire MAC header may be moved to the HARQ SIG field along with other HARQ related information.

[0262] 28A is a diagram illustrating 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 servant trigger may be sent from the anchor AP 2802 to the servant AP 2803 prior to joint transmission to the STA 2801. The trigger may synchronize the carrier and symbol frequency between the APs (e.g., 2802 and 2803) to match the conditions when CSI was taken by the STA 2802 prior to the joint transmission.

[0263] Noise may be added to the servant trigger when it is received by the servant AP. After carrier frequency offset (CFO) correction / synchronization of the servant trigger, there may be no guarantee that the carrier / symbol frequencies at the servant AP 2803 may be exactly the same as those at the anchor AP 2802. Furthermore, the clocks of the APs may drift after this synchronization during the joint transmission period, and the synchronized frequency between the APs may also have an offset with respect to the STA 2801 carrier / symbol frequency. Therefore, CFO correction at the receiving / non-AP STA side may be required.

[0264] 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 estimate and correct the initial and residual CFO / sample frequency offset (SFO) based on the short training frame (STF) and / or long training frame (LTF) and / or pilots.

[0265] In joint transmission, the transmitters of spatial streams may be multiple APs, and each AP may have its own clock. The use of STF / LTF to estimate the initial CFO may not be ideal, since 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. Furthermore, data portions transmitted from different APs of 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 a current problem for the receiver to apply a specific correction to the signal coming from a specific AP.

[0266] Because the joint transmission procedure may be transparent to the STA 2801 (e.g., in cases where the STA may not be aware that two or more APs have participated in a beamformed transmission), an indication may be signaled within the preamble of the jointly transmitted PPDU to indicate that it is a jointly transmitted PPDU, such that the STA does not have to use CFO / SFO correction procedures or other receiver procedures that apply to PPDUs coming from a single entity.

[0267] For example, if a STA receives a PPDU with two spatial streams with a joint transmission indication, it may assume that the two streams have a different frequency offset from its own clock. Based on this, it may perform per-stream CFO / SFO corrections separately based on the STF / LTF / pilots of each stream, instead of combining these reference signals from the two streams and jointly determining a single CFO / SFO correction for both streams.

[0268] 28B is a diagram illustrating an example of joint transmission from two APs to a single STA using a backhaul. The two APs may have a backhaul 2804 link operating on band B (e.g., a band different from the band used for joint transmission to the STA).

[0269] FIG. 28C is a diagram illustrating an example of using a backhaul to correct drift in an access link.

[0270] In one case, the anchor AP 2803 may signal to the servant AP 2803 that its backhaul link and access link transmitters have the same clock source or that the carrier / symbol frequencies on both links are correlated.

[0271] In another case, the anchor AP 2802 may signal to the servant AP 2803 how its backhaul link and access link carrier / symbol frequency drift on both links are correlated. 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 becomes 3 ppm slower than normal, the carrier frequency at 5 Hz may be 5 GHz * 3 ppm slower and the carrier frequency at 2.4 GHz may be 2.4 GHz * 3 ppm slower.

[0272] The servant AP 2803 may use the above indication to indicate to the anchor AP 2802 that it may perform frequency synchronization on the access link based on observation of the backhaul link 2804. The servant AP 2803 may have the backhaul link and the access link share the same clock source, or the servant AP 2803 may be able to observe its own clock difference between the backhaul link and the access link in real time. Upon collecting this information from all servant APs (e.g., 2803), the anchor AP 2802 may decide to activate backhaul-assisted frequency correction during joint transmission periods and / or indicate to all servant APs (e.g., 2803) that joint transmission does not require transmission of midambles.

[0273] If there is reception on the backhaul, the servant AP (e.g., 2803) may derive the backhaul CFO / SFO during reception, first based on the estimated LTF / STF, and later additionally based on pilot tracking. 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 move a window of time-domain samples before the FFT on the OFDM symbol to compensate for the SFO.

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

[0275] The STA 2801, when receiving a joint transmission, may perform CFO / SFO correction to compensate for frequency errors between the STA 2801 and the anchor AP 2802 as if it received a beamformed transmission from an antenna coming from a single AP. Ideally, the servant A 2803 may perform the procedure described above to match the frequency of the anchor AP 2802 and behave as if they were the antennas of the anchor AP 2802.

[0276] Although the functions and elements are described above in a particular combination, one skilled in the art will recognize that each function or element can be used alone or in any combination with other functions and elements. Also, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electrical signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). Software and associated processors may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0277] Although the solutions described herein take into account 802.11 specific protocols, it will be understood that the solutions described herein are not limited to this scenario and are applicable to other wireless systems as well.

[0278] Although SIFS is used to indicate various interframe spacings in the design and procedural examples, any other interframe spacings, such as RIFS, AIFS, DIFS or other agreed upon time intervals, may be applied in the same solution.

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

Claims

1. A method performed by a station (STA), comprising: receiving an indication regarding a multi-AP transmission for a first access point (AP) and a second AP; receiving a first packet from the first AP having a first association ID, a first BSSID, and an automatic repeat request (HARQ) process ID, the first packet being received in a first 802.11 WiFi transmission, the first association ID being carried in a first Physical Layer Convergence Protocol (PLCP) header indicating that the STA is an intended recipient of the first packet, and the first BSSID being a locally unique identifier for the first AP; comparing the first association ID associated with the first packet based on information received from the first AP; receiving a second packet from the second AP having a second association ID, a second BSSID, and the HARQ process ID, the second packet being received in a second 802.11 WiFi transmission, the second association ID being carried in a second PLCP header indicating that the STA is an intended recipient of the second packet, and the second BSSID being a locally unique identifier for the second AP; combining the first packet with the second packet based on the HARQ process ID received in the first packet and the HARQ process ID received in the second packet being the same; broadcasting a response to the first AP and the second AP; A method comprising:

2. Decoding the first packet; and starting a timer; The method of claim 1 further comprising:

3. Decoding the second packet; and combining the first packet and the second packet to generate a combined packet if the timer has not expired and decoding the combined packet, or determining that the second packet comprises a new transmission if the timer has expired and decoding the second packet; The method of claim 2 , further comprising:

4. determining information related to the second packet based on information received from the second AP, the information including the second association ID or a HARQ ID; The method of claim 3 further comprising:

5. The method of claim 4 , wherein the response is based on whether the second packet is determined to be complementary to 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 of claim 1 , wherein the first AP and the second AP are a virtual AP.

8. A station (STA), A transceiver; a processor operably coupled to the transceiver; Equipped with The processor and the transceiver are configured to receive an indication regarding a multi-AP transmission to a first access point (AP) and a second AP; The processor and the transceiver are configured to receive a first packet from the first AP, the first packet having a first association ID, a first BSSID, and an automatic repeat request (HARQ) process ID, the first packet being received in a first 802.11 WiFi transmission, the first association ID being carried in a first Physical Layer Convergence Protocol (PLCP) header and indicating that the STA is an intended recipient of the first packet, the first BSSID being a locally unique identifier for the first AP, the processor and the transceiver are configured to compare the 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 from the second AP having a second association ID, a second BSSID, and the HARQ process ID, the second packet being received in a second 802.11 WiFi transmission, the second association ID being carried in a second PLCP header indicating that the STA is an intended recipient of the second packet, the second BSSID being a locally unique identifier for the second AP; the processor and the transceiver are configured to combine the first packet with the second packet based on the HARQ process ID received in the first packet and the HARQ process ID received in the second packet being the same; the processor and the transceiver are configured to broadcast a response to the first AP and the second AP; S.T.A.

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

10. the processor and the transceiver are further configured to decode the second packet; 10. The STA of claim 9, wherein if the timer has not expired, the processor and the transceiver are further configured to combine the first packet and the second packet to generate a combined packet and decode the combined packet, or if the timer has expired, the processor and the transceiver are further configured to determine that the second packet includes a new transmission and decode the second packet.

11. 11. The STA of claim 10, wherein the processor and the transceiver are further configured to ascertain information associated with the second packet based on information received from the second AP, the information including the second association ID.

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

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

14. The STA of claim 8 , wherein the first AP and the second AP are a virtual AP.

Images