Method and system for incremental freezing using multi-kernel polarization codes

Abstract

An encoding device may encode data bits using a polar code associated with a first polar code kernel structure. The encoding device may send the initial transmission to a receiver. The initial transmission may include polarization encoded data bits. The encoding device may receive, from the receiver, first feedback indicating that at least a first subset of the data bits is not successfully decoded by the receiver. The encoding device may encode at least a first subset of the data bits that are not successfully decoded by the receiver, using a polar code associated with a second polar code kernel structure, using a bit channel of the second polar code kernel structure, the reliability of the bit channel is relatively higher than that associated with one or more bit channels for encoding a first subset of the data bits using a first polar code kernel structure of the initial transmission.

Description

[0001] Cross - reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 432,828, filed on December 15, 2022, U.S. Provisional Patent Application No. 63 / 433,326, filed on December 16, 2022, and U.S. Provisional Patent Application No. 63 / 433,217, filed on December 16, 2022. The entire contents of these U.S. Provisional Patent Applications are incorporated herein by reference. Background of the Invention

[0002] Hybrid automatic repeat request (HARQ) can be a technique for attempting to ensure successful reception of one or more (e.g., all) information bits in the case of a transmission failure. HARQ can combine forward error correction (FEC) with a re - transmission, which can contain one or more (e.g., all) or part of the information bits to increase the probability of successful decoding after re - transmission. The control channel may not use re - transmission, and / or enabling the HARQ function using polar codes is currently an active area of research. Summary of the Invention

[0003] A method can be implemented by an encoding device. The encoding device can encode data bits using a polar code associated with a first polar code kernel structure. The encoding device can send an initial transmission to a receiver. The initial transmission can include the polar - encoded data bits. The encoding device can receive a first feedback from the receiver for the initial transmission. The first feedback can indicate that at least a first subset of the data bits has not been successfully decoded by the receiver. The encoding device can encode at least the first subset of the data bits that have not been successfully decoded by the receiver using a polar code associated with a second polar code kernel structure. The first subset of the data bits can be encoded using bit channels of the second polar code kernel structure, and the reliability of the bit channels is relatively higher than the reliability associated with one or more bit channels used to encode the first subset of the data bits using the first polar code kernel structure for the initial transmission. The encoding device can send a first re - transmission to the receiver. The first re - transmission can include the polar - encoded first subset of the data bits associated with the second polar code kernel structure.

[0004] The encoding device may receive, from the receiver, a second feedback for the first retransmission. The second feedback may indicate that at least a second subset of data bits has not been successfully decoded by the receiver. The second subset of data bits may be a subset of the first subset of data bits. The encoding device may encode at least the second subset of data bits using a polar code associated with a third polar code kernel structure. The second subset of data bits may be encoded using bit channels of the third polar code kernel structure, the reliability of which is relatively higher than the reliability associated with one or more bit channels used to encode the second subset of data bits using a second polar code kernel structure for the first retransmission. The encoding device may send a second retransmission to the receiver. The second retransmission may include the polar-coded second subset of data bits.

[0005] The encoding device may send to the receiver one or more indications of the first or second polar code kernel structure for the first retransmission and / or an indication of the mapping of the first subset of data bits to the bit channels of the second polar code kernel structure.

[0006] The first feedback indicating that at least the first subset of data bits has not been successfully decoded by the receiver may include one or more NACK messages. The code rate may be determined for the initial transmission based on a modulation and coding scheme (MCS). The respective data bits may be mapped to a first subset of bit channels in the initial transmission and the first retransmission based on the respective reliability of the data bits. The first polar code kernel structure may include a first kernel order, a first kernel size, and / or a first kernel structure. The second polar code kernel structure may include a second kernel order, a second kernel size, and / or a second kernel structure.

[0007] The encoding device may select the first polar code kernel structure based on channel quality, size of resources, encoder complexity, or reliability. The encoding device may select the second polar code kernel structure based on the code rate. The code rate may be associated with the first transmission.

[0008] The encoding device may determine the code rate for the first retransmission based on a predefined set of code rates. The encoding device may determine the code rate for the first retransmission based on the signal-to-noise ratio associated with the initial transmission. Description of the Drawings

[0009] Figure 1A is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0010] Figure 1B is illustrated in accordance with one embodiment and may be inFigure 1A System diagram of an example wireless transmit / receive unit (WTRU) used within the communication system illustrated in

[0011] Figure 1C is a system diagram that illustrates an example radio access network (RAN) and an example core network (CN) that can be used within the communication system illustrated in Figure 1A according to one embodiment.

[0012] Figure 1D is a system diagram that illustrates a further example RAN and a further example CN that can be used within the communication system illustrated in Figure 1A according to one embodiment.

[0013] Figure 2 is a diagram depicting an example polar encoder with a block size of 8.

[0014] Figure 3 is a diagram depicting an example multi-core polar encoder with a codeword size of 12.

[0015] Figure 4 is a diagram depicting another example multi-core polar encoder with a codeword size of 15.

[0016] Figure 5 is a flow chart depicting an example multi-core polar code framework.

[0017] Figure 6 is a flow chart depicting an example multi-core encoding process at a transmitter (TX).

[0018] Figure 7 is a flow chart depicting an example multi-core decoding process at a receiver (RX).

[0019] Figure 8 is a flow chart depicting an example IF-HARQ enabled multi-core polar framework.

[0020] Figure 9 is a flow chart depicting an example IF-HARQ process at a receiver (RX).

[0021] Figure 10 is a flow chart depicting an example IF-HARQ process at a transmitter (TX). DETAILED DESCRIPTION

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

[0023] As Figure 1A shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (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 station, fixed or mobile subscriber unit, subscription-based unit, pager, cellular phone, personal digital assistant (PDA), smart phone, laptop, netbook, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, watch or other wearable device, head-mounted display (HMD), vehicle, drone, medical device and applications (e.g., remote surgery), industrial device and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automation processing chain context), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any one of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

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

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

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

[0029] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish the air interface 116.

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

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

[0032] Figure 1A Base station 114b in [description] 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 commercial venue, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d may implement radio technologies such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d may implement radio technologies such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not be required to access the Internet 110 via CN 106 / 115.

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

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

[0035] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 can include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A the WTRU 102c shown in the figure can be configured to communicate with a base station 114a that can employ a cellular-based radio technology and a base station 114b that can employ IEEE 802 radio technology.

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

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

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

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

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

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

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

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

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

[0045] The WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with a particular subframe for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception)).

[0046] Figure 1C is a system diagram illustrating a RAN 104 and a CN 106 according to an embodiment. As noted above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRU 102a, 102b, 102c via the air interface 116. The RAN 104 may also communicate with the CN 106.

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

[0048] Each of 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, scheduling of users in UL and / or DL, etc. As Figure 1C shown, eNode-Bs 160a, 160b, 160c may communicate with each other via the X2 interface.

[0049] Figure 1C shown, CN 106 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 depicted as part of CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0050] MME 162 may be connected to each of eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and may act as a control node. For example, MME 162 may be responsible for authenticating users of WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during the initial attachment of WTRUs 102a, 102b, 102c, etc. MME162 may provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

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

[0052] The SGW 164 can be connected to the PGW 166, which can provide the WTRUs 102a, 102b, 102c with access to a packet switched network (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0053] The CN 106 can facilitate communication with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to a circuit switched network (such as the PSTN 108) to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 can include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with such an IP gateway that serves as an interface between the CN 106 and the PSTN 108. Additionally, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

[0054] Although the WTRU is Figures 1A to 1D described as a wireless terminal herein, it is contemplated that in some representative embodiments, such a terminal can use (e.g., temporarily or permanently) a wired communication interface to the communication network.

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

[0056] Infrastructure basic service set (BSS) mode WLANs can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic destined for an STA from outside the BSS can reach the STA via the AP and can be delivered to the STA. Traffic from an STA to a destination outside the BSS can be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS can be sent via the AP. For example, the source STA can send the traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer traffic. Peer traffic can be sent between the source and destination STAs (e.g., directly between them) using direct link setup (DLS). In some representative embodiments, DLS can use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode can sometimes be referred to in this document as the "ad hoc" communication mode.

[0057] When operating in 802.11ac infrastructure mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STAs to establish a connection with the AP. In some representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA can back off. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0058] High throughput (HT) STAs can communicate using a 40 MHz wide channel, e.g., via a combination of the primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

[0059] A very high throughput (VHT) STA can support channels that are 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide. The 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. The 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or by combining two non - contiguous 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can be passed through a segment parser that can divide the data into two streams. The inverse fast Fourier transform (IFFT) processing and time - domain processing can be done separately on each stream. The streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0060] The operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth 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 bandwidth, 10 MHz bandwidth, and 20 MHz bandwidth in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz bandwidth, 2 MHz bandwidth, 4 MHz bandwidth, 8 MHz bandwidth, and 16 MHz bandwidth using non - TVWS spectrum. According to a representative embodiment, 802.11ah can support meter - type control / machine - type communication (MTC), such as MTC devices in a macro - coverage area. The MTC devices can have certain capabilities, for example, limited capabilities, including supporting (e.g., only supporting) certain and / or limited bandwidths. The MTC devices can include a battery whose battery life is above a threshold (e.g., to maintain a very long battery life).

[0061] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as the primary channel. The primary channel 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 set and / or restricted by the STA that supports the minimum bandwidth operation mode among all STAs operating in the BSS. In the example of 802.11ah, for an STA that supports (e.g., only supports) the 1MHz mode (e.g., an MTC type device), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) settings can depend on the state of the primary channel. If the primary channel is busy, for example, due to an STA (which only supports the 1MHz operation mode) transmitting to the AP, the entire available frequency band may be considered busy, even if most of the frequency band is still idle and available.

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

[0063] Figure 1D is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As noted above, RAN 113 can employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 113 can also communicate with CN 115.

[0064] RAN 113 may include gNBs 180a, 180b, 180c, although it will be appreciated that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, 180c. Thus, gNB 180a, for example, may use multiple antennas to transmit wireless signals to WTRU 102a and / or receive wireless signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive a coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

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

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

[0067] Each of gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As Figure 1D shown, gNBs 180a, 180b, 180c may communicate with each other via the Xn interface.

[0068] Figure 1DThe CN 115 shown in the figure may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may include data networks (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0069] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing the registration area, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by 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, etc. The AMF 162 may provide control plane functions for handover between the RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0071] UPF 184a and 184b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. These gNBs can provide access to a packet-switched network (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184a and 184b can 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.

[0072] CN 115 can facilitate communication with other networks. For example, CN 115 can include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with the IP gateway that serves as an interface between CN 115 and PSTN 108. Additionally, CN 115 can provide access to other network 112 to WTRU 102a, 102b, and 102c. The other network 112 can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU 102a, 102b, and 102c can be connected to local data networks (DN) 185a and 185b via the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and DNs 185a and 185b.

[0073] In view of Figures 1A to 1D and Figures 1A to 1D the corresponding descriptions, one or more or all of the functions described herein with respect to one or more of the following: WTRU102a-d, base stations 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DNs 185a-b, and / or any other device(s) described herein can be performed by one or more emulation devices (not shown). The emulation device(s) can be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device(s) can be used to test other devices and / or simulate network and / or WTRU functions.

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

[0075] The one or more emulation devices can perform one or more (including all) functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation device can be used in test scenarios in a test laboratory and / or in a non-deployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (e.g., which can include one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0076] Methods, apparatuses, and / or systems for enabling HARQ-compatible polar codes for a multi-core construction of polar codes are described herein. The methods, apparatuses, and / or systems herein can include signaling for decoding failures and / or sets of undecoded information, methods for selecting a new multi-core ordering for retransmission, and / or mapping of sets of undecoded information to encoder inputs.

[0077] Methods, apparatuses, and / or systems for notifying a transmitter of a decoding failure are provided. Methods, apparatuses, and / or systems for updating a set of undecoded information bits and / or corresponding reliabilities based on a previous transmission are provided. Methods, apparatuses, and / or systems for selecting a new ordering for a multi-core structure based on a new retransmission code rate are provided. Methods, apparatuses, and / or systems for selecting information bits with the weakest reliability in an undecoded set according to a new code rate are provided. Methods, apparatuses, and / or systems for mapping the selected information bits to encoder inputs with the strongest reliability are provided.

[0078] The HARQ mechanism for polar codes may not be addressed in existing specifications because the control channel (e.g., 5G NR control channel) may not utilize retransmissions. The coding structure of polar codes may limit the flexibility of one or more HARQ mechanisms that can be used with the polar decoding process. In an example, methods, apparatuses, and / or systems for multi-core polar codes with HARQ support including polar codes can be described herein.

[0079] The methods, apparatuses, and / or systems described herein may be related to multi-kernel polar codes and / or hybrid ARQ systems. Polar codes and multi-kernel architectures may be described herein. A polar code may be a capacity-achieving deterministic channel code. A polar code may exhibit performance comparable to that of conventional LDPC codes and / or turbo codes with low error floors or without error floors when assisted by an embedded CRC. In an example, a polar code may perform reliably in short block lengths as well as medium and long block lengths. A polar code may be a channel coding scheme for control channels (e.g., for one or more 3GPP NR standards).

[0080] Polar coding may be defined by Equation 1. i.x = uG N (1)

[0081] The codeword vector may be represented by x. The input vector may be represented by u. The generator matrix may be labeled as G N . The codeword vector x of the polar code may be generated by the product of the input vector u and the generator matrix G N . In an example of polar code construction, x and u may be binary vectors of length N = 2 n . N may denote the codeword block length. The generator matrix G N may be defined by the Kronecker power of , where represents the n-th Kronecker power of T.

[0082] Figure 2 is a diagram depicting an example polar encoder 200. The polar encoder 200 may have a block length of 8. Polar coding may be expressed by the equation x = uG N . The codeword vector may be x204 (e.g., u0, u1, u2, u3, u4, u5, u6, u7). The input vector may be u202 (e.g., x0, x1, x2, x3, x4, x5, x6, x7). The generator matrix may be labeled as G N . The codeword vector x204 of the polar code may be generated by the product of the input vector u202 and the generator matrix G N . In an example of polar code construction, x204 and u202 may be binary vectors of length N = 2 n . N may denote the codeword block length. The generator matrix G N may be defined by the Kronecker power of , where represents the n-th Kronecker power of T. The generator matrix G N may be decomposed into multiple consecutive segments, where each segment includes a kernel matrix multiplication stage and a permutation π i .

[0083] One or more input bits for a polar code may have a fixed value (e.g., such as 0). The fixed-value bits may be referred to as “frozen bits”. The input indices for the frozen bits may be represented by a set and / or if i < j. The remaining portion of the input bits for the polar code may convey variable information and / or may be referred to as “non-frozen bits”. The input indices for the non-frozen bits may be represented by a set A = {a1, a2, a3..., a K} and a i < a j if i < j.

[0084] The number of information bits (e.g., or non-frozen bits) may be described as K. The codeword block length may be N. The number of frozen bits may be described as N – K. The code rate of the polar code may be denoted as R. The code rate R of the polar code may be described as

[0085] This document may describe code construction. Code construction may be a process of determining the input bit indices between frozen bits and non-frozen bits for a polar code. Code construction may include initially calculating the reliability of each input bit index and / or sorting the bit index reliabilities (e.g., before starting the encoding operation). If the bit index reliability order is determined, in an example, the least reliable input bits may be assigned as frozen bits and the remaining bits may be assigned as non-frozen / information bits. The ratio of frozen and non-frozen bits may be determined according to the desired code rate.

[0086] Figure 3 FIG. is a diagram depicting an example multi-kernel polar encoder 300 having a codeword size of 12. Figure 4 FIG. is a diagram depicting an example multi-kernel polar encoder 400 having a codeword size of 15.

[0087] Multi-kernel polar codes may provide flexible code rates. In an example, multi-kernel polar codes may provide more flexible code rates compared to polar codes having 2x2 kernels. Multi-kernel polar codes may use 2x2 kernels. Multi-kernel polar codes may use different types of kernels than 2x2. For example, multi-kernel polar codes may use 3x3, 5x5, and / or 7x7 kernels or combinations of these kernels. Some examples of these kernels may be provided by matrices T2, T3, and T5.

[0088] The multi-kernel structure may exist in the form of kernel order, kernel size, and / or kernel structure. Kernels having a similar size may be obtained in different ways. For example, Figure 3Configurations that can depict the multi-core polarization encoder structure of T3×T2×T2. The structure of the multi-core polarization encoder 300 can include a codeword size that can be implicitly determined as N = 12 (3x2x2). Figure 4 Configurations that can depict the multi-core polarization encoder structure of T5×T3. The codeword size of the multi-core polarization encoder 400 can be N = 15.

[0089] Hybrid Automatic Repeat reQuest (HARQ) can be used to ensure reliable and / or successful transmission. HARQ regarding polarization codes can be described herein. HARQ can be based on a combination of forward error correction and / or retransmission strategy (ARQ), which includes enabling retransmission of a codeword (e.g., the entire codeword and / or a subset of the codeword) until one or more transmissions are successfully received and / or the maximum number of retransmissions is allowed. If the maximum allowed number of transmissions is reached, the transmission may be in error. There can be various HARQ retransmission techniques, where the differences between the techniques can be at least partially related to how the retransmitted signals are combined by the receiver and / or whether the entire codeword and / or only a subset of the information and / or redundancy bits are retransmitted.

[0090] In an example, performance metrics that can be used to evaluate a HARQ scheme (FEC+ARQ) include the average number of retransmissions, spectral efficiency, and / or average throughput. The average number of retransmissions can play a role in terms of transmission latency, in some examples regardless of whether the transmission is successful. Spectral efficiency and / or average throughput can be related to the success rate (e.g., or conversely, BLER) and the code rate and / or modulation order.

[0091] One HARQ variant that can be used for communication is Incremental Redundancy (IR-HARQ). For IR-HARQ, the transmission can start at a higher code rate. In an example of IR-HARQ that includes retransmission (e.g., when a NACK is received as feedback), a lower code rate can be employed. The lower code rate can be employed, for example, by adding additional parity bits to the information sequence transmission. In an example, the process can be iterative until the codeword is successfully transmitted (e.g., until an ACK is fed back). In an example, when the codeword is properly received (e.g., the decoded codeword passes a cyclic redundancy check), the transmission (retransmission) can be successful. For example, when the decoded codeword passes a cyclic redundancy check, the transmission (retransmission) can be determined to be successful. In an example, the bits of the transmitted codeword can be properly received by the receiver after the initial transmission or after one or more retransmissions.

[0092] IR-HARQ can help maintain relatively high throughput and / or spectral efficiency while employing a similar (e.g., the same) code structure. Puncturing and / or shortening can be used in LDPC codes for supporting rate matching enabled by IR-HARQ. In addition to the specific structure of the LDPC code employed that allows a nested configuration of a subset of the parity-check matrix, puncturing and / or shortening can also be used, which can provide the possibility of decoding subcodewords (e.g., using the mother code structure).

[0093] This document may describe polar coding for supporting rate matching and / or IR-HARQ. This document may describe polar coding for supporting rate matching and / or IR-HARQ without significant performance degradation. Polar codes can be structured inherently. In an example, using puncturing and / or shortening operations for rate matching may affect the BLER performance. For example, the BLER performance degradation may be caused by the unavailability of a nested structure. The nested structure may include a higher-rate code within a lower-rate mother code. In an example, the nested code rate structure can be punctured while still having the characteristics of a good code. A good code can have a BLER performance below a certain threshold, e.g., after puncturing. For an example of a double-polar code, there may be no available ability to include the identity submatrix in the double-polar code representation in a way that results in one or more (e.g., all) of the nested codes having good performance. The code length of traditional polar codes can exist in the form of a power of 2, which can further reduce the flexibility of the polar coding scheme.

[0094] Multi-kernel polar codes can allow addressing the limitations of traditional polar codes in terms of code length flexibility. It may not be clear and / or established in the current 3GPP standard to implement rateless polar codes that perform well at different rates.

[0095] Rateless LDPC and / or Turbo codes can be enabled by a puncturing process, where a mother code with a lower code rate can be used. Puncturing can be performed on a set of codewords of the bits of the mother code and / or bits can be transmitted during retransmission. The enhanced redundancy scheme can ensure that the use of a higher-rate code does not result in performance degradation. Not resulting in performance degradation can be achieved by a special nested structure of the parity-check matrix, which can allow an optimized degree distribution and / or nested characteristics. For polar codes, nested characteristics may be difficult to achieve due to the highly structured nature of these codes. The incremental redundancy introduced by puncturing and / or shortening may not naturally enable strong codes for different rates.

[0096] The current implementations of polar codes for control channels (e.g., in 5G NR), such as hybrid ARQ, may not include an adaptive retransmission process. The coding structure of polar codes may limit the flexibility of the HARQ mechanism that can be used with the polar decoding process.

[0097] This document may describe HARQ support for polar codes. Polar coding can be used for data channels in future wireless systems. For example, polar coding can be used due to its error correction advantages. If polar coding is used for future data channels (e.g., outside 5G systems), the HARQ support capability can be addressed. The methods and / or processes described herein may include an enabler and / or process for the use of HARQ with multi-kernel polar codes. The methods, processes, and / or devices described herein can address the adaptive retransmission process for polar codes. The advantages of the methods, processes, and / or devices described herein may include the following enabler: it combines multi-kernel polar codes and / or IF-HARQ to provide a flexible polar coding process for future (e.g., 6G and subsequent) communications.

[0098] This document may describe the selection of kernel structures for multi-kernel polar codes. Figure 5 FIG. is a flowchart depicting an example multi-kernel polar code framework 500. The multi-kernel polar code framework 500 may include an enabler and / or signaling for a multi-kernel polar code to be used in an actual communication system. An encoding device (e.g., such as a WTRU) may include the multi-kernel polar code framework 500. The building blocks of the multi-kernel polar code framework 500 may include a multi-kernel polar encoder 502 and / or one or more kernel selection blocks 504. The multi-kernel polar encoder 502 may be constructed based on the kernel structure output of the kernel selection block 504.

[0099] This document may describe multi-kernel polar coding. The multi-kernel polar encoder 502 may be constructed based on a configuration input 516 from the kernel selection block 504. The polar code kernel structure may be determined by the kernel selection block 504. The encoding device may send an indication 514 indicating the determined polar code kernel structure to the receiver. The constructed multi-kernel polar encoder 502 may encode information bits 506 (e.g., using the polar code kernel structure determined by the kernel selection block 504) to output a codeword 508. The configuration input 516 from the kernel selection block 504 may include information related to the multi-kernel structure of the polar encoder (e.g., such as the polar code kernel structure) and / or the codeword length. The kernel selection block 504 may determine the output to the polar encoder 516 based on one or more selection criterion inputs. In an example, the kernel selection block 504 may determine the output (e.g., the polar code kernel structure) to the polar encoder 516 based on the size 510 of the available resources and the CSI feedback 512. A kernel structure indication 518 may be sent to the receiver. For example, the kernel selection block 516 may output the kernel structure indication 518 to the receiver. The kernel structure indication 518 may indicate the kernel structure selected by the kernel selection block 504.

[0100] In an example, a transmitter may include a set of kernels that can be used to construct a multi-kernel polar encoder. The set of kernels may be signaled to a receiver (e.g., via available messaging capabilities). In an example, the transmitter and / or the receiver may be a wireless transmit / receive unit (WTRU). The set of available kernels in the WTRU may be labeled as where i k labels the size of the kernel in a set including N U different kernels.

[0101] Multi-kernel polar coding may include dynamic selection of an information set. The information set (e.g., a set of frozen bits and / or a mapping of information bits to encoder inputs) may be determined as part of the polar code construction process. In an example, the information set may be determined based on the reliability of input bits. For example, the reliability of input bits may be determined based on density evolution (DE / GA) techniques under Gaussian approximation. Bit channels with higher reliability may be assigned to information symbols. For example, data bits to be transmitted may be mapped to encoder inputs (e.g., bit channels) with higher (e.g., strongest) reliability. In such an example, the remaining input bits may be frozen (e.g., assigned a value of 0).

[0102] In an example, the information set may be determined based on the minimum distance of the multi-kernel structure of the polar code. The information set may be determined to maximize the minimum distance of the selected information set.

[0103] In an example, information set construction may be based on an indication from a gNB. The WTRU may use the indication from the gNB to determine the information set. The indication may include an index to a predefined technique. The indication may include an index of input bits to be used as the information set.

[0104] A kernel selection block (e.g., such as Figure 5 the kernel selection block 504 shown in ) may be used by the WTRU to select a kernel structure. For example, the kernel selection may be performed by the WTRU. In an example, the WTRU may determine and / or select a kernel structure based on parameters such as channel quality and / or the size of resources. For example, the channel quality may be measured for a measured RSSI via a CQI parameter indicating SNR, code rate R, and / or modulation order Q. For example, the size of resources may be the target codeword length E and / or the number of dedicated resource elements N RE . If the size of resources is provided as an input, the target codeword length may be calculated by E = Q·N RE . The number of information bits K may be calculated by K = R·E.

[0105] Kernel selection may include: identifying a set of multi-kernel structure candidates. In an example, the multi-kernel structure candidates may be determined based on a target codeword length E. In an example, a kernel selection block may determine a set of candidate kernel structures where N C indicates the number of candidate kernel structures, W j indicates having of the kernel structure, where M j indicates the number of stages in the j-th kernel structure, indicates the kernel structure W j with size j l of the kernel, and / or For a given kernel structure W j the codeword length can be calculated by . The set S W of candidate kernel structures may include kernel structures having a codeword length N j close to the target codeword length E. In an example, N j ∈[E - δ, E + δ], where δ may be an integer satisfying the condition 0 < δ << E. In an example, the value of δ may be indicated to the WTRU and / or be predefined.

[0106] Kernel selection (e.g., a kernel selection block) may include: calculating one or a set of (one or more) performance metrics for one or more (e.g., all) candidate kernel structures in the set S W . In an example, the performance metric P j may be a function of SNR, code rate R, kernel structure W j and / or the target code rate E, such that P j = F(NR, R, K j , E), where F() may indicate a function and / or method for measuring the performance of a kernel. Examples of functions for measuring performance may be described herein. In an example, kernel selection may be based on one or more kernel performance metrics such as reliability, coding complexity, minimum rate matching, and / or distance spectrum.

[0107] Kernel performance (e.g., a kernel performance function) may be based on reliability. The average reliability of the input bit channels may be used to determine kernel performance. For a given kernel structure W j and / or SNR, the reliability of each input bit may be calculated. In an example, bit channel reliability may be calculated based on DE / GA techniques. The mean of the highest K reliabilities may be calculated to obtain P j , where K = R·N j . In an example, a higher P j may imply better performance.

[0108] The core performance (e.g., core performance function) can be based on the coding complexity. The coding complexity of the multi-core polar encoder can be used to determine the core performance. For a given core structure W j , the number of XOR operations can be determined based on the cores in the structure. In an example, O j can indicate the number of XOR operations included for core T j . For example, for a given core structure W j , the performance can be determined as In an example, a lower P j can imply better performance.

[0109] The core performance (e.g., core performance function) can be based on the distance spectrum. The distance spectrum of the core structure can be used as a performance function to select the core structure. In an example, core T l can have an associated partial distance sequence where D i indicates the number of non-zero entries in the i-th row of T i . For example, the partial distance sequence for core T2 can be given by . The partial distance sequence for core T3 can be given by . The distance spectrum of the core structure can be calculated by . For example, assuming W j : T3×T2, then the distance spectrum can be used within the performance function to select the strongest core. For example, the mean of can be calculated to obtain P j .

[0110] Core selection (e.g., core selection block) can select the strongest core structure to use, e.g., based on the core performance (e.g., core performance function). The selected core and / or K can be fed to the polar encoder for the encoding process. The selected core structure can be signaled to the receiver. An example multi-core selection process 600 for the transmitter is depicted in Figure 6 . An example multi-core selection process 700 for the receiver is depicted in Figure 7 . The selected core structure can be a multi-core structure selected based on the core performance function, where the core performance function can be used to select the core structure based on one or more performance metrics.

[0111] Figure 6is a flowchart depicting an example multi-core encoding process 600 at a transmitter. At 602, the transmitter may agree with the receiver on a set of available cores and / or core performance metrics for core selection. For example, the transmitter may receive at 602 from the receiver within a capabilities signaling message a set of available cores (e.g., as part of a process of agreement between the transmitter and the receiver). At 604, the transmitter may agree with the receiver on a codeword length, a code rate, and / or a mapping of information bits to encoder inputs. For example, the transmitter may send at 604 to the receiver an indication of the codeword length, the code rate, and / or a method of mapping information bits to encoder inputs (e.g., as part of a process of agreement between the transmitter and the receiver). At 606, the transmitter may determine candidate core structures. At 608, the transmitter may select a core structure. In the example, the core structure may be selected based on the determined metrics (e.g., based on core performance). For example, the transmitter may utilize at 608 a core performance function to select an appropriate core structure. At 610, the transmitter may agree with the receiver on the selected core structure. The transmitter may indicate the determined core structure to the receiver (e.g., as part of a process of agreement between the transmitter and the receiver). At 612, the transmitter may encode data to be transmitted via multi-core encoding. The data encoded at 612 may be performed using the selected core structure (e.g., the multi-core structure selected at 608). At 614, the transmitter may transmit the encoded data to the receiver. After each transmission made at 614, the multi-core encoding process 600 may return to 604 such that the transmitter may agree with the receiver on a codeword length, a code rate, and / or a mapping of information bits to encoder inputs associated with another transmission).

[0112] Figure 7is a flowchart depicting an example multi - kernel encoding process 700 at a receiver. At 702, the receiver may agree with the transmitter on a set of available kernels and / or the determined kernel performance metrics. For example, the receiver may report the available set of kernels to the transmitter at 702 within a capabilities signaling message (e.g., as part of a negotiation process between the transmitter and the receiver). At 704, the receiver may agree with the transmitter on the codeword length, code rate, and / or the method for mapping information bits to the encoder input. For example, the receiver may receive at 704 an indication from the transmitter of the codeword length, code rate, and / or the method for mapping information bits to the encoder input (e.g., as part of a negotiation process between the transmitter and the receiver). At 706, the receiver may agree with the transmitter on the determined and / or selected kernel structure. For example, the receiver may receive at 706 an indication of the selected kernel structure from the transmitter. At 708, the receiver may receive the encoded data. At 710, the receiver may decode the encoded data. After decoding each set of the received encoded data at 710, the multi - kernel encoding process 700 may return to 704 such that the transmitter may agree with the receiver on the codeword length, code rate, and / or the mapping of information bits to the encoder input associated with another transmission (e.g., a set of encoded data).

[0113] In an example, the WTRU and the gNB may include a process for fallback to a conventional 2x2 kernel structure for polar coding. For example, the fallback may be triggered by the gNB and / or indicated to the WTRU based on factors such as the number of WTRUs served by the gNB, traffic load, channel state, available computing resources, etc. In an example, the fallback may be triggered by the WTRU based on factors such as available computing resources, channel state, battery state, throughput, etc. In an example, the fallback may be implicitly triggered by the WTRU and / or the gNB based on factors such as channel state, throughput, etc.

[0114] The multi - kernel polar decoder may be a receiver (e.g., a DL or UL - based WTRU or gNB). The multi - kernel polar decoder may include one or more modules for decoding a multi - kernel polar code. The decoder may be constructed on the selected multi - kernel structure. The decoder may be of the following types: successive cancellation decoder, belief propagation decoder, and / or AI / ML - based decoder, etc. In an example, the decoder may be of the following types: a blind decoder without knowledge of the multi - kernel structure. The receiver may or may not recover the multi - kernel structure as part of the decoding process.

[0115] Signaling can enable a multi-core structure selection process. In an example, the WTRU and the gNB can signal to each other. The WTRU and the gNB can signal to each other to agree on a set of available cores, agree on a selected core structure, determine a method for core structure selection, select an information set, and / or participate in a fallback process. In an example, the signaling between the WTRU and the gNB can be based on a control or data channel.

[0116] Signaling can be utilized for the WTRU and the gNB to agree on a set of available core structures. The WTRU can feedback the available cores as part of the capability signaling. In an example, the feedback on the set of available cores can include the indices of the available cores. In an example, the WTRU can feedback the indices of the predefined core structures to both the WTRU and the gNB. In an example, the set of cores can be predefined and / or implicit to the WTRU and the gNB. In an example, a core structure and / or a set of core structures can be flexibly determined by the WTRU and / or reported to the gNB periodically, semi-periodically, or dynamically (e.g., set U). In an example, the gNB can indicate the set of cores to the WTRU.

[0117] Signaling can be related to the selected core structure. The WTRU and the gNB can agree on the selected core structure. The feedback on the core structure can include the size of one or more (e.g., all) of the selected core structures and / or the index of the selected core structure. In an example, the selected core structure can be implicit to the WTRU and the gNB for a set of parameters such as SNR, code R, and / or target codeword length E. In an example, the set of parameters can be known to the WTRU and the gNB.

[0118] Signaling can be related to the core structure selection process. In an example, the WTRU can determine the core selection method based on the current state, scenario, historical information, etc. of the WTRU. If the core structure is explicit, the WTRU and the gNB can agree on the core selection method via signaling. If the core structure feedback is implicit, there may be no explicit signaling for agreement between the WTRU and the gNB. In an example, the core selection method can be indicated to the WTRU by the gNB, e.g., by sending the index from a predefined table of core selection methods to the WTRU. In an example, the WTRU can feedback the identified core selection method to the gNB. For example, the WTRU can feedback the core selection method by sending the index from a predefined table of core selection methods. In an example, the WTRU can flexibly determine and / or signal the core selection method.

[0119] Signaling can be related to the selection of (one or more) information sets. In an example, the WTRU and the gNB can agree on a technique for selecting the information set. In an example, the technique for selecting the information set can be predefined at the WTRU and / or the gNB. The gNB can indicate the technique to be used to the WTRU. In an example, the gNB and / or the WTRU can indicate an index of the information set. In an example, the indication of the information set can be implicit based on parameters such as codeword length and SNR.

[0120] Signaling can be related to a fallback procedure. In an example, the gNB can indicate a fallback to a legacy core to the WTRU. In an example, the WTRU can feedback a request to fallback to a legacy core structure to the gNB, which can be followed by an approval indication from the gNB to the WTRU.

[0121] Signaling (e.g., between the WTRU and the gNB) can be dynamic and / or semi-static based on control and / or data channels. For example, signaling can occur via UCI on PUCCH / PUSCH, DCI on PDCCH, and / or MAC CE. Implicit signaling between the WTRU and the gNB can include the selection of certain UL resources for control and / or data. For example, implicit signaling can include the selection of specific PUCCH resources, RACH resources, SRS resources, spatial relation information, etc.

[0122] This document can describe an initial configuration for multi-core polar coding. In an example, the WTRU can feedback a set of available cores to the gNB via signaling capabilities. The WTRU can receive an indication of core performance metrics. The core performance metrics can be related to a core performance function (e.g., providing a basis for the core performance function). In an example, the core performance metrics can be used for code blocks (e.g., all code blocks). The WTRU can receive an indication of a retransmission scheme including an intermediate code rate and / or an updated core structure to be used in the case of retransmission. The WTRU can receive an indication of a method for mapping information bits to encoder inputs.

[0123] A multi-core structure can be selected. The WTRU can receive an indication of available resources, codeword size, code rate, and / or core structure (e.g., multi-core structure). The WTRU can determine a set of candidate core structures based on the allocated resources and / or codeword length for a given core structure. The WTRU can determine performance metrics for selecting a core structure (e.g., selecting among methods based on complexity, reliability, distance spectrum, and / or minimum rate matching). The WTRU can calculate the performance metrics for one or more (e.g., all) candidate cores. The WTRU can feed the core structure into a multi-core polar encoder.

[0124] A multi-kernel polar encoder can be used to perform encoding / decoding. The WTRU can receive a code block encoded via a multi-kernel polar code. The WTRU can construct a multi-kernel polar encoder with a provided kernel structure from a kernel selection block. The WTRU can map data bits to bit channels (e.g., multi-kernel polar encoder inputs) based on a given mapping method and / or code rate. The WTRU can encode information bits and / or generate a codeword. The WTRU can decode a code block to recover the information bits.

[0125] Figure 8 FIG. depicts an example incremental freeze HARQ (IF-HARQ) enabled multi-kernel polar framework 800. An encoding device (e.g., such as a WTRU) can include an IF-HARQ enabled multi-kernel polar code framework 800. The multi-kernel polar encoder 800 can include a polar encoder 804. The polar encoder 804 can encode data bits using a polar code associated with a polar code kernel structure. The polar encoder 804 can utilize the polarization effect. The polarization effect can be described by the situation when information bits 808 are attributed to noiseless bit channels and / or frozen bits are transmitted through low reliability bit channels. Incremental freezing can be a rate matching technique that can maintain the polarization code's capacity achieving characteristics in different regimes while supporting HARQ processes. Incremental freezing can be used in multi-kernel polar encoding to enable IF-HARQ 802. For example, instead of incremental redundancy. Enabling IF-HARQ 802 can include initially freezing fewer bits, enabling a high code rate, and / or progressively retransmitting (e.g., via an initial transmission and multiple retransmissions) information bits previously transmitted in a less reliable channel. The retransmitted bits decoded in future transmissions may result in effective freezing of bits and / or allow decoding of information bits sent on the first transmission. In an example, the freezing process can converge. For example, if a set of information bits to be frozen is selected based on the reliability ordering of bit channels, the freezing process can converge. Incrementally freezing bits sent in earlier transmissions (retransmissions) can maintain the polarization code's capacity achieving characteristics. A multi-kernel polar code kernel structure can be used to support different code lengths.

[0126] To enable IF-HARQ 802 using a multi-kernel polar code kernel structure, a WTRU may be configured to transmit / receive CSI feedback 810 and / or signal a target information block length K prior to transmission. A kernel selection block 806 may select a polar code kernel structure. An encoding device may send an indication 814 indicating the selected polar code kernel structure to a receiver. After selecting an appropriate polar code kernel structure, in an example, an initial (e.g., peak) code rate R0 may be determined based on an MCS index provided by a link adapter. For example, a WTRU may determine an initial code rate R0 (e.g., for an initial data transmission) based on the MCS index. In an example, an information and frozen set selection process may depend on the peak code rate, codeword length, and / or kernel structure.

[0127] A WTRU may receive multiple multi-kernel polar coding configurations (e.g., from a network or another WTRU). The multi-kernel polar coding configuration may be a multi-kernel polar code kernel structure. The multi-kernel polar coding configuration may include a mapping of information bits to encoder inputs. The WTRU may use a first multi-kernel polar coding configuration of the multiple multi-kernel polar code configurations to transmit a first data transmission (e.g., a set of polar-coded data bits). For example, the WTRU may encode a set of data bits using the first multi-kernel polar coding configuration. The set of data bits may be mapped to a first set of bit channels in an initial transmission based on the respective reliability of the data bits. The first data transmission may be an initial transmission. The first multi-kernel polar coding configuration may be associated with a first polar code kernel structure, a first code rate, and a first codeword length to the network or the other WTRU. The first polar code kernel structure may include a first kernel order, a first kernel size, and / or a first kernel structure. The WTRU may receive feedback 812 (from the network or the other WTRU) in response to the first data transmission. The feedback 812 may indicate an acknowledgement (ACK) or a negative ACK (NACK) associated with the initial transmission.

[0128] When feedback 812 indicates a NACK, the WTRU may initiate an IF-HARQ process 802. The NACK may indicate that at least a first subset of the polar-coded data bits has not been successfully decoded by the receiver. The IF-HARQ process 802 may include kernel selection (e.g., kernel selection block 806), e.g., associated with a retransmission (e.g., a first retransmission). The WTRU may determine a second polar code structure. The WTRU may determine a code rate for the first retransmission based on a predefined set of code rates and / or signal-to-noise ratios associated with the initial transmission. The second polar code structure may be associated with a second multi-kernel polar code configuration, a second code rate, and / or a second codeword length. The second polar code structure may include a mapping of a first set of data bits to the bit channels of the polar code encoder (e.g., the bit channels of the second polar code kernel structure) and a second set of information bits that may be frozen. The first set of information bits may include lower reliability than the second set of information bits. The WTRU may send an indication of the second polar code kernel structure for the first retransmission to the receiver. The WTRU may send a mapping of the first set of data bits to the bit channels of the second polar code kernel structure to the receiver.

[0129] The WTRU may retransmit the first data to the network or the other WTRU using the second multi-kernel polar code configuration. For example, the WTRU may encode at least a first subset of the data bits that have not been successfully decoded by the receiver using a polar code associated with the second polar code kernel structure. The second polar code kernel structure may include a second kernel order, a second kernel size, and / or a second kernel structure. The first subset of data bits may be encoded using the bit channels of the second polar code kernel structure that have a relatively higher reliability than one or more of the bit channels associated with encoding the first subset of data bits using the first polar code kernel structure for the initial transmission. The WTRU may send a first retransmission including the first subset of data bits associated with the second polar code kernel structure to the receiver.

[0130] Methods and / or enablers for dynamic kernel order selection, mapping of information bits to encoder inputs, and / or intermediate code rates may be described herein. If a multi-kernel polar code kernel structure is selected, the transmitter may encode the information bits and / or transmit the information bits over the K most reliable channel bits (e.g., encoder inputs), while the remaining N-K bits may be frozen for the first transmission. A freeze pattern (e.g., mapping of information bits to encoder inputs) may be identified for enabling the HARQ process. A freeze pattern may be identified for retransmissions. Additionally or alternatively, the mapping of information bits to encoder inputs may depend on the intermediate code rate used for retransmissions.

[0131] In an example, dynamic kernel order selection and / or mapping of information bits can be performed for incremental freezing. For a multi-kernel polar code, the order of the kernels can affect the order of the polarization operation and / or the reliability of the encoder input. Considering that the Kronecker product may not be commutative, changing the order of the kernels in W can be equivalent to permuting its rows and / or columns.

[0132] IF-HARQ can be implemented using a multi-kernel polar code by subsequently adapting the kernel structure (e.g., dynamically changing the order of the kernels in each retransmission). The resulting permutation may lead to a different reliability order for the channel bits, which can be beneficial for one or more (e.g., some) information bits. IF-HARQ can incrementally freeze the channel bits based on their reliability order in different previous transmissions. Changing the order of the kernels may result in a different ranking of the reliability of the encoder input, and / or, a gain can be obtained by retransmitting the least reliable bits from a previous transmission with higher reliability after applying the kernel order permutation.

[0133] After generating different kernel orders, e.g., the transmitter can compute the reliability of the encoder input (e.g., bit channels) of the available multi-kernel polar code kernel structures. The reliability can be determined, for example, by DE / GA techniques. In an example, the set can label the K highest reliability scores of the information bits using the kernel structure W represented by the set where a j < a k l if k < l. The transmitter can select the polar code kernel structure based on the reliability set . In an example, the metric can be defined to take the average of the reliabilities such that In an example, the transmitter can select the W with the highest . In an example, the metric that can be included is that determining the reliability can be j . The WTRU can select the W with the highest . After selecting the kernel structure, e.g., the information bits b with the lowest K reliabilities in the previous transmission can be assigned to the polar encoder input for a new transmission. j i i

[0134] In an example, a multi-kernel polar code kernel structure with parameters (N,K) = (12,9) can be generated by the multi-kernel structure {T2,T3,T2} for an initial transmission with a code rate . The information bits (b1,…,b9) transmitted during the first transmission can be assigned to the encoder input based on Table 1, where u i i iIndicates the polar encoder input. One or more (e.g., all) other encoder inputs (e.g., u1, u2, u3) can be frozen (e.g., set to 0). The peak code rate and / or the intermediate code rate for retransmission can be provided as and provided. Table 1: Mapping information bits to encoder inputs based on {T2, T3, T2} for the first retransmission

[0135] If the first transmission is not successful and / or the transmitter receives a NACK, the transmitter can calculate the reliability of the encoder inputs for one or more (e.g., all) kernel structures (e.g., 3 different structures) including the initial kernel structure. In an example, the transmitter and the receiver (e.g., the WTRU and the gNB) may have determined the intermediate code rate for the first retransmission. The WTRU can calculate the reliability of the information bits associated with one or more (e.g., all) codes designed from these structures, as given in Table 2. Table 2: Reliability of encoder inputs for different kernel structures

[0136] The WTRU can select a kernel structure based on the reliability of the inputs. For example, the WTRU can select 6 inputs and / or calculate their average reliability for each kernel structure. In the example shown in Table 2, based on the reliability, the selected kernel structure can be {T3, T2, T2}. For example, the kernel selection process can include: calculating the average reliability for the 6 best inputs. Thus, in the first retransmission, the WTRU can switch the kernel structure from {T2, T3, T2} to {T3, T2, T2}.

[0137] After selecting the kernel structure, in an example, the transmitter can determine the mapping of the information bits to the encoder inputs (e.g., bit channels). S b ={b1: μ1, b2: μ2,..., b9: μ9} can label the set of undecoded information bits, and u i can label the highest reliability associated with b i in the previous transmission. For example, the information bit with the lowest reliability in S b can be retransmitted and / or assigned to the encoder input, as given in Table 3. One or more (e.g., all) other encoder inputs can be frozen. Table 3: Mapping information bits to encoder inputs based on {T3, T2, T2} for the second transmission

[0138] If the information bits in the first retransmission are successfully decoded, then the decoded information bits can be used, since the new frozen bits and / or S in the original transmission b can be updated. If one or more (e.g., all) of the information bits in the original transmission are still not decodable, then a second retransmission can be sent. In the second retransmission, information bits can be selected from the set S of undecoded information bits in Table 1 b (e.g., b7, b8, b9). In the example, the remaining part of the information bits may have been decoded during the first retransmission.

[0139] If the information bits of the first retransmission are not successfully decoded, then in the example, for the second retransmission, at a rate retransmit the updated set S b of the information bits with the lowest reliability, e.g., b1, b2, b4. For the second retransmission, one or more (e.g., all) other encoder inputs can be frozen. For example, the WTRU can receive a second feedback from the receiver for the first retransmission. The second feedback can indicate that at least a second subset of the data bits has not been successfully decoded by the receiver. The second subset of the data bits can be a subset of the first subset of the data bits. The WTRU can encode at least the second subset of the data bits using a polar code associated with a third polar code kernel structure. The third polar code kernel structure can include a third kernel order, a third kernel size, and / or a third kernel structure. The second subset of the data bits can be encoded using a bit channel of the third polar code kernel structure, which has a relatively higher reliability than one or more bit channels associated with encoding the second subset of the data bits using the second polar code kernel structure for the first retransmission. The WTRU can send the second retransmission including the polar-coded second subset of the data bits to the receiver.

[0140] The receiver can provide feedback indicating the decoding status of one or more (e.g., all) of the received transmissions to the transmitter. The feedback can indicate the status of the undecoded data bits after receiving the transmission (retransmission). The feedback can be sent along with an ACK / NACK message that can indicate the decoding result of the transmission (retransmission). If a subsequent retransmission is indicated (e.g., because a subset of the data bits has not been successfully decoded), then the WTRU can apply a similar (e.g., the same) process to calculate a new kernel order and / or the mapping of the information bits to the encoder inputs.

[0141] This document may describe a process for enabling an IF-HARQ process for multi-core polar codes. A WTRU (e.g., a transmitter) and a receiver (e.g., a network device such as a gNB or another WTRU) may agree on a multi-core polar coding configuration. The WTRU may transmit at an initial (e.g., anchor) code rate R0 and / or an agreed-upon codeword length. The WTRU may transmit the initial code rate and / or the agreed-upon codeword length after a link adaptation process. The receiver may receive the codeword and / or decode the codeword. The receiver may send an indication / feedback for ACK / NACK. If a NACK is received by the WTRU, the transmitter may initiate an IF-HARQ process. If an ACK is received, the transmission may have been successful.

[0142] In an example, for a retransmission, the transmitter may determine a new code rate and / or report the new code rate to the receiver. The transmitter may determine the code rate, e.g., based on the link SNR. The code rate may be determined according to the following options: when static IF-HARQ is employed, the code rate may be implicit and / or may not be reported. In the case of dynamic IF-HARQ, by selecting an adjustment parameter Δ j such that R j+1 = R j ×Δ j , the code rate may be determined based on a look-up table that matches SNR and code rate values. The code rate may be data-driven based on a predictor that outputs a code rate (e.g., R j+1 = f(R j , N, SNR)) regarding SNR, code length, and / or the previous code rate.

[0143] In an example, the transmitter may send a message indicating the code rate and / or an acknowledgement of the retransmission to the receiver. The transmitter may start a process of determining and / or selecting a polar code core structure. The transmitter may generate a set of reordered core structures, and / or calculate the reliability of the inputs to the polar encoder. The WTRU may select a polar code core structure based on the number of information bits retransmitted and / or the corresponding reliability. The transmitter may determine the mapping of information bits to encoder inputs. In the first transmission, one or more (e.g., all) information bits may be mapped to the encoder inputs with the highest reliability. If there may be a retransmission, in the j-th retransmission, the transmitter may select R based on the decoding success of the previous retransmission and / or the corresponding reliability of the information bits in the previous transmission. jN information bits. The transmitter and / or receiver may agree on a new kernel structure and / or mapping of the information bits to the encoder input. In an example, given the SNR, code rate, and / or codeword length, the kernel structure and / or mapping may be implicit to both the transmitter and / or receiver. In an example, the transmitter may indicate the new kernel order and / or mapping to the receiver. A similar (e.g., same) process may be iteratively repeated until successful decoding of one or more (e.g., all) information bits and / or reaching N max (e.g., maximum number of retransmissions).

[0144] Figure 9 is a flowchart depicting an example IF-HARQ process 900 performed by a receiver. At 902, there may be a new code block that may be transmitted to the receiver. At 904, the receiver may receive an indication of a polar code kernel structure, an indication of a mapping of data bits to bit channels, and / or a transmission (e.g., initial transmission, first retransmission, jth retransmission). At 906, the receiver may decode the transmission (e.g., the transmitted codeword). At 908, the receiver may update the set of undecoded information. At 910, the receiver may send feedback to the transmitter. The feedback sent by the receiver at 910 may be based on the set of undecoded information. The feedback sent by the receiver at 910 may indicate that a subset of the data bits has not been successfully decoded. If a subset of the data bits has not been successfully decoded by the receiver, the feedback sent by the receiver at 910 may be a NACK message. At 912, the process diverges based on whether the data bits were successfully decoded at 906. If the data bits were not successfully decoded, then at 914, the receiver may update the number of transmissions received for the code block from j to j + 1 and may prepare to receive a retransmission at 904. If the decoding is successful, the receiver may reset the process at 902.

[0145] Figure 10is a flowchart depicting an example IF-HARQ process 1000 performed by a transmitter. At 1002, the transmitter may prepare to start an IF-HARQ process for a new code block, where j = 0 before data bit transmission. At 1004, the transmitter may determine and / or select a polar code kernel structure and / or a mapping of data bits to bit channels of the polar code for the first transmission or the j-th retransmission. At 1006, the transmitter may encode the data bits using the polar code kernel structure and the mapping of data bits to the bit channels of the polar code kernel structure. At 1008, the transmitter may transmit (e.g., initial transmission, j-th retransmission) the encoded data bits to the receiver. At 1010, the transmitter may receive feedback from the receiver. The feedback received at 1010 may indicate that a subset of the data bits has not been successfully decoded by the receiver or that the decoding is successful. At 1012, if the decoding is successful, the transmitter may prepare to reset the IF-HARQ process for a new data block at 1002. If the feedback received at 1010 indicates that a subset of the data bits has not been successfully decoded by the receiver, then at 1012, the transmitter may prepare to transmit a retransmission (e.g., first retransmission, retransmission number j + 1). At 1016, the transmitter may select a polar code kernel structure for the retransmission. The polar code kernel structure may be selected based on the code rate and / or the reliability of the bit channels. At 1018, the transmitter may map the data bits to be transmitted to the bit channels for the polar code kernel structure. In the example, the data bits not successfully decoded by the receiver may be mapped to bit channels with higher reliability for the next transmission.

[0146] For incremental freezing, there may be an intermediate retransmission code rate. For each retransmission (e.g., after the receiver fails to decode successfully), a new intermediate code rate may be defined. A decoding failure may mean that the actual channel conditions are worse than the estimated channel conditions. For the i-th retransmission, a new intermediate code rate R i .

[0147] For static incremental freezing (SIF), an intermediate code rate may be predetermined for a given peak code rate R0. In the example, a set of predefined code rates may be signaled and / or predetermined between the transmitter and the receiver For example, N max may indicate the maximum number of retransmissions. If R j can be determined based on R0 (e.g., only based on R0), then the method may be considered SIF. In an example of SIF, R i =(R0), j > 0, 0 < R j < 1.

[0148] may be based on to calculate an example code rate set. The intermediate code rate can be reduced to a factor relative to R0 at each retransmission An example code rate set can be calculated based on to calculate an example code rate set.

[0149] The example code rate set can be such that where c > 1, and, in the case where no information bits are recovered in a previous retransmission, one or more (e.g., all) information bits can be encoded periodically / semi - periodically. The periodicity of the intermediate code rate R0 can be changed according to the success of the previous transmission decoding.

[0150] For dynamic incremental freezing (DIF), the intermediate code rate can be changed dynamically between retransmissions. In an example, the intermediate code rate can be changed according to the SNR and / or the success of the previous transmission decoding. In an example, a set of code rates can be indicated, and the intermediate code rate can be described as R j = Δ j R0, where 0 < Δ j ≤ 1 can be a rate scaling parameter for dynamically adjusting the intermediate code rate. The rate scaling parameter Δ j can be signaled from the transmitter to the receiver for each retransmission.

[0151] For machine - learning - based incremental freezing (ML - IF), the intermediate code rate can be determined by the ML / predictor block. The input to the ML block can be the predicted SNR value for each transmission and / or the previous code rate. The output of the ML block can directly or indirectly provide the next intermediate code rate. Example ML blocks can include neural networks and / or reinforcement learning techniques.

[0152] The decoding of polar codes using the incremental freezing scheme for multi - kernel structure polar codes can be based on decoding schemes such as chase combining, sequential decoding, parallel decoding, etc. In the chase - combining scheme, the same information and / or frozen bits can be retransmitted for a set of retransmissions. The decoder can combine the received symbols to increase the received SNR and / or decode the combined codewords. In the sequential - decoding scheme, decoding can start from the latest received codeword and then sequentially decode the previous codewords. If the retransmitted codeword can be successfully decoded, for example, the recovered information bits can be set as frozen bits for decoding the previously received codewords. In the parallel - decoding scheme, whenever a new retransmitted codeword is received, one or more (e.g., all) of the received codewords can be decoded in parallel. The log - likelihood ratio (LLR) values used in the decoding process of one or more (e.g., all) of the retransmitted codewords can be updated jointly during the parallel - decoding scheme.

[0153] Signaling can occur between a transmitter and a receiver, e.g., to enable multi-core structure selection. In an example, the transmitter can be a WTRU or a network device. In an example, the receiver can be a WTRU or a network device. In an example, the transmitter and / or receiver can agree on an intermediate code rate and / or a polar code core structure. In an example, the intermediate code rate can be shared explicitly with a signaling message between the transmitter and the receiver. In an example, the polar code core structure can be signaled between the transmitter and the receiver. In an example, the intermediate code rate and / or the core structure can be implicit. For example, the transmitter and the receiver can agree on a predetermined code rate.

[0154] In the case of a decoding failure, e.g., the receiver can notify the transmitter of the decoding status of one or more (e.g., all) of the transmissions received so far. At each retransmission, some (e.g., but not all) of the information bits can be decoded. In an example, information regarding the undecoded set can be sent from the receiver to the transmitter via ACK / NACK messages enabling one or more (e.g., all) of the retransmissions received for a data block. For example, the receiver can signal an ACK / NACK message after the decoding process for each retransmission. In an example, the receiver can send a 1-bit ACK / NACK after the original transmission, a 2-bit ACK / NACK after the first retransmission, a 3-bit ACK / NACK after the second retransmission, etc. For example, an ACK / NACK feedback of 011 after the second retransmission can notify the transmitter that the decoding of the original transmission was not successful but the decoding of the information bits in the first and / or second retransmissions was successful. Based on the ACK / NACK feedback, the transmitter and / or receiver can update the undecoded information set accordingly.

[0155] In an example, signaling between a WTRU and a gNB can use control and / or data channels, such as UCI on PUCCH / PUSCH, DCI on PDCCH, and / or MAC CE, dynamically and / or semi-statically. Implicit signaling between a WTRU and a gNB can include the selection of certain UL resources for control and / or data, such as using specific PUCCH resources, RACH resources, SRS resources, spatial relation information, etc.

[0156] Transmissions and retransmissions can be performed to enable IF-HARQ for multi-core polar codes. In the case of a decoding failure, the WTRU may indicate that a subset of data bits has not been successfully decoded (e.g., via a NACK message to the network (e.g., gNB)). The WTRU may receive a retransmission encoded as described herein. Encoding the retransmission may include: updating the set of undecoded information bits and / or corresponding reliabilities using feedback provided by the WTRU. Encoding the retransmission may include: determining one or more (e.g., all) kernel structures having a different ordering of the kernel structure in the original first transmission. Encoding the retransmission may include: calculating a reliability score for each encoder input for one or more (e.g., all) kernel structures. Encoding the retransmission may include: calculating a metric for each kernel structure, e.g., an average of the reliabilities of the encoder inputs having the highest reliability for a given number of encoder inputs determined using an intermediate code rate. Encoding the retransmission may include: selecting the best kernel structure based on the metric for the kernel performance function. Encoding the retransmission may include: selecting the information bits having the lowest reliability in the set of undecoded bits. Encoding the retransmission may include: mapping the information bits to the encoder inputs having the highest reliability. Encoding the retransmission may include: encoding the information bits and / or generating a codeword. The WTRU may decode the retransmitted code block. The WTRU may indicate feedback (e.g., ACK / NACK message) for each of the retransmitted code blocks to notify the network of the set of decoded information bits.

[0157] Although the features and elements are described above in particular combinations, those skilled in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein can be implemented in a computer program, software, or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memories, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented by an encoding device, the method comprising: Encoding data bits using a polar code associated with a first polar code kernel structure; Sending an initial transmission to a receiver, the initial transmission including the polar-coded data bits; Receiving, from the receiver, a first feedback for the initial transmission, wherein the first feedback indicates that at least a first subset of the data bits has not been successfully decoded by the receiver; Encoding at least a first subset of the data bits that have not been successfully decoded by the receiver using a polar code associated with a second polar code kernel structure, wherein the first subset of the data bits is encoded using bit channels of the second polar code kernel structure, and the reliability of the bit channels is relatively higher than the reliability associated with one or more bit channels used to encode the first subset of the data bits using the first polar code kernel structure for the initial transmission; And Sending a first retransmission to the receiver, the first retransmission including the polar-coded first subset of the data bits associated with the second polar code kernel structure.

2. The method according to claim 1, further comprising: Receiving, from the receiver, a second feedback for the first retransmission, wherein the second feedback indicates that at least a second subset of the data bits has not been successfully decoded by the receiver, and the second subset of the data bits is a subset of the first subset of the data bits; Encoding at least a second subset of the data bits using a polar code associated with a third polar code kernel structure, wherein the second subset of the data bits is encoded using bit channels of the third polar code kernel structure, and the reliability of the bit channels is relatively higher than the reliability associated with one or more bit channels used to encode the second subset of the data bits using the second polar code kernel structure for the first retransmission; And Sending a second retransmission to the receiver, the second retransmission including the polar-coded second subset of the data bits.

3. The method according to claim 1 or 2, further comprising: Sending to the receiver one or more of an indication of the first polar code kernel structure or the second polar code kernel structure for the first retransmission or an indication of a mapping of the first subset of the data bits to the bit channels of the second polar code kernel structure.

4. The method according to any one of claims 1 to 3, wherein the first feedback indicating that at least a first subset of the data bits has not been successfully decoded by the receiver includes one or more NACK messages.

5. The method according to any one of claims 1 to 4, further comprising: Determining a code rate for the initial transmission based on a modulation and coding scheme (MCS).

6. The method according to any one of claims 1 to 5, wherein the respective data bits are mapped to a first subset of the bit channels in the initial transmission and the first retransmission based on the respective reliability of the data bits.

7. The method according to any one of claims 1 to 6, wherein the first polar code kernel structure includes a first kernel order, a first kernel size, or a first kernel structure, and wherein the second polar code kernel structure includes a second kernel order, a second kernel size, or a second kernel structure.

8. The method according to any one of claims 1 to 7, further comprising: selecting the first polar code kernel structure based on channel quality, size of resources, encoder complexity, or reliability; and selecting the second polar code kernel structure based on a code rate, wherein the code rate is associated with a first transmission.

9. The method according to any one of claims 1 to 8, further comprising: determining a code rate for the first retransmission based on a predefined set of code rates.

10. The method according to any one of claims 1 to 8, further comprising: determining a code rate for the first retransmission based on a signal-to-noise ratio associated with the initial transmission.

11. An encoding device, comprising: a processor configured to: encode data bits using a polar code associated with a first polar code kernel structure; send an initial transmission to a receiver, the initial transmission including the polar-coded data bits; receive a first feedback for the initial transmission from the receiver, wherein the first feedback indicates that at least a first subset of the data bits has not been successfully decoded by the receiver; encode at least the first subset of the data bits that have not been successfully decoded by the receiver using a polar code associated with a second polar code kernel structure, wherein the first subset of the data bits is encoded using bit channels of the second polar code kernel structure, and the reliability of the bit channels is relatively higher than the reliability associated with one or more bit channels used to encode the first subset of the data bits using the first polar code kernel structure for the initial transmission; and send a first retransmission to the receiver, the first retransmission including the polar-coded first subset of the data bits associated with the second polar code kernel structure.

12. The encoding device according to claim 11, wherein the processor is further configured to: receive a second feedback for the first retransmission from the receiver, wherein the second feedback indicates that at least a second subset of the data bits has not been successfully decoded by the receiver, and the second subset of the data bits is a subset of the first subset of the data bits; encode at least the second subset of the data bits using a polar code associated with a third polar code kernel structure, wherein the second subset of the data bits is encoded using bit channels of the third polar code kernel structure, and the reliability of the bit channels is relatively higher than the reliability associated with one or more bit channels used to encode the second subset of the data bits using the second polar code kernel structure for the first retransmission; and send a second retransmission to the receiver, the second retransmission including the polar-coded second subset of the data bits.

13. The encoding device according to claim 11 or 12, wherein the processor is further configured to: Send one or more of an indication of the first polar code kernel structure or the second polar code kernel structure for the first retransmission or an indication of the mapping of the first subset of the data bits to the bit channels of the second polar code kernel structure to the receiver.

14. The encoding device according to any one of claims 11 to 13, wherein the first feedback indicating that at least the first subset of the data bits has not been successfully decoded by the receiver includes one or more NACK messages.

15. The encoding device according to any one of claims 11 to 14, wherein the processor is further configured to: Determine a code rate for the initial transmission based on a modulation and coding scheme (MCS).

16. The encoding device according to any one of claims 11 to 15, wherein the corresponding data bits are mapped to a first subset of the bit channels in the initial transmission based on the respective reliability of the data bits.

17. The encoding device according to any one of claims 11 to 16, wherein the first polar code kernel structure includes a first kernel order, a first kernel size, or a first kernel structure, and wherein the second polar code kernel structure includes a second kernel order, a second kernel size, or a second kernel structure.

18. The encoding device according to any one of claims 11 to 17, wherein the processor is further configured to: Select the first polar code kernel structure based on channel quality, size of resources, encoder complexity, or reliability; and Select the second polar code kernel structure based on a code rate, wherein the code rate is associated with a first transmission.

19. The encoding device according to any one of claims 11 to 18, wherein the processor is further configured to: Determine a code rate for the first retransmission based on a predefined set of code rates.

20. The encoding device according to any one of claims 11 to 18, wherein the processor is further configured to: Determine a code rate for the first retransmission based on the signal-to-noise ratio associated with the initial retransmission.

Images