Physical (PHY) Layer Design for Hybrid Automatic Repeat Request (HARQ) in Wireless Local Area Network (WLAN) Systems

Abstract

A method for transmitting data from a wireless device includes determining an information block length corresponding to an error correcting code; inserting padding bits into at least one protocol data unit (PDU) of a plurality of PDUs such that a padded PDU size is an integer multiple of the determined information block length, wherein each PDU in a frame of PDUs to be transmitted includes a PDU size that is an integer multiple of the determined information block length; and transmitting the frame encoded with the error correcting code having the determined information block length to a wireless receiver.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 989,274, filed March 13, 2020, which is incorporated herein by reference in its entirety for all purposes. [Background technology]

[0002] Hybrid Automatic Repeat Request (HARQ) is used in 5G networks. A mechanism like HARQ is also desirable in wireless local area networks (WLANs). The IEEE 802.11 standard was not originally designed to include HARQ functionality. As the IEEE 802.11 standard evolved, HARQ functionality was introduced to support efficient retransmission of information received with errors. However, implementing HARQ-like functionality in WLANs poses challenges, including the need to consider the detection of protocol data units for correction and the use of aggregated protocol data units for efficient transmission over the wireless network. Therefore, a new method for supporting HARQ in WLANs using the IEEE 802.11 protocol is needed. Summary of the Invention

[0003] In one embodiment, a method for aligning a size of a Protocol Data Unit (PDU) in a plurality of PDUs to a length of a corresponding information block of an error correcting code for wireless transmission includes determining an information block length corresponding to the error correcting code, and inserting padding bits into at least one PDU of the plurality of PDUs to align the padded PDU size to an integer multiple of the determined information block length. Each PDU size within a frame of PDUs is similarly aligned to an integer multiple of the determined information block length. The frame of PDUs is encoded with an error correcting code having the determined information block length and transmitted to a wireless receiver.

[0004] Although various embodiments are described and / or claimed herein in which apparatus, systems, devices, etc. and / or any elements thereof perform operations, processes, algorithms, functions, etc. and / or portions thereof, it should be understood that any embodiment described and / or claimed herein contemplates any apparatus, system, device, etc. and / or any element thereof being configured to perform any operation, process, algorithm, function, etc. and / or portion thereof. [Brief explanation of the drawings]

[0005] A more detailed understanding may be had from the following detailed description, taken by way of example in conjunction with the accompanying drawings. The figures in such drawings, like the detailed description, are examples. Therefore, the figures and detailed description should not be considered limiting, as other equally effective examples are possible and likely. Furthermore, like reference numerals ("references") in the figures indicate like elements. [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] 1B is a system diagram illustrating an example WTRU that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C]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 illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2] 1 shows the format of an exemplary HE SU PPDU. [Figure 3] 1 shows the format of an exemplary HE MU PPDU. [Figure 4] 1 shows the format of an exemplary HE ER SU PPDU. [Figure 5] 1 shows an exemplary HE TB PPDU format. [Figure 6] 1 illustrates the structure of an exemplary EHT PPDU preamble. [Figure 7] 1 illustrates an exemplary data scrambler. [Figure 8] 10 illustrates an exemplary HE PPDU padding process in the last OFDM symbol (non-STBC). [Figure 9] 1 illustrates an exemplary procedure for performing LDPC encoding based on individual MPDUs within an A-MPDU frame. [Figure 10] 1 illustrates an exemplary procedure for performing LDPC encoding based on an MPDU having a maximum length (size) among MPDUs in an A-MPDU frame. [Figure 11] 1 illustrates an exemplary procedure for performing boundary alignment of MPDUs and CWs (information blocks) by using PHY layer padding. [Figure 12] 1 shows an example of LDPC codeword (information block) length selection using boundary alignment coding procedures for MPDU and CW. [Figure 13] 1 shows an exemplary flow diagram of the method of the present disclosure. [Figure 14] 10 illustrates an exemplary HARQ sequence number provided by a receiver Rx. [Figure 15] This shows an example in which the order of the FEC and scrambler in the transmitter Tx is reversed. [Figure 16] 1 shows an example in which the order of the FEC and scrambler in the receiver Rx is reversed. [Figure 17] 1 shows an exemplary L-SIG field length. [Figure 18] 1 illustrates exemplary HE-SIG-A fields of different PPDUs. DETAILED DESCRIPTION OF THE INVENTION

[0006] A detailed description of illustrative embodiments will now be described with reference to various figures. While the description provides detailed examples of possible implementations, it should be noted that the details are intended to be illustrative and in no way limit the scope of the present application. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, embodiments and other examples explicitly, implicitly, and / or inherently described, disclosed, or otherwise provided herein (collectively "provided").

[0007] 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may 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 DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0008] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0009] The communications 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 communications networks, such as the CN 106 / 115, 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, a Home Node B, a Home eNodeB, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0010] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive radio 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 wireless service coverage for 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, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

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

[0012] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114 a and the WTRUs 102 a, 102 b, 102 c in the RAN 104 / 113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communications 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 Packet Access (HSUPA).

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

[0014] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).

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

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

[0017] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a location such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, 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 embodiment, 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 yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-APro, 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 need to access the Internet 110 through the CN 106 / 115.

[0018] The RAN 104 / 113 may communicate with the CN 106 / 115, 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 various 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 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0019] The CN 106 / 115 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 public 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 the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. The network 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 / 113 or a different RAT.

[0020] 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 that can use cellular-based wireless technology and a base station 114b that can use IEEE 802 wireless technology.

[0021] 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 understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0022] 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 associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, 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. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0025] The transceiver 120 may be configured to modulate signals 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.

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

[0027] 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 providing power to the WTRU 102. For example, the power source 134 may include one or more dry batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

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

[0029] 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 modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction 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, and / or a humidity sensor.

[0030] 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 downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and or substantially eliminating self-interference through either hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of either some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or downlink (e.g., for reception)).

[0031] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As mentioned above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

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

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

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

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

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

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

[0038] 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. Furthermore, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

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

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

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

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

[0043] High Throughput (HT) STAs may, for example, use 40 MHz wide channels for communication via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

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

[0045] 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 compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter-type control / machine-type communications, such as MTC devices within macro coverage areas. MTC devices may have limited capabilities, including, for example, support for (e.g., only for) specific and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0046] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STA among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah example, the primary channel can 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) configuration can depend on the conditions of the primary channel. For example, if the primary channel is busy due to a STA (that only supports 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and be available for use.

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

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

[0049] The RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may, for example, transmit wireless signals to and / or receive wireless signals from the WTRU 102a using multiple antennas. In one embodiment, the gNBs 180a, 180b, and 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, and the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0050] 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 different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

[0051] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNode-Bs 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. The non-standalone configured WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0052] 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, dual connectivity, 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 via an Xn interface.

[0053] 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. While each of the foregoing elements is shown as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0054] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of the SMF 183a, 183b for registration, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0055] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 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 WTRU / UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0056] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 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 downlink packets, providing mobility anchoring, etc.

[0057] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (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.

[0058] 1A-1D 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, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-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 simulate network and / or WTRU functions.

[0059] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or 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 communication network to test other devices in the communication 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 communication network. The emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial wireless communication.

[0060] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0061] The examples provided herein do not limit the applicability of the subject matter to other wireless technologies that may use the same or different principles as may be applied, for example.

[0062] As described herein, a wireless transmit / receive unit (WTRU) may be an example of user equipment (UE). Accordingly, the terms UE and WTRU may be used interchangeably herein. Furthermore, when used in a WLAN environment where wireless technologies such as IEEE 802.11 are used, a UE may also be referred to as a station (STA).

[0063] WLAN System Overview A WLAN in Infrastructure Basic Service Set (BSS) mode has an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP typically has access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating from outside the BSS to a STA arrives via the AP and is delivered to the STA. Traffic from a STA to a destination outside the BSS is sent to the AP and delivered to the respective destination. Traffic between STAs within the BSS may be transmitted via the AP, with the source STA sending traffic to the AP and the AP delivering the traffic to the destination STA.

[0064] The IEEE 802.11ac infrastructure mode of operation allows an AP to transmit beacons on a fixed channel (usually the primary channel). This channel can be 20 MHz wide and is the operating channel of the BSS. This channel is also used by STAs to establish connections with the AP. The basic channel access mechanism in IEEE 802.11 systems is Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA). In this mode of operation, all STAs, including the AP, sense the primary channel. If the channel is detected to be busy, the STAs back off. Therefore, only one STA may transmit at any given time in a given BSS.

[0065] IEEE 802.11n also allows High Throughput (HT) STAs to use 40 MHz wide channels for communication, which is achieved by bonding the primary 20 MHz channel with adjacent 20 MHz channels to form a 40 MHz wide contiguous channel.

[0066] In IEEE 802.11ac, Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and 160 MHz wide channels. The 40 MHz and 80 MHz channels are formed by combining contiguous 20 MHz channels, as in IEEE 802.11n. A 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or two non-contiguous 80 MHz channels (also known as an 80+80 configuration). In the 80+80 configuration, after channel coding, the data passes through a segment parser and is split into two streams. Inverse Fast Fourier Transform (IFFT) and time-domain processing are performed separately for each stream. The streams are then mapped to two channels, and the data is transmitted. At the receiver, this mechanism is reversed, and the combined data is transmitted to the MAC.

[0067] To improve spectral efficiency, IEEE 802.11ac introduces the concept of downlink multi-user multiple input multiple output (MU-MIMO) transmission to multiple STAs in the same symbol time slot, such as during a downlink orthogonal frequency-division multiplexing (OFDM) symbol. The potential use of downlink MU-MIMO is also currently being considered for IEEE 802.11ah. It is important to note that downlink MU-MIMO is not an issue when used in IEEE 802.11ac because it uses the same symbol timing for waveform transmissions to multiple STAs, making multi-STA interference a non-issue. However, all STAs involved in MU-MIMO transmission with the AP must use the same channel or band, which limits the operating bandwidth to the smallest channel bandwidth supported by the STAs involved in the MU-MIMO transmission with the AP.

[0068] IEEE 802.11ax Physical Layer Protocol Data Unit (PPDU) IEEE 802.11ax defines physical and medium access control layer specifications that enable high-efficiency (HE) operation of IEEE 802.11 devices. IEEE 802.11ax is considered the next major generation of Wi-Fi after IEEE 802.11ac. IEEE 802.11ax defines a new numerology with smaller subcarrier spacing. IEEE 802.11ax introduces downlink / uplink (DL / UL) OFDMA to achieve better spectrum efficiency.

[0069] IEEE 802.11ax supports four PPDU formats: a. High Efficiency Single User PPDU (HE SU PPDU): This PPDU format is used for single-user transmission. See Figure 2 for the format of the HE SU PPDU. b. High Efficiency Multi-User PPDU (HE MU PPDU): This PPDU format is used for transmission to one or more users when the PPDU is not a response to a trigger frame. The High Efficiency Signal Field-B (HE-SIG-B) field is shown in the PPDU format in Figure 3. c. High Efficiency Extended Range Single User PPDU (HE ER SU PPDU): This PPDU format is used for SU transmission with extended range. In this format, the HE-SIG-A field is twice as long as the High Efficiency Signal Field-A (HE-SIG-A) field in other HE PPDU formats. See Figure 4 for the HE ER SU PPDU format. d. High Efficiency Trigger-Based PPDU (HE TB PPDU): This PPDU format is used for transmissions that are a response to a trigger frame from the AP or a frame carrying a Triggered Response Scheduling (TRS) control subfield. The High Efficiency- Short Training Field (HE-STF) field of the HE TB PPDU has a duration of 8 μs, which is twice the size of the HE-STF field in other HE PPDU formats. See Figure 5 for the format of the HE TB PPDU.

[0070] The Legacy Signal (L-SIG), HE-SIG-A, and HE-SIG-B fields carry the physical (PHY) layer control information of the PPDU. The L-SIG field has legacy numerology and format so that all STAs can recognize the L-SIG field. The HE-SIG-A and HE-SIG-B fields are recognized by HE STAs. The L-SIG fields are shown in Table 1. The HE-SIG-A fields for different PPDU formats are shown in Table 2.

[0071] IEEE 802.11be PPDU Design The IEEE Standards Committee approved the IEEE 802.11be Task Group (TG) based on the Project Authorization Request (PAR) and Criteria for Standards Development (CSD) developed by the Extremely High Throughput Study Group (EHT SG).

[0072] SIG Field The IEEE 802.11be Task Group (TGbe) agreed that the Very High Throughput (EHT) PPDU should have a preamble structure as shown in Figure 6. The Universal Signal field (U-SIG) contains version-independent and version-dependent bits. The bits in the version-independent field have static positions and bit definitions across different generations / PHY versions. The version-independent bits can include the PHY version identifier, UL / DL flag, BSS color, and transmit opportunity (TXOP) (duration, bandwidth information, etc.). The version-dependent bits can include the PPDU type. In combination with the EHT-SIG common fields, the version-dependent fields can also include the modulation and coding scheme (MCS), number of space-time streams, guard interval + extreme high throughput + long training field (GI + EHT-LTF) side, coding, etc. User-specific fields can be used in MU configuration. IEEE 802.11be does not have separate PPDU formats for SUs and MUs, but can have a single PPDU format for both SUs and MUs.

[0073] Objective / challenge statement Objective / Task 1: MAC Protocol Data Unit (MPDU) and Codeword (CW) Alignment To enable the HARQ mechanism, the hybrid automatic repeat request (HARQ) retransmission unit and acknowledgment unit must be clearly defined. In current standards, a frame check sequence (FCS) is inserted at the end of a MAC layer frame (i.e., MPDU). STAs can check the FCS to determine whether the MPDU was received correctly and respond with an acknowledgment. MPDUs can be aggregated at the MAC layer and passed to the PHY layer. In currently available designs, the PHY layer can perform channel coding without recognizing MPDU boundaries. However, HARQ combining may be based on a codeword (CW), which depends on the PHY layer's channel coding procedure. Therefore, the MPDU and the codeword are not aligned, which can cause problems with HARQ retransmission and acknowledgment.

[0074] Objective / Task 2: Identification of scramblers and failed sections The IEEE 802.11ax data field scrambler and procedure is shown in Figure 7. The PHY layer operation including the scrambler is shown in Figure 8. Scrambling is performed before forward error correction (FEC) processing.

[0075] For Aggregated MAC Protocol Data Units (A-MPDUs), scrambling is performed using a 7-bit seed, and the bit sequence used to scramble the MPDU (the scrambling sequence) depends on the position of the MPDU within the A-MPDU. This is the scrambler state x when the first bit of the MPDU is shifted into the scrambler. 1 ,...,x 7 is determined by.

[0076] For the first HARQ transmission, the receiver can descramble the FEC decoder output bits based on the SERVICE field and the offset d (in bits) from the beginning of the A-MPDU, extract the MPDU, and perform an FCS check. However, for receiving an HARQ retransmission, the receiver cannot descramble the FEC output bits (after HARQ combining processing) unless it remembers the scrambler state associated with the FEC output, which is derived from the offset d of the original A-MPDU and the scrambler seed.

[0077] Signaling is required to allow the receiver to reconstruct the scrambling sequence that was used to scramble the section of uncoded bits of the original A-MPDU.

[0078] For non-HARQ reception, the size of the buffer for log-likelihood ratio (LLR) soft bits is related to the CW size (e.g., several CWs). For HARQ reception, the buffer size needs to be increased to accommodate multiple failed CWs within one or more A-MPDUs. It may be impossible to design an HARQ buffer large enough to handle the maximum length (size) of an A-MPDU. It is estimated that only 13–26% of the CWs require storage, so the HARQ buffer does not need to be sized to handle the worst case.

[0079] There are two ways for the transmitter to associate the HARQ retransmission section with the position of the original A-MPDU. 1. Method based on section position (offset d, e.g., byte position, CW position) of original A-MPDU: In this case, the receiver would need to remember the d of the failed section and the scrambling seed of the A-MPDU or the scrambler state at the beginning of the failed section. For retransmissions, the transmitter needs to signal the location of the retransmitted section within the original A-MPDU, which allows

number

number

[0080] Note that for Method 2 above, the receiver does not need to keep track of the location of the failed section in the original A-MPDU. If the receiver does not maintain the scrambler state, the transmitter needs to signal the scrambler state (or position d + initial scrambler seed) for each retransmitted section.

[0081] The above method describes how the transmitter identifies the relationship between the retransmitted data and the original transmission (based on the offset of the original A-MPDU or a number specified by the receiver). However, the receiver's HARQ feedback in Method 1, which can only feedback correctly received MPDUs, has already been proposed. In such a case, the transmitter does not know whether the receiver has allocated an LLR buffer to store the LLRs of the section containing the missing MPDU. When the transmitter performs a retransmission, if the receiver has not buffered the LLRs, self-decodable retransmission is preferable. Such a method has already been proposed. The MCS of the retransmissions can potentially be independent. However, the retransmissions must use the same scrambler seed as the first transmission, which needs to be signaled separately for each retransmitted section.

[0082] In either of the above methods, it is desirable to reduce the state information that needs to be maintained by the receiver, so that the receiver does not need to maintain scrambler state information, and optionally enable self-decodable retransmissions. It is also desirable to reduce signaling overhead, so that the transmitter signals only one (initial) scrambler state that can be used in all retransmitted HARQ sections or additional new MPDUs in retransmitted A-MPDUs.

[0083] Objective / Task 3: HARQ buffer status For HARQ transmissions, HARQ buffers are required at both the transmitter and receiver sides. It is important for the HARQ source to know whether a failed transmission was buffered at the receiver side so that it can plan retransmissions. For example, if a failed transmission was not buffered, the source can retransmit a self-decodable version. A mechanism and method should be provided for the HARQ source to know the status of the receiver's buffer.

[0084] Proposed Solution Embodiment 1: MAC Protocol Data Unit (MPDU) and Codeword (CW) Alignment The usefulness of the methods disclosed herein need not be limited to a particular layer of a wireless device. Thus, structures such as MPDU and A-MPDU can be considered as a protocol data unit and a frame of multiple PDUs, respectively. In the following description, example embodiments including MPDU and A-MPDU are used as concrete examples, but the concepts need not be limited to such particular layers. The methods and procedures disclosed herein can be used to address Objective / Problem 1. In this embodiment, several methods are disclosed for aligning MPDU boundaries with codeword boundaries.

[0085] Assume that an aggregated MPDU (A-MPDU) is passed from the MAC layer to the PHY layer, where multiple codewords may be introduced by the encoding procedure. To align the MPDU and CW boundaries, one or more of the following changes may be required to the IEEE 802.11 parameters: a. The TXVECTOR parameter can include the MPDU length (size) in the A-MPDU frame. The TXVECTOR parameter is an internal vector passed from the MAC layer to the PHY layer within the device. This vector sets the PHY layer parameters necessary to enable PPDU transmission. In the method herein, the TXVECTOR parameter includes not only the A-MPDU length but also the length (size) of each individual MPDU. b. The HARQ SIG can include the length (size) of the MPDU so that the RXVECTOR parameter can set the MPDU length (size) value appropriately. The RXVECTOR parameter is an internal vector passed from the physical layer to the MAC layer within the device. This vector conveys information about the received PPDU parameters. In the method herein, the RXVECTOR parameter includes not only the A-MPDU length but also the length (size) of each individual MPDU.

[0086] In the above procedure, the length or size of the MPDU is mentioned. However, this may be replaced by the length or size of the HARQ unit. The HARQ unit may refer to a unit for retransmission and / or acknowledgment, such as an MPDU. Note that the MPDU_length is expressed in bytes.

[0087] Method I In this method, an MPDU can be used as a unit to which an information block can be applied. In one example, the MPDU is the unit used to perform a low-density parity-check (LDPC) encoding procedure, which can be repeated for all MPDUs in the A-MPDU. In this way, each MPDU can have its own information block length, e.g., LDPC codeword length (CW length or information block length). As used herein, the term codeword is synonymous with information block.

[0088] An exemplary procedure for single user (SU) transmission is shown below. See Figure 9 for an example. In Figure 9, three MPDUs have three different lengths or sizes. MPDU1, denoted as 902, has length 1, MPDU2, denoted as 904, has length 2, and MPDU3, denoted as MPDU3, has length 3. The procedure for Method 1 includes: For the akth MPDU, calculate the initial number of OFDM symbols in the MPDU using the following formula: k is used as an alternative to the Aggregation MAC Protocol Data Unit (A-MPDU) Padding Before End of Frame (EOF) (APEP)_length described in the published technology of "IEEE P802.11ax (registered trademark) / D3.0, Amendment 6: Enhancements for High Efficiency WLAN (2018)." In the above-mentioned D3.0 Amendment 6, MPDU_Length k is used to replace APEP_length.

number

[0089] In this method, each MPDU may use an integer number of OFDM symbols. The boundaries of different MPDUs may align with the boundaries of CWs and OFDM symbols. The MPDU delimiters defined in the A-MPDU frame may be omitted, and some signaling may be shifted to PHY layer signaling.

[0090] The PHY layer signaling may be modified to include one or more of the following subfields: a. More LDPC Extra Symbol Segment fields can be carried, each associated with an MPDU. In one approach, one LDPC Extra Symbol Segment field can be included in a mandatory SIG field (e.g., U-SIG field or EHT SIG field). The remaining LDPC Extra Symbol Segment fields can be carried in Extra SIG fields. These parameters can optionally be included in the TXVECTOR parameter. b. More Pre-FEC Padding Factor fields can be conveyed, each associated with an MPDU. In other words, each MPDU can have an integer number of OFDM symbols. At the end of each MPDU, packet extension (packet bit padding) for HARQ implementation can be applied. The Pre-FEC Padding Factor field of that MPDU can indicate the packet extension (packet bit padding) of that MPDU. In one method, one additional Pre-FEC Padding Factor field can be included in a mandatory SIG field (e.g., U-SIG field or EHT SIG field). The additional Pre-FEC Padding Factor field can be conveyed in an Extra SIG field. Note that this field enables packet extension (packet bit padding) per MPDU and can apply to both LDPC and Block Convolution Code (BCC). These parameters can optionally be included in the TXVECTOR parameters.

[0091] Method II In this method, the MPDU with the longest length or size among the MPDUs in the A-MPDU can be used as the unit length or size for calculating the information block. In one example, the size of the MPDU can be used as the unit size for calculating the LDPC error correction parameters. The maximum length or size of all MPDUs in the A-MPDU can be denoted as MPDU_max_length. The remaining MPDUs can be padded to MPDU_max_length. The illustrated LDPC error correction coding procedure can be repeated for all MPDUs in the A-MPDU. In this way, each MPDU can have the same information block length (e.g., LDPC codeword length (CW length)).

[0092] An example is shown in Figure 10. An A-MPDU can contain three MPDUs of various sizes or lengths. MPDU1, denoted as 1002, has length 1, MPDU2, denoted as 1004, has length 2, and MPDU3, denoted as 1006, has length 3. MPDU3 may have the largest length. The MAC layer can add bit padding 1008 to MPDU1 and bit padding 1010 to MPDU2. Bit padding is added to each MPDU so that the length or size of the MPDU plus the bit padding equals MPDU_max_length (i.e., the size or length of MPDU3). The MPDUs and their respective bit padding are then passed to the PHY layer. In the PHY, the LDPC error correction coding procedure can be performed based on the MPDU_max_length as shown in Method I. Padding information, such as the padding length and the MPDU length before padding, can be signaled in the MAC header or PHY header, or in a delimiter before each MPDU.

[0093] If multi-user (MU) transmission can be used, the procedure can be as shown below. a. An AP (or other type of STA capable of transmitting to one or more STAs) can schedule MU transmissions to M users, and each user can prepare an A-MPDU. MPDU_length is used to represent the MPDU length of the mth user and the kth MPDU. mk is used. The ranges of m=1,...,M and k can be user dependent. b. The AP receives all MPDU_length mk , and find the MPDU_max_length among all users. c. The AP pads each MPDU to MPDU_max_length and can signal the original MPDU length or the padding length in the MAC header, PHY header, or delimiter within the A-MPDU frame. d. For user m, the AP may perform the LDPC error correction coding procedure on each MPDU as described in Method I.

[0094] In one method, the padding described above can be performed before end-of-frame (EOF) padding. In one method, the padding can be performed together with MAC padding, such as pre-EOF padding, such that MPDU_length refers to the length of the MPDU before EOF padding and before the padding procedure defined herein.

[0095] Method III In this method, the total length of the A-MPDU, i.e., APEP_length, can be used as the unit for calculating the LDPC error correction parameters. The calculation can follow the LDPC encoding procedure defined in the D3.0 Amendment 6 mentioned above. The LDPC codeword length L LDPC and the number of initial LDPC code words N CW0Based on the codeword boundaries, a PHY layer aligned padding can be performed along with a shortening procedure so that the boundaries of the information blocks or CWs are aligned with the MPDU boundaries. An LDPC encoding procedure can be performed on the aligned padded information bits.

[0096] Figure 11 illustrates an example of the use of Method III. In the example of Figure 11, MPDUs have different sizes (lengths). MPDU1, shown as 1102, has an initial length of 1, MPDU2, shown as 1104, has an initial length of 2, and MPDU3, shown as 1104, has an initial length of 3. The original information blocks, represented as codewords (CWs), associated with these three MPDUs are shown as 1120. Bit padding can be performed on each MPDU. Bit padding 1112 can be performed on MPDU1, bit padding 1114 can be performed on MPDU2, and bit padding 1116 can be performed on MPDU3. As an example result, a group 1122 of three information blocks or CWs may result in representing MPDU1+padding 1112, a second group 1124 of two information blocks or CWs may result in representing MPDU2+padding 1114, and a third group 1126 of four information blocks or CWs may result in representing MPDU3+padding 1116. Note that the various MPDUs are padded to correspond (align) with the boundaries of the information blocks (CWs).

[0097] An exemplary aligned padding procedure for SU transmission is shown below (assuming K MPDUs in an A-MPDU). 1. Calculate the initial number of OFDM symbols in the PPDU using the APEP_length given in D3.0 Amendment 6 mentioned above. 2. According to the calculation shown in the above-mentioned D3.0 revised 6th edition, one LDPC code word length L LDPC and encode the initial number of LDPC codewords as N CW,0 The information bit length of each LDPC codeword is R·LLDPC and R is the coding rate. 3.MPDU_length k For the k-th MPDU (k=1,...,K) having , the number of LDPC codewords in the MPDU is calculated. a.

number

number

number

number

number

number

[0098] For multi-user (MU) transmission, the following procedure can be used: For every user, calculate the following per-user parameters according to the procedure defined in steps 1-7 above: a. Initial number of OFDM symbols per user N SYS,init,u

[0099] Find the user with the longest coded packet duration and set the user value as N SYS,init and a init (following the procedure defined in D3.0 Amendment 6 mentioned above).

[0100] For the last MPDU of all users, N SYS,init and a init to perform bit padding and shortening as described in steps 8-11 above.

[0101] According to the above mentioned D3.0 revised 6th edition, SYM and coefficients are calculated to continue the encoding procedure.

[0102] Information block / codeword length selection This method allows for the selection of an information block length, such as an LDPC error correction code word length. FIG. 12 shows an example of information block (e.g., LDPC code word length) selection using a boundary-aligned encoding procedure for an MPDU and information block (CW). In this example using an LDPC example, three different LDPC code word lengths (information block lengths) are used. Predefined / predetermined code word length selection criteria can be set. For example, an information block length (code word length) that minimizes the number of boundary-aligned padding / shortening bits for the MPDU and CW can be selected. After the code word length selection, the encoding procedure can be performed as shown in the method described above.

[0103] Three different MPDU sizes are shown in Figure 12. MPDU1, designated 1202, has an initial length of 1, MPDU2, designated 1204, has an initial length of 2, and MPDU3, designated 1204, has an initial length of 3. Three different sets of information block (CW) lengths are also shown. A first CW set 1240 can be compared to a second CW set 1260 and a third CW set 1280. Each CW set has a different length and number of information blocks (CWs). In one example, the length of each CW in CW set 1280 is selected as the basis for determining additional bit padding to apply to each MPDU. Bit padding 1212 can be applied to MPDU1, bit padding 1214 can be applied to MPDU2, and bit padding 1216 can be applied to MPDU3. As an example result, a group 1222 of three CWs may result in representing MPDU1+padding 1212, a second group 1224 of three CWs may result in representing MPDU2+padding 1214, and a third group 1226 of four CWs may result in representing MPDU3+padding 1216.

[0104] How to minimize the number of bits of alignment padding 1. Possible LDPC codeword length L LDPC,m Check all m=1,...,M (M is the number of possible LDPC codeword lengths defined) and calculate the number of LDPC codewords in the k-th MPDU. a.

number

number

[0105] The concepts and features of the first embodiment described above as Method I, Method II, Method III, and codeword length selection can be combined to construct an A-MPDU having one or more padded MPDU sizes that match the unit of information block length. Furthermore, the above concepts can be applied layer-agnostic. That is, the information block (codeword) length can be selected, the size of the data block unit (protocol data unit) can be determined, and the alignment of the data unit size with a multiple of the information block length can be applied regardless of the specific structural layer. Therefore, the protocol data unit (PDU)-sized data units can be used in the above methods to construct multiple PDUs within a frame of PDUs to be transmitted. Figure 13 illustrates an example of a method for matching the size of a PDU within a constructed frame of multiple PDUs to the length of a corresponding information block of an error correction code for wireless transmission.

[0106] In FIG. 13 , at 1305, a wireless device, such as a wireless station (STA) or access point (AP), may determine an information block length corresponding to an error correction code. As described above, the information block length may also be referred to as a codeword length. The information block may be used to encode parameters of the error correction code. At 1310, the wireless device may insert padding bits into at least one of the PDUs of a frame of multiple PDUs to align the padded PDU size with an integer multiple of the determined information block length. For example, as shown in the example of FIG. 11 , padding bits 1112 may be added / appended / concatenated to a first PDU (e.g., MPDU1) to correspond to the information block length (codeword length). In the example of FIG. 11 , padding bits 1112 are added to the first PDU to correspond to an integer multiple of CW 1112. In the example of FIG. 11 , the integer multiple of CW is 3 at 1122. However, the padding bits added to the PDU may result in other integer multiples of CW. This act of inserting padding bits essentially matches the padded PDU size to be the size of an integer number of information block lengths (CW length).

[0107] Returning to FIG. 13 , at 1315, the operation at 1310 of aligning the PDU size to an integer multiple of the CW length may be repeated or continued as needed for the remaining PDUs in the frame of multiple PDUs. Thus, each PDU size in the frame of multiple PDUs may be similarly aligned to an integer multiple of the determined information block length. For example, in FIG. 11 , the next PDU (e.g., MPDU 2) may be padded with bits 1114 to generate a PDU size of an integer number (two CWs, as in 1124). Similar padding with bits 1116 may be applied to the next PDU (e.g., MPDU 3) as needed to align the next PDU size (e.g., the size of MPDU 3) to an integer multiple of the CW. In the example of FIG. 11 , the size of the next PDU (e.g., MPDU 3) and padding bits 1116 are aligned to a length of four CWs, as in 1126. Note that the operations at 1310 and 1315 may be considered a single boundary alignment process or a multi-step boundary alignment process. It is possible that one or more PDUs within the constructed (resulting) frame of multiple PDUs to be transmitted (such as the A-MPDU to be transmitted) do not require padding bits to align to an integer number of information blocks.

[0108] Returning to FIG. 13 , at 1320, the wireless device may optionally signal, if applicable, the size of each PDU in the constructed frame of the PDU to be transmitted to different structural layers within the wireless device. For example, this signaling may be transferred in a parameter from the medium access control layer to the physical layer within the wireless device. Thus, the wireless device may appropriately use a mechanism to prepare the transmission of the constructed frame of PDUs by indicating the size of each resulting PDU in the constructed frame of multiple PDUs. The size of each resulting PDU in the transmitted constructed frame (padded PDU size) is the sum of the original PDU length and any padding bits (i.e., padding bits added as needed) to match the length of the entire information block, as described above. In some examples, padding bits may not be required so that the original PDU length is equal to the information block / codeword length to be used in the transmitted frame.

[0109] 13, at 1325, the wireless device may transmit the constructed frame (e.g., A-MPDU frame) of multiple PDUs encoded with an error correcting code having the determined information block length to a wireless receiver. This operation is used by the wireless device to communicate the constructed multi-PDU frame to a wireless receiver on a network, such as an IEEE 802.11 or another standards-based wireless network. The transmitted information may include not only the constructed multi-PDU frame but also associated information blocks (codewords) that can be used by the receiver to error correct received PDUs in the constructed and transmitted multi-PDU frame.

[0110] In one embodiment, the information block length corresponds to a length used as a unit length of a low-density parity-check code of the error-correcting code. The information block length may be a single information block length for constructing each PDU size within the constructed frame of multiple PDUs. In one specific example, inserting padding bits into at least one PDU may result in each PDU within the constructed frame of PDUs being of equal size. In one specific example embodiment, inserting padding bits into at least one PDU of the multiple PDUs may include inserting padding bits into at least one MPDU within the A-MPDU frame.

[0111] In one embodiment, signaling of each PDU size in the constructed frame of the PDU can be performed in a parameter signaled from one layer to another layer in the wireless device. In one example, signaling of each PDU size in the constructed frame of the PDU can be signaled from the MAC layer to the PHY layer in the wireless device and can be achieved using a TXVECTOR parameter. In one embodiment, the wireless device in the method of FIG. 13 can transmit a constructed frame of a PDU encoded with an error correcting code, such as an LDPC code, to a receiver on the same network as the wireless device by signaling each PDU size in the constructed frame of the PDU in the preamble of the wireless transmission. In another embodiment, wireless transmission of the multi-PDU frame encoded with an error correcting code to the receiver can be achieved by also using an Extra Symbol Segment field in the preamble of the wireless transmission. The Extra Symbol Segment field can be a low-density parity check Extra Symbol Segment field. In another embodiment, transmitting the constructed frame of PDUs encoded with error correction codes to the receiver can be accomplished by also transmitting a pre-forward error correction padding factor field in the preamble of the wireless transmission. Note that the wireless transmission of the constructed frame of PDUs can be accomplished using a STA or an AP in the wireless communication system.

[0112] Embodiment 2: Scrambler and failed section identification The methods and procedures disclosed herein may be used to address Objective / Problem 2. As noted above, the usefulness of the methods disclosed herein need not be limited to a particular layer of a wireless device. Thus, structures such as MPDU and A-MPDU can be considered as a protocol data unit and a frame of multiple PDUs, respectively. In the following description, example embodiments including MPDU and A-MPDU are used as concrete examples, but the concepts need not be limited to a particular layer.

[0113] The information block referred to as CW in the following section can also be a group of CWs (CW group), where each group is a unit for feedback and retransmission. Each CW or CW group can have an additional CRC to verify the correctness of the received bits.

[0114] The purpose / problem statement identifies two methods for the transmitter / receiver to identify failed sections in feedback and retransmission: the first method is based on the offset d in the original A-MPDU, and the second method is based on an identifier (HARQ sequence number) specified by the receiver, with a numbering space proportional to the HARQ buffer size.

[0115] The first method requires signaling the identity of the original MPDU and the offset d in the retransmission. The second method (in the absence of feedback, the transmitter backs off and retransmits the original A-MPDU) signals the HARQ sequence number in the retransmission, from which the receiver derives the context (e.g., scrambler state, pointer to the HARQ buffer, CW size, decoded bits not assembled into MPDUs before and after the CW associated with the HARQ sequence number).

[0116] An example is shown in Figure 14 to explain the second method. Figure 14 shows an example of HARQ sequence numbers provided by the receiver (Rx). This method does not rely on MPDU and information block (CW) boundary alignment, but for generality, it is described as an example where they are not aligned. In this example, in the first HARQ transmission 1402, CW1, CW2, CW3, CW5, CW6, CW7, CW9, and CW11 are decoded. Traffic identifier x (TID x) and MPDU N are associated with portions of CW1, CW2, and CW3. TID y and MPDU M are associated with portions of CW6 and CW7. TID z and MPDU L are associated with portion of CW9. The receiver assembles MPDU N, MPDU M, and MPDU L using each decoded CW and reflects this in a block acknowledgement (BA) 1405 to the transmitter. BA 1405 is shown in Figure 14 as feedback 1404 associated with the first HARQ transmission 1402. BA 1405 is a bitmap for acknowledgment of MPDUs.

[0117] In feedback 1404, the receiver adds a HARQ bitmap 1406 for CWs, where each bit is associated with a CW that is not associated with any of the successfully received MPDUs (i.e., MPDU N, MPDU M, MPDU L), except (optionally) for a CW where both the preceding and following CWs are occupied by successfully received MPDUs (e.g., CW8). For example, CW8 does not have a corresponding bit in the HARQ bitmap 1306 because it lies between two successfully received MPDUs (MPDU M and MPDU L).

[0118] The receiver identifies a starting HARQ sequence number h 1407 before the HARQ bitmap 1406. In the above example, the failed CWs (CW4, CW8, CW10) are assigned HARQ sequence numbers h, h+1, and h+2 by the receiver, respectively. See items 1410, 1411, and 1412, respectively. Successful CWs, such as CW5 and CW11, but not occupied by successful MPDUs (shown as 1414 without a HARQ sequence number in Figure 14), are not identified by a HARQ sequence number, but the decoded bits are stored locally at the receiver for reassembly. For successful CWs partially occupied by successful MPDUs, such as CW3, CW6, CW7, and CW9, the bits in the HARQ CW bitmap are not associated with the successful MPDUs but are stored locally before or after the CW-related bits in the HARQ CW bitmap to link to the CW (either the locally stored information bits from the successful CW or the failed CW with the HARQ sequence number). In the HARQ CW bitmap 1406, the notations "N" and "Y" stand for No and Yes and simply indicate the acknowledgment of the CW. In practice, other notations, such as digital notations, may be used. There are two sets of acknowledgments in the feedback 1404. The first set is the MPDU-level acknowledgment (bitmap of MPDUs 1405), and the second set is the CW-level acknowledgment (bitmap of CWs 1406). For the MPDU-level acknowledgment, the conventional IEEE 802.11 BA mechanism and format can be used. CW-level acknowledgment 1406 carries acknowledgment of CWs not covered by successful MPDU-level acknowledgment. The HARQ initiator / transmitter can identify failed CWs by receiving HARQ feedback 1404. In this example, the failed CWs are CW4, CW8, and CW10. The HARQ initiator / transmitter can retransmit the failed CWs and indicate the HARQ sequence number range as [h, h+k], where k+1 is the total number of failed CWs.

[0119] In the HARQ bitmap of CWs 1406, the state of each bit can signal the state of a CW that is not occupied by a successful MPDU, or, in a more compact bitmap, each bit signals the state of a CW that is not occupied by a successful MPDU and that is not the only CW between two CWs that are occupied by successful MPDUs.

[0120] For example, the transmitter knows based on the "MPDU Bitmap" that there is an unsuccessful MPDU between MPDU M and MPDU L, and does not need to signal the status of CW8 in the HARQ Bitmap because CW8 is the only CW between MPDU M and MPDU L. The transmitter can induce the failure of the CW without explicit signaling.

[0121] In the above example, the HARQ bitmap identifies the status of CW4, CW5, CW10, and CW11. The transmitter understands that the first bit in the HARQ bitmap 1406 is associated with CW4 because it is the first CW not occupied by a successful MPDU (identified in "Bitmap of MPDUs" 1405 in the BA of feedback 1404). The transmitter realizes that the third bit in the HARQ bitmap 1406 identifies CW10 because it is the fourth CW not occupied by a successful MPDU and CW8 precedes CW10, which does not require a bit in the bitmap.

[0122] In the alternative second HARQ transmission 1408 of Figure 14, the transmitter identifies the CW to be retransmitted based on the HARQ sequence numbers h to h+k. The receiver uses the context associated with the HARQ sequence numbers to find the LLRs stored in the HARQ buffer and combine and decode the CW. If successful, the receiver uses the context of the HARQ sequence number to find the bits before or after the CW for reassembly.

[0123] The HARQ bitmap 1406 may signal only the status of the set of CWs that cannot be assembled into an MPDU and for which the receiver has buffered LLRs or decoded partial MPDUs. The receiver may not have the memory capacity to buffer the LLRs of all failed CWs. For unbuffered CWs, they are not identified in the HARQ bitmap 1406. The transmitter identifies and performs HARQ retransmissions for failed MPDUs whose CW positions correspond to CWs explicitly or implicitly identified in the HARQ bitmap 1406. For failed MPDUs whose CW positions do not correspond to CWs explicitly or implicitly identified by the HARQ bitmap 1406, the transmitter may not perform HARQ retransmissions. In this case, the bitmap may represent the status of a subset of all CWs that do not contain successfully decoded MPDUs, denoted as a truncated bitmap. Signaling can be provided in the feedback to indicate the CW positions within the PPDU in the truncated bitmap. For example, the bitmap has only two bits corresponding to CW10 and CW11. The signaling in the feedback indicates the start of the bitmap as CW10 and its length is 2. The transmitter interprets CWs that are not explicitly signaled by this shortened bitmap (e.g., CW4, CW5, and CW8) as soft bits that are not stored by the receiver for these CWs. For MPDUs contained in these CWs (e.g., CW4, CW5, and CW8) that do not have buffered soft bits, the transmitter can perform HARQ retransmission of the MPDU instead of performing HARQ retransmission of the CW. There may be multiple shortened bitmaps in the feedback to represent different portions of the buffered or decoded CWs.

[0124] An alternative to the method in the above paragraph is to send feedback as a Block Acknowledgement (BA). The locations of CWs that do not contain a successful MPDU and are (are not) buffered by the receiver are explicitly signaled along with the BA. For example, the additional signaling could be a bitmap of all CWs in the PPDU, with a bit value set to 1 to indicate that the corresponding CW is not buffered and a bit value set to 0 to indicate that the corresponding CW is decoded or not decoded but buffered. In one alternative, the additional signaling could be a list of CW indices of failed CWs that are not buffered.

[0125] Alternatively, the feedback from the receiver can be a collection of fields, each corresponding to the state of a CW. Each field can have multiple values, such as successful, failed but buffered, or failed and not buffered. For example, for a 2-bit field for CW, "10" can signal that the CW (and the MPDUs therein) have been decoded, "01" can signal that the CW has not been decoded but its soft bits have been buffered for HARQ retransmission combining, and "00" can signal that the CW has not been decoded and its soft bits have not been buffered.

[0126] In the above embodiment, the receiver still needs to keep the scrambler state in the context associated with the failed section / CW.

[0127] FIG. 15 shows two diagrams of data bits from a transmitter Tx and an LDPC output using a scrambling sequence. As shown in FIG. 15, because an LDPC encoder is linear, the order of the scrambler can be reversed. That is, scrambling can occur after encoding and descrambling can occur before decoding. Configuration 1510 of FIG. 15 shows the transmission procedure in the current standard, where the data bits coming from the MAC layer are scrambled first. Because scrambling is a linear operation, it can be expressed as adding the data bits with the scrambling sequence. The scrambling sequence can be generated by passing all 0 bits to the scrambler using a given scrambling seed. The added value, i.e., the scrambled bits, is then input to the LDPC encoder. On the other hand, in configuration 1520 of FIG. 15, the data bits and the scrambling sequence are passed separately to the LDPC encoder, and the addition is performed at the output of the LDPC encoder. These two operations are equivalent in the sense that they generate the same output from the same input (i.e., data bits).

[0128] Based on this property, HARQ retransmissions of a CW / section can be sent using different scrambling sequences without the receiver needing to remember the scrambler state in the original A-MPDU.

[0129] FIG. 16 is a block diagram showing a possible reverse order of FEC and scrambler in the receiver Rx. In FIG. 16, the log-likelihood ratio element n′ (LLRn′) received in the nth HARQ transmission can be pre-descrambled and then combined with the previous LLRs, decoded, and possibly stored in the HARQ buffer. The pre-descrambling is based on the LLRn′ from the soft demapper and the coded scrambling sequence. The coded scrambling sequence is generated by encoding the scrambling sequence, which may use a different seed from the previous HARQ transmission. The pre-descrambling operation can be, for example, an operation of inverting the sign of LLRn′ if the corresponding bit in the coded scrambling sequence is 1.

[0130] Based on the above mechanism, the receiver (Rx) no longer needs to store the scrambler state, and the transmitter can signal a single scrambling seed for the entire retransmission A-MPDU, which may consist of multiple HARQ retransmission sections from different previous A-MPDUs with different scrambler initiations. The single scrambling seed can be signaled in the PPDU header instead of the payload.

[0131] Alternatively, each retransmitted HARQ section can be scrambled based on a scrambling seed derived from the HARQ sequence number or an identifier of the HARQ (re)transmission, in which case the additional overhead of a scrambling seed is not required.

[0132] Alternatively, a scrambling sequence may be applied after the FEC encoder, which makes HARQ retransmissions independent of the scrambling sequence of the original transmission. Furthermore, with the new modification of signaling the network allocation vector (NAV) outside the payload, third-party STAs no longer need to decode unintended PPDUs to observe the NAV. Scrambling after FEC randomizes interference that does not have the processing gain provided by FEC compared to the desired signal.

[0133] Alternatively, the scrambling sequence may be based on the identity of the BSS, possibly in conjunction with other quantities, to construct the final scrambling sequence. Scrambling may be performed before or after FEC encoding.

[0134] Embodiment 3: Buffer-Limited HARQ Transmission HARQ Buffer Negotiation As mentioned above, the usefulness of the methods disclosed herein need not be limited to a particular layer of a wireless device. Therefore, structures such as MPDU and A-MPDU can be considered as a protocol data unit and a frame of multiple PDUs, respectively. In the following description, example embodiments including MPDU and A-MPDU are used as concrete examples, but the concepts need not be limited to a particular layer. In one method, the HARQ sender and the HARQ responder can negotiate the HARQ buffer size prior to HARQ transmission. The negotiation can be capability-based and static. For example, HARQ buffer-related information can be transmitted in a HARQ capability information element at association time.

[0135] In one approach, HARQ buffer negotiation can occur before a HARQ transmission or sequence of HARQ transmissions or a TXOP. For example, HARQ buffer negotiation can be part of an existing Block Acknowledgement negotiation through an add block acknowledgement (ADDBA) request / response frame exchange. In this case, the negotiated HARQ buffer size can be applied to the Block Acknowledgement frame exchange session, or HARQ buffer negotiation can occur before one or more HARQ processes using newly defined control / management frames.

[0136] The HARQ buffer related information may include: a.Buffer size b. Buffer size per traffic ID (TID) c. Sending buffer size and receiving buffer size

[0137] The size may be a quantized value of the actual buffer size available, or several levels of buffer size may be predefined, and the device may indicate a level such that the actual device buffer size is just above the fixed level value.

[0138] HARQ Feedback with Buffer Indication Information It may be difficult for the HARQ source to conclude whether a particular failed HARQ unit is buffered. In this embodiment, buffer indication information may be included in the HARQ feedback so that the HARQ source can perform retransmission appropriately.

[0139] The HARQ receiver / responder may choose not to buffer the received HARQ units if: a. The receiver does not have sufficient capacity to buffer the HARQ units b. The receiver can detect strong collisions or high interference in HARQ units. c. The receiver is able to detect that the received Signal-to-Interference-plus-Noise Ratio (SINR) of the HARQ unit is below a predefined / predetermined threshold.

[0140] In one method, both a HARQ-ACK bitmap and a HARQ buffer indication bitmap can be included in the HARQ feedback / ACK. Both bitmaps can have a fixed length / size. The size of the bitmaps can be predefined, pre-defined, or negotiated. For example, the size can be negotiated when the HARQ session is established between the sender and the responder. The HARQ-ACK bitmap can indicate whether a HARQ unit is successfully decoded. The HARQ buffer indication bitmap can indicate whether a HARQ unit is buffered. For example, the HARQ feedback / ACK can convey acknowledgements for eight HARQ units, where HARQ units 1, 3, and 5 are not successfully decoded and HARQ units 1 and 3 are buffered. In this case, the HARQ-ACK bitmap can be 8 bits long [10101000], and the HARQ buffer indication bitmap can be [10100000].

[0141] In one method, both a HARQ-ACK bitmap and a HARQ buffer indication bitmap can be included in the HARQ feedback / ACK. The HARQ-ACK bitmap can indicate whether an HARQ unit is successfully decoded and can have a fixed length. The size of the HARQ-ACK bitmap can be predefined, pre-defined, or negotiated. For example, the size can be negotiated when an HARQ session is established between the sender and the responder. The HARQ buffer indication bitmap can indicate whether an HARQ unit is buffered. The size of the HARQ buffer indication bitmap can depend on the value of the HARQ-ACK bitmap. For example, the HARQ feedback / ACK can convey acknowledgments for eight HARQ units, where HARQ units 1, 3, and 5 were not successfully decoded and HARQ units 1 and 3 are buffered. In this case, the HARQ-ACK bitmap can be set to 8-bit length [10101000], and the HARQ buffer indication information bitmap can be set to

[0110] corresponding to the failed HARQ unit.

[0142] The source may need to retransmit failed HARQ units (e.g., units 1, 3, and 5 in the example above), but the HARQ unit that cannot be buffered (unit 5 in the example above) may be transmitted in a self-decodable version and / or using a lower MCS, since combining for that unit may not be possible.

[0143] HARQ buffer resolution In this method, the HARQ buffer size may be fixed for the STA, but the STA can select the resolution of the stored values ​​to adjust the HARQ buffer usage. For example, the size of the HARQ buffer may be M bits. The HARQ buffer can be used to store soft-decoded values ​​(i.e., LLRs). If each LLR value uses 8 bits to represent it, the buffer can be used to store M / 8 LLR values. If each LLR value uses 6 bits to represent it, the buffer can be used to store M / 6 LLR values. Different LLR value resolutions can result in different storage capacities for the HARQ unit. In the proposed scheme, the HARQ buffer resolution, along with the HARQ buffer size, can be exchanged between the sender and responder.

[0144] In one method, the HARQ buffer resolution can be part of the HARQ buffer negotiation process introduced in the section "HARQ Buffer Negotiation."

[0145] In one method, multiple resolution levels can be predefined, predefined, or negotiated. The source can indicate that the HARQ transmission should be buffered using one resolution level. The source can calculate and adjust the transmitted packet size based on the receiver's HARQ buffer size and the proposed resolution level. The responder can set the buffer resolution according to the source's instructions. The HARQ buffer resolution can be signaled in a HARQ negotiation frame exchanged before the HARQ transmission, or it can be signaled in the MAC header / PHY header along with the HARQ transmission.

[0146] One method is to allow the responder / receiver to reduce the HARQ buffer resolution and report it to the source. For example, the responder / receiver may fail to detect HARQ unit n and store it at HARQ buffer resolution m. The responder / receiver can report this information to the source in the HARQ feedback.

[0147] In one approach, multiple resolution levels can be predefined, predefined, or negotiated based on QoS parameters, e.g., traffic requiring high reliability can use higher resolution.

[0148] The following documents are included as reference materials and are incorporated by reference as if set forth herein: [1] IEEE Std 802.11(Trademark)-2016: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications [2] "IEEE P802.11ax(TM) / D3.0, Amendment 6: Enhancements for High Efficiency WLAN", 2018

[0149] While features and elements have been provided above in particular combinations, those of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described herein, which are intended as examples of various aspects. It will be apparent to those skilled in the art that many modifications and variations can be made without departing from the spirit and scope of the invention. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly stated as such. Functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is understood that the present disclosure is not limited to any particular method or system.

[0150] The above-described embodiments are described with reference to the terminology and structure of infrared-enabled devices (i.e., infrared emitters and receivers) for simplicity, however, the described embodiments are not limited to these systems and may also be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0151] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the term "video" or "image" may mean either a snapshot, a single image, and / or multiple images displayed over time. As another example, when referred to herein, the terms "user equipment" and its abbreviation "UE," and "remote" may mean or include: (i) a wireless transmit / receive unit (WTRU); (ii) any of multiple embodiments of a WTRU; (iii) a wireless-enabled and / or wired-enabled (e.g., tetherable) device specifically configured to have some or all of the structure and functionality of a WTRU; (iii) a wireless-enabled and / or wired-enabled device configured to have less than all of the structure and functionality of a WTRU; or (iv) others. Details of an exemplary WTRU that may be representative of any WTRU described herein are provided herein in connection with FIGS. 1A-1D.

[0152] Additionally, the methods provided 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 electronic 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). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0153] Modifications to the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of applicable embodiments, it should be understood that the described embodiments are merely exemplary and should not be construed as limiting the scope of the following claims. For example, the embodiments provided herein include handheld devices, which may include or be utilized with any suitable voltage source, such as a battery providing any suitable voltage.

[0154] Furthermore, in the embodiments provided above, references are made to processing platforms, computing systems, controllers, and other devices that include processors. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the practices of those skilled in the art of computer programming, references to acts and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "executed by a computer," or "executed by a CPU."

[0155] Those of ordinary skill in the art will understand that the operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals, and the memory system maintains the data bits in memory locations, thereby reconfiguring or otherwise altering the operation of the CPU and the processing of other signals. The memory locations in which the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that embodiments are not limited to the platforms or CPUs described above, and that other platforms and CPUs may support the provided methods.

[0156] The data bits may be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM)) or non-volatile (e.g., Read-Only Memory (ROM)) mass storage system readable by a CPU. The computer-readable media may include computer-readable media that reside exclusively on a processing system, or distributed, cooperative, or interconnected among multiple interconnected processing systems, which may be local or remote to a processing system. It should be understood that embodiments are not limited to the memories described above, and that other platforms and memories may support the provided methods.

[0157] In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium, which may be executed by a processor of a mobile, a network element, and / or any other computing device.

[0158] There is little distinction between hardware and software implementations of aspects of the system. Whether to use hardware or software is generally a design choice representing a cost vs. efficiency trade-off (although the choice between hardware and software can be important in certain situations). There may be a variety of vehicles (e.g., hardware, software, and / or firmware) in which the processes and / or systems and / or other techniques described herein may be effective, and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may select a primarily hardware and / or firmware vehicle. If flexibility is paramount, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0159] The foregoing detailed description has illustrated various embodiments of devices and / or processes through the use of block diagrams, flowcharts, and / or examples. To the extent that such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will appreciate that each function and / or operation in such block diagrams, flowcharts, or examples may be individually and / or collectively implemented by a wide range of hardware, software, firmware, or substantially any combination thereof. In one embodiment, portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and / or other integrated forms. However, those skilled in the art will recognize that certain aspects of the embodiments disclosed herein may equivalently be implemented, in whole or in part, in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as substantially any combination thereof, and that designing circuitry and / or writing software and / or firmware code is within the skill of those skilled in the art in light of this disclosure. Furthermore, those skilled in the art will understand that the subject matter mechanisms described herein may be distributed as program products in various forms, and that exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution.Examples of signal bearing media include, but are not limited to, recordable-type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission-type media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.).

[0160] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner described herein and then use engineering techniques to integrate such described devices and / or processes into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of the following: a system unit housing; a video display; memory, such as volatile and non-volatile memory; a processor, such as a microprocessor and a digital signal processor; computing entities, such as an operating system, drivers, a graphical user interface, and application programs; one or more interaction devices, such as a touchpad or screen; and / or a control system, such as feedback loops and control motors (e.g., feedback that senses position and / or velocity, control motors that move and / or adjust components and / or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication systems and / or network computing / communication systems.

[0161] The subject matter described herein may, in some cases, depict different components that are contained within or connected to different other components. It should be understood that such illustrated architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality may be achieved. Thus, any two components herein that combine to achieve a particular function may be considered to be “associated” with each other such that the desired functionality is achieved, regardless of the architecture or intervening components. Similarly, any two components so associated may also be considered to be “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components so associated may also be considered to be “operably coupleable” to each other to achieve the desired functionality. Examples of operably coupleable include, but are not limited to, components that are physically matable and / or physically interacting, and / or components that are wirelessly interacting and / or wirelessly interacting, and / or components that logically interact and / or logically interacting.

[0162] With respect to the use of virtually any plural and / or singular term herein, those skilled in the art can convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for purposes of clarity.

[0163] In general, those skilled in the art will understand that terms used in this specification, and particularly in the appended claims (e.g., the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including, but not limited to," the term "having" should be interpreted as "having at least," and the term "comprises" should be interpreted as "including, but not limited to"). Furthermore, where a specific number of recitations of an introduced claim are intended, such intention will be explicitly set forth in the claim; in the absence of such recitation, those skilled in the art will understand that no such intention exists. For example, where only one item is intended, the term "single" or similar language may be used. To assist in understanding, the following appended claims and / or description of this specification may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed as meaning that the introduction of a claim recitation by the indefinite article "a" or "an" limits any particular claim containing such an introduced claim recitation to embodiments containing only one such recitation, even if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. Furthermore, those skilled in the art will recognize that even when a specific number of recitations of an introduced claim are explicitly recited, such recitation should be interpreted to mean at least the recited number (e.g., the simple recitation "two recitations" without other modifiers means at least two recitations, or more than two recitations).Furthermore, when notation similar to "at least one of A, B, and C" is used, such structure is generally intended as the meaning that one of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, a system having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). When notation similar to "at least one of A, B, or C" is used, such structure is generally intended as the meaning that one of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, a system having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). Those skilled in the art will further appreciate that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" should be understood to include the possibilities of "A" or "B" or "A and B." Furthermore, as used herein, the term "any of," followed by a list of items and / or a list of categories of items, is intended to include "any of," "any combination of," "any plurality of," and / or "any combination of" of the items and / or categories of items, individually or in combination with other items and / or other categories of items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero.

[0164] Furthermore, where features or aspects of the disclosure are described in terms of a Markush group, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0165] As will be understood by those skilled in the art, for all purposes, including in terms of providing a written description, all ranges disclosed herein encompass any possible subranges and combinations of subranges. Any recited range can be readily recognized as fully descriptive and allowing the same range to be broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range described herein can be easily broken down into a lower third, middle third, upper third, etc. Also, as will be understood by those skilled in the art, all terms such as "up to," "at least," "greater than," "less than," etc., refer to ranges that are inclusive of the recited number and that can be further broken down into subranges as described above. Finally, as will be understood by those skilled in the art, ranges include individual elements. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

Claims

1. 1. A method for transmitting data from a wireless device, comprising: inserting padding bits into at least one physical protocol data unit (PPDU) of a plurality of PPDUs to be encoded with an error correcting code such that the padded PPDU size is an integer multiple of a length of the error correcting code, wherein each PPDU in a frame of PPDUs to be transmitted includes a PPDU size that is an integer multiple of a length of the error correcting code, and the PPDU size is aligned with a corresponding codeword (CW); transmitting the frame of the PPDUs including the at least one padded PPDU, the frame being encoded with the error correction code and including a transmit vector (TX VECTOR) indicating each PPDU size in the frame; A method comprising:

2. 2. The method of claim 1, wherein inserting padding bits into at least one PPDU of the plurality of PPDUs includes inserting padding bits into at least one MPDU within an aggregated medium access control protocol data unit (MPDU) (A-MPDU) frame.

3. 2. The method of claim 1, wherein transmitting the frames encoded with the error correction code to a wireless receiver includes signaling each PPDU size in a preamble of a wireless transmission.

4. 1. A wireless device comprising circuitry for transmitting data, including a transmitter, a receiver, a processor, and a memory, inserting padding bits into at least one Physical Protocol Data Unit (PPDU) of a plurality of PPDUs to be encoded with an error correcting code such that the padded PPDU size is an integer multiple of a length of the error correcting code, each PPDU in a frame of PPDUs to be transmitted including a PPDU size that is an integer multiple of a length of the error correcting code, the PPDU size being aligned with a corresponding codeword (CW); transmitting the frame of the PPDUs including the at least one padded PPDU, the frame being encoded with the error correction code, and the frame including a transmit vector TX VECTOR indicating the size of each PPDU in the frame; 1. A wireless device configured to:

5. The wireless device of claim 4 , wherein the error correction code is a low-density parity-check (LDPC) code.

6. 5. The wireless device of claim 4, wherein the inserting of padding bits into at least one PPDU of the plurality of PPDUs comprises inserting padding bits into at least one MPDU within an aggregated medium access control protocol data unit (MPDU) (A-MPDU) frame.

7. The wireless device of claim 4 , further configured to signal each PPDU size in a preamble of the transmission.

8. 5. The wireless device of claim 4, further configured to use a Low Density Parity Check (LDPC) Extra Symbol Segment field in a preamble of the transmission to transmit the frame encoded with the error correction code.

9. 5. The wireless device of claim 4, further configured to use an advance forward error correction padding coefficient field in a preamble of the transmission to transmit the frame encoded with the error correction code.

10. The wireless device of claim 4 , wherein the wireless device is one of a wireless station or a wireless access point.

11. 5. The wireless device of claim 4, wherein the wireless device is configured to select the error correction code from the plurality of error correction codes according to the length of each error correction code in the plurality of error correction codes and according to each size of a PPDU to be transmitted in the frame.

12. The wireless device of claim 4 , wherein the wireless device is configured to select an error correction code that minimizes the number of bits of matching padding.

13. The wireless device of claim 4 , wherein at least two PPDUs in the frame have different lengths.

14. The wireless device of claim 4 , wherein the frame is an Aggregation MPDU (A-MPDU) frame.

15. A computer-readable storage medium containing instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 3.

Images