Method and apparatus for handling dependencies for XR traffic in wireless system to meet QoS requirements based on DRB selection / dynamic change

Abstract

A wireless transmit / receive unit (WTRU) may include receiving a configuration from a network entity for one or more sets of data radio bearers (DRBs). The WTRU may receive one or more sets of protocol data units (PDUs) from an augmented reality (XR) application. The WTRU may map the PDUs to the DRB based on the priority of the set of PDUs. The WTRU may determine information on dependencies related to the set of PDUs based on information associated with the set of PDUs. The WTRU may determine a priority of a set of PDUs based on quality of service (QoS) requirements and dependencies with one or more sets of PDUs. The WTRU may map a set of PDUs to a set of DRBs based on the priority of the set of PDUs.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 445,509, filed on February 14, 2023, the entire contents of which are incorporated herein by reference. Background Art

[0003] The term extended reality (XR) is an umbrella term for different types of immersive experiences, including virtual reality (VR), augmented reality (AR), and mixed reality (MR), as well as the realities that are inserted between them. Virtual reality (VR) is a rendered version of the visual and audio scene being delivered. This rendering is designed to mimic the visual (e.g., stereoscopic 3D) and audio sensory stimulation of the real world as naturally as possible when the observer or user moves within a range defined by the application. Augmented reality (AR) is content that provides users with additional information or artificially generated objects / items or overlays on their current environment. Mixed reality (MR) is an advanced form of AR in which some virtual elements are inserted into the physical scene with the aim of providing the illusion that these elements are part of the real scene. XR can include all combined real and virtual environments and human-computer interactions generated by computer technology and wearable devices.

[0004] The concept of immersion in the context of XR applications / services refers to the sense of being surrounded by a virtual environment and providing a sense of being physically and spatially located in the virtual environment. The level of virtuality can range from partial sensory input to fully immersive multisensory input, making virtual reality virtually indistinguishable from actual reality.

[0005] In the present disclosure, a wireless transmit / receive unit (WTRU) may correspond to any XR device / node that may come in various form factors. Typical WTRUs (e.g., XR WTRUs) may include, but are not limited to, the following: head-mounted displays (HMDs), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with position tracking and cameras, wearables, haptic gloves, haptic body suits, haptic shoes, and the like. In addition to the above, several different types of XR WTRUs may be envisioned based on XR device functionality, such as displays, cameras, sensors, sensor processing, wireless connectivity, XR / media processing, and power, which are provided by one or more devices, wearables, actuators, controllers, and / or accessories. One or more devices / nodes / WTRUs may be grouped into collaborative XR groups to support any of the XR applications / experiences / services.

[0006] In XR services and applications, traffic may include data or protocol data units (PDUs), which may be associated with application data units (ADUs), PDU sets, or data bursts. In one example, one or more PDUs belonging to a PDU set may be associated with different segments or components of a video frame or video slice. A data burst may consist of one or more PDU sets. For example, the total payload size (e.g., units of bits / bytes) of a PDU set or a data burst transmitted in an uplink (UL) and / or received in a downlink (DL) may depend on the type of media frame (e.g., 3D video frame, audio frame). Summary of the Invention

[0007] In an embodiment, a wireless transmit / receive unit (WTRU) includes a processor, and the processor may be configured to receive a configuration for a first data radio bearer (DRB) set and a second DRB set from a network entity. The WTRU receives a first protocol data unit (PDU) set from an extended reality (XR) application. The WTRU maps the first PDU set to the first DRB set based on a priority of the first PDU set. The WTRU also receives a second PDU set from the XR application. The WTRU determines information about a dependency relationship between the first PDU set and the second PDU set based on information associated with the first PDU set and the second PDU set. The WTRU determines a priority for the second PDU set based on a quality of service (QoS) requirement and a dependency relationship between the first PDU set and the second PDU set. The WTRU maps the second PDU set to the first DRB set or the second DRB set based on the priority of the first PDU set and the priority of the second PDU set.

[0008] The WTRU may receive feedback from a network entity regarding a first PDU set. The QoS requirement may be based on the performance or success rate of the first PDU set. The feedback may include information regarding a first number of successfully received PDUs in the first PDU set or a second number of PDUs to be retransmitted by the WTRU. The performance of the first PDU set may be statistical, instantaneous, or event-triggered.

[0009] The success rate of the first PDU set may be based on feedback or residual delay.

[0010] The residual delay may be the time spent in the buffer relative to the delay budget of the first PDU set or the packet delay budget (PDB) of the first PDU set.

[0011] The success rate of the first PDU set may be a measure of the percentage of PDUs in the PDU set that were transmitted above a percentage threshold.

[0012] The performance or success rate of the first PDU set may be a function of both the percentage of the first PDU set transmitted and the time taken to transmit the first PDU set.

[0013] Information about dependencies may include arrival time or data type. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented.

[0015] Figure 1B is a diagram showing the embodiment of the invention. Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within a communication system is shown.

[0016] Figure 1C is a diagram showing that according to an embodiment, Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) for use within a communication system is shown in FIG.

[0017] Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in a communication system is shown in FIG.

[0018] Figure 2 This shows an example of low scheduling efficiency caused by failure of various PDU sets to satisfy dependencies.

[0019] Figure 3 An example of a flow for two PDU sets is shown, where a PDU set delay budget (PSDB) is mapped to a corresponding quality of service (QoS) flow and then mapped to a data radio bearer (DRB).

[0020] Figure 4A An example of DRB selection / dynamic change that meets QoS requirements is shown.

[0021] Figure 4B Another example of DRB selection / dynamic change that meets QoS requirements is shown.

[0022] Figure 5A An example of a network configuration limited to logical channels (LCHs) that process dependencies is shown.

[0023] Figure 5B Another example of a network configuration limited to processing dependent logical channels (LCHs) is shown.

[0024] Figure 6An example of a process for selecting PDUs for filling a Medium Access Control (MAC) PDU / transport block to consider dependencies in addition to QoS is shown.

[0025] Figure 7 An example of enhancement of the discard mechanism in the case where PDUs in a PDU set arrive simultaneously is shown.

[0026] Figure 8 An example is shown where the discard mechanism of successfully delivered PDUs / PDU sets is enhanced.

[0027] Figure 9 An example of a discard mechanism enhancement is shown in which the PDUs in a PDU set arrive in sequence. DETAILED DESCRIPTION

[0028] Figure 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tailing unique word DFT spread OFDM (ZT-UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0029] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Any of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (e.g., a WTRU), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or MiFi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), consumer electronic devices, devices operating on a commercial and / or industrial wireless network, etc. Any of the wireless transmit / receive units 102a, 102b, 102c, and 102d may be interchangeably referred to as a WTRU.

[0030] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly connect to at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CNs 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), NodeBs, eNodeBs, Home NodeBs, Home eNodeBs, gNodeBs (gNBs), New Radio (NR) NodeBs, site controllers, access points (APs), wireless routers, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

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

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

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

[0038] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business place, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0039] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Data may have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions (e.g., user authentication). Although in Figure 1A Although not shown, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0041] One or more of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers to communicate with different wireless networks via different wireless links). Figure 1A The WTRU 102c shown may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0042] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

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

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

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

[0046] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

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

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

[0050] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a 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.

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

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

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

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

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

[0056] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for facilitating switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

[0058] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0059] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0060] Although the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may utilize a wired communication interface with a communication network (eg, temporarily or permanently).

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

[0062] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic entering and / or leaving the BSS. Traffic originating from outside the BSS and destined for a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. This peer-to-peer traffic may be sent between a source and destination STA (e.g., directly between the source and destination STAs) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode cannot have an AP, and STAs (eg, all STAs) within or using the IBSS can communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

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

[0064] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0065] Very high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be subjected to inverse fast Fourier transform (IFFT) processing and time domain processing respectively. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the above-mentioned 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0066] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier frequency are reduced in 802.11af and 802.11ah relative to the channel operating bandwidth and carrier frequency used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, for example, limited capabilities including support for certain and / or limited bandwidths (e.g., only support). MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0067] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA that supports (e.g., only supports) 1 MHz mode (e.g., an MTC-type device), the primary channel can be 1 MHz wide, 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 only supports 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy, even if most of the frequency band remains idle and available.

[0068] In the United States, the available frequency band for 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz, depending on the country code.

[0069] Figure 1D1 is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 may employ NR wireless technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

[0071] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing a varying number of OFDM symbols and / or an absolute time duration of varying length).

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

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

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

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

[0076] The SMFs 183a, 183b may connect to the AMFs 182a, 182b in the CN 115 via the N11 interface. The SMFs 183a, 183b may also connect to the UPFs 184a, 184b in the CN 115 via the N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure traffic routing through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0077] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

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

[0079] Given that Figures 1A-1D and Figures 1A-1D

[0015] As described herein, one or more or all of the functionality described herein with respect to one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein. An emulated device may be one or more devices configured to emulate one or more or all of the functionality described herein. For example, an emulated device may be used to test other devices and / or simulate network and / or WTRU functionality.

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

[0081] One or more emulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation device can be used in a test scenario in a test lab and / or a wired and / or wireless communication network that is not deployed (e.g., testing) to enable testing of one or more components. The one or more emulation devices can be test devices. The emulation device can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas).

[0082] In XR traffic, dependencies can exist between PDUs (within a PDU set or data burst), between PDU sets, between data bursts and / or between multiple streams. Dependencies between PDUs can be defined by data type, transmission / arrival time and / or other dependency parameters. For example, a PDU may include multimedia data, such as video data and / or audio data. Multimedia data may contain different data types that may be dependent on each other. In one example, when a PDU or a PDU set includes intra-coded picture frames (I frames), predicted picture frames (P frames) and / or bidirectionally predicted picture frames (B frames), the P frames and / or B frames may be dependent on one or more I frames. An I frame may include an entire image and may be encoded without reference to other frames. P frames and / or B frames may include images and / or video data and may reference other frames, such as I frames or other P frames / B frames. In this way, P frames and / or B frames may be dependent on other frame types. Dependencies may also exist between any two frames or their types.

[0083] Figure 2An example of scheduling inefficiency resulting from failure to satisfy dependencies between individual PDU sets is shown in process 200. As used herein, at 201, dependencies between PDUs of a PDU set (e.g., PDUs 1-4) may be referred to as intra-PDU set dependencies. For intra-PDU set dependencies, each PDU in PDU set 1 may be successfully delivered within a PDU set delay budget (PSDB) (e.g., PSDB 1). The PDU set delay budget (PSDB), as defined in Release 18XR (TR 23.700-60), may be the time between the receipt of the first PDU (at the UPF in the DL, at the UE in the UL) and the successful delivery of the last arriving PDU in the PDU set (at the UE in the DL, at the UPF in the UL). Additionally, at 202, dependencies between one or more PDU sets may be referred to as inter-PDU set dependencies. For inter-PDU set dependencies, each PDU in PDU set 2 may be successfully delivered within PSDB 2 to decode PDU set 1, or vice versa.

[0084] A PDU set can be implemented to process and deliver a group of PDUs belonging to a PDU set, which consists of one or more PDUs carrying a payload of an information unit generated at the application layer (e.g., a frame or video slice for an XRM service). In some implementations, the application layer may need the PDUs in the PDU set to use the corresponding information unit. In other implementations, when some PDUs are lost, the application layer can still recover part of the information unit.

[0085] There may be multiple types of PDU sets for different types of applications and / or data types (e.g., video data, audio data, etc.). A first type of PDU set (e.g., Type I) may not tolerate any loss / delay of any PDU of the PDU set or loss / delay above a predefined threshold. When the loss or delay is above a threshold (e.g., one of the PDUs is lost or delayed within a period of time), the remaining PDUs may be discarded. A second type of PDU set (e.g., Type II) may tolerate some loss / delay or loss / delay above a predetermined threshold. The XR application may reconstruct the PDU set in the event that some PDUs of the PDU set are delayed / lost, depending on the type of application and / or data type.

[0086] A PDU set integrated indication (PSII) or a PDU set integrated processing indication (PSIHI) can be implemented to process PDUs in different types of PDU sets according to specific parameters. A PDU set mapped to a QoS flow with a PSII or PSIHI indicator can be a type in which each PDU in the PDU set is implemented to successfully decode the PDU set at the application. A PDU set can have a PSII or PSIHI indicator. Or other structures to which the PDU set is mapped (e.g., a QoS flow, a DRB, a LCH, etc.) can have a PSII or PSIHI indicator. There is no such indicator that can indicate a non-PSII or non-PSIHI PDU set, for example, a PDU set that can be decoded at the application even if one or more PDUs in the PDU set are lost and / or delayed beyond the PSDB. For example, a PDU set QoS parameter can be defined to support processing for different types of PDU sets. A device and / or an application executing on the device can use the PDU set QoS parameter to determine whether each PDU in the PDU set is required by the application layer to use the PDU set (PDU set integrated indication) (e.g., to meet a specific quality of service threshold).

[0087] Failure to satisfy dependencies (e.g., by successfully receiving and / or decoding dependent PDUs / PDU sets within certain time frames) may result in scheduling inefficiencies. For example, unsuccessful transmission / reception of one PDU set may render other successfully delivered PDU sets useless because the application executing on the device cannot decode the dependent PDU sets. Furthermore, discarding one PDU set at the Packet Data Convergence Protocol (PDCP), e.g., due to PDCP timer expiration, may render other dependent PDU sets useless. The same applies to dependencies within a PDU set, such as Figure 2 shown.

[0088] Embodiments for handling dependencies in XR traffic are described herein. Examples for handling dependencies in XR traffic during one or more of the selection of a data radio bearer (DRB) and / or LCH, multiplexing of PDUs into transport blocks (TBs) (e.g., during a logical channel prioritization (LCP) procedure), and / or mechanisms for discarding PDUs / PDU sets are described.

[0089] In one example, the LCP process may support prioritization based on LCH parameters (e.g., priority, priority bit rate (PBR), buffer size duration (BSD), and / or other LCH parameters). Furthermore, when certain discard mechanisms are used, a discard timer may be implemented to determine when certain data is discarded at the transmitting entity. When the discard timer for a PDCP service data unit (SDU) expires, or when successful delivery of the PDCP SDU is confirmed via a PDCP status report before the discard timer expires, the transmitting PDCP entity may discard the PDCP SDU and the corresponding PDCP data PDU. If the corresponding PDCP data PDU has already been submitted to lower layers, the discard may be indicated to the lower layers.

[0090] In some DRB and LCH selection / mapping processes, LCP processes and discard mechanisms handle packets on a per-PDU basis. They may not be suitable for handling packets on a PDU aggregate basis. Furthermore, they may not be suitable for handling any dependencies that may exist between PDUs in a PDU aggregate or between multiple PDU aggregates. In XR, violation of dependencies can lead to higher PDU aggregate error rates (PSERs) and scheduling inefficiencies.

[0091] In one example, unsuccessful transmission / reception of one PDU set may render other successfully delivered PDU sets useless because the application executing on the device cannot decode the dependent PDU sets. In addition, discarding one PDU set at the PDCP (e.g., due to expiration of a PDCP discard timer) may render other dependent PDU sets useless. Based on these issues, a process can be implemented to account for dependencies in XR traffic when managing dependent PDUs / PDU sets, as described herein.

[0092] One example of managing dependent PDUs / PDU sets may include managing multiplexing of PDUs / PDU sets. One embodiment of multiplexing may involve DBR selection / dynamic change to meet QoS requirements. The WTRU may receive a configuration of a DRB set from a network entity. For example, the WTRU may receive a DRB set and / or their indicated priorities (e.g., DRB 1, priority of DRB 1, DRB 2, priority of DRB 2) configured by the gNB from the network (NW) (e.g., in radio resource control (RRC)). One or more DRBs may be configured (e.g., configured by the network) and / or reserved for dependent PDUs / PDU sets. The WTRU may receive PDU set 1 and its associated priorities (e.g., importance), for example, from an XR application. The WTRU may map the PDU sets to DRBs based on the associated priorities. For example, the WTRU may map / forward PDU set 1 to DRB 1 based on the priority of PDU set 1. The WTRU may receive PDU set 2 and its associated priorities, for example, from an XR application (e.g., PDU set 2 may arrive later than expected). The WTRU may determine information about the dependency based on, for example, arrival time, data type, and / or other dependency parameters. For example, the WTRU may determine that PDU Set 1 and PDU Set 2 are dependent based on the dependency parameters. The WTRU may also determine the success rate of PDU Set 1 based on feedback and / or residual delay. The method for determining the performance / success rate of the PDU sets may be statistical or instantaneous. The WTRU may determine the QoS / priority of PDU Set 2 based on the performance / success rate of the first PDU set. For example, the WTRU may track the performance / success rate of the PDU set based on its performance over a past time window and take these statistics into account when determining to switch the mapping of another PDU set to the DRB of the PDU set. As another example, the WTRU may perform an instantaneous sampling check on the performance / success rate of the PDU set. For example, the WTRU may determine to change the priority of PDU Set 2 by mapping PDU Set 2 to DRB 1 (if the performance / success rate of DRB 1 is greater than the configured threshold) or mapping PDU Set 2 to another pre-configured DRB 3 (the priority of DRB 3 is higher than the priority of DRB 2) to ensure QoS and dependencies.

[0093] Another embodiment for multiplexing may involve configuring the LCH to be restricted to processing dependencies, which may be considered a network-assisted embodiment. The WTRU may receive the configuration of the LCH set from a network entity. For example, the WTRU may receive the LCH set configured by the gNB, for example, from the NW in RRC. One or more LCHs may be restricted to processing dependencies (e.g., LCH B). The WTRU may receive one or more PDU sets, for example, from an XR application. The WTRU may determine information about the dependencies based on, for example, arrival time, data type, and / or other dependency parameters. For example, the WTRU may determine that PDU set 1 and PDU set 3 are dependent based on the dependency parameters. If the parameters of LCH B (e.g., priority, PBR) meet the requirements for the dependent PDU set (PDU set delay budget (PSDB), e.g., PSDB1, PSDB3), the WTRU may map the dependent PDU set to LCH B. In the event of a conflict between an independent LCH and a restricted dependent LCH during the LCP process, the WTRU may be configured to prioritize the restricted dependent LCH, which may result in a reduced impact on the PSER. As an example, if the priority of LCH A (a non-dependent LCH that may take into account parameters such as priority) is the same as the priority of LCH B (a special LCH configured and / or reserved for handling dependencies), the WTRU may be configured to prioritize LCH B.

[0094] In an embodiment, multiplexing may involve selecting PDUs to fill a medium access control (MAC) PDU / transport block to take into account dependencies in addition to QoS, which may be considered a MAC embodiment. Configuration parameters received from a network entity for LCH configuration may include a time threshold (T). For example, the WTRU may receive the LCH set and time threshold T configured by the gNB from the NW (e.g., in RRC), and the WTRU may receive PDUs from one or more PDU sets (e.g., PDU 1 of PDU set 1, PDUs 1 and 2 of PDU set 3) from an XR application.

[0095] The WTRU may multiplex the received PDUs into a transport block (e.g., PDU 1 of PDU set 1 and PDUs 1 and 2 of PDU set 3 are multiplexed into TB1). In addition, the WTRU may receive more PDUs from the XR application, including the remaining PDUs of the PDU set. The WTRU may determine information about the dependency based on, for example, arrival time, data type, and / or other dependency parameters. For example, the WTRU may determine that PDU set 1 and PDU set 3 are dependent based on the dependency parameters. The WTRU may determine the remaining delay t for transmitting the remaining PDUs of the PDU set. If t < T, the WTRU may consider the priority of the LCH during multiplexing of the PDUs into the TB. For example, the WTRU may multiplex PDU set 2 from LCH2 onto the remaining PDUs of PDU set 3. In this way, the determination may be based on the priority of PDU set 2 and the priority of LCH2. If t>T, in addition to LCH parameters (e.g., priority), the WTRU may consider dependencies between PDU sets during multiplexing of PDUs into TBs (e.g., as an example, when multiplexing PDUs into TB 2, the WTRU may prioritize PDUs of PDU set 3 over PDUs of PDU set 2, assuming that such prioritization does not violate PSDB2 (PSDB of PDU set 2)).

[0096] In an embodiment, as a variation of the above, within DRB2, the WTRU may dynamically change / control some parameters, such as adjusting (increasing) the PBR based on dependencies.

[0097] In an embodiment, a discard mechanism may be applied based on consideration of dependent PDUs / PDU sets. For example, a WTRU may receive XR data from an XR application to be transmitted to a network entity. The WTRU may identify a data type associated with the XR data and process information for the indicated data type. As described herein, different types of PDUs / PDU sets (e.g., Type I or Type II) may be considered to tolerate loss / delay of any PDU in the PDU set. The WTRU may transmit the XR data to the network entity and receive feedback (e.g., in the form of a status report). When the feedback indicates a negative acknowledgement (NACK), the WTRU may determine whether the duration for retransmitting the XR data is still valid. In response to determining that the duration for retransmitting the XR data is still valid, the WTRU may retransmit the XR data. In response to determining that the duration for retransmitting the XR data has expired and the data type is a first data type (e.g., Type I), the WTRU may discard the XR data. In response to determining that the duration for retransmitting the XR data has expired and the data type is a second data type (e.g., Type II), the WTRU may discard the XR data and instruct a dependent Packet Data Convergence Protocol (PDCP) entity to discard dependent XR data associated with the XR data.

[0098] An example illustrates applying a discard mechanism when PDUs in a PDU set arrive simultaneously. When data units (e.g., PDU sets, PDUs) mapped to different PDCP entities are not successfully delivered, discards may be required across multiple PDCP entities. In such an embodiment, the steps involved may include the WTRU receiving XR data, e.g., PDU set 1, from an XR application. The WTRU may identify a data type (e.g., Type I or Type II) and / or a flag indicating data type processing associated with the XR data (e.g., PDU set 1). The WTRU may transmit the XR data in the UL to the gNB. Additionally, the WTRU may receive a status report (e.g., a PDCP status report) indicating a negative acknowledgement (NACK) from the gNB and may retransmit one or more PDUs of the PDU set (e.g., PDU set 1). The WTRU may retransmit the PDUs of PDU set 1 if a duration for retransmitting the data units is still valid (e.g., the PDCP timer(s) for PDU set 1 are still running). If the PDCP timer(s) for the XR data unit (e.g., PDU timer(s) or PDU set timer(s)) has expired and the data type of the PDU set is a second data type (e.g., Type II), the WTRU may fall back to discarding any remaining PDUs, e.g., PDU set 1. If the PDCP timer(s) for the XR data unit (e.g., PDU timer(s) or PDU set timer(s)) has expired and the data type of the PDU set is a first data type (e.g., Type 1), the WTRU may discard the XR data unit (e.g., a copy of PDU set 1 or the remaining PDUs of PDU set 1); the WTRU may instruct the dependent PDCP entity to discard all dependent XR data units (e.g., PDU set 2); the WTRU may send an indication to the gNB (e.g., PDCP entity 2 in the gNB) to indicate the discard / release of any context associated with dependent PDU set 2 (e.g., SN); and / or if the dependent PDUs set in the dependent PDCP entity (e.g., PDCP 2) have been submitted to lower layers (e.g., WTRU radio link control (RLC) entity), the WTRU (e.g., PDCP 2) may send a discard indication to the lower layers (e.g., RLC 2) to avoid SN gaps.

[0099] In an embodiment of the discard mechanism, a WTRU receiving XR data (e.g., PDU set 1) from an XR application may transmit the XR data to the gNB in ​​the UL when the PDU / PDU set is successfully delivered. If the WTRU receives a status report at the gNB indicating successful delivery of the XR data, the WTRU (transmitter side) may discard the copy of the successfully delivered PDU set after receiving the status report from the gNB (receiver side, e.g., PDCP entity at the gNB). In current systems, a status report may be sent from the receiver (e.g., a receiving PDCP entity in the network) to the transmitter (e.g., a transmitting PDCP entity in the WTRU) to confirm the successful delivery of the PDU. Such a status report may be on a per-PDU basis. In one solution, there may be a status report transmitted from the receiver to the transmitter to indicate the delivery status of the PDU set (e.g., one status report per PDU set). The delivery status may include successful or unsuccessful delivery or delayed delivery of the PDU set.

[0100] In an embodiment, when the PDUs in the PDU set arrive out of sequence, a discard mechanism enhancement may be applied. For example, the process may include the WTRU at time t1 (t1 < t A' ) receives the first batch of PDUs of the PDU set from the XR application. The WTRU may transmit the first batch of PDUs of the PDU set in the UL. The WTRU may receive a retransmission indication for the first batch of PDUs from the gNB (e.g., receiving PDCP entity at the gNB). If the WTRU has received the first batch of PDUs from the gNB, the WTRU may transmit the first batch of PDUs of the PDU set in the UL. A' If the WTRU transmits the remaining PDUs of the PDU set in the UL and the PDCP timer(s) for the first PDUs of the PDU set are still running, the WTRU may transmit the remaining PDUs of the PDU set in the UL; and / or the WTRU may retransmit the first PDUs after a retransmission indication from the gNB. A' If the remaining PDUs of the PDU set have not been received previously, the WTRU may determine not to retransmit the first batch of PDUs of the PDU set, even if the PDCP timer(s) for the first batch are still running; and / or the WTRU may send an indication to the gNB (e.g., a receiving PDCP entity at the gNB) that the first batch of PDUs of the PDU set will not be retransmitted (to avoid any gaps in sequence numbering). Additionally, the WTRU may include an indication as to why the retransmission will not proceed despite the retransmission indication from the gNB (failure to receive the remaining PDUs of the PDU set on time).

[0101] In the discussion herein, the term network (NW) may include, for example, one or more of a base station (e.g., gNB, transmission / reception point (TRP), RAN node, access node), core network functions (e.g., AMF, SMF, policy control function (PCF), network exposure function (NEF)), and application functions (e.g., edge server function, remote server function). In addition, a flow may correspond to one or both of a QoS flow or a data flow. For example, a data flow consisting of one or more PDUs, sets of PDUs, or data bursts may be associated with one or more QoS requirements, such as latency, data rate, reliability, round trip time (RTT) delay). Different flows that may originate from a common application / experience source and / or be intended for a common destination device / WTRU or group of associated devices / WTRUs may be referred to as associated flows or related flows.

[0102] In the disclosure herein, a data unit may refer to one or more frames (eg, media / video / audio frames or slices / fragments), PDU sets, data bursts, and groups of frames / PDU sets / data bursts. The term may also apply to.

[0103] The term Quality of Experience or QoE may correspond to one or both of application and / or higher layer metrics and measurements that may be directly or indirectly observable / visible at the WTRU and / or application functions. For example, such QoE metrics and measurements may or may not be directly observable / observable at the base station. Such QoE metrics and measurements may be determined / performed based on QoS metrics / parameters (e.g., latency, data rate, reliability, RTT / Motion Photon (MTP) delay).

[0104] In the discussion herein, a forwarding configuration may correspond to one or more radio bearers (e.g., data radio bearers (DRBs) and / or signaling radio bearers (SRBs), logical channels (LCHs), logical channel groups (LCGs), configuration parameters in various layers within the AS protocol stack (e.g., service data adaptation protocol (SDP), PDCP, RLC, MAC, physical layer (PHY), other protocol layers), parameters associated with logical channel prioritization (LCP) (e.g., priority, PBR, BSD), bandwidth part (BW), carrier, radio link / interface (Uu link, sidelink (SL)), and radio resources (e.g., a set of one or more frequency / time / space resources, such as symbols, time slots, subcarriers, resource elements, or beams).

[0105] A mapping configuration may be used to correspond to one or more of the parameters and / or configurations associated with the mapping. For example, a mapping configuration may be a data unit, a PDU, an SDU, a PDU set, a data burst, an application data (e.g., ADU) flow, and a QoS flow (e.g., associated or non-associated). These parameters and / or configurations may originate from any of the application layer, higher layers, and the network for one or more radio bearers (e.g., DRBs, SRBs), layers, sublayers, or entities (e.g., SDAP, new layers, PDCP, RLC, MAC, PHY), LCHs, carriers or component carriers (e.g., CCs in CA configurations), BWPs, and radio links / interfaces (e.g., Uu links or side links). In addition, these parameters and / or configurations may be used, for example, to deliver data / PDUs in the UL direction or the DL direction.

[0106] As used herein, the terms XR / application-aware data transmission / reception or XR / application-aware QoS processing may correspond to one or more attributes associated with a PDU set, ADU, or data burst: A PDU set (e.g., a media unit, a video frame) may include one or more PDUs. A PDU set may be associated with QoS requirements at the PDU set level (e.g., data rate, latency, error rate, reliability), which may apply to one or more or all PDUs associated with the PDU set. Different PDUs in a PDU set may be associated with respective PDU-level QoS requirements. A data burst may refer to data generated by an application in a short period of time, including PDUs from one or more PDU sets. Such attributes, associations and interdependencies (e.g., within a PDU set and / or between PDU sets) including start / end indications (e.g., via sequence numbers, start / end indications), start / end times, duration, payload size, periodicity, importance / priority and QoS (e.g., PSDB) of PDU sets / data bursts can be visible to the AS layer (e.g., with associated IDs) and / or processed at the AS layer with awareness of the association during data transmission in the UL and data reception in the DL.

[0107] XR / application-aware data transmission / reception or XR / application-aware QoS processing may also correspond to application or high-level importance or priority: different PDUs in a PDU set or all PDUs in a PDU set may be associated with different application / high-level importance / priority values. Such importance values ​​may correspond to spatial importance (e.g., the spatial location of a video frame whose data is carried by a PDU / PDU set, where a PDU / PDU set carrying a field of view (FoV) spatial location may be associated with a higher spatial importance than a non-FoV spatial location) or temporal importance (e.g., the temporal sequence of video frames whose data is carried by a PDU / PDU set, where a PDU / PDU set carrying a basic video frame such as an I-frame may be associated with a higher temporal importance than a differential video frame such as a P-frame / B-frame). During data transmission and reception, such importance values ​​may be visible to the access stratum (AS) layer (e.g., with an associated ID / tag / indication), which may be implemented by application awareness. These items may also correspond to QoS / data flows. The application's PDUs / PDU sets may be encoded and delivered by the application to the WTRU (in the UL) or the network (in the DL) via one or more QoS / data flows. In this regard, the different QoS flows carrying the PDUs / PDU sets associated with the XR application / experience may be visible to the AS layer (e.g., with associated IDs) and / or handled at the AS layer with knowledge of the association during data transmission and reception.

[0108] WTRU actions (e.g., WTRU actions related to application actions and / or AS layer actions for ensuring / supporting differentiated QoS) may correspond to determination of application metadata and one or more of the XR applications. In an example, the determination of metadata may involve determining any of the FoV / visual / spatial perimeter, 2D / 3D size, edges, spatial attributes, and boundaries of the FoV based on measurements in any spatial dimension, including but not limited to longitude, latitude, altitude, depth, roll, pitch, yaw in one or more coordinate systems (e.g., Cartesian coordinate system, spherical coordinate system). In another example, the determination of metadata may involve determining the quality of the FoV content, e.g., whether the FoV content has high quality, which in the case of images may be quantified and evaluated by image resolution (e.g., number of megapixel density). As a further example, the determination of metadata may involve determining the importance and / or priority of the FoV content. For example, the importance may be associated with the spatial importance and / or temporal importance of the content / data. For example, the spatial / temporal importance value may indicate an absolute or relative importance associated with the FoV content. For example, spatial importance may be associated with one or more segments / tiles / slices / positions of the FoV in the spatial dimension. For example, temporal importance may be associated with one or more frames / subframes of the FoV in the temporal dimension.

[0109] The WTRU action may also correspond to the determination / generation of application content. In an example, the determination of application content may involve determining / capturing one or more 2D / 3D image / video frames associated with a FoV boundary / perimeter / edge defined by the WTRU / node for itself and / or FoV metadata on behalf of another WTRU / node. For FoV content mapping, the WTRU may use visual sensors (e.g., 2D / 3D cameras, lidar), RF sensors (e.g., RF transceivers, radar), audio sensors (e.g., sonar), etc. to determine the image / video frames. Mapping of the FoV may also be referred to herein as sensing of FoV content or capturing of FoV content. In another example, the determination of application content may also include recording / capturing audio frames as part of the real environment or as part of an overlaid audio track / audio file, where the audio file originates from a source other than the current real environment being mapped.

[0110] WTRU actions may also correspond to performing measurements and reporting measurement information. In one example, the WTRU may perform measurements of the position / spatial / posture (e.g., 6DoD / 3DoD orientation, location / position), motion / movement rate, etc. of the user / WTRU and / or other objects (e.g., virtual or real) that the user may be interacting with. The WTRU may send / report posture measurements to the network periodically or upon detecting an event trigger (e.g., a change in posture measurement value above / below a threshold). Another example may include the WTRU performing measurements on one or more of a reference signal or channel (e.g., synchronization signal block (SSB), channel state information (CSI) reference signal (RS), PRS, sidelink RS), GNSS signal, unlicensed carrier, ultra-wideband signal, lidar signal, visual signal, etc. In other examples, the WTRU may perform measurements on a radio link interface (e.g., Uu link, SL) associated with the WTRU, the WTRU may trigger the transmission and / or measurement of reference signals in one or more other WTRUs (e.g., via the Uu link and / or sidelink), and / or send measurement reports to the network and / or another WTRU.

[0111] The WTRU actions may also correspond to processing / forwarding data / PDU sets and processing QoS associated with the PDU / PDU sets. In one example, the data may include any of media / image / video frames, sensor data, and measurement data (e.g., posture measurements, link / channel measurements) determined by the WTRU, which may be used to support application / service / network requests associated with the WTRU. In another example, the WTRU may send and / or receive data to / from one or more destinations, including a RAN node (e.g., a gNB), a CN function / entity, an application function (e.g., hosted in the WTRU or the network). In addition, the WTRU may perform splitting / merging of data / PDUs in one or more QoS flows into one or more forwarding configurations during transmission / reception.

[0112] The WTRU action may further involve processing / forwarding information related to connections with the network and / or other WTRUs. For example, sending capability information to the network may include one or more of the ability to support one or more traffic flows with different XR traffic patterns (e.g., periodic / aperiodic, PDU sets with variable payload sizes), the ability to perform application layer measurements (e.g., QoE measurements, application buffer measurements, RTT measurements), and the ability to detect changes in traffic patterns. Another example may involve sending inter-WTRU coordination capability information to the network, including the ability to support one or more interfaces, the ability to coordinate and / or interact with other WTRUs / devices (e.g., via SL interfaces), which may be co-located or non-co-located with the WTRU. Further examples may include one or more of: receiving configuration, including receiving RRC configuration from the gNB and / or receiving NAS layer configuration from the CN; sending and / or receiving assistance data to / from the network associated with traffic, QoS, scheduling, etc., for supporting UL / DL transmission; and sending a request for radio resources and / or resource grants (e.g., dynamic grants, semi-static / configured grants).

[0113] In various embodiments herein, there may be common components. With respect to the determination of dependencies in traffic, dependencies may refer to dependencies within a PDU set (i.e., dependencies between different PDUs of a PDU set) or dependencies between PDU sets (i.e., dependencies between one or more PDU sets). Dependencies may also refer to dependencies between different PDU sets in a data burst (e.g., different PDU sets received within a short time window). Dependencies may be determined by the WTRU or known to / transmitted to the WTRU via an importance tag added at an application or SDAP or a new layer above / below SDAP. For example, the importance tag may be added to the data unit (e.g., in the header of each PDU set) or sent as metadata (e.g., via separate signaling). In addition, lower layers may be able to read the importance tag and infer any dependencies from the importance tag. Dependencies may be determined by the WTRU or known to / transmitted to the WTRU via an SN tag added at an application or SDAP or a new layer above / below SDAP. For example, the importance tag may be added to the data unit (e.g., in the header of each PDU set) or sent as metadata (e.g., via separate signaling). In addition, lower layers may be able to read the importance tag and infer any dependencies based on the importance tag (e.g., PDUs 1, 2, and 3 of PDU set 1 may be labeled [1, 1], [1, 2], [1, 3], and PDUs 1 and 2 of PDU set 2 may be labeled [2, 1], [2, 2]).

[0114] Dependencies may also be determined by the WTRU or communicated to the WTRU via arrival times, such as time keeping (e.g., in SDAP / PDCP, time window start / end times based on a time reference (e.g., SFN) and / or lower layers may assume dependencies within two data units (e.g., two PDU sets) that arrive within a time window of each other. Dependencies may also be determined by the WTRU or communicated to the WTRU via data types. For example, a subsequent frame may depend on the first or more frames (e.g., the second frame depends on the first frame). Additionally, one frame type may depend on another frame type, such as a dependent / differential frame (e.g., P-frame / B-frame) that depends on an I-frame. Another example may be that a PDU set type I has higher dependencies between the constituent PDUs of the PDU set because, by definition, a PDU set type I cannot tolerate any loss / delay of any PDU in the PDU set; compared to a PDU set type II that may tolerate loss / delay of one or more PDUs in the PDU set.

[0115] The dependency may be further determined by the WTRU or known / communicated to the WTRU via a QoS flow. For example, the WTRU may determine that two PDU sets arriving in the same QoS flow are dependent on each other. The dependency may be further determined by the WTRU or known / communicated to the WTRU via an explicit indication from a higher / application layer. For example, a higher / application layer may explicitly mark two data units as being dependent on each other because an application may require both data units at the other end. For example, an application may mark PDU set 1 and PDU set 3 as being dependent on each other (e.g., by marking PDU set 1 and PDU set 3 in-band, or by separate signaling indicating the dependency between PDU set 1 and PDU set 3) so that lower layers in the WTRU (e.g., the AS layer) may treat PDU set 1 and PDU set 3 in a manner that maintains the dependency. Other examples may involve a higher / application layer providing an application layer packet. The packet may be considered a PDU. The application layer packet may be an RTP packet. The packet may include a header that describes the PDU. Thus, there may be a field in the header that indicates the priority (e.g., importance) of the packet relative to other packets in the same flow. The WTRU may determine that packets with the same priority value in the header are dependent on each other. There may also be a field in the header that indicates a sequence number. The WTRU may determine that PDU sets associated with consecutive sequence numbers are associated with each other (e.g., a PDU set associated with sequence number 4 is associated with a PDU set associated with sequence number 5). Further, there may be a field in the header that indicates a dependency relationship. For example, the dependency indication may be referred to as a correlation ID, and the PDU sets that include the correlation ID in the header may be considered dependent on each other. Alternatively, the WTRU may receive a PDU set handling rule in a NAS message. The PDU set handling rule may be received as part of the QoS rules. The PDU set handling rule may indicate the correlation ID values ​​that should be considered associated with each other. For example, the PDU set handling rule may indicate that correlation ID values ​​5 and 3 are associated. The WTRU may then determine that any packets with correlation IDs 3 or 5 in the header are associated with each other.

[0116] The dependency relationship may also be determined by the WTRU or known / communicated to the WTRU via any one or a combination of the above. For example, the WTRU may determine that two sets of PDUs of the same importance or priority that are sent consecutively (or within a short specified time window of each other) are dependent on each other. As another example, the WTRU may determine that two sets of PDUs of the same type that have arrival times within a short specified time window of each other are dependent.

[0117] The common components of other embodiments may include information about traffic characteristics. The WTRU may send information (e.g., to the NW) or receive information (e.g., from a higher / application layer or from the NW) or determine information about traffic characteristics: the information may include the size of the PDU set, the number of PDUs in each PDU set, the number of PDUs in a data burst in one or more traffic flows. The information about traffic characteristics may include instantaneous measurements / determinations and / or statistical / distribution information, such as average, minimum, maximum, standard deviation values. Information related to the PDU set may include the size of the PDU set (e.g., total payload, the number of PDUs in the PDU set), an indication of the start / first and / or end / last PDU of the PDU set, and an indication of the association / dependency of the PDUs in the PDU set (e.g., an ID of the PDU set, an importance / priority value). As an example, the WTRU may receive (e.g., from an XR application) information about the number of PDUs in the PDU set and an indication of the first PDU in the PDU set. Based on this information, the WTRU may determine the size of the PDU set and the last PDU of the PDU set. As a further example, the WTRU may have received PDUs 1, 2, and 3 from a PDU set. Based on information about the size of the PDU set (e.g., in terms of the total number of PDUs in the PDU set), the WTRU may determine that PDUs 4, 5, and 6 of the PDU set are still pending and should be received immediately (ideally, within a time window that allows the WTRU to deliver all PDUs in the PDU set within the transmission delay budget (PSDB)). Yet another example may involve the WTRU sending to the NW or receiving from the NW / application / higher layers information about PDU sets and / or data bursts in one or more data / QoS flows, including the number of PDUs or PDU sets (e.g., instantaneous, average, maximum, minimum), the payload size of the PDU sets and / or data bursts in bits / bytes (e.g., instantaneous, average, maximum, minimum), periodicity, importance / priority, start and end indications of the PDU sets and / or data bursts (e.g., ID of the first PDU / PDU set, ID of the last PDU / PDU set), and dependency information within a PDU set and / or data burst and dependency information across one or more PDU sets and / or data bursts (e.g., indicating whether one or more PDU sets are dependent on each other and / or whether PDU sets in one or more data bursts are dependent and / or whether PDUs in a PDU set are dependent on each other, etc.).

[0118] Other examples of information about traffic characteristics may include the WTRU sending information related to jitter in the UL and / or DL. Such jitter information, which may be sent on a per-flow, per-PDU set, or per-PDU basis, may include, for example, a range, an average, a maximum, and a minimum. In addition, the WTRU may send information about the importance / priority of any data unit (e.g., a PDU, a PDU set, a data burst) to be sent / received in the UL / DL. The WTRU may also receive indications (e.g., from the NW or higher / application layers) about changes in traffic pattern characteristics and / or may send indications upon detecting changes in the UL / DL traffic pattern (e.g., changes in payload size, PDU set size, data burst size, jitter range, periodicity, etc.). In addition, the WTRU can send configuration to the NW via any one or more of RRC signaling and / or NAS messages (e.g., SRB0, SRB1, SRB2, SRB3, SRB4); control PDUs associated with any AS layer in the AS layer (e.g., SDAP control PDU, PDCP control PDU); UL MAC CE (e.g., existing MAC CE, new MAC CE, regular BSR, periodic BSR, enhanced BSR, padding BSR, preemptive BSR, etc.); UCI (e.g., single-bit SR, multi-bit SR, feedback, ACK / NACK, CSI report); PDCCH; PUCCH; non-AS (NAS) layer signaling (e.g., PDU session-related messages); and / or application layer signaling / messages.

[0119] Other common components of the embodiments may include the WTRU receiving configuration information from the network. The WTRU may receive a set of DRBs (e.g., DRB 1, priority of DRB 1, DRB 2, priority of DRB 2) configured by the gNB from the gNB (e.g., in RRC). The WTRU may receive rules / restrictions for mapping DRBs to LCHs and / or mapping DRBs and / or LCHs to resource grants (e.g., CGs) from the gNB, for example. The WTRU may receive a set of LCHs from the gNB (e.g., in RRC), some of which may be configured to handle dependencies. LCH parameters (e.g., BSD, PBR, priority) may apply to all or some of the data units (PDUs and / or PDU sets and / or data bursts) mapped to the LCHs. Further examples include the WTRU receiving LCP configurations and changes to LCP configurations (e.g., LCP restrictions / rules / configurations for handling PDUs / PDU sets / data bursts) from the gNB for a specific duration or indefinitely or until further notice (e.g., a change in LCP configuration). The WTRU may receive an indication from the gNB as to whether these LCP rules may be temporarily relaxed / changed for a duration as to whether they may always be applied. As a further example, the WTRU may receive from the gNB configuration for multiplexing PDUs / PDU sets / data bursts into transport blocks. Still further examples include the WTRU potentially receiving configuration information from the NW via any one or more of RRC signaling and / or messages (e.g., dedicated / unicast signaling via any of SRBs, broadcast / SIBs); control PDUs associated with any of the AS layers (e.g., SDAP control PDUs, PDCP control PDUs); the DL MAC CE, (iv) the downlink assignment index (DCI); PDCCH; PUSCH; non-AS (NAS) layer signaling (e.g., PDU session establishment response or PDU session modification command); and / or application layer signaling / messages.

[0120] In various embodiments, one or more common components may include Figure 3 The information shown in . Figure 3An example of a flow of two PDU sets is shown in process 300, where PDU set delay budgets (PSDBs) are mapped to corresponding quality of service (QoS) flows and then mapped to data radio bearers (DRBs). As shown, PDU set 1 with PSDB 1 is mapped to QoS flow 1 301 and then mapped to DRB 1 302. Another PDU set (PDU set 2) with PSDB 2 is mapped to QoS flow 2 303 and then mapped to DRB 2 304. The diagram conceptually illustrates that two different types of PDU sets (PDU set 1 and PDU set 2) (which differ in that they have different QoS requirements (PSDB 1 and PSDB 2)) can be mapped to different QoS flows and different DRBs. It is further shown that one PDU set 1 and one PDU set 2 can be sent together at time t. There may be one or more PDU sets 1 (with PSDB 1) and one or more PDU sets 2 (with PSDB 2) mapped to QoS flow 1 301 and QoS flow 2 303, respectively, and mapped to DRB 1 302 and DRB 2 304, respectively. These mappings and related examples may be applied to one or more of the methods mentioned herein. In addition, PDU set 1 may refer to PDU set type 1, which may include one or more PDU sets with PSDB 1 requirements. Type 1 here is not limited to the type IPDU set mentioned above. As described herein, PDU set type 1 may be a type IPDU set or a type I IPDU set. PDU set 1 may refer to one or more PDU sets with similar PDU set-level QoS requirements (e.g., the same or similar PSDB 1, PSER1, PSII indication, etc.). Similarly, PDU set 2 may refer to one or more PDU sets with similar PDU set-level QoS requirements (e.g., the same or similar PSDB 2, PSER2, PSII indication, etc.). PDU set 1 can be PDU set type I or PDU set type II. Similarly, for PDU set 2, PDU set 3, etc., they can be PDU set type I or PDU set type II.

[0121] In embodiments related to multiplexing that may involve DRB selection / dynamic change to meet QoS requirements, the mechanism may be applied at the SDAP layer (e.g., by adding one or more new functions at SDAP) or at one or more new or existing layers above or below SDAP. Figure 4A An example of DRB selection / dynamic change that meets QoS requirements is shown in process 400. Figure 4AAs shown, in process 400, PDU set 1 (PSDB 1) and PDU set 2 (PSDB 2) may be dependent PDU sets. PDU set 1 (PSDB 1) may be mapped to QoS flow 1 and then to DRB 1. Similarly, PDU set 2 (PSDB2) may be mapped to QoS flow 2 and then to DRB 2. Figure 4B In the process shown in 420, DRB 1 can be configured for PDU set 1, and DRB 2 can be configured for PDU set 2 (DRB configuration: semi-static). Figure 4B As shown in process 420, the WTRU (e.g., at SDAP or another layer above SDAP) may determine a dependency between PDU Set 1 and PDU Set 2. In process 420, PDU Set 1 and PDU Set 2 may be mapped to respective DRBs 1 and 2.

[0122] Reference again Figure 4A In the process 400 shown, DRB 1 may have a priority of priority 1 and DRB 2 may have a priority of priority 2. Priority 1 may be higher than priority 2. Based on the priority, PDU set 1 may be mapped to DRB 1 and PDU set 2 may be mapped to DRB 2 to ensure that PSDB 1 and PSDB 2 are satisfied and the priority of PSDB 1 and PSDB 2 are satisfied. Figure 4B The process 420 shown is used to ensure that the dependency between PDU Set 1 and PDU Set 2 is maintained. Figure 4A As shown, at 444, PDU set 2 may arrive late (e.g., due to jitter) such that PSDB 2 is approaching. PSDB 2 and the dependency relationship between PDU set 1 and PDU set 2 may no longer be satisfied / maintained using DRB 2. DRB 2 may be given a lower priority than DRB 1 and DRB 3. PDU set 2 may be mapped to DRB 3, which is the next highest priority because PDU set 1 and PDU set 2 are dependent. The WTRU may determine to change the priority of PDU set 2 to maintain PSDB 2 and the dependency relationship by mapping PDU set 2 to DRB 1 through QoS flow 2 or mapping PDU set 2 to another pre-configured DRB 3 through QoS flow 2.

[0123] The WTRU may receive the DRB sets (e.g., first DRB set (DRB 1), DRB priority 1, second DRB set (DRB 2), DRB priority 2) configured by the gNB from the NW or network entity (e.g., in an RRC or other configuration message). The WTRU may receive a first protocol data unit set (PDU set 1) (e.g., from an XR application). The WTRU maps / forwards PDU set 1 to DRB 1 based on the importance or priority of PDU set 1. The WTRU may receive PDU set 2, for example, from the XR application (e.g., PDU set 2 may arrive later than expected). The WTRU may determine information about a dependency associated with the first PDU set and the second PDU set based on information associated with the first PDU set and the second PDU set (e.g., arrival time, data type, etc.). Thus, the information about the dependency may include arrival time or data type. In this example, the WTRU may determine that PDU set 1 and PDU set 2 are dependent. The WTRU may then determine a success rate for the PDUs. The WTRU may determine a new QoS / priority for PDU Set 2 based on QoS requirements, etc., based on the performance / success rate of the first PDU Set and the dependency relationship between the first PDU Set and the second PDU Set. Based on the priority of the first PDU Set and the priority of the second PDU Set, the WTRU may determine to change the priority of PDU Set 2 to ensure QoS and dependency relationship by mapping PDU Set 2 to DRB 1 or mapping PDU Set 2 to another pre-configured DRB (e.g., DRB 3, where the priority of DRB 3 > the priority of DRB 2).

[0124] Figure 4B 4. The mapping between PDU sets (e.g., at the SDAP layer), QoS flows, and DRBs is shown for process 420, process 430, and process 440. A WTRU (e.g., SDAP or a new layer above SDAP) may determine a dependency between PDU set 1 and PDU set 2. Process 420 is described herein. In process 430, PDU set 1 and PDU set 2 may arrive in different QoS flows, and the WTRU may map them to the same DRB according to process 430 to ensure that the newly derived dependency is maintained. As shown in process 440, PDU set 1 and PDU set 2 may each arrive in the same QoS flow A, and the WTRU may map them to the same DRB A.

[0125] In an embodiment, the determination may be performed based on a feedback mechanism / delay relative to the performance / success rate of one data unit. The WTRU may determine the performance / success rate of PDU Set 1 based on the feedback and / or the remaining delay. For example, the WTRU may receive feedback from a network entity (such as a gNB) regarding previously transmitted PDU Set 1. Examples of feedback may be the number of hybrid automatic repeat request (HARQ) / automatic repeat request (ARQ) (re)transmissions or any other feedback from the gNB (e.g., in a PDCP status report, PDCP control PDUs, SDAP control PDUs) to determine the success rate. In another example, the feedback may include information such as an acknowledgement (ACK) regarding the number of successfully received PDUs in the PDU Set and / or a negative ACK (NACK) regarding the number of PDUs to be retransmitted by the WTRU. In another example, the WTRU may send information regarding whether PDU Set 1 transmitted in the UL may be followed by an ACK / NACK feedback indication, wherein the WTRU may expect to receive the ACK / NACK feedback indication from the gNB and / or higher layers (e.g., TCP, RTP) and / or lower layers (e.g., HARQ, ARQ) within a preconfigured time window after transmitting PDU Set 1 in the UL. In another example associated with a similar embodiment in the DL that may be implemented by the NW, the WTRU may send information to the NW, for example, to allow the NW to determine the performance / success rate of PDU Set 1. The WTRU may send information regarding whether data units received in the DL may be followed by an ACK / NACK feedback indication, wherein the WTRU may expect the ACK / NACK feedback indication to be transmitted to the gNB and / or higher layers (e.g., TCP, RTP) and / or lower layers (e.g., HARQ, ARQ) within a preconfigured time window after receiving PDU Set 1 in the DL.

[0126] In a further example of a determination performed based on feedback and / or residual delay relative to the performance / success rate of a data unit, the WTRU may measure the time delay, elapsed time, or residual delay, for example, the absolute time that the data unit has spent in the buffer or the time spent in the buffer relative to the delay budget of the PDU set or data unit (e.g., relative to the PSDB of the PDU set or the PDB of the PDU set). In this example, the PDU set that spent the shortest time in the buffer may be scored or may produce a higher success rate. In addition, the WTRU may determine the performance / success rate of the PDU set as a measure of the percentage of PDUs in the PDU set that were successfully transmitted (e.g., above a percentage threshold). Alternatively, the WTRU may determine the performance / success rate of the PDU set as a measure of the time taken to transmit certain PDUs of the PDU set (e.g., below a delay threshold). In another example, the WTRU may determine the performance / success rate of the PDU set based on the percentage of PDUs transmitted and the time taken to transmit the PDUs. For example, the success rate of a PDU set at a measurement moment (e.g., time instance T) can be determined as the ratio of 1) the percentage of PDUs in the PDU set that are successfully sent until time instance T to 2) the percentage of time relative to the PSDB that the PDUs are successfully sent until time instance T.

[0127] In an embodiment, the determination of the performance / success rate of a PDU set may be statistical or instantaneous. For example, the WTRU may track the performance / success rate of a PDU set based on its performance over a past time window and take these statistics into account when determining to switch the mapping of another PDU set to the DRB of the PDU set. As another example, the WTRU may perform an instantaneous spot check of the performance / success rate of a PDU set.

[0128] In an embodiment, the performance / success rate of a PDU set may be event-triggered. For example, the WTRU may receive a request from the gNB to measure the performance / success rate of a PDU set. As another example, upon registering a relatively low score, a score below a defined threshold, or a high score above a defined threshold for the performance / success rate, the WTRU may perform another check on the PDU set. Furthermore, upon receiving several consecutive NACK indications from the gNB, the WTRU may decide to measure the performance / success rate of the PDU set.

[0129] The WTRU may also receive thresholds from the gNB corresponding to performance / success rates above or below the thresholds. Performance / success rates above the thresholds may be relatively better than performance / success rates below the thresholds. The WTRU may evaluate the performance of the PDU set based on these thresholds when determining whether to change the mapping.

[0130] In an embodiment, a determination may be made relative to the new QoS / priority of a data unit based on the performance / success rate of another data unit and / or a dependency between two data units. In one example, a data unit (e.g., PDU Set 2) may arrive at the WTRU late (e.g., due to jitter) such that its delay budget (e.g., PSDB 2) is almost close. The WTRU may also determine that mapping PDU Set 2 to DRB 2 may not ensure that PSDB 2 is met and some acceleration may be required. The WTRU may also determine a new QoS / priority for a PDU Set (e.g., PDU Set 2) based on the performance / success rate of PDU Set 1. For example, if PDU Set 1 performs well, the WTRU may switch the mapping of PDU Set 2 from DRB 2 to DRB 1. Additionally, for example, if PDU set 1 does not perform well, the WTRU may switch the mapping of PDU set 2 from DRB 2 to another DRB 3 (where DRB 3 has a priority > that of DRB 2). Furthermore, if the WTRU has determined that there may be a dependency between PDU set 1 and PDU set 2 such that PDU set 1 cannot be reconstructed without PDU set 2, and PDU set 1 has a good performance / success rate (above a threshold configured by the gNB), the WTRU may switch the mapping of PDU set 2 from DRB 2 to DRB 1.

[0131] In an embodiment, the selection / change of DRBs may be based on dependencies. The WTRU may initially map / forward PDU set 1 to DRB 1 based on the importance of PDU set 1. The WTRU may also determine to change the priority of PDU set 2 to ensure QoS and dependencies by mapping PDU set 2 to DRB 1 or mapping PDU set 2 to another pre-configured DRB 3 (priority 3 > priority 2).

[0132] In an embodiment for multiplexing, the configuration may involve the LCH being restricted to handling dependencies, which may be considered an NW-assisted embodiment. Figure 5A and 5B An exemplary illustration of this embodiment is shown in FIG. Figure 5ARepresents an option to map a PDU set in a DRB to one or more LCHs according to processes 510 and 520 and processes 530 and 540. Processes 510 and 520 may be an option for mapping a PDU set in a DRB to an LCH. Process 510 shows an example of a 1-to-1 mapping (PDCP maps the PDU set to one LCH). PDU set 1 and PDU set 2 may arrive in different QoS flows (QoS flow 1 and QoS flow 2). The WTRU may map PDU set 1 and PDU set 2 to the same DRB (DRB A). The PDCP may map PDU set 1 and PDU set 2 to one logical channel (LCH A). The MAC may multiplex the PDU sets received over the logical channel LCH A.

[0133] Process 520 illustrates an example of a 1-to-M mapping of PDU sets to LCHs (e.g., PDCP may map PDU sets to more than one LCH). PDU set 1 and PDU set 2 may arrive in different QoS flows (QoS flow 1 and QoS flow 2). The WTRU may map PDU set 1 and PDU set 2 to the same DRB (DRB A). The PDCP may map PDU set 1 and PDU set 2 to different logical channels, LCH A and LCH B. The MAC may multiplex the PDU sets received over the logical channels, LCH A and LCH B.

[0134] Procedures 530 and 540 are another option for mapping a PDU set in a DRB to an LCH. Procedure 530 shows an example of a one-to-one mapping of a PDU set to an LCH (PDCP maps the PDU set to an LCH). PDU set 1 and PDU set 2 may arrive in the same QoS flow (QoS flow A). The WTRU may map PDU set 1 and PDU set 2 to the same DRB (DRB A). PDCP may map PDU set 1 and PDU set 2 to a single logical channel (LCH A).

[0135] Procedure 540 illustrates an example of a 1-to-M mapping of a PDU set to more than one (PDCP maps a PDU set to more than one LCH). PDU set 1 and PDU set 2 arrive in the same QoS flow (QoS flow A). The WTRU may map PDU set 1 and PDU set 2 to the same DRB (DRBA). PDCP may map PDU set 1 and PDU set 2 to different logical channels, LCH A and LCH B.

[0136] exist Figure 5BIn the process 550 and 560, the WTRU may determine that there is a dependency between PDU Set 1 and PDU Set 3. In process 550, PDU Set 1 may be mapped to QoS Flow 1, PDU Set 2 may be mapped to QoS Flow 2, and PDU Set 3 may be mapped to QoS Flow 3. If the parameters (e.g., priority, PBR) of LCH B meet the QoS requirements of the dependent PDU sets (PSDB1, PSDB3), the WTRU may map the dependent PDU sets (PDU Set 1 and PDU Set 3) to the LCH LCB. If there is a conflict between the independent LCH and the restricted dependent LCH during the LCP process, the WTRU may be configured to prioritize the restricted dependent LCH. At process 560, PDU Set 1, PDU Set 2, and PDU Set 3 may be mapped to QoS Flow A. If the parameters of LCH B (e.g., priority, PBR) meet the QOS requirements of the dependent PDU sets (PSDB1, PSDB3), the WTRU may map the dependent PDU sets (PDU set 1 and PDU set 3) to LCH B. If there is a conflict between the independent LCH and the restricted dependent LCH during the LCP procedure, the WTRU may be configured to prioritize the restricted dependent LCH. For example, LCH B may be reserved to handle the dependency. The WTRU may receive the LCH sets (first one or more LCH sets and second one or more LCH sets) configured by the gNB from the NW or network entity (e.g., in RRC), the second one or more LCH sets including one or more LCHs that are restricted to handle dependencies between PDUs (e.g., LCH B). The WTRU may receive the one or more PDU sets, for example, from an XR application. The WTRU may determine information about the dependency requirements of the PDU sets based on information associated with the PDU sets (e.g., arrival time, data type) (e.g., the WTRU may determine that PDU set 1 and PDU set 3 are dependent). Therefore, the dependency requirement may be based on arrival time or data type. If the parameters of LCH B (e.g., priority, prioritized bit rate (PBR) associated with the first and second LCHs) meet the requirements of the dependent PDU set (e.g., PSDB1, PSDB3), the WTRU may map the dependent PDU set to LCH B.

[0137] In case of a conflict between an independent LCH and a restricted dependent LCH during the LCP procedure, the WTRU may be configured to prioritize the restricted dependent LCH and may map the dependent PDU set to LCH B. (Less impact on the PSER.) For example, if the priority of LCH A (independent LCH) is the same or equal to the priority of LCH B (special LCH handling dependency), the WTRU may be configured to prioritize LCH B.

[0138] In an embodiment, the WTRU may receive configuration information from the network, including LCHs for handling dependencies. In one example, the WTRU may receive a set of LCHs configured by the gNB from the NW, for example, in RRC and / or following a request sent from the WTRU to the NW, the LCH set including one or more LCHs for handling dependencies. For UL traffic (generated in the WTRU application), the WTRU may have some knowledge of the (expected) traffic pattern (e.g., for an upcoming time window). The WTRU may send an indication to the network in advance on its traffic pattern, and the network may be able to configure the LCHs accordingly. For example, the WTRU may know the periodicity of upcoming video traffic. The WTRU may send this information to the gNB. The gNB may then configure the LCHs accordingly. In a related example, the WTRU may receive information about its UL traffic and / or the dependencies of upcoming UL traffic (e.g., from an application), or determine information about the dependencies of its UL traffic and / or the dependencies of upcoming UL traffic, and send this information to the gNB. The gNB may then configure one or more logical channels that may be restricted to handling such dependencies. Additionally, the LCHs may be configured to handle the dependencies. The set LCH may have similar parameters as a regular LCH (e.g., PBR, BSD, priority). The set LCH may also have additional parameters related to dependencies. For example, LCH B may be restricted to mapping only I frames and their differential P frames / B frames. The set LCH may be restricted to handling dependencies. For example, an LCH restricted to handling dependencies (e.g., LCH B) is only used to carry dependent PDU sets. For example, if PDU set 1 and PDU set 3 are dependent, they may be mapped to LCH B. As another example, if there are no dependent PDU sets at a given time, an independent PDU set (e.g., PDU set 2, which does not depend on any other PDU set and does not have another PDU set that depends on it) will not be mapped to LCH B even if LCH B is available at that time (e.g., no dependent PDU sets are loaded). In addition, the set LCH may prioritize handling dependencies, but may also map to independent data units in the absence of dependent data units. For example, if there are no dependent PDU sets at a given time, an independent PDU set (e.g., PDU set 2, which does not depend on any other PDU set and does not have another PDU set that depends on it) can be mapped to LCH B, where, in the event that there are other dependent PDU sets (e.g., PDU set 1 and PDU set 3), LCH B will be used to handle the dependent PDU sets.

[0139] As another example of receiving configuration information from the network, upon learning of incoming UL traffic, the gNB may configure a higher number of LCHs and / or LCH parameters (e.g., prioritized bit rate (PBR)) for the corresponding logical channels to accommodate a larger amount of data per LCH (e.g., a higher PBR) and process dependent LCHs. The gNB may configure the LCHs to handle dependencies, such as by limiting processing to only a set of dependent PDUs or by prioritizing processing of a set of dependent PDUs.

[0140] In the case where one or more LCHs may be configured by the gNB to prioritize processing of dependent PDU sets, the configuration information may allow the WTRU to decide whether to use the LCH only for mapping to dependent PDU sets (e.g., restricting its use to processing only dependencies) or to use the LCH also for mapping to independent PDU sets in the absence of dependent PDU sets.

[0141] In another example, the gNB may configure one or more LCHs (e.g., LCH D) to also handle intra-PDU set dependencies (e.g., dependencies between different PDUs in a PDU set), such that each PDU of a PDU set can be mapped to LCH D. In one example, LCH D may be restricted to mapping only to Type IPDU sets, since the dependency requirements are stronger for Type I (e.g., Type IPDU sets cannot tolerate any loss / delay of any PDU in the PDU set, while Type II sets can tolerate some loss / delay and still be reconstructed at the end).

[0142] In another example of receiving configuration information from the network, the gNB may send the WTRU a range of allowed changes that the WTRU can make to LCH parameters. For example, within a DRB, the gNB may configure a range of PBR values ​​for each logical channel mapped to that DRB. The WTRU may be able to adjust / control LCH parameters (e.g., PBR) based on dependency information that the WTRU has determined / received (e.g., from higher layers / application layers). For example, the WTRU may decide whether to use the LCH to strictly handle dependencies to map to a dependent PDU set or to prioritize the dependent PDU set (and also to map to an independent PDU set in the absence of a dependent PDU set).

[0143] In an embodiment, data units may be mapped to an LCH that is configured to handle dependencies. There may be one or more LCHs that are configured by the gNB and sent to the WTRU to handle dependencies (e.g., LCH B sent in RRC). In one example, the WTRU has received information (e.g., from a higher / application layer) or has determined that there is a dependency between PDU Set 1 and PDU Set 3 and has received LCH B from the gNB that is configured to handle the dependency. For example, if the parameters of LCH B (e.g., PBR, BSD, priority) meet the requirements of the dependent PDU sets (e.g., PSDB 1 for PDU Set 1 and PSDB 3 for PDU Set 3), the WTRU may map PDU Set 1 and PDU Set 3 to LCH B. Additionally, if the parameters of LCH B (e.g., PBR, BSD, priority) do not meet the requirements of each dependent PDU set or do not meet the dependency requirements of the PDU sets, for example, the parameters of LCH B may be suitable for PDU Set 3 but not for PDU Set 1, the WTRU may receive configuration information for another LCH C from the network entity. The WTRU may also map PDU Set 1 and PDU Set 3 to LCH C, which may have been configured and sent to the WTRU (e.g., in RRC), with parameters that are appropriate for the requirements of PDU Set 1 and PDU Set 3 and therefore meet the PDU set dependency requirements. If the parameters of LCH B (e.g., PBR, BSD, priority) do not meet the requirements of each dependent PDU set or do not meet the PDU set dependency requirements, for example, the parameters of LCH B may be appropriate for PDU Set 3 but not for PDU Set 1, the WTRU may send an indication to the network entity (e.g., gNB) to request another LCH to be processed with parameters that are appropriate for the requirements of PDU Set 1 and PDU Set 3, wherein the requested another LCH meets the PDU set dependency requirements and is mapped to PDU Set 1 and PDU Set 3 when the new LCH is received. If the parameters of LCH B (e.g., PBR, BSD, priority) do not meet the requirements for each dependent PDU set or do not meet the dependency requirements for a PDU set, for example, the parameters of LCH B may be suitable for PDU set 3 but not for PDU set 1, then the WTRU may determine to map PDU set 1 using a regular LCH (e.g., one or more LCHs for PDU set 1) to ensure that PSDB 1 is met if another LCH requested is not received. For example, if the WTRU does not receive any LCH to handle the dependency requirements for each dependent PDU set, then the WTRU may select this option, either in RRC or in response to a request sent to the gNB to request one.

[0144] In an embodiment, the configuration may include information on how to handle collisions between two different types of LCHs. During the LCP procedure, the WTRU may be configured to prioritize PDUs in one or more LCHs based on normal LCH parameters (e.g., priority, PBR, BSD). In one example, if LCH A (a normal LCH) has a higher priority than LCH B (a LCH configured to handle dependencies), the WTRU may prioritize PDUs / PDU sets mapped to LCH A over PDUs / PDU sets mapped to LCH B. For example, the two LCHs may have similar parameters (e.g., priority, PBR, BSD). In this example, the WTRU may be configured to prioritize LCH B over LCH A, e.g., to add the PDUs / PDU sets mapped to LCH B to the first transport block over the PDUs / PDU sets mapped to LCH A, because any loss / delay of data units mapped to LCH B will have a higher impact on the PDU Set Error Rate (PSER) than any loss / delay of data units mapped to LCH A. Other options for this example might include mapping independent PDU set 2 to LCH A. Dependent PDU set 1 and PDU set 3 to LCH B. The loss / delay of any PDU in PDU set 2 might only affect the reconstruction of PDU set 2, while the loss / delay of any PDU in PDU set 1 or PDU set 3 might affect the reconstruction of both PDU set 1 and PDU set 3, resulting in a greater impact on the PSER.

[0145] In an embodiment, the configuration may include information about dynamic changes to LCH parameters (e.g., PBR, BSD, priority). Within a DRB, the WTRU may dynamically change / control some parameters (e.g., LCH parameters), such as adjusting the PBR of a logical channel based on dependencies. In one example, the WTRU may notify the gNB of the arrival of a large amount of UL traffic. In response, the gNB may configure a higher number of LCHs and / or LCH parameters (e.g., prioritized bit rate PBR) for the corresponding logical channels to accommodate the larger amount of data per LCH (e.g., LCHs with a higher PBR), and send this configuration information to the WTRU (e.g., in RRC). In another example, the WTRU may receive a range of allowed changes that the WTRU can make to the LCH parameters or configuration information from a network entity such as the gNB. For example, within a DRB, the WTRU may be configured with a range of PBR values ​​for each logical channel mapped to the DRB. The WTRU may adjust / control the LCH parameters (e.g., PBR) based on the latest information received or determined by the WTRU regarding the amount of UL traffic. Related to the previous example, the WTRU may adjust configuration information or LCH parameters (e.g., PBR) to accommodate the dependency between two data units or two PDU sets. For example, if the WTRU learns that there is a dependency between PDU set 1 and PDU set 3, the WTRU may increase / raise the PBR of the logical channel carrying PDU set 1 to also accommodate the PDUs of PDU set 3.

[0146] In embodiments, the selection of PDUs used to populate a MAC PDU / transport block may involve consideration of dependencies other than QoS, which may be identified as a Medium Access Control (MAC) embodiment.

[0147] Figure 6 Process 600 is shown, illustrating an example of selecting PDUs to populate a medium access control (MAC) PDU / transport block to account for dependencies other than QoS. Figure 6 An example of a Link Control Protocol (LCP) enhancement is shown in FIG. Figure 6As shown, PDU 2 and PDU 3 in PDU set 1 can be mapped to QoS flow 1, and then the PDUs of QoS flow 1 can be mapped to DRB 1. PDU 1, PDU 2, and PDU 3 in PDU set 2 can be mapped to QoS flow 2. PDU 3 and PDU4 in PDU set 3 can be mapped to QoS flow 3, and then the PDUs of QoS flow 2 and QoS flow 3 can be mapped to the same DRB 2. PDU set 1 has a dependency relationship with PDU set 3. Each DRB can have a corresponding LCH for sending the PDUs in the PDU set to the MAC layer 603. After receiving the PDUs of the PDU set, the MAC layer can multiplex the PDUs for transmission in a transport block. The delay budget of PDU set 1 can be smaller than the delay budget of PDU set 2 (PSDB 1<PSDB 2).

[0148] The delay budget of PDU set 2 may be less than the delay budget of PDU set 3 (PSDB 2 < PSDB 3). LCH 1 may have a higher priority than LCH 2. LCH 2 may have a higher priority than LCH 3. The WTRU may determine that PDU set 1 has a dependency on PDU set 3. At time t1, PDU 1 of PDU set 1 and PDUs 1 and 2 of PDU set 3 may be multiplexed into TB1601. At time t2, the remaining PDUs may be in their respective LCHs, as shown in FIG160. Figure 6 As shown. If the remaining PDUs of PDU Set 3 are not transmitted / delayed, this failure to transmit or delay may not only cause decoding failure of PDU Set 3, but also may cause decoding failure of PDU Set 1 due to the dependency. When multiplexing the PDUs into TB2 602, the WTRU may prioritize the remaining PDUs of PDU Set 3 (PDUs 3 and 4) over PDU Set 2 to maintain the dependency between PDU Set 1 and PDU Set 3, assuming that the priority ordering will not violate PSDB 2. PDUs 2 and 3 of PDU Set 1, PDUs 3 and 4 of PDU Set 3, and PDU 1 of PDU Set 2 may be multiplexed into TB2 602. The WTRU may determine to perform such priority allocation if a certain percentage (X is above a threshold) of the PDUs in PDU Set 3 have been multiplexed. The WTRU may receive the set of LCHs configured by the gNB from the NW (e.g., in RRC), and the configuration parameters include at least the time threshold T. The WTRU receives PDUs from one or more PDU sets (eg, PDU 1 of PDU set 1, PDUs 1, 2 of PDU set 3) from an XR application.

[0149] The WTRU may multiplex the PDUs received from the one or more PDU sets into one or more transport blocks (e.g., PDU 1 of PDU set 1, PDU 1 and PDU 2 of PDU set 3 are multiplexed into TB1 601). In addition, the WTRU may receive multiple PDUs or additional PDUs from the XR application, including the remaining PDUs of the PDU set. The WTRU may determine information about the dependency of one or more PDU sets based on, for example, arrival time, data type (e.g., the WTRU determines that PDU set 1 and PDU set 3 are dependent). Thus, the information about the dependency may include arrival time and data type. The WTRU may determine a remaining delay t for transmitting the remaining PDUs or additional PDUs of the PDU set. The WTRU may compare a time threshold (T) to the delay (t). If t<T, the WTRU considers or applies the priority of the LCH when multiplexing the PDUs into the TBs, for example, the WTRU multiplexes PDU set 2 from LCH 2 onto the remaining PDUs of PDU set 3 (for example, by considering the priority of PDU set 2 and the priority of LCH2), and if t>T, the WTRU considers or applies the priority of the LCH and the dependency or dependency information between PDU sets when multiplexing the PDUs into the TBs (for example, when multiplexing the PDUs into TB2 602, the WTRU prioritizes the PDUs of PDU set 3 over the PDUs of PDU set 2, assuming that this prioritization does not violate the PS PDU 2 of DB set 2).

[0150] In an embodiment, the WTRU may again receive configuration information from the network. For example, the WTRU may receive (e.g., in RRC) a set of LCHs configured by the gNB. The WTRU may have some knowledge of the (expected) traffic pattern for the UL traffic (generated in the WTRU's application). The WTRU may also send an indication to the network in advance on its traffic pattern, and the network may configure the LCHs accordingly. For example, the WTRU may be aware of the periodicity of upcoming video traffic. The WTRU may send this information to the gNB. The gNB may then configure the LCHs accordingly. In one example, upon knowing that a large amount of UL traffic is coming, the gNB may configure a higher number of LCHs and / or LCH parameters (e.g., Prioritized Bit Rate (PBR)) for the corresponding logical channels to accommodate the larger amount of data per LCH (e.g., a higher PBR). In another example, the gNB may send the WTRU (and the WTRU may receive from the gNB or a network entity) a range of allowable changes to the LCH parameters or configuration parameters that the WTRU can make. For example, within a DRB, the gNB may configure a range of PBR values ​​for each logical channel mapped to that DRB. The WTRU may adjust / control LCH parameters (e.g., PBR) based on the latest information the WTRU has about the UL traffic. Related to the previous example, the WTRU may adjust LCH parameters (e.g., PBR) to accommodate a dependency between two data units or PDU sets. For example, if the WTRU learns that there is a dependency between PDU set 1 and PDU set 2, the WTRU may increase / raise the PBR of the logical channel carrying PDU set 1 to also accommodate the PDUs of PDU set 2.

[0151] In one example, the WTRU may receive configuration information related to a time threshold T from the network. In one example, the WTRU may receive the time threshold T from the gNB (e.g., in RRC). The time threshold T may correspond to or may be the maximum time that a data unit (e.g., a PDU or a set of PDUs) may spend in a lower layer buffer (e.g., a MAC buffer). In addition, one time threshold T may be applied to all PDU sets (T PDU集合 ), and another time threshold T can be applied to all PDUs (T PDU ), or there may be several time thresholds T, depending on, for example, or based on the type of data unit or PDU or based on the delay budget of the data unit or PDU. In the above example, the maximum length of time that any PDU set can stay in the lower layer buffer (e.g., MAC buffer) may be T PDU集合. Further, a PDU set may have one or more time thresholds T, for example, an I frame may have one time threshold T, a P frame may have another time threshold T, a B frame may have another time threshold T, and so on. There may be one time threshold T for the first image frame and another time threshold T for the differential frame. As another example, there may be a different time threshold T for each different type of PDU set, or there may be a different time threshold T for each PDU set with a different PDU set delay budget (PSDB). For example, PDU sets L, M, N with PSDB 1 may have a time threshold T1, while PDU sets X, Y, Z with PSDB 2 may have a time threshold T2. Further, there may be a different time threshold T for each QoS flow; a different time threshold T for each DRB; and / or a different time threshold T for each logical channel.

[0152] In the example where the WTRU receives configuration information related to the time threshold T from the network, the WTRU may be configured with a table having different values ​​for the time threshold T for each different type of PDU set or for different arbitrary parameters listed above. Another example may apply if the WTRU does not receive the time threshold T for a data unit from the gNB, the WTRU may estimate what time threshold T to apply based on historical information. For example, the WTRU may apply the same time threshold T for a new I frame as it did for a previous I frame. In a further example, if the WTRU does not receive the time threshold T for a data unit from the gNB, the WTRU may estimate what time threshold T to apply based on information about other similar data units. Additionally, the WTRU may apply the same time threshold T for differential P frames as it does for differential B frames. As an example above, if the WTRU does not receive the time threshold T for a PDU set with PSDB1 (e.g., PDU set 1), it may assign a time threshold T to that PDU set (PDU set 1) similar to that for other PDU sets with PSDB1. In the absence of other PDU sets with PSDB1, the WTRU may find the PDU set with the closest available PSDB to PSDB1. In the presence of more than one other PDU set with PSDB1, the WTRU may use the more stringent time threshold T of the two. In the presence of more than one other PDU set with PSDB1, the WTRU may additionally consider other factors (such as the type of PDU set) when deciding the time threshold T to apply to PDU set 1. For example, if two other PDU sets have PSDB1, one of them may be an I-frame and the other may be a P-frame, and if PDU set 1 is an I-frame, the WTRU may use the time threshold T of the other I-frame PDU set for PDU set 1.

[0153] In another example of receiving configuration information related to a time threshold, for example, if the WTRU does not know this information, the WTRU may send a request to the gNB to request a time threshold T for a data unit. The WTRU may add information about the PDU set (e.g., type of PDU set, PSDB, PDU set importance, etc.) to the request. Another example may include the WTRU receiving a time threshold T from a higher layer / application layer, which is the maximum length of time a data unit (e.g., PDU set, PDU) may be retained in a lower layer buffer (e.g., MAC buffer). In addition, the WTRU may receive this time threshold T for each PDU set (e.g., from a higher / application layer or from the gNB).

[0154] In one example, the WTRU may receive the time threshold T once per DRB (e.g., during RRC from the gNB), and the WTRU may assume that the same time threshold T will be used for all data units mapped to that DRB (unless / until there is a reconfiguration of the DRB).

[0155] In an embodiment, the received configuration information may include a time delay t. The WTRU may determine / calculate / measure a time delay t for each data unit (PDU set and / or PDU). The time delay t may be an absolute value (e.g., corresponding to the amount of time a data unit spends in various buffers in the WTRU), or it may be measured relative to other time metrics (e.g., the PDB for a PDU or the PSDB for a PDU set). In one example, the time delay t may correspond to the amount of time a data unit or PDU or PDU set spends in a WTRU buffer or buffers (e.g., lower layer buffers in the WTRU, such as a MAC buffer, an RLC buffer). There may be one value of t corresponding to the sum of the time a data unit spends in all lower layers of the WTRU (e.g., in a MAC buffer, an RLC buffer, etc.), or there may be different values ​​of t corresponding to the amount of time a data unit spends in each respective buffer (e.g., t MAC , t RLC The WTRU can then use different values ​​(e.g., t MAC , t RLC(e.g., MAC buffer) is added to a sum of the time spent in the WTRU buffer. For example, the time delay t may correspond to the remaining time that a PDU has before it needs to be transmitted to satisfy its PDB. In this regard, the remaining time may be calculated by subtracting the amount of time the PDU has spent in the WTRU buffer (e.g., MAC buffer) from the PDB. The remaining time may also be calculated by subtracting the amount of time the PDU has spent in the WTRU buffer and other time windows (one or more) from the PDB, for example, to compensate for air transmission time and / or the time the PDU spends in a buffer on the receiving side (e.g., gNB buffer).

[0156] Another example of received configuration information includes a time delay, t, which may correspond to the remaining time that a PDU set has to satisfy its PSDB before being transmitted. This remaining time may be calculated by subtracting the amount of time the PDU set has spent in a WTRU buffer (e.g., a MAC buffer) from the PSDB. The remaining time may also be calculated by subtracting the amount of time the PDU set has spent in a WTRU buffer and other time windows (one or more) from the PSDB, for example, to compensate for air transmission time and / or the time the PDU set may spend in a buffer on the receiving side (e.g., a gNB buffer).

[0157] In an embodiment, the received configuration information may include consideration of a delay t for sequential arrival of the PDUs of a PDU set. For example, all PDUs of a PDU set may not arrive at the same time (e.g., due to UL jitter from a codec generating traffic in the WTRU). The PDUs of a PDU set may arrive in two or more batches of PDUs from an application layer in the WTRU (lower layers in the WTRU). Each batch or batch of PDUs may contain one or more PDUs of a PDU set. Lower layers in the WTRU (e.g., AS layer) may need to track arrival times to ensure that subsequent processing of data units still adheres to the corresponding delay budget (e.g., PSDB of a PDU set, PDB of a PDU). Additionally, all PDUs of a PDU set may need to be received at a receiver within the PSDB (at a gNB for UL traffic) to maintain dependencies within the PDU set and / or to maintain the integrity of the PDU set.

[0158] As an example of the foregoing, the WTRU may start a timer when the first PDU of a PDU set arrives at the WTRU's lower layers (e.g., the AS layer) and run the timer until all PDUs of the PDU set arrive at the lower layers. The WTRU timer used to determine the time delay t may correspond to the amount of time from the time the first PDU in the PDU set arrives at the WTRU's lower layers to the time the last PDU in the PDU set arrives at the WTRU's lower layers. In another example, based on the PSDB of the PDU set and the total amount of time one or more PDUs of the PDU set have spent at the WTRU's lower layers (e.g., in the WTRU MAC buffer), the time delay t may correspond to the remaining amount of time that one or more or all PDUs of the PDU set can spend at the WTRU's lower layers (e.g., in the WTRU MAC buffer). In the foregoing example, the time delay t may be calculated by subtracting the amount of time the PDUs of the PDU set have spent in the WTRU buffer (e.g., the MAC buffer) from the PSDB of the PDU set. In the calculation, this may be measured by calculating the time difference between the current calculation time and the time the first PDU in the PDU set arrives at the lower layers. As another example, the time delay t may be calculated by subtracting the amount of time that the PDUs of the PDU set have spent in a WTRU buffer (e.g., a MAC buffer) and other time windows (one or more) from the PSDB of the PDU set, e.g., to compensate for over-the-air transmission time and / or the time that the PDU set may spend in a buffer on the receiving side (e.g., a gNB buffer).

[0159] As a further example, the WTRU may be configured to calculate the time delay t periodically, semi-periodically, or aperiodically. For example, the configured periodicity for calculating the delay t may be the same for all PDU sets, or may be different for different types of PDU sets based on any one or more factors such as the PDU set type, PSDB, PDU set importance, etc. In addition, the WTRU may be configured to calculate t more frequently (e.g., with a higher periodicity) when it has a PDU set with a smaller PSDB in its buffer than a PDU set with a higher PSDB. Still further, the WTRU may be configured to calculate t more frequently (e.g., with a higher periodicity) when it has a PDU set with a higher importance in its buffer than a PDU set with a lower importance. In addition, the WTRU may be configured to calculate t more frequently (e.g., with a higher periodicity) when it has a PDU set corresponding to a first / image frame (e.g., an I-frame) in its buffer than a PDU set corresponding to a differential frame (e.g., a P-frame / B-frame).

[0160] In an embodiment, the received configuration information may include consideration of the time delay t, and the WTRU may consider other parameters during multiplexing of the PDUs of a PDU set into a transport block (TB), such as the magnitude of the time delay t, the magnitude of the time delay relative to a time threshold (T), dependencies between data units, the number / percentage of PDUs in the PDU set that have been multiplexed into a TB or lower layer, etc. In addition to LCH parameters (e.g., priority, PBR, BSD), the WTRU may consider any one or more of the following parameters during multiplexing: the magnitude of the time delay t; the magnitude of the time delay t relative to the time threshold T; and / or dependencies between data units (e.g., between two PDU sets). For example, the WTRU may have determined or may have been informed that there is a dependency between two PDU sets (PDU set 1 and PDU set 3) (inter-PDU set dependency). Additionally, the WTRU may determine or may be informed that there is a dependency between different PDUs of a PDU set (intra-PDU set dependency), and that the PDU set may be a type IPDU set that cannot tolerate any loss / delay of any PDU of the PDU set.

[0161] Other parameters during multiplexing may include one or more of the number / percentage of PDUs in the PDU set that have already been multiplexed / received at a lower layer. As an example, if t < T, the WTRU may only consider LCH parameters (e.g., priority, PBR, BSD) when multiplexing the PDUs of the PDU set into a TB. For example, because the WTRU determines that the time one or more or all PDUs of the PDU set spends in the WTRU buffer (e.g., MAC buffer) does not exceed the maximum amount of time they can spend in the WTRU buffer (e.g., MAC buffer) so that the PSDB of the PDU set can still be satisfied, the WTRU only needs to consider LCH parameters during multiplexing. In another example, if t > T or t quickly approaches T, the WTRU may consider any dependencies between two PDU sets in addition to the LCH parameters (e.g., priority, PBR, BSD) when multiplexing the PDUs of the PDU set into a TB. For example, because the WTRU determines that the amount of time that the PDUs of a PDU set can spend in a WTRU buffer (e.g., a MAC buffer) has been exceeded or is likely to be within a short time window that is exceeded, the WTRU may also consider dependencies between the PDUs of a PDU set or between different PDU sets when multiplexing the PDUs of the PDU set into a transport block. In another example, if the WTRU has determined that a dependency exists between PDU set 1 and PDU set 3, and t > T or t is rapidly approaching T for PDU set 3, then the WTRU may prioritize the PDUs of PDU set 3 over any PDUs of PDU set 2 even if PDU set 2 is mapped to an LCH with a higher priority than PDU set 3. (See, for example, Figure 6 ) In one example, if the WTRU determines that prioritization / acceleration will not violate the PSDB of PDU set 2, then the WTRU may perform such priority processing / acceleration of the PDUs of PDU set 3 relative to the PDUs of PDU set 2.

[0162] For example, if the WTRU has determined that there is a dependency between PDU Set 1 and PDU Set 3, and t > T or t is rapidly approaching T for PDU Set 3, and the first PDUs of PDU Set 3 have been multiplexed into a TB, then the WTRU may prioritize the remaining PDUs of PDU Set 3 over any PDUs of PDU Set 2, even though PDU Set 2 may be mapped to an LCH with a higher priority than PDU Set 3. (Again, see e.g. Figure 6 ) In one example, if the WTRU determines that prioritization / acceleration will not violate the PSDB of PDU set 2, then the WTRU may perform such priority processing / acceleration of the PDUs of PDU set 3 relative to the PDUs of PDU set 2.

[0163] For example, if the WTRU has determined that there is a dependency between PDU Set 1 and PDU Set 3, and t > T or t is rapidly approaching T of PDU Set 3, and the first batch of PDUs of PDU Set 3 has been multiplexed into a TB, and the number of PDUs in the first batch > N, where N may have been pre-configured by the gNB, the WTRU may prioritize the remaining PDUs of PDU Set 3 over any PDUs of PDU Set 2, even though PDU Set 2 may be mapped to an LCH with a higher priority than PDU Set 3. In one example, if the WTRU determines that prioritization / acceleration does not violate the PSDB of PDU Set 2, the WTRU may perform such preferential processing / acceleration of the PDUs of PDU Set 3 relative to the PDUs of PDU Set 2.

[0164] In an embodiment, the received configuration information may include consideration for dynamic changes to LCH parameters (e.g., prioritized bit rate adjustments). Within a DRB, the WTRU may dynamically change / control some parameters, such as adjusting the PBR based on dependencies. In one example, the WTRU may notify the gNB of the arrival of a large amount of UL traffic. In response, the gNB may configure a higher number of LCHs and / or LCH parameters (e.g., prioritized bit rate, PBR) for the corresponding logical channel to provide a larger amount of data per LCH (e.g., higher PBR). In another example, the gNB may send the WTRU a range of allowed changes that the WTRU can make to the LCH parameters. For example, within a DRB, the gNB may configure a range of PBR values ​​for each logical channel mapped to the DRB. The WTRU may adjust / control the LCH parameters (e.g., PBR) based on the latest information the WTRU has about the UL traffic. In the aforementioned example, the WTRU may adjust the LCH parameters (e.g., PBR) to accommodate the dependency between two data units. For example, if the WTRU learns that there is a dependency between PDU set 1 and PDU set 3, the WTRU may increase / increase the PBR of the logical channel carrying PDU set 1 to also accommodate the PDUs of PDU set 3.

[0165] In the following embodiments, the term PDCP refers to the Packet Data Convergence Protocol entity / layer in the WTRU, or any new entity / layer in the WTRU that performs the task of delivering / discarding data units. It is assumed that similar / corresponding entities / layers may exist at the gNB in ​​the network.

[0166] In an embodiment, a discard mechanism enhancement may be provided when PDUs in a PDU set arrive simultaneously. Figure 7 A process 700 is shown that illustrates an example of an enhancement to a discard mechanism that discards PDUs when PDUs in a PDU set arrive simultaneously. Figure 7As shown, there may be two types of PDU sets (e.g., Type I and Type II as described herein). Type I PDU set cannot tolerate loss / delay exceeding a threshold for any PDU of the PDU set. When one or more PDUs are lost or delayed above a threshold, the remaining PDUs may be discarded. Type I PDU set can tolerate some loss / delay exceeding a threshold. The XR application can reconstruct the PDU set if some PDUs in the PDU set are delayed / lost. The WTRU may receive XR data, such as PDU set 1, from the XR application. The XR data may include one or more PDUs from one or more PDU sets. The WTRU may identify the data type (e.g., Type I or Type II) associated with the XR data (e.g., PDU set 1) and / or detect or mark PSII or identify the data type with processing information for the indicated data type.

[0167] The PDUs of PDU Set 1 may be transmitted to the Service Data Adaptation Protocol (SDAP) 701. The PDUs of PDU Set 1 may be transmitted via PDCP 1 704 and RLC 1 708. The gNB may receive one or more PDUs of PDU Set 1. For example, RLC 1 and / or PDCP 1 may receive one or more PDUs of PDU Set 1. In response to successfully receiving the PDUs in PDU Set 1, the gNB may transmit a status report (e.g., ACK) to the WTRU indicating successful delivery of PDU Set 1. If one or more PDUs of PDU Set 1 are not received in RLC 1 709 and / or PDCP 1 705, the gNB may send a status report (e.g., NACK) to the WTRU indicating unsuccessful delivery of PDU Set 1. In response to the status report (e.g., NACK) indicating unsuccessful delivery of PDU Set 1, the WTRU may discard dependent PDU Set 2. For example, PDCP 1 704 may send an indication to PDCP 2 703 to discard PDUs of PDU Set 2 before transmission via RLC 2 707. The gNB may be unable to receive PDU Set 2 at RLC 2 710, PDCP 2 706, and / or SDAP 702.

[0168] The WTRU may retransmit one or more PDUs in a PDU set (e.g., PDU set 1). The WTRU may retransmit the PDUs or XR data of a PDU set if the duration for retransmitting the data units is still valid or if the PDCP timer(s) (e.g., PDU timer(s) or PDU set timer(s)) for the PDU set (e.g., PDU set 1) is still running. If the PDCP timer(s) (e.g., PDU timer(s) or PDU set timer(s)) for the XR data units has expired and the data type of PDU set 1 is PDU set type II, the WTRU may fall back to discarding any remaining PDUs of PDU set 1. If the PDCP timer(s) (e.g., PDU timer(s)) or duration or PDU set timer(s) for the XR data unit has expired and the data type of the PDU set is PDU set type 1, the WTRU may discard the XR data unit (e.g., a copy of PDU set 1 or the remaining PDUs of PDU set 1), and / or the WTRU may instruct the dependent PDCP entity to discard each dependent XR data unit (e.g., PDU set 2). If the dependent PDUs set in the dependent PDCP entity (e.g., PDCP 2 703) have been submitted to the lower layers (e.g., WTRU RLC entity 2 707), the WTRU (e.g., PDCP 2 703) may send a discard indication to the lower layers (e.g., RLC 2 707) to avoid SN gaps. If the dependent PDCP entity is within a network entity (e.g., gNB), the WTRU may signal an indication to the network entity to discard the dependent XR data associated with the XR data. If the dependent PDCP entity is within the WTRU, the WTRU may signal an indication to the WTRU to discard the dependent XR data associated with the XR data.

[0169] In an embodiment of the discard mechanism, a successfully delivered PDU / PDU set may be Figure 8 Execute the process as shown. Figure 8A process 800 is shown illustrating an exemplary discard mechanism with an extension of an SDU-based status report to a PDU-set-based successful delivery of a PDU / PDU set. A status report may be sent from a receiver (e.g., a receiving PDCP entity in a network) to a transmitter (e.g., a transmitting PDCP entity in a WTRU) to confirm successful delivery of a PDU. Such a status report may be on a per-PDU basis. There may be a status report transmitted from the receiver to the transmitter to indicate the delivery status of a PDU set (e.g., one status report per PDU set). The delivery status may include successful or unsuccessful delivery or delayed delivery of the PDU set. The WTRU may receive XR data, such as PDU set 1, from an XR application. For example, the XR data may be received at an SDAP 801 and prepared for transmission via the WTRU's PDCP 803 and RLC 805. The WTRU may transmit the XR data in the UL to the gNB. The gNB may receive one or more PDUs of the XR data via the RLC 806 and / or PDCP 804 to provide to the SDAP 802. The gNB may prepare a status report indicating the successful (e.g., ACK) or unsuccessful (e.g., NACK) delivery or reception of one or more PDUs in the XR data. If the WTRU receives a status report at the gNB indicating successful delivery of the XR data, the WTRU (transmitter side) may discard its copy of the set of successfully delivered PDUs after receiving the status report from the gNB (receiver side).

[0170] In an embodiment, the WTRU may detect a flag for PDU set processing or identifying a data type. The concept of a PDU set may include processing and delivering a group of PDUs that belong to one PDU set. Some PDU sets may tolerate some loss and / or delay of one or more PDUs in the PDU set that is above a threshold, for example, an XR application may still reconstruct the PDU set in the event of a delay / loss of one or more PDUs in the PDU set. In the present disclosure, such a PDU set may be referred to as a type I IPDU set. Other PDU sets (referred to herein as type IPDU sets) may not tolerate the loss / delay of PDUs in the PDU set below a threshold, for example, an XR application may not tolerate the delay / loss of any PDU in the PDU set below a threshold. If there is a delay / loss of any PDU in the PDU set, the remaining PDUs in the PDU set may be discarded.

[0171] In one example, the XR application typically determines whether reconstruction of a PDU set may occur with some loss / delay, so the XR application may mark the PDU set as Type I or Type II. The marking may be done at the NAS layer or the AS layer (e.g., SDAP). This information may be passed down / relayed to lower layers so that the lower layers (e.g., PDCP) may adjust the processing of the PDU set accordingly (e.g., discard). In another example, this information may be added to each PDU set (e.g., as a tag in the header of each PDU set), and the lower layers in the WTRU (e.g., PDCP) may read this information. The XR data may include a tag indicating the data type of the XR data. In another example, this information may be added to one PDU set, and the lower layers may assume that similar information applies to all subsequent PDU sets (e.g., all subsequent PDU sets without a tag are of the same type as the one PDU set with the tag) until a PDU set with a different tag reaches the lower layers.

[0172] In other examples, the type of PDU set and the number of subsequent PDU sets of the same type (e.g., N) may be marked in the header of a first PDU set. Upon receiving / reading the header of this first PDU set, the lower layers may provide similar processing to the N subsequent PDU sets without spending time reading the headers of the subsequent N PDU sets. Furthermore, this information may be sent separately as metadata to the lower layers in the WTRU (e.g., SDAP, PDCP, RLC, MAC, any new layers in the protocol stack). Additionally, a type of PDU set may carry a flag (e.g., a one-bit flag) that identifies the type. For example, only a type IPDU set may carry a flag that indicates that the XR application cannot tolerate any loss / delay of any PDU in the PDU set.

[0173] In another example, a first type IPDU set may carry a flag indicating its type. Lower layers may assume that subsequent PDU sets are also type I, and further, the WTRU may assume that PDU sets with a certain importance are of a certain type. For example, the WTRU may assume that any PDU set with an importance value greater than a certain preset value (e.g., >8 on an importance or priority level of 1-10, where 10 is the most important) is a type IPDU set, and therefore cannot tolerate PDU loss / delay above a threshold (e.g., threshold 1) in the PDU set. The importance of the PDU set may be determined by the XR application and conveyed to the WTRU in-band (e.g., in the header of the PDU set) or in separate signaling (e.g., metadata signaling).

[0174] In another example, an application may define parameters for the use of PDUs that are set at the application. The parameter may be, for example, a PDU set QoS parameter that may indicate a preferred treatment of the PDU set at lower layers, such as a PSII (PDU Set Integration Indication) that indicates whether all PDUs are required for use of the PDU set at the application. The parameter may be binary (e.g., PDUs are required without any loss / delay or without requirement) or more fine-grained (e.g., a specific number / percentage of PDUs of a PDU set is required at the application to reconstruct the PDU set). The parameter may be signaled to lower layers by a marking of the PDU set (e.g., an in-band marking in the header) or by separate signaling (e.g., signaling dedicated to metadata on the PDU set).

[0175] In an embodiment, one PDCP discard timer or multiple PDCP discard timers may be provided. In the PDCP framework, there may be one discard timer associated with each PDCP service data unit (SDU). When the discard timer of the PDCP SDU expires, or the successful delivery of the PDCP SDU is confirmed by a PDCP status report, the transmitting PDCP entity discards the PDCP SDU together with the corresponding PDCP data PDU. In the case where the XR traffic consists of one or more PDUs in a PDU set and one or more PDU sets in a data burst, and there is a dependency between the constituent PDUs in the PDU set or between the constituent PDU sets in the data burst, when configuring the PDCP discard timer, one or more of the following aspects may be considered. In one example, there may be a PDCP discard timer that operates according to the PDCP SDU, wherein the expiration or duration of the timer for retransmitting XR data takes into account or is based on the packet delay budget (PDB) of a single PDU. This configuration means that each PDU set corresponds to multiple PDCP discard timers. In another example, there may be one PDCP discard timer or duration for retransmitting XR data that operates on a per PDCP SDU basis, and in this configuration, the expiration of each constituent timer for each PDU set takes into account or is based on the PSDB of the PDU set (instead of the PDB of an individual PDU). This configuration means that there are multiple PDCP discard timers per PDU set, all of which have expiration times corresponding to the PSDB of the PDU set. In another example, there may be one PDCP discard timer that operates on a per PDCP SDU basis, and in this configuration, if the PDUs of the PDU set do not all arrive at the WTRU at the same time, then PDCP discard timers of different lengths (taking into account the PSDB) are applied to the SDUs of the same PDU set so that they all expire at the same time. For example, the first batch of PDUs of a PDU set (arriving at time t1) may have a larger discard timer expiration time value than the second batch of PDUs of the PDU set (arriving at time t2, where t2>t1). Further, there may be one PDCP discard timer that operates on a per PDU set basis, which takes into account the PSDB of the PDU set.

[0176] In an embodiment, more than one configuration is possible. For example, the gNB may configure whether the PDCP discard timer operates per PDCP SDU or per PDCP PDU set. In another example, the WTRU may determine which option to use (PDCP discard timer operated per PDCP SDU or per PDCP PDU set) and / or how to configure the expiration timer value (PDB based on a single PDU or PSDB based on a PDU set or PSDB based on a PDU set with increment / decrement based on the time of arrival at the WTRU) based on whether all PDCP SDUs belonging to the PDU set arrive simultaneously or in an interleaved manner.

[0177] As used herein, a PDCP discard timer for an XR data unit is used to describe a discard timer per PDCP SDU or per PDU aggregate according to any one or more of the above options and examples.

[0178] In an embodiment, the WTRU discard behavior may be based on a discard timer. The discard behavior at the WTRU (e.g., at the PDCP layer in the WTRU) may be based on a PDU or on a PDU set. In addition, for each SDU of a PDU set, there is a discard timer corresponding to each PDCP SDU. For example, each PDCP SDU is discarded when its respective discard timer expires (whether the discard timer is based on a single PDB for the PDU / PDCP SDU or based on the PDU set delay budget (PSDB) of the PDU set of which it is a part). In addition, there may be a discard timer available for each PDU set. For example, when the discard timer expires or when the first batch of PDUs is retransmitted, the transmitting PDCP entity (e.g., a WTRU for UL traffic) discards any PDU in the PDU set that was not successfully transmitted. In the presence of a discard timer associated with each PDCP SDU and a discard timer associated with a PDU set, the WTRU may determine which of the two conditions is to be prioritized (e.g., whichever is smaller, the PDB or the PSDB).

[0179] In an embodiment, the WTRU discard behavior is based on factors other than the expiration of the discard timer of the data unit (e.g., dependent on the discard timer of the data unit, data type, etc.). In addition to the discard timer value, the discard behavior at the WTRU (e.g., at the PDCP layer in the WTRU) may be based on the data type or any indication from a higher layer / application layer on the preferred handling of the XR data unit. The behavior may be configured at an entity (e.g., a PDCP entity) of any AS layer in the WTRU (e.g., the PDCP layer in the WTRU) or at an entity of a layer in the WTRU. An example of such a layer may be an existing layer or a layer between the SDAP and PDCP layers in the WTRU, which may be common to multiple PDCP entities in the WTRU. The WTRU discard behavior of a data unit (e.g., PDU Set 1) may be a function of any one or more of the following. The discard timer(s) for the data unit has expired or is within a small preconfigured expiration time window. For example, the discard timer associated with PDU Set 1 has expired or is within a small preconfigured expiration time window. Additionally, the discard timer(s) of the component(s) of the data unit have expired or are within a small preconfigured expiration window. For example, the discard timer(s) of one or more PDUs of PDU Set 1 have expired or are within a small preconfigured expiration window. Additionally, the discard timer(s) of the dependent data units have expired or are within a small preconfigured expiration window of expiration. For example, the discard timer(s) of the dependent PDU Set 1 and / or the PDU Set 2 upon which PDU Set 1 depends have expired or are within a small preconfigured expiration window of expiration.

[0180] In an embodiment, a status report may be provided to indicate one or more of successful delivery of an XR data unit, successful delivery of a dependent XR data unit, successful delivery of another XR data unit on which the XR data unit depends, unsuccessful delivery of an XR data unit, unsuccessful delivery of a dependent XR data unit, and unsuccessful delivery of another XR data unit on which the XR data unit depends. For example, the WTRU may discard an XR data unit or a copy of an XR data unit if the PDCP discard timer(s) for the XR data unit has expired or is within a small preconfigured expiration time window and / or data type = PDU set type 1 (e.g., the application cannot reconstruct the PDU set in the event of any PDU delay / loss). The XR data unit may be an entire PDU set or some PDUs in a PDU set. In addition, if the PDCP discard timer(s) for the XR data unit has expired and / or the data type of the XR data unit = PDU set type 1 and / or the WTRU (e.g., a transmitting PDCP entity in the WTRU) may receive a status report from the gNB (e.g., a receiving PDCP entity in the gNB) indicating unsuccessful delivery of the XR data unit and / or there is a dependency between the XR data unit and another XR data unit (e.g., another PDU set mapped to a different DRB / PDCP entity), the WTRU may send an indication to one or more PDCP entities with the dependent data unit to discard all copies of the dependent data unit. In another example, the WTRU may determine a dependency between PDU set 1 and PDU set 2 such that PDU set 2 may be useless without PDU set 1. For example, PDU set 1 may be an I-frame and PDU set 2 may be a differential P-frame / B-frame. If the PDCP discard timer(s) for PDU set 1 has expired and the WTRU (e.g., PDCP) has received a status report of PDU set type 1 from the gNB indicating unsuccessful delivery of one or more PDUs of PDU set 1 and the data type of PDU set 1 is PDU set type 1 that cannot tolerate any loss / delay of any PDU of the PDU set for successful reconstruction of the PDU set, then the WTRU (e.g., transmitting PDCP entity 1 carrying copies of PDU set 1) may send an indication to PDCP entity 2 (carrying copies of PDU set 2) to discard all copies of PDU set 2 and / or any PDU of PDU set 2 because PDU set 2 depends on the successful reconstruction of PDU set 1.

[0181] In another example, if a dependent PDU set has been submitted to a lower layer (e.g., a WTRU RLC entity), the WTRU (e.g., a PDCP entity) may send a discard indication to the lower layer (e.g., an RLC entity) to avoid any gaps in the sequence numbering. In this example, if a dependent PDU set 2 has been submitted from PDCP entity 2 to RLC entity 2, PDCP entity 2, upon receiving an indication from PDCP entity 1 that the discard timer(s) for PDU set 1 have expired and one or more or all of the PDUs of PDU set 1 were not successfully delivered to the gNB, may send an indication to RLC entity 2 to avoid any gaps in the sequence numbering. After receiving the indication at RLC entity 2 from PDCP entity 2, RLC entity 2 may send an indication to the gNB or to lower layers indicating that PDU set 2 is no longer useful. The indication may also include the cause (e.g., due to unsuccessful delivery of some or all of PDU set 1, or due to unsuccessful reconstruction of PDU set 1 due to some or more or all of the PDUs of PDU set 1 being delayed / lost).

[0182] In an embodiment, there may be a layer / entity in the WTRU that is common to multiple PDCP entities. An example of such a layer may be a layer between the SDAP and PDCP layers in the WTRU, which may be common to multiple PDCP entities in the WTRU. For example, in a model where each type of PDU set may be mapped to a different DRB (and therefore a different PDCP entity), and there is a dependency between two or more such different PDU sets (mapped to different PDCP entities), a common layer above the existing PDCP entities may exist. For example, the common layer may (i) have visibility of all dependent PDU sets and the PDCP entities to which they are mapped, (ii) send indications to all PDCP entities with dependent PDU sets to inform them of the dependency, (ii) receive indications (e.g., status reports) from the gNB indicating successful, unsuccessful delivery of data units and / or an indication to discard any data unit or dependent data unit, (iii) send indications to all PDCP entities with dependent PDU sets to inform them of the successful / unsuccessful delivery indication from the gNB, (iv) may process one or more discard timers and / or have visibility of discard timers at one or more PDCP entities, (v) determine the dependency between data units (e.g., between PDU set 1 and PDU set 2), and (vi) send discard indications to the PDCP entities to discard the dependent data units (e.g., sending a discard indication to PDCP2 to discard set 2 after a status report from the gNB indicating unsuccessful delivery of set 1).

[0183] In any of the above embodiments and examples, after discarding the dependent PDU set, the WTRU may send an indication to the gNB (e.g., the corresponding PDCP entity in the gNB) to inform the gNB of the discard. The indication may include a means of identifying the discarded PDU set and / or any context associated with the discarded PDU set (e.g., sequence number, ordinal number, etc.). In one example, the WTRU may determine that PDU set 1 and PDU set 2 are dependent. If the discard timer(s) for PDU set 1 have expired and PDU set 1 was not successfully delivered to the gNB, the WTRU may discard PDU set 2 (e.g., the WTRU may have received a status report from the gNB indicating unsuccessful delivery of PDU set 1 or a request from the gNB to resend PDU set 1).

[0184] In an embodiment, a discard mechanism enhancement may be applied when PDUs in a PDU set arrive out of sequence. Figure 9 A process 900 is shown illustrating an example of a discard mechanism for out-of-sequence arrival of PDUs of a PDU set at a PDCP entity. The PDUs of the PDU set sent from the RLC 901 may be based on one or more PDUs of the PDU set received and one or more PDUs of the PDU set not received. Each of the six PDUs of PDU set 1 may be received at the PDCP 903 and transmitted via the RLC 901 of the WTRU. PDU set 1 may be received within the PSDB 904 via the RLC 902 at a receiver (e.g., a gNB) to maintain dependencies within the PDU set. The transmitting PDCP 903 may send each PDU in PDU set 1 within tA and tA < PSDB1. The transmitting PDCP 903 may send each PDU within tA' and tA' ≤ tA. tA may include the time at which the transmitting PDCP entity 903 may have to send the PDUs of PDU set 1 to satisfy PSDB1. When PDUs 1, 2, 3 are received at t1 (t1 < tA') and PDUs 4, 5, 6 have not yet been received, the WTRU may take different actions. If the WTRU receives a retransmission indication for PDUs 1, 2, 3 from the receiving entity (gNB), then the WTRU may determine not to retransmit PDUs 1, 2, 3 if PDUs 4, 5, 6 have not yet been received at the WTRU, even if the PDCP timer at the WTRU is still running. If PDUs 4, 5, 6 have not yet been received at the WTRU, the PDCP 903 at the WTRU may discard the copies of PDUs 1, 2, 3 at approximately tA; even if the WTRU has not received a status report (from the gNB) confirming the successful delivery of PDUs 1, 2, 3 at the receiving end. t AMay include the time at which the transmitting PDCP entity 903 must send PDUs of PDU Set 1 (e.g., to lower layers in the WTRU) to satisfy PSDB1. A' The time by which the transmitting PDCP entity 903 must receive (e.g., from the application layer in the WTRU) the PDUs of PDU Set 1 to satisfy PSDB1 may be included, such that t A' ≤t A In addition, the first batch of PDUs: for example, PDUs 1, 2, and 3 of PDU set 1 received at time t1, t1 < t A' The remaining PDUs: for example, PDUs 4, 5, and 6 of PDU set 1 received at time t2, where t2 < t1.

[0185] As an example, the WTRU may receive the first batch of PDUs of a PDU set from the XR application at time t1, where t1 < t A' The WTRU transmits a first batch of PDUs of the PDU set in the UL to a network entity. The WTRU may receive a retransmission indication for the first batch of PDUs from the gNB from the network entity (e.g., the receive PDCP entity 904 at the gNB). If the WTRU has received the remaining PDUs of the PDU set before tA′ and the PDCP timer(s) for the first batch of PDUs of the PDU set is still running, the WTRU transmits the remaining PDUs of the PDU set in the UL, and the WTRU retransmits the first batch of PDUs after the retransmission indication from the gNB. If the WTRU has not received the remaining PDUs of the PDU set before tA′, the WTRU determines not to retransmit the first batch of PDUs of the PDU set, even if the PDCP timer(s) for the first batch is still running. The WTRU may determine to discard the first batch of PDUs of the PDU set, and the WTRU may send an indication to the gNB (the receive PDCP entity 904 at the gNB) that the first batch of PDUs of the PDU set will not be retransmitted (to avoid any gaps in sequence numbering). Additionally, if the WTRU has no remaining PDUs, the WTRU may include the reason why no retransmission was performed despite the retransmission indication from the gNB (failure to receive the remaining PDUs of the PDU set on time).

[0186] In an embodiment, there may be timing considerations for the sequential arrival of the PDUs of a PDU Set. For example, each PDU of a PDU Set may not arrive at the same time (e.g., due to UL jitter from a codec generating traffic in the WTRU). The PDUs of a PDU Set may arrive from the application layer in the WTRU (to the lower layers in the WTRU) in two or more batches of PDUs. Each batch or batch of PDUs may contain one or more PDUs of the PDU Set. The lower layers in the WTRU (e.g., the AS layer) may need to track the arrival time to ensure that subsequent processing of the data units still adheres to the corresponding delay budget (e.g., PSDB for PDU Set, PDB for PDU). Each PDU of a PDU Set may need to be received at a receiver (at a gNB for UL traffic) within the PSDB to maintain dependencies within the PDU Set and / or to maintain the integrity of the PDU Set. The transmitting entity in the WTRU (e.g., the transmitting PDCP entity) may need to ensure that the PDUs of the PDU Set are received within the time constraint t A Each PDU in the PDU set is sent within t A <PSDB of the PDU set. In addition, in order to be able to A To send each PDU in the PDU set within a time constraint t, the transmitting entity in the WTRU (e.g., the transmitting PDCP entity) may need to A' Each PDU in the PDU set is received within t A' ≤t A If the PDUs of a PDU set arrive at the WTRU sequentially (e.g., from an XR application), the WTRU may assign different time constraints by which each batch may need to be received. For example, if PDU batches 1, 2, and 3 of the same PDU set arrive at times t1, t2, and t3, respectively, where t1 < t2 < t3, the WTRU (e.g., the transmitting PDCP entity) may assign time constraints by which each batch may need to be transmitted to lower layers to ensure that each PDU can be delivered in time, for example, PDU batches 1, 2, and 3 may need to be received at time intervals t1, t2, and t3, respectively. x , t y and t z is transmitted, where t z <t y <t x .

[0187] In an embodiment, the WTRU may determine not to resend a batch of PDUs of a PDU set despite a resend request from the gNB instructing the WTRU to do so. As an example, despite receiving a request / indication from the gNB to resend some data units (e.g., the remaining PDUs of the PDU set), if the WTRU knows that the other data units (e.g., the other PDUs of the PDU set) cannot be transmitted within the time constraint (e.g., the PSDB of the PDU set), then the WTRU may determine not to resend them. If the WTRU believes that the remaining PDUs of the PDU set are within t A' If the data unit cannot be reached by the WTRU (e.g., lower layers / AS layers in the WTRU) within t1, the WTRU may determine to discard the data unit (partial PDU of the PDU set). In one example, the WTRU (e.g., a PDCP entity at the WTRU) may receive some partial data units (e.g., PDUs 1, 2, and 3 of PDU set 1) at time t1, where t1 < t A' , with this time limit, the transmitting PDCP needs to receive the PDUs of the PDU set to ensure that the PSDB is satisfied. The WTRU knows the size of the entire data unit (e.g., PDU set 1 has a total of 6 PDUs) and the type of data unit (e.g., PDU set 1 is a type IPDU set, so the application cannot tolerate any loss / delay of any PDU of the PDU set). In another example, the WTRU may transmit the portion of the data unit it has already received (e.g., PDUs 1, 2, 3 of PDU set 1) to the gNB without waiting for the remaining PDUs of the PDU set (e.g., PDUs 4, 5, 6 of PDU set 1). In another example, if the WTRU may receive a retransmission indication from the gNB to retransmit the data units it has already transmitted (e.g., PDUs 1, 2, 3 of PDU set 1) while the discard timer(s) for these data units (e.g., PDUs 1, 2, 3 of PDU set 1) are still running, if the remaining data units of the PDU set (e.g., PDUs 4, 5, 6 of PDU set 1) have not been received at the WTRU (e.g., from the XR application) and t A' has passed or is rapidly approaching, the WTRU may decide not to resend them (and / or discard) PDUs 1, 2, 3 of PDU Set 1. The WTRU may determine that it receives t A' The remaining PDUs in PDU Set 1 and the WTRU can ASince it is unlikely that PDUs 4, 5, and 6 will be transmitted to and received by the gNB in ​​a timely manner, and since PDU Set 1 is a type of IPDU set that cannot tolerate any loss / delay of any PDU, the WTRU may determine not to resend PDUs 1, 2, and 3 of PDU Set 1 despite a request from the gNB and / or even though the discard timers corresponding to PDUs 1, 2, and 3 have not expired.

[0188] In another example where the WTRU determines not to retransmit a batch of PDUs of a PDU set, where the WTRU has determined not to retransmit a batch of data units to the gNB despite having received a request to do so from the gNB and the PDCP timer(s) for the batch of data units may still be running (as described above), the WTRU may send an indication to the gNB (e.g., a receiving PDCP entity at the gNB) to avoid any gap in any sequence numbering at the gNB and any unnecessary delay in resolving the gap. The indication sent by the WTRU to the gNB may include one or both of the following: an indication that a batch of PDUs of a PDU set (e.g., the first batch of PDUs in PDU Set 1, PDUs 1, 2, 3) will not be retransmitted, and a reason why retransmission is not being performed despite the retransmission request from the gNB, e.g., failure to receive the remaining PDUs of the PDU set in a timely manner means that the PDU set cannot be reconstructed. For example, due to the fact that PDUs 4, 5, 6 of PDU Set 1 were not received at the WTRU (e.g., from the application layer) within tA'.

[0189] In another example, upon receiving the first batch of data units that are part of a larger data unit (e.g., upon receiving PDUs 1, 2, 3 of PDU set 1), knowing the size of the larger data unit (e.g., PDU set 1 has a total of 6 PDUs) and the type of the larger data unit (e.g., PDU set 1 is a type of IPDU set that cannot tolerate any loss / delay of any PDU of the PDU set), the WTRU (e.g., the transmitting PDCP entity in the WTRU) may decide / determine to wait until it receives each data unit of the larger data unit (e.g., PDUs 1, 2, 3, 4, 5, 6 of PDU set 1) before transmitting them to lower layers, and therefore to the gNB. In this case, if the WTRU receives the first batch of data units at t A' No data unit is received as part of a larger data unit (any of PDUs 1-6) within t A'If the transmitting PDCP entity must receive PDUs of PDU Set 1 (e.g., from the application layer in the WTRU) to satisfy the PSDB for PDU Set 1, the WTRU may determine not to send any data units that it may receive. A' If the WTRU receives PDUs 1, 2, 3, 4, and 5 of PDU Set 1 within t , the WTRU may not transmit PDUs 1, 2, 3, 4, and 5 of PDU Set 1 until PDU 6 of PDU Set 1 is received. A' If the WTRU does not receive PDU 6 of PDU Set 1 within 10 seconds, the WTRU discards each PDU of PDU Set 1. Assume that the WTRU knows that PDU Set 1 is of type IPDU Set.

[0190] In an embodiment, there may be one PDCP discard timer or multiple PDCP discard timers for each PDU set. In the case of XR traffic consisting of one or more PDUs in a PDU set and one or more PDU sets in a data burst, and there is a dependency between the constituent PDUs in the PDU set or between the constituent PDU sets in the data burst, when configuring the PDCP discard timer, one or more of the following aspects may be considered. For example, there may be a PDCP discard timer that operates in accordance with PDCP SDUs, wherein the expiration of the timer takes into account the packet delay budget (PDB) of a single PDU. Therefore, whether the time for retransmitting the first batch of PDUs has not expired may be based on the packet delay budget (PDB) of each PDU. This configuration means that there are multiple PDCP discard timers for each PDU set. In another example, there may be a PDCP discard timer that operates in accordance with PDCP SDUs, and in this configuration, the expiration of each constituent timer of each PDU set takes into account the PSDB of the PDU set (instead of the PDB of a single PDU). Therefore, whether the time for retransmitting the first batch of PDUs has not expired may be based on the PDU set delay budget (PSDB) of the PDU set. This configuration means that there are multiple PDCP discard timers per PDU set, each discard timer having an expiration time corresponding to the PSDB of the PDU group. In another example, there may be a PDCP discard timer that operates on a per-PDCP SDU basis, and in this configuration, if not all of the PDUs of a PDU set arrive at the WTRU at the same time, then PDCP discard timers of different lengths (taking into account the PSDB) are applied to the SDUs of the same PDU set so that they each expire at the same time. For example, the first batch of PDUs of a PDU set (arriving at time t1) may have a larger discard timer expiration time value than the second batch of PDUs of the PDU set (arriving at time t2, where t2>t1). Furthermore, there may be a PDCP discard timer that operates on a per-PDU set basis, which takes into account the PSDB of the PDU set.

[0191] In further examples where there is one PDCP discard timer or multiple PDCP discard timers per PDU set, more than one configuration is possible. For example, the gNB may configure whether the PDCP discard timer is operated per PDCP SDU or per PDCP PDU set. Furthermore, the WTRU may determine which option to use (PDCP discard timer operated per PDCP SDU or per PDCP PDU set) and / or how to configure the expiration timer value (PDB based on a single PDU or PSDB based on a PDU set or PSDB based on a PDU set with increment / decrement based on the time of arrival at the WTRU) based on whether each PDCP SDU belonging to the PDU set arrives simultaneously or in an interleaved manner.

[0192] As discussed herein, the term PDCP discard timer for XR data units is used to describe the discard timer per PDCP SDU or per PDU aggregate, as discussed in the options above.

[0193] In an embodiment of an enhanced discard method, the WTRU discard behavior may be based on a discard timer. For example, the discard behavior at the WTRU (e.g., at the PDCP layer in the WTRU) may be based on a per-PDU or per-PDU set basis. Thus, for each SDU of a PDU set, each PDCP SDU may have a discard timer or a time for retransmitting the first batch of PDUs. For example, each PDCP SDU is discarded when its respective discard timer expires (whether the discard timer is based on a single PDB for the PDU / PDCP SDU or based on the PSDB of the PDU set of which it is a part). In addition, each PDU set may have a discard timer. For example, when the discard timer of a PDU set expires, the transmitting PDCP entity (e.g., a WTRU for UL traffic) discards any PDU of the PDU set that has not been successfully transmitted. In the presence of a discard timer or a duration for retransmitting the XR data associated with each PDCP SDU and a discard timer associated with the PDU set of which the PDCP SDU / PDU is a part, the WTRU may determine which of the two conditions is more stringent (e.g., the smaller of the PDB or PSDB).

[0194] In an embodiment, the WTRU discard behavior may be based on factors other than the expiration of a discard timer for a data unit (e.g., dependency, data type, number / percentage of PDUs in a PDU set that have been received / multiplexed into a TB / transmitted in the UL at lower layers in the WTRU, the remaining number of PDUs in a PDU set that have not been received at lower layers in the WTRU, a discard timer for a dependent data unit, etc.). The discard behavior for a PDU set may be based on dependency, data type, a number of received PDUs in a PDU set, or a second batch of received PDUs in a PDU set. For example, in addition to the discard timer value of one or more PDCP discard timers, the discard behavior at the WTRU (e.g., at the PDCP layer in the WTRU) may be based on other factors, such as the discard timer value of another dependent data unit, the data type of the data unit, or any indication from a higher / application layer regarding preferred handling of the XR data unit. The behavior may be configured at an entity (e.g., a PDCP entity) of any AS layer (e.g., a PDCP layer in the WTRU) in the WTRU or at an entity of a layer in the WTRU. An example of such a layer may be a layer between the SDAP and PDCP layers in the WTRU, which may be common to multiple PDCP entities in the WTRU. In addition, the WTRU discard behavior of a data unit (e.g., PDU Set 1) may be a function of one or more elements. For example, the discard timer(s) of the data unit may have expired or are within a small pre-configured expiration time window. For example, the discard timer associated with PDU Set 1 may have expired. For example, the discard timer associated with PDU Set 1 may be within less than 5 ms of expiration. In another example, the discard timer associated with PDU Set 1 may be within a very short expiration time. For example, a shorter expiration time may mean a duration corresponding to 10% of the discard timer value, and / or a duration corresponding to 15% of the PSDB value, etc. In another example, the discard timer of one or more components of the data unit may have expired or are within a short pre-configured expiration time window, for example, the discard timer of one or more PDUs of PDU Set 1 may have expired, or PDU Set 1 has a total of 6 PDUs. The lower layers in the WTRU receive PDUs 1, 2, and 3 but have not yet received PDUs 4, 5, and 6. The WTRU may also discard PDUs 1, 2, and 3 if the discard timer for any one or more of PDUs 4, 5, and 6 expires and the WTRU has not yet received PDUs 4, 5, and 6. In another example, PDU Set 1 has a total of 6 PDUs. The lower layers in the WTRU receive PDUs 1, 2, and 3 but have not yet received PDUs 4, 5, and 6.The WTRU may also discard PDUs 1, 2, 3 if the discard timer of the PSDB corresponding to the PDU set expires and the WTRU has not received PDUs 4, 5, 6.

[0195] In an embodiment, the discard timer of the dependent data unit may expire or may be within a small pre-configured expiration time window. For example, the discard timer of the dependent PDU set 1 and / or the PDU set 2 on which the PDU set 1 depends has expired. Additional options include: a status report indicating successful delivery of the XR data unit; a status report indicating successful delivery of a dependent XR data unit, a status report indicating successful delivery of another XR data unit on which the XR data unit depends, a status report indicating unsuccessful delivery of the XR data unit, a status report indicating unsuccessful delivery of a dependent XR data unit, a status report indicating unsuccessful delivery of another XR data unit on which the XR data unit depends, and any combination of one or more of the above;

[0196] As an example above, if the PDCP discard timer(s) for an XR data unit has expired or is within a small preconfigured expiration time window and / or the data type = PDU set type 1 (e.g., the application cannot reconstruct the PDU set in the event of any PDU delay / loss), the WTRU may discard the XR data unit or a copy of the XR data unit. The XR data unit may be an entire PDU set or some PDUs in a PDU set. In another example, if the PDCP discard timer(s) for an XR data unit has expired or is within a small preconfigured expiration time window and / or the data type of the XR data unit = PDU set type 1 and / or the WTRU (e.g., a transmitting PDCP entity in the WTRU) has received a status report from the gNB (e.g., a receiving PDCP entity in the gNB) indicating unsuccessful delivery of the XR data unit and / or a dependency relationship exists between the XR data unit and another XR data unit (e.g., another PDU set mapped to a different DRB / PDCP entity), the WTRU may send an indication to one or more PDCP entities with dependent data units to discard each copy of the dependent data unit. Whether the duration for retransmitting XR data has expired may be based on a dependent data unit or data type, so that the WTRU may determine a dependency between PDU Set 1 and PDU Set 2 such that PDU Set 2 may be useless without PDU Set 1. For example, PDU Set 1 may be an I-frame and PDU Set 2 may be a differential P-frame / B-frame. If the PDCP discard timer(s) for PDU Set 1 have expired and the WTRU (e.g., PDCP) has received a status report from the gNB indicating unsuccessful delivery of one or more PDUs of PDU Set 1, and the data type of PDU Set 1 is PDU Set Type 1 that cannot tolerate any loss / delay of any PDU of the PDU Set for successful reconstruction of the PDU Set, the WTRU (e.g., transmitting PDCP entity 1 carrying copies of PDU Set 1) may send an indication to PDCP entity 2 (carrying copies of PDU Set 2) to discard each copy of PDU Set 2 and / or any PDU of PDU Set 2, since PDU Set 2 depends on the successful reconstruction of PDU Set 1.

[0197] In an embodiment, if a dependent PDU / PDU set has been submitted to a lower layer (e.g., a WTRU RLC entity), the WTRU (e.g., a PDCP entity) may send a discard indication to the lower layer (e.g., an RLC entity) to avoid any gaps in the sequence numbering. Thus, if a dependent PDU set 2 has been submitted from PDCP entity 2 to RLC entity 2, PDCP entity 2, upon receiving an indication from PDCP entity 1 that the discard timer for PDU set 1 has expired and one or more or all of the PDUs of PDU set 1 were not successfully delivered to the gNB, may send an indication to RLC entity 2 to avoid any gaps in the sequence numbering. Furthermore, upon receiving the indication at RLC entity 2 from PDCP entity 2, RLC entity 2 may send an indication to the gNB or to lower layers to indicate that PDU set 2 is no longer useful. The indication may also include the cause (e.g., due to unsuccessful delivery of some or all of the PDUs of PDU set 1, or due to unsuccessful reconstruction of PDU set 1 due to some or more or all of the PDUs of PDU set 1 being delayed / lost). As an example, if PDUs 1, 2, 3 of PDU set 1 have been submitted to the lower layers (e.g. RLC entity), but PDUs 4, 5, 6 of PDU set 1 have not yet reached the WTRU, and the discard timers of PDUs 4, 5, 6 and / or the discard timer of PDU set 1 have expired or are within a small pre-configured expiration time window, the WTRU may send an indication to the lower layers (RLC entity) to inform it to discard PDUs 1, 2, 3 of PDU set 1 (to avoid any gaps in the sequence numbering).

[0198] Example embodiments for multiplexing may include DBR selection / dynamic change to meet QoS requirements. The WTRU may receive the DRB sets (e.g., DRB1, priority of DRB1, DRB2, priority of DRB2) configured by the gNB from the NW (e.g., in RRC). The WTRU may receive PDU set 1, for example, from an XR application. In addition, the WTRU maps / forwards PDU set 1 to DRB1 based on the importance of PDU set 1. The WTRU may receive PDU set 2, for example, from an XR application (e.g., PDU set 2 may arrive later than expected). The WTRU determines information about the dependency based on, for example, arrival time, data type (e.g., the WTRU determines that PDU set 1 and PDU set 2 are dependent), etc. The WTRU may also determine the success rate (statistical or instantaneous) of PDU set 1 based on feedback and / or residual delay. The WTRU also determines the QoS / priority of PDU set 2 based on the performance / success rate of the first PDU set. The WTRU may determine to change the priority of PDU Set 2 to ensure QoS and dependencies by (i) mapping PDU Set 2 to DRB 1 or (ii) mapping PDU Set 2 to another pre-configured DRB 3 (priority 3 > priority 2).

[0199] Another exemplary embodiment for multiplexing may involve configuring the LCH to be restricted to processing dependencies, which may be considered a network-assisted embodiment. The WTRU may receive, for example in RRC, from the NW, a LCH set configured by the gNB, which includes one or more LCHs that are restricted to processing dependencies (e.g., LCH B). The WTRU then receives, for example, one or more PDU sets from an XR application. The WTRU determines information about the dependencies based on, for example, arrival time, data type. (E.g., the WTRU determines that PDU set 1 and PDU set 3 are dependent). If the parameters of LCH B (e.g., priority, PBR) meet the requirements for the dependent PDU set (PDU set delay budget (PSDB), e.g., PSDB1, PSDB3), the WTRU may map the dependent PDU set to LCH B. In the event of a conflict between an independent LCH and a restricted dependent LCH during the LCP process, the WTRU may be configured to prioritize the restricted dependent LCH, which may result in a reduced impact on the PSER. As an example, if the priority of LCH A (legacy LCH) is the same as the priority of LCH B (special LCH for processing dependency), the WTRU may be configured to prioritize LCH B.

[0200] Another exemplary embodiment for multiplexing may involve selecting PDUs to fill a MAC PDU / transport block to take into account dependencies other than QoS, which may be considered a MAC embodiment. The WTRU may receive a set of LCHs configured by the gNB and a time threshold T from the NW, for example in RRC. The WTRU may receive PDUs from one or more PDU sets (e.g., PDU 1 of PDU set 1, PDUs 1 and 2 of PDU set 3) from an XR application. The WTRU multiplexer may receive the PDUs into a transport block. (e.g., PDU 1 of PDU set 1 is multiplexed with PDUs 1 and 2 of PDU set 3 into TB1). In addition, the WTRU may receive more PDUs from the XR application, including the remaining PDUs of the PDU set. The WTRU determines information about the dependencies based on, for example, arrival time, data type, etc. (e.g., the WTRU determines that PDU set 1 and PDU set 3 are dependent). The WTRU determines a remaining delay t for transmitting the remaining PDUs of the PDU set. If t < T, the WTRU considers the priority of the LCH during multiplexing of the PDUs into the TB (e.g., the WTRU multiplexes PDU set 2 from LCH 2 instead of the remaining PDUs of PDU set 3). Thus, the determination may be based on the priority of the PDU set and the priority of the LCH. If t > T, the WTRU considers the priority of the LCH and the dependencies between the PDU sets during multiplexing of the PDUs into the TB (e.g., as an example, the WTRU prioritizes PDUs of PDU set 3 over PDUs of PDU set 2 when multiplexing the PDUs into TB 2, assuming that this prioritization does not violate PSDB 2 (PSDB for PDU set 2)).

[0201] In a variation of the above multiplexing embodiment, within DRB2, the WTRU may dynamically change / control some parameters, such as adjusting (increasing) the PBR based on dependencies.

[0202] An exemplary embodiment of a discard mechanism enhancement may be applied when PDUs in a PDU set arrive simultaneously. This step may include the WTRU receiving XR data, such as PDU set 1, from an XR application. The WTRU detects a flag for PSII or identifying the data type. The WTRU transmits the XR data to the gNB in ​​the UL. The WTRU receives a status report from the gNB indicating a NACK, such as retransmitting some or all PDUs of the PDU set (e.g., PDU set 1). If a PDCP timer (e.g., a PDU timer or PDU set timer(s) of the PDU set (e.g., PDU set 1)) is still running, the WTRU retransmits the PDUs of the PDU set. If the PDCP timer(s) (e.g., a PDU timer(s) or PDU set timer(s) of an XR data unit) has expired and the data type = PDU set type II, the WTRU may fall back to discarding any remaining PDUs of PDU set 1. For example, if the PDCP timer(s) for an XR data unit has expired and the data type = PDU set type I, (i) the WTRU may discard the data unit (e.g., a copy of PDU set 1 or the remaining PDUs of PDU set 1), (ii) the WTRU may instruct the dependent PDCP entity to discard each dependent XR data unit (e.g., PDU set 2), and (iii) if the dependent set in the dependent PDCP entity (e.g., PDCP 2) has been submitted to the lower layer (e.g., WTRU RLC entity), the WTRU (e.g., PDCP 2) may send a discard indication to the lower layer (e.g., RLC 2) to avoid SN gaps.

[0203] In another exemplary embodiment of the discard mechanism, when a PDU / PDU set is successfully delivered, the steps may include the WTRU receiving XR data (e.g., PDU set 1) from an XR application, the WTRU transmitting the XR data in the UL to the gNB, and if the WTRU receives a status report at the gNB indicating successful delivery of the XR data, the WTRU (transmitter side) discarding a copy of the successfully delivered PDU set after receiving the status report from the gNB (receiver side). A status report may be sent from a receiver (e.g., a receiving PDCP entity in the network) to a transmitter (e.g., a transmitting PDCP entity in the WTRU) to confirm the successful delivery of the PDU. Such a status report may be on a per-PDU basis. There may be a status report transmitted from the receiver to the transmitter to indicate the delivery status of the PDU set (e.g., one status report per PDU set). The delivery status may include successful or unsuccessful delivery or delayed delivery of the PDU set.

[0204] Another exemplary embodiment of a discard mechanism enhancement may be applied when the PDUs in the PDU set arrive out of sequence. The process may include the WTRU at time t1 (t1 < t A' ) receives the first batch of PDUs of the PDU set from the XR application. The WTRU transmits the first batch of PDUs of the Transmission PDU set in the UL. The WTRU receives a retransmission indication for the first batch of PDUs from the gNB (e.g., the receiving PDCP entity at the gNB). If the WTRU A' If the WTRU has previously received the PDUs of the PDU set and the PDCP timer(s) for the first batch of PDUs of the PDU set are still running, then (i) the WTRU transmits the remaining PDUs of the PDU set in the UL, and (ii) the WTRU may retransmit the first batch of PDUs following a retransmission indication from the gNB. A' The remaining PDUs of the PDU set were not previously received: (i) the WTRU determines not to retransmit the first batch of PDUs of the PDU set even if the PDCP timer(s) for the first batch are still running, and (ii) the WTRU sends an indication to the gNB (the receiving PDCP entity at the gNB) that the first batch of PDUs of the PDU set will not be retransmitted (to avoid any gaps in the sequence numbering). Additionally, the WTRU may include an indication as to why the retransmission is not proceeding despite receiving the retransmission indication from the gNB (failure to receive the remaining PDUs of the PDU set on time).

[0205] In another exemplary embodiment, when the PDUs in the PDU set arrive sequentially, the discard mechanism enhancement may be applied, and the WTRU may receive the PDUs at time t1 (t1 < t A' ) Step of receiving PDUs 1, 2, 3 of PDU Set 1 from the XR application. The WTRU may then transmit PDUs 1, 2, 3 of PDU Set 1 in the UL. The WTRU may then receive a retransmission indication for PDUs 1, 2, 3 of PDU Set 1 from the gNB. If the WTRU A' If the WTRU receives PDUs 4, 5, and 6 before the WTRU receives PDUs 4, 5, and 6, it may transmit PDUs 4, 5, and 6 of PDU Set 1 in the UL and retransmit PDUs 1, 2, and 3 of PDU Set 1. A' If PDUs 4, 5, and 6 were not previously received, the WTRU may determine not to retransmit PDUs 1, 2, and 3 of PDU Set 1 and may send an indication to the gNB that PDUs 1, 2, and 3 of PDU Set 1 will not be retransmitted. Similarly, the WTRU may include an indication as to why the retransmission is not to be performed.

[0206] The terms and concepts disclosed herein may include those not disclosed or described in standard documents, and therefore the concepts and terms herein are not meant to be limited to how such terms are used in existing standards. Instead, these standards are cited to the extent necessary to provide background references for understanding.

[0207] The processes and methods described herein may be applied in any combination, may be applied to other wireless technologies, and may be used for other services. The WTRU may reference an identifier of a physical device, or may reference an identifier of a user, such as an identifier associated with a subscription (e.g., MSISDN, SIP URI, etc.). The WTRU may reference an application-based identifier, such as a user name that may be used by each application.

[0208] The above process may be implemented in a computer program, software, and / or firmware incorporated into 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 via a wired connection and / or a wireless connection) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as CD-ROM disks and / or digital versatile disks (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured to: receiving, from a network entity, a configuration for a first set of data radio bearers (DRBs) and a second set of DRBs; receiving a first set of protocol data units (PDUs) from an extended reality (XR) application; Mapping the first PDU set to the first DRB set based on a priority of the first PDU set; receiving a second set of PDUs from the XR application; determining, based on information associated with the first PDU set and the second PDU set, information about a dependency relationship related to the first PDU set and the second PDU set; determining a priority of the second PDU set based on a quality of service (QoS) requirement and the dependency relationship between the first PDU set and the second PDU set; as well as Based on the priority of the first PDU set and the priority of the second PDU set, the second PDU set is mapped to the first DRB set or the second DRB set.

2. The WTRU of claim 1 , further comprising: Feedback regarding the first set of PDUs is received from the network entity.

3. The WTRU of claim 2, wherein the QoS requirement is based on a performance or success rate of the first PDU set.

4. The WTRU of claim 2 , wherein the feedback comprises information regarding a first number of PDUs in the first PDU set that were successfully received or a second number of PDUs to be retransmitted by the WTRU.

5. The WTRU of claim 3, wherein the performance of the first PDU set is statistical, instantaneous, or event-triggered.

6. The WTRU of claim 3, wherein the success rate of the first PDU set is based on the feedback or residual delay.

7. The WTRU of claim 6, wherein the residual delay is a time spent in a buffer relative to a delay budget of the first PDU set or a packet delay budget (PDB) for the first PDU set.

8. The WTRU of claim 3, wherein the success rate of the first PDU set is a measure of a percentage of PDUs in a PDU set that are transmitted above a percentage threshold.

9. The WTRU of claim 3, wherein the performance or the success rate of the first PDU set is a function of both a percentage of the first PDU set transmitted and a time taken to transmit the first PDU set.

10. The WTRU of claim 1, wherein the information regarding the dependency includes an arrival time or a data type.

11. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving, from a network entity, a configuration for a first set of data radio bearers (DRBs) and a second set of DRBs; receiving a first set of protocol data units (PDUs) from an extended reality (XR) application; Mapping the first PDU set to the first DRB set based on a priority of the first PDU set; receiving a second set of PDUs from the XR application; determining, based on information associated with the first PDU set and the second PDU set, information about a dependency relationship related to the first PDU set and the second PDU set; determining a priority of the second PDU set based on a quality of service (QoS) requirement and the dependency relationship between the first PDU set and the second PDU set; as well as Map the second PDU set to the first DRB set or the second DRB set.

12. The method according to claim 11, further comprising: Feedback regarding the first set of PDUs is received from the network entity.

13. The method of claim 12, wherein the QoS requirement is based on performance or success rate of the first PDU set.

14. The method of claim 12, wherein the feedback includes information regarding a first number of successfully received PDUs in the first PDU set or a second number of PDUs to be retransmitted by the WTRU.

15. The method of claim 13, wherein the performance of the first PDU set is statistical, instantaneous, or event-triggered. The method of claim 13 , wherein the success rate of the first PDU set is based on the feedback or residual delay.

17. The method of claim 16, wherein the residual delay is a time spent in a buffer relative to a delay budget of the first PDU set or a packet delay budget (PDB) for the first PDU set.

18. The method of claim 13, wherein the success rate of the first PDU set is a measure of a percentage of PDUs in a PDU set that are transmitted above a percentage threshold.

19. The method of claim 13, wherein the performance or the success rate of the first PDU set is a function of both a percentage of the first PDU set transmitted and a time taken to transmit the first PDU set.

20. The method according to claim 11, wherein the information about the dependency relationship includes arrival time or data type.

Images