Enhancements associated with packet data convergence protocol network coding

Abstract

Systems, methods, and instrumentalities are described herein that may be associated with enhancements to uplink (UL) scheduling procedures (e.g., including scheduling request (SR), buffer status reporting (BSR), and delay status reporting (DSR)). The enhancements may be used to report network coding (NC) related information to the network to support reception of X linearly-independent NC protocol data units (PDUs) or more to recover the X NC service data units (SDUs) at the receiver, satisfy common processing deadline requirements of NC PDUs at the receiver, and / or support differentiated treatment of NC PDUs.

Description

ENHANCEMENTS ASSOCIATED WITH PACKET DATA CONVERGENCE PROTOCOL NETWORK CODINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of Provisional U.S. Patent Application No. 63 / 571,755, filed March 29, 2024, the disclosure of which is incorporated herein by reference in its entirety.BACKGROUND

[0002] Mobile communications using wireless communication continue to evolve. A fifth generation of mobile communication radio access technology (RAT) may be referred to as 5G new radio (NR). A previous (legacy) generation of mobile communication RAT may be, for example, fourth generation (4G) long term evolution (LTE).SUMMARY

[0003] Systems, methods, and instrumentalities are described herein that may be associated with enhancements to uplink (UL) scheduling procedures (e.g., including scheduling request (SR), buffer status reporting (BSR), and delay status reporting (DSR)). In examples, a device may be configured to receive configuration information. The configuration information may indicate a metric associated with reporting network coding (NC) protocol data unit (PDU) related information. The metric may be further associated with a volume of NC SDUs or NC PDUs, at least one NC configuration parameter, or NC PDU characteristics. The volume of NC service data units (SDUs) or NC PDUs may be a minimum number of bits / bytes / NC PDUs to recover source NC SDUs or may be a total number of bits / bytes / NC SDUs associated with an NC generation (e.g., a minimum number of NC SDUs used to generate NC PDUs). The at least one NC configuration parameter may be a generation size, an NC PDU size, or a code rate. The NC PDU characteristics may be systematic NC PDUs or coded NC PDUs.

[0004] The device may be configured to apply NC to SDUs to generate NC PDUs. The device may be configured to determine at least one NC specific condition is met. The NC specific condition being met may be a trigger to send information. The at least one NC specific condition may be a change in network coding,a change in data volume, a change in radio conditions determined based on radio measurements or related proxy metrics, higher priority PDUs arriving in the buffer, or arrival of NC PDUs generated from NC SDUs that require retransmission. The change in network coding may be an activation or deactivation of NC or a change in NC configuration or parameters. The change in data volume may be an increase in volume above a configured threshold. The change in radio conditions determined based on radio measurements or related proxy metrics may be a number of hybrid automatic repeat request (HARQ) retransmissions exceeding a threshold, a time from a start of a first transmission for a HARQ process up to a completion of the HARQ process exceeding a threshold, a packet delay budget exceeding a threshold, or a number of radio link control (RLC) retransmissions exceeding a threshold.

[0005] The device may be configured to calculate NC data volume (e.g., based on the determination that the at least one NC specific condition is met and the metric associated with reporting NC PDU related information). For example, the NC data volume may be calculated based on NC PDUs (e.g., all NC SDUs) associated with NC PDUs in the buffer. The device may be configured to calculate a minimum number of bits / bytes / NC PDUs required to recover source NC PDUs based on at least one of: an SDU arrival rate, an NC processing time, generation size, channel conditions, or an NC encoding matrix. The device may be configured to calculate a packet specific classification-based volume to report in BSR. In examples, the packet specific classification-based volume may be systematic NC PDUs or coded NC PDUs.

[0006] The device may receive an indication of a scheduled resource. The device may be configured to transmit the information. The information may include NC data volume (e.g., the calculated NC data volume) and NC configuration information. The information may be transmitted via the scheduled resource. The device may transmit NC data volume and the metric associated with reporting NC PDU related information (e.g., NC configuration information). In examples, the NC data volume may be transmitted based on at least one of: a minimum number of NC PDUs required to decode NC PDUs per logical channel group (LCG), NC PDUs per LCG and one or more of generation size, NC PDU size, or code rate. In examples, NC data volume may be transmitted based on a number of NC PDUs per NC PDU characteristic in an LCG. The device may be configured to separately report an amount of data to be network coded and an amount of data that may not be network coded. The device may be configured to report a number of NC generations and the NC data volume based on a number of NC PDUs per NC PDU characteristic per NC generation in an LCG.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0008] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0009] 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. 1 A according to an embodiment.

[0010] FIG. 1 D 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. 1 A according to an embodiment.

[0011] FIG. 2 illustrates an example uplink (UL) layer 2 structure with network coding (NC) protocol in packet data convergence protocol (PDCP).

[0012] FIG. 3 illustrates an example of segmented service data unit (SDU)-based NC.

[0013] FIG. 4 illustrates an example of cross-SDU based NC.

[0014] FIG. 5 illustrates an example of a buffer status report (BSR) medium access control-control element (MAC CE) with NC protocol data units (PDUs) group by dependency (super-set).

[0015] FIG. 6 illustrates an example of a BSR MAC CE with NC configuration information in the first octet.

[0016] FIG. 7 illustrates an example of a MAC CE with NC configuration information in the first octet.

[0017] FIG. 8 illustrates an example of a BSR MAC CE with an NC code rate specified per logical channel group (LCG).

[0018] FIG. 9 illustrates an example of a BSR MAC CE with an NC PDU type specified per LCG.

[0019] FIG. 10 illustrates an example of a MAC CE with an NC PDU type specific per LCG.

[0020] FIG. 11 illustrates an example of a BSR MAC CE with an NC PDU type and an NC generation specified per LCG.

[0021] FIG. 12 illustrates an example of a MAC CE with an NC PDU type and NC generation specific per LCG.

[0022] FIG. 13 illustrates an example of WTRU processing for requesting resources for NC data transmission.

[0023] FIG. 14 illustrates an example BSR where systematic and coded packet buffer sizes are reported.

[0024] FIG. 15 illustrates an example of WTRU processing to resolve overlap between scheduling requests (SRs) and multiplexing with other uplink control information (UCI).DETAILED DESCRIPTION

[0025] 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. For example, 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.

[0026] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a ON 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. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, 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 (loT) 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), aconsumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0027] 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. By way of example, 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.

[0028] 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. 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. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0029] 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).

[0030] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, 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).

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

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

[0033] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, 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).

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

[0035] The base station 114b in FIG. 1 A 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. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0036] 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. 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. Although not shown in FIG. 1A, it will be appreciated that 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. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, 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.

[0037] 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). 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. For example, 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.

[0038] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with 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.

[0039] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, 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. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0040] 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, inp ut / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0042] Although the transmit / receive element 122 is depicted in FIG. 1 B 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.

[0043] 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 / receiveelement 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, 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.

[0044] 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. In addition, 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. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0046] 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. In addition to, or in lieu of, the information from the GPS chipset 136, 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 locationdetermination method while remaining consistent with an embodiment.

[0047] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an 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 frequencymodulated (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. 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.

[0048] 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). In an embodiment, 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 uplink (UL) (e.g., for transmission) or the downlink (e.g., for reception)).

[0049] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, 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.

[0050] 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. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0051] 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. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0052] 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 theforegoing 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.

[0053] 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. For example, 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.

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

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

[0056] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or 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. In addition, 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.

[0057] Although the WTRU is described in FIGS. 1 A-1 D 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.

[0058] In representative embodiments, the other network 112 may be a WLAN.

[0059] 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 interfaceto 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. 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). In certain representative embodiments, 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.

[0060] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, 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. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, 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) may transmit at any given time in a given BSS.

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

[0062] Very High Throughput (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. For the 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. The streams may be mapped on to the two 80 MHzchannels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving 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).

[0063] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11ah relative to those used in 802.11 n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 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).

[0064] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11ac, 802.11 af, and 802.11 ah, 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. In the example of 802.11 ah, 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.

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

[0066] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with theWTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0067] 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. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0068] 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).

[0069] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the 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). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration 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. For example, 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, 160csubstantially simultaneously. In the non-standalone configuration, 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.

[0070] 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. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0071] The CN 115 shown in FIG. 1 D 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.

[0072] 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. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling 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. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency communication (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0073] 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 managingand allocating WTRU 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.

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

[0075] The CN 115 may facilitate communications with other networks. For example, 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. In addition, 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. In one embodiment, 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.

[0076] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, 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. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0077] 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. For example, 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.

[0078] 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. For example, 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 (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0079] Reference to a timer herein may refer to determination of a time or determination of a period of time. Reference to a timer expiration herein may refer to determining that the time has occurred or that the period of time has expired. Reference to a timer herein may refer to a time, a time period, tracking the time, tracking the period of time, etc.

[0080] Systems, methods, and instrumentalities are described herein that may be associated with enhancements to uplink (UL) scheduling procedures (e.g., including scheduling request (SR), buffer status reporting (BSR), and delay status reporting (DSR)). The enhancements may be used to report network coding (NC) related information to the network to support reception of X linearly-independent NC protocol data units (PDUs) or more to recover the X NC service data units (SDUs) at the receiver, satisfy common processing deadline requirements of NC PDUs at the receiver, and / or support differentiated treatment of NC PDUs.

[0081] In examples, a WTRU may send NC related information to the network so that the scheduler can allocation a proper number and size of grant(s) for differentiated treatment of X or more than X NC PDUs with common delay budget constraints to successfully recover X NC SDUs at the receiver. The WTRU may determine NC specific condition(s) to trigger a procedure (e.g., SR, BSR, another medium access controlcontrol element (MAC CE), etc.) for transmission of information to the scheduler. The WTRU may transmit NC data volume and / or additional information (e.g., the metric associated with reporting NC PDU related information including at least the NC configuration parameters, etc.) implicitly, explicitly, or in a hybrid manner via SR and / or a MAC CE (e.g., BSR, a new MAC CE, etc.). The WTRU may track a timer associated with NC PDUs to track a remaining delay budget and satisfy the common processing deadline requirement of NC PDUs associated with an NC generation.

[0082] In examples, a WTRU may determine NC specific conditions to cancel transmission of a signal triggered to report NC PDU related and other information related for proper scheduling of data. The WTRU may perform prioritization for more than one individual SR with overlapping physical uplink control channel (PUCCH) resources in a slot (e.g., by prioritizing SR triggered for NC PDUs with higher relative priority). The WTRU may indicate positive SR using an index-based or bitmap-based mechanism based on a number of overlapping SRs if SR is multiplexed with other uplink control information (UCI). The WTRU may assign NC PDUs to NC PDU sets based on the NC configuration and the NC PDU characteristics.

[0083] In examples, a device may be configured to receive configuration information. The configuration information may indicate a metric associated with reporting NC PDU related information. The metric may be further associated with a volume of NC SDUs or NC PDUs, at least one NC configuration parameter, or NC PDU characteristics. The volume of NC SDUs or NC PDUs may be a minimum number of bits / bytes / NC PDUs to recover source NC SDUs or may be a total number of bits / bytes / NC SDUs associated with an NC generation (e.g., a minimum number of NC SDUs used to generate NC PDUs). The at least one NC configuration parameter may be a generation size, an NC PDU size, or a code rate. The NC PDU characteristics may be systematic NC PDUs or coded NC PDUs.

[0084] The device may be configured to apply NC to SDUs to generate NC PDUs. The device may be configured to determine at least one NC specific condition is met. The NC specific condition being met may be a trigger to send information. The at least one NC specific condition may be a change in network coding, a change in data volume, a change in radio conditions determined based on radio measurements or related proxy metrics, higher priority PDUs arriving in the buffer, or arrival of NC PDUs generated from NC SDUs that require retransmission. The change in network coding may be an activation or deactivation of NC or a change in NC configuration or parameters. The change in data volume may be an increase in volume above a configured threshold. The change in radio conditions determined based on radio measurements or related proxy metrics may be a number of hybrid automatic repeat request (HARQ) retransmissions exceeding a threshold, a time from a start of a first transmission for a HARQ process up to a completion of the HARQ process exceeding a threshold, a packet delay budget exceeding a threshold, or a number of radio link control (RLC) retransmissions exceeding a threshold.

[0085] The device may be configured to calculate NC data volume (e.g., based on the determination that the at least one NC specific condition is met and the metric associated with reporting NC PDU related information). For example, the NC data volume may be calculated based on NC PDUs (e.g., all NC SDUs) associated with NC PDUs in the buffer. The device may be configured to calculate a minimum number ofbits / bytes / NC PDUs required to recover source NC PDUs based on at least one of: an SDU arrival rate, an NC processing time, generation size, channel conditions, or an NC encoding matrix. The device may be configured to calculate a packet specific classification-based volume to report in BSR. In examples, the packet specific classification-based volume may be systematic NC PDUs or coded NC PDUs.

[0086] The device may receive an indication of a scheduled resource. The device may be configured to transmit the information. The information may include NC data volume (e.g., the calculated NC data volume) and NC configuration information. The information may be transmitted via the scheduled resource. The device may transmit NC data volume and the metric associated with reporting NC PDU related information (e.g., NC configuration information). In examples, the NC data volume may be transmitted based on at least one of: a minimum number of NC PDUs required to decode NC PDUs per logical channel group (LCG), NC PDUs per LCG and one or more of generation size, NC PDU size, or code rate. In examples, NC data volume may be transmitted based on a number of NC PDUs per NC PDU characteristic in an LCG. The device may be configured to separately report an amount of data to be network coded and an amount of data that may not be network coded. The device may be configured to report a number of NC generations and the NC data volume based on a number of NC PDUs per NC PDU characteristic per NC generation in an LCG.

[0087] Network coding is a packet processing function that may transform X input packet(s) into Y output packet(s). X may be greater than or equal to 2 and Y may be greater than or equal to X (e.g., with the case X equal to 1 and Y equal to 1 being a special case). The X input packets being coded together may form a network coding generation (denoted hereinafter as a generation). An input packet may be an SDU or a segment of an SDU. An output packet may be denoted PDU. Network coding may be a packet processing function that transforms X SDUs into Y PDUs. The PDUs associated with the same generation may include the same or different characteristics. Such characteristics may be systematic packets, coded packets, less- innovative coded packets, more-innovative coded packets, etc. Furthermore, there may be dependencies between PDUs of the same generation in the sense that: the receiver may (e.g., may need to) receive X PDUs or more to recover the X SDUs; how many more PDUs or specific PDUs needed (e.g., that may be needed) by the receiver to receive the X SDUs may depend on the PDUs already available at the receiver; and / or the scheduling of the PDUs of the same generation may be constrained by the same overall delay budget.

[0088] FIG. 2 illustrates an example uplink layer 2 structure with NC protocol in packet data convergence protocol (PDCP). The concepts of PDU sets may be leveraged (e.g., based on examplesherein). In examples, the PDUs generated by the protocol layer may implement the NC function (e.g. as shown in FIG. 2), and not PDUs of layers above the access stratum (e.g., application layer). For example, PDU set related information such as PDU Set Importance (PSI), a PDU Set Integrated Handling Indication (PSIHI), or a PDU Set Delay Budget (PSDB) may be introduced in relation with PDUs generated by NC. The same generation may include more than one dependent PDU set that have PDUs that share similar characteristics. The receiver may (e.g., may need to) receive some or all dependent PDU sets to recover the source packets. Such features (e.g., requirements) of different PDU sets for source packet recovery may be denoted hereinafter as dependent-PDU set integrated handling.

[0089] FIG. 3 illustrates an example of segmented SDU-based NC. FIG. 4 illustrates an example of cross-SDU based NC. The NC encoding process may support one or multiple NC generations in parallel as shown in FIG. 3 and FIG. 4. FIG. 3 shows segmented-SDU based NC in which one NC SDU may be segmented and NC may be performed on the segments (e.g., one-to-many mapping). As shown, each NC SDU may belong to a different NC generation. FIG. 4 shows cross-SDU based NC on which NC may be performed using multiple NC SDUs per NC generation (e.g., many-to-many mapping). As shown, more than one NC SDU (e.g., X NC SDUs) may belong to the same NC generation. Techniques of handling these PDUs differently may be required to maximize the performance benefit of network coding (e.g., given that PDUs / PDU sets from same generation may have different characteristics). For example, NC PDUs from the same generation may be mapped to different LCHs based on their characteristics. PDUs / PDU sets with different characteristics from the same NC generation may be mapped to different RLC entities as a function of one or more of their characteristics. PDUs / PDU sets with different characteristics from the same NC generation may be mapped to the same RLC entity (e.g., additionally). PDUs / PDU sets with different characteristics may be handled differently using one or more of medium access control (MAC) layer processing (e.g., UL scheduling), physical layer (PHY) resources (time, space, frequency), or transmission techniques (e.g., waveform, multiple input multiple output (MIMO) / beamforming techniques, etc.).

[0090] Example SR procedures may not carry or consider information (e.g., additional information) related to PDUs, required to recover source packets, and / or having the same delay budget requirement. Enhancements proposed for SR procedures may be useful to meet the delay requirements of PDUs.

[0091] Example BSR / DSR enhancements may support delay aware scheduling. SR enhancements may bring further improvement since SR precedes BSR / DSR if no resources are available for BSR / DSRtransmission. Enhancements may (e.g., may also) be needed for BSR and DSR procedures if reporting data volume and / or delay information in the context of NC (e.g., if NC is controlled by the WTRU).

[0092] Example SR, BSR and DSR may not provide information that can support differentiated handling of PDUs with different characteristics. For example, if PDU sets with different characteristics arrive over the same logical channel (LCH), the SR configured for this LCH may not provide the network with any PDU set- related information. Similarly, BSR and DSR may transmit volume and / or delay report(s) at the granularity level of a logical channel group. Enhancements may be required to the (e.g., aforementioned) procedures to support differentiated handling requirements of PDU sets.

[0093] Systems, methods, and instrumentalities are described herein that may be associated with enhancements to uplink scheduling procedures (e.g., including SR, BSR, and DSR). The enhancements may be used to report NC related information to the network to support reception of X linearly-independent NC PDUs or more to recover the X NC SDUs at the receiver, satisfy common processing deadline requirements of NC PDUs at the receiver, and / or support differentiated treatment of NC PDUs (e.g., if NC is performed in PDCP as shown in FIG. 2).

[0094] The concepts of multi-bit SR, DSR, and enhancements for BSR may be leveraged to enable UL scheduling procedures to support differentiated treatment of NC PDUs bounded common delay budget. Examples herein may provide information that may be transmitted to the gNB so that the gNB can schedule resources to enable successful transmission of X out of Y NC PDUs associated with an NC generation over channels that have low or no mutual correlation to maximize performance benefit of NC. Examples herein may perform signaling to report NC specific information such that the scheduler can issue correct size and number of grants for the data volume that may (e.g., may need to) be transmitted to recover X NC SDUs at the receiver within a certain time. Examples of scheduling of NC PDUs while accounting for dependent- PDU set integrated handling and common delay deadline requirement of NC PDUs are provided herein. Examples of the WTRU determining and reporting NC data volume and what NC specific information can be reported to the gNB to enable efficient scheduling for successful reception of X out of Y NC PDUs within a certain deadline to recover the X NC SDU are provided herein. Examples of enhancements that can be considered for the signaling (e.g. SR, BSR, another MAC CE, etc.) to enable NC PDU related information transmission for efficient and timely scheduling of resources are provided herein.

[0095] Examples of NC PDU related information transmission(s) are provided herein. Examples of information associated with NC PDUs that can be reported to the network to support differentiatedtreatment of NC PDUs and account for dependent-PDU set integrated handling and common delay budget constraints of NC PDUs if NC is employed in UL transmission are provided herein.

[0096] A WTRU may send information related to at least NC PDUs (e.g., volume based on a minimum number of NC PDUs required to decode the NC SDUs, total NC PDUs associated with a generation, NC SDUs associated with NC generation(s) etc.), NC PDU characteristics, NC configuration parameters, etc. The WTRU may send the information via SR, BSR, another MAC CE, etc., so that a scheduler may allocate a proper number and size of grant(s) for a differentiated treatment of X or more than X NC PDUs with common delay budget constraints to successfully recover X NC SDUs at the receiver.

[0097] A WTRU may receive configuration information. The configuration information may indicate a metric for reporting NC PDU related information. The metric may be (e.g., may be further) associated with a volume of NC SDUs or NC PDUs (e.g. a minimum number of bits / bytes / NC PDUs to recover source NC SDUs, a total number of bits / bytes / NC SDUs associated with an NC generation (e.g., a minimum number of NC SDUs used to generate NC PDUs), etc.), at least one NC configuration parameter(s) (e.g., generation size, NC PDU size, code rate, etc.), NC PDU characteristics (e.g., systematic NC PDUs, coded NC PDUs, etc.), etc.

[0098] The WTRU may receive data in its buffer and apply NC to SDUs or generating NC PDUs. The WTRU may determine that at least one NC-specific condition is met. The NC-specific condition being met may be a trigger to send information (via e.g. SR, BSR, another MAC CE, etc.). The at least one NC- specific condition may be: a change in NC such as activation / deactivation of NC; a change in NC configuration / parameters (e.g. in case of WTRU autonomous selection of NC configuration); a change in data volume such as increase in volume above a (pre)-configured threshold; if a WTRU experiences a change in radio conditions that may be determined based on radio measurements or related proxy metrics (e.g., a number of HARQ retransmissions exceeding a threshold, a time from a start of first transmission for a HARQ process up to the completion of the HARQ process exceeding a threshold (e.g., an average time exceeding a threshold), a packet delay budget or similar exceeding a threshold; or a number of RLC retransmissions exceeding a threshold); if higher priority / importance NC PDUs (e.g., systematic, highly innovative, etc.) arrive in the buffer than those currently in the buffer; arrival of NC PDUs generated from NC SDUs which require retransmission; etc.

[0099] The WTRU may calculate the NC-data volume (e.g., based on the determination that the at least one NC specific condition is met and the metric associated with reporting NC PDU related information). For example, the WTRU may calculate a minimum number of bits / bytes / NC PDUs required to recover sourceNC SDUs (e.g., based on a minimum number of NC PDUs required to decode the source NC SDUs (e.g., based on an SDU arrival rate, an NC processing time, a generation size, channel conditions, and / or an NC encoding matrix, etc.). The WTRU may calculate data volume based on NC SDUs (e.g., all NC SDUs) associated with the NC PDUs in the buffer. The WTRU may calculate packet specific classification-based volume (e.g. systematic NC PDUs, coded NC PDUs, etc.) to report in BSR.

[0100] The WTRU may receive an indication of scheduled resources for transmission (e.g., via SR, BSR, new MAC CE, etc.). The WTRU may transmit information. The information may include NC data volume (e.g., the calculated NC data volume) and additional information (e.g. NC configuration information / parameter(s), etc.) (e.g., via SR, BSR, another MAC CE, etc.). The information may be transmitted via the scheduled resource. The WTRU may report (e.g., may separately report) the amount of data to be network coded and the amount of data that may not be network coded (e.g., may report an amount of data before network coding that may be inputted into NC but has not been network coded yet and report (e.g., separately report) an amount of data that may not be network coded). The WTRU may transmit the NC data volume based on minimum number of NC PDUs required to decode NC SDUs per LCG. The WTRU may transmit the NC data volume based on NC SDUs per LCG and one or more of generation size, NC PDU size, code rate, etc. The WTRU may transmit the NC data volume based on a number of NC PDUs per NC PDU characteristics in an LCG. The WTRU may report a number of NC generations and the NC data volume based on a number of NC PDUs per NC PDU characteristics per NC generation in an LCG.

[0101] A common deadline requirement may be if NC SDUs of the same generation may be able to be decoded once the receiver has received the dependent packets (e.g., all of the dependent packets) in this generation. It may be possible that NC SDUs used in forming a generation have different deadlines. However, since all NC PDUs may be needed to decode all NC SDUs, the most conservative NC SDU deadline may be used for all NC PDUs. Thus, all NC PDUs may have the same deadline.

[0102] An innovative packet may be a coded packet that if received, may be useful for decoding the generation (e.g., increases the rank of the generator matrix). This may imply that the packet is formed with coefficients that may be linearly independent of the other packets already received.

[0103] A level of innovation may be usefulness of the packet if decoding a generation of packets. Some packets may (e.g., may only) enable the decoding of a small amount of source packets while others may enable the decoding of a large amount of source packets.

[0104] The WTRU is “configured with” may refer to the scenario that the WTRU receives a configuration from the gNB or another node (e.g., group coordinator WTRU). In cases that the WTRU receives a configuration from the gNB, the WTRU may receive a dedicated radio resource control (RRC) configuration or SIB from the gNB. In cases that the WTRU receives a configuration from another node, the WTRU may receive configuration via sidelink communication (e.g., PC5 RRC). The WTRU ‘configured’ or ‘(pre)- configured’ to perform an action may (e.g., may also) refer to the scenario that the WTRU is hard coded to perform the action.

[0105] Examples of a WTRU configured to determine NC PDU related and other information are provided herein. In examples, a WTRU may be configured to report NC PDU related and / or other information to the scheduler. The WTRU may (e.g., may also) be configured to determine values of one or more NC PDU related information elements to evaluate condition(s) to trigger or cancel transmission of a signal for reporting NC PDU related information to the network. The WTRU may be configured to determine and / or report metric(s) associated with one or more of the following information elements: a volume of NC SDUs or NC PDUs; a volume of non-NC data; a number of NC generations; a priority or importance of NC PDUs; timing information of NC SDUs or NC PDUs; NC configuration parameter(s); an NC SDU retransmission indication; a number of grants; or attribute(s) of preferred or required grant(s).

[0106] For a volume of NC SDUs or NC PDUs, a WTRU may be configured to determine a volume associated with the NC PDUs for reporting to the network or if evaluating triggering or cancellation condition(s) for transmission of NC PDU related information. For example, the WTRU may be configured to determine minimum number of bits / bytes / NC PDUs required to recover source NC SDUs associated with the most time-sensitive NC generation(s) in ideal channel conditions where time sensitivity may be determined based on value of timer associated with NC SDUs or NC PDUs. For example, the WTRU may be configured to determine an estimated minimum number of bits / bytes / NC PDUs required to recover source NC SDUs associated with the most time-sensitive NC generation(s), according to actual channel condition(s). For example, the WTRU may be configured to determine a total number of bits / bytes / NC PDUs associated with the most time-sensitive NC generation(s). For example, the WTRU may be configured to determine minimum number of bits / bytes / NC PDUs required to recover source NC SDUs associated with NC generations (e.g., all NC generations) in ideal channel conditions. For example, the WTRU may be configured to determine a total number of bits / bytes / NC PDUs required to recover source NC SDUs associated with NC generations (e.g., all NC generations). For example, the WTRU may be configured to determine a minimum number of bits / bytes / NC PDUs required to recover pending source NCSDUs (e.g., all pending source NC SDUs) according to the actual channel conditions. For example, the WTRU may be configured to determine packet specific classification-based volume (e.g. based on characteristics of PDUs such as systematic packets, coded packets, less innovative packets, more innovative packets, etc.).

[0107] For a volume of NC SDUs or NC PDUs, a WTRU may be configured to determine a volume of NC SDUs associated with NC generation(s) for reporting to the network and the scheduler may determine the buffer status (e.g., to allocate scheduling grant(s) for associated NC PDUs) as a function of one or more of a reported volume based on NC SDUs, NC configuration parameter(s), channel conditions, etc. For example, the WTRU may be configured to determine a total volume of NC SDUs associated with the most time-sensitive NC generation(s). For example, the WTRU may be configured to determine a total volume of NC SDUs associated with all NC generation(s). For example, the WTRU may be configured to report volume of NC SDUs for complete NC generation(s) (e.g., all complete NC generation(s)) and for NC generation(s) expected to be complete by a certain occasion (e.g., at the volume reporting occasion, before expected grant reception, etc.).

[0108] For a volume of non-NC data, the WTRU may be configured to determine a volume of data that may or may not be network coded.

[0109] For a number of NC generations, the WTRU may be configured to report number of NC generations to which data in the buffer belong.

[0110] For a priority or importance of NC PDUs, the WTRU may be configured to determine a priority or importance of NC PDU set(s) to which the NC PDU(s) in the buffer belong for reporting or evaluation of triggering / cancellation criteria for transmission of NC PDU related information (e.g., where priority or importance of NC PDU set is as defined in examples herein).

[0111] For timing information of NC SDUs or NC PDUs, the WTRU may be configured to determine a remaining delay budget of NC PDU(s) / PDU set(s) associated with an NC generation for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information. For timing information of NC SDUs or NC PDUs, the WTRU may be configured to determine time spent in the buffer by NC PDU(s) / PDU set(s) for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information. For timing information of NC SDUs or NC PDUs, the WTRU may be configured to report the residual value of the PDCP discard timer of an oldest NC SDU associated with an NC generation. For timing information of NC SDUs or NC PDUs, the WTRU maybe configured to report the residual value of the PDCP discard timer of the oldest NC SDU associated with a NC PDU, NC PDU set, etc.

[0112] For NC configuration parameter(s), the WTRU may be configured to report one or more of NC configuration parameter(s) (e.g., galois field size, rank of encoding matrix, NC code rate, generation size, segment (NC PDU) size, etc.).

[0113] For an NC SDU retransmission indication, the WTRU may be configured to indicate if one or more NC PDUs in the buffer are associated with NC SDUs which are being retransmitted.

[0114] For a number of grants, the WTRU may be configured to report a number of grants required to achieve transmit diversity for the NC PDUs associated with the same generation(s).

[0115] For attribute(s) of preferred / required grant(s), the WTRU may report one or more attributes of required grant(s) that may support efficient transmission of NC PDUs.

[0116] Examples of a WTRU starting a timer associated with NC PDUs / PDU sets are provided herein. In examples, the WTRU may be configured with one or more condition(s) to start a timer associated with NC PDUs or NC PDU sets at a pre-configured occasion. The timer may be tracked for evaluation of triggering or cancellation conditions of NC PDU related information element(s) reporting, determine remaining delay budget of one or more of NC PDUs, NC PDU sets or NC generation, report a timing value associated with NC PDUs to the network, discard NC PDUs, etc. The WTRU may start the timer based on one or more of the following: NC PDU set related parameters (e.g. PSI, PSIHI, remaining delay budget, etc.); NC PDU related parameters (e.g., type, importance, etc.); or parameters of the associated NC generation (e.g., rank of encoding matrix, PDU set size, generation size, etc.)

[0117] In examples, a WTRU may be configured with one or more of the following condition(s) to start a timer associated with NC PDUs / PDU set(s) when NC PDU(s) are generated: a PSI associated with the generated NC PDUs is equal or greater than a threshold; a remaining delay budget is equal or below a threshold; the number of generated NC PDUs associated with a generation is equal or above a threshold; or the NC PDUs (e.g., all the NC PDUs) associated with a generation becoming available.

[0118] For a PSI associated with the generated NC PDUs being equal or greater than a threshold, the WTRU may be configured to start timer on when one or more NC PDUs are generated and the WTRU may be configured (e.g., further configured) to start timer associated with NC PDUs if the PSI of the PDU set associated with the generated NC PDUs is equal or above threshold.

[0119] For a remaining delay budget being equal or below a threshold, the WTRU may be configured to start a timer when one or more NC PDUs are generated and the WTRU may be configured (e.g., further configured) to start a timer associated with NC PDUs if the delay budget of the PDU set associated with the generated NC PDUs is equal or below a threshold.

[0120] For the number of generated NC PDUs associated with a generation being equal or above a threshold, the WTRU may be configured to start a timer when NC PDUs are generated and the WTRU may be configured (e.g., further configured) to start a timer associated with NC PDUs if the number of generated NC PDUs associated with an NC generation is equal or above a threshold.

[0121] For the NC PDUs (e.g., all the NC PDUs) associated with a generation becoming available, the WTRU may be configured to start a timer associated with NC PDUs if NC PDUs (e.g., all NC PDUs) associated with an NC generation are generated.

[0122] In examples, the WTRU may be configured one or more of the following condition(s) to start a timer associated with NC PDUs / PDU set(s) when one or more NC PDUs belonging to a NC PDU set are transmitted using an uplink grant: NC PDU(s) is / are required to recover NC SDU(s) due to a dependent PDU set integrated handling requirement; a PSIHI is set to ‘true” for the NC PDU set; the number of NC PDUs, associated with the NC PDU set(s), remaining in the buffer is equal or above a threshold; the number of transmitted NC PDUs, associated with the NC PDU set(s), is smaller than a threshold; or the importance of one or more remaining NC PDUs, associated with the NC PDU set(s), is equal or above a threshold.

[0123] For NC PDU(s) being required to recover NC SDU(s) due to a dependent PDU set integrated handling requirement, the WTRU may be configured to start a timer if one or more NC PDUs associated with an NC generation are transmitted and the WTRU may be configured (e.g., further configured) to a start timer associated with NC PDUs if some PDUs belonging to NC PDU set(s), which may be required to recover source packet(s) (NC SDU(s)) as per a dependent PDU set integrated handling indication, from the NC generation are still in the buffer.

[0124] For a PSIHI being set to ‘true’ for the NC PDU set, the WTRU may be configured to start a timer if one or more NC PDUs associated with an NC generation are transmitted and the WTRU may be configured (e.g., further configured) to start a timer associated with NC PDUs if some PDUs associated with the same NC PDU set are still in the buffer and the PSIHI is set to ‘true’, 1 , etc. for the NC PDU set.

[0125] For the number of NC PDUs, associated with the NC PDU set(s), remaining in the buffer being equal or above a threshold, the WTRU may be configured to start a timer if one or more NC PDUs associated with an NC generation are transmitted and the WTRU may be configured (e.g., further configured) to start a timer associated with NC PDUs if the number of remaining PDUs, associated with the same generation, is equal or above a threshold.

[0126] For the number of transmitted NC PDUs, associated with the NC PDU set(s), being smaller than a threshold, the WTRU may be configured to start a timer if one or more NC PDUs associated with an NC generation are transmitted and the WTRU may be configured (e.g., further configured) to start a timer associated with NC PDUs if the number of transmitted PDUs, associated with the same generation, is equal or below a threshold.

[0127] For the importance of one or more remaining NC PDUs, associated with the NC PDU set(s), being equal or above a threshold, the WTRU may be configured to start a timer if one or more NC PDUs associated with an NC PDU set are transmitted and the WTRU may be configured (e.g., further configured) to start a timer associated with NC PDUs if the importance of one or more remaining NC PDUs, from the associated PDU set, is equal or above a threshold.

[0128] Examples of initialization values for the timer are provided herein. In examples, the WTRU may initialize the timer with an RRC configured value. In examples, the WTRU may determine an initialization value of the timer based on a metric to be reported to the network or based on the triggering / cancellation condition(s) for NC PDU related information reporting as a function of one or more of the following: PDCP discard timer of NC SDU(s); remaining delay budget; or arrival time of NC SDU(s).

[0129] A WTRU may be configured to report the remaining time associated with NC SDUs / NC PDUs / NC PDU sets so that a common processing deadline requirement of the PDU set(s) associated with an NC generation may be satisfied by the scheduler. In examples, the WTRU may be configured to report or consider a residual value of a remaining delay budget of the NC PDU and may start the timer associated with the NC PDU with the remaining delay budget of the NC PDU. In examples, the WTRU may be configured to report or consider a residual value of a remaining delay budget of the NC PDU set and may start the timer associated with the PDU set with the remaining delay budget of the NC PDU set to which the NC PDU belong. In examples, the WTRU may be configured to report a remaining time before an NC SDU, associated with the NC generation to which NC PDUs / NC PDU sets belong, may be discarded. The scheduler may use this information to determine the deadline by which one or more NC PDUs from the WTRU may be delivered to or processed by the receiving NC entity. The WTRU may start the value oftimer with the residual value of the PDCP discard timer associated with the oldest NC SDU of NC generation.

[0130] A WTRU may be configured to track time spent by NC PDUs / NC PDU sets in the buffer for reporting to the network or to consider for trigg ering / cance Nation of other NC PDU related information transfer to the network. The scheduler may use this information to determine the remaining delay budget for delay aware scheduling. In examples, time spent may be the time since arrival of the NC SDU in the buffer and the WTRU may start the timer with the time elapsed since arrival of the NC SDU. If there is more than one NC SDU associated with an NC generation (e.g., many-to-one or many-to-many mapping between NC SDUs and NC PDUs), time spent may be based on the arrival time of the oldest NC SDU associated with the NC generation and the WTRU may start the timer with the time elapsed since arrival of the oldest NC SDU associated with the NC generation. In examples, time spent may be based on the time elapsed since one or more NC PDUs / PDU set(s) associated with the same NC generation was transmitted using one or more previous grant(s) and the WTRU may start a timer associated with NC PDU set(s) with ‘zero’. In examples, time spent may be the time since a generation or arrival of NC PDU(s) in the buffer and the WTRU may start the timer associated with NC PDU(s) with ‘zero’.

[0131] Examples of a WTRU determining values for NC PDU related and other information elements are provided herein. In examples, a WTRU may determine values of NC PDU related information elements, at the expected reporting occasion, based on one or more of: NC configuration parameters, NC SDU characteristics, an NC PDU set configuration, a PDCP discard timer, time spent in the buffer, an NC processing time, channel conditions, a one trip time, or a round trip time. The WTRU may determine one or more of the following NC PDU related information elements: the WTRU may determine a volume of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information; the WTRU may determine a volume of NC SDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information; the WTRU may determine a priority or importance of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information; the WTRU may determine timing information of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information; or the WTRU may determine one or more of NC configuration parameter(s) (e.g., generation size, code rate, rank of generator matrix, segment (NC PDU) size, etc.) based on some (pre-)configured conditions (e.g., QoS requirements of NC SDUs, channel conditions, etc.) and report one or more of theseNC configuration parameters to the network. The network may utilize this information to determine NC PDU related information for efficient scheduling.

[0132] For the WTRU determining a volume of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a volume based on a minimum number of NC PDUs required to decode the NC SDUs associated with one or more generation(s) in perfect channel condition(s) as a function of one or more of: an SDU arrival rate, an NC processing time, a generation size, or a rank of the encoding matrix. For the WTRU determining a volume of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a volume based on an estimated number of NC PDUs required to decode the NC SDUs associated with one or more generations as a function of one or more of: an SDU arrival rate, a PDCP discard timer, an NC processing time, a generation size, actual channel conditions, a packet error rate requirement, or a rank of the encoding matrix. For the WTRU determining a volume of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a volume based on NC PDUs (e.g., all NC PDUs) associated with one or more generation(s) as a function of one or more of: an SDU arrival rate, an NC processing time, a PDCP discard timer, a generation size, or a rank of the encoding matrix.

[0133] For the WTRU determining a volume of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a volume based on a minimum number of NC PDUs ideally required to decode the NC SDUs associated with the most time-sensitive NC generation(s) as a function of one or more of: a remaining delay budget of NC PDU sets, a generation size, or a rank of the encoding matrix. For the WTRU determining a volume of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a volume based on an estimated number of NC PDUs required to decode the NC SDUs associated with the most time-sensitive NC generation(s) as a function of one or more of: channel conditions, a packet error rate requirement, a remaining delay budget of NC PDU sets, a generation size, or a rank of the encoding matrix. For the WTRU determining a volume of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a volume based on NC PDUs (e.g., all NC PDUs) associated with the most time-sensitive NC generation(s) as a function of one or more of: channelconditions, a remaining delay budget of NC PDU sets, a generation size, or a rank of the encoding matrix. For the WTRU determining a volume of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a packet specific classification-based volume (e.g., based on characteristics of PDUs such as systematic packets, coded packets, less innovative packets, more innovative packets, etc.).

[0134] For the WTRU determining a volume of NC SDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a volume corresponding to NC SDUs associated with complete NC generation(s) (e.g., all complete NC generation(s)) at the instant of volume determination. For the WTRU determining a volume of NC SDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a volume corresponding to NC SDUs associated with NC generation(s) (e.g., all NC gen eration (s)) expected to be complete by a certain occasion (e.g., at the volume reporting occasion as a function of generation size, NC SDU arrival rate, NC processing time, etc.).

[0135] For the WTRU determining a priority or importance of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a priority of NC PDUs as the priority of the NC PDU sets, to which they belong, configured as a function of importance of NC SDU(s) and one or more of: NC PDU characteristics (e.g., systematic PDU, coded PDU, etc.) or a remaining delay budget (e.g., as described herein).

[0136] For the WTRU determining timing information of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a timing value from the value of the running timer associated with NC PDUs at the expected transmission occasion of the signal with NC PDU related information. When condition(s) to start a timer for NC PDUs associated with an NC generation are satisfied, the WTRU may already have a running timer associated with NC PDUs and the WTRU may determine timing information of NC PDU as the timer value at the expected transmission occasion of signal with NC PDU related information.

[0137] For the WTRU determining timing information of NC PDUs in the buffer for reporting to the network or if evaluating triggering / cancellation condition(s) for transmission of NC PDU related information, the WTRU may determine a timing value for NC PDUs associated with an NC generation based on one or more of: an RRC configured value, an NC PDU set delay budget, a PDCP discard timer, an arrival time of NC SDU(s), an NC processing time, a one trip time (OTT), a round trip time (RTT), or a number of HARQretransmission. When condition(s) to start a timer for NC PDUs associated with an NC generation are not already satisfied, the WTRU may not have a running timer associated with NC PDUs and the WTRU may be configured to determine the timing value based on one or more of the afore-mentioned parameters. For example, a WTRU may be configured to report a remaining delay budget (e.g., via an SR) and the WTRU may (e.g., may further) be configured to a start timer associated with NC generation when NC PDUs (e.g., all NC PDUs) associated with the NC generation are generated. The WTRU may determine to trigger an SR to request resources due to arrival of the NC PDUs in the buffer. The WTRU may not have a running timer associated with those NC PDUs since the WTRU may not have yet generated NC PDUs (e.g., all NC PDUs) associated with the NC generation. The WTRU may determine a value for reporting via an SR based on one or more of: an RRC configured value, an NC processing time, a residual value of PDCP discard timer of the oldest NC SDU associated with NC PDU(s) in the buffer, an OTT, an RTT, or a maximum or expected number of HARQ retransmission.

[0138] Examples of NC PDU related information transmission procedures are provided herein. Examples of a WTRU triggering reporting of an NC PDU set and / or other information are provided herein. A WTRU may be configured with one or more condition(s) to trigger transmission of a signal to inform the network about NC PDUs / PDU set(s) and / or non-NC data. The WTRU may trigger transmission based on one or more of the following: a remaining delay budget of NC PDUs / PDU sets; a volume of the NC PDUs / SDUs associated with an NC generation; a change in a network coding configuration; or NC PDU / PDU set related parameters or characteristics (e.g., PSI, PSI HI, etc.).

[0139] A WTRU may be configured one or more of the following condition(s) to trigger transmission of signal (e.g. SR, BSR, DSR, other MAC CE, etc.): a change in network coding configuration / operation; a change in data volume or a change in radio conditions; timing associated with NC PDUs / PDU set(s) being below or above a threshold; a volume of NC PDUs, associated with an NC generation, already transmitted using previous uplink grant(s) being equal or below a threshold; a volume of NC PDUs, associated with an NC generation, remaining in the buffer being equal or above a threshold; any number of NC PDUs associated with an NC generation remaining in the buffer if PSIHI indicates that PDUs (e.g., all PDUs) are required for decoding the PDU set at the receiver (e.g., PSIHI is ‘true’, 1, etc.); NC PDUs from dependent PDU sets which may be required to recover the source packets associated with an NC generation remaining in the buffer; importance of NC PDUs remaining in the buffer being equal or above a threshold; generation of NC PDUs; arrival of NC PDU(s) in the buffer such that importance of the NC PDU(s) is equal or above a threshold; arrival of NC PDU(s) in the buffer such that importance of the NC PDU(s) is higherthan importance of NC PDU(s) already available in the buffer; arrival of NC PDU(s) in the buffer; or available grant(s) not sufficient to provide diversity required for transmission of NC PDUs.

[0140] For the change in network coding configuration / operation, the WTRU may be configured to trigger transmission of a signal such as SR, BSR, DSR other MAC CE, etc. (e.g., with NC PDU related and / or other information if there is a change in network coding configuration / operation such as if activating or deactivating of an NC, changing NC configuration / parameters (e.g., in case of WTRU autonomous selection of NC configuration), etc.).

[0141] For the change in data volume, the WTRU may be configured to trigger transmission of a signal such as SR, BSR, DSR other MAC CE, etc. (e.g., with NC PDU related and / or other information if there is a change in volume of data in the buffer (e.g., an increase in volume is above a (pre)configured threshold)).

[0142] For the change in radio conditions, the WTRU may be configured to trigger signaling (e.g. SR, BSR, DSR, other MAC CE, etc.) if the WTRU experiences a change in radio conditions that may be determined based on radio measurements or related proxy metrics (e.g., a number of HARQ retransmissions exceeding a threshold, a time from a start of first transmission for a HARQ process up to its completion exceeding a threshold (e.g., an average time exceeding a threshold), a packet delay budget or similar exceeding a threshold, a number of RLC retransmissions exceeding a threshold, etc.).

[0143] For timing associated with NC PDUs / PDU set(s) being below or above a threshold, the WTRU may be configured to transmit time spent in the buffer and the WTRU may be configured (e.g., further configured) with condition(s) to trigger signal transmission (e.g. SR, DSR, other MAC CE, etc.) with timing information if the time spent by NC PDUs in the buffer is equal or above a threshold.

[0144] For timing associated with NC PDUs / PDU set(s) being below or above a threshold, the WTRU may be configured to transmit a remaining time (e.g., a remaining delay budget) and the WTRU may be configured (e.g., further configured) with a condition to trigger signal transmission (e.g. SR, DSR, etc.) with timing information if the residual value of a timer associated with NC PDUs is equal or below a threshold.

[0145] For timing associated with NC PDUs / PDU set(s) being below or above a threshold, the WTRU may be configured to transmit volume information and the WTRU may be configured (e.g., further configured) with a condition to trigger signal transmission (e.g. SR, BSR, DSR, etc.) with volume information of the PDUs if the remaining delay budget of NC PDUs associated is equal or below a threshold.

[0146] For timing associated with NC PDUs / PDU set(s) being below or above a threshold, the WTRU may be configured to transmit a signal (e.g. an SR) requesting resources for NC PDUs if the remaining delay budget of NC PDUs is equal or below a threshold.

[0147] For the volume of NC PDUs, associated with an NC generation, already transmitted using previous uplink grant(s) being equal or below a threshold, the WTRU may be configured to transmit timing information related to NC PDUs in the buffer and the WTRU may be configured (e.g., further configured) with a condition to trigger a signal transmission (e.g. SR, DSR, etc.) with timing information if the volume of NC PDUs, associated with an NC generation, already transmitted using previous uplink grant(s) is equal or below a threshold.

[0148] For the volume of NC PDUs, associated with an NC generation, already transmitted using previous uplink grant(s) being equal or below a threshold, the WTRU may be configured to transmit volume information related to NC PDUs in the buffer and the WTRU may be configured (e.g., further configured) with a condition to trigger a signal transmission (e.g. SR, BSR, DSR, etc.) with volume information if the volume of NC PDUs, associated with an NC generation, already transmitted using previous uplink grant(s) is equal or below a threshold.

[0149] For the volume of NC PDUs, associated with an NC generation, already transmitted using previous uplink grant(s) being equal or below a threshold, the WTRU may be configured to transmit a signal requesting resources for NC PDUs without explicit volume information (e.g., an SR), if the volume of NC PDUs, associated with an NC generation, already transmitted using previous uplink grant(s) is equal or below a threshold.

[0150] For a volume of NC PDUs, associated with an NC generation, remaining in the buffer being equal or above a threshold, the WTRU may be configured to transmit timing information related to NC PDUs in the buffer and the WTRU may be configured (e.g., further configured) with a condition to trigger a signal transmission (e.g. SR, DSR, other MAC CE, etc.) with timing information if the volume of NC PDUs, associated with an NC generation, remaining in the buffer is equal or above a threshold.

[0151] For a volume of NC PDUs, associated with an NC generation, remaining in the buffer being equal or above a threshold, the WTRU may be configured to transmit volume information related to NC PDUs in the buffer and the WTRU may be configured (e.g., further configured) with a condition to trigger a signal transmission (e.g. SR, BSR, DSR, etc.) if the volume of NC PDUs, associated with an NC generation, remaining in the buffer is equal or above a threshold.

[0152] For a volume of NC PDUs, associated with an NC generation, remaining in the buffer being equal or above a threshold, the WTRU may be configured to transmit a signal requesting resources for NC PDUs without explicit volume information (e.g., via an SR), associated with an NC generation, remaining in the buffer is equal or above a threshold.

[0153] For any number of NC PDUs associated with an NC generation remaining in the buffer if PSIHI indicates PDUs (e.g., all PDUs) are required for decoding the PDU set at the receiver (e.g., PSIHI is ‘true’, 1, etc.), the WTRU may be configured to trigger a transmission of a signal (e.g., with timing information, volume, PSI, etc.) if one or more NC PDUs belonging to an NC PDU set are transmitted and some PDUs of the PDU set are still in the buffer and PSIHI indicates PDUs (e.g., all PDUs) are required for decoding the PDU set at the receiver (e.g., PSIHI is ‘true’ for the PDU set).

[0154] For NC PDUs from dependent PDU sets which are required to recover the source packets associated with an NC generation remaining in the buffer, the WTRU may be configured to trigger a transmission of a signal (e.g., with timing information, volume, PSI, etc.) if one or more NC PDUs from dependent PDU sets which are required to recover the source packets associated with the NC generation remain in the buffer.

[0155] For importance of NC PDUs remaining in the buffer being equal or above a threshold, the WTRU may be configured to trigger a transmission of a signal such as SR, BSR, DSR, etc. (e.g., with NC PDU related information) if some NC PDUs from one or more NC generations are transmitted and the importance of one or more NC PDUs remaining in the buffer is equal or above a threshold.

[0156] For generation of NC PDUs, the WTRU may be configured with a condition to trigger a transmission of a signal such as SR, BSR, DSR, etc. (e.g., with NC PDU related information) if generating one or more NC PDU(s).

[0157] For the arrival of NC PDU(s) in the buffer such that importance of the NC PDU(s) is equal or above a threshold, the WTRU may be configured with a condition to trigger a transmission of a signal such as SR, BSR, DSR, etc. (e.g., with NC PDU related information) if NC PDU(s) arrive in the buffer such that importance of the NC PDU(s) is equal or above a threshold.

[0158] For the arrival of NC PDU(s) in the buffer such that importance of the NC PDU(s) is higher than importance of NC PDU(s) already available in the buffer, the WTRU may be configured with a condition to trigger a transmission of a signal such as SR, BSR, DSR, etc. (e.g., with NC PDU related information) if NC PDU(s) arrive in the buffer such that importance of the NC PDU(s) is higher than importance of NC PDU(s)already available in the buffer. In examples, the importance of NC PDU(s) may be the same as the importance of the NC PDU set (e.g., PSI). In examples, the importance of NC PDU(s) may be based on the characteristics of NC PDUs (e.g., systematic packet, coded packet, less innovative packet, more innovative packet, etc.). In examples, the importance of NC PDUs may be determined based on whether NC SDU(s) associated with NC PDUs require retransmission or not (e.g., NC PDUs associated with NC SDU(s) which require retransmission may have higher importance).

[0159] For the arrival of NC PDU(s) in the buffer such that such that remaining delay budget of the NC PDU(s) is lower than that of NC PDU(s) already available in the buffer, the WTRU may be configured with a condition to trigger a transmission of a signal such as SR, BSR, DSR, etc. (e.g., with NC PDU related information) if NC PDU(s) arrive in the buffer such that a remaining delay budget of the NC PDU(s) is lower than that of NC PDU(s) already available in the buffer.

[0160] For the arrival of NC PDU(s) in the buffer, the WTRU may be configured with a condition to trigger a transmission of a signal such as SR, BSR, DSR. etc. (e.g., with NC PDU related information) if NC PDU(s) arrive in the buffer (e.g., if there is no NC PDU(s) pending for transmission in the buffer).

[0161] For available grant(s) not sufficient to provide diversity required for transmission of NC PDUs, the WTRU may be configured with a condition to trigger a transmission of a signal such as SR, BSR, DSR, etc. (e.g., with NC PDU related information) if available grant(s) cannot provide the diversity required for transmission of NC PDUs associated with one or more NC generations.

[0162] Examples of values / levels for transmitting NC PDU related information are provided herein. A WTRU may report quantized value(s) of NC PDU related information elements(s). This may indicate a range within which value of a metric associated with NC PDUs / PDU set lies. These value(s) / range(s) may be configured by the network for reporting NC PDU related information. The level(s) may be (pre)configured in absolute unit(s) or using another metric. For example, to report a remaining delay budget, level(s) may be (pre)configured in absolute unit(s) of time (e.g., ms, s, etc.), or these may be (pre)configured using another metric (e.g., PSDB, sym, si, spreading factor (SF), etc.).

[0163] A WTRU may be configured with a single level for reporting NC PDU related information. A WTRU may be (pre)configured with one or more of the following: a default or initial value for reporting NC PDU related information; or a semi-statically or dynamically configured value which may be used by a WTRU to report information associated with NC PDUs / PDU sets.

[0164] A WTRU may be configured with more than one value corresponding to different ranges for reporting NC PDU related information. The following may be specified and / or (pre)configured in relation to at least one of the following reported values: a list / table of values; a minimum value / maximum value / step size; or default or initial values.

[0165] For a list / table of values, the list / table of ranges may be specified or (pre)configured which may be used by a WTRU to report information associated with NC PDUs / PDU sets.

[0166] For a minimum value / maximum value / step size, the maximum value and / or minimum value and / or step size may be configured for dynamic control of NC PDU related information reporting by the WTRU. This may be used by the WTRU to determine different ranges for reporting NC PDU related information.

[0167] Examples of WTRU transmitting NC PDU related and other information in an explicit or implicit manner are provided herein. A WTRU may report NC PDU related and / or other information, explicitly, implicitly, or using a combination of explicit and implicit approaches, to the network for proper scheduling of data. In examples, a WTRU may report NC PDU related information explicitly via multi-bit SR, a MAC CE such as enhanced BSR / DSR, or another MAC CE, etc. In examples, a WTRU may report NC PDU related information implicitly. For instance, a WTRU may report different values of an information element implicitly via different SR configurations. In examples, a WTRU may report NC PDU related information using a combination of implicit and explicit approaches. A WTRU may report part of a value of an information element implicitly (e.g., via different SR configurations) and another part of value of the information element may be reported explicitly (e.g., via multi-bit SR, a MAC CE such as BSR, DSR, etc.). An actual value of the information element may be determined based on both explicit and implicit information.

[0168] In examples, a WTRU may perform in-band signaling (e.g., WTRU may report NC configuration information, specific to the data volume being reported, together with BSR, DSR, SR, etc.). In examples, a WTRU may perform out of band signaling (e.g., WTRU may report NC configuration information which may be not specific to a particular instance of data volume report, in a separate MAC CE from the BSR or DSR, which may report data volume).

[0169] Examples of signaling to explicitly report NC PDU related and / or other information are provided herein. Examples of transmitting NC PDU related and / or other information via MAC CE are provided herein. Information regarding NC PDUs and NC PDU sets may be reported to the network for assistance with scheduling. Information about NC PDUs / PDU sets such as volume, delay information, importance, etc. maybe reported via BSR / DSR or a MAC CE (e.g., a new MAC CE). For example, if there are three levels of innovativeness of NC PDUs (e.g., high, medium, low), then a threshold may be set such that reporting may be done with high and medium priority NC PDUs (e.g., only with high and medium priority NC PDUs).

[0170] FIG. 5 illustrates an example of a BSR MAC CE with NC PDUs group by dependency (super-set). A MAC CE may report NC PDU / NC PDU set related information by reporting information such as data volume, NC configuration, etc. with other NC PDUs of a similar characteristic / type. This may be a reporting volume for groups of PDUs / PDU sets or PDU super-sets. This MAC CE may be an enhanced BSR / DSR or a new MAC CE. An example enhanced BSR MAC CE is shown in FIG. 5. The first octet may be a bitmap where i-th bit may be a flag indicating the presence of the buffer size field for the i-th logical channel group. The WTRU may report a volume of data per LCG in the UL buffer, in octet 2 - octet m+1, in bits / bytes, or reports an index pointing to a bit / byte value in a table. Octet m+2 may be a bitmap where the i-th bit may be a flag indicating the presence of the buffer size field for the i-th PDU super-set. The remaining octets may be the buffer size values for the specified PDU super-sets. Note that the data volume for the LCG / PDU super-set may be one of several possible metrics (e.g., as described herein).

[0171] Since data volume may be reported with NC PDUs of a similar characteristic / type, the network may become aware of the volume of NC PDUs per characteristics / types. This may allow the network to make more informed scheduling decisions as the network may decide if it wants to allocate resources to the WTRU for systematic vs coded packets, highly innovative vs less innovative packets, etc.

[0172] Depending on the configuration, the “super-set” reporting may be done within a LCG or independent of LCGs. Information for dependent (e.g., all dependent) PDUs / PDU sets may be (e.g., may not need to) be reported. The WTRU may report the volume (e.g., only the volume) of NC PDUs of a certain priority, etc.

[0173] FIG. 6 illustrates an example of a BSR MAC CE with NC configuration information in the first octet. In examples, the WTRU may report the autonomously determined NC code rate and / or NC PDU size via a MAC CE as the NC may produce PDUs of a fixed size and the same NC configuration may apply to LCGs (e.g., all LCGs). This MAC CE may be an enhanced BSR / DSR or a new MAC CE. For example, if a WTRU can select one out of 16 possible code rates and there are 16 possible NC PDU sizes, an enhanced BSR MAC CE may be as shown in FIG. 6. The WTRU may report the number of PDUs per LCG in the buffer size rather than a raw bit / byte value. The first octet may be allocated for NC configuration information. In the first octet, 4 bits may be allocated for indicating 1 of 16 possible NC PDU sizes and 4bits may be allocated for indicating 1 of 16 NC code rates. The second octet may be a bitmap where i-th bit may be a flag indicating the presence of the buffer size field for the i-th logical channel group.

[0174] FIG. 7 illustrates an example of a MAC CE with NC configuration information in the first octet. In examples, a WTRU may report the size of NC PDUs in bits / bytes as well as the code rate that may be used for generating NC PDUs (e.g., so that network can determine a number of redundant packets). For example, if a WTRU can select one out of 16 possible code rates and if there are 16 possible NC PDU sizes, a MAC CE for signaling NC configuration information may be as shown in FIG. 7. The MAC CE may include one octet, wherein 4 bits may be allocated for indicating 1 of 16 possible NC PDU sizes and 4 bits may be allocated for indicating 1 of 16 NC code rates.

[0175] FIG. 8 illustrates an example of a BSR MAC CE with an NC code rate specified per LCG. In examples, the WTRU may report the NC configuration per group (e.g., LCG, NC PDU characteristic group, etc.) of NC PDUs via a MAC CE. This MAC CE may be an enhanced BSR / DSR or a new MAC CE. An example enhanced BSR MAC CE is shown in FIG. 8. The first octet may be a bitmap where i-th bit may be a flag indicating the presence of the buffer size field for the i-th logical channel group. For LCGs (e.g., each LCG), 2 bits may be allocated for indicating 1 of 4 possible NC code rates. Data volumes in the BSR may be reported at a more granulated level than the LCG. The WTRU may report a volume of data in the UL buffer in bits / bytes or report an index pointing to a bit / byte value in a table. Note that the data volume may be one of several possible metrics (e.g., as described herein).

[0176] FIG. 9 illustrates an example of a BSR MAC CE with an NC PDU type specified per LCG. In examples, the WTRU may report the NC PDU characteristics per group (e.g., LCG, generation, etc.) of NC PDUs via a MAC CE. This MAC CE may be an enhanced BSR / DSR or a new MAC CE. An example enhanced BSR MAC CE is shown in FIG. 9. The first octet may be a bitmap wherein i-th bit is a flag indicating the presence of the buffer size field and NC PDU type information for the i-th logical channel group. For LCGs (e.g., each LCG), 4 bits may be allocated as a bitmap where the i-th bit may be a flag indicating the presence of the possible NC PDU types / characteristics in this LCG. This may be the second half of octets 2 and above in FIG. 9. The network may be aware of NC PDU types in addition to data volume. Note that one possible type of NC PDU may be a systematic NC PDU or NC PDU where no NC has been performed. The WTRU may report a volume of data in the UL in bits / bytes or reports an index pointing to a bit / byte value in a table. Note that the data volume may be one of several possible metrics (e.g., as described herein). This may be the first half of octets 2 and above as shown in FIG. 9.

[0177] FIG. 10 illustrates an example of a MAC CE with an NC PDU type specific per LCG. In examples, a WTRU may report an NC PDU type in LCGs (e.g., each LCG). An example MAC CE is shown in FIG. 10. The first octet may be a bitmap wherein i-th bit may be a flag indicating the presence of the NC PDU type information for the i-th logical channel group. For LCGs (e.g., each LCG), an octet may be allocated as a bitmap where the i-th bit may be a flag indicating the presence of the possible NC PDU types / characteristics in this LCG. These may be octets 2 and above as shown in FIG. 10. The network may be aware of the NC PDU type(s) in the LCGs (e.g., each LCG) in addition to the data volume per LCG and thus may make more informed scheduling decisions. Note that one possible type of NC PDU may be a systematic NC PDU or NC PDU where no NC has been performed.

[0178] FIG. 11 illustrates an example of a BSR MAC CE with an NC PDU type and an NC generation specified per LCG. In examples, the WTRU may report the NC PDU characteristics per group (e.g., LCG, generation, etc.) per generations of NC PDUs via a MAC CE. This MAC CE may be an enhanced BSR / DSR or a new MAC CE. An example enhanced BSR is shown in FIG. 11 . The first octet may be a bitmap where i-th bit may be a flag indicating the presence of the buffer size and other information elements’ field for the i-th logical channel group. In the subsequent octets, information about LCGs may be indicated. In each of these octets, 2 bits may be allocated as a bitmap wherein the i-th bit may be a flag indicating the presence of the possible NC PDU types / characteristics and 2 bits may be allocated for a bitmap where the i-th bit may be a flag indicating the presence of NC PDUs from 2 possible generations. Note that one possible type of NC PDU may be a systematic NC PDU or NC PDU where no NC has been performed. The WTRU may report a volume of data in the UL in bits / bytes or report a table index that maps to a bit / byte volume in the first 4 bits of the octet. Note that the data volume may be one of several possible metrics (e.g., as described herein).

[0179] FIG. 12 illustrates an example of a MAC CE with an NC PDU type and NC generation specific per LCG. In examples, a WTRU may report the type of NC PDUs in LCGs (e.g., each LCG) and the NC generations to which NC PDUs belong. An example MAC CE used for reporting the NC PDU type per LCG is shown in FIG. 12. The first octet may be a flag indicating the presence of the buffer size field for the logical channel group i up to 8 LCGs. For subsequent octets, the first 4 bits of each octet may be allocated as a bitmap wherein the i-th bit may be a flag indicating the presence of the 4 possible NC PDU types / characteristics. The second 4 bits of each octet may be allocated as a bitmap wherein the i-th bit may be a flag indicating the presence of NC PDUs forming the 4 possible generations.

[0180] Examples of SR design to explicitly report NC PDU related information are provided herein. In examples, a WTRU may be configured to report NC PDU related information explicitly via SR. In examples, a WTRU may provide m=log2(M) bits of information via SR, where M may be the constellation size and each constellation point may represent a certain value of an information element. For example, a WTRU may apply a binary phase shift keying (BPSK) modulation and provide 1 bit of information corresponding to two code points, each representing a (pre)configured / standardized value of an information element which the WTRU may report via SR. In examples, quadrature phase shift keying (QPSK) modulation may be applied to report 2 bits of information corresponding to four different (pre)configuredZstandardized values of an information element. In examples, QPSK modulation may be applied to report 2 bits of information corresponding to different (pre)configuredZstandardized values of two distinct information elements.

[0181] A WTRU may be configured with M different threshold levels and SR transmission may be triggered if a value of an information element associated with PDU(s) / PDU set(s) goes above / below configured thresholds (e.g., each configured threshold). The codepoint transmitted via SR may indicate the threshold above / below which the information element value has gone resulting in SR transmission.

[0182] A WTRU may set the values of bits b(0),...,b(m-1) according to the code point, the WTRU is configured to report. Table 1 shows an example of mapping 1 bit or 2 bits code points for timing indication to the threshold values, if a WTRU is configured with more than one threshold to report delay budget via SR.Table 1 : Example mapping of timing indicator field values / code points to a threshold

[0183] A WTRU may be configured with one threshold and one codepoint out of the M code points for SR transmission. If a value of an information element associated with PDU(s) / PDU set(s) goes above / below the configured threshold, the WTRU may trigger an SR transmission. The WTRU may be configured with the same SR resource configuration for up to M logical channels such that each logical channel may be configured with a different code point to indicate a value of a reported information elementin SR. If a WTRU transmits one of the configured codepoints in the SR to the network, the WTRU may implicitly inform (e.g., also inform) the network which logical channel triggered the SR.

[0184] Examples of implicit reporting of NC PDU related information are provided herein. A WTRU may report NC PDU related information implicitly via different SR configurations. The WTRU may be configured with more than one SR configuration per LCH and the configurations (e.g., each configuration) may correspond to a different value of an NC PDU relation information element reported via SR. For example, the WTRU may be configured with different PUCCH formats, different values of cyclic shifts for sequence generation, different time and / or frequency resources for PUCCH for SR reporting to report different values of an NC PDU relation information element.

[0185] A WTRU may be configured with one threshold and two different resource configurations for SR transmission. A first SR resource configuration may be associated with an NC PDU related information element value below the threshold. A second SR resource configuration may be associated with an NC PDU related information element value above the threshold. If an information element value associated with NC PDU(s) / NC PDU set(s) is below the configured threshold, the WTRU may trigger an SR transmission on the first resource. If an information element value associated with NC PDU(s) / NC PDU set(s) is above the configured threshold, the WTRU may trigger an SR transmission on the second resource.

[0186] A WTRU may be configured with more than one level for a reporting value of an information element and a resource configuration for each level for SR transmission. If an information element value associated with NC PDU(s) / NC PDU set(s) is below / above the configured level, the resource used for SR transmission may indicate the value of the information element associated with NC PDU(s) / NC PDU set(s).

[0187] A WTRU may be configured to report different values of one or more information elements via a combination of one or more parameters associated with a PUCCH resource configuration to represent different levels. For example, the WTRU may be configured with a PUCCH format 0 to report one range of values of an information element and the WTRU may be configured with a PUCCH format 1 to report another range of values for the information element. The WTRU may be configured to report actual values within a range via another resource parameter (e.g., PRB offset, cyclic shift, etc.).

[0188] Examples of a WTRU reporting NC PDU related information using a combination of explicit and implicit mechanisms are provided herein. A WTRU may report NC PDU related information using a combination of implicit and explicit approaches. For example, the WTRU may be configured with differentPUCCH formats associated with different sets of values of an information element. The WTRU may transmit an SR using a 1 bit / 2 bits modulated symbol to indicate one out of two / four values of an information element from a set associated with the PUCCH format. In examples, the WTRU may be configured with different cyclic shifts for sequence selection associated with different ranges of values of an information element. The WTRU may transmit an SR with a 1 bit / 2 bits modulated symbol to indicate one out of two / four values from the range associated with the sequence cyclic shift.

[0189] Examples of cancellation criteria for signals triggered to request resources for NC PDUs are provided herein. A WTRU may be configured with one or more condition(s) to cancel transmission of a signal triggered to inform a network about NC PDUs / PDU set(s) and other information required for proper scheduling of data. The WTRU may cancel signaling based on one or more of the following: a successful transmission of minimum number of NC PDUs associated with pending NC SDUs; a remaining delay budget being above a threshold; discarding of NC PDUs; an expiration of a timer; a transmission of all pending data; or a transmission of all MAC CEs with information required for the proper scheduling of data.

[0190] For the successful transmission of a minimum number of NC PDUs associated with pending NC SDUs, the WTRU may cancel transmission of a signal (e.g., such as SR, BSR, DSR, other MAC CE, etc.) reporting NC PDU related and / or other information if a minimum number of NC PDUs required to recover the pending NC SDUs have been successfully transmitted. The WTRU may discard from the buffer the data the WTRU may no longer need to transmit (e.g., in this case).

[0191] For the remaining delay budget being above a threshold, the WTRU may cancel transmission of a signal (e.g., such as SR, BSR, DSR, other MAC CE, etc.) reporting NC PDU related and / or other information if a remaining delay budget of NC PDUs remaining in the buffer is above a threshold.

[0192] For the discarding of NC PDUs, the WTRU may cancel a transmission of a signal (e.g., such as SR, BSR, DSR, other MAC CE, etc.) reporting NC PDU related and / or other information if the WTRU discards pending NC PDUs in the buffer (e.g., due to discard (acknowledgment (ACK)-based or timer based) of all NC SDUs associated with NC PDUs).

[0193] For the expiration of a timer, the WTRU may cancel transmission of a signal (e.g., such as SR, BSR, DSR, other MAC CE, etc.) reporting NC PDU related and / or other information if the timer expires associated with each of pending NC PDUs in the buffer.

[0194] For the transmission of all pending data, the WTRU may cancel transmission of a signal (e.g., such as SR, BSR, DSR, other MAC CE, etc.) reporting NC PDU related and / or other information if the UL grant(s) can accommodate pending data (e.g., all pending data) available for transmission.

[0195] For the transmission of MAC CEs (e.g., all MAC CEs) with information required for proper scheduling of data, the WTRU may cancel a pending SR reporting NC PDU related information triggered for a MAC CE (e.g., BSR, DSR, or a new MAC CE) if the MAC CE which includes volume and / or other NC related information is transmitted.

[0196] Examples of the prioritization / multiplexing of SR are provided herein. Examples of the WTRU performing prioritization / multiplexing of SR with overlapping PUCCH resources are provided herein. The WTRU may perform prioritization for more than one individual SR with overlapping PUCCH resources in a slot (e.g., by prioritizing an SR triggered for NC PDUs with higher relative priority). The WTRU may determine relative priority of NC PDUs based on one or more of the following: a delay sensitivity of the NC PDUs or NC SDUs; an importance of an NC PDU set; an importance of NC SDUs; (re)transmission of NC SDUs; characteristics of NC PDUs; or a priority of a logical channel.

[0197] For the delay sensitivity of the NC PDUs or NC SDUs, the WTRU may evaluate a relative priority of NC PDUs based on the delay sensitivity of NC SDUs (e.g., based on PDCP discard timer) associated with NC PDUs or the delay sensitivity of NC PDUs (e.g., based on value of timer associated with NC PDUs or NC PDU set etc.) of an LCH for prioritization of SR. For example, the WTRU may prioritize SR triggered for NC PDUs with a lower remaining delay budget.

[0198] For the importance of the NC PDU set, the WTRU may evaluate the relative priority of NC PDUs based on the importance of an NC PDU set to which NC PDUs belong for prioritization of SR. For example, there may be one-to-one mapping between the priority of NC PDUs and priority of the NC PDU sets. The WTRU may prioritize SR triggered for NC PDUs belonging to NC PDU sets with higher importance / priority (e.g., where priority / importance of NC PDUs may be configured as described herein).

[0199] For the importance of NC SDUs, the WTRU may evaluate the relative priority of NC PDUs based on the importance of NC SDUs associated with the NC PDUs. For example, the WTRU may prioritize SR triggered for NC PDUs generated from NC SDUs with higher importance.

[0200] For the (re)transmission of NC SDUs, the WTRU may evaluate the relative priority of NC PDUs based on whether the NC SDUs associated with the NC PDUs are being retransmitted or not. For example,the WTRU may prioritize SR triggered for NC PDUs generated from NC SDUs which are being retransmitted.

[0201] For characteristics of NC PDUs, the WTRU may evaluate the relative priority of NC PDUs based on characteristics of NC PDUs (e.g., systematic NC PDU, coded NC PDU, etc.). For example, the WTRU may prioritize SR for systematic NC PDUs over SR triggered for coded NC PDUs.

[0202] For the priority of the logical channel, the WTRU may evaluate the relative priority of NC PDUs based on the priority of the LCH to which they belong. For example, the WTRU may prioritize SR for NC PDUs from a LCH with higher priority.

[0203] In examples, the WTRU may select a PUCCH resource for multiplexing two or more overlapping SRs. The WTRU may perform multiplexing in an ascending order of PUCCH resources IDs or logical channel IDs. The WTRU may perform multiplexing of overlapping SRs if a number of overlapping PUCCH resources for an SR in a slot is below a threshold.

[0204] Examples of a WTRU performing prioritization / multiplexing of SR for multiplexing with other UCI are provided herein. If there is an overlap between a first PUCCH resource configured for SR transmission and a second PUCCH resource configured for HARQ-ACK information bits, a WTRU may prioritize SR or HARQ-ACK based on the delay budget of NC PDUs for which the SR was triggered. For example, the WTRU may transmit SR in the first PUCCH resource configured for SR transmission if the remaining delay budget of NC PDUs is below a (pre)configured threshold. Otherwise, the WTRU may transmit HARQ-ACK information bits in the second PUCCH resource.

[0205] A WTRU may be configured to transmit multiple PUCCHs for multiple SRs in a slot, with SR transmission occasions that may overlap with a transmission of a PUCCH with HARQ-ACK information or channel state information (CSI) report(s) from the WTRU in the slot. The WTRU may determine whether to multiplex information for one SR (e.g., perform SR prioritization) or more than one SRs (e.g., multiplex overlapping SRs) with other UCI bits based on a number of overlapping PUCCH resources for the SR in the slot. For example, if a number of overlapping PUCCH resources for SRs is below a (pre)configured threshold, the WTRU may perform multiplexing of more than one SR for transmission of SR bits with other UCI. Otherwise, if a number of overlapping PUCCH resources for SRs is equal or above the (pre)configured threshold, the WTRU may perform prioritization among overlapping SRs based on the relative importance of NC PDUs (e.g., as described herein) and multiplex the information of a prioritized SR with other UCI bits.

[0206] If a WTRU multiplexes SR information with other UCI bits in a PUCCH resource, the WTRU may indicate schedulingRequestResourceld for the positive SR(s) using a bitmap-based approach or indexbased approach. The WTRU may determine which mechanism (e.g., bitmap based, index based) to use for an indication of a positive SR based on a number of overlapping PUCCH resources for an SR in the slot. For example, if number of overlapping PUCCH resources for SRs is below a (pre)configured threshold, the WTRU may include a bitmap in the multiplexed UCI bits to indicate scheduling request resources ID(s) with positive SR. The bits in the bitmap may be mapped to the scheduling request resource ID(s) of the overlapping SRs in an ascending or descending order. The WTRU may set a bit in the bitmap to ‘one’ if the corresponding SR is positive. Otherwise, the WTRU may set the bit to ‘zero’. For example, if a number of overlapping PUCCH resources for SRs is equal or above the (pre)configured threshold, the WTRU may include an index of the scheduling request resource ID with a positive SR in the UCI bits.

[0207] Examples of a configuration of NC PDUs / PDU sets are provided herein. PDUs may be assigned into PDU sets based on characteristics. In examples, the WTRU may assign NC PDUs (e.g., all NC PDUs) associated with an NC generation to the same PDU set. The PDUs (e.g., all the PDUs) regardless of type / characteristics may be included in the PDU set. In examples, the WTRU may assign NC PDUs to different NC PDU sets based on type / characteristics of NC PDUs. Different PDU sets may (e.g., may then) experience differentiated treatment (e.g., differentiated handling). For example, the WTRU may assign systematic NC PDUs (e.g., all systematic NC PDUs) of a generation to one PDU set and coded packets (e.g., all coded packets) to a different PDU set. The WTRU may assign highly innovative packets to one PDU set and less innovative packets to a separate PDU set. For example, the WTRU may assign PDUs formed from higher priority SDUs to one PDU set and PDUs formed from lower priority SDUs to a separate PDU set. For example, the WTRU may assign NC PDUs to different PDU sets based on decoding complexity parameters such as field size or density.

[0208] PDU set assignments may be based on one or a confluence of several variables. This may yield two or more PDU sets for each generation. For example, there may be one PDU set including systematic packets (e.g., all systematic packets) in a generation and a separate PDU set including coded packets (e.g., all coded packets). There may be two PDU sets including coded packets, one for highly innovative packets, and one for less innovative packets. The coded packets may be divided into different NC PDU sets randomly.

[0209] Examples of determining a remaining delay budget for NC PDU sets are provided herein. The remaining delay budget of a PDU set may be a parameter that indicates how much time is left before thePDUs in the PDU set may be received by the base station. If the PDUs are received past this time, the PDUs may not be useful. This parameter may be configured based on the integrated handling requirement (e.g., whether all PDUs in the set need to be received).

[0210] In examples, the WTRU may determine the remaining PDU set delay budget as a function of the NC PDU characteristics, the NC configuration parameters, and the discard timer of the NC SDUs used to form the NC PDUs in the NC PDU set. For example, in the case of one-to-many mapping, the WTRU may determine the remaining delay budget of the NC PDU set to be the remaining PDCP discard time of the NC SDU used to form the NC PDU set. For example, in the case of many-to-many mapping, the WTRU may determine the remaining delay budget of the NC PDU set to be the most stringent remaining PDCP discard timer of the NC SDUs used to form the NC PDU set. For example, in the case of many-to-many mapping, the WTRU may determine the remaining delay budget of the NC PDU set to be the least stringent remaining PDCP discard timer of the NC SDUs used to form the NC PDU set. For example, the WTRU may determine the remaining delay budget of the NC PDU set including systematic packets to be the most stringent remaining PDCP discard timer of the NC SDUs used to form the NC PDU set and the remaining delay budget of the NC PDU set including coded packets to be the least stringent remaining PDCP discard timer of the NC SDUs used to form the NC PDU set.

[0211] Examples of determining a remaining delay budget for NC PDUs are provided herein. The remaining delay budget may be a parameter that indicates how much time is left before the packet may be received by the base station. If the packet is received past this time, the packet may be considered expired as it is not useful. This parameter may be defined for NC SDUs as per the PDCP discard timer.

[0212] To meet the common deadline requirements of NC PDUs, the WTRU may set the remaining delay budget of NC PDUs (e.g., all NC PDUs) in the same generation to be the lowest remaining delay budget of the NC SDUs (e.g., all NC SDUs) used to form the NC PDUs in the generation. For example, in the one-to-many mapping case, the WTRU may assign NC PDUs (e.g., all NC PDUs) a remaining delay budget as a function of the PDCP discard timer of the NC SDU used to form the PDUs. For example, in the many-to-many mapping case, the WTRU may assign NC PDUs (e.g., all NC PDUs) a remaining delay budget as a function of the PDCP discard timer of the NC SDU used in forming the generation. For example, in the many-to-many mapping case, the WTRU may assign NC PDUs a remaining delay budget as a function of the PDCP discard timer of the NC SDUs used to form each NC PDU. If on-the-fly decoding is used, the remaining delay budget of the NC SDUs may still be met.

[0213] NC PDUs’ (e.g., all NC PDUs’) part of a generation may use the remaining delay budget as a function of the PDCP discard timer of the NC SDUs used in forming the generation. NC PDUs from multiple generations may be in the same NC PDU set. The WTRU may assign a remaining delay budget to be the lowest remaining delay budget of NC SDUs (e.g., all NC SDUs) used to form the PDUs in the generations.

[0214] The WTRU may assign NC PDUs (e.g., each NC PDU) a different remaining delay budget based on the NC PDU’s characteristics. As described herein, these characteristics may (e.g., may also) be used in a PDU set assignment by the WTRU. For example, if there is a PDU set including systematic packets (e.g., only systematic packets), then the WTRU may assign these PDUs as a function of the PDCP discard timer of the NC SDU used to form them. If there is a PDU set including coded packets, the WTRU may assign the PDUs in this PDU set no / infinity delay budget. Because the NC PDUs in this second set are acting as redundant packets, these PDUs may or may not be required for decoding and thus may not be treated as urgent compared to the systematic packets. For example, if there is a PDU set including systematic packets (e.g., only systematic packets), then the WTRU may assign these PDUs as a function of the PDCP discard timer of the NC SDU used to form them. If there is a PDU set including coded packets, the WTRU may assign the PDUs in this set as a function of the PDCP discard timer of the NC SDUs used to form the NC PDUs. Because the NC PDUs in this second set are acting as redundant packets, these PDUs may still be useful for decoding if any of the NC SDUs used to form the NC PDU have yet to be decoded and have not expired. For example, if there is a PDU set including systematic packets (e.g., only systematic packets), then the WTRU may assign these PDUs the remaining delay budget as a function of the PDCP discard timer of the NC SDU used to form them. If there is a PDU set including coded packets, the WTRU may assign the PDUs in this set to be another middle value of the remaining delay budget as a function of the PDCP discard timer of the NC SDUs used to form the NC PDUs. This value may be configured such that it meets the delay requirements for most (e.g., but not all) of the NC SDUs used to form the NC PDU. Because the NC PDUs in this second set are acting as redundant packets, these PDUs may (e.g., may still) be useful for decoding as long as any of the NC SDUs used to form the NC PDU have yet to be decoded and have not expired.

[0215] Examples of determining PDU set integrated handling requirements for NC PDU sets are provided herein. In examples, PDUs (e.g., all PDUs) in a generation may be a part of the same PDU set. The WTRU may configure the PDU set integrated handling requirement to “false” or 0 indicating that not all PDUs in the set may (e.g., may need to) be received.

[0216] In examples, the WTRU may assign NC PDU sets (e.g., each NC PDU set) a remaining PDU set integrated handling requirement based on the NC PDU’s characteristics. For example, if there is a PDU set with higher priority and / or higher innovation packets, the WTRU may set the PDU set integrated handling requirement to “true” or 1 indicating that PDUs (e.g., all PDUs) in the set may (e.g., may need to) be received. If there is a PDU set with lower priority and / or less innovative packets, the WTRU may set the PDU set integrated handling requirement to “false” or 0 indicating that not all PDUs in the set may (e.g., may need to) be received.

[0217] Examples of determining dependent PDU set integrated handling requirements for NC PDU sets are provided herein. The dependent PDU set integrated handling indicator may indicate if the PDU set is dependent on other PDU sets. A PDU set may be dependent on another PDU set if they are part of the same generation and the dependent PDU set may be required to decode the generation.

[0218] In examples, the PDUs (e.g., all the PDUs) in a generation may be a part of the same PDU set. The WTRU may configure the dependent PDU set integrated handling requirement to be “false” or 0 as this PDU set may be sufficient for decoding the generation.

[0219] In examples, the WTRU may assign NC PDU sets (e.g., each NC PDU set) the dependent PDU set integrated handling indicator based on the characteristics of the NC PDUs in the PDU sets and WTRU autonomous decision. For example, the WTRU may create two PDU sets for a generation, one including systematic packets and one including a number of coded packets that is insufficient to decode the whole generation. The WTRU may configure the dependent PDU set integrated handling requirement of the PDU set including systematic packets (e.g., only systematic packets) to be “false” or 0 as this PDU set may be sufficient for decoding the generation. The WTRU may configure the dependent PDU set integrated handling requirement of the PDU set including coded packets (e.g., only coded packets) to be “true” or 1 as this PDU set may require at least part of the other PDU set to decode the generation.

[0220] In examples, the WTRU may assign NC PDU sets (e.g., each NC PDU set) the dependent PDU set integrated handling indicator based on the characteristics of the NC PDUs in the PDU sets and the network command of NC configuration parameters. For example, the WTRU may create two PDU sets for a generation, one including systematic packets and one including a number of coded packets that may be insufficient to decode the whole generation. The WTRU may configure the dependent PDU set integrated handling requirement of the PDU set including systematic packets (e.g., only systematic packets) to be “false” or 0 as this PDU set may be sufficient for decoding the generation. The WTRU may configure thedependent PDU set integrated handling requirement of the PDU set including coded packets (e.g., only coded packets) to be “true” or “false” depending on channel conditions.

[0221] Examples of determining PDU set importance for NC PDU sets are provided herein. The PDU set importance may be a relative level of importance compared to the other PDU sets.

[0222] In examples, the PDUs (e.g., all the PDUs) in a generation may be a part of the same PDU set. The WTRU may configure the PDU set’s importance as a function of the importance of the NC SDU(s) used for the generation. For example, in the one-to-many case, the WTRU may assign the importance based on the importance of the singular NC SDU that is being segmented. For example, in the many-to- many case, the WTRU may assign the importance based on the importance of the NC SDUs being encoded. If the NC SDUs are of variable importance, the WTRU may assign the importance as the highest, lowest, or a middle level importance.

[0223] In examples, the WTRU may assign NC PDU sets (e.g., each NC PDU set) a PDU set importance based on the characteristics of the NC PDUs in the PDU sets. For example, the WTRU may create two PDU sets for a generation, one including systematic packets and one including a number of coded packets that may be insufficient to decode the whole generation. The WTRU may assign the systematic packets higher importance than the coded packets as the systematic packets may be required for decoding while the coded packets are not essential. For example, if there is a PDU set including highly innovative packets, then the WTRU may assign the PDU set a higher importance level than a PDU set including less innovative packets. The WTRU may assign NC PDUs in a generation into two PDU sets, one including packets coded with high priority NC SDUs and one including packets coded with low priority NC SDUs. The WTRU may assign a higher priority to the PDU set including packets coded with high priority NC SDUs than the PDU set including packets coded with lower priority NC SDUs.

[0224] FIG. 13 illustrates an example of WTRU processing for requesting resources for NC data transmission. FIG. 13 shows a realization of WTRU processing for reporting NC PDU related and / or other information to the scheduler where the WTRU may perform systematic NC encoding for many-to-many mapping between X NC SDUs and Y NC PDUs. The WTRU may start the timer to track a remaining delay budget of NC PDUs of one NC generation if at least X linearly independent NC PDUs are generated.

[0225] At (1), the WTRU may be configured to report a remaining delay budget (e.g., via an SR and via a MAC CE (e.g., which may also reports data volume)) such as enhanced BSR, DSR or another MAC CE, before X or more than X NC PDUs associated with an NC generation are to be processed by the receivingNC entity for successful recovery of X source NC SDUs. It may be assumed that the received configurations for reporting delay budget may include the following: a threshold for remaining delay budget reporting via an SR for each LCH and two SR resource configurations per LCH, where one SR resource configuration (e.g., configuration A) may be for the remaining delay budget below the configured threshold and the other SR resource configuration (e.g., configuration B) may be for the remaining delay budget above the configured threshold; and two or more different ranges of remaining delay budget values for reporting via the MAC CE per LCG.

[0226] At (2) and (3), if X NC SDUs arrive in the buffer, the WTRU may perform NC encoding.

[0227] At (4), NC PDUs may arrive in the LCH transmit buffer.

[0228] At (5), (6), and (7), if X linearly independent NC PDUs belong to the same NC generation become available, the WTRU may determine a remaining delay budget for the NC PDUs associated with the same generation and may start a timer to track a remaining delay budget for successful recovery of source NC SDUs associated with the NC generation.

[0229] At (8), the WTRU may determine NC specific condition(s) to request resources for transmission of NC data (e.g., the WTRU may determine if an NC is activated since transmission of a last BSR or if newly arrived NC PDUs have a higher importance than the NC PDUs already available in the buffer, etc.).

[0230] At (9), the WTRU may trigger a process for reporting volume information and a remaining delay budget of NC PDUs.

[0231] At (10), if uplink shared channel (UL-SCH) resources are available for transmission of the MACCE, (18) may be applied. Otherwise, (11) may be applied.

[0232] At (11), the WTRU may trigger a scheduling request procedure.

[0233] At (12), if a timer is already running and tracking a remaining delay budget of the NC PDUs which have triggered the SR, (13) may be applied. Otherwise, (14) may be applied.

[0234] At (13), the WTRU may transmit an SR using the SR resource configuration based on the residual value of the timer associated with the most time sensitive NC PDUs. If the residual of the timer is above the configured threshold, the WTRU may transmit an SR in the resource for configuration B.Otherwise, the WTRU may transmit an SR in the resource for configuration A. (16) and (17) may then be applied.

[0235] At (14), the WTRU may determine the remaining delay budget for the NC PDUs in the buffer based on an NC processing time, a residual value of a PDCP discard timer of the oldest NC SDUassociated with NC PDU(s) in the buffer, an OTT, an RTT, a maximum or expected number of HARQ retransmission, etc.

[0236] At (15), the WTRU may transmit an SR using the SR resource configuration based on the remaining delay budget, for the most time sensitive NC PDUs, calculated in (14). If the remaining delay budget is above the configured threshold, the WTRU may transmit an SR in the resource for configuration B. Otherwise, the WTRU may transmit an SR in the resource for configuration A.

[0237] At (16) and (17), if the WTRU receives a grant to transmit a MAC CE for reporting volume and remaining delay budget information or the grant is suitable to transmit a minimum amount of NC PDUs sufficient to recover source NC SDUs, the WTRU may cancel the pending SR. The WTRU may transmit the pending data and / or MAC CE with volume, delay budget, and other information in the scheduled UL-SCH resources.

[0238] At (18), if a timer is already running and tracking a remaining delay budget of the NC PDUs which have triggered the MAC CE transmission procedure, (19) may be applied. Otherwise, (20) may be applied.

[0239] At (19), the WTRU may transmit a MAC CE with volume information and residual value(s) of the timer(s) associated with the NC PDUs in the buffer. (22) may then be applied.

[0240] At (20), the WTRU may determine the remaining delay budget for the NC PDUs in the buffer based on an NC processing time, a residual value of a PDCP discard timer of the oldest NC SDU associated with NC PDU(s) in the buffer, an OTT, an RTT, a maximum or expected number of HARQ retransmission, etc.

[0241] At (21), the WTRU may transmit MAC CE with volume information and the remaining delay budget value(s) calculated in (20).

[0242] At (22), the WTRU may receive suitable grant(s) scheduling UL-SCH resources for data transmission.

[0243] At (23), the WTRU may transmit pending data in the available UL-SCH resources.

[0244] FIG. 14 illustrates an example BSR where systematic and coded packet buffer sizes are reported. As shown in FIG. 14, the WTRU may autonomously determine the NC configuration based on a network instruction and channel measurements and may (e.g., may then) send a MAC CE to report the configuration. The WTRU may (e.g., may then) perform in the PDCP layer and send an enhanced BSR that includes the characteristics of the NC PDUs the WTRU has generated.

[0245] The WTRU may be configured with one or more of the following conditions as a function of one or more of: NC PDU set information, characteristics, or quality of service (QoS) parameters (e.g., size, importance, type, remaining delay budget, etc.); triggering conditions for reports (e.g., SR / BSR / DSR, etc.); cancellation conditions for reports; or NC configurations. The PDCP may receive an SDU from upper layers. The WTRU may select an NC configuration based on SDU characteristics and a received configuration. The WTRU may performs an NC in a PDCP layer. The WTRU may assign NC PDUs to NC PDU sets based on the characteristics of the NC PDUs. The WTRU may send enhanced BSR based on received trigger conditions that are a function of an NC configuration and NC PDU characteristics as shown in FIG. 14. The WTRU may report data volume for systematic and / or coded packets separately for each LCG that a buffer size is being reported for. The WTRU may trigger sending of a BSR if a certain number of systematic packets are in the UL buffer. The WTRU may receive a grant from the network. The WTRU may send NC PDUs in the UL buffer.

[0246] FIG. 15 illustrates an example of WTRU processing to resolve overlap between SRs and multiplexing with other UCI. FIG. 15 shows the WTRU processing to resolve overlap between PUCCH resources for multiple SR and other UCI transmission. The SR may explicitly report NC volume information to the network.

[0247] At (1), the WTRU may receive a configuration to determine a mechanism (e.g., prioritization v / s multiplexing) to resolve an overlap of an SR transmission if an SR transmission occasion overlaps with another UCI transmission. The received configurations may include one or more of the following: a threshold on number of overlapping PUCCH resources for SR (Kthr) to determine whether to resolve overlap between SR via prioritization or multiplexing; a size of the codepoint (m) to report volume via the SR or SR multiplexed with other UCI; or M=2mvalues corresponding to M different ranges of volume that can be reported to the network.

[0248] At (2) and (3), if NC SDUs arrive in the buffer, the WTRU may perform NC encoding.

[0249] At (4), NC PDUs may arrive in the LCH transmit buffer.

[0250] At (5) and (6), the WTRU may determine NC specific conditions to trigger an SR to request resources for transmission of NC data. For example, the WTRU may determine if an NC is activated since transmission of a last BSR or if newly arrived NC PDUs have higher importance than the NC PDUs already available in the LCH transmit buffer. If there are no UL-SCH resources for at least one of a transmission of data, a MAC CE to report data volume, or NC related information, the WTRU may trigger SR.

[0251] At (7), the WTRU may determine that it is configured to transmit K PUCCHs for respective K SRs, determined by scheduling request resource IDs in an ascending order, in a slot with SR transmission occasions that may overlap with a transmission of a PUCCH with HARQ-ACK information from the WTRU in the slot.

[0252] At (8), the WTRU may determine if K is below or equal the configured threshold (if K < (Kthr)). If yes, (9) may be applied. Otherwise, (11) may be applied.

[0253] At (9), if K < (Kthr), the WTRU may perform multiplexing to resolve overlap between SRs.

[0254] At (10), the WTRU may transmit a PUCCH with OACKHARQ-ACK information bits in a resource using a PUCCH format configured to transmit more than 2 bits of UCI in a slot, and may multiplex SR bits by appending K + mK bits to the end of OACKHARQ-ACK information bits. The first K bits may represent a bitmap in ascending order of the values of a scheduling request resource ID where k-th bits may be set to ‘1 ’ indicating positive SR for the k-th corresponding SR resource ID. Every m bits following the K bits may be reserved to transmit a volume report for the respective k-th SR. For a positive SR, the corresponding m bits may transmit the codepoint representing the volume related to NC PDUs in the associated LCH. For a negative SR, the corresponding m bits may be set to a default value (e.g., all-zero, all one, etc.). The m bits may be set to any value by the WTRU.

[0255] At (11), if K > (Kthr), the WTRU may multiplex at most one positive SR from the overlapping SRs with the HARQ-ACK information bits and may use an index-based approach to indicate the ID of the positive SR as described in (12). The WTRU may prioritize an SR for multiplexing with HARQ-ACK based on the relative importance / priority of NC PDUs. The WTRU may determine a relative priority of NC PDUs (e.g., as defined herein) based on delay sensitivity, NC PDU set importance, etc.

[0256] At (12), the WTRU may transmit a PUCCH with OACKHARQ-ACK information bits in a resource using a PUCCH format configured to transmit more than 2 bits of UCI in a slot, and may multiplex SR by appending [log2( + 1)] + m bits representing a negative or positive SR, in ascending order of the values of scheduling request resource ID to the HARQ-ACK information bits. The WTRU may transmit the combined OUC| = OACK+ [log2( + 1)] + m UCI bits. If the WTRU has performed prioritization among more than one overlapping positive SRs or if there was only one SR triggered, the value of the log2( + 1) bits may indicate the positive SR. The WTRU may transmit the volume information for the corresponding positive SR in the following m bits. An all-zero value for the log2( / C + 1) bits may represent a negative SR value across all K SRs. If the reported positive SR is not configured to reportvolume information or for an all-zero value for the log2K + 1) bits, the corresponding m bits may be set to a default value (e.g., all-zero, all one, etc.). The m bits may be set to any value by the WTRU.

[0257] Although features and elements described above are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements.

[0258] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0259] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

CLAIMSWhat is Claimed:1 . A wireless transmit receive unit (WTRU), comprising: a processor configured to: receive configuration information, wherein the configuration information includes a metric associated with reporting network coding (NC) protocol data unit (PDU) related information; apply NC to service data units (SDUs) to generate NC PDUs; determine at least one NC specific condition is met; calculate NC data volume based on the determination that the at least one NC specific condition is met and based on the metric associated with reporting NC PDU related information; and transmit at least an indication of the calculated NC data volume.

2. The WTRU of claim 1 , wherein the transmission further includes an indication of the metric associated with reporting NC PDU related information.

3. The WTRU of claim 1, wherein the metric associated with reporting NC PDU related information is a volume of NC PDUs.

4. The WTRU of claim 3, wherein the volume of NC PDUs is a minimum number of NC PDUs required to recover source NC SDUs.

5. The WTRU of claim 1, wherein the metric associated with reporting NC PDU related information is a volume of the NC SDUs.

6. The WTRU of claim 5, wherein the volume of NC SDUs is a minimum number of NC SDUs used to generate the NC PDUs.

7. The WTRU of claim 1 , wherein the at least one NC specific condition is an increase of data volume above a threshold, a number of hybrid automatic repeat request (HARQ) retransmissions exceeding a threshold, a time from a start of a HARQ process up to a completion of the HARQ process exceeding a threshold, a packet delay budget exceeding a threshold, a number of radio link control (RLC) retransmissions exceeding a threshold, or a change in network coding.

8. The WTRU of claim 1, wherein the metric associated with reporting NC PDU related information includes at least one NC configuration parameter.

9. The WTRU of claim 8, wherein the at least one NC configuration parameter is a generation size, an NC PDU size, or a code rate.

10. The WTRU of claim 1 , wherein the processor is further configured to receive an indication of a scheduled resource, and wherein the calculated NC data volume is transmitted via the scheduled resource.

11. A method associated with a wireless transmit receive unit (WTRU), the method comprising: receiving configuration information, wherein the configuration information includes a metric associated with reporting network coding (NC) protocol data unit (PDU) related information; applying NC to service data units (SDUs) to generate NC PDUs; determining at least one NC specific condition is met; calculating NC data volume based on the determination that the at least one NC specific condition is met and based on the metric associated with reporting NC PDU related information; and transmitting at least an indication of the calculated NC data volume.

12. The method of claim 11 , wherein the transmission further includes an indication of the metric associated with reporting NC PDU related information.

13. The method of claim 11, wherein the metric associated with reporting NC PDU related information is a volume of NC PDUs.

14. The method of claim 13, wherein the volume of NC PDUs is a minimum number of NC PDUs required to recover source NC SDUs.

15. The method of claim 11, wherein the metric associated with reporting NC PDU related information is a volume of the NC SDUs.

16. The method of claim 15, wherein the volume of NC SDUs is a minimum number of NC SDUs used to generate the NC PDUs.

17. The method of claim 11 , wherein the at least one NC specific condition is an increase of data volume above a threshold, a number of hybrid automatic repeat request (HARQ) retransmissions exceeding a threshold, a time from a start of a HARQ process up to a completion of the HARQ process exceeding a threshold, a packet delay budget exceeding a threshold, a number of radio link control (RLC) retransmissions exceeding a threshold, or a change in network coding.

18. The method of claim 11, wherein the metric associated with reporting NC PDU related information includes at least one NC configuration parameter.

19. The method of claim 18, wherein the at least one NC configuration parameter is a generation size, an NC PDU size, or a code rate.

20. The method of claim 11, further comprising: receiving an indication of a scheduled resource, wherein the calculated NC data volume is transmitted via the scheduled resource.

Images