[go: up one dir, main page]

WO2025034777A1 - Sélection adaptative de graphe de base pour codage ldpc - Google Patents

Sélection adaptative de graphe de base pour codage ldpc Download PDF

Info

Publication number
WO2025034777A1
WO2025034777A1 PCT/US2024/041169 US2024041169W WO2025034777A1 WO 2025034777 A1 WO2025034777 A1 WO 2025034777A1 US 2024041169 W US2024041169 W US 2024041169W WO 2025034777 A1 WO2025034777 A1 WO 2025034777A1
Authority
WO
WIPO (PCT)
Prior art keywords
wtru
performance
network
bgs
condition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2024/041169
Other languages
English (en)
Inventor
Anouar YATRIBI
Yugeswar Deenoo NARAYANAN THANGARAJ
Mihaela Beluri
Ahmet Serdar TAN
J. Patrick Tooher
Mohamed Salah IBRAHIM
Moon-Il Lee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
InterDigital Patent Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InterDigital Patent Holdings Inc filed Critical InterDigital Patent Holdings Inc
Publication of WO2025034777A1 publication Critical patent/WO2025034777A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/11—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits using multiple parity bits
    • H03M13/1102—Codes on graphs and decoding on graphs, e.g. low-density parity check [LDPC] codes
    • H03M13/1148—Structural properties of the code parity-check or generator matrix
    • H03M13/116—Quasi-cyclic LDPC [QC-LDPC] codes, i.e. the parity-check matrix being composed of permutation or circulant sub-matrices
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/65—Purpose and implementation aspects
    • H03M13/6508—Flexibility, adaptability, parametrability and configurability of the implementation
    • H03M13/6516—Support of multiple code parameters, e.g. generalized Reed-Solomon decoder for a variety of generator polynomials or Galois fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
    • H04L1/0027—Scheduling of signalling, e.g. occurrence thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
    • H04L1/0028—Formatting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0057—Block codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0075—Transmission of coding parameters to receiver

Definitions

  • a device e.g., a wireless transmit/receive unit (WTRU) may include a processor configured to perform one or more actions.
  • the device may send a request message for a base graph (BG) selection.
  • the device may receive a response message associated with the request message.
  • the response message may indicate a subset of a plurality of BGs associated with the WTRU.
  • the device may select, from the subset of the plurality of BGs, a BG for which a performance associated with the WTRU is determined to satisfy a threshold.
  • the device may send an indication of the selected BG.
  • the device may determine (e.g., be configured to determine) that a condition exists.
  • the determination that the performance associated with the WTRU satisfies the threshold may include a determination that the performance associated with the WTRU satisfies the threshold if the selected BG is used under the determined condition.
  • the determined condition may include one or more of a channel condition, a memory condition of the WTRU, or a CPU condition of the WTRU.
  • the device may determine (e.g., be configured to determine), based on a satisfaction of a triggering condition associated with the BG selection, to send the request message.
  • the device may be configured to send or receive a transport block using a low-density parity- check code generated from the selected BG.
  • FIG.1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.
  • FIG.1B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG.1A according to an embodiment.
  • WTRU wireless transmit/receive unit
  • FIG.1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG.1A according to an embodiment.
  • FIG.1D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG.1A according to an embodiment.
  • FIG.2 is an example structure of LDPC BGs that may be adopted in a network NR (e.g., 5G NR).
  • FIG.3 is an example FNSPA decoding architecture with 3 decoding iterations for a code.
  • FIG.4 is an example of two unfolds of a Relaxed RNN based NBP architecture.
  • FIG.5 is an example BLER performance comparison of a PR- LDPC code generated using a designed BG with a 3GPP 5G NR LDPC BG2.
  • DETAILED DESCRIPTION [0017]
  • FIG.1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single-carrier FDMA
  • ZT UW DTS-s OFDM unique word OFDM
  • the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.
  • UE user equipment
  • PDA personal digital assistant
  • smartphone a laptop
  • a netbook a personal computer
  • the communications systems 100 may also include a base station 114a and/or a base station 114b.
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 104/113, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
  • BSC base station controller
  • RNC radio network controller
  • the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum.
  • a cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • beamforming may be used to transmit and/or receive signals in desired spatial directions.
  • the base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 116 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • LTE-A Pro LTE-Advanced Pro
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).
  • NR New Radio
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies.
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles.
  • DC dual connectivity
  • the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., a eNB and a gNB).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.11 i.e., Wireless Fidelity (WiFi)
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA20001X, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for
  • the base station 114b in FIG.1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • WLAN wireless local area network
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • the base station 114b and the 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 picocell or femtocell.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the CN 106/115.
  • the RAN 104/113 may be in communication with the 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 the WTRUs 102a, 102b, 102c, 102d.
  • the data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like.
  • QoS quality of service
  • the CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT.
  • the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
  • the CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112.
  • the PSTN 108 may include circuit- switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers.
  • the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.
  • Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links).
  • the WTRU 102c shown in FIG.1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
  • FIG.1B is a system diagram illustrating an example WTRU 102.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others.
  • GPS global positioning system
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116.
  • a base station e.g., the base station 114a
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the transmit/receive element 122 is depicted in FIG.1B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.
  • 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.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like.
  • an accelerometer an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity track
  • the peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.
  • the WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the 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 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118).
  • the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).
  • FIG.1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the CN 106.
  • the RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode-Bs 160a, 160b, 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like.
  • the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the CN 106 shown in FIG.1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
  • the MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
  • the MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.
  • the SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface.
  • the SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
  • the SGW 164 may perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
  • the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.
  • IP gateway e.g., an IP multimedia subsystem (IMS) server
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRU is described in FIGS.1A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.
  • the other network 112 may be a WLAN.
  • a WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP.
  • the AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS.
  • Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs.
  • Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations.
  • DS Distribution System
  • Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA.
  • the traffic between STAs within a BSS may be considered and/or referred to as peer-to- peer traffic.
  • the peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS).
  • the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS).
  • a WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other.
  • the IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication.
  • the AP may transmit a beacon on a fixed channel, such as a primary channel.
  • the primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling.
  • the primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP.
  • Carrier Sense Multiple Access with Collision Avoidance may be implemented, for example in in 802.11 systems.
  • the STAs e.g., every STA, including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off.
  • One STA e.g., only one station
  • High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.
  • VHT STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels.
  • the 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels.
  • a 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration.
  • the data, after channel encoding may be passed through a segment parser that may divide the data into two streams.
  • Inverse Fast Fourier Transform (IFFT) processing, and time domain processing may be done on each stream separately.
  • IFFT Inverse Fast Fourier Transform
  • the streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA.
  • the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).
  • MAC Medium Access Control
  • 802.11af and 802.11ah The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac.802.11af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum.
  • 802.11ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area.
  • MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths.
  • the MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).
  • WLAN systems which may support multiple channels, and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel which may be designated as the primary channel.
  • the primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS.
  • the bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode.
  • the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes.
  • Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.
  • STAs e.g., MTC type devices
  • NAV Network Allocation Vector
  • FIG.1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment.
  • the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 113 may also be in communication with the CN 115.
  • the RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment.
  • the gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the gNBs 180a, 180b, 180c may implement MIMO technology.
  • gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c.
  • the gNB 180a may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • the gNBs 180a, 180b, 180c may implement carrier aggregation technology.
  • the gNB 180a may transmit multiple component carriers to the 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.
  • the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology.
  • WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).
  • CoMP Coordinated Multi-Point
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum.
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time).
  • TTIs subframe or transmission time intervals
  • the gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration.
  • WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c).
  • WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point.
  • WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band.
  • WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c.
  • WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously.
  • eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.
  • Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG.1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.
  • UPF User Plane Function
  • AMF Access and Mobility Management Function
  • the CN 115 shown in FIG.1D may include at least one AMF 182a, 182b, at least one UPF 184a,184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are 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. [0064]
  • the AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node.
  • the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like.
  • Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c.
  • the AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
  • the SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface.
  • the SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface.
  • the SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b.
  • the SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like.
  • a PDU session type may be IP-based, non-IP based, Ethernet- based, and the like.
  • the UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.
  • the CN 115 may facilitate communications with other networks.
  • the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108.
  • IP gateway e.g., an IP multimedia subsystem (IMS) server
  • IMS IP multimedia subsystem
  • the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
  • DN local Data Network
  • one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown).
  • the emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein.
  • the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.
  • the emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment.
  • the one or more emulation devices may perform the 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 in order to test other devices within the communication network.
  • the one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.
  • the one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components.
  • the one or more emulation devices may be test equipment.
  • Direct RF coupling and/or wireless communications via RF circuitry may be used by the emulation devices to transmit and/or receive data.
  • RF circuitry e.g., which may include one or more antennas
  • a device e.g., a WTRU
  • a device may include a processor configured to perform one or more actions. The device may determine a measurement associated with a current BG and a performance metric associated with the current BG. The device may send an indication based on the measurement and the performance metric. The device may receive a BG selection response.
  • the BG selection response may include a candidate subset of BGs and candidate information for each respective BG in the candidate subset of BGs.
  • the device may select a BG from the candidate subset of BGs based on the candidate information. [0073]
  • the device may send a BG selection request.
  • the device may send a report indicating the BG selected from the candidate subset of BGs.
  • selecting a BG from the candidate subset of BGs may be based on a condition of the WTRU.
  • the candidate information for each respective BG in the candidate subset of BGs may include one or more of: an index of the respective BG, a pair of signal-to-noise (SNR) and block error rate (BLER), an SNR value at which a target BLER is reached, dimensions of the respective BG, a list of average decoding iterations required for each SNR value and for each code rate, or a code rate range supported by the respective BG.
  • SNR signal-to-noise
  • BLER block error rate
  • the device may send a first set of assistance information associated with base graph (BG) generation.
  • the device may receive a request for a second set of assistance information associated with BG generation.
  • the request for a second set of information may include a transmission configuration.
  • the device may send the second set of assistance information based on the transmission configuration.
  • the second set of assistance information may indicate a pruning transport block (PTB).
  • the device may receive performance information for a BG.
  • the device may determine whether the BG satisfies the performance target based on the performance information for the BG.
  • the device may send an indication based on the determination of whether the BG satisfies the performance target. [0079]
  • the device may receive a request for the first set of assistance information.
  • the device may determine a condition is met prior to sending the first set of assistance information. [0081] The device may determine whether the BG satisfies a constraint of the WTRU based on a current condition of the WTRU. The indication may be based on the determination of whether the BG satisfies the constraint of the WTRU. [0082]
  • the transmission configuration may include one or more of: a PTB configuration, a mini batch size, a periodicity of PTB transmissions, or a number of PTBs per period.
  • the second set of assistance information may include the PTB.
  • LDPC base-graphs e.g., new LDPC base-graphs
  • a data driven artificial intelligence (AI)/machine learning (ML) aided design approach, online training, and/or pruning of NBP decoder(s) may be applied to adaptively design more efficient code(s) specific to WTRU’s reported applicable condition(s) (e.g., use case(s), channel condition(s), WTRU processing latency, etc.).
  • Feature(s) associated with network e.g., 5G network
  • NR new radio
  • LDPC low-density parity-check
  • Protograph low-density parity-check (PR-LDPC) codes may be defined for a channel coding procedure in network NR (e.g., 5G NR) for data channels.
  • Multiple (e.g., two) base-graphs (BGs) may be adopted.
  • a first BG, BG1 may be adopted for long information block lengths (e.g., 500 ⁇ K ⁇ 8448) and intermediate-to-high code rates (e.g., 1/3 ⁇ R ⁇ 8/9).
  • a second BG, BG2 may be adopted to target short to moderate information block lengths (e.g., 40 ⁇ K ⁇ 3824) and low to intermediate code rates (e.g., 1 ⁇ 5 ⁇ R ⁇ 2 ⁇ 3).
  • Two BGs may cover a wide range of block lengths and code rates by using different values of an expansion factor.
  • the different values of the expansion factor may be organized in 8 different lifting size sets with each set containing a subset of various values (e.g., which may result in a large number of different parity-check matrices (PCMs) covering a wide range of sizes).
  • PCMs parity-check matrices
  • the design of the BGs may support puncturing and shortening, which may help to achieve flexibility and/or to support incremental redundancy (IR) hybrid automatic repeat request (HARQ) retransmission techniques.
  • the dimensions of the BGs may be 46 ⁇ 68 and 42 ⁇ 52, respectively.
  • the maximum number of parallel edges of the BGs may be 384 for BG1 and 256 for BG2.
  • the expansion process after rate- matching may allow for transformation of the BG to a binary PCM with a given size (e.g., depending on a calculated expansion factor Z).
  • the expansion procedure may be a copy and permute operation.
  • the expansion procedure may map each entry of the BG to a Z ⁇ Z identity matrix.
  • a resulting PCM may have a quasi-cyclic structure.
  • the resulting PCM may allow for layered BP decoding and/or a simplest representation.
  • the design approach of the BGs (e.g., BG 1 and BG2) may be based on asymptotic assumptions for very long codes (e.g., infinitely long block lengths).
  • the structure of the two BGs may enable a useful property (e.g., properties) (e.g., satisfactory performance over the entire SNR range and/or low decoding thresholds and error floors).
  • the structure of the proto-matrices representing the BGs may incorporate punctured column(s), information column(s), core parity column(s), and/or extension parity column(s) (e.g., in standardized PR-LDPC codes). Degree-1 columns may be considered for improving performance and/or simplifying the encoding process by precoding.
  • the rows structure may include core check row(s) and extension check row(s).
  • a submatrix delimited by extension parity columns and core check rows may be an all-zero matrix (e.g., helping the underlying code(s) to be rate-compatible and nested).
  • the lower right portion of the proto-matrix (e.g., that may be delimited by extension check rows and extension parity columns) may be an identity matrix, for example, to enable support of IR-HARQ retransmissions.
  • FIG.2 depicts an example structure of LDPC BGs that may be adopted in a network NR (e.g., 5G NR).
  • 5G NR e.g., 5G NR
  • the BG selection method may be based on payload size and code rate.
  • An appropriate BG to employ for channel encoding/decoding may be selected based on payload size and/or code rate.
  • one or more of the following may be performed as part of a BG selection method (e.g., as may be used in 5G NR).
  • each code block of the transport block may be encoded according to the following: if A ⁇ 292, or if A ⁇ 3824 and R ⁇ 0.67, or if R ⁇ 0.25, LDPC BG2 may be used; otherwise, LDPC BG1 may be used.
  • the same BG selection method may be used for subsequent re-transmission of the same transport block.
  • ML models may suffer from a large computational and storage complexity (e.g., due to a large number of weights and/or layers in the model architecture).
  • the complexity of the ML model may have a direct impact on the training and inference time (e.g., of the ML Model).
  • a large ML model may experience overfitting or out-of-distribution, which may impact the generalization capacity of the model.
  • Model pruning may be a practical approach for compressing ML models and/or improving their generalizability (e.g., while reducing the storage complexity). Pruning an ML model may include eliminating weights (e.g., edges) or neurons that may have less impact on the model accuracy (e.g., so that the performance may be compromised with complexity).
  • Pruning some ML models may help to improve the performance while compressing the model.
  • a pruning approach may be based on one-shot pruning.
  • a (e.g., different) pruning approach may include iterative pruning. Pruning a model may be performed on either the edges (e.g., replacing the weights by zero) or on the neurons (e.g., by avoiding duplicated neurons that have similar weights after activation functions).
  • An evaluation metric used for pruning may be the magnitude of the weights, or the L2-norm, amongst other possible measurement(s).
  • the decision rule for edge selection may be based on a pre-defined threshold value.
  • the decision rule for edge selection may be based on pruning edge(s) (e.g., one or a set of edges) that have the minimum magnitude per each pruning iteration.
  • a BG pruning procedure may include one or more of the following.
  • the BG may be converted to an unrolled DNN graph across the number of neural belief propagation (NBP) decoding iterations.
  • the NBP decoder may train the edges of the BG (e.g., a semi-random dense BG generated according to the configuration) using a data-driven approach, for example, by feeding the received PTBs transmitted over specific conditions.
  • edge(s) e.g., one or a set of edges
  • the pruning process may be iterative until a final BG is obtained when stopping criteria is met.
  • NBP neural belief propagation
  • LDPC BG design Feature(s) associated with neural belief propagation (NBP) decoding and LDPC BG design are provided herein.
  • NBP may be used to decode all linear block codes with low complexity and/or low latency. NBP may be an approach to make the decoding block data-driven and to further enhance the performance.
  • NBP may include considering the unrolled version of the Tanner Graph across all the decoding iterations (e.g., to learn the edges connecting variable nodes to check nodes). Using NBP for decoding linear block codes may be done to compensate for the negative impact of short cycles (e.g., that may be a cause (e.g., main cause) of performance degradation in BP). If the edges are learned optimally, the messages passed from edges arising from short cycles may be attenuated (e.g., may result in the decoder minimizing the error propagation effect caused by the existence of short cycles).
  • short cycles e.g., that may be a cause (e.g., main cause) of performance degradation in BP.
  • the NBP may be applied to different variants of the BP (e.g., similar to a plain BP), which may enable consideration of simplified check-node updates (e.g., to lower complexity and latency while improving performance compared to the plain BP-SPA).
  • the NBP may be used to decode PR-LDPC codes (e.g., to improve their performance).
  • the NBP may be presented by a DNN (e.g., with an input layer fed by the LLR initializations).
  • the number of processing units (e.g., neurons) in the input layer may be equal to the code length n.
  • the DNN structure may include hidden layer(s) (e.g., several hidden layers).
  • Each unfold of hidden layers may represent a VN update layer followed by a CN update layer. These layers may be followed by a marginalization layer (e.g., depending on the architecture of the NBP). If the hidden layer(s) are followed by a marginalization layer, the DNN may not be processed entirely during the inference phase (e.g., because the marginalization layer may output LLR estimate(s) that enable the calculation of the syndrome weight, used as stopping criteria).
  • the output layer of the NBP model may include n LLR estimates activated using a Sigmoid function.
  • the NBP may have an RNN architecture that includes Lmax unfolds. There may be (e.g., alternatively) one marginalization layer as an output layer.
  • the number of hidden layers may be equal to 2Lmax, and the architecture may be feed-forward (FF).
  • the DNN graph architecture of the NBP may be related to the Tanner Graph.
  • the layers may not be fully connected.
  • the neurons of the NBP may be the nodes (e.g., CNs and VNs) of the Tanner Graph.
  • the edges may be the connections between these nodes (e.g., non-zero elements of the PCM associated to the code). [0102]
  • the edges of the NBP may be trained across all the iterations and/or have different weights.
  • the NBP architecture may be FF.
  • the NBP architecture may be RNN and may include a repetition of the same unfold (e.g., VN layer -> CN layer -> marginalization layer).
  • the weights may be tied spatially and/or temporally All the edges may share the same weight across all decoding iterations.
  • This simplified architecture may be called Simple Scaling (SS).
  • SS may significantly reduce storage requirements, training, and/or inference decoding complexity.
  • VN layer [0104]
  • ⁇ ′ ( ⁇ ′ , ⁇ ), ⁇ ′ ⁇ ⁇ [0106]
  • the intrinsic weights w(i,v) and marginalization weights w(2L+1,v) may have negligible impact on the performance (e.g., in contrast to the weights used in the VN layer and in the CN layer for the simplified variants).
  • the intrinsic weights w(i,v) and marginalization weights w(2L+1,v) may be discarded.
  • the trainable weight In the FNMS the trainable weight may be the normalization factor. In the FNOMS, the trainable weight may be the offset parameter. When the trainable weight(s) are equal to 1, the algorithm may be similar to the plain BP.
  • the NBP decoders may be guaranteed (e.g., if learned properly) to perform better than other decoders if the weights are initialized by 1 before training.
  • FF and RNN based architectures of the NBP are illustrated in FIGS.3 and 4.
  • FIG.4 depicts an example of two unfolds of a Relaxed RNN based NBP architecture.
  • FIG.3 depicts the unrolled Tanner Graph across decoding iterations (e.g., 5 iterations).
  • the nodes in the first hidden layer e.g., Atanh+tanh neurons
  • the messages may be initialized by zeros and (e.g., only) the CN update may be calculated.
  • the second layer nodes may correspond to VNs, while the following nodes (e.g., Atanh neurons) may be CNs.
  • the edges connecting the layers of nodes may be the position(s) of non-zero entries in the PCM (e.g., based on which the reliability messages may be calculated and passed).
  • the output of the DNN may be the result of the marginalization layer, which may output n estimates of the LLRs corresponding to each coded bit.
  • Another trainable parameter may be added to further improve the performance of the NBP by ML technique(s). This trainable parameter may be referred to as a relaxation or dumping parameter ⁇ .
  • the resulting decoder may be relaxed.
  • the relaxation factor may accelerate the convergence speed.
  • the relaxation factor may improve performance (e.g., by applying an exponentially weighted moving average to combine the message sent at iteration i-1 with the raw message computed in iteration i).
  • the decoder may be less relaxed as ⁇ approaches 0, and more relaxed as ⁇ approaches 1.
  • One function may be the binary cross-entropy (BCE) multi-loss function, which may update the gradients after each decoding iteration (e.g., resulting in a performance improvement and faster training convergence, in contrast to other BCE).
  • BCE binary cross-entropy
  • the multi-loss BCE function may take the following form: log( ⁇ ⁇ , ⁇ ) + ( 1 ⁇ ⁇ ⁇ ) log(1 ⁇ ⁇ ⁇ , ⁇ ) where o(v,i) may be the output of the neural network for the v th component of the transmitted codeword at the i th decoding iteration, while yv may be the actual transmitted codeword symbol (e.g., label).
  • Other loss functions may be considered in the NBP schemes, such as the soft bit error rate loss function and/or the soft syndrome weight loss function (e.g., which may allow training to be unsupervised). These functions may be combined into one general loss function.
  • Feature(s) associated with technical and structural requirements of LDPC BG design are provided herein. The design of a robust LDPC BG may be subject to mathematical, structural, and/or technical requirements that may be jointly met or compromised. Long BGs may have different requirements than short BGs.
  • the technical requirements for designing BGs for PR-LDPC codes may include one or more of the following: low density; irregularity for achieving low decoding thresholds; low error floors (e.g., avoiding short cycles and trapping sets); robust performance (e.g., avoiding short cycles and/or degree distribution optimization); quasi-cyclic structure (e.g., supporting parallel decoding implementations, such as layered BP decoding, and low BG storage requirements); support of the IR-HARQ retransmission techniques; or support of rate-matching (e.g., puncturing and shortening).
  • a design for obtaining an efficient BG may consider one or more of the following structural constraints: control and optimize the number of parallel edges in the BG; optimize the degree distribution; linear minimum distance growth with regard to the codelength; low iterative decoding threshold; or maximize the girth of the BG.
  • the structural constraint of linear minimum distance growth with regard to the codelength may be implemented.
  • a design for obtaining an efficient BG may include VNs with degrees at least equal to 3 and/or include a substantial number of degree-2 VNs (e.g., less than nc-1, where nc may be the number of CNs (e.g., rows of the BG)).
  • the structural constraint of a low iterative decoding threshold may be implemented.
  • a design for obtaining an efficient BG may include at least one very high degree VN (e.g., optionally punctured), one or more degree-1 VNs (e.g., precoders), and/or degree-2 VNs.
  • VN very high degree VN
  • degree-1 VNs e.g., precoders
  • degree-2 VNs e.g., precoders
  • ML techniques and a data-driven on the air approach may be exploited to meet the above criteria and/or requirement(s).
  • the two standardized LDPC BGs in a network NR e.g., BG1 and BG2 may cover a wide range of code rates and information block length.
  • BG1 may be for long payload sizes and intermediate-to-high code rates, while BG2 may be for low to moderate code rates and short-to- intermediate block lengths. There may be no specific BG targeting both short block length and high code rates. Performance of the two BGS may be mediocre in those specific regimes.
  • the design approach of BG1 and BG2 may be based on theoretical assumptions in coding theory related to asymptotical infinite block length regimes (e.g., while supporting puncturing which may add latency and penalize the channel coding reliability).
  • the BG selection procedure in a network NR may be (e.g., only) based on conditions related to payload size and code rate (e.g., without considering the applicable conditions and generalization/scalability to new scenarios and use-cases). Limitations when considering scalability and the support of different specific applicable conditions, such as channel condition, scenarios/use-cases, MIMO rank, waveform, and hardware configuration, may be addressed. [0123] A careful approach, for example based on the recent advances in ML techniques and driven by data over the air interface, may be implemented.
  • BGs for short block length may not (e.g., completely) avoid the existence of short cycles that may reduce decoding performance.
  • the use of ML based NBP decoders for decoding LDPC codes may lead to a significant performance improvement (e.g., at the cost of reasonable complexity).
  • the structure of NBP decoders may be exploited to learn a BG structure by using pruning techniques. A dense BG may be trained iteratively and pruned subsequently based on the edges that may be irrelevant to the decoding performance.
  • a sparser BG with robust performance may be trained on a specific channel condition captured by the dataset used for training.
  • Feature(s) associated with adaptive BG selection and signaling are provided herein.
  • a WTRU may support a set of BGs (e.g., for LDPC channel coding and/or error correction as described herein).
  • the set of BGs for LDPC error correction may be WTRU-specific (e.g., specific to the WTRU).
  • the WTRU may determine (e.g., select) a BG (e.g., a preferred BG) from the set of supported WTRU-specific BGs, for example based on a condition, e.g., determine the preferred BG as a function of measured condition(s) (e.g., channel condition(s)) and/or decoder performance indicator(s) (e.g., memory, number of iterations, processing latency).
  • the WTRU may report (e.g., to a network entity such as a base station) the BG that was selected from the set of supported WTRU-specific BGs (e.g., the preferred BG).
  • a WTRU may perform one or more of the following, for example, associated with determining a preferred BG from a supported set of WTRU-specific BGs for error correction.
  • a WTRU may support a set of WTRU-specific BGs for LDPC error correction. The WTRU may determine that trigger condition(s) are met.
  • Trigger condition(s) may include one or more of the following: a NACK rate exceeding a configured threshold; detection of a change in channel condition(s) (e.g., satisfying a threshold) or traffic type; or detection of a mismatch between a reference performance of a BG and associated operating condition(s) compared to the actual performance/condition(s) (e.g., where conditions may refer to channel conditions, payload size, or the like).
  • the WTRU may send a BG selection request (e.g., based on one or more of the trigger condition(s) being satisfied and/or an indication from the network).
  • the WTRU may determine measurements and/or historical WTRU performance associated with the current configuration (e.g., BG).
  • the WTRU may report measurements and/or historical WTRU performance (e.g., a performance metric) associated with the current configuration (e.g., BG).
  • Performance metric(s) of the current BG (e.g., performance of the WTRU when using the current BG) may include one or more of: average memory use/availability; peak memory use/availability; complexity (e.g., CPU use/availability); number of iterations; or processing latency.
  • Measurement(s) associated with the current BG may include one or more of: channel conditions (e.g., WTRU speed, doppler, delay spread); or MIMO rank.
  • the WTRU may receive a BG selection response.
  • the BG selection response may include a candidate subset of BGs (e.g., a subset of the supported set of WTRU-specific BGs).
  • Information associated with each BG in the candidate subset may include one or more of: an index of the BG; SNR values at which a target BLER may be reached (e.g., pairs of (SNR, BLER)); BG dimensions; list(s) of average decoding iterations required for each SNR value and for each code rate; or supported code rate (e.g., range).
  • the WTRU may select a BG from the candidate subset.
  • the BG from the candidate subset may be selected based on a function of the BG candidate performance and/or WTRU specific conditions and/or requirements.
  • the WTRU may select a BG (e.g., from the candidate subset) based on a condition, e.g., select the BG based on WTRU determined condition(s) (e.g., channel conditions, memory, and CPU requirements/constraints) and/or the performance of the BG (e.g., performance of the WTRU under the WTRU determined condition(s) if using the BG).
  • a condition e.g., channel conditions, memory, and CPU requirements/constraints
  • the performance of the BG e.g., performance of the WTRU under the WTRU determined condition(s) if using the BG.
  • the WTRU may select a BG (e.g., from the candidate subset) for which WTRU transmission and/or reception performance is maximized or is above (e.g., satisfies) a threshold for the reported WTRU condition(s) (e.g., the WTRU determined condition(s)).
  • the selected BG may be a function of the reported rank (e.g., where a different BG may be selected based on the SNR for each layer).
  • the WTRU may report the selected BG to a network node (e.g., a gNB).
  • the WTRU may transmit and/or receive encoded TBs using the selected BG (e.g., begin transmitting/receiving encoded TBs using the selected BG after the selection and/or reporting of the BG).
  • a network node e.g., a gNB
  • the WTRU may transmit and/or receive encoded TBs using the selected BG (e.g., begin transmitting/receiving encoded TBs using the selected BG after the selection and/or reporting of the BG).
  • Feature(s) associated with WTRU-assisted BG generation and performance monitoring are provided herein.
  • a WTRU may support a (e.g., WTRU-specific) BG for LDPC error correction.
  • the WTRU may provide assistance information for NW-based BG generation.
  • the WTRU may receive a BG (e.g., a new BG) and/or performance information associated with the BG (e.g., new BG).
  • the WTRU may determine if the BG (e.g., new BG) is applicable (e.g., based on WTRU condition(s)).
  • the BG e.g., new BG
  • the BG may be applicable if the BG (e.g., new BG) meets a performance target based on the performance information for the BG and/or if the BG (e.g., new BG) meets a constraint of the WTRU based on a current condition of the WTRU.
  • An applicable BG may be a BG that meets the constraints of the WTRU (e.g., memory, processing speed/latency), while meeting the performance target(s) (e.g., attaining target BLER at a specified SNR).
  • the WTRU may report the determination outcome (e.g., that the BG is applicable, that the BG is not applicable, etc.) to the network (e.g., a network node such as a gNB).
  • a WTRU may perform one or more of the following , for example if assisting a network with BG generation and/or performance monitoring.
  • a WTRU supporting a WTRU-specific BG may be triggered to provide assistance information for network-based BG generation.
  • the trigger may be one or more of: an indication from the network; or an event-based trigger (e.g., the WTRU determining that a condition is met (e.g., NACK rate exceeding a threshold, number of decoding iterations exceeding a threshold, etc.).
  • the WTRU may report a first set of assistance information for BG generation.
  • the first set of assistance information may include (e.g., indicate) one or more of: a memory size (e.g., maximum available memory size); a number of decoder iterations (e.g., average number of decoder iterations); a NACK rate (e.g., average NACK rate); a payload size (e.g., average payload size) measured by the WTRU (e.g., to determine if the WTRU is operating in the low payload regime); or legacy CSI reports.
  • the WTRU may receive an indication and/or a configuration to transmit a second set of assistance information.
  • the second set of assistance information may include one or more pruning transport blocks (PTB) (e.g., used to enhance the dataset for data-assisted BG generation).
  • the configuration may include one or more of a PTB configuration; a batch size (e.g., a minimum batch size); a periodicity of PTB transmissions; or a number of PTBs per period.
  • the WTRU may perform one or more PTB transmissions (e.g., without HARQ retransmissions).
  • the WTRU may indicate the identity of the PTB explicitly (e.g., index to a set of pre-defined PTBs) or implicitly.
  • the WTRU may receive a BG (e.g., new BG) from the network.
  • BG e.g., new BG
  • the WTRU may receive performance information associated with the BG (e.g., new BG generated by the network).
  • Performance information associated with a BG may include one or more of a performance of the BG (e.g., BLER); a cumulative loss of intermediate BG evaluation; a number of short cycles; a number of degree-1 and/or degree-2 variable nodes (VN); or an average number of decoding iterations over a set of SNR values.
  • the WTRU may determine if the received BG is applicable. The determination may be based on a comparison of the received BG information (e.g., performance information associated with the BG) to WTRU conditions (e.g., the current WTRU conditions).
  • the received BG may be applicable if the BG meets a performance target based on the performance information for the BG and/or if the BG meets a constraint of the WTRU based on a condition (e.g., current condition) of the WTRU.
  • An applicable BG may be a BG that meets the constraints of the WTRU (e.g., memory, processing speed and/or latency), while meeting a performance target (e.g., attaining target BLER at a specified SNR).
  • the WTRU may report, e.g., to the network, the determination of whether the BG is applicable.
  • Pruning transport blocks may refer to a predefined codeword for enabling data-driven adaptive BG pruning (generation).
  • Applicable BG may refer to a BG that meets the constraint(s) of the WTRU (e.g., memory, processing speed/latency) and/or meets performance target(s) (e.g., attaining target BLER at a specified SNR).
  • BG pruning procedure may refer to an iterative process to train the weights of a decoder for LDPC codes. A (e.g., each) pruning iteration may lead to a lower density BG. The process may stop when set criteria (e.g., stopping condition(s)) is met.
  • a set of WTRU-specific BG may refer to a set of BGs supported by the WTRU.
  • the set of WTRU- specific BGs may include BGs that were (e.g., dynamically) determined to match to specific channel condition(s) and/or WTRU hardware capabilities and/or constraint(s).
  • Candidate BG subset may refer to a subset of the “set of WTRU-specific BGs” (e.g., signaled by the NW).
  • Feature(s) associated with adaptive BG selection and signaling are provided herein.
  • a WTRU may be configured for adaptive BG selection.
  • the WTRU may be configured or indicated to determine one or more parameter(s) associated with WTRU-specific base-graph selection.
  • the configuration parameter(s) may include a higher layer parameter BG selection indicator.
  • the higher layer BG selection indicator may be a binary bit indicating to the WTRU whether a BG selection procedure is enabled or not. For example, if set to a value (e.g., 1), the WTRU may assume that WTRU-specific BG selection is required, e.g., based on one or more conditions (e.g., one or more channel conditions).
  • the WTRU may be configured to select a BG periodically, semi-persistently or aperiodically.
  • the WTRU may send a BG selection request based on one or more trigger conditions, for example, a significant change (e.g., a change that satisfies a threshold) in a channel condition.
  • the WTRU e.g., in response to a BG selection request (e.g., sent by the WTRU), may be configured with (e.g., may receive an indication of) a candidate subset of BGs.
  • the candidate subset of BGs may include a set of WTRU-specific BGs.
  • the WTRU may be configured with one or more BGs.
  • the WTRU may be configured with cell-specific BGs and/or WTRU-specific BGs.
  • a BG may be configured with a BG ID and/or BG parameter(s).
  • the WTRU may be configured with (e.g., may receive an indication of) a BG (e.g., via SSB, PBCH, DCI, MAC CE, or RRC configuration). For example, a WTRU may monitor a DCI with a specific RNTI to receive a BG (e.g., new, or updated). A WTRU may report measurement(s) associated with one or more BGs (e.g., to enable indication of configuration or scenario that may enable configuration of appropriate BG(s)). [0152] A WTRU may receive one or more configurations of one or more BGs.
  • the WTRU may receive an indication of a set of activated BGs (e.g., a subset of all configured BGs).
  • the indication of a set of activated BGs may be received via DCI, MAC CE, or RRC signaling (e.g., from a network node, such as, in examples, a base station).
  • a WTRU may receive an indication to de-activate one or more BGs.
  • the WTRU may receive an indication to add or remove one or more BGs from a set of activated BGs.
  • the indication to activate, add, and/or remove one or more BGs from a set of active BGs may be a bitmap associated to BG ID(s).
  • Each candidate subset may have an associated set of predefined attribute(s) known at both the WTRU and a network node (e.g., gNB).
  • each candidate subset may have one or more of the following features: range of code rates; range of information block lengths; channel quality condition(s); ML model information; memory use/size; latency; or performance metric(s) associated with the candidate subset (e.g., average BLER).
  • Channel quality conditions may include one or more of: SNR range, Doppler range, delay spread range, or rank range. For example, one subset of BGs may be trained under low to intermediate rank values while another may be trained under high rank values.
  • ML model information may include the ML model ID used to rank the candidate subset and/or ML model parameter(s).
  • the candidate BG and/or its associated parameter(s) may be indicated by the network (e.g., by a node such as a gNB), for example in a DCI, MAC CE, or RRC message.
  • the BG configuration may include some assistance information associated with the candidate BG (e.g., channel condition(s) used for training the candidate set) to assist the WTRU with the BG determination (e.g., preferred BG determination).
  • assistance information associated with the candidate BG e.g., channel condition(s) used for training the candidate set
  • Feature(s) associated with indication of a determined BG are provided herein.
  • a WTRU may be configured to determine, select, and/or report a BG from the configured candidate subset. The determination may be based on WTRU measurement(s) (e.g., channel conditions), complexity, and/or latency requirements.
  • the WTRU may be configured to transmit (e.g., indicate) the BG (e.g., preferred BG, index) and the associated parameter(s) (e.g., expected processing) via UCI, in a PUSCH resource, and/or in MAC CE.
  • the WTRU may transmit (e.g., indicate) the BG (e.g., preferred BG, index) in a PUSCH resource while transmitting the associated parameter(s) via UCI.
  • the WTRU may be configured to transmit (e.g., indicate) the BG (e.g., preferred BG , index) periodically while other parameter(s) may be transmitted semi-persistently or aperiodically.
  • Feature(s) associated with WTRU trigger(s) for BG selection are provided herein.
  • a WTRU may be configured to determine/select a BG (e.g., preferred BG) from a configured candidate subset of BGs (e.g., as described herein). The determination may be based on WTRU measurement(s).
  • the WTRU may be triggered to determine or update parameter(s) of the BG (e.g., preferred BG).
  • the parameter(s) of the BG may include one or more of the following: an index that indicates the BG (e.g., preferred BG); associated processing latency; performance Indicator (e.g., average BLER); or number of iterations.
  • the trigger(s) to determine or update the parameter(s) of the BG may include or be based on one or more of: time, measurement(s), change in scenario configuration, performance of an associated function, based on feedback resource selection, or based on a feedback payload.
  • Time may be a trigger to determine or update the BG parameter(s) (e.g., preferred).
  • the WTRU may be configured with time instances or slot(s) when the WTRU may determine one or more BG parameters.
  • a measurement (e.g., performed by the WTRU) may be a trigger to determine or update the BG parameter(s) (e.g., preferred).
  • the WTRU may perform measurement(s).
  • the WTRU may, based on the measurement(s) achieving certain threshold(s) or satisfy a condition, be triggered to determine one or more BG parameters.
  • the WTRU may measure and monitor the BG performance in terms of BLER (e.g., number of NACKs).
  • the WTRU may determine one or more BG parameters (e.g., different BG index, or different number of iterations).
  • the WTRU may perform channel related measurement(s) (e.g., one or more of WTRU speed, RSSI, RSRQ, RSRP, SINR, Channel Occupancy (CO), Doppler spread, Doppler shift, Delay spread, Average Delay, AoA, or AoD). Based on the value(s) obtained for one of the measurements, the WTRU may be triggered to determine/select/switch one or more BG parameters.
  • channel related measurement(s) e.g., one or more of WTRU speed, RSSI, RSRQ, RSRP, SINR, Channel Occupancy (CO), Doppler spread, Doppler shift, Delay spread, Average Delay, AoA, or AoD.
  • the WTRU may determine that a change in the BG set may be needed if a change (e.g., a change that satisfies a threshold) in one of the aforementioned channel-related measurements occurs.
  • a change in scenario or configuration may be a trigger to determine or update the BG parameter(s) (e.g., preferred). For example, if a WTRU determines or receives an indication of a change in scenario or configuration used for training the currently used BG, the WTRU may determine one or more BG parameters.
  • Performance of an associated function may be a trigger to determine or update the BG parameter(s) (e.g., preferred).
  • the WTRU may determine the performance of DL transmission(s) (e.g., the rate of HARQ-NACK). If the performance satisfies a threshold (e.g., below or above), the WTRU may determine one or more BG parameters.
  • Determining or updating the BG parameter(s) may be triggered based on feedback resource selection, a feedback resource, and/or a change thereof. Determining or updating the BG parameter(s) (e.g., preferred, by a WTRU) may be triggered based on a feedback payload. For example, the WTRU may determine one or more BGs if a feedback payload associated with BG reporting changes (e.g., from a previous feedback transmission).
  • Feature(s) associated with measurement reporting in support of BG selection are provided herein.
  • a WTRU may be using a data-driven BG or a legacy BG for uplink and downlink.
  • a WTRU may maintain historical performance associated with that LDPC BG configuration.
  • Historical performance may be used to assist the adaptive BG selection procedure (e.g., BG switching).
  • Historical performance assistance information related to the BG configuration may include one or more of: average memory use/availability; peak memory use/availability; complexity; or processing latency (e.g., in UL and DL).
  • Complexity may be determined in terms of CPU use/availability and/or battery life consumption (e.g., in uplink and/or downlink).
  • the complexity of uplink may be related to the rate-matching and bit selection procedure while using the BG.
  • the complexity of uplink may be related to dynamic generation of the encoding matrix, e.g., after defining the lifting size for the given payload size and code rate.
  • the complexity of downlink may be coupled with HARQ retransmission feedback caused by unsuccessful decoding attempt(s) (e.g., where the decoder may be unable to reach a convergence point). This may be related to the number of decoding iterations that reach (e.g., usually reach) a maximum allowed limit (e.g., which for example, may imply more battery consumption of the WTRU).
  • Historical performance assistance information related to the BG configuration may include processing latency in UL and DL.
  • the processing latency may be defined by the rate-matching, bit selection, and/or encoding latency.
  • the density of the generator matrix used for encoding may be used (e.g., as more non-zero elements may imply more arithmetic operations).
  • processing latency may correspond to the number of required decoding iterations to reach convergence for a given channel condition.
  • the density of the BG may contribute in defining the latency.
  • the employed code rate may contribute to defining the latency (e.g., where lower code rates may require more decoding latency as more check-nodes of the BG may be utilized during the decoding process).
  • Bit selection and HARQ decoding attempt(s) may contribute to the processing latency.
  • the WTRU may determine other measurement(s) (e.g., in addition to historical performance of the BG) related to its applicable condition(s).
  • the other measurement(s) related to the WTRU’s applicable condition(s) may allow the BG selection to be more WTRU-specific and enable selection of a BG (e.g., suitable BG) that may improve (e.g., optimize) performance (e.g., given the reported WTRU’s applicable conditions).
  • Applicable condition(s) e.g., of the reported WTRU
  • the WTRU may send a request to the Rx node (e.g., network node) for BG selection (e.g., based on (e.g., after) collecting the applicable conditions measurement(s) and historical performance).
  • the WTRU may receive a confirmation and indication to report its measurements for initiating the BG selection/switching procedure.
  • the WTRU may report its measurements, e.g., through the PUCCH.
  • the report format of the measurements may be incorporated in UCI binary field(s) (e.g., new UCI binary field(s)), for example predefined range(s) of QOS performance and applicable condition(s).
  • the measurement(s) may be (e.g., alternatively) reported as field(s) (e.g., new field(s)) comprising their corresponding raw values.
  • Feature(s) associated with WTRU procedures for BG selection are provided herein.
  • a WTRU may receive a BG selection response from the Rx node, e.g., via PDCCH.
  • the received response may include candidate WTRU-specific data-driven BGs.
  • the received response may include a subset of candidate BG unique IDs (e.g., in addition to their associated information, for example information associated to the BG(s) in the subset).
  • the information specific to each candidate BG belonging to the received subset may include one or more of: BG-specific parameter(s), historical performance (e.g., reliability), encoding or decoding complexity, or latency (e.g., measured at the Rx node).
  • parametrical and/or historical information related to the BG may include one or more of: an ID of the BG; supported range of code rates; historical BLER performance; HARQ NACK rate; or average decoding iterations.
  • Parametrical and/or historical information related to the BG may include an ID of the BG (e.g., a respective ID of each BG in the subset).
  • the ID of the BG may be determined using a specific Hash function (e.g., which may map a BG to a compressed unique ID).
  • Parametrical and/or historical information related to the BG may include a supported range of code rates. A supported range of code rates may be indicated explicitly (e.g., all the supported code rates) or implicitly (e.g., by the minimum and/or maximum supported code rates, in addition to a step).
  • Parametrical and/or historical information related to the BG may include historical BLER performance. Historical BLER performance may be indicated by performance reliability of the BG with respect to payload sizes, code rates, and/or a specific decoding algorithm. Pairs of SNR values and/or their corresponding calculated BLER performance may be maintained.
  • SNR values, at which pre-configured BLER threshold values may be reached may be stored.
  • a threshold of 10 ⁇ (-1) may give an indication about the performance of the BG in an SNR regime (e.g., a poor SNR regime) while a threshold of 10 ⁇ (-4) may show the waterfall behavior of the BLER curve (e.g., which may indicate how the BG performs in moderate to high SNR regimes).
  • Payload sizes and/or code rates may be indicated explicitly or implicitly (e.g., using intervals).
  • Parametrical and historical information related to the BG may include HARQ NACK rate.
  • HARQ NACK rate may provide an indication of the transmission latency. Transmission latency may be relevant to a use-case.
  • Parametrical and/or historical information related to the BG may include decoding iterations (e.g., average decoding iterations). Average decoding iterations may provide an indication about the decoding latency and/or convergence speed of the BG with respect to a specific decoding algorithm, code rate, and/or payload size. The average number of decoding iterations may be described explicitly by sets (e.g., sets of SNR, payload size, code rate, decoding algorithm, and/or number of iterations), or implicitly by considering code rates and payload sizes (e.g., ranges of code rates and/or payload sizes instead of specific values).
  • the subset selection may be performed by the Rx node (e.g., the network or another WTRU) such that the candidate BG subset may satisfy the reported WTRU applicable conditions.
  • the WTRU may prioritize some reported conditions over others for example to facilitate the subset selection at the Rx node.
  • the selection may be performed by order of priority (e.g., reliability, latency, and/or complexity, or the like).
  • the Rx node may attempt to increase (e.g., maximize) the range of performance for the reported WTRU conditions.
  • the number of selected BGs belonging to the candidate subset may be pre-configured and/or may be determined (e.g., dynamically determined).
  • the WTRU may perform selection of a BG (e.g., one BG) based on its order of priority (e.g., as a function of its reported conditions and/or requirements).
  • the WTRU may use a fixed threshold or a dynamic threshold with respect to the reported conditions.
  • the threshold e.g., fixed or dynamic
  • the WTRU may prioritize, in some use cases, latency and/or complexity over reliability, and/or vice versa.
  • the WTRU may consider the reported rank. Different BGs may be selected based on the SNR for each layer.
  • a selection criterion may be whether the WTRU is selecting the BG for uplink or downlink.
  • the selection of a BG may depend on whether the WTRU is selecting the BG for uplink or downlink (e.g., where latency and/or complexity may be relatively more prioritized than reliability).
  • Feature(s) associated with dynamic selection of a BG are provided herein.
  • a WTRU may select a BG for a transmission.
  • the selected BG may be from a set of active BGs.
  • the selection may be valid for a single transmission, or a set of transmissions.
  • the selection may be valid for a configured or determined period of time, slots, and/or number of transmissions.
  • the selection may be valid until the WTRU receives an indication from the network (e.g., a network node such as a gNB) to use a specific BG.
  • the WTRU may indicate the selected BG to the network (e.g., a network node such as a gNB) for example if selecting a BG (e.g., new BG) for a transmission.
  • the indication of a selected BG may be performed with a transmission using a default or fallback BG.
  • the indication of selected BG may be performed implicitly (e.g., by the use of an associated parameter in the transmission).
  • the WTRU may indicate the selected BG in a transmission by selecting transmission resources, parameters, associated RS/RS configuration, and/or via scrambling of the transmission (e.g., where the scrambling used may be associated with the selected BG).
  • a WTRU may select a BG for a transmission as a function of one or more of: whether the transmission is an original transmission or a retransmission; the transmission power; the priority of the transmission; the QoS associated with the transmission; the LCH of the transmission; the resources of the transmission; the TCI state; the TRP; the panel; the cell; the carrier; the BWP; the channel access method used; or associated measurement(s).
  • a WTRU may determine a BG for the reception of a transmission from another node (e.g., in DL or SL) based on an indication received from the transmitting node.
  • the indication may be received in a separate transmission.
  • the indication may be received using a default or fallback BG.
  • the indication may be received via DCI, SCI, MAC CE, and/or RRC.
  • a WTRU may determine a BG for the reception of a transmission implicitly based on one or more of: an associated parameter of the transmission; transmission resources; parameters of associated RS/RS configuration; or scrambling of the transmission.
  • a WTRU may indicate (e.g., to the network, such as a gNB, or another WTRU) the identity of a BG used for reception of a transmission by the network or another WTRU.
  • the WTRU may indicate a determined BG for decoding in a HARQ-ACK feedback transmission.
  • the WTRU may report the determined BG based on the rate of HARQ-ACKs or HARQ-NACKs (e.g., if all HARQ feedback associated to one or more transmissions using a same BG may be NACK, the WTRU may report the determined BG in the HARQ-ACK feedback).
  • a WTRU may determine a BG used by a network (e.g., a node of the network such as a gNB), for example for reception of an UL transmission.
  • the WTRU may determine a BG used by the network based on one or more of: HARQ-ACK feedback; scheduling for a retransmission or a new transmission; NDI in a DCI; or reception of indication by the network (e.g., DCI, MAC CE, and/or RRC).
  • a WTRU procedure for UL transmission may include one or more of the following.
  • the WTRU may give priority to the existence of degree-1 variable nodes (VNs) in the BG (e.g., for UL transmission), which may reduce the encoding complexity and/or latency.
  • the degree-1 VNs may act as precoders.
  • the degree-1 VNs may allow the generation of the generator matrix for example for a given code rate and/or payload size.
  • the generator matrix may be the dual code of the parity-check matrix generated from the BG after rate-matching.
  • the number of punctured VNs may be a selection criterion relevant to the UL.
  • a selection criterion relevant to the UL may be whether puncturing is required for achieving a wide range of code rates.
  • Puncturing may employ (e.g., require employing) the bit selection procedure, which may increase the transmission latency.
  • a WTRU procedure for DL reception may include one or more of the following.
  • the selection for DL reception may use (e.g., require) different criteria for selecting a suitable BG based on the WTRU reported conditions and/or requirements.
  • the structural properties of the BG may contribute to maintaining a lower decoding complexity and/or latency while maintaining reasonable performance.
  • the WTRU may prefer (e.g., select) a BG with a quasi-cyclic structure (e.g., a key enabler for supporting parallel layered decoding), which may (e.g., significantly) reduce the decoding complexity and/or latency.
  • the WTRU may prefer (e.g., select) a BG with lower density (e.g., as the density of the BG contributes to reducing the decoding latency for example by minimizing the number of arithmetic operations per decoding iteration), For example lowering (e.g., minimizing) the number of arithmetic operations per decoding iteration may be beneficial for the WTRU (e.g., in terms of its CPU constraints).
  • puncturing may be a parameter (e.g., another parameter) to consider in the selection process for DL (e.g., if a low decoding latency may be mandatory to a certain level).
  • the WTRU may report the selected BG to the Rx node, e.g., based on the selection procedure being completed.
  • the BG may be reported by indicating the unique BG ID, e.g., via PUCCH. If the WTRU fails to select a BG suitable to its requirements and/or applicable conditions, the WTRU may proceed, by a fallback, to a legacy BG or may switch to another previously used WTRU-specific BG (e.g., the WTRU may indicate (e.g., signal) the ID of the BG to which it has switched or fallen back to).
  • a WTRU may support a set of BGs (e.g., WTRU-specific BGs, for LDPC channel coding and/or error correction as described herein).
  • the WTRU may determine a BG (e.g., preferred BG) from the set of supported WTRU-specific BGs.
  • the WTRU may report (e.g., to a network entity such as a base station) the BG (e.g., preferred BG) from the set of supported WTRU-specific BGs, as a function of measured conditions (e.g., channel conditions) and/or decoder performance indicators (e.g., memory, number of iterations, processing latency).
  • measured conditions e.g., channel conditions
  • decoder performance indicators e.g., memory, number of iterations, processing latency
  • a WTRU may support a set of WTRU-specific BGs for LDPC error correction.
  • the WTRU may determine that trigger condition(s) are met.
  • Trigger condition(s) may include event-based triggers such as one or more of: a NACK rate exceeding a configured threshold; detection of a change in channel condition(s) (e.g., satisfying a threshold) and/or traffic type; or detection of a mismatch between a reference performance of a BG and associated operating condition(s) compared to the actual performance/condition(s) (e.g., where conditions may refer to channel conditions, payload size, etc.).
  • the WTRU may send a BG selection request.
  • the WTRU may determine and/or report measurements and/or historical performance (e.g., a performance metric) associated with the current configuration (BG).
  • Measurement(s) e.g., associated with the current BG
  • may include channel condition(s) e.g., WTRU speed, Doppler, delay spread
  • Performance e.g., historical performance
  • Performance of the current BG may include one or more of: average and/or peak memory use and/or availability; complexity (e.g., CPU use and/or availability); number of iterations; or processing latency.
  • Processing latency in UL may include one or more of: encoding latency, existence of a degree-1 VN, or puncturing.
  • Processing latency in DL may include one or more of: decoding latency, average number of decoding iterations, or density of the BG.
  • the WTRU may receive a BG selection response.
  • the BG selection response may include a candidate subset of BGs (e.g., a subset of the supported set of WTRU-specific BG(s)).
  • the associated information may include one or more of: an index of the BG; or SNR values at which a target BLER may be reached (e.g., pairs of (SNR, BLER)); BG dimensions; list(s) of average decoding iterations used (e.g., required) for each SNR value and/or each code rate; or a supported code rate range.
  • the WTRU may select a BG from the candidate subset based on the BG candidate performance and/or WTRU specific conditions and/or requirements.
  • the WTRU may select a BG based on a condition, e.g., select the BG based on WTRU determined condition(s) (e.g., channel conditions, memory & CPU requirements and/or constraints) and/or the performance of the BG(e.g., performance of the WTRU under the WTRU determined condition(s) if using the BG).
  • the WTRU may select a BG for which transmission and/or reception performance may be is maximized or is above a threshold for the reported WTRU conditions (e.g., the WTRU determined condition(s)).
  • the WTRU may select a BG based on a reported rank. A different BG may be selected based on the SNR for each layer.
  • the WTRU may report the selected BG to a network node (e.g., the gNB).
  • the WTRU may transmit and/or receive encoded TB(s) using the selected BG.
  • Configuration information for WTRU-assisted BG generation may include one or more of the following.
  • a WTRU may be configured (e.g., may receive an indication) to transmit specific transport block(s), referred herein as pruning transport blocks (PTB) (e.g., as assistance information for NW-based BG generation).
  • PTB pruning transport blocks
  • PTB may include reference codewords known by both the transmit node (e.g., WTRU) and/or the receive node (e.g., gNB and/or another network node).
  • the information bits (e.g., payload) of PTBs may be uncoded.
  • HARQ retransmissions may be disabled (e.g., for PTBs).
  • PTBs may be used to enhance the dataset for data-assisted BG generation.
  • the PTB configuration may include one or more of: codeword size (e.g., a set of codeword sizes), an indication of the predefined codeword to be transmitted, or PTB transmission type.
  • the PTB configuration may include codeword size, such as a set of codeword sizes.
  • the PTB configuration may include the number of information bits (e.g., payload size), k, and/or the codeword size, n. [0199] The PTB configuration may include the number of information bits, k, and/or the code rate. The PTB configuration may include the lifting size, Z. [0200] The PTB configuration may include an indication of the predefined codeword to be transmitted. In examples, the PTB configuration may include an index to a table of predefined PTB codewords. The predefined codewords may include random and/or fixed bit patterns. The PTB configuration may be an initial value for a predefined random number generator (RNG). The WTRU may initialize the RNG with the indicated initial value and/or may generate a bit sequence of a length indicated by the codeword configuration.
  • RNG predefined random number generator
  • the PTB configuration may include PTB transmission type.
  • PTB transmission type may be periodic, semi-persistent, or aperiodic.
  • the PTB resource configuration may include one or more PTB resource sets.
  • a PTB resource set may be associated with a bandwidth part (BWP).
  • the WTRU may receive the PTB resource configuration via RRC configuration.
  • the resource set configuration may be used for both periodic and semi-persistent PTB transmission types.
  • the resource set configuration may include one or more of the following: a PTB transmission period (e.g., measured in slots, TTIs, or the like); a number of PTBs per period and/or time interval between transmissions; a slot offset and/or TTI offset of PTB transmissions (e.g., with respect to the start of each transmission period); or an indication of (e.g., indicator for) the bandwidth part to be used for PTB transmission.
  • PTB transmission parameters may be configured dynamically (e.g., via the control channel DCI) if data channels are used for PTB transmissions.
  • Dynamically configured parameters may include one or more of: PTB modulation type; the transport block (TB) the PTB is to be transmitted on; a precoding matrix indication; or a TPC indication.
  • Dynamically configured parameters may include the transport block (TB) the PTB transmitted on. If dual (e.g., or multiple) transport block transmission is supported over the data channel, one transport block may be used for actual payload/data transmission, and/or another transport block may be used for PTB transmission.
  • the WTRU may receive an indication of which transport block to use for PTB transmission.
  • Dynamically configured parameters may include a TPC indication.
  • the WTRU may be configured to re-transmit a PTB at different (e.g., indicated) power levels so that the PTB received at the network node is within an SNR range (e.g., a target SNR range).
  • SNR range e.g., a target SNR range.
  • Feature(s) associated with configuration of the BG generation are provided herein.
  • Data-driven LDPC BG generation may require a set of parameters for the configuration of the Rx node to enable the procedure. This configuration may be related to the parameters of the LDPC BG, the BG evaluation configuration (e.g., the NBP ML model hyperparameters and/or evaluation metrics), and/or the configuration for the pruning procedure.
  • the BG configuration may include parameter(s) related to the structure of the BG. These parameter(s) may control how well the BG performs over specific channel conditions and/or block length regimes.
  • the supported code rates may automatically be calculated from the dimensions of the BG (e.g., due to the nested rate-compatible property of the LDPC BGs).
  • the memory requirements of the designed BG may depend on its dimensions, a number (e.g., the maximum number) of parallel edges (e.g., the maximum integer per BG entry), and/or whether double edges are allowed in the same bundle (e.g., one entry of the BG may contain multiple values, which may enable the BG to expand a parallel edge to circulant bundle of edges, which may or may not be an identity matrix).
  • the parameters for the BG configuration may include one or more of: a mother (e.g., lower rate) BG configuration; indexes and/or number of punctured VNs; a number (e.g., maximum number) of parallel edges (e.g., for core and/or punctured VNs); or whether double edges are allowed in the same bundle.
  • a mother (e.g., lower rate) BG configuration may be described as the daughter BG configuration in addition to the number of extension rows and/or columns (e.g., due to the nested rate-compatible structure). Extension rows may be employed to achieve higher code rates while extension columns may be added to support IR-HARQ. The supported code rates may be determined.
  • a supported code rate range may be a code range such that: [0211] Index and/or number of punctured VN(s) may be parameters for BG configuration. A number (e.g., maximum number) of parallel edges, for core and/or punctured VN(s) may be for performance improvement of the BG. Higher parallel edge values may be used (e.g., preferred) for the punctured VNs compared to core VNs.
  • BG evaluation settings may be configured to enable monitoring of the performance of the BG being generated.
  • BG evaluation settings may include the parameters related to NBP training (e.g., which may enable the pruning procedure).
  • the performance monitoring may be performed intermediately during the pruning procedure (e.g., if intermediate BGs are obtained in each iteration or in a set of iterations).
  • Careful selection of the NBP hyperparameters may be important if optimizing the BG generation procedure and/or enabling a robust training model.
  • NBP training may be exploited to obtain performance results (e.g., using the value returned by the loss function).
  • the PTBs used for training the NBP may be employed to evaluate the final BG and/or obtain BLER performance (e.g., over a set of SNR values).
  • the BG evaluation configuration may include (e.g., may indicate to evaluate) one or more of: the NBP hyperparameters or evaluation metrics.
  • the NBP hyperparameters may include one or more of: a number of NBP training epochs; batch size (e.g., a number of PTBs to use for training); a NBP decoding variant; decoding stopping criteria (e.g., maximum number of decoding iterations and/or syndrome weight (e.g.,, if the syndrome weight is zero, the decoder may converge to a codeword); an optimizer (e.g., ADAM, RMSPROP, or SGD); a learning rate value; a learning rate scheduler; or an objective function.
  • decoding stopping criteria e.g., maximum number of decoding iterations and/or syndrome weight (e.g., if the syndrome weight is zero, the decoder may converge to a codeword
  • an optimizer e.g., ADAM, RMSPROP, or SGD
  • a learning rate value e.g., a learning rate scheduler
  • objective function e.g., ADAM, RMSPROP
  • An objective function may be defined as the binary cross-entropy loss function, the soft bit error rate function, the soft syndrome function (e.g., for optimizing BLER instead of BER), or any combination of loss functions.
  • Evaluation metrics may include one or more of: BER/BLER (e.g., may be obtained by decoding the PTBs (e.g., all the PTBs) and/or collecting error rates. Labels may be already predefined (e.g., all-zero codewords)); BG density; a NBP cumulative loss function; or any combination of metrics.
  • Pruning the BG (e.g., eliminating edges that may be not contributing to performance) may be performed using one or more different approaches.
  • the edges of the BG may be pruned according to different metrics.
  • One-shot pruning e.g., a set of predefined number of edges may be pruned in one shot
  • a fast approach e.g., the fastest
  • An efficient option may be iterative pruning (e.g., a single and/or a set of edges may be pruned in each iteration after training).
  • a preconfigured threshold may be used (e.g., the L2-norm and/or magnitude values under the threshold may be pruned).
  • Stopping criteria of the iterative pruning process may be determined and/or selected (e.g., by the WTRU). Stopping criteria may be one or more of the following: a number (e.g., maximum number) of consecutive iterations in which the loss function value diverges; a number (e.g., maximum number) of pruning iterations; a desired BLER value at a fixed SNR value; a time (e.g., timer-based stopping condition); a function of CG PTB resource available; or any combination of the above.
  • a number e.g., maximum number
  • Stopping criteria may be one or more of the following: a number (e.g., maximum number) of consecutive iterations in which the loss function value diverges; a number (e.g., maximum number) of pruning iterations; a desired BLER value at a fixed SNR value; a time (e.g., timer-based stopping condition); a function of CG PTB resource available; or any combination of the above.
  • the number (e.g., maximum number) of pruning iterations may control the density (e.g., minimum density) of the BG at which the pruning process should be stopped (e.g., in order to avoid a substantial number of low weights CNs and/or VNs, which may have an impact on the BG performance).
  • WTRU triggers for reporting assistance information for network-based BG generation are provided herein.
  • a WTRU may be triggered to report assistance information for network-based BG generation.
  • the triggers (e.g., for the WTRU to report assistance information) may be event-based, time- based, and/or network-based.
  • Event-based triggers may include one or more of the WTRU determining: a condition or a set of conditions may be met; a change in channel conditions; or the average payload size (e.g., for the downlink transmissions) and/or the measured channel conditions do not match the performance information of the configured WTRU-specific BG set.
  • the WTRU may determine that a condition or a set of conditions may be met.
  • the WTRU may determine that the NACK rate exceeds a preconfigured threshold.
  • the WTRU may determine that the average number of iterations for TB decoding exceeds a preconfigured threshold.
  • the WTRU may determine that the available memory size is below a preconfigured threshold.
  • An event-based trigger may be a change in channel conditions.
  • the WTRU may determine that the current SNR may be outside the SNR range corresponding to the current BG.
  • the WTRU may determine that the channel rank has changed, which may result in operating conditions outside of the parameters of the current BG.
  • the WTRU may determine whether the average payload size (e.g., for the downlink transmissions) and/or the measured channel conditions match the performance information of the configured WTRU-specific BG set.
  • Time-based triggers may include one or more of: expiration of timers configured for PTB assistance information transmission; or expiration of validity timers for the current configured BG.
  • Network-based triggers may include an indication from the network.
  • An indication from the network for the WTRU to transmit a first set of assistance information (e.g., the indication may include an uplink grant and/or indication of metrics to be transmitted).
  • An indication from the network for the WTRU to transmit a second set of assistance information may be included.
  • the second set of assistance information may include one or more PTBs.
  • the indication may be an activation of PTB transmissions via a MAC CE (e.g., which may include the PTB reporting resource set ID if the WTRU is configured with semi-persistent PTB reporting).
  • the indication may be dynamic (e.g., via the DCI of the control channel).
  • a WTRU may provide assistance information for network-based BG generation.
  • a WTRU may provide assistance information to the network for BG generation.
  • the assistance information may be categorized under two sets.
  • a first set of assistance information may be used for indicating the WTRU- based statistic(s) and/or requirement(s).
  • a second set of assistance information may be used for creating dataset at the network.
  • the two sets of assistance information (e.g., provided by the WTRU) may be feedback to the network within a single message or separate messages.
  • a first set of assistance information on WTRU-based statistics and/or requirements may enable the network to implement a WTRU-centric BG structure (e.g., that may be trained by a WTRU-specific dataset).
  • the first set of assistance information may include one or more the following: statistical information; target average number of decoder iterations; target average NACK rate; available (e.g., maximum available) memory size for decoder; historical average payload size of the WTRU; or legacy CSI report(s).
  • a first set of assistance information on WTRU-based statistics and/or requirements may include statistical information on the historical average of the number of decoding iterations of the WTRU. Historical average of the number of decoding iterations information may be part of the network-based BG design process (e.g., the network may design a BG so that the average number of decoding iterations via the BG may be lower than the current BG used at the WTRU).
  • a first set of assistance information on WTRU-based statistics and/or requirements may include a target average number of decoder iterations. This information may be used by the network to design a BG to address the specific needs of a WTRU for certain scenarios, such as low power mode.
  • a first set of assistance information on WTRU-based statistics and/or requirements may include a target average NACK rate (e.g., target BLER). This assistance information may be used by the network to address reliability requirements of a WTRU.
  • a first set of assistance information on WTRU-based statistics and/or requirements may include an available (e.g., maximum available) memory size for a decoder. This assistance information may be used by the network to meet the hardware requirements of a WTRU.
  • a first set of assistance information on WTRU-based statistics and/or requirements may include historical average payload size of a WTRU. This assistance information may be used by the network to determine whether the WTRU satisfies the requirements of the network-based BG design process, such as low payload regime.
  • a first set of assistance information on WTRU-based statistics and/or requirements may include legacy CSI reports.
  • the network may use information on the existing channel quality to design a WTRU- specific BG.
  • the WTRU may report multiple types of assistance information (e.g., as described herein).
  • the network may design multiple BGs in advance (e.g., to be used for the request of a WTRU).
  • the second set of assistance information may be used by the network to create a dataset for an iterative BG pruning process.
  • the WTRU may send PTB to the network (e.g., for the network to create a dataset for an iterative BG pruning process).
  • PTB may be a special type of codeword predefined at the network and/or WTRU.
  • the network may use the Log Likelihood Ratio (LLR) measurements of the PTB bits to design the BG via iterative pruning operations.
  • a PTB may include an all zero codeword.
  • the transmission of PTBs may be configured by the network.
  • the codeword length, n, of a PTB and/or the number of PTBs, m, may be configured by the network.
  • the network may configure the WTRU to send groups of PTBs periodically.
  • a PTB may be transmitted from the WTRU to the network via one or more different schemes.
  • PTB transmission schemes may include one or more of the following: PTB over SRS; PTB over PUSCH; PTB over PUCCH; or PTB over dedicated RS.
  • PTB may be transmitted from the WTRU to the network via SRS.
  • the network may make use of SRS so that SRS may be used for data collection from the WTRU.
  • the SRS sequence may be predefined at the WTRU and/or network (e.g., Zadoff-Chu based).
  • the network may configure the WTRU to send sufficient SRS to represent n x m bits of required PTBs.
  • the WTRU may be scheduled to send (n x m / 2) SRS (e.g., assuming the SRS modulation may be QPSK based).
  • Power control adjustments on SRS may be applied to receive SRS with different SNR levels (e.g., which may lead to better SNR generalization and/or SNR-based training at the network).
  • PTB may be transmitted from the WTRU to the network via PUSCH.
  • the network may schedule the WTRU to send PTBs over PUSCH.
  • the WTRU and network may share a common PTB codeword.
  • the WTRU may use an all zero codeword as PTB to be transmitted from the WTRU to network.
  • the network may schedule time frequency resources for the specific WTRU so that, m, PTBs (e.g., all zero PTBs) with codeword length, n, may be transmitted from the WTRU.
  • the network may configure the WTRU to use any symbol modulation level, such as QPSK.
  • PTB may be transmitted from the WTRU to the network via PUCCH.
  • the PTB feedback may be defined as a new component of UCI/PUCCH signaling. The PTB feedback may be used if the overhead of PTB feedback is low.
  • the network may allocate PUCCH uplink resources for the WTRU to feedback PTBs over UCI/PUCCH (e.g., together with other components of CSI report or separately).
  • PTB may be transmitted from the WTRU to the network via dedicated RS.
  • the WTRU may use a dedicated RS to transmit the PTBs.
  • the dedicated RS may be used to transmit an all zero codeword with predetermined symbol modulation, such as QPSK.
  • the number of dedicated RSs may be determined based on the length of the configured codelength, n, and/or the number of PTBs, m. If the dedicated RS modulation is QPSK, the WTRU may be scheduled to send (n x m / 2) dedicated RSs.
  • the network may compute m x n LLRs corresponding to m x n bits transmitted within the PTBs (e.g., based on receiving the PTB symbols).
  • Feature(s) associated with WTRU behavior based on receiving a BG and associated parameters are provided herein.
  • a WTRU may receive a BG (e.g., which may be determined based on the network-side pruning procedure).
  • the core BG may be received in addition to extension rows (e.g., without extension columns).
  • the extension columns may be generated (e.g., automatically generated) by the WTRU.
  • the ID of the BG may be received (e.g., in addition).
  • the ID of the BG may be unique to that specific BG and/or may be determined based on a Hash function.
  • the BG may be received with its associated information (e.g., depending on the WTRU memory capabilities), including performance information (e.g., BER/BLER over specific SNR values, and/or thresholds at which predefined BER/BLER values may be reached).
  • the received associated information may (e.g., also) include QOS requirement(s), including one or more of: decoding latency for a given decoding algorithm and/or set of SNR values; range of payload size associated with the BG; code rate associated with the BG; or further information related to the applicable conditions reported by the WTRU for generating the BG.
  • a WTRU may indicate (e.g., signal) use of the received BG for PUSCH/PDSCH to the network.
  • the WTRU may indicate (e.g., signal) use of the received BG to the network by reporting the BG ID.
  • the WTRU may receive a confirmation (e.g., from the network) to ensure there is no misalignment in the FEC scheme.
  • the WTRU may report a BG switch to another WTRU-specific BG if the applicable conditions vary rapidly. If there is a change in the use-case (e.g., eMBB), the WTRU may indicate (e.g., signal) a legacy fallback.
  • a WTRU may support WTRU-specific BG for LDPC error correction.
  • the WTRU may provide assistance information for network-based BG generation.
  • the WTRU may receive a BG and/or the associated performance information.
  • the WTRU may determine if the BG is applicable (e.g., based on the WTRU conditions and/or associated performance information).
  • the WTRU may report the determination outcome (e.g., whether the BG is applicable) to the network.
  • one or more of the following may be performed.
  • a WTRU (e.g., supporting WTRU- specific BG for LDPC error correction) may be triggered to provide assistance information for network- based BG generation.
  • the trigger may be an indication from the network, or may be event based (e.g., the WTRU determining that a condition may be met, such as a NACK rate exceeding a threshold, number of decoding iterations exceeding a threshold, or the like).
  • the WTRU may report a first set of assistance information for BG generation.
  • the first set of assistance information may include one or more of: an available (e.g., maximum available) memory size; an average number of decoder iterations; an average NACK rate; an average payload size measured by the WTRU (e.g., to determine if the WTRU is operating in the low payload regime); or legacy CSI reports.
  • the WTRU may receive an indication and/or a configuration to transmit a second set of assistance information.
  • the second set of assistance information may include one or more pruning transport blocks (PTB) (e.g., used to enhance the dataset for data-assisted BG generation).
  • the configuration may include one or more of: the PTB configuration, a batch size (e.g., minimum batch size), periodicity of PTB transmissions, or number of PTBs per period.
  • the WTRU may perform one or more PTB transmissions (e.g., without HARQ retransmissions).
  • the WTRU may indicate (e.g., if performing a PTB transmission) the identity of the PTB explicitly (e.g., index to a set of pre-defined PTBs), or implicitly.
  • the WTRU may receive performance information for the BG (e.g., generated by the network).
  • the performance information may include one or more of: performance of the BG (BLER), cumulative loss of intermediate BG evaluation; a number of short cycles; a number of degree-1 and/or degree-2 variable nodes (VN); or an average number of decoding iterations over a set of SNR values.
  • BLER performance of the BG
  • VN degree-1 and/or degree-2 variable nodes
  • the WTRU may determine if the BG is applicable.
  • the WTRU may report the determined outcome to the network. The determination may be based on comparing the received BG information to the WTRU condition(s) (e.g., current WTRU condition(s)).
  • Dynamic PR-LDPC BGs may be designed, e.g., for short block lengths. The design may be naturally extended to an (e.g., any) arbitrary block length including the moderate and/or long block length regime.
  • a (e.g., any) BG may be characterized by the number of VNs, n v , and/or the number of CNs, n c , contained in the core BG, and/or the number of optionally punctured VNs, np.
  • a LDPC BG may be identified by the triplet (n v ,n c ,n p ).
  • the parameter n p may be used to consider a very high degree VN in the design process (e.g., where the corresponding VN (e.g., column of the BG) may be fixed from the initialization and/or excluded from the pruning process).
  • the number of extension nodes, next, may be pre-configured.
  • the range of code rates that the BG supports may be directly determined (e.g., based on the defined parameters).
  • the core BG may correspond to the daughter PR-LDPC code with higher code rate.
  • the code rate of the daughter PR-LDPC code may be given by: [0246] [0288] If a number (e.g., an equal number) of extension rows and columns are added, different lower code rates may be achieved (e.g., depending on how many extension nodes are inserted).
  • the minimum achievable code rate by the mother code with lower rate may be given by: [0247] [0289]
  • Another configuration parameter may be a number (e.g., the maximum number) of parallel edges. The maximum number of parallel edges may correspond to an integer entry (e.g., the maximum integer entry) to fill in the BG during the initialization phase.
  • a number (e.g., maximum number) of parallel edges may be enough to obtain a BG (e.g., good for short block lengths).
  • a low storage requirement may be maintained (e.g., as each entry may require 2 bits in the memory).
  • Other network BGs e.g., 5G NR BGs
  • Other parameters may include the configuration related to the pruning procedure.
  • the BG design process may be initiated by generating a set of random fully dense BGs with respect to the pre-defined dimensions and/or parallel edges.
  • the number of random BGs may be defined by the parameter ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ , which may be included in the pruning configuration PCS.
  • the WTRU may select one initial BG which has a lower number of short cycles (e.g., of length 4).
  • the extension columns may not be counted and/or may not be (e.g., never) pruned from the BG.
  • the extension columns may be fixed and/or take the form ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ; ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ .
  • ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ and ⁇ ⁇ ⁇ ⁇ ⁇ may be all-zero matrix and/or identity matrix of size ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ , respectively.
  • the variables may be contained in a proto-matrix with ⁇ ⁇ + ⁇ ⁇ ⁇ ⁇ rows and ⁇ ⁇ columns.
  • the WTRU may select the BG with a number (e.g., minimum number) of cycles of a length (e.g., a length 4) (e.g., for calculating the number of short cycles contained in the generated BGs and/or for the selection of the initial BG for initializing the NBP before pruning).
  • the selection may be extended to calculating longer cycles (e.g., those with length 6).
  • Bi,j may denote the BG entry located in the ith row and jth column, such that Bi,j ⁇ bmax.
  • bmax may be a number (e.g., the maximum number) of parallel edges (e.g., maximum integer allowed in the BG).
  • Z may be the expansion factor.
  • each BG the number of short cycles ncycles may be calculated.
  • the BG with a smaller value of ncycles may be selected as the initial BG.
  • the nested property may be guaranteed (e.g., given the upper right extension all-zero submatrix).
  • the higher rate daughter code may be nested within the lower rate mother code (e.g., after adding the extension columns and rows).
  • the lower right identity sub-matrix may ensure that IR-HARQ retransmissions may be supported by adding rows (e.g., and/or columns) for each subsequent retransmission.
  • each extension VN may be connected (e.g., only connected) to one extension row (e.g., making the higher rate codes nested).
  • the weights corresponding to the fully connected DNN associated to the NBP decoder by a value may be initialized (e.g., given that the initial dense BG is generated and/or selected, and/or a maximum number of decoding iterations is fixed). Initially, all the edges associated to the initial BG entries may have similar (e.g., the same) importance and/or relevance.
  • a WTRU may use a training dataset according to the configuration (e.g., codelengths, code rates, and/or batch size). The same dataset may be used for all the BG versions during pruning iterations (e.g., for fair and/or stable performance monitoring).
  • the NBP weights may be trained every iteration (e.g., epoch). At the end of an iteration (e.g., each iteration), one or a set of weights may be pruned according to the configuration. In examples, a set of M weights may be pruned in one shot. In examples, only one weight may be pruned.
  • the pruning metric may be based on the magnitude of the weights or on the l2-norm.
  • the selection of weights to prune may be based on a value (e.g., the minimum value) of the selected metric and/or may be based on a pre-defined threshold included in the configuration.
  • Calculating which weight to prune may depend on (e.g., be based on) the employed NBP variant (FSNPA or RNSPA). If the RNSPA is employed, the selection may be straightforward (e.g., as the BG nodes may be temporally tied, for example they share the same weights in different decoding iterations). If FNSPA is employed, the weights may be different across decoding iterations. If FNSPA is employed, the individual weights may be first calculated before the pruning process (e.g., by computing the average of the weight associated to each node across the decoding iterations). For each node, an individual weight value may be found which may be used to perform pruning.
  • FSNPA or RNSPA NBP variant
  • the density of the designed BG and/or the total number of short cycles may be reduced.
  • the performance of the current BG (e.g., after pruning) may be evaluated over a specific SNR value, such as a representative SNR value with respect to the considered channel. Performance may be evaluated over 3 different SNR values so that the iterative decoding threshold, the waterfall performance, and/or error floors may be evaluated (e.g., at the same time).
  • the pruning process may be stopped if some stopping condition is met.
  • the stopping condition may be BLER performance.
  • the design process may be stopped if the BG (e.g., new BG) performs worse than the previous one (e.g., the design approach may be no longer useful for improving the LDPC BG for the given BG structure).
  • the result may be a BG (e.g., new BG) (e.g., in the end of the design), specifically designed to perform optimally under the considered channel model.
  • the design may be different for different channels.
  • the final BG may be retrained (e.g., another time), so that the new edges may be adaptively fine-tuned to the specific BG connections (e.g., if the NBP decoder is desired to be used for decoding the BG). Otherwise, the obtained BG may be (e.g., directly) used for a (e.g., any) decoding algorithm able to decode LDPC codes.
  • the obtained LDPC codes for the designed BG may be quasi-cyclic codes (e.g., as may be similar to other network NR LDPC BGs).
  • the obtained LDPC codes for the designed BG may support the IR-HARQ as well as rate matching by puncturing and/or shortening.
  • the LDPC BG AI/ML pruning-based design may include one or more of the following.
  • the BG dimensions, NBP, and/or pruning parameters may be fixed.
  • a channel model may be fixed.
  • a set of M fully dense initial LDPC BGs may be generated (e.g., according to the BG dimensions and/or parameters).
  • the set may include an all-zero upper right submatrix (e.g., for the nested property).
  • the set may include a lower right identity matrix for supporting the IR-HARQ.
  • the number of short cycles for the M candidate may be calculated.
  • An (e.g., one) initial BG with less short cycles may be selected.
  • the pruning loop may be started (e.g., by training the BG edges using an NBP decoder). Different values of the expansion factor may be employed for design diversity with regard to the codelength.
  • the pruning metric for the trained edges may be calculated.
  • the weights may be pruned according to the pruning type. If the RNSPA is employed, the weights may be calculated. If the FNSPA is employed, the average weight for each edge across decoding iterations may be calculated.
  • the metric may be the magnitude and/or the l2-norm.
  • the pruning type may be a set of weights or only one weight.
  • the selection may be based on the minimum value of the selected metric and/or based on a pre-defined threshold.
  • the weights e.g., all the weights
  • the BLER performance and/or short cycles number of the new obtained BG may be evaluated.
  • An appropriate set of SNR values e.g., over different regimes
  • the stopping criteria may be checked (e.g., to see if it is met). Performance convergence may occur if BLER performance and/or cumulative loss do not improve after k iterations. A number (e.g., maximum number) of pruning iterations may be reached.
  • An LDPC BG design may include one or more of the following parameters: BG dimensions, number of extension rows and/or columns, number of parallel edges, code rate range, pruning technique, or NBP decoder.
  • an LDPC BG design may have one or more of the following parameters: BG dimensions (n v ,n c ,n p ), may be (5,3,1); a number of extension rows and/or columns n ext may be a value (e.g., 2); a number of parallel edges may be a value (e.g., 3); a code rate range (rmin,rmax) may be (1/3,1/2); a pruning technique may be one weight per pruning iteration (e.g., based on the minimum magnitude of the weights); or an NBP decoder may be FSNPA. [0268] A set of initial BGs may be randomly generated. A (e.g., one) candidate may be selected.
  • the second VN (e.g., second column) may have more parallel edges (e.g., up to 3), as this VN may be optionally punctured.
  • An all-zero submatrix may be present (e.g., the upper right).
  • a lower down identity matrix may be used for supporting the IR-HARQ.
  • an (e.g., each) added extension CN may be connected (e.g., only) to one extension VN (e.g., making the LDPC BG have the nested rate-compatible property).
  • the weights in Tanner graph associated to non-zero edges used in the NBP may have weights initialized to a value (e.g., 1s).
  • the weights may use the FNSPA in the first pruning iteration (e.g., after training), the new trained weights may take the following form: 0.12 0.76 ⁇ . ⁇ ⁇ 0.2 0.37 0 0.56 0.09 0.23 0.45 0.89 0 [0272]
  • ⁇ (1) 0.66 0.71 0.13 0.29 0.75 0 0.19 0.77 0.17 0.68 0.2 0.38 [ 0.97 0.3 0.2 0.65 0.61 0
  • the trained weights in the first pruning iteration may show the relevance of the connections between CNs and/or VNs.
  • W (1) may be the average weights (e.g., for each edge) computed across the FSNPA iterations.
  • a value e.g., the minimum value
  • the minimum value may correspond to the edge connecting the first CN to the 3rd VN. Therefore, this edge may be pruned, and/or its corresponding entry in the BG may be replaced by a value (e.g., 0) (e.g., eliminating the connection).
  • the new obtained BG may be sparser and may take the following form: [0275]
  • the BLER performance of the new BG may be evaluated for a set of SNR values, and for different expansion factors.
  • the obtained BLER may be stored for monitoring the performance improvement (e.g., in the next pruning iteration).
  • the weights associated to the remaining edges may be initialized to a value (e.g., 1), and the same NBP training procedure may be repeated until a number (e.g., the maximum number) of pruning iterations may be reached and/or until the performance of the BG starts to be penalized (e.g., before starting the next pruning iteration).
  • the obtained LDPC BG may be sparse.
  • the optimal training action(s) may be enabled to learn a robust representation for the given parameters and/or dimension.
  • the first VN (e.g., first column) may be a degree-1 VN.
  • the first VN may act as a precoder.
  • the second VN may be a very high degree VN.
  • the edges connecting the second VN to all the CN may not have been pruned.
  • a very high degree VN may be (e.g., optionally) used for puncturing.
  • the core VNs (e.g., all VNs excluding the precoder and extension VNs) may have a degree at least equal to a value (e.g., 3) (e.g., which may support having a linear minimum distance growth with respect to the codelength).
  • the obtained LDPC code may have a linear minimum distance growth (e.g., for any arbitrary expansion factor).
  • the number of decoding iterations may be a value (e.g., 30) iterations, and the number of training epochs in each pruning iteration may be a value (e.g., 2000).
  • the batch size may be a value (e.g., 120), while the learning rate may be a value (e.g., 0.001).
  • the initial dense BG may be pruned until performance degradation has been observed.
  • the final BG may be obtained.
  • the obtained LDPC BG may take the following form: [0282]
  • the deigned BG may have useful structural properties.
  • FIG.5 depicts an example BLER performance comparison of a PR- LDPC code generated using a designed BG with a network NR LDPC BG2 (e.g., 3GPP 5G NR LDPC BG2).
  • the comparison of BLER performance for an LDPC code generated using the designed BG with the network NR LDPC BG2 with the same code parameters and/or code rate For evaluating the performance, a value of (e.g., 15) decoding iterations of the BP-SPA may be considered, for a transmission over an AWGN channel using a QPSK modulation.
  • the BLER performance of the designed BG may outperform the LDPC code (e.g., the LDPC code generated by the 3GPP BG2).
  • the performance gap may be due to the careful design approach (e.g., which may be data-driven and/or performed by pruning techniques).
  • the designed BG may provide an iterative decoding threshold that may be significantly lower than its network NR BG2 counterpart.
  • the designed BGs may be more suitable for worse channel conditions (e.g., while maintaining lower latency, lower retransmissions, better reliability, and/or lower storage requirements).
  • the presented performance may be further improved, for example by designing BGs with different dimensions and/or under realistic channel models.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Probability & Statistics with Applications (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne des systèmes, des procédés et des dispositifs qui sont associés à la sélection adaptative de graphe de base (BG) pour un codage de contrôle de parité à faible densité, LDPC. Un dispositif (par exemple, une unité d'émission/de réception sans fil [WTRU]) peut comprendre un processeur configuré pour effectuer une ou plusieurs actions. Le dispositif peut envoyer un message de demande pour une sélection de graphe de base (BG). Le dispositif peut recevoir un message de réponse associé au message de demande. Le message de réponse peut indiquer un sous-ensemble d'une pluralité de BG associés à la WTRU. Le dispositif peut sélectionner, à partir du sous-ensemble de la pluralité de BG, un BG pour lequel une performance associée à la WTRU est déterminée pour satisfaire un seuil. Le dispositif peut envoyer une indication du BG sélectionné.
PCT/US2024/041169 2023-08-07 2024-08-07 Sélection adaptative de graphe de base pour codage ldpc Pending WO2025034777A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363531058P 2023-08-07 2023-08-07
US63/531,058 2023-08-07

Publications (1)

Publication Number Publication Date
WO2025034777A1 true WO2025034777A1 (fr) 2025-02-13

Family

ID=92843392

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/041169 Pending WO2025034777A1 (fr) 2023-08-07 2024-08-07 Sélection adaptative de graphe de base pour codage ldpc

Country Status (1)

Country Link
WO (1) WO2025034777A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060227778A1 (en) * 2005-04-09 2006-10-12 Lg Electronics Inc. Method of supporting multiple codes in a wireless mobile communication system
WO2019023137A1 (fr) * 2017-07-28 2019-01-31 Qualcomm Incorporated Techniques et appareils pour la détermination et l'indication de graphes de base de contrôle de parité à faible densité

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060227778A1 (en) * 2005-04-09 2006-10-12 Lg Electronics Inc. Method of supporting multiple codes in a wireless mobile communication system
WO2019023137A1 (fr) * 2017-07-28 2019-01-31 Qualcomm Incorporated Techniques et appareils pour la détermination et l'indication de graphes de base de contrôle de parité à faible densité

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NOKIA ET AL: "Nominal code rate and BG determination", vol. RAN WG1, no. Reno, USA; 20171127 - 20171201, 17 November 2017 (2017-11-17), XP051369096, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fran/WG1%5FRL1/TSGR1%5F91/Docs/> [retrieved on 20171117] *

Similar Documents

Publication Publication Date Title
US12028159B2 (en) Polar coding systems, procedures, and signaling
US11057156B2 (en) Advanced polar codes for control channel
US11563511B2 (en) Polar coding system for ultra-reliable low latency communication
US20250330267A1 (en) Methods and procedures for polar coded modulation
US20190181983A1 (en) Advanced polar codes for next generation wireless communication systems
US11705926B2 (en) Reduced complexity polar encoding and decoding
TWI783080B (zh) 無線傳輸/接收單元（ｗｔｒｕ）與傳輸極性編碼位元之方法
US20240129063A1 (en) Methods and procedures for polar encoding and decoding with low latency
US20250015923A1 (en) Methods and procedures for flexible and highly-parallel polar encoding and decoding
US20240289627A1 (en) Methods, procedures, apparatuses and systems for data-driven wireless transmit/receive unit specific symbol modulation
WO2017193936A1 (fr) Procédures de décodage dans des systèmes à segmentation de bloc de code
EP4635113A1 (fr) Procédés et systèmes de figeage incrémentiel avec des codes polaires à noyaux multiples
TW202423158A (zh) 用於低密度同位圖適配的訊令和報告
WO2025034777A1 (fr) Sélection adaptative de graphe de base pour codage ldpc
WO2024130533A1 (fr) Conception de code polaire pour décodeur en pipeline
WO2025189627A1 (fr) Procédé, appareil et système de retransmission d&#39;informations de commande de liaison montante
WO2025102555A1 (fr) Procédés, systèmes et appareil de détermination de longueur de code mère
WO2024182273A1 (fr) Procédés, architectures, appareils et systèmes d&#39;entraînement et de sélection en ligne de décodeurs à propagation de croyance neuronale
WO2025212470A1 (fr) Procédés de validation de politique hors ligne dans un apprentissage par renforcement

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24773593

Country of ref document: EP

Kind code of ref document: A1