WO2025235470A1

WO2025235470A1 - Methods for supporting dynamic scheduling of uplink traffic

Info

Publication number: WO2025235470A1
Application number: PCT/US2025/027929
Authority: WO
Inventors: Tejaswinee LUTCHOOMUN; Ghyslain Pelletier; Senay NEGUSSE; Tuong Duc HOANG; Benoit Pelletier; Jaya Rao
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2024-05-06
Filing date: 2025-05-06
Publication date: 2025-11-13
Anticipated expiration: 2026-11-06

Abstract

Disclosed herein are systems, methods, and instrumentalities associated with the transmission of dependent or associated data units. A wireless transmit/receive unit (WTRU) as described herein may obtain a first data unit and a second data unit, and determine a dependency between the first data unit and the second data unit. The WTRU may receive a grant that provides resources for uplink transmissions and may select one or more logical channels to use the resources provided by the grant, wherein the selection may be made based at least on the dependency between the first data unit and the second data unit. The WTRU may perform a transmission associated with the one or more logical channels using at least a portion of the resources provided by the grant.

Description

METHODS FOR SUPPORTING DYNAMIC SCHEDULING OF UPLINK TRAFFIC

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63/642,943, filed May 6, 2024, the contents of which are incorporated by reference herein.

BACKGROUND

[0002] Services and applications such as extended reality (XR) services and applications may provide different types of immersive experiences to a user, such as, e.g., Virtual Reality (VR), Augmented Reality (AR) and/or Mixed Reality. Traffic associated with these services and applications may be organized into data units such as protocol data units (PDUs) associated with an application data unit (ADU), PDU sets, data bursts, etc. Dependency may exist between at least some of these data units and may affect how transmission/reception should be performed in a wireless communication system.

SUMMARY

[0003] Disclosed herein are systems, methods, and instrumentalities associated with the transmission of dependent or associated data units. A wireless transmit/receive unit (WTRU) as described herein may obtain a first data unit and a second data unit, and determine a dependency between the first data unit and the second data unit. The WTRU may receive a grant providing resources for uplink transmissions and may select one or more logical channels to use the resources provided by the grant, wherein the selection may be made based at least on the dependency between the first data unit and the second data unit. The WTRU may perform a transmission associated with the one or more logical channels using at least a portion of the resources provided by the grant.

[0004] In examples, the WTRU may determine that the second data unit depends on the first data unit and may select the one or more logical channels such that transmission of the first data unit may be prioritized over transmission of the second data unit. In examples, the first data unit may be of a first data type, the second data unit may be of a second data type, and the WTRU may receive configuration information from a network device indicating a mapping between the first data type and a first logical channel, and a mapping between the second data type and a second logical channel. [0005] In examples, the first data unit may be of a first data type, the second data unit may be of a second data type, and the WTRU may receive an indication from a network device that the resources provided by the grant may be used to transmit data of the first data type or the second data type.

[0006] In examples, the second data unit may depend on the first data unit, the one or more selected logical channels may include a first logical channel, and the WTRU may map the entire first data unit and at least a portion of the second data unit to the first logical channel. In examples, the first data unit may correspond to a first protocol data unit (PDU) or a first PDU set, and the second data unit may correspond to a second PDU or a second PDU set.

[0007] In examples, the second data unit may depend on the first data unit, and the WTRU may determine that the first data unit has not been successfully received by a receiving device within a time period, and select a logical channel associated with the second data unit to use the resources provided by the grant. In examples, the WTRU may receive an indication from the receiving device regarding reception of the first data unit and determine, based on the indication, that the first data unit has not been successfully received by the receiving device.

[0008] In examples, the WTRU may send a report to a receiving device indicating at least the dependency between the first data unit and the second data unit. In examples, the report may further indicate a buffer status associated with the first data unit or the second data unit.

[0009] A network device (e.g. , a base station) as described herein may transmit configuration information to a WTRU, wherein the configuration information may indicate a mapping between a first logical channel and a first data type, and a mapping between a second logical channel and a second data type, wherein the second data type may be dependent on the first data type. The network device may provide the WTRU with resources for performing uplink transmissions and may receive, from the WTRU, a first transmission associated with the first logical channel and performed using at least a first portion of the resources provided by the network device. The network device may transmit feedback regarding the first transmission to the WTRU and may receive, from the WTRU, a second transmission associated with the second logical channel subsequent to the transmission of the feedback. The second transmission may be performed using a second portion of the resources provided by the network device.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented. [0011] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that can be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0012] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0013] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that can be used within the communications system illustrated in FIG. 1 A according to an embodiment.

DETAILED DESCRIPTION

[0014] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings.

[0015] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can 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), singlecarrier 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.

[0016] As shown in FIG. 1A, the communications system 100 can include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the I nternet 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 can 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 can be referred to as a “station” and/or a “ST A”, can be configured to transmit and/or receive wireless signals and can include a user equipment (WTRU), 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), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d can be interchangeably referred to as a WTRU.

[0017] The communications systems 100 can include a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b can 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 can be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a base station, 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 can include any number of interconnected base stations and/or network elements.

[0018] The base station 114a can be part of the RAN 104/113, which can 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 can be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell can provide coverage for a wireless service to a specific geographical area that can be relatively fixed or that can change over time. The cell can further be divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a can employ multiple-input multiple output (MIMO) technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and/or receive signals in desired spatial directions.

[0019] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which can 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 can be established using any suitable radio access technology (RAT).

[0020] More specifically, as noted above, the communications system 100 can be a multiple access system and can 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 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).

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

[0023] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c can implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a base station).

[0024] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can 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.

[0025] The base station 114b in FIG. 1 A can be a wireless router, Home Node B, Home eNode B, or access point, for example, and can 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 can 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 can 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 can 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 can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106/115.

[0026] The RAN 104/113 can be in communication with the CN 106/115, which can 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 can 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 can 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 can 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 can be utilizing a NR radio technology, the CN 106/115 can also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0027] The CN 106/115 can 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 can include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 can 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 can include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104/113 or a different RAT.

[0028] One or more (e.g., all) of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 can include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1 A can be configured to communicate with the base station 114a, which can employ a cellularbased radio technology, and with the base station 114b, which can employ an IEEE 802 radio technology.

[0029] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 can 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 can include any sub-combination of the foregoing elements while remaining includeent with an embodiment.

[0030] The processor 118 can 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 can perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can 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 can be integrated together in an electronic package or chip.

[0031] The transmit/receive element 122 can 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 can be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 can 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 can be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 can be configured to transmit and/or receive any combination of wireless signals. [0032] Although the transmit/receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 can include any number of transmit/receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

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

[0034] The processor 118 of the WTRU 102 can be coupled to, and can 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 can also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 can 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 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 can 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).

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

[0036] The processor 118 can also be coupled to the GPS chipset 136, which can 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 can 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 can acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0037] The processor 118 can further be coupled to other peripherals 138, which can 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 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 can include one or more sensors, the sensors can 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. [0038] The WTRU 102 can 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) can be concurrent and/or simultaneous. The full duplex radio can 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 WTRU 102 can include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception).

[0039] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 can employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

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

[0041 ] Each of the eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can 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 can communicate with one another over an X2 interface.

[0042] The CN 106 shown in FIG. 1 C can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and/or operated by an entity other than the CN operator.

[0043] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and can serve as a control node. For example, the MME 162 can 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 can 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. [0044] The SGW 164 can be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions, such as anchoring 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.

[0045] The SGW 164 can be connected to the PGW 166, which can 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.

[0046] The CN 106 can facilitate communications with other networks. For example, the CN 106 can 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 can include, or can 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 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and/or wireless networks that are owned and/or operated by other service providers. [0047] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that, in certain representative embodiments, such a terminal can use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0048] In representative embodiments, the other network 112 can be a WLAN.

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

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

[0051] High Throughput (HT) STAs can 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.

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

[0053] Sub 1 GHz modes of operation are supported by 802.11af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 802.11 af 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.11 ah can support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0054] WLAN systems, which can support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which can be designated as the primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all ST As in the BSS. The bandwidth of the primary channel can 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 can 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 can 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 can be considered busy even though a majority of the frequency bands remains idle and can be available.

[0055] In the United States, the available frequency bands, which can 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.11 ah is 6 MHz to 26 MHz depending on the country code.

[0056] 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 can employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 can also be in communication with the CN 115.

[0057] The RAN 113 can include base stations 180a, 180b, 180c, though it will be appreciated that the RAN 113 can include any number of base stations while remaining includeent with an embodiment. The base stations 180a, 180b, 180c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the base stations 180a, 180b, 180c can implement MIMO technology. For example, base stations 180a, 108b can utilize beamforming to transmit signals to and/or receive signals from the base stations 180a, 180b, 180c. Thus, the base station 180a, for example, can use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. In an embodiment, the base stations 180a, 180b, 180c can implement carrier aggregation technology. For example, the base station 180a can transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the base stations 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from base station 180a and base station 180b (and/or base station 180c).

[0058] The WTRUs 102a, 102b, 102c can communicate with base stations 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing can vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can communicate with base stations 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).

[0059] The base stations 180a, 180b, 180c can 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 can communicate with base stations 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 can utilize one or more of base stations 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c can communicate with base stations 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c can communicate with/connect to base stations 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c can implement DC principles to communicate with one or more base stations 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as a mobility anchor for WTRUs 102a, 102b, 102c and base stations 180a, 180b, 180c can provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0060] Each of the base stations 180a, 180b, 180c can be associated with a particular cell (not shown) and can 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 base stations 180a, 180b, 180c can communicate with one another over an Xn interface.

[0061] The CN 115 shown in FIG. 1 D can 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 can be owned and/or operated by an entity other than the CN operator.

[0062] The AMF 182a, 182b can be connected to one or more of the base stations 180a, 180b, 180c in the RAN 113 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can 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 can 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 can be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and/or the like. The AMF 162 can 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.

[0063] The SMF 183a, 183b can be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b can also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type can be IP-based, non-IP based, Ethernet-based, and the like. [0064] The UPF 184a, 184b can be connected to one or more of the base stations 180a, 180b, 180c in the RAN 113 via an N3 interface, which can 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 can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0065] The CN 115 can facilitate communications with other networks. For example, the CN 115 can include, or can 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 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can 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 can 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.

[0066] In view of Figures 1A-1D, 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, base station 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, can be performed by one or more emulation devices (not shown). The emulation devices can be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices can be used to test other devices and/or to simulate network and/or WTRU functions.

[0067] The emulation devices can 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 can 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 can 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 can be directly coupled to another device for purposes of testing and/or can perform testing using over-the-air wireless communications.

[0068] The one or more emulation devices can 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 can 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 can be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which can include one or more antennas) can be used by the emulation devices to transmit and/or receive data.

[0069] When used herein, the term extended reality (XR) may encompass different types of immersive experiences including, for example, virtual reality (VR), augmented reality (AR), mixed reality (MR), and the realities interpolated among them. A virtual reality (VR) may be a rendered version of a delivered visual and/or audio scene. The rendering may be designed to mimic the visual (e.g., stereoscopic 3D) and/or audio sensory stimuli of the real world to an observer or user as they move within the limits defined by an application. An augmented reality (AR) may provide an observer or user with additional information, artificially generated objects/items, and/or content overlaid upon their current environment. A mixed reality (MR) may be an advanced form of AR, where some virtual elements may be inserted into a physical scene with the intent to provide an illusion that these elements may be part of the real scene. An XR service or application may include real-and-virtual combined environments and/or human-machine interactions generated by computer technology and/or wearables. Immersion in the context of XR applications/services may refer to the sense of being surrounded by a virtual environment as well as providing a feeling of being physically and spatially located in the virtual environment. Levels of virtuality may range from partial sensory inputs to fully immersive multi-sensory inputs leading to a virtual reality practically indiscernible from actual reality.

[0070] Traffic in a wireless communication network (e.g., related to XR services and applications) may consist of PDUs that may be associated with an application data unit (ADD), one or more PDU sets, or one or more data bursts. For example, the PDUs belonging to a PDU set may be associated with different segments or components of a video frame or a video slice. A data burst may include one or more PDU sets that may be transmitted or received over a time period or time window. A number of PDUs associated with a PDU set or a data burst (e.g., transmitted in the uplink (UL) or received in the downlink (DL)) may be dependent on the type of media frames (e.g., 3D video frames and/or audio frames).

[0071] A WTRU may transmit traffic (e.g., XR traffic) comprising one or more data units (e.g., PDUs or PDU sets) in the UL (e.g., pose information, gesture information, video data, etc.). The WTRU may receive traffic (e.g., XR traffic) in the DL (e.g., videos, audios, and/or haptics). Such traffic may be transmitted and/or received (e.g., periodically or aperiodically) in one or more data flows (e.g., QoS flows). The traffic (e.g., XR traffic) in the UL may arrive from an application layer at the WTRU, or from different devices, terminals, WTRUs (e.g., via a sidelink, a Wi-Fi connection, or a wired connection) at different time instances. Such traffic may be characterized by different attributes (e.g., variable payload sizes per PDU set, variable number of PDUs per PDU set, variable per-PDU/PDU set level importance and different levels of inter-dependencies between PDUs/PDUs sets, etc.). The traffic (e.g., PDUs or PDU sets) received by the WTRU may experience different delays, jitters, data rates and/or loss rates. To ensure QoS and/or high-quality user experience (QoE), data transmission, data reception and other associated functions (e.g. prioritization, multiplexing, scheduling, etc.) may be performed on a timely basis with awareness of the traffic characteristics (e.g., with awareness of PDU set attributes).

[0072] In examples (e.g., during coding operations at a video coder/decoder (codec)), different types of data packets may be transmitted or received, including, e.g., source, repair, and/or enhancement data units. For example, a PDU (e.g., a mandatory PDU) may be used by an application to decode a data unit. A source PDU may be a type of mandatory PDUs. A repair PDU may be generated from a source PDU and used to reconstruct the source PDU. A redundant PDU may be a type of repair PDUs. An enhancement PDU may be generated from a source PDU. An enhancement PDU may include a packet that may be used to achieve a certain (e.g., higher) quality of a related PDU (e.g., the quality may be set by an application layer). An enhancement PDU may or may not be mandatory (e.g., a receiver may be able to determine or predict a missing enhancement PDU from another PDU such as a source PDU). A video frame delivered without an enhancement PDU may still be considered a successful delivery.

[0073] In examples, the type of a packet may be absorbed into the importance of the packet, which may be conveyed to a WTRU from an application (e.g., source and/or mandatory packets may have an importance value of 0, 1, or 2 on a scale of 0-15, where a value of 14 or 15 may represent a least important packet).

[0074] A repair data unit may be generated from a source data unit. A source-to-repair dependency between a repair data unit and a source data unit may be characterized in different ways. For example, the source-to-repair dependency between a repair data unit and a source data unit may be one-to-one (e.g, 1 :1).

In such an example, every source packet may be associated with a repair packet and a direct dependency may exist between the source packet and the repair packet (e.g, the repair packet may be generated from the source packet).

[0075] As another example, the source-to-repair dependency between a repair data unit and a source data unit may be one-to-one, but not every source packet may generate (e.g, be associated with) a repair packet.

In this example, a source packet may generate a repair packet. The repair packet may be used to reconstruct the source packet from which the repair packet was generated. The repair packet may also be used to reconstruct another source packet from which the repair packet was not generated (e.g, the reconstructed source packet may be adjacent to the source packet from which the repair packet was generated).

[0076] As another example, the source-to-repair dependency between a repair data unit and a source data unit may be one-to-many (e.g, 1 :M). In this example, a source packet may generate multiple repair packets. One or more (e.g, multiple) repair packets may be used to reconstruct a source packet.

[0077] As another example, the source-to-repair dependency between a repair data unit and a source data unit may be many-to-one (e.g, M: 1). In this example, multiple source packets may be used to generate a repair packet. The repair packet may be used to reconstruct one or more of the source packets from which the repair packet was generated.

[0078] The source-to-repair dependency described herein may be visible to an application in a WTRU. The WTRU may receive an indication of such dependencies from the application. [0079] In examples, the dependencies between data units may be absorbed into the importance of the data units, which may be conveyed to a WTRU from an application (e.g., a data unit used to decode another data unit may have an importance value of 0, 1, or 2 on a scale of 0-15, where a value of 14 or 15 may represent a least important data unit).

[0080] An enhancement data unit may be generated from a source data unit and/or a repair data unit. The dependency between a source and/or a repair data unit and an enhancement data unit may be characterized in different ways. For example, the dependency between a source/repair data unit and an enhancement data unit may be one-to-one (e.g., 1 :1). In this example, a (e.g., every) source or repair packet may be used to generate an enhancement packet. A direct dependency may exist between the source/repair packet and the enhancement packet that was generated from the source/repair packet.

[0081] As another example, the dependency between a source/repair data unit and an enhancement data unit may be one-to-one, but not every source/repair packet may generate an enhancement packet. In this example, a source/repair packet may generate an enhancement packet. An enhancement packet may be used to reconstruct the source/repair packet from which the enhancement packet was generated. The enhancement packet may also be used to reconstruct another source or repair packet from which the enhancement packet was not generated (e.g., a source or repair packet adjacent to the source or repair packet used to generate the enhancement packet).

[0082] As another example, the dependency between a source/repair data unit and an enhancement data unit may be one-to-many (e.g., 1:M). In this example, a source or repair packet may generate multiple enhancement packets. One or more (e.g., multiple) enhancement packets may be used to reconstruct a source or repair packet.

[0083] As another example, the dependency between a source/repair data unit and an enhancement data unit may be many-to-one (e.g., M: 1). In this example, multiple source and/or repair packets may be used to generate an enhancement packet. The enhancement packet may be used to reconstruct one or more of the source and/or repair packet(s) used to generate the enhancement packet.

[0084] The source/repair packet-to-enhancement packet dependency described herein may be visible to an application in a WTRU. The WTRU may receive an indication of such dependencies from the application.

[0085] In examples, the dependencies between data units may be absorbed into the importance of the data units, which may be conveyed to a WTRU from an application (e.g., data units that are used to decode another data unit may have an importance value of 0, 1, or 2 on a scale of 0-15, where a value of 14 or 15 may represent a least important data unit).

[0086] Logical channel prioritization (LCP) may allow a network device to configure a WTRU with a set of rules for prioritizing data to be transmitted in the uplink. For example, in response to receiving a grant from the network device providing resources for uplink transmissions, the WTRU may determine which logical channels may be eligible for multiplexing using this grant (e.g., using resources provided by the grant). The WTRU may determine resources that may be allocated to each of the logical channels based on logical channel parameters (e.g., priority, Prioritized Bit Rate (PBR), and/or Bucket size duration (BSD)).

[0087] A WTRU supporting an XR experience may receive data units (e.g., PDUs, PDU sets, data bursts, and/or bitstreams) from higher layers or different devices, such as AR glasses and/or haptics gloves (e.g., via a sidelink (SL)). Such data units, which may have variable payload sizes, different periodicities, jitters, and/or different inter-dependencies, may be processed and/or transmitted by the WTRU in the UL.

[0088] A WTRU may be configured with multiple configured grants (CGs) for PUSCH transmission occasions in a period associated with a (e.g., single) CG PUSCH configuration. A WTRU may provide a dynamic indication of one or more un-used CG PUSCH occasions, e.g., via Uplink Control Information (UCI) transmitted by the WTRU. A WTRU may be configured with buffer status report (BSR) related parameters including one or more BSR tables, an indication to delay reporting of buffered data in the uplink, and/or an indication to discard a PDU set for the DL and/or UL. A WTRU may be configured with parameters related to power savings, such as, e.g., DRX support for an XR frame rate corresponding to non-integer periodicities (e.g., which may be indicated via a semi-static mechanism and/or RRC signaling). A WTRU may have XR awareness, for example, based on signaling from a core network (CN) that may include semi-static information transmission per QoS flow (e.g., PDU set QoS parameters), dynamic information per PDU set (e.g., PDU Set information and/or identification), and/or an end-of-data burst indication. A WTRU may provide XR traffic assistance information (e.g., periodicity, UL traffic arrival information, etc.) to a network or another WTRU.

[0089] Application traffic (e.g., for immersive applications) to and from a WTRU may include different types of data units (e.g., mandatory packets, repair packets, enhancement packets, etc.). Radio bearers such as Data Radio Bearers (DRBs) or Signaling Radio Bearers (SRBs) may be (e.g., semi-statically) configured with a number of QoS parameters such as, e.g., PDU Set Delay Budget (PSDB) and/or PDU Set Error Rate (PSER). Data may be associated to a radio bearer. For example, data for an immersive application that may be encoded using Application Layer Forward Error Correction (AL-FEC) may be mapped to a corresponding DRB. LCP may be performed to prioritize and/or multiplex data (e.g., in a transport block) based on the LCH configuration associated to the corresponding DRB (e.g., for all data units of the DRB and/or without differentiating between data units of the same radio bearer).

[0090] Multiple (e.g., two) data units or types may have the same QoS (e.g., PSDB), but may be useful to an application in different ways.

[0091] A WTRU may manage the multiplexing of data on a transport block (TB) scheduled for uplink transmission, for example, based on the relational properties of the data units available for transmission. The WTRU may do so, for example, by grouping related data units (e.g., AL-FEC encoded application data) together and/or utilizing the relative importance of different types of data units (e.g., data units used as source data units, repair data units, or enhancement data units by a decoder).

[0092] Scheduling (e.g., UL scheduling) may be managed based on the dependencies between data units, the grouping of data units, and/or the types of data units.

[0093] A WTRU may receive data bits or packets (e.g., source data bits/packets and/or repair data bits/packets) from an application. The WTRU may (e.g, at a service data adaptation protocol (SDAP) layer and/or a Packet Data Convergence Protocol (PDCP) layer) assign different subsets of data bits/packets to different data units (e.g, primary data units or a group thereof, secondary data units or a group thereof, etc.). The WTRU may send an indication regarding the data units (e.g, data unit types, indications of data volumes, etc.) to a network device (e.g, via RRC signaling such as a WTRU assistance message, a MAC CE, UCI, etc.). The WTRU may receive configuration information from the network device (e.g, in the form of one or more LCP rules/restrictions). The WTRU may transmit a primary group of data units to the network device. The WTRU may receive feedback from the network device regarding the successful or unsuccessful reception of the primary group of data units. The WTRU may perform LCP based on one or more LCP rules/restrictions and/or the feedback from the network device. For example, the WTRU may prioritize a secondary group of data units if (e.g, only if) the primary group of data units is not received by the network device within a time window (e.g, a preconfigured time window).

[0094] A data unit described herein may include one or more of the following: a data bit and/or a group of data bits, a PDU segment, a PDU, a PDU set, a set of PDUs (e.g, a PDU set) considered as one unit by an application (e.g, a set of PDUs associated with a video frame), a group of PDU sets, a data burst, and/or a group of data bursts.

[0095] A data unit and/or a component thereof may be associated with an identifier (ID). In an example, such an ID may be allocated by an application. As another example, the ID may be allocated by a WTRU based on an existing identifier (e.g., a PDCP sequence number). The ID may be allocated by the WTRU based on an update to an existing identifier (e.g., update to a PDCP sequence number) to incorporate a concept of data units. For example, sequence numbering (1 ,1), (1,2), (1,3) at the PDCP may refer to packets 1 , 2, 3 of data unit 1 . The ID may be allocated by the WTRU using an identifier that may allow a transmitter and/or a receiver to exchange feedback on a data unit. The WTRU may receive rules for allocating the identifiers to the data units and/or the constituents of the identifiers from the network (e.g., via an RRC (re)configuration message). The WTRU may receive rules or configuration information (e.g., during RRC (re)configuration) on translating the identifiers of the data units and/or their constituents (e.g., which may have been allocated to or received from a higher application layer) to identifiers that may be understandable by the network. The rules or configuration information may include rules for creating an identifier, one or more mapping tables for mapping an application-created identifier to an identifier that the network understands, and/or rules on updating an identifier. In examples, feedback from the network on the successful and/or unsuccessful reception of data unit(s) and/or components thereof may include the identifiers of the data units and/or the components thereof. [0096] A WTRU (e.g., an application on the WTRU) may group data into one or more data units (e.g., PDUs or PDU sets) that may be visible to the WTRU. For example, a data unit may be generated and/or grouped as a unit of data by an application on a WTRU (e.g., the data unit may correspond to a video frame generated the application), and may be sent to the WTRU (e.g., a lower layer component of the WTRU). As another example, data may be generated by an application on a WTRU, and the WTRU (e.g., an SDAP and/or a PDCP entity of the WTRU) may group the data into a data unit. As another example, a WTRU (e.g., an SDAP and/or PDCP entity in the WTRU) may see a flow of data bits coming in from one or more QoS flows and may combine the repair data bits in the data flow into a repair PDU and/or combine the source data bits in the data flow into a source PDU (e.g., the PDU may constitute a data unit). As another example, a WTRU (e.g., an SDAP and/or PDCP entity in the WTRU) may combine some source PDUs and their corresponding repair PDUs into a PDU set (e.g, which may constitute a data unit). As another example, source PDUs assembled or grouped by a WTRU (e.g, by an SDAP and/or PDCP entity in the WTRU) may constitute a primary data unit, while repair PDUs assembled or grouped by the WTRU (e.g, by an SDAP and/or PDCP entity in the WTRU) may constitute a secondary data unit. The WTRU (e.g, the SDAP and/or PDCP entity in the WTRU) may add markers to the data units, which may be read by a receiver (e.g, a base station) and/or a lower layer component of the WTRU (e.g, an MAC entity in the WTRU).

[0097] When used herein, a group of data units may refer to a group of data units of a certain type. For example, a first group of data units may refer to a group of mandatory packets, while a second group of data units may refer to a group of repair packets. The term “data units” may be used interchangeably herein with the term “a group of data units.”

[0098] When used herein, a type of data units may refer to any characteristic of the data units, e.g., attributed by an application and/or a WTRU. A type of data units may refer to, for example, repair data units, source data unit, or enhancement data units. A type of data units may also refer to, for example, primary data units, secondary data units, or tertiary data units. A type of data units may also refer to, for example, mandatory data units, or non-mandatory data units. A type of data units may also refer to data units that are used for QoS or data units used for QoE (e.g., repair data units or enhancement data units). A type of data units may refer to data units that are not used for either QoS or QoE enhancements. A type of data units may refer to data units that are used (e.g., only) for QoS enhancements or (e.g., only) for QoE enhancements (e.g., an enhancement data unit). A type of data units may include low delay budget data units (e.g., with a PSDB and/or PSDD below a certain value for a PDU set), high delay budget data units (e.g., with a PSDB and/or PSDD below a certain value for a PDU set), low error rate data units (e.g, with a PSER set below a certain value for a PDU set), high error data units (e.g, with a PSER above a certain value for a PDU set), data units of a certain importance value or above the importance value, and/or data units of a certain importance value or below the importance value.

[0099] Dependencies may exist between data units (e.g, dependencies between a source packet and a repair packet generated from the source packet). At a lower layer, such as in a certain protocol stack layer (e.g, SDAP, PDCP, RLC, MAC, and/or PHY), the dependencies may be translated and/or be made visible, for example, via an in-band marking (e.g, in a packet header such as an SDAP sub-header, a PDCP sub-header, etc.).

[0100] The dependencies between data units may be indicated and/or made visible via a separate control data unit (e.g, a separate PDCP control PDU may be used to provide information on the dependencies between two data PDCP PDUs via the sequence numbering of those PDUs, etc.).

[0101] The dependencies between data units may be indicated and/or made visible implicitly, for example, via a mapping (e.g, dependent data units may be mapped to a same QoS flow/DRB/LCH/etc, in which case the QoS flow/DRB/LCH may be marked and/or designated for the dependent data units).

[0102] The dependencies between data units may be translated and/or made visible via an explicit relationship between the data units. For example, a primary data unit and a secondary data unit may be created by a WTRU (e.g, by an SDAP/PDCP entity of the WTRU) by assembling data or data types into the primary/second data units. The dependency of the primary and second data units may be detectable and/or visible via one or more of the methods described herein (e.g, via in-band marking, a control PDU, a mapping, etc.).

[0103] Data units may go through one or more of the following layers or sub-layers of a protocol stack. At an SDAP sublayer, data units mapped to the same QoS flow or to different QoS flows may have dependencies. In the latter case, the dependent QoS flows may be marked with a dependent marker. At a PDCP sublayer, data units mapped to a same DRB or to different PDCP entities/DRBs may have dependencies. A data unit ID may be indicated in a PDCP header. At an RLC sublayer, data units mapped to the same RLC entity or to different RLC entities may have dependencies. At an MAC sublayer, data units mapped to the same LCH or to one or more designated LCHs may have dependencies. A data unit ID may be indicated in a MAC header. The MAC sublayer in the WTRU may receive information on the dependencies, e.g., from one or more of the above sublayers in the protocol stack such as an RLC, PDCP, and/or SDAP sublayer).

[0104] At a PHY sublayer, dependencies may be known/tracked via a HARQ process ID mapped to a transport block (TB) and/or a code block group (CBG). For example, a TB may include PDUs of a data unit. As another example, a CBG may include PDUs of a data unit. The dependencies may be known/tracked via grants in a multi-PUSCH CG. For example, one or more (e.g., all) grants in a CG occasion may be associated with PDUs of a data unit. The dependencies may be known/tracked via different CG configurations for data units or a type/group of data units. For example, restrictions may be imposed to allow (e.g., only allow) source data units to be mapped to the CG grants of a CG configuration. As another example, a CG configuration may be configured for source data units and another CG configuration may be configured for repair data units. The dependencies may be known/tracked via a set of resources (e.g., grants, frequency resources, etc.) reserved for a data unit or a type/group of data units thereof. The dependencies may be known/tracked via an ID for a data unit (e.g., a PDU set ID). For example, the dependencies may be known/tracked via a mapping between a TB and one or more data units of the same type. The dependencies may be known/tracked via a mapping between a TB and one or more data units that have inter-dependencies. The WTRU (e.g., a PHY sublayer in the WTRU) may receive a data unit ID from a MAC sublayer in the WTRU. The dependencies may be known/tracked via an indicator (e.g., “0” may indicate a repair PDU and “1” may indicate a source PDU), which may be included in a header of the data unit.

[0105] Dependency information at a (e.g., any) sublayer of a protocol stack may be received from a (e.g, any) sublayer above that sublayer. For example, the PHY sublayer may receive dependency information from the MAC sublayer, the MAC sublayer may receive dependency information from the RLC sublayer, the PDCP sublayer and/or the SDAP sublayer, and the PDCP sublayer may receive dependency information from the SDAP sublayer and/or an upper (e.g., application) layer.

[0106] A WTRU may identify dependency and/or an association between data units at a PHY layer. For example, the PHY layer in the WTRU may use association information and/or configuration information to maintain the association between dependent data units when mapping and/or transmitting TBs within scheduled UL resources. For example, when mapping TBs to the scheduled UL resources, the PHY layer in the WTRU may ensure that a receiving entity may identify the dependency and/or association between data units contained across different transport blocks (TBs). The PHY layer may receive explicit and/or implicit information (e.g., an indication) from a higher layer (e.g., the MAC layer) regarding TBs that may contain associated data units.

[0107] The PHY layer in a WTRU may receive dependency and/or association information from a higher layer in different ways. For example, HARQ process IDs may be assigned to TBs containing dependent/associated data units (e.g., PDUs or PDU sets), and the PHY layer in the WTRU may be configured to identify TBs assigned with these HARQ process ID(s) as an indication that the TBs contain associated data units such as PDUs or PDU sets. The HARQ process I D(s) may be selected from one or more sets of HARQ process IDs reserved for TBs containing associated data units such as associated PDUs or PDU sets.

[0108] A resource grant (e.g., a configured grant or dynamic grant providing resources for uplink transmissions) may be assigned to TBs containing dependent or associated data units (e.g., PDUs or PDU sets). In response to receiving an indication (e.g., via RRC signaling, DCI, etc.) of such a resource grant for transmissions (e.g., the grant may be considered a reserved/special grant), the PHY layer in a WTRU may be configured to determine that TBs mapped to the grant (e.g., reserved/special resource grant) may be TBs that contain dependent or associated data units. A resource mapping for TBs containing dependent or associated data units (e.g., PDUs or PDU sets) may be implemented in different ways. For example, in the frequency domain, the PHY layer at the WTRU may be configured to map TBs containing dependent data units on a reserved (e.g., special or designated) bandwidth part (BWP). In the time domain, the PHY layer at the WTRU may be configured to map TBs containing dependent data units on one or more (e.g., reserved) transmission occasions within a multi-PUSCH CG period. In the spatial domain, the PHY layer at the WTRU may be configured to map TBs containing dependent data units on one or more reserved antenna ports.

[0109] A channel coding scheme may be assigned to TBs containing dependent or associated data units (e.g., PDUs or PDU sets). For example, the PHY layer at a WTRU may receive an indication (e.g., from the MAC layer) to employ a certain channel coding scheme and/or error detection scheme (e.g., cyclic redundancy check) that may be (e.g., exclusively) reserved for use on TBs containing dependent or associated data units.

[0110] The PHY layer at a WTRU may be provided with an explicit indication (e.g., via a MAC header) on TBs that may contain dependent or associated data units.

[0111] A WTRU (e.g., an SDAP/PDCP component at the WTRU) may assign different subsets of data units (e.g., source data units and/or repair data units) to separate PDU sets, and may create a relationship (e.g., an explicit relationship) between the data units (e.g., between a primary data unit such as a source data unit, and a secondary data unit such as a repair data unit). The relationship may be used as a restriction in LCP for the secondary data unit (e.g., the WTRU may only transmit the secondary data unit if the primary data unit has been transmitted or has not been transmitted). The WTRU may treat certain data units (e.g., enhancement data units) as tertiary data units, the transmission of which may not affect the QoS of a data flow or a service. These enhancement data units may be transmitted on a best effort basis (e.g., if resources are available), but the QoS of their associated data units (e.g., source data units that may be enhanced by the enhancement data units) may not be impacted if one or more (e.g., all) of the associated enhancement data units are not transmitted. For example, a source data unit may be deemed as (e.g., successfully) received (e.g., at a receiver) if one or more source data bits or data packets of the source data unit are received at the receiver. In examples, a data unit may include one or more source data bits/packets and one or more enhancement data bits/packets. The source data unit(s) may be considered as (e.g., successfully) received at a receiver if the source data bits/packets of the source data unit are successfully received at the receiver, irrespective of whether the enhancement data bits/packets are transmitted and/or received.

[0112] A primary data unit may be interchangeably referred to herein as a first data unit. A secondary data unit may be interchangeably referred to herein as a second data unit.

[0113] Different modeling approaches may be used depending on a mapping of data units to one or more DRBs, if applicable. A data unit may include one or more data packets (e.g, of the same type or different types). For example, a data unit may include repair data packets, source data packets, and/or a combination of source and repair data packets. As another example, a data unit may include a combination of source, repair, and enhancement data packets.

[0114] In examples, a single data unit may be mapped to a single DRB. The DRB may be mapped to an LCH, in which case data (e.g, all of the data) from the DRB may be mapped to the LCH. The DRB may also be mapped to more than one LCH. In this case, if a data unit comprising different data units or different types of data units (e.g, source data bits/packets, repair data bits/packets, and/or enhancement data bits/packets), a DRB-to-LCH split may be performed based on the types of data bits/packets comprised in the data unit (e.g., a first LCH for source data bits/packets, a second LCH for repair data bits/packets, a third LCH for enhancement data bits/packets, etc.).

[0115] In examples, multiple related data units may be mapped to a single DRB. The multiple data units may be mapped to a single LCH or to multiple LCHs. For example, a first LCH may be used for a primary data unit (or a group of primary data units) and a second LCH may be used for a secondary data unit (or a group of secondary data units). As another example, a first LCH may be used for a data unit comprising one or more source data bits/packets, and a second LCH may be used for a data unit comprising one or more repair data bits/packets.

[0116] In examples, multiple data units may be mapped to different DRBs.

[0117] In examples, data units may not be mapped to any DRB, in which case, the priorities of transmission may be (e.g., dynamically) determined for a (e.g., each) grant on a per data unit basis. A WTRU may determine the priority of transmission of a secondary data unit (or a group of secondary data units) based on whether a primary data unit (or a group thereof) has been transmitted. The WTRU may determine the transmission priority of a secondary data unit (or a group thereof) based on whether a certain amount of primary data, such as a certain percentage (e.g., 90% or higher, 80% or lower, etc.) of primary data units, has been transmitted. The WTRU may determine the priority of transmission of a secondary data unit (or a group thereof) based on whether a primary data unit (or a group thereof) has been successfully received at a receiver. A successful reception may be confirmed via feedback from a network device to the WTRU (e.g., HARQ feedback at the PHY sublayer, a MAC CE at the MAC sublayer, a RLC status report at the RLC sublayer, a PDCP status report at the PDCP sublayer, etc.). The feedback may be on a per-PDU basis, a per- TB basis, or a per-data unit basis. For example, the WTRU may determine the transmission priority of a secondary data unit (or a group thereof) based on the amount of primary data (e.g., a primary data unit or a group thereof) that has been successfully received at a receiver. The determination may be made, for example, based on a number or percentage of primary PDUs transmitted as a function of a total number of primary PDUs. The WTRU may confirm the successful reception based on feedback received from a network device (e.g., HARQ feedback at the PHY sublayer, a MAC CE at the MAC sublayer, a RLC status report at the RLC sublayer, a PDCP status report at the PDCP sublayer, etc.). As another example, the WTRU may determine the transmission priority of a secondary data unit, or a group thereof based on whether a primary data unit or a group thereof has not been successfully received at a receiver. [0118] A WTRU may receive configuration information from a network device regarding LCH selection, dynamic LCH switching, modification of existing LCP parameters (e.g, priority, PBR, or bucket size (Bj)), switching to a different set of LCP parameters (e.g., a different priority, PBR, or Bj), switching to a different LCP configuration, and/or application of LCP restrictions.

[0119] A WTRU may receive configuration information regarding one or more logical channels from a network device. The configuration information may include parameters such as a set of allowed subcarrier spacings a logical channel is allowed to use (e.g., via an allowedSCS-List information element (IE)), a maximum PUSCH duration in which a logical channel may be scheduled (e.g., a maxPUSCH-Duration IE), and/or a set of serving cells (e.g., via an allowedServingCells IE), which may include a set of uplink component carriers on which a logical channel may be transmitted.

[0120] The configuration information may include parameters such as the data and/or data type that may be mapped to a logical channel (e.g., source data, repair data, and/or enhancement data), and/or dependent data and/or data types. For example, the configuration information may indicate that (e.g., only) a primary data unit may be mapped to a logical channel, or that (e.g., only) a secondary data unit may be mapped to a logical channel. As another example, the configuration information may indicate that (e.g., only) a primary data unit and a dependent secondary data unit may be mapped to a logical channel. As another example, the configuration information may indicate that (e.g., only) a primary data unit and a certain amount of a dependent secondary data unit (e.g., up to 50% of the total available volume of the secondary data unit in the WTRU’s buffer) may be mapped to a logical channel. As another example, the configuration information may indicate that (e.g., only) a mandatory data unit or a type thereof may be mapped to a logical channel (e.g., only source data units may be mapped to the logical channel). As another example, the configuration information may indicate that (e.g., only) a non-mandatory data unit or a type thereof may be mapped to a logical channel (e.g., only repair and/or enhancement data units may be mapped to the logical channel). As another example, the configuration information may indicate that (e.g., only) a certain amount of a data unit of type thereof may be mapped to a logical channel (e.g., the configuration information may set an upper limit on the volume of nonmandatory data (e.g, repair and/or enhancement data) that may be mapped to a logical channel).

[0121] A WTRU may determine which logical channel(s) may transmit data using an allocated grant. For example, the WTRU may receive an indication from the network regarding resource allocation for a logical channel. The indication may be used by the WTRU to ensure that a logical channel may be allowed to use the resource allocation. [0122] A WTRU may receive information (e.g. , configuration parameters) regarding data unit dependencies. The WTRU may use the information to prioritize data (e.g., uplink data) at the WTRU. For example, a grant (e.g, resources allocated by a network for uplink transmissions) may be restricted to be used for certain data units or certain type(s) of data units such as for one or more primary data units (e.g, mandatory data units like source data units), or for one or more secondary data units (e.g, repair data units). As another example, a grant may be restricted to be used for one or more non-mandatory data units (e.g, repair and/or enhancement data units). As another example, a grant may be restricted to be used for non-mandatory data units (e.g, source data units) up to a percentage (e.g, 50%) of the total grant size (e.g, such that at least 50% of the resources provided by the grant may be used for mandatory data units). As another example, a grant may be restricted to be used for additional data units (e.g, tertiary data unit such as enhancement data units). As yet another example, a grant may be restricted to be used for additional data units (e.g, tertiary data units such as enhancement data units) up to a percentage (e.g, 75%) of the total grant size (e.g, such that at least 25% of the resources provided by the grant may be used for other data units).

[0123] A WTRU may consider information on data unit dependencies during resource allocation (e.g, when performing an LCP procedure). For example, if the WTRU has been allocated a sufficiently large grant, the WTRU may fit data (e.g, all of the data) from different logical channels onto a MAC PDU. If the WTRU has been allocated a grant (e.g, transmission resources) that is not sufficiently large (e.g, to fit all data in the WTRU’s buffer), the WTRU may consider information on the dependencies between data units during an LCP procedure (e.g, in addition to other LCH parameters such as a priority, a PBR, a Bj, etc.). For example, if two logical channels have the same priority, the WTRU may prioritize the logical channel that is mapped to one or more primary data units. If two logical channels have the same priority, and one of the logical channels is mapped to one or more primary data units while the other channel is mapped to one or more secondary data units, the WTRU may prioritize the logical channel mapped to the secondary data units over the logical channel mapped to the primary data units for a time period (e.g, only) if the primary data units are not successfully received at a receiver (e.g, within a time window).

[0124] As another example, two logical channels may be configured with different priorities (e.g, one with a first priority and the other one with a second priority, wherein the first priority may be higher than the second priority). One of the logical channels may be mapped to one or more primary data units, while the other one of the logical channels may be mapped to one or more secondary data units. In this scenario, the WTRU may prioritize the logical channel mapped to the secondary data units (e.g, even though the logical channel has a lower priority) over the logical channel mapped to the primary data units (e.g, even though the logical channel has a higher priority) for a time period if (e.g., only if) the primary data units are not successfully received at a receiver (e.g., within a time window).

[0125] As yet another example, two logical channels may be configured with different priorities (e.g., one with a first priority and the other one with a second priority, wherein the first priority may be higher than the second priority). One of the logical channels may have data corresponding to one or more primary data units, while the other one of the logical channels may have data corresponding to one or more secondary data units. In this scenario, the WTRU may prioritize the logical channel with data corresponding to the secondary data units (e.g., even though the logical channel has a lower priority) over the logical channel with data corresponding to the primary data units (even though the logical channel has a higher priority) for a configured time period under certain conditions. The conditions may be based on a grant (e.g., provision of uplink transmission resources) being insufficient to fit both the primary and secondary data, or that the primary data units are not successfully received at a receiver within a time window. The conditions may be based on dependencies between the primary data units and the secondary data units. The WTRU may determine or be indicated about such dependencies (e.g., by upper/application layers). The conditions may be based on certain functionalities being activated by a network. The conditions may be based on the primary data units being partially received at a receiver within a time window (e.g., 90% or less of primary data units are successfully received at the receiver within the time window). The conditions may be based on the primary data units being successfully received at a receiver within a time window. The conditions may be based on the WTRU not transmitting an SR/BSR/DSR to the network to inform the network about data in the WTRU’s buffer, or not requesting additional resources from the network (e.g., if an SR/BSR/DSR was recently transmitted and a timer prohibiting the retransmission of the SR/BSR/DSR or a new SR/BSR/DSR is still running).

[0126] A WTRU may select one or more logical channels during an LCP procedure based on the dependency of data carried by the logical channels.

[0127] A WTRU may be configured with one or more designated logical channels to expediate certain data. For example, if the remaining transmission time of a data unit computed via a timer (e.g., a discardTimer) is below a predetermined value, the WTRU may select these designated logical channels for the data unit and/or (e.g., dynamically) switch the data unit from a legacy logical channel to one of these designated logical channels (e.g., if the remaining transmission time value for the data unit is critical).

[0128] A WTRU may be configured with one or more designated logical channels to compensate for/accommodate the dependency of data in the WTRU’s buffer. For example, a primary data unit and a secondary data unit that depend on each other may be mapped to the same logical channel, which may be a logical channel configured and/or designated to handle such dependencies.

[0129] A WTRU may be configured with one or more designated logical channels for data in the WTRU’s buffer that may not impact the QoS of a data flow or service (e.g., such data may include an enhancement data unit).

[0130] A WTRU may be configured with more than one LCP configuration. For example, the WTRU may be configured with a default LCP configuration and an additional LCP configuration that may consider data unit dependencies as part of the prioritization rules described herein. In examples, the default LCP configuration may (e.g., always) be activated, unless/until the WTRU receives an indication from the network to deactivate the default LCP configuration and activate the other LCP configuration. The WTRU may receive an indication of a time period during which the other LCP configuration may remain activated. In examples, the default LCP configuration may be activated until/unless rules/conditions for activating the other LCP configuration are met. The rules/conditions may include one or more of the rules/conditions described herein.

[0131] In examples, a WTRU may be configured to modify existing LCP parameters (e.g., priority, PBR, BSD, Bj, etc.) to a different set of LCP parameters (e.g., priority, PBR, BSD, Bj, etc.) if certain rules/conditions as described herein are met. For example, instead of (e.g., temporarily) prioritizing a lower priority logical channel over a higher priority logical channel to meet the dependency criteria described herein, the WTRU may modify one or more LCP parameters to increase the priority of the lower priority logical channel and/or to decrease the priority of the higher priority logical channel (e.g., for the duration of a time period).

[0132] In examples, a DRB and/or an LCH may not be configured, and a WTRU may be configured to determine the transmission priority of a data unit as a function of the properties of the data unit and/or a dependent data unit.

[0133] In examples, a WTRU may be configured with rules/conditions for considering data unit dependency via RRC signaling (e.g., during RRC (re)configuration), and the WTRU may receive an activation indication from a network device before the rules/conditions are implemented. For example, the network device may activate the functionality of (e.g., temporarily) prioritizing a lower priority logical channel over a higher priority logical channel. For example, the network device may send an activation request/indication (e.g., via a MAC CE or DCI). The activation request/indication may indicate a time period for the activation of the rules/conditions, and the WTRU may deactivate the rules/conditions and revert back to other rules (e.g., other LCP rules) following the expiry of the time period. As another example, the WTRU may receive from the network device a deactivation request or indication. [0134] A WTRU may be configured with a time period during which the WTRU may consider data dependencies during the allocation of resources in an LCP procedure (e.g., in addition to other LCH parameters such as priority, PBR, or Bj). The WTRU may be configured to (e.g., only) consider the time period if specific conditions are met, such as, e.g., if the priorities of multiple logical channels are the same, if multiple logical channels have data that may be multiplexed into a MAC PDU, if the amount of resources available is not sufficient for the WTRU to multiplex data associated with multiple logical channels, if there are dependencies between the data of multiple logical channels, and/or if the WTRU has received feedback (e.g., form a network device) on the transmission status of one or more data units from one or more logical channels. [0135] The WTRU may receive from the network (e.g., via RRC (re)configuration and/or together with other LCP parameters) one or more values for the time period, along with rules/conditions for applying the values. For example, the WTRU may receive from the network a time period value for a (e.g., each) logical channel per MAC entity (e.g., similar to other parameters such as priority, prioritised BitRate, bucketSizeDuration, etc.). During such a time period, a priority of a logical channel may not be the only (e.g, most important) parameter to consider for resource allocation. For example, if a logical channel has data with dependencies, the logical channel may be prioritized over a logical channel that may not have data with dependencies for the duration of the time period, even if the logical channel has a lower priority than the other logical channel. As another example, if a logical channel has data of a certain type (e.g, primary data units), the logical channel may be prioritized over a logical channel that may not have the type of data for the duration of the time period, even if the logical channel has a lower priority than the other logical channel. As another example, if a logical channel has data of a certain type (e.g, secondary data units), the logical channel may be prioritized over a logical channel that has dependent data for the duration of the time period, even if the logical channel has a lower priority than the other logical channel, if feedback regarding the logical channel has been received from the network (e.g, primary data was not successfully received by the network or only a certain amount of primary data was successfully received at the network, etc.).

[0136] A WTRU may receive from the network a time period value that may be applied for a logical channel during resource allocation in an LCP procedure. For that time period, the WTRU may consider data dependencies (e.g, over priorities) when allocating resources to logical channels that have data to transmit, provided some conditions/rules are met. At the expiry of the time period, the WTRU may flush data in the WTRU’s buffer (e.g, all data associated with the logical channels) and revert to another LCP procedure (e.g, where resources may be allocated to logical channels in decreasing order of priorities up to a PBR of each logical channel). The WTRU may also flush the data buffer in a mobility situation (e.g, handover). [0137] A WTRU may be configured with a time window during which the WTRU may monitor for feedback from a network device regarding one or more data units transmitted to the network device. The WTRU may start the time window when the data units are transmitted in the uplink. For example, the WTRU may start the time window for a primary data unit when the first packet of the primary data unit has been multiplexed into a MAC PDU. The WTRU may start the time window for a primary data unit when the last packet of the primary data unit has been multiplexed into a MAC PDU. The WTRU may start the time window for a primary data unit when all of the packets of the primary data unit have been multiplexed into a MAC PDU. The WTRU may start the time window for a primary data unit when a certain percentage/number of packets of the primary data unit have been multiplexed into a MAC PDU (e.g. , 70% or greater of all packets in the primary data unit has been multiplexed into a MAC PDU). The WTRU may start the time window for a primary data unit when the most important packets of the primary data unit have been multiplexed into a MAC PDU (e.g., if importance is assigned on a per-PDU basis). The WTRU may start the time window for a primary data unit when a certain percentage/number of the most important packets of the primary data unit have been multiplexed into a MAC PDU (e.g., 70% or greater of packets of high importance in the primary data unit have been multiplexed into a MAC PDU). The WTRU may start the time window for a primary data unit when a certain percentage/number of the packets of the primary data unit with an importance higher than a preconfigured threshold value have been multiplexed into a MAC PDU (e.g., 70% or greater of the packets of the primary data unit that have an importance greater than a preconfigured threshold value has been multiplexed into a MAC PDU). For example, the WTRU may start the time window for a primary data unit when 70% or greater of the PDUs of a PDU set with a PDU Set Importance (PSI) level of 2 or below has been multiplexed into a MAC PDU, assuming PSI levels 0,1 and 2 are the highest importance levels.

[0138] The WTRU may start the time window for a primary data unit when the first packet of the primary data unit has been transmitted. The WTRU may start the time window for a primary data unit when the last packet of the primary data unit has been transmitted. The WTRU may start the time window for a primary data unit when all and/or a certain percentage/amount of the primary data unit (e.g., 50% of all packets of the primary data unit) have been transmitted. The WTRU may start the time window for a primary data unit when a certain type/subtype of the primary data unit (e.g., all packets of the primary data unit having an importance higher than a preconfigured threshold value) have been transmitted. The WTRU may start the time window for a primary data unit when a certain percentage/amount (e.g., 50%) of a type of packets of the primary data unit have been transmitted. [0139] If the time window expires and the WTRU has not received feedback from the network device, or the WTRU has received certain feedback from the network device, the WTRU may consider data dependencies during the allocation of resources in an LCP procedure. The WTRU may start the time window at the transmission of a primary data unit.

[0140] If the time window expires and the WTRU receives feedback from the network device that a primary data unit has not been received, the WTRU may prioritize a logical channel carrying a secondary data unit for a time period configured by the network for a logical channel, for example, irrespective of the priority of that logical channel. The primary data unit (e.g, comprising one or more source packets) may be generated from the secondary data unit (e.g., comprising one or more repair packets).

[0141] If the time window expires and the WTRU receives feedback from the network device that a primary data unit has been partially received, the WTRU may prioritize a logical channel carrying a secondary data unit for a time period configured by the network for that logical channel, for example, irrespective of the priority of that logical channel. For example, a certain number/percentage of a data unit may be requested by an application and the request may result in the network providing feedback to the WTRU when the number/percentage of the data unit is received by the network or not received by the network. As an example, an application may require reception of 80% of primary data unit, and this may result in a base station (e.g., a gNB) transmitting a status report or feedback to the WTRU when 80% of the primary data units are received by the base station. This requirement may also lead to the base station transmitting a status report or feedback to the WTRU when 80% of the primary data units are not received by the base station.

[0142] At the expiry of the time window described herein, a WTRU may flush data in the WTRU’s buffer (e.g., all data associated with logical channels) and revert to a legacy LCP procedure (e.g., where resources may be allocated to logical channels in decreasing order of priorities up to the PBR of each logical channel). The WTRU may also flush the data buffer in a mobility situation (e.g., handover from one network device to another).

[0143] Feedback from a network device on the reception status of one or more packets may occur at one or more protocol stack sublayers. The feedback may be for the successful reception or unsuccessful reception of a data unit. The feedback (e.g, a status report) may be provided on a per-PDU basis and/or on a per-data unit basis.

[0144] The feedback (e.g, a status report) may include a status report from a receiving SDAP entity (e.g, in a base station for the UL) to a transmitting SDAP entity (e.g, in a WTRU for the UL). The feedback may include a status report from a receiving PDCP entity (e.g, in a base station for the UL) to a transmitting PDCP entity (e.g . , in a WTRU for the UL) that may inform the transmitter about whether a PDCP PDU was received or not by the receiving PDCP entity (e.g., based on the sequence number of the PDCP PDUs). The feedback may include a PDCP status report (e.g., on a per-data unit basis). The feedback may include an RLC status report (e.g., on a per-byte, per-number of bytes, per-PDU, or per-number of PDUs basis). The feedback may include a status report on a per-data unit basis. The feedback may include MAC CE reporting on a per-data unit basis. The feedback may include HARQ feedback.

[0145] Feedback from a network device at a sublayer may be related to application information such as an FEC ratio. The FEC ratio may refer to the amount/percentage of a data unit that need to be received successfully by an application for the application to reconstruct the data unit. For example, an FEC ratio of 9/10 may signify that 90 out of 100 PDUs of a PDU set may be successfully received at the application for the application to reconstruct the PDU set. The ratio may be specified for a (e.g., each) type or subtype of data of the data unit. For example, the ratio may specify that 80% of repair PDUs of a data unit may be successfully received at the application for the application to reconstruct the data unit.

[0146] The network device may receive the application related information from an application (e.g., in an application server). The information may be related to uplink traffic and/or downlink traffic. For example, a network may receive application related information (e.g., on uplink traffic) from a WTRU.

[0147] The network may provide feedback to the WTRU on successful/unsuccessful reception of data units on a per data unit basis. For example, if a data unit includes a PDU set of 10 PDUs, wherein 8 of the 10 PDUs of the PDU set may need to be successfully received by a receiver for an application to successfully decode the PDU set, the network may send a group ACK/NACK for the 8 PDUs of the PDU set in a status report. The 8 PDUs may be a specific set of 8 PDUs of the PDU set or any 8 PDUs of the PDU set.

[0148] In examples, a PHY layer component or entity may determine the reception status of dependent data units (e.g., PDUs) based on feedback received from a network device. A network device may provide a WTRU with HARQ feedback (e.g., in DCI) indicating the status (e.g., ACK or NACK) of one or more UL transmissions. The network device may use the HARQ feedback to provide information regarding the success or failure of reception of one or more TBs transmitted by the WTRU in the UL. In the case of a failed reception, the network device may, in addition to providing information regarding the failure, provide information (e.g., in DCI) regarding the resources it is granting the WTRU for retransmitting the TBs that the network device failed to receive or correctly receive. The PHY layer component at the WTRU may perform retransmission of the one or more TBs according to one or more indicated transmission parameters (e.g., a MCS, RV, repetition, frequency/time domain resources, etc.) without awareness of data unit dependencies and/or an association between data units within the TBs.

[0149] In examples, a WTRU may receive feedback from a network device on the reception status of one or more TBs containing dependent/associated data units (e.g., PDUs). A PHY layer component at the WTRU may identify the status of the dependent/associated data units in the TBs based on configured information for identifying data unit dependencies and/or based on an explicit indication from the network device. Based on the dependencies of the data units across the TBs for which the feedback was received, the WTRU may infer the status of one or more data units within the TBs for which the network device did not provide explicit feedback.

[0150] A PHY layer component in a WTRU may determine that feedback received from a network device is related to one or more TBs that contain dependent/associated data units (e.g., PDUs). The WTRU may identify the association based on a bitmap (or any suitable data structure) that may contain downlink feedback information (DFI). For example, the WTRU may receive a DFI (e.g., in DCI) comprising HARQ feedback corresponding to one or more of the HARQ processes belonging to the TBs that contain associated data units. The feedback may include information in the form of a bitmap, which may include association information across one or more HARQ processes.

[0151] A PHY layer component in a WTRU may determine that feedback received from a network device is related to one or more TBs that contain dependent/associated data units (e.g., PDUs). The WTRU may identify the association based on information for activating one or more reserved CG resources for UL transmission. For example, the WTRU may receive a DFI (e.g., in DCI) that may include information for activating (e.g., via SPS) one or more CG resources that may be reserved for the uplink transmission or retransmission of HARQ processes or TBs that may contain dependent/associated data units.

[0152] A PHY layer component in a WTRU may determine that feedback received from a network device is related to one or more TBs that contain dependent/associated data units (e.g., PDUs). The WTRU may identify the association based on an explicit indication (e.g., provided in DCI). For example, the WTRU may receive an explicit indication (e.g., in DCI) informing the PHY layer component of the WTRU about the status of one or more TBs that contain dependent data units.

[0153] A WTRU may transmit a BSR/DSR and/or a related SR to a network device, with information on the type and/or volume of data units in the WTRU’s buffer. For example, the WTRU may have, in its buffer, a second group of data units that may depend on a first group of data units for successful reconstruction at an application. As another example, the WTRU may have, in its buffer, a second group of data units that may be transmited if a first group of data units is not successfully transmitted. As yet another example, the WTRU may have, in its buffer, a second group of data units that may be transmitted if a first group of data units is partially transmited. In these examples, the WTRU may send an indication to a network device. The indication may include a BSR MAC CE, a DSR MAC CE, and/or an associated SR. The indication may indicate the type of data (e.g., source packets, repair packets, enhancement packets, etc.) in the WTRU’s buffer, or the number of data units (e.g., the number of source packets, the number of repair packets, etc.) in the WTRU’s buffer. The indication may indicate the buffer size of the data units (e.g., the buffer size for source packets, buffer size for repair packets, etc.) in the WTRU’s buffer. The indication may indicate the ratio of one group of data units to another group of data units (e.g., the ratio of source to repair packets), or the remaining time of a data unit that may be associated with a delay budget of the data unit (e.g., remaining time of a PDU set with respect to the PSDB of PDU set).

[0154] A WTRU may transmit different types of BSRs/DSRs (e.g., a pre-emptive BSR, a pre-emptive DSR, a regular BSR/DSR, etc.) to a network device. For example, the WTRU may have 70% of packets of a data unit in its buffer. The WTRU may receive an indication of an FEC ratio of 8/10 (e.g., 8 out of 10 PDUs of the data unit need to be successfully received for a successful decoding of the PDU set at an application). The WTRU may expect that an additional number (e.g., 10%) of packets of the data unit is upcoming. In this situation, the WTRU may transmit a BSR with a data volume index corresponding to the 10% of packets not yet in the WTRU’s buffer. This transmission may occur alongside a regular BSR with a data volume index on the 70% of packets in the WTRU’s buffer.

[0155] A WTRU may transmit a BSR with information on both the data in the WTRU’s buffer and expected data coming to the WTRU’s buffer.

[0156] In one or more of the examples described herein, a WTRU may send a DSR instead of a BSR, or send a pre-emptive DSR instead of a pre-emptive BSR.

[0157] In examples, a WTRU may obtain data bits or data packets (e.g., source data bits or packets, repair data bits or packets, etc.) that may be associated with an application (e.g., a video application). The WTRU (e.g., an SDAP or PDCP component of the WTRU) may assign different subsets of the data bits or packets to one or more (e.g., separate) data units (e.g., one or more primary data units, one or more secondary data units, etc.), wherein a dependency may exist in the data units. The WTRU may send an indication regarding the data units (e.g., the respective types of the data units, the respective volumes of the data unit, etc.) to a network device (e.g., via RRC signaling such as via a WTRU assistance message). The WTRU may receive configuration information from the network device regarding rules/conditions/restrictions (e.g., LCP rules) associated with the data units. The WTRU may transmit a primary group of data units to the network device, and may receive feedback from the network device on the successful or unsuccessful reception of the primary group of data units. The WTRU may perform a procedure (e.g., an LCP procedure) based on the configuration information (e.g., the LCP rules/restrictions/conditions indicated in the configuration information) and/or the feedback received from the network device. The WTRU may prioritize a secondary group of data units based on the feedback (e.g., if the primary group of data units is not successfully received by the network device within a time window).

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

[0159] 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

1 . A wireless transmit/receive unit (WTRU), comprising: a processor configured to: obtain a first data unit and a second data unit; determine a dependency between the first data unit and the second data unit; receive a grant that provides resources for uplink transmissions; select one or more logical channels to use the resources provided by the grant, wherein the selection is made based at least on the dependency between the first data unit and the second data unit; and perform a transmission associated with the one or more logical channels using at least a portion of the resources provided by the grant.

2. The WTRU of claim 1 , wherein the processor is configured to determine that the second data unit depends on the first data unit and to select the one or more logical channels such that transmission of the first data unit is prioritized over transmission of the second data unit.

3. The WTRU of claim 1 , wherein the first data unit is of a first data type, the second data unit is of a second data type, and the processor is further configured to receive configuration information from a network device indicating a mapping between the first data type and a first logical channel, and a mapping between the second data type and a second logical channel.

4. The WTRU of claim 1 , wherein the first data unit is of a first data type, the second data unit is of a second data type, and wherein the processor is further configured to receive an indication from a network device to use the resources provided by the grant to transmit data of the first data type or the second data type.

5. The WTRU of claim 1 , wherein the second data unit depends on the first data unit, the one or more selected logical channels include a first logical channel, and the processor is further configured to map the entire first data unit and at least a portion of the second data unit to the first logical channel.

6. The WTRU of claim 1 , wherein the first data unit corresponds to a first protocol data unit (PDU) or a first PDU set, and wherein the second data unit corresponds to a second PDU or a second PDU set.

7. The WTRU of claim 1 , wherein the second data unit depends on the first data unit, and wherein the processor being configured to select the one or more logical channels to use the resources provided by the grant comprises the processor being configured to: determine that the first data unit has not been successfully received by a receiving device within a time period; and select a logical channel associated with the second data unit to use the resources provided by the grant.

8. The WTRU of claim 7, wherein the processor is configured to receive an indication from the receiving device regarding reception of the first data unit and determine, based on the indication, that the first data unit has not been successfully received by the receiving device.

9. The WTRU of claim 1 , wherein the processor is further configured to send a report to a receiving device indicating at least the dependency between the first data unit and the second data unit.

10. The WTRU of claim 9, wherein the report further indicates a buffer status associated with the first data unit or the second data unit.

11 . A method implemented by a wireless transmit/receive unit (WTRU), the method comprising: obtaining a first data unit and a second data unit; determining a dependency between the first data unit and the second data unit; receiving a grant that provides resources for uplink transmissions; selecting one or more logical channels to use the resources provided by the grant, wherein the selection is made based at least on the dependency between the first data unit and the second data unit; and performing a transmission associated with the one or more logical channels using at least a portion of the resources provided by the grant.

12. The method of claim 11 , wherein the second data unit depends on the first data unit, and wherein the one or more logical channels are selected to prioritize transmission of the first data unit over transmission of the second data unit.

13. The method of claim 11 , wherein the first data unit is of a first data type, the second data unit is of a second data type, and the method further comprises receiving configuration information from a network device indicating a mapping between the first data type and a first logical channel, and a mapping between the second data type and a second logical channel.

14. The method of claim 11 , wherein the first data unit is of a first data type, the second data unit is of a second data type, and wherein the method further comprises receiving an indication from a network device to use the resources provided by the grant to transmit data of the first data type or the second data type.

15. The method of claim 11 , wherein the second data unit depends on the first data unit, the one or more selected logical channels include a first logical channel, and the entire first data unit and at least a portion of the second data unit are mapped to the first logical channel.

16. The method of claim 11 , wherein the second data unit depends on the first data unit and selecting the one or more logical channels to use the resources provided by the grant comprises: determining that the first data unit has not been successfully received by a receiving device within a time period; and selecting a logical channel associated with the second data unit to use the resources provided by the grant.

17. The method of claim 16, further comprising receiving an indication from the receiving device regarding reception of the first data unit, wherein the determination that the first data unit has not been successfully received by the receiving device is made based on the indication.

18. The method of claim 11 , further comprising sending a report to a receiving device indicating at least the dependency between the first data unit and the second data unit.

19. A network device, comprising: a processor configured to: transmit configuration information to a wireless transmit/receive unit (WTRU), wherein the configuration information indicates a mapping between a first logical channel and a first data type, and a mapping between a second logical channel and a second data type, the second data type dependent on the first data type; provide resources for the WTRU to perform uplink transmissions; receive, from the WTRU, a first transmission associated with the first logical channel and performed based on the configuration information, wherein the first transmission uses at least a first portion of the resources provided by the network device; transmit feedback regarding the first transmission to the WTRU; and receive, from the WTRU, a second transmission associated with the second logical channel and performed based on the configuration information.

20. The network device of claim 19, wherein the second transmission is performed using a second portion of the resources provided by the network device.