XR methods for supporting fine-grained QOS differentiation

Abstract

Systems, methods, and means are disclosed herein for an XR method to support fine-grained QoS differentiation. A WTRU may receive a delay threshold associated with one or more PDU sets. The WTRU may determine PDU delay information associated with the PDU set, where the PDU delay information may include a remaining delay amount associated with a delay boundary of the PDU set. The WTRU may select one or more logical channels for the PDU set. The WTRU may determine a logical channel prioritization (LCP) configuration associated with the selected logical channel based on the delay threshold and the PDU delay information, e.g., by comparing the PDU delay information to a delay threshold. The WTRU may transmit the PDU set using the determined LCP configuration. Transmitting the PDU set may include prioritizing one or more of the PDUs of the PDU set over PDUs of a higher priority logical channel.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Application No. 63 / 309,193, filed February 11, 2022, U.S. Provisional Application No. 63 / 335,293, filed April 27, 2022, U.S. Provisional Application No. 63 / 395,547, filed August 5, 2022, and U.S. Provisional Application No. 63 / 410,755, filed September 28, 2022, the entire contents of which are incorporated by reference herein. [Background technology]

[0002] The term extended reality (e.g., eXtended Reality, or XR) is an umbrella term for different types of immersive experiences that may include, for example, Virtual Reality (VR), Augmented Reality (AR), and / or Mixed Reality (MR), and realities interpolated between them. Virtual reality (VR) is a rendered version of a delivered visual and auditory scene. The rendering may be designed to mimic as naturally as possible the visual (e.g., stereoscopic 3D) and auditory stimuli of the real world to the observer or user as the observer or user moves within limits defined by the application. Augmented reality (AR) is when a user is provided with additional information or artificially generated items or content overlaid on the current environment. Mixed reality (MR) is an advanced form of AR where some virtual elements are purposefully inserted into a physical scene to provide the illusion that these elements are part of the real scene. XR can include one or more real and virtual combined environments and human-machine interactions generated by computer technology and wearables.

[0003] The concept of immersion in the context of XR applications / services can refer to providing a sense of being surrounded by, and physically and spatially located within, a virtual environment. The level of virtualization can range from partial sensory input to fully immersive multi-sensory input leading to a virtual reality that may be virtually indistinguishable from actual reality.

[0004] XR devices may be associated with the ability to provide varying degrees of spatial tracking. XR devices may be equipped with various sensors that enable spatial tracking, such as, for example, monocular / stereo / depth cameras, radio beacons, GPS, inertial sensors, etc. Spatial tracking may be performed at various levels, (e.g., 3 degrees of freedom (DoF)), (e.g., rotational movement along X, Y, and Z axes) or 6DoF (e.g., rotational and / or translational movement along X, Y, and Z axes). Spatial tracking may result in some form of interaction to experience virtual content. A user may act within and / or interact with components within the extended reality. For example, actions and / or interactions may include movement, gestures, eye tracking, etc. Spatial tracking may be a key enabler of an immersive XR experience. For example, some form of head and / or motion tracking may ensure that simulated visual and audio components from the user's perspective are updated to match the user's movements. Inaccurate and / or delayed spatial tracking may result in discomfort and / or a feeling of motion sickness for the user.

[0005] The wireless transmit / receive unit (WTRU) can correspond to any XR device / node, which may come in various form factors. 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 camera(s), wearables, etc. In addition to the above, several different types of XR WTRUs may be envisioned based on XR device capabilities, such as display, camera, sensors, sensor processing, wireless connectivity, XR / media processing, and power, provided by one or more devices, wearables, actuators, controllers, and / or accessories. One or more devices / nodes / WTRUs may be grouped into a collaborative XR group to support one or more XR applications / experiences / services. Summary of the Invention

[0006] A wireless transmit / receive unit (WTRU) can map packet data units (PDUs) of application data units (ADUs) in different quality of service (QoS) flows to level 2 (L2) transmission configurations. For example, the WTRU can perform mapping of PDu's of ADUs in different QoS flows to transmission configurations (e.g., DRBs and / or LCHs) based on a buffer occupancy threshold and / or an application indication (e.g., an importance value) in the PDUs.

[0007] The WTRU may receive (e.g., in RRC) a configuration including one or more transmission configurations (e.g., DRB and / or LCH), each of which may be associated with one or more buffer occupancy thresholds. The WTRU may receive one or more PDUs belonging to an ADU in one or more associated QoS flows. The WTRU may determine an expected amount of data when mapping PDUs from the QoS flows to a first transmission configuration. If the expected amount of data in the first transmission configuration is greater than the associated buffer occupancy threshold, the WTRU may send an indication (e.g., a medium access control (MAC) control element (CE)) to the network upon triggering of a buffer overload event, receive an indication from the network to split the QoS flows and other AS layer status, determine a first set of PDUs and a second set of PDUs in the QoS flows based on the application importance indication (e.g., spatial importance) in the PDUs and the network / AS layer indication, and send the first set of PDUs in the QoS flows to the first transmission configuration and send the second set of PDUs in the QoS flows to the second transmission configuration. If the expected amount of data in the first transmission configuration is not greater than the associated buffer occupancy threshold, the WTRU may transmit the PDUs in the QoS flow in the first transmission configuration. After receiving a resource grant, the WTRU may transmit the PDUs in the transmission configuration in the uplink (UL).

[0008] The WTRU may implement one or more methods for handling a QoS surge event. The WTRU may switch between mapping configurations (e.g., from a mapping configuration that ensures to meet the average QoS to another mapping configuration that ensures to meet the surge QoS) for mapping PDUs from QoS flows to transmission configurations based on detection of a QoS surge event.

[0009] The WTRU may receive a configuration (e.g., in RRC) including one or more mapping configurations including a first mapping configuration (e.g., may be activated) and a second mapping configuration (e.g., may be deactivated), one or more transmission configurations (e.g., DRB and / or LCH), which may each be configured with parameters for achieving an average QoS (e.g., average data rate with latency constraint), and / or a threshold associated with a maximum increase in QoS for the first mapping configuration. The WTRU may receive one or more PDUs belonging to an ADU in one or more associated QoS flows. The WTRU may apply the first mapping configuration to map the PDUs from the QoS flows to the transmission configurations. If an event indication is received and / or detected (e.g., i.e., there is a QoS surge event expected for a certain duration), the WTRU may determine an expected increase in QoS (e.g., an amount of QoS surge) based on the achievable QoS using the first mapping configuration and information in the event indication. If the expected QoS increase is greater than a threshold, the WTRU may send an indication to the network (e.g., MAC CE) to request activation of a second mapping configuration and information about the event (e.g., the amount of QoS increase and the surge event duration), receive an activation indication for the second mapping configuration, transmit a PDU using the activated second mapping configuration to the forwarding configuration for the surge event duration, and transmit a PDU using the first mapping configuration after expiration of the surge event duration. If the expected QoS increase is not greater than a threshold, the WTRU may transmit a PDU using the first mapping configuration to the forwarding configuration. The WTRU may transmit a PDU in the forwarding configuration in the uplink (UL) after receiving a resource grant.

[0010] The WTRU may perform one or more methods for supporting differentiated QoS with application awareness during data transmission. The WTRU may transmit assistance / status information associated with XR / application awareness to the network. The WTRU may receive configuration / assistance information from the network to support differentiated QoS. The WTRU may detect and / or receive triggering events / conditions for supporting differentiated QoS at the WTRU. The WTRU may determine association of PDUs to ADUs based on explicit or implicit indications and / or parameters. The WTRU may perform mapping of PDUs associated with ADUs in different QoS flows to transmission configurations. The WTRU may switch between different mapping configurations to map PDUs of ADUs to transmission configurations. The WTRU may determine a transmission configuration for transmitting PDUs of ADUs while ensuring that ADU level latency requirements are met. The WTRU may decide to change priority handling procedures / configurations to address the QoS event. The WTRU may change configuration parameters in the PHY and MAC layers for transmitting PDUs / ADUs when detecting a triggering event / condition. The WTRU may be configured with one or more sublayers / entities in the access stratum to handle delivery of PDUs at the granularity of PDU sets. For example, a PDU set may include one or more PDUs associated with a (e.g., one) unit of information generated in an application and subject to a per-PDU set level of quality of service (QoS). The WTRU may change CG / SPS configuration parameters and / or select a CG / SPS configuration to (re)align with data transmission / reception. The WTRU may be configured to handle different types of PDU sets. The WTRU may be configured with LCP restrictions for handling PDU sets. The WTRU may determine the LCP configuration to apply to support the traffic attributes and QoS of the PDU set.

[0011] The WTRU may receive configuration information including a delay threshold associated with one or more PDU sets. Each of the one or more PDU sets may include multiple PDUs. The WTRU may determine PDU delay information associated with a PDU set of the one or more PDU sets. The PDU delay information may include a delay amount (e.g., a remaining delay amount) associated with a delay boundary of the PDU set. The WTRU may select one or more logical channels for the PDU set. The WTRU may determine a logical channel prioritization (LCP) configuration associated with the selected logical channel based on the delay threshold and the PDU delay information. For example, the LCP configuration may include a logical channel restriction for the logical channel associated with the PDU set. Alternatively, the LCP configuration may include one or more LCP parameters for the at least one logical channel, where the one or more LCP parameters may include a prioritization of the multiple PDUs of the PDU set relative to one or more PDUs of a second PDU set. The WTRU may transmit the PDU set using the determined LCP configuration.

[0012] The WTRU may determine the LCP configuration by comparing the PDU delay information to a delay threshold. For example, the WTRU may select a first LCP configuration as the LCP configuration if the delay information is less than or equal to the delay threshold and select a second LCP configuration if the delay information is greater than the delay threshold. Transmitting the PDU set using the first LCP configuration may include prioritizing one or more of the PDUs of the PDU set over PDUs of a higher priority logical channel and transmitting the prioritized PDUs of the PDU set. Transmitting the PDU set using the first LCP configuration may include prioritizing the PDUs of the one or more logical channels based on a descending order of priorities associated with the logical channels. The WTRU may transmit an indication of the PDU delay information to the network. The WTRU may map the PDUs to the one or more logical channels. [Brief description of the drawings]

[0013] [Figure 1A] FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] FIG. 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] FIG. 2 shows an example of mapping PDUs associated with ADUs in different QoS flows to a transfer configuration. [Diagram 3] FIG. 3 illustrates an example of a WTRU determining the traffic attributes of a set of PDUs and the LCP configuration to apply to support QoS. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Exemplary Network for an Implementation of the Present Invention 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. Communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communications system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communications system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0015] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, wireless paging, mobile phones, Personal Digital Assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0016] 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 interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base station transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each illustrated as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0017] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular 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 the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell, for example, using beamforming to transmit and / or receive signals in a desired spatial direction.

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

[0019] More specifically, as noted above, the communications system 100 may be a multiple access system, but may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communications 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 ​​Uplink Packet Access (HSUPA).

[0020] 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-A Pro).

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

[0022] 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 LTE radio access and NR radio access together, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to and / or from multiple types of base stations (e.g., eNBs and gNBs).

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

[0024] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as an office, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. 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 yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0025] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error 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 high level security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs that use 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 communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] The CN 106 / 115 may also act 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 providing 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 transmission control protocol (TCP), user datagram protocol (UDP), and / or internet protocol (IP) of 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 RANs 104 / 113 or a different RAT.

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

[0028] Figure 1B is a system diagram illustrating an example WTRU 102. As shown in Figure 1B, 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 source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0029] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B illustrates the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0032] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned 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, for example, NR and IEEE 802.11.

[0033] 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. In addition, the processor 118 may access information from and store data in any type of suitable 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, etc. 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 home computer (not shown).

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

[0035] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, 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 may determine its location based on the timing of signals being received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by way of any suitable position determination method while remaining consistent with an embodiment.

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

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

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

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

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

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

[0042] The MME 162 may be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0043] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0044] The SGW 164 may be connected to a 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.

[0045] 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 communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0046] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, in certain representative embodiments it is contemplated that such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

[0047] In an exemplary embodiment, the other network 112 may be a WLAN.

[0048] A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS to the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent, for example, through the AP, where the source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between the source STA and the destination STA 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 may not have an AP, and STAs within or using an IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

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

[0050] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

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

[0053] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is active due to a STA (that only supports the 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered active even though most of the frequency band may remain dormant and available.

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

[0055] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may employ NR radio technology and communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

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

[0057] 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 (e.g., including varying numbers of OFDM symbols and / or lasting varying lengths of absolute time) or transmission time intervals (TTIs) of various or scalable lengths.

[0058] 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 accessing any other RAN (e.g., eNode-Bs 160a, 160b, 160c, etc.). 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 unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNodeB 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 eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

[0060] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is illustrated as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

[0063] The UPFs 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 UPFs 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.

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

[0065] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0066] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may use terrestrial wireless communication to implement the tests.

[0067] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test scenario in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0068] There may be different types of Extended Reality (XR) applications / use cases. Virtual Reality 1 (VR1) applications may be used. VR1 applications (e.g., immersive six degree of freedom (6DoF) streaming) may be modeled using service flows applicable to the viewport-dependent streaming architecture. Similar to adaptive streaming (e.g., DASH), viewport-dependent streaming may allow for dynamically updating the quality of media and / or video based on available bitrates in the network and / or air interface. According to the service / traffic flow, tracking and attitude information of the viewport of the XR device (e.g., small packet size less than 100B) is periodically transmitted to the XR server at a relatively low data rate (e.g., 0.5-2Mbps, 60-500Hz) in the uplink (UL). In response, the XR server transmits in the downlink (DL) at a relatively high data rate (e.g., 6-18MBps for 4k omnidirectional and field of view (FoV) area streaming) and adaptively transmits viewport-optimized media (e.g., H.264 / 265 video) quasi-periodically (e.g., 40 / 60 / 120fps), which is then rendered on the XR device display.

[0069] The traffic characteristics of VR1 may be as follows: UL traffic may include attitude / viewport information (e.g., including information about 6DoF), may have small packet size (e.g., constant size less than 100B), low data rate (e.g., 0.5-2Mbps), and may be single-flow. UL traffic may be periodic (e.g., with periodicity range of 60-500Hz). DL traffic may include media / video including viewport optimized scenes (e.g., high quality) and / or media video for non-viewport scenes (e.g., low quality), may have large packet size (e.g., variable size with Gaussian distribution or fixed size of 1500B), high data rate (e.g., 6-18Mbps) and end-to-end (E2E) latency (e.g., 50ms), and may be multi-flow (e.g., may include video flows with different bitrates, 3D media, and / or metadata). DL traffic may be quasi-periodic (eg, periodic as a function of frame rate of 40 / 60 / 120 fps).

[0070] Virtual reality 2 (VR2) applications may be used. VR2 applications (e.g., immersive game spectator mode) can be modeled using service flows applicable to the split rendering architecture. The XR server may perform pre-rendering and encoding of 2D media / video frames based on pose information sent by the XR device periodically at low data rates (e.g., 0.5-2 Mbps, 60-500 Hz). Rendering is performed primarily in the XR server and transmitted in DL at high data rates and low latency (e.g., 30-45 Mbps, 10-20 ms). The XR device decompresses the received media / video and performs asynchronous time-warping (ATW) to correct the viewport based on the latest pose information. The RTT latency for sending pose information in the UL and receiving pre-rendered media in the DL may range up to 50 ms, but ATW may enable meeting the motion-to-photon latency requirement (less than 20 ms) based on in-device processing.

[0071] The traffic characteristics of VR2 may be as follows: UL traffic may contain pose / viewport information, may have small packet size (e.g., constant size less than 100B), low data rate (e.g., 0.5-2Mbps), and may be single-flow. UL traffic may be periodic (e.g., with periodicity range of 60-500Hz). DL traffic may contain 3D scenes in the frame buffer, may have large packet size (e.g., variable size with Gaussian distribution or fixed size of 1500B or more), high data rate (e.g., 30-45Mbps), latency round trip time of 30ms or 50ms, and may be multi-flow (e.g., may contain 3D video / media and / or metadata). DL traffic may be quasi-periodic (e.g., periodicity as a function of frame rate of 60 / 90fps).

[0072] Augmented reality 1 (AR1) applications may be used. AR1 applications (e.g., real-time communication with a store clerk) may be characterized using service flows applicable to distributed computing architectures. According to the service / traffic flows, the XR device transmits pose information (e.g., 0.5-2 Mbps, 60-500 Hz) and / or video (e.g., 10 Mbps, 10 Hz frame update rate) in the UL to the XR server. The received information is used by the XR server to generate a scene, which is then converted into a 2D (e.g., video) or 3D media (e.g., 3D object) format along with metadata (e.g., scene description). The compressed media and metadata (e.g., which may be characterized by a Pareto distribution) are delivered quasi-periodically in the DL at a relatively high data rate (e.g., 30-45 Mbps, 40 / 60 / 120 fps). The XR device then locally generates the AR scene by overlaying the 3D objects onto the 2D video and rendering the scene within the device display.

[0073] The traffic characteristics of AR1 may be as follows: UL traffic may include attitude information and / or 2D video stream information. The attitude information may have a small packet size (e.g., constant size less than 100B), a low data rate (e.g., 0.5-2Mbps), and may be periodic at 60-500Hz. The video information may have a relatively large packet size, a data rate of 10Mbps, may be periodic with an update periodicity of 10Hz, and may be multi-flow video. DL traffic may include 2D / 3D pre-rendered media and XR metadata, may have a large packet size (e.g., Pareto distribution) and a high data rate (e.g., 30-45Mbps), and may be multi-flow (e.g., may include 2D / 3D media and / or metadata). DL traffic may be quasi-periodic (e.g., periodicity as a function of frame rate of 60 / 90fps).

[0074] Augmented Reality 2 (AR2) applications may be used. AR2 applications (e.g., XR conference, AR animated avatar call) may use services / traffic flows applicable to the XR conversation architecture when two or more XR clients / devices can perform peer-to-peer communication with intermediate media processing in the network. Different types of media that may be supported for AR2 applications may include 2D+ / RGBD (e.g., 2.7Mbps), 3D mesh (e.g., 30Mbps), and / or 3D Video point cloud coding (VPCC), / Geometry-based point cloud compression (GPCC) (e.g., 5-50Mbps) based on the type of user expression. The XR client in the device may initiate a call setup procedure, based on which the session control function triggers network-based media processing. The session control function forwards the call setup to the second XR client and / or device, and then forwards real-time media processing and streaming to both clients with low latency (e.g., E2E<100ms). During an XR call, 2D / 3D media, and possibly user pose information, are transmitted quasi-periodically on the UL and DL between the XR client / device.

[0075] The traffic characteristics of AR2 may be as follows: UL traffic may include 2D / 3D media, user posture, and / or video. UL traffic may have relatively large packet size, data rate of 2.7-50 Mbps, packet delay budget (PDB) less than 150 ms, and may be multi-flow (e.g., 2D / 3D media). UL traffic may be quasi-periodic (e.g., 60-500 Hz). DL traffic may include 2D / 3D media, user posture, and / or video. DL traffic may have large packet size (e.g., truncated Gaussian distribution), data rate of 2.7-50 Mbps, and E2E PDB less than 100 ms, and may be multi-flow (e.g., may include 2D / 3D media). DL traffic may be quasi-periodic (e.g., 60-500 Hz).

[0076] XR conferencing applications can be used. XR conferencing applications can provide an immersive conferencing experience between geographically separated users by representing the users in a 3D volumetric representation (e.g., point cloud or mesh). One or more cameras (e.g., with depth perception capabilities) can be placed at each user's location to enable interaction (e.g., see, hear, rotate, zoom in, resize) with each other's full 3D volumetric representation on their respective headsets / glasses. XR conferencing applications can support simultaneous UL and DL media traffic with media consisting of audio, video, and 3D objects. Media formats that can be applied to capture users in a 3D volumetric format include 2D+ / RGBD (e.g., >2.7Mbps for one camera, >5.4Mbps for two cameras), 3D mesh (e.g., about 30Mbps), 3D VPCC / GPCC (e.g., 5-50Mbps). Media processors can be centrally located or distributed at the edge. Additionally, the service / traffic flows between XR clients / users via the in-network media processors can be expected to be similar to the AR2 and XR conversation use cases. Joining an XR conference session may result in an initial download peak to download the virtual environment and associated media objects in the XR application. Throughout the remainder of the session, data rates may vary depending, for example, on the number of users, the user's upload format, and / or the refresh rate of the virtual 2D / 3D objects / environments.

[0077] The traffic characteristics of an XR conference may be as follows: UL traffic may include 2D / 3D media, and user posture and / or real-time video. UL traffic may have relatively large packet size, data rate of 2.7-50 Mbps, and may be multi-flow (e.g., 2D / 3D media). UL traffic may be quasi-periodic (e.g., 60-500 Hz). UL traffic may be 10 -3DL traffic may have a low encoder packet error rate (PER) of less than 10 ms. DL traffic may include 2D / 3D media, user pose and / or real-time video, and 2D / 3D objects / environments (e.g., may be from a third party). DL traffic may have large packet sizes, data rates of 2.7-50 Mbps, and E2E PDBs of less than 100 ms, and may be multi-flow (e.g., may include 2D / 3D media). DL traffic may be quasi-periodic (e.g., 60-500 Hz) and may be 10 -3 The encoder may have a low PER of less than 1.

[0078] Cloud gaming (CG) applications may be used. CG applications (e.g., 5G online games) may mainly rely on an adaptive streaming architecture, where video / media rendered in the network is streamed to thin clients in devices (e.g., smartphones, tablets, etc.). In a typical service / traffic flow for CG, the XR device transmits viewport-related pose information (e.g., 100-250B) to the XR server periodically in UL (e.g., 0.1-1Mbps, 60-500Hz). The generated viewport-related video / media (e.g., 1500B) is encoded / compressed (e.g., H.264 / 265 video) and quasi-periodically transmitted by the XR server in DL (e.g., 30-45Mbps, 30 / 50 / 60 / 90 / 120fps, PER:10). -3 ). The received video / media is then rendered in the XR device upon decoding and processing. The RTT latency to support certain high-end CG applications (e.g., Category D: photorealistic or natural video games) may be determined by the round trip interaction delay (e.g., 50ms). For other CG applications (e.g., Categories A, B, C), the uplink PDB may be 10ms and the downlink streaming PDB may range from 50ms to 200ms.

[0079] The traffic characteristics of the CG may be as follows: UL traffic may include pose / viewport information. UL traffic may have relatively small packet size (e.g., 100-250B), low data rate of 0.1-1 Mbps, PDB of 10 ms, and may be single-flow. UL traffic may be periodic (e.g., 60-500 Hz). DL traffic may include 2D / 3D media and / or user video. DL traffic may have large packet size (e.g., up to 1500B), high data rate of 30-45 Mbps, PDB of 20 ms, and may be multi-flow (e.g., may include 2D / 3D media and / or video). DL traffic may be quasi-periodic (e.g., periodicity as a function of frame rate of 30 / 50 / 60 / 90 / 120 fps) and may be 10 ms. -3 The encoder may have a low PER of less than 1.

[0080] In the existing NR quality of service (QoS) framework, QoS may be differentiated with per-flow granularity, and each QoS flow may be identified with a QoS flow identifier (QFI). The QFI may be associated with several QoS parameters, such as traffic type (e.g., non-GBR / GBR / delay-critical GBR), data rate (e.g., GFBR / MFBR), packet delay budget, averaging window, maximum data burst volume (MDBV), time to live, etc. Such QoS parameters may be applied to provide consistent forwarding treatment during transmission to PDUs in a QoS flow. However, such QoS framework and QoS parameters may not be directly applicable to handle traffic associated with XR services.

[0081] In XR services and applications such as AR, VR, and CG, traffic may consist of data / PDUs that may be associated with media frames or application data units (ADUs). PDUs belonging to an ADU may be associated with different spatial locations within the frame. For example, some PDUs within an ADU may carry data associated with field of view (FoV) spatial locations within the frame. Similarly, other PDUs within an ADU may carry non-FoV spatial locations within the frame. Different PDUs in an ADU may contribute to different user experiences and thus may be associated with different spatial and / or temporal importance values. During transmission, PDUs associated with an ADU may need to be differentiated and treated differently with respect to QoS (e.g., different from existing QoS frameworks where all PDUs within a QoS flow are provided with the same forwarding treatment), regardless of whether the PDUs of an ADU are within one or more associated QoS flows.

[0082] The interdependencies between PDUs of an ADU in a single or multiple QoS flows may bring different challenges to ensure that the relative QoS associated with the PDUs (e.g., maximum difference in QoS achievable for different PDUs of an ADU) is satisfied in addition to satisfying the absolute QoS requirements of each PDU during transmission in UL and DL. Furthermore, some events (e.g., user movement change, scene change, etc.) may cause the amount of critical / high importance PDUs in an ADU that needs to be transmitted at high data rate and very low latency to suddenly increase over a relatively short time window. In such cases, it may be difficult to use semi-static configurations at the access stratum (AS) layer to deal with sudden surges in high importance PDUs, the lack of queue management mechanisms at L2 to ensure bounded latency, and to deal with the dynamically changing interdependencies between PDUs in an ADU. Therefore, ensuring the QoS requirements of data / QoS flows associated with an XR service may include preserving interdependencies between PDUs in an ADU, meeting ADU-level QoS during transmission, handling surges in traffic / QoS, and / or taking into account dynamically changing interdependencies and relative importance of PDUs in an ADU.

[0083] QoS processing for XR may be performed.

[0084] As used herein, the term "network" may include, for example, any of a base station (e.g., gNB, TRP, RAN node, access node), a core network function (e.g., AMF), and / or an application function (e.g., edge server function, remote server function).

[0085] As used herein, the term "flow" may correspond to either a QoS flow or a data flow (e.g., a flow(s) of data consisting of one or more PDUs or ADUs that may be associated with one or more QoS requirements, such as latency, data rate, and / or reliability). Different flows, possibly originating from a common application / experience source and / or destined for a common destination device / wireless transmit / receive unit (WTRU) or group of associated devices / WTRUs, may be referred to as associated or correlated flows.

[0086] As used herein, the term "transmission configuration" may correspond to any of the following: bearers (e.g., data radio bearers (DRBs) and / or signaling radio bearers (SRBs)), logical channels (LCHs), logical channel groups (LCGs), configuration parameters at individual layers in the AS protocol stack (e.g., Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), Physical Layer (PHY), or other protocol layers), parameters associated with Logical Channel Prioritization (LCP) (e.g., priority, PBR, BSD), BWP, carrier, radio link / interface (e.g., Uu link, SL), and / or radio resources (e.g., a set of one or more frequency / time / space resources such as time slots, subcarriers, or beams). Radio resources may also be associated with configured grants, dynamic grants, and / or any other resource grants or grant-free resources.

[0087] As used herein, the term "mapping configuration" may correspond to any of the following: parameters and / or configurations associated with mapping from one or more application data (e.g., ADU) flows, QoS flows (e.g., associated or unassociated), or one or more radio bearers, SDAPs, PDCPs, LCHs, carriers or component carriers (e.g., CCs in a CA configuration), BWPs, and radio links / interfaces (e.g., Uu links or sidelinks), which may be used, for example, to deliver PDUs in the UL or DL ​​direction.

[0088] As used herein, the term "cooperative devices / WTRUs" or "associated devices / WTRUs" that may be collectively associated to support an application / experience may correspond to any of the following: independent / standalone WTRUs / devices / nodes (e.g., XR devices, XR glasses, smart watches) that may possibly be configured with direct connectivity to the network via one or more links (e.g., Uu links); non-standalone devices / nodes (e.g., devices associated with a WTRU, sensors, wearable devices, haptic gloves, reference nodes / WTRUs) that may not be configured with direct connectivity to the network, but may be accessible to / by the network via one or more indirect links (e.g., via an SL or another WTRU with direct connectivity); devices / nodes controlled by the network (e.g., a network operator); and / or stationary / static or moving / mobile devices / nodes / WTRUs.

[0089] As used herein, the term "XR / application aware data transmission / reception" or "XR / application aware QoS processing" may correspond to any of the following: ADU processing; application / higher layer importance / priority, and / or QoS flow processing.

[0090] In ADU processing, an ADU (e.g., media unit, video frame) may contain one or more PDUs. An ADU may be associated with ADU-level QoS requirements (e.g., data rate, latency, reliability) that may be applicable to one or more PDUs associated with the ADU. Different PDUs in an ADU may be associated with individual PDU-level QoS requirements. Such associations and interdependencies may be visible to the AS layer (e.g., using associated IDs) and / or may be processed at the AS layer with awareness of the associations during data transmission and reception.

[0091] For application / high-layer importance / priority, different PDUs within an ADU (e.g., or all PDUs within an ADU) may be associated with different application / high-layer importance / priority values. Such importance values ​​may correspond to spatial importance (e.g., the spatial location of the video frame whose data is carried by the PDU / ADU, a PDU / ADU carrying a 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 the video frames whose data is carried by the PDU / ADU, a PDU / ADU carrying a base video frame such as an I-frame may be associated with a higher temporal importance than a difference video frame such as a P-frame / B-frame). Such importance values ​​may be visible to the AS layer (e.g., by means of an associated ID / marker / indication) during data transmission and reception, possibly enabled by application awareness.

[0092] In QoS flow processing, the ADU / PDUs of an application may be encoded by the application and delivered over one or more QoS / data flows and / or to the WTRU (e.g., in the UL) or to the network (e.g., in the DL). In this regard, different QoS flows carrying ADU / PDUs associated with an XR application / experience may be visible to the AS layer (e.g., with associated IDs) and / or may be processed at the AS layer with awareness of the association during data transmission and reception.

[0093] As used herein, the term "WTRU action(s)", which may relate to application actions and / or AS layer actions to ensure / support differentiated QoS, may correspond to any of the following: determining metadata of an application (e.g., an XR application); determining / generating application content; performing measurements and / or reporting; processing / forwarding data / PDUs / ADUs and handling QoS associated with PDUs / ADUs; processing / forwarding information related to connectivity with the network and / or other WTRUs, etc.

[0094] The WTRU action(s) may include determining metadata of an application (e.g., an XR application). Determining metadata of an application may involve, for example, determining any of the FoV / visual perimeter, 2D / 3D size, borders, spatial attributes, and / or boundaries of the FoV based on measurements in any spatial dimension(s) including, but not limited to, longitude, latitude, altitude, depth, roll, pitch, yaw in one or more coordinate systems (e.g., Cartesian, spherical). For example, determining metadata may involve determining the quality of the FoV content (e.g., whether the FoV content is of high quality, which in the case of images may be quantified and evaluated by image resolution (e.g., number or density of megapixels)). Determining metadata may involve determining the importance and / or priority of the FoV content. The importance may be associated with the spatial importance and / or temporal importance of the content / data. For example, the spatial / temporal importance values ​​may indicate absolute and / or relative importance associated with the FoV content. Spatial importance may be associated, for example, with one or more segments / tiles / slices / locations of the FoV in the spatial dimension, whereas temporal importance may be associated, for example, with one or more frames / subframes of the FoV in the temporal dimension.

[0095] WTRU actions may include application content determination / generation. Application content determination / generation may include determining / capturing, by the WTRU / node, for itself and / or on behalf of another WTRU / node, one or more 2D / 3D image / video frames associated with a FoV boundary / perimeter / boundary defined by the FoV metadata. For FoV content mapping, the WTRU may determine the image / video frames using a visual sensor (e.g., 2D / 3D camera, lidar), an RF sensor (e.g., RF transceiver, RADAR), an audio sensor (e.g., sonar), etc. Mapping the FoV may also be referred to herein as sensing FoV content or capturing FoV content. Application content determination / generation may also include recording / capturing audio frames as part of the real environment or as part of an overlaid soundtrack / audio file with an audio file originating from a source other than the current real environment being mapped.

[0096] WTRU actions may include performing measurements and / or reports. The WTRU may perform measurements of attitude (e.g., 6DoD / 3DoD orientation, location / position), speed of movement / movement, etc., of the user / WTRU and / or other objects (e.g., virtual or real) with which the user may be interacting. The WTRU may transmit / report attitude measurements to the network, for example, periodically or upon detecting an event trigger (e.g., a change in attitude measurement above / below a threshold). In an example, the WTRU may perform measurements of one or more of reference signals (e.g., SSB, CSI-SR, PRS, sidelink RS), GNSS signals, unlicensed carriers, ultra-wideband signals, LIDAR signals, visual signals, etc. In another example, the WTRU may perform measurements of the radio link interface(s) associated with the WTRU (e.g., Uu link, SL). The WTRU may trigger transmission and / or measurement of reference signals (e.g., via Uu link and / or sidelink) in one or more other WTRUs. The WTRU may transmit measurement reports to the network and / or to another WTRU.

[0097] WTRU actions may include processing / forwarding data / PDUs / ADUs and processing QoS associated with the PDUs / ADUs. Data may include any of media / image / video frames, sensor data, and / or measurement data (e.g., attitude measurements, link / channel measurements) determined by the WTRU, possibly to support application / service / network requests associated with the WTRU. The WTRU may transmit and / or receive data to / from one or more destinations including RAN nodes (e.g., gNBs), CN functions / entities, application functions (e.g., hosted at the WTRU or in the network), etc. The WTRU may perform splitting / merging of data / PDUs in one or more QoS flows into one or more transfer configurations during transmission / reception.

[0098] WTRU actions may include processing / forwarding information related to connectivity with the network and / or other WTRUs. For example, processing / forwarding information related to connectivity with the network and / or other WTRUs may include sending capability information to the network, which may or may not be co-located with the WTRU, including information regarding capabilities to support one or more interfaces and / or information regarding capabilities to cooperate and / or interact with other WTRUs / devices (e.g., via an SL interface), receiving configuration(s) including receiving RRC configuration(s) from the gNB and / or NAS layer configuration from the CN, sending and / or receiving assistance data to / from the network associated with traffic, QoS, scheduling, etc., to support UL / DL transmissions, and / or sending requests for radio resources and / or resource grants (e.g., dynamic grants, semi-static / configured grants).

[0099] The WTRU may support differentiated QoS. In an example, the WTRU may be configured to flexibly update a protocol stack including mapping configuration, forwarding configuration, SDAP, PDCP, RLC, MAC, PHY, and / or any other layers in the AS layer based on detection of one or more configured triggering conditions.

[0100] ADUs and / or PDUs received in one or more QoS flows with the same or different QoS requirements may be mapped to one or more transfer configurations using a mapping configuration. Different transfer configurations may be configured to achieve / enforce different QoS when transmitting ADUs / PDUs. In an example, PDUs of ADUs received in one or more QoS flows may be mapped to one or more transfer configurations (e.g., DRBs with common / different PDCP entities) using a mapping configuration (e.g., in an SDAP), and the transfer configurations may be associated / grouped to achieve / ensure ADU-level QoS. Upon mapping, configurations (e.g., priority, PDB) in the transfer configuration to achieve / enforce PDFU-level and / or ADU-level QoS may be applied to the PDUs / ADUs in the buffer associated with the transfer configuration.

[0101] PDUs of different ADUs received on different QoS flows may have different expected QoS to be met during transmission. Based on the determination of the expected QoS for the PDUs / ADUs received or to be received on the QoS flows, the WTRU may apply certain mapping and buffer / queue management mechanisms at one or more layers of the AS layer protocol stack (e.g., SDAP, PDCP, MAC) such that the expected QoS for the PDUs may be met during transmission and / or upon reception at the network.

[0102] To meet the QoS requirements of PDU / ADU, different layers in the transmission configuration may be configured with different configuration parameters. Such configuration parameters may include, for example, support for AM / UM in RLC, LCP rules / restrictions and associated LCH parameters (e.g., PBR, BSD, priority) in MAC, and / or number of HARQ transmissions. To meet the QoS requirements, some parameters may be configured, for example, in the PDCP (e.g., sequence number size, ROCH) and / or SDAP (e.g., mapping between QFI and radio bearer) sublayers.

[0103] The term "expected QoS" as used herein may refer to an expected margin of a certain QoS metric (e.g., latency, data rate, reliability) prior to the arrival of a PDU / ADU or when the PDU / ADU is received at the WTRU (e.g., QoS to be achieved / enforced upon transmission). In an example, the expected QoS may correspond to a duration available at the WTRU to forward the PDU on the Uu link. The expected QoS may also correspond to a time to live (TTL) (e.g., maximum time available for processing and delivery) for individual PDUs or different PDUs within the ADU. The expected QoS may be determined based on indications / markers in the PDU (e.g., QFI in the PDU header, timestamp, ADU ID, etc.) and / or based on the use of timers that may be set upon receiving the PDU / ADU and reset / stopped upon expiration of a configured duration. Similar mechanisms (e.g., based on indications / markers and / or timers) may be applied to change between different mapping and / or forwarding configurations to ensure the expected QoS.

[0104] In some examples, the expected QoS / TTL may be stricter or more relaxed than the default QoS metric applied associated with the PDU / ADU. For example, if a PDU arrives late at the WTRU or experiences more delay and jitter at the application layer (e.g., due to the encoder) and therefore indicates a high importance value for the PDU (e.g., above a threshold), the expected latency to be met over the Uu link for the PDU may be lower than the default PDB typically used to transmit the PDU. Alternatively, if a PDU arrives early or indicates a low importance value for the PDU (e.g., below a threshold), the expected latency on the Uu link may be considered more relaxed than the PDB typically used to transmit such PDU.

[0105] The expected QoS may change dynamically based on the QoS experienced during reception and / or importance / priority indications, and in the case of a fixed QoS (e.g., PBR, PDB), an increase / decrease in expected QoS before reception may translate into a decrease / increase in expected QoS over the Uu link.

[0106] In an example, the WTRU may be configured to perform 1:1, N:1 or N:M mapping of one or more QoS flows to one or more transmission configurations to enable flexible utilization of radio bearers and resources while satisfying QoS of PDU / ADU.

[0107] Differentiated QoS with application awareness during data transmission may be supported. In an example, the WTRU may support differentiated QoS at one or more levels of QoS granularity when processing a data transmission associated with an ADU. The WTRU may support differentiated QoS and / or assist the network to support differentiated QoS during data transmission based on one or more of the following: configuration, triggering events, conditions / criteria received from the network and / or application(s).

[0108] The WTRU may be configured with one or more conditions and / or configurations associated with the processing / handling of data / PDUs associated with ADUs transmitted to or received from the network. Such conditions and / or configurations may relate to or reflect an expected QoS or a change in such expected QoS to be achieved for the data / PDUs / ADUs during transmission to the network (e.g., in the UL) or during reception at the WTRU (e.g., in the DL).

[0109] The WTRU may support differentiated QoS when operating in a WTRU-based mode and / or a WTRU-assisted mode associated with handling of traffic / QoS during data transmission. Different modes for WTRU operation when supporting differentiated QoS may include WTRU-based differentiated QoS and / or WTRU-assisted differentiated QoS. In WTRU-based differentiated QoS, the WTRU may perform selection / determination of one or more configurations / parameters / mechanisms for meeting QoS requirements associated with XR / application-aware data transmission / reception based on assistance information and / or configuration information received from the network. In WTRU-assisted differentiated QoS, the WTRU may assist the network to select / determine one or more configurations / parameters / mechanisms for meeting QoS requirements associated with XR / application-aware data transmission / reception by providing assistance information and / or preferred configuration information (e.g., preferred parameters supported in mapping / forwarding configurations) to the network.

[0110] The WTRU may perform mapping of ADU PDUs in different QoS flows to one or more transport configurations and / or determining / selecting a set of transport configurations and / or parameters of the transport configurations for transmitting the ADU PDUs based on one or more conditions / configurations / operational modes described herein.

[0111] In an example (e.g., as described herein), the WTRU may perform mapping of ADU PDUs in different QoS flows to one or more transmission configurations. Such mapping may be performed based on the use of one or more configured mapping configurations (e.g., determining mapping configuration parameters, dynamic activation / deactivation, etc.) and other conditions / configurations described herein. This type of mapping may be referred to herein as "mapping of ADU PDUs to transmission configurations in the WTRU to support differentiated QoS."

[0112] In an example (e.g., as described herein), the WTRU may determine / select a transmission configuration and / or a set of parameters of the transmission configuration for transmitting the PDU of the ADU. Such determination / selection may be performed based on the use of one or more configured transmission configurations, associated parameters, and / or other conditions / configurations described herein. This may be referred to herein as "determining / selecting a transmission configuration at a WTRU to support differentiated QoS."

[0113] The WTRU may send assistance / status information associated with XR / application awareness to the network. In an example, the WTRU may send information associated with XR / application awareness and / or support of QoS processing (e.g., association of PDUs to ADUs) to the network, possibly to enable the network to have awareness of WTRU actions and / or applications / QoS configurations / parameters supported by the WTRU.

[0114] Information associated with XR / application awareness and / or QoS may be transmitted from the WTRU to the network as one or more of the following message types: assistance information, preferred configuration information (e.g., preferred mapping and / or forwarding configurations / parameters to be applied in the UL / DL), status information / indications (e.g., associated with any of the AS layers), measurement / status reports (e.g., WTRU attitude information, channel / link measurements, buffer occupancy measurements), and / or request / response messages.

[0115] The information may be transmitted by the WTRU periodically (e.g., using one or more configured periodicity values), aperiodically / dynamically (e.g., upon detecting a trigger event / condition described herein), as an update message (e.g., upon detecting a change in previously transmitted information), and / or semi-persistently (e.g., transmitted with a periodicity value for a time window / duration). In an example, the WTRU may switch between a first and a second periodicity value for transmitting information, possibly based on the type of event detected (e.g., a QoS surge event). In another example, the WTRU may change between transmitting information periodically and aperiodically based on whether any change and / or amount of change in the transmitted / reported information is determined.

[0116] The WTRU may send information / instructions to the network via one or more of the following: RRC signaling and / or messages; control PDUs associated with any of the AS layers (e.g., SDAP control PDUs, PDCP control PDUs, etc.); UL MAC CE (e.g., BSR, preemptive BSR, elastic BSR that may be scalable / adjustable by sending subsequent instructions, possibly without canceling previous BSRs, etc.); UCI (e.g., SR, feedback, ACK / NACK, CSI, etc.); non-AS (NAS) layer signaling (e.g., PDU session related messages); and / or application layer signaling / messages.

[0117] The information transmitted by the WTRU to the network, in any of the message types, may include a combination of one or more of the following: identifiers / IDs; priorities of applications supported by the WTRU; data flows associated with the applications; devices associated with the applications; data and / or traffic types associated with the data flows per application; traffic characteristics and / or parameters of the data / traffic associated with the data / QoS flows per application; QoS requirements or expected QoS associated with the data; attitude information (e.g., orientation, position / location); capability information associated with connectivity; capability information associated with WTRU actions; preferred configuration information; instruction(s) to activate / deactivate configurations; measurements and / or uncertainty information related to the application / AS layer.

[0118] The information sent by the WTRU to the network may include one or more identifiers / IDs in any of the message types. For example, the WTRU may send one or more IDs including one or more of the following: ID(s) associated with the application (e.g., application ID, service ID, session ID, application configuration ID, etc.); group IDs (e.g., associated with a group of QoS flows, a group of forwarding configurations, and / or a group of devices / WTRUs); ID(s) of individual QoS flows, mapping configurations, and / or forwarding configurations, and / or data type / message IDs (e.g., ADU ID, PDU ID, ID associated with attitude information, FoV information, media / video frame information, etc.).

[0119] The information transmitted by the WTRU to the network may include, in any of the message types, the priorities of the applications supported by the WTRU. For example, the WTRU may transmit information regarding IDs of the supported applications and / or relative / absolute priority values ​​associated with the supported applications.

[0120] The information transmitted by the WTRU to the network may include, in any of the message types, the data flows associated with the application. For example, the WTRU may transmit the number of supported data / QoS flows for each application and / or their associated IDs. The WTRU may also transmit information regarding relative / absolute priority values ​​associated with the data / QoS flows of different supported applications.

[0121] The information sent by the WTRU to the network in any of the message types may include the devices associated with the application, For example, the WTRU may send the number and / or IDs associated with supported devices and / or the association of devices per application.

[0122] The information transmitted by the WTRU to the network may include, in any of the message types, the data / traffic type associated with the data flow for each application. For example, the WTRU may transmit information regarding different data / QoS flows associated with an application, and the data types may include video data (e.g., I-frame data, P-frame data, B-frame data), RGB-D data, 360-degree video data, haptic data, attitude / positioning data, audio data, etc.

[0123] The information transmitted by the WTRU to the network may include, in any of the message types, traffic characteristics and / or parameters of the data / traffic associated with the data / QoS flows per application. For example, the WTRU may transmit information regarding traffic characteristics of different data / QoS flows associated with an application, including whether the data is periodic, aperiodic, semi-persistent, quasi-periodic, etc. The WTRU may transmit information regarding the number of PDUs expected per ADU in one or more flows per application. The information regarding the number of PDUs per ADU may also include statistical / distribution information, such as average, minimum, maximum, and / or standard deviation values.

[0124] The information transmitted by the WTRU to the network may include, in any of the message types, QoS requirements and / or expected QoS associated with the data. For example, the WTRU may transmit QoS requirements and / or expected QoS of one or more flows associated with an application, including data rate, latency, reliability, absolute / relative priority values, etc. The QoS requirement information may also include statistical / distribution information, such as average, minimum, maximum and / or standard deviation values. The WTRU may also indicate that such QoS requirements or expected QoS may be supported at different QoS granularities, such as per PDU, per PDU subgroup (e.g., one or more PDUs) within an ADU, per ADU, per group of ADUs, per flow, etc. The WTRU may also indicate a time window (e.g., start time, duration and / or end time) during which such QoS requirements or expected QoS may be applicable to different QoS granularities.

[0125] The information transmitted by the WTRU to the network in any of the message types may include attitude information (e.g., orientation, position / location). For example, the attitude information may be associated with measurements in any spatial dimension (e.g., 6DoF, 3DoF) including, but not limited to, longitude, latitude, altitude, roll, pitch, and / or yaw in one or more coordinate systems (e.g., Cartesian, spherical). In an example, the attitude information transmitted by the WTRU may be associated with the orientation and / or position / location of the WTRU. The WTRU may also transmit information regarding the movement of the WTRU / user (e.g., speed of movement in terms of linear movement (e.g., distance / second) or rotational movement (e.g., degrees / second)). The attitude information may include uncertainty information (e.g., certainty in predicted user movement).

[0126] The information sent by the WTRU to the network may include capability information associated with connectivity in any of the message types. For example, the information regarding the interfaces may include the number and / or type of interfaces supported by the WTRU (e.g., NR Uu, NR SL, WiLAN, Bluetooth, etc.). The capability information regarding the interfaces possibly supported by the WTRU and / or required by the WTRU to support any of the WTRU actions may include any of the following: bandwidth, number of carriers, number of transmit antennas, number of receive antennas, etc.

[0127] The information sent by the WTRU to the network may include capability information associated with the WTRU action in any of the message types. For example, capability information related to a WTRU action, possibly including visual sensing supported by the WTRU (e.g., sensors, cameras associated with the WTRU) and / or visual sensing required by the WTRU, may include any of the following: FoV resolution (e.g., number of megapixels), aperture size, shutter lag and startup time, image quality (e.g., min / max range), zoom lens options, image stabilization, exposure settings, battery life, sound / audio, ability to merge overlapping frames from different angles (e.g., stitching frames from individual captures together for a panoramic image / video).

[0128] The information transmitted by the WTRU to the network may include preferred configuration information in any of the message types. For example, the WTRU may transmit one or more preferred mapping and / or forwarding configurations to the network, including specific parameters associated with the mapping / forwarding configurations to support any WTRU actions that may be performed / supported by the WTRU and / or any other associated WTRUs / devices. The forwarding configurations transmitted by the WTRU associated with the supported and / or requested UP / CP configurations (e.g., radio bearers, LCHs, links) may include latency requirements, data rate requirements (e.g., in Mbps), reliability requirements, absolute / relative importance / priority values ​​associated with the UP / CP configurations (e.g., radio bearers, logical channels, links), and / or LCP configuration(s).

[0129] In an example (e.g., for a PDU), the latency requirement may be expressed in terms of a Packet Delay Budget (PDB) associated with an IP packet / PDU, the data rate may be expressed in terms of a bit rate (e.g., minimum, maximum, average, guaranteed) associated with one or more PDUs (e.g., individual PDUs, groups of PDUs, bursts), and the reliability may be expressed in terms of a Packet Error Rate (PER). In another example (e.g., for an ADU(s), the latency requirement may be expressed in terms of an application delay budget or a frame delay budget associated with an ADU (e.g., video / media rate), the data rate may be expressed in terms of a bit rate (e.g., minimum, maximum, average, guaranteed) associated with one or more ADUs (e.g., video / media frames), and the reliability may be expressed in terms of a frame error rate or an application error rate.

[0130] In the case of an LCP configuration, the WTRU may indicate LCP rules / restrictions that may be applied to the set of transmission configurations (e.g., restrictions associated with the mapping of DRBs / LCHs to configured resource grants), whether such LCP rules / restrictions may be temporarily changed for a certain duration, conditional LCP configurations applicable upon detecting a certain configured event (e.g., a surge in the number of PDUs / data with high QoS requirements), and / or a fallback / default LCP configuration.

[0131] The WTRU may associate and / or indicate weights / probability values ​​for different mapping and / or forwarding configurations when transmitting a request(s) related to a preferred configuration. The weights / probability values ​​may be determined, for example, based on the likelihood of the configuration to be applied during the transmission and / or other application / AS layer information / instructions. The network may use such weights / probability information, for example, to determine and provide a combined configuration to the WTRU and / or to activate / deactivate configurations that may match the weight values ​​indicated by the WTRU.

[0132] The information sent by the WTRU to the network may include, in any of the message types, an instruction(s) to activate / deactivate a configuration. For example, the WTRU may send an instruction to the network to request to activate / deactivate a mapping / forwarding configuration and / or parameters associated with the configuration, which may be pre-configured in the WTRU. The WTRU may include the ID of the configuration / parameter when sending the request instruction. The request to activate / deactivate a configuration may be accompanied by information about the WTRU action (e.g., splitting / merging QoS flows).

[0133] The information transmitted by the WTRU to the network may include measurements related to the application / AS layer in any of the message types. The WTRU may transmit RSRP, RSRQ, RSSI measurements of signals, channels, radio links, carriers, etc., which may be associated with one or more WTRU actions. The WTRU may transmit attitude / positioning measurements (e.g., location information, attitude in 6DoF, speed of user / WTRU movement / movement). The WTRU may transmit QoS related measurements related to the number of PDUs / ADUs received (e.g., over a duration), changes in QoS (e.g., increase / decrease in data rate, latency, reliability), validity period associated with the PDUs / ADUs, and / or remaining time to deliver the PDUs / ADUs.

[0134] The information transmitted by the WTRU to the network may include uncertainty information in any of the message types. For any of the information transmitted / reported by the WTRU that includes application layer information (e.g., pause information, QoS flows) and / or AS layer information (e.g., preferred forwarding configuration), the WTRU may also transmit the uncertainty associated with the information. In examples where the WTRU may perform parameter prediction or estimation (e.g., posture, QoS surges), the WTRU may indicate the uncertainty associated with the estimation / prediction to the network.

[0135] The embodiments described herein may use one or more of the above information (eg, assistance information, preferred configuration) transmitted by the WTRU to the network.

[0136] The WTRU may receive configuration / assistance information from the network to support differentiated QoS. For example, the WTRU may receive configuration / assistance information to enable the WTRU to support any procedures, mechanisms, rules, actions, etc. associated with handling differentiated QoS during data transmission and / or reception of data / PDUs / ADUs in one or more data / QoS flows. The configuration / assistance information may be received from the network by the WTRU periodically (e.g., with one or more configured periodicity values), aperiodically / dynamically (e.g., status indication / information or request / request messages), and / or semi-persistently (e.g., sent with a periodicity value over a time window / duration).

[0137] The WTRU may receive configuration / assistance information via one or more of the following: RRC signaling and / or messages (e.g., dedicated / unicast signaling, broadcast / SIBs); control PDUs associated with any of the AS layers (e.g., SDAP control PDUs, PDCP control PDUs, etc.); DL MAC CE; DCI; non-AS (NAS) layer signaling (e.g., PDU session related messages); and / or application layer signaling / messages.

[0138] The configuration / assistance information received by the WTRU from the network may include one or more of the following: mapping / forwarding configurations and / or parameters; AS layer status information / instructions; validity information; thresholds; requirements / assistance information regarding attitude / movement, and / or requirements / assistance information regarding spatial / FoV information.

[0139] The configuration / assistance information received by the WTRU from the network may include mapping / forwarding configurations and / or parameters. For example, the WTRU may receive one or more configurations and / or sets of configuration parameters to be applied at different layers of the AS protocol stack (e.g., RRC, SDAP, PDCP, RLC, MAC, PHY, or any other layer). The configurations / parameters applied at different layers may include configurations / parameters for SDAP / PDCP (e.g., 1-to-1, 1-to-M or N-to-M mapping configuration, marking / indication / ID to apply (e.g., associated with QoS flow handling, ADU), and / or value range associated with importance / priority information to identify in PDU / ADU); configurations / parameters for PDCP (e.g., ID and sequence number to apply, RoCH configuration, security / encryption parameters, and / or packet duplication configuration); configurations / parameters for RLC (e.g., parameters for AM / UM / TM operation); configurations / parameters for MAC (e.g., LCH parameters (e.g., priority for PDU and / or ADU level, PBR, BSD), LCP configuration (e.g., rules / limits / policies for PDU and / or ADU level handling, duration for changing between different LCP rules / policies), and / or configurations for multiplexing / assembly); and / or configurations / parameters for PHY (e.g., MCS, HARQ configuration).

[0140] The WTRU may receive one or more sets of configuration parameters associated with a default configuration, which may be activated and / or used during a normal scenario, for example, for transmitting / receiving data. The WTRU may also receive another set of configuration parameters, which may be associated with exceptional operation, which may be activated and / or used upon detecting a triggering event / condition (e.g., as described herein).

[0141] The WTRU may receive default priority values ​​corresponding to a transmission configuration (e.g., DRB / LCH) associated with an application. For example, a first transmission configuration may be associated with a first priority value and / or a second transmission configuration may correspond to a second priority value. The first and second transmission configurations may be associated with the same application. The first set of priority values ​​may be intended to achieve default QoS performance (e.g., default latency, default data rate), and the second set of priority values ​​may be intended to achieve exceptional QoS performance (e.g., surge / burst data rate, very low latency) for the PDUs in the first and second transmission configurations being transmitted.

[0142] The configuration / assistance information received by the WTRU from the network may include AS layer status information / indications. The AS layer status information / indications may include identifiers / IDs, status of mapping / forwarding configurations, and / or flow control. For example, the WTRU may receive information regarding one or more IDs to apply during transmission / reception, including one or more of the following: WTRU ID(s) (e.g., C-RNTI, I-RNTI, NAS ID, TMSI / IMS); ID(s) associated with the application (e.g., application ID, service ID, session ID, application configuration ID); group ID(s) (e.g., group of QoS flows, group of forwarding configurations, associated with a group of devices / WTRUs); ID(s) of individual QoS flows, mapping configurations, forwarding configurations, and / or data type / message ID(s) (e.g., ADU ID, PDU ID). The WTRU may receive information regarding achieved / achievable QoS when using one or more mapping / forwarding configurations. For example, such information may be received by the WTRU regarding data rate, latency (e.g., expected, remaining latency), reliability, and / or achievable / achieved priority when transmitting / receiving data / PDUs / ADUs. The WTRU may also receive statistical / relative / absolute information associated with the achieved / achievable QoS, e.g., in terms of average, maximum, minimum, and / or standard deviation, etc. The WTRU may possibly receive explicit or implicit flow control indications from the network indicating whether to start / increase / decrease / pause / stop transmitting PDUs / ADUs with respect to achieving an indicated transmission rate, latency, and / or reliability in one or more transmission configurations.

[0143] The configuration / assistance information received by the WTRU from the network may include validity information. For example, the WTRU may receive validity information associated with a mapping / forwarding configuration indicating if / when a configuration (e.g., a mapping and / or forwarding configuration) may be considered valid or invalid based on one or more triggering events / conditions. The WTRU may also receive information regarding whether a configuration should be deactivated and / or released upon determining that the configuration is invalid. The WTRU may receive information regarding whether a configuration is considered valid / invalid based on the WTRU's RRC state (e.g., CONNECTED, INACTIVE, IDLE) and / or when transitioning between different RRC states.

[0144] The configuration / assistance information received by the WTRU from the network may include thresholds, which may include one or more of a buffer occupancy threshold, an expected threshold time value, an expected data rate (EDR) threshold, an expected reliability threshold, an attitude difference threshold, a WTRU movement threshold, and / or a correlation time window.

[0145] The thresholds may include a buffer occupancy threshold. For example, the buffer occupancy threshold(s) associated with one or more transfer configurations may indicate a maximum / minimum amount of data / PDUs / ADUs (e.g., in terms of total payload size / volume) that may be contained in the buffer.

[0146] The threshold may include an expected threshold time value. For example, the WTRU may receive one or more expected threshold time values ​​or expected time of arrival (ETA) thresholds corresponding to an expected time for receiving a PDU / ADU in a data flow, where the PDU may be either a first PDU associated with the ADU or a subsequent PDU after receiving an earlier PDU. The ETA threshold may be associated with an expected latency of a second PDU / ADU after receiving / transmitting a first PDU / ADU having a first latency value. The ETA threshold may be associated with an expected latency of a PDU / ADU in a second associated data / QoS flow after receiving / transmitting a PDU / ADU in a first data / QoS flow having a first latency value. The ETA threshold may be associated with a duration or a time value. For example, the WTRU may start a timer at a time instance when it receives / transmits a first PDU and may stop the timer when it expires at a time instance corresponding to a threshold time value and / or when it receives / transmits a second PDU (e.g., the first and second PDUs may be associated with the same ADU).

[0147] The thresholds may include an expected data rate (EDR) threshold. The WTRU may receive one or more EDR thresholds associated with an expected data rate for receiving / transmitting PDUs / ADUs in one or more data / QoS flows. The data rate may correspond to one or more of the following units: PDUs / ADUs per second, frames per second, and / or bits per second, etc. The EDR threshold may be associated with an expected data rate of a second PDU / ADU after receiving / transmitting a first PDU / ADU having a first data rate value. The EDR threshold may be associated with an expected data rate of a PDU / ADU in a second associated data / QoS flow after receiving / transmitting a PDU / ADU in the first data / QoS flow having the first data rate value.

[0148] The threshold may include an expected reliability (EER) threshold. The WTRU may receive one or more EER thresholds associated with an expected reliability of receiving a PDU / ADU in one or more data / QoS flows. The reliability value may correspond to one or more of a packet error rate, a frame / ADU error rate, and / or a probability of error, etc. The EER threshold may be associated with an expected reliability for a second PDU / ADU after receiving / transmitting a first PDU / ADU with a first reliability value. The EER threshold may be associated with an expected reliability of a PDU / ADU in a second associated data / QoS flow after receiving / transmitting a PDU / ADU in the first data / QoS flow with a first reliability value.

[0149] The threshold may include an attitude difference threshold, which may correspond to a difference between measurements of attitude information at a first time instance and a second time instance, where the time instance may correspond to one or more of a time slot, a symbol duration, a SFN, and / or units of seconds / milliseconds.

[0150] The threshold may include a WTRU movement threshold, which may correspond to a difference in a location or rotation angle of the WTRU between a first time instance and a second time instance, where the time instance may correspond to one or more of a timeslot, a symbol duration, a SFN, and / or a unit of seconds / milliseconds.

[0151] The threshold may include a correlation time window. The correlation time window may correspond to a minimum time difference between two or more triggering events (e.g., attitude information measurements, QoS events), and events may be considered to be correlated with each other when they occur within the correlation time window. When events occur at time instances that exceed the correlation time window, they may be considered independent. In an example, the WTRU may use the correlation time window to determine whether to send an indication to the network (e.g., indicating a change in the WTRU's location / movement or a change in QoS).

[0152] The configuration / assistance information received by the WTRU from the network may include attitude / movement request / assistance information. The attitude / movement information request / assistance may be associated with measurements in any spatial dimension (e.g., 6DoF), possibly in one or more coordinate systems (e.g., Cartesian, spherical).

[0153] The configuration / assistance information received by the WTRU from the network may include request / assistance information regarding spatial / FoV information. The request / assistance information regarding FoV information may correspond to a dimension of the FoV (e.g., perimeter / boundary / size / boundary / angular width of the FoV) and may be expressed in terms of measurements of any spatial dimension in one or more coordinate systems (e.g., Cartesian, spherical). The WTRU may receive information regarding the FoV of its own sensor / camera (e.g., which may be co-located with the WTRU). Information regarding the FoV, including the extended FoV, received by the WTRU may include dimensions, duration for which the indicated FoV may be valid, and / or area for which the indicated FoV information may be valid (e.g., list of cell IDs, list of cell sector IDs, list of directions within the cell).

[0154] The embodiments described herein may use one or more of the above configuration / assistance information received by the WTRU from the network.

[0155] Triggering events / conditions may occur in the WTRU to support differentiated QoS. The WTRU may be configured with one or more events / conditions related to triggering one or more of the WTRU actions described above, including sending assistance information / instructions to the network, receiving configuration / assistance information from the network, changing the mapping configuration, changing the forwarding configuration, etc.

[0156] Such triggering events / conditions may relate to guaranteeing / supporting differentiated QoS and / or meeting expected QoS when transmitting / receiving PDUs / ADUs in one or more associated QoS flows. Such triggering events / conditions may determine whether and which actions may be performed by the WTRU. Such triggering events / conditions may indicate when (e.g., at what point in time) an action may be performed by the WTRU (e.g., any of the events / conditions / criteria described below are met). The conditions may be based on one or more of: indications / information from the network; indications / information from the application / higher layers; buffer status and loading in the transmission configuration (e.g., DRB / LCH); changes in the configuration(s) in the WTRU; timing / timestamp information (e.g., may be associated with expected QoS); measurements on the Uu link(s); compensation based on expected QoS; properties associated with the link / channel to which the transmission configuration is associated; and / or detection of a QoS event (e.g., a surge in high importance data).

[0157] The triggering event / condition may include an indication / information from the network. The WTRU may receive an indication / information from the network (e.g., gNB) regarding expected / achievable QoS for transmission over the Uu link (e.g., in UL and / or DL). The information may be received semi-statically, during / at configuration, and / or dynamically. The WTRU may trigger an action (e.g., mapping or forwarding configuration determination / selection) as described herein based on the indication / information received from the network. The expected / achievable QoS may be indicated on a per-PDU, per-ADU, per-QoS / data flow, per-forwarding configuration, and / or per-mapping configuration basis. The WTRU may implicitly receive information regarding expected / achievable QoS from the gNB based on one or more of the following: The number of times HARQ feedback is received, resource grants (e.g., configured grants, dynamic grants), allocation of retransmission grants corresponding to one or more transmission configurations (e.g., LCH / DRB / BWP), and / or de-prioritization of PUSCH / grant for one or more LCHs with intra / inter-WTRU prioritization, etc. For example, the WTRU may be triggered to perform any of the WTRU actions described herein upon receiving an indication from the network (e.g., in an RRC, MAC CE, other control PDU, or DCI). The indication received by the WTRU may relate to a change / update of a mapping / transmission configuration in the WTRU and / or an expected QoS associated with one or more QoS flows.

[0158] The triggering event / condition may include an indication / information from an application / higher layer. The WTRU may perform one or more WTRU actions upon receiving an indication from the application / higher layer. Such an indication may include information regarding changes in traffic characteristics / patterns associated with the generated / processed / received PDUs / ADUs in one or more QoS / data flows. The application may indicate to the WTRU information regarding an expected number of QoS flows that may be associated with the application, an expected number of PDUs per ADU, an expected frame / ADU in a subsequent time instance (e.g., next frame generation instance), an expected change in the importance / priority distribution of the generated PDUs, an expected increase / decrease in latency for delivering the PDUs / ADUs (e.g., due to processing in the codec / application), and / or jitter, an expected change in the validity period associated with the PDUs / ADUs, and / or an expected change in the WTRU / user's movement / mobility (e.g., increase / decrease in the speed of movement), etc.

[0159] For example, the WTRU may receive an indication from an application / higher layers indicating the arrival of one or more PDUs (e.g., in a batch / burst) prior to reception of the PDU. The information regarding the arrival of the PDU may include an expected timing of PDU / ADU generation at the application (e.g., time slot / frame) and / or an expected timing of reception at the WTRU. The WTRU may be triggered to perform one or more of the WTRU actions described herein based on the indication of the importance / priority of the transmitted PDU. The WTRU may trigger an action (e.g., change the mapping / forwarding configuration) to transmit a delayed PDU with compensation (e.g., lower latency) when it receives an indication including an importance / priority value higher than a threshold.

[0160] Triggering events / conditions may include buffer status and loading in a transport configuration (e.g., DRB / LCH). Buffer status and loading in a transport configuration may include conditions associated with one or more of the following measurements (e.g., compared to thresholds): amount of PDUs / ADUs in one or more buffers associated with the transport configuration(s), possibly over a period of time; arrival / departure rate of PDUs / ADUs in one or more buffers associated with the transport configuration(s); average, maximum, and / or minimum size / volume of PDUs / ADUs in a buffer associated with the transport configuration(s) (e.g., number of PDUs in an LCH buffer); a measure of the amount of time spent by one or more PDUs / ADUs in a buffer associated with the transport configuration(s); and / or number of transport configurations that meet a condition / threshold associated with data volume, arrival rate, PDU / ADU size, etc.

[0161] For example, the WTRU may perform any of the actions described herein (e.g., change the mapping configuration, change the forwarding configuration, and / or send a report or status indication) if at least one PDU / ADU in a forwarding configuration is in the buffer for a period longer than a threshold time value and / or if the buffer status of the forwarding configuration exceeds a threshold. Other buffer status metrics that may be monitored to determine the expected QoS may include the number of buffered PDUs / ADUs above / below a configured threshold in one or more associated forwarding configurations and / or the rate of PDUs / ADUs arrival / departure in the buffer relative to the configured arrival / departure rate. The WTRU may determine the number of PDUs / ADUs received over a duration / window to determine if the rate of received PDUs is within the expected range for QoS. The WTRU may then determine / select a mapping configuration to adjust / compensate for the expected QoS if PDUs / ADUs are received outside the expected range for QoS.

[0162] The triggering event / condition may include a change in configuration(s) in the WTRU. The WTRU may be triggered to perform one or more WTRU actions (e.g., send an indication / report to the network) when changing the mapping configuration and / or the forwarding configuration, including changing at least one of the parameters in the mapping configuration (e.g., mapping QoS flows to the new forwarding configuration), the DRB / LCH (e.g., priority, PDB, PBR), and / or the LCP configuration. For example, the WTRU may be triggered to perform one or more WTRU actions when the CDRX / DRX configuration and / or any of the associated parameters applied in the WTRU are modified / updated, which may affect the transmission / reception pattern and / or the achievable QoS during data transmission.

[0163] The triggering event / condition may include timing / timestamp information that may be associated with the expected QoS. For example, the WTRU may track timing related information (e.g., timestamp, marker, and / or timing control PDU) in one or more PDUs / ADUs received in an earlier time window to determine latency or jitter. The timing information may then be used to determine the expected QoS for the next PDU / ADU in the next time window. The timing information may be determined / indicated as deadline / latency bounds and / or time to live that may be met per PDU, per ADU, or per QoS flow. Such timing information may be determined, for example, across one or more associated / correlated QoS flows. In another example, the timing information may be determined / indicated on a count basis (e.g., PDU / ADU count). The WTRU may trigger an action (e.g., determining a mapping / forwarding configuration) as described herein upon determining the timing information and its impact on whether the expected QoS may / may not be met.

[0164] The WTRU may send information regarding the expected QoS based on measurements associated with the duration that a PDU / ADU spends in a transmission configuration (e.g., the elapsed time between receipt and transmission of a PDU / ADU). The WTRU may send information / indications / reports to the network (e.g., as described herein) periodically or based on the setting / expiration of a configured timer.

[0165] The triggering event / condition may include measurements on the Uu link(s). For example, the WTRU may perform measurements on the Uu link (e.g., corresponding to RSRP, RSSI, CQI, and / or CSI) to determine the expected QoS. Channel / load measurements taken over a configured duration may indicate whether a PDU / ADU can achieve the expected QoS during transmission or whether the QoS budget (e.g., latency) may be exceeded. The WTRU may trigger actions as described herein (e.g., determining a mapping configuration) based on the measurements on the Uu link.

[0166] The WTRU may determine the Uu link conditions based on the number of ARQ / HARQ retransmissions made via ARQ / HARQ (e.g., ACK / NACK) feedback messages and / or one or more HARQ processes associated with a transmission configuration applied to transmit the PDU / ADU. The expected QoS may then be determined based on a (e.g., configured) mapping function between the feedback / retransmission (ReTx) count and the expected QoS. As an example, a ReTx count above a threshold may translate to poor Uu link / channel conditions and thus reduced expected QoS. In another example, the WTRU may determine the channel / link conditions based on a CSI report received from the network.

[0167] The WTRU may be triggered to perform one or more WTRU actions and / or send an indication to the network when a channel measurement(s) made on the Uu link (e.g., RSRP, RSSI, RSRQ, CQI, CSI) increases / decreases with respect to a configured threshold and / or remains above / below a threshold for a certain duration. The WTRU may be triggered to perform one or more WTRU actions when one or more QoS related measurements (e.g., latency measured for PDUs / ADUs in one or more transmission configurations) exceed a certain threshold. The WTRU may trigger an action (e.g., as described herein) based on a determination of the duration / jitter or change in duration / jitter between reception of successive PDUs associated with an ADU. For example, the WTRU may infer an increase / decrease in jitter between successive PDUs to determine if the processing load at the application / higher layers is high / low. To determine the duration, the WTRU may set a timer when a first PDU arrives and reset the timer when a second PDU associated with the same ADU arrives.

[0168] The triggering event / condition may include compensation based on expected QoS. The WTRU may be triggered to perform one or more WTRU actions based on a determination of expected QoS for one or more PDUs / ADUs, where the expected QoS may indicate that the PDUs are delayed or likely to arrive early. The WTRU may trigger the action such that the delayed PDUs are transmitted with a determined compensation amount. In an example, the action(s) may be triggered upon detecting a change in expected QoS (e.g., higher / lower) for the PDUs / ADUs by a certain threshold. The WTRU may determine the delayed PDUs to be transmitted using a transmission configuration that allows it to meet the compensation amount, where the compensation amount may be determined by subtracting the expected latency from the actual latency.

[0169] The triggering event / condition may include properties associated with the link / channel with which the transmission configuration is associated. The WTRU may be configured with properties specific to the transmission configuration / link / channel, such as transmission configuration / link / channel priority and / or configuration parameters that enable / disable specific actions for the transmission configuration / link / channel. For example, a transmission configuration / link / channel configured with a high priority may allow the WTRU to change (e.g., any) configuration (e.g., relative to an initial or default configuration). The WTRU may change parameters of the transmission configuration associated with the high priority as long as the change only affects the transmission configurations of other lower priorities.

[0170] The triggering event / condition may include detection of a QoS event (e.g., a surge of high importance data). The QoS event may include, for example, a surge event associated with an increase in the number of PDUs / ADUs or amount of data, possibly over a time window, that is indicated / marked with high importance / priority. Similarly, other QoS events may include QoS contraction, associated with a decrease in the number of PDUs / ADUs or amount of data over a time window. The WTRU may be triggered to perform one or more WTRU actions upon detecting one or more QoS events, possibly by taking into account an indicated / determined duration that the QoS event is expected to last. The WTRU may then perform other WTRU action(s), possibly resulting in a return to a default configuration after the detected QoS event ends.

[0171] The WTRU may determine association of PDUs to ADUs based on explicit / implicit indications / parameters. The WTRU may determine whether PDUs in one or more QoS / data flows transmitted by the WTRU (e.g., in the UL) and / or received by the WTRU (e.g., in the DL) are associated with ADUs and / or applications / higher layer functions (e.g., NAS). The WTRU may determine association of PDUs to ADUs and / or applications / higher layer functions based on explicit indications and / or implicit parameters / identifiers detectable by the WTRU in the PDUs or QoS flows.

[0172] Parameters and / or identifiers for determining association of a PDU to an ADU may be configured in the WTRU (e.g., via RRC signaling, NAS layer signaling, and / or application / higher layer signaling). The parameters / identifiers used by the WTRU to identify association of a PDU to an ADU may include one or more of an identifier / ID associated with a flow and / or application; priority / importance information associated with a flow; time / timing information within the associated flow; spatial / attitude information in the associated flow, and / or explicit indication from the application / higher layer / AS layer.

[0173] The parameters / identifiers used by the WTRU to identify association of a PDU to an ADU may include an identifier / ID associated with a flow and / or an application. The WTRU may determine that a first PDU and / or a second PDU in the same or different QoS flow are associated with an ADU based on detecting a common ID associated with the ADU. Such an ID may be found in the PDUs in one or more QoS flows (e.g., in the header and / or payload). The IDs of the ADUs and / or applications associated with the ADUs may be pre-configured in the WTRU.

[0174] The parameters / identifiers used by the WTRU to identify association of a PDU to an ADU may include priority / importance information associated with a flow. The WTRU may determine that a first PDU and / or a second PDU in one or more QoS flows are associated with an ADU based on detection of common and / or similar importance / priority indications in the PDUs (e.g., in the header and / or payload) in the QoS flows. Such importance / priority indications may relate to spatial or temporal indications. The WTRU may determine that a PDU is associated with an ADU when the importance / priority indication (e.g., in the PDU header or payload) detected by the WTRU is above / below one or more importance / priority thresholds.

[0175] The parameters / identifiers used by the WTRU to identify the association of a PDU to an ADU may include time / timing information within the associated flow. The WTRU may determine that a first PDU and / or a second PDU in one or more QoS flows are associated with an ADU when the PDUs are received by the WTRU within a duration / window. The duration / window may correspond, for example, to a time difference between a reception time of a first PDU (e.g., at t1) and a reception time of a second PDU (e.g., at t2) in the same QoS flow. For example, the duration / window may correspond to a time difference between a reception time of a PDU in the first QoS flow (e.g., at “t1”) and a reception time of a PDU in the second QoS flow (e.g., at “t2”). The WTRU may determine that a first and a second PDU in the same or different QoS flows are associated with an ADU when the time difference (e.g., t2-t1) is less than a duration / window threshold. In an example, the duration / window threshold may be associated with a frame rate (e.g., 60Hz, 120Hz) used by the application / higher layers to generate the ADUs / PDUs. The WTRU may determine that the first and second PDUs in one or more QoS flows are associated with an ADU based on a common format and / or granularity of timing information (e.g., timestamp, packet count, sequence number) carried in the PDUs.

[0176] The parameters / identifiers used by the WTRU to identify association of a PDU to an ADU may include spatial / attitude information within the associated flow. The WTRU may determine that a first PDU and / or a second PDU in one or more QoS flows are associated with an ADU when the PDUs carrying spatial information correspond to a common spatial parameter / ID. The spatial parameter / ID may include, for example, one or more of the following: direction and / or orientation of the FoV of the user / WTRU, slices and / or tiles of a video and / or media frame, location information (e.g., coordinates of the WTRU), and / or attitude information, etc. The spatial parameter / ID may be determined by the WTRU based, for example, on detection for a particular PDU carrying spatial information (e.g., attitude and / or control PDUs that may be identified by the WTRU based on a data type identifier) ​​or detection of other PDUs that may include spatial information within the PDU (e.g., in the header and / or payload).

[0177] The parameters / identifiers used by the WTRU to identify association of a PDU to an ADU may include an explicit indication from the application / upper layer / AS layer. The WTRU may determine that a first PDU and / or a second PDU in one or more QoS flows are associated with an ADU when the WTRU or a higher layer / AS layer in the network receives an explicit indication / message. In an example, the WTRU may receive timing information (e.g., periodicity, burst time window / duration) in the indication that the PDU is associated with the ADU. Other than the timing information (e.g., burst duration), the WTRU may assume that the PDU is uncorrelated and / or not associated with an ADU.

[0178] The WTRU may perform mapping of PDUs associated with ADUs in different QoS flows to forwarding configurations. The WTRU may use the mapping configuration to perform mapping of PDUs associated with ADUs in one or more QoS flows to one or more forwarding configurations based on the AS layer indication and the upper layer indication (e.g., as shown in FIG. 2). FIG. 2 illustrates an example of mapping PDUs associated with ADUs in different QoS flows to forwarding configurations. For example, as shown in FIG. 2, PDUs (e.g., S1-S10) of ADUs (e.g., video frames being viewed by a user) in a first QoS flow (e.g., Qflow1) and a second QoS flow (e.g., Qflow2) may be mapped to a first forwarding configuration (e.g., FwdConfig1), a second forwarding configuration (e.g., FwdConfig2), or a third forwarding configuration (e.g., FwdConfig3) based on a buffer occupancy threshold associated with the forwarding configuration and the application indication(s) (e.g., spatial importance value in the PDU header). The WTRU may perform mapping of PDUs of ADUs in a manner that may ensure that ADU-level QoS is met when transmitting the mapped data / PDUs in a transmission configuration in the UL.

[0179] To support such mapping of ADU PDUs, the WTRU may receive configuration information from the network (e.g., RRC) consisting of one or more transmission configurations (e.g., one or more DRBs or LCHs), where each (e.g., each) transmission configuration may be associated with one or more buffer occupancy thresholds. The WTRU may also receive a mapping configuration from the network to perform the PDU mapping. The mapping configuration may be applied at any of the AS layers in the WTRU, including SDAP, PDCP, RLC, MAC, or at another layer, e.g., as one or more sub-functions in the AS layer, as the case may be. The WTRU may also receive other configuration and / or assistance information from the network, as described herein. Additionally, the WTRU may possibly receive configuration / assistance information from higher layers / applications, which may be used by the WTRU to convert upper layer messages and / or indications (e.g., spatial / temporal importance values, QFIs) in the PDU / ADU header into identifiers / markers / information (e.g., priorities) that can be processed at the AS layer (e.g., SDAP, PDCP, RLC, MAC, PHY, or any other layer) when transmitting data / PDUs.

[0180] When receiving a PDU of an ADU, the WTRU may determine association of the PDU to an ADU, possibly in a different QoS flow, based on an indication / ID in the PDU (e.g., a sequence number / ID of the ADU in the header of the PDU that may be associated with the ADU) or other techniques (e.g., PDUs received within a time / burst window may be determined to be associated with the same ADU). For the PDUs in the QoS flow, which may be a subset or all PDUs belonging to the ADU, the WTRU may determine expected traffic information, such as an amount of data volume, when mapping the PDU to a first transmission configuration. The first transmission configuration may be applied, for example, to transmit data / PDUs identified / marked with an importance / priority value (e.g., spatial / temporal importance value in the PDU header) that is greater than or less than a threshold. The expected traffic information may include an expected amount of data in a buffer of the first transmission configuration, an expected data rate achievable during transmission of the PDU, an expected latency for transmitting the PDU, an expected priority applied in LCP procedures and / or other L2 / L1 procedures during transmission, and / or an expected reliability achievable, etc. Such expected traffic information may be determined, for example, based on one or more of the data / PDUs in the QoS flow, configuration parameters applied in the forwarding configuration, and / or load / traffic status information and / or assistance information received from the AS layer (e.g., from PDCP, RLC, MAC, PHY, RRC) or from the network. In an example, the WTRU may determine an expected amount of data when mapping PDUs from the QoS flow to the first forwarding configuration based on a total amount of data of the PDUs expected to be mapped and a total amount of data in a buffer of the forwarding configuration.

[0181] If the WTRU determines that the expected amount of data is less than a buffer occupancy threshold associated with the forwarding configuration, the WTRU may map the PDUs in the QoS flow to the forwarding configuration using the mapping configuration. If the WTRU determines that the expected amount of data is greater than a buffer occupancy threshold associated with the forwarding configuration, the WTRU may send an indication to the network, for example, to indicate the triggering of a potential buffer overload event. The WTRU may send the indication in AS layer signaling (e.g., an RRC message, a control PDU associated with any of the AS layers (e.g., SDAP, PDCP, RLC, etc.), MAC CE, or UCI). The indication sent by the WTRU may include any of the following information, for example: an ID of the forwarding configuration, an ID of the overload event, an amount of data overload / overflow, an expected delay due to the overload, a request for resources to handle the overload event (e.g., overloaded data, total data in buffer), and / or a priority / urgency associated with the overload event. The WTRU may determine how to address a potential buffer overload event based on the amount of data / PDUs in the QoS flow, the indication / marker (e.g., importance value) associated with the data / PDUs in the QoS flow, and the AS layer / network indication (e.g., amount of data or load in the forwarding configuration with respect to a buffer occupancy threshold). The WTRU may perform flow control by splitting / segmenting the data / PDUs in the QoS flow before mapping to the forwarding configuration or by controlling the amount of data mapped to the forwarding configuration to potentially mitigate any cost associated with not meeting ADU-level QoS and prevent buffer overflow events.

[0182] The WTRU may receive instructions from the network in AS layer signaling (e.g., RRC, control PDU, MAC CE, DCI), possibly after sending an instruction to the network, and the received instruction may indicate one or more of, for example, whether and how to split data / PDUs in the QoS flow, thresholds related to importance / priority marking to apply when splitting data / PDUs in the QoS flow, updated thresholds related to buffer occupancy to apply in the forwarding configuration, updated traffic information regarding achievable data rate / expected delay / expected reliability when transmitting data in the forwarding configuration, and / or radio resources (e.g., configured grants, dynamic grants, BWP, CC) to handle overload events, etc.

[0183] The WTRU may determine one or more sets of PDUs in a QoS flow based on an indication received from higher layers or in the PDU (e.g., importance / priority value indicated / marked in the PDU header) and / or other indication received from the AS layer / network. For example, the WTRU may determine a first set of PDUs for any PDUs in the QoS flow(s) that are indicated / marked with an importance / priority value greater than an importance threshold. Similarly, the WTRU may determine a second set of PDUs for any PDUs in the QoS flow(s) that are indicated / marked with an importance / priority value less than an importance threshold. The WTRU may then use a mapping configuration to map the first set of PDUs to a first transmission configuration and the second set of PDUs to a second transmission configuration. The first transmission configuration may be used to transmit PDUs of higher importance / priority (e.g., above the importance / priority threshold) and the second transmission configuration may be used to transmit PDUs of lower importance / priority (e.g., below the importance / priority threshold). Mechanisms for splitting / partitioning data / PDUs within a QoS flow based on the importance / priority indication associated with the PDU, possibly in a mapping configuration, may be applied to prevent buffer overload events in a forwarding configuration. Furthermore, splitting / partitioning PDUs in a QoS flow based on the importance / priority indication of the PDU may ensure that ADU level QoS (e.g., data rate, latency, reliability) is met by mapping the PDUs based on knowledge of the association of the PDUs to the ADUs and knowledge of the upper layer / AS layer indication.

[0184] The WTRU may transmit data / PDUs that are mapped to one or more transmission configurations using procedures at L2 (e.g., LCP, multiplexing, assembly into transport blocks) and / or L1 (e.g., modulation) and may use resource grants received from the network.

[0185] The WTRU may switch between different mapping configurations for mapping PDUs of an ADU to a transmission configuration. The WTRU may switch between different mapping configurations for mapping PDUs associated with an ADU to one or more transmission configurations, possibly upon detection of a QoS related event. A QoS related event may include a QoS surge event associated with an increase in the number of PDUs or amount of data, possibly over a time window, indicated / marked with high importance / priority. Similarly, another QoS event may include a QoS contraction event(s) associated with a decrease in the number of PDUs or amount of data, possibly over a time window. The WTRU may switch between different mapping configurations to ensure that ADU-level QoS is met when transmitting data / PDUs mapped in a transmission configuration in the UL.

[0186] To support switching between mapping configurations, the WTRU may receive configuration information from the network (e.g., RRC) including one or more of the following: one or more mapping configurations (e.g., including a first mapping configuration and a second mapping configuration); one or more transmission configurations (e.g., DRB, LCH, resource grants) where (e.g., each) transmission configuration may be configured with parameters (e.g., average data rate, latency, and reliability) to achieve a particular QoS during data transmission; and / or one or more thresholds indicating upper / lower limits for changing the QoS associated with the first mapping configuration (e.g., increasing or decreasing data / PDUs with high importance / priority or high QoS requirements).

[0187] The configuration information (e.g., RRC) that the WTRU receives from the network may include one or more mapping configurations. In an example, a first mapping configuration may be activated (e.g., in case of direct use without the WTRU needing to request activation) and a second mapping configuration may be deactivated (e.g., the WTRU may send a request for activation before use). The first mapping configuration may be used to handle average or expected data transmission scenarios where the amount of data / PDUs with different importance / priority levels mapped from the QoS flows and transmitted in the UL is within an average level (e.g., above and / or below a threshold amount / level). The second mapping configuration may be associated with and used during exceptional scenarios where the amount of data / PDUs with different importance / priority levels mapped from the QoS flows and transmitted in the UL is relatively higher / lower than the average / expected scenario. The mapping configuration may include mapping parameters / rules indicating how the M-to-N mapping relationship may be performed to map data / PDUs from the M QoS flows to the N transmission configurations. For example, a first mapping configuration may be associated with a first M-to-N mapping relationship (e.g., for a relatively small number of forwarding configurations) and a second mapping configuration may be associated with a second M-to-N mapping relationship (e.g., for a relatively large number of forwarding configurations). The WTRU may receive an authorized set of mapping parameters (e.g., parameter IDs) that may be modified by the WTRU when determining the second mapping configuration.

[0188] When receiving the ADU PDU, the WTRU may determine the association of the PDU to the ADU based on an indication / ID in the PDU (e.g., the ID of the ADU in the PDU header) or possibly in different QoS flows as described herein. The WTRU may apply a default / first mapping configuration for mapping the ADU PDU to one or more transport configurations based on default parameters in the mapping configuration. The WTRU may apply the mapping configuration at any of the AS layers in the WTRU, including SDAP, PDCP, RLC, MAC, or at another layer, e.g., as one or more of the sub-functions in the AS layer.

[0189] Upon determining / detecting a QoS event, the WTRU may initiate a procedure to (re)select or change the mapping configuration it applies to map PDUs to a forwarding configuration. The WTRU may determine the QoS event based on an indication received from an upper layer / AS layer (e.g., indicating an expected surge in high QoS PDUs or a change in achievable QoS at the AS layer) and / or based on indications / markings in PDUs in a QoS flow (e.g., the number of PDUs with high importance marking is greater than an importance threshold). The WTRU may first estimate the expected change in QoS (e.g., an increase in data rate, or an increase in latency) when using an existing (e.g., default / first) mapping configuration based on the data / PDUs in the QoS flow (e.g., data amount or number of PDUs with high importance indication / marking) and AS layer information associated with the load in the forwarding configuration (e.g., the status of other data / PDUs in the buffer with respect to the time elapsed since their arrival in the buffer, and the time remaining for transmission).

[0190] If the expected change in QoS is less than a threshold (e.g., the number of PDUs with high importance is less than a threshold), the WTRU may use the first mapping configuration to map the PDUs to the associated transmission configuration. If the expected change in QoS is greater / less than a threshold (e.g., the number of PDUs with high importance is greater than a threshold), the WTRU may determine whether the second mapping configuration can address the QoS event associated with the expected change in QoS. For example, the WTRU may determine whether by using the second mapping configuration, the number of PDUs with high importance in the QoS flow may be mapped to another transmission configuration that may result in ensuring that the expected QoS is below / above a threshold and preventing a QoS event. The WTRU may also determine an expected duration for the QoS event to last based on an indication from an upper layer / application, an amount of data / PDUs with high importance / priority in the buffer, and / or other AS layer indications. The WTRU may then determine a duration for which the second mapping configuration is activated based on the determined expected duration for the QoS event to last. The WTRU may determine mapping parameters to be applied in the second mapping configuration based on the configuration related to allowed parameters received from the network, the indication / marking in the PDU in the QoS flow, and the AS layer indication.

[0191] The WTRU may send a request to activate the second mapping configuration and / or an indication indicating the parameters to be applied in the second mapping configuration to the network. The WTRU may also send any of the following information in the indication: ID of the mapping configuration requested to be activated, ID of the mapping parameters to be changed / activated, ID associated with the QoS event, expected duration for using the second mapping configuration, amount or distribution of data / PDUs with different importance / priority levels, expected delay in mapping the data / PDUs to the transmission configuration, request for resources to handle the QoS event, and / or priority / urgency indication associated with the QoS event, etc. The WTRU may send the indication in AS layer signaling (e.g., RRC message, control PDU associated with any of the AS layers (e.g., SDAP, PDCP, RLC, etc.), MAC CE, or UCI).

[0192] The WTRU may receive an indication from the network in AS layer signaling (e.g., RRC, control PDU, MAC CE, DCI), and the received indication may indicate one or more of a deactivation indication to deactivate the first mapping configuration (ID), an activation indication to activate the second mapping configuration (ID), ID of the mapping parameters to be activated / deactivated, a validity condition for activating the second mapping configuration (e.g., time period / duration or detection of another QoS event), and / or any updated parameters associated with the forwarding configuration (e.g., updated LCP, priority, PBR, BSD), radio resources to address the QoS event (e.g., configured grant, dynamic grant, BWP, CC), etc.

[0193] After activating the second mapping configuration, the WTRU may perform mapping of ADU PDUs from the QoS flow to the forwarding configuration using parameters associated with the second mapping configuration. For example, the WTRU may start a timer when activating the second mapping configuration, and possibly be provided with a validity condition (e.g., period / duration) for the WTRU to use the second mapping configuration. The WTRU may fall back to using the first mapping configuration upon expiration of the timer (e.g., after deactivating the second mapping configuration). Alternatively, if the WTRU detects another QoS event (e.g., if the number of high importance PDUs in the QoS flow falls below a threshold), the WTRU may stop the timer, deactivate the second forwarding configuration, and / or fall back to using the first mapping configuration.

[0194] The WTRU may use resource grants received from the network to transmit data / PDUs that are mapped to one or more transmission configurations using procedures at L2 (e.g., LCP, multiplexing, assembly into transport blocks) and / or procedures at L1 (e.g., modulation).

[0195] The WTRU may determine a transmission configuration for transmitting the PDUs of the ADU while ensuring that the ADU-level latency requirement is met. The WTRU may determine one or more transmission configurations to apply when transmitting the PDUs associated with the ADU to meet the ADU-level latency requirement based on the time the PDUs are received by the WTRU. A transmission configuration configured with an appropriate set of parameters (e.g., priority, PBR, BSD, LCP) may be determined or selected by the WTRU such that PDUs received from the application / higher layer within a threshold time (e.g., deadline) are transmitted using a default transmission configuration (e.g., default priority). PDUs received after the threshold time may be transmitted using a different transmission configuration with a different set of parameters (e.g., high priority) to meet the ADU-level latency requirement.

[0196] The WTRU may receive configuration information from the network (e.g., RRC) to determine / select a transmission configuration. The configuration information may include one or more transmission configurations (e.g., DRB, LCH, resource grant) associated with different parameters and / or first and second threshold time values ​​for receiving PDUs from an application / higher layer. The different transmission configurations and / or parameters of the configurations received by the WTRU may be associated with achieving at least a default priority (e.g., to achieve expected / average latency associated with an ADU during normal transmission), a high priority (e.g., to achieve minimum latency for expedited transmission), and / or a best effort priority (e.g., to achieve higher latency than the average latency) during PDU transmission. The threshold time value may be associated, for example, with meeting an ADU-level latency requirement. The second threshold time may be a maximum latency acceptable for transmitting all PDUs associated with an ADU.

[0197] Upon receiving the first PDU, the WTRU may determine its association with the ADU and / or the reception time of the PDU based on the indication / marking in the PDU (e.g., ADU ID in the PDU header, timestamp, sequence number, packet count). The WTRU may start a timer after receiving the first PDU and allow the timer to run for a certain duration (e.g., up to a first threshold time value). The WTRU may select a transmission configuration with default parameters for transmitting the first PDU in the UL.

[0198] When receiving a second PDU associated with the ADU, the WTRU may determine a reception time of the PDU based on an indication / marking in the PDU (e.g., a timestamp in the header of the PDU, a packet count). The WTRU may also determine a reception time of the second PDU based on a timer that may be set, for example, after receiving the first PDU. The WTRU may also determine whether the second PDU is the last PDU associated with the ADU based on an indication / marking in the PDU (e.g., an ADU ID, a sequence number of the PDU, a PDU count number, a flag indicating the last PDU). If it is determined that the second PDU is not the last PDU associated with the ADU and the second PDU is received before the first threshold time (e.g., before expiration of the timer), the WTRU may select a transmission configuration with default parameters for transmitting the second PDU on the UL.

[0199] Alternatively, if the second PDU is received after the first threshold time (e.g., after expiration of a timer), the WTRU may determine / select a transmission configuration with parameters (e.g., high priority) that may enable the PDU to be transmitted with lower latency, possibly to compensate for delayed reception at the WTRU. For example, the WTRU may determine from the reception time of the second PDU an amount of latency reduction or compensation (e.g., time difference between the reception time and the first threshold time) that may be applied to expedite transmission of the PDU. The WTRU may determine / select a transmission configuration with parameters (e.g., priority) that are appropriate or consistent with the determined latency reduction / compensation. The WTRU may send an indication to the network (e.g., RRC, MAC CE, control PDU, UCI) consisting of any of the following information: An ID of the determined / selected transmission configuration, an ID of the parameters of the determined / selected transmission configuration, a request to activate the selected transmission configuration, a request to provide information of the appropriate transmission configuration, an amount of latency reduction / compensation for transmitting the delayed PDU, and / or a request for resources for transmitting the delayed PDU, etc. The WTRU may then transmit a second PDU using information related to the transmission configuration to apply (e.g., ID, parameters to apply) and a resource grant from the network after receiving the determined / selected transmission configuration and possibly an activation instruction.

[0200] If the second PDU is determined to be the last PDU associated with the ADU and the second PDU is received before the first threshold time (e.g., before the expiration of the timer), the WTRU may select a transmission configuration with default parameters for transmitting the second PDU in the UL. If the second PDU, which may be the last PDU of the ADU, is received by the WTRU after the first threshold time (e.g., before the expiration of the timer) and before the second time threshold, the WTRU may determine from the time of reception of the second PDU an amount of latency reduction or compensation (e.g., the time difference between the reception time and the first threshold time) that may be applied to facilitate transmission of the PDU. The WTRU may also determine an appropriate transmission configuration for transmitting the PDU and / or transmit an indication to the network to request to activate / provide information regarding the transmission configuration and / or resource grant. The WTRU may then transmit the second PDU using information regarding the transmission configuration to apply (e.g., ID, parameters to apply) and / or resource grant from the network after receiving the determined / selected transmission configuration and possibly an activation indication.

[0201] If a second PDU, which may be the last PDU of the ADU, is received by the WTRU after a second time threshold, the WTRU may determine an importance / priority indication / marking (e.g., in the PDU header). If the importance / priority indication is greater than a threshold (e.g., the threshold may be configurable by an application / higher layer in the WTRU), the WTRU may use a transmission configuration with best effort priority to transmit the PDU in the UL. Otherwise, if the importance / priority indication is less than a threshold, the WTRU may drop the PDU without transmitting it. The WTRU may send an indication to the network when dropping the PDU (e.g., in RRC, MAC CE, control PDU, UCI).

[0202] The WTRU may decide to change priority handling procedures / configurations to handle the QoS event. The WTRU may change to an alternative priority handling configuration (e.g., LCP configuration at the MAC layer) possibly upon detecting any QoS event for a duration such that any issues related to not being able to meet ADU-level QoS may be mitigated. The QoS event may include a sudden surge in the number of PDUs indicated / marked with high importance / priority.

[0203] The WTRU may receive configuration information from the network (e.g., RRC) to change the priority handling configuration, which may include one or more priority handling configurations (e.g., including at least a first LCP configuration and a second LCP configuration) and / or one or more durations / periods to control the duration for which the second LCP configuration may be applied. The first LCP configuration may be initially activated and the second LCP configuration may be deactivated. The first LCP configuration may be used to handle normal data transmission scenarios where the number of PDUs with different importance levels mapped from QoS flows and transmitted on the UL is within an average range (e.g., above and / or below a threshold amount / level). The second LCP configuration may be used when the number of PDUs with different importance / priority levels mapped from QoS flows and transmitted on the UL is relatively higher than normal scenarios (e.g., above a configured threshold). The second LCP configuration may also allow the priority handling procedure / policy to be modified to be biased towards one or more transport configurations / LCHs having data / PDUs with relatively high importance / priority (e.g., above a threshold number) from being fair to all transport configurations / LCHs having data / PDUs in their buffers.

[0204] When receiving a PDU of an ADU, the WTRU may determine the association of the PDU to the ADU, possibly in different QoS flows, based on the indication / ID in the PDU (e.g., the ID of the ADU in the PDU header). The WTRU may apply a default / first LCP configuration to transmit the PDU mapped to the corresponding forwarding configuration, which may be intended to satisfy the ADU-level QoS (e.g., latency, data rate).

[0205] Upon determining / detecting a QoS event, the WTRU may initiate a procedure to change the LCP configuration applied for transmitting the PDUs mapped to the transmission configuration. The WTRU may determine whether a QoS event occurs based on indications / markings in the PDUs in the QoS flow (e.g., the number of PDUs with high importance value is greater than a threshold).

[0206] If a QoS event is detected, the WTRU may change from using the first LCP configuration to the second LCP configuration. The WTRU may also start a timer that may run for a duration that is estimated based on a duration indicated in the received configuration information or a duration that may be applied to transmit a number of PDUs with a high importance value before transmitting other associated PDUs with a lower importance value. In an example, the WTRU may determine the duration for using the second LCP configuration based on any indication from a higher layer / application indicating the duration for which the QoS event will last.

[0207] The WTRU may send an indication to the network to indicate a request to use / activate the second LCP configuration. The WTRU may also send in the indication one or more of the ID of the LCP configuration requested to be activated or used by the WTRU, the expected duration for using the second LCP configuration, a distribution of the number of data / PDUs having different importance / priority levels, and / or a priority / urgency indication associated with the QoS event, etc. The WTRU may send the indication in AS layer signaling (e.g., an RRC message, a control PDU associated with any of the AS layers, a MAC CE, or a UCI).

[0208] The WTRU may receive from the network in AS layer signaling (e.g., RRC, control PDU, MAC CE, DCI) an indication indicating one or more of a deactivation indication to deactivate the first LCP configuration (ID), an activation / confirmation indication to activate / use the second LCP configuration (ID), and / or one or more validity conditions for using the second LCP configuration (e.g., duration / duration or detection of another QoS event).

[0209] After activating the second LCP configuration, the WTRU may transmit high importance PDUs in a corresponding transmission configuration with the priority / policy / procedure associated with the second LCP configuration. The WTRU may use the second LCP configuration until expiration of a timer, which may be set when activating the second LCP configuration. Upon expiration of the timer, the WTRU may fall back to using the first LCP configuration, e.g., after deactivating the second LCP configuration. Alternatively, if the WTRU detects another QoS event (e.g., if the number of high importance PDUs in a QoS flow falls below a threshold), the WTRU may stop the timer, deactivate the second LCP configuration, and / or fall back to using the first LCP configuration.

[0210] When the WTRU detects a triggering event / condition, it may change configuration parameters at the PHY and / or MAC layers to transmit the PDU / ADU. In an example, the WTRU may modify one or more configuration parameters associated with the PHY and / or MAC layers to achieve an expected QoS when transmitting the PDU / ADU. The WTRU may modify configurations applied for link adaptation, including adjustments / offsets to transmit power, transmission scheme, MCS, coding rate, etc.

[0211] In an example, the WTRU may be configured with one or more transmit power levels (e.g., via higher layer signaling and / or PHY layer signaling), where the transmit power levels may be expressed in terms of a ratio to a maximum transmit power level, possibly based on a number of resource blocks. Upon detecting any triggering event / condition (e.g., as described herein), the WTRU may select and / or use an appropriate transmit power level based on a determined expected QoS (e.g., latency, data rate, reliability) for transmitting the PDU / ADU. For example, the WTRU may use a higher transmit power level to increase reliability and / or reduce the number of HARQ retransmissions when determining a lower latency budget for transmitting a PDU in the UL.

[0212] A WTRU, which may be configured with a first and second set of MCS, coding and / or spatial transmission schemes (e.g., MIMO schemes with different layers and / or number of antenna ports), may transition to using a second set of MCS / coding / spatial schemes from the first set upon detecting any of the triggering events described herein. For example, the WTRU may use a higher order modulation set with a lower coding rate and higher rank for spatial multiplexing to transmit PDUs at a higher rate (e.g., even if the CSI is unfavorable). The rules for using the appropriate set of MCS / coding / spatial schemes upon detecting a triggering event may be configured in the WTRU by the network via higher layer signaling (e.g., RRC).

[0213] In an example related to changing intra-WTRU multiplexing behavior, the WTRU may change the rules for multiplexing of PDUs based on different priorities associated with buffers including buffers in the SDAP, PCDP, RLC, MAC (e.g., LCH) or any other layer upon detecting any triggering event. In an example related to multiplexing in MAC, if there is an overlap of PSSCH resources between a low priority LCH (e.g., carrying eMBB PDUs), a high priority LCH (e.g., carrying URLLC PDUs), and an LCH carrying PDUs with high importance marking, the WTRU may cancel multiplexing of PDUs in the low priority LCH in favor of PDUs with high importance marking and / or high priority for transmission in the UL.

[0214] Mapping restrictions in the WTRU for mapping between a transmission configuration / LCH and one or more resource pools / BWPs may be modified / relaxed such that upon detection of any of the triggering events / conditions, the WTRU may transmit a PDU in an LCH by accessing an appropriate resource from the restricted resource pool. For example, rules associated with mapping from a transmission configuration / LCH to a resource having a maximum PSSCH duration may be modified such that the WTRU may access resources that may not normally be associated with an LCH to transmit a PDU with a high importance value as long as such PDU is transmitted within the maximum PSSCH duration.

[0215] The WTRU may be configured with sublayers / entities in the access stratum to handle delivery of PDUs at the granularity of PDU sets. For example, a PDU set may include one or more PDUs associated with a (e.g., one) unit of information generated in an application and subject to a per-PDU set level of quality of service (QoS). In an example, the WTRU may be configured to support one or more (e.g., any) sublayers, entities, and / or functions in the access stratum to satisfy QoS during UL transmission and / or DL ​​reception while ensuring the integrity of the PDU set. The configurations supported by the WTRU may refer to any of the layers / sublayers / entities in the access stratum, including, but not limited to, SDAP, PDCP, RLC, MAC, and PHY. A PDU set may refer to an ADU or one or more PDUs within an ADU. In this specification, PDU set and ADU may be used interchangeably when referring to a set of PDUs that may be associated with one or more QoS parameters (e.g., latency, data rate, priority) that may be satisfied based on the PDU set. For example, a latency requirement for a PDU set may be met when the Nth or last PDU in a PDU set of N PDUs is transmitted and / or received within a PDU Set Delay Boundary (PSDB). For example, a reliability requirement for a PDU set (e.g., PDU Set Error Rate (PSER)) may be met when a certain number of PDUs in one or more of the transmitted PDUs in a PDU set are received correctly (e.g., without error) at a receiving entity (e.g., a base station in the UL or a WTRU in the DL) and possibly within the latency requirement (e.g., PSDB).

[0216] In an example, a WTRU may be configured with one or more SDAP sublayers / entities for ensuring QoS during transmission and / or reception based on one or more PDU sets. To enable this, the WTRU may perform, in the SDAP entity, a mapping between QoS flows and data radio bearers, and / or marking of QoS flows in the UL and / or DL.

[0217] The WTRU may perform mapping between QoS flows and data radio bearers in the SDAP entity. For example, the WTRU may map one or more PDUs associated with a PDU set in a QoS flow received from a higher layer / application to one or more configured radio bearers. Such mapping may be performed based on an indication / marking in the PDUs received in the QoS flow and / or a mapping rule for mapping from QoS flows to radio bearers configured in the WTRU. For example, the WTRU may identify the start of a PDU set when it identifies the start of a new ID / marking or sequence number (SN) set (e.g., in a header of the PDU) associated with the PDU set. The WTRU may map one or more (e.g., all) PDUs with similar ID / marking / SN associated with the PDU set to the same radio bearer.

[0218] The WTRU may map the PDUs associated with a PDU set in a QoS flow to one or more radio bearers based on the QoS indication / marking in the PDUs. For example, the WTRU may map the PDUs in a PDU set to radio bearers based on the priority / importance value indicated in the PDU (e.g., PDU header). Such segmentation of the PDUs in a PDU set during mapping may be performed to ensure differentiated QoS and forwarding treatment. When segmenting and mapping the PDUs, the WTRU may include an indication in the SDAP header (e.g., ID, SN) such that the integrity of the PDU set is preserved during transmission.

[0219] The WTRU may perform a mapping of the PDUs associated with a PDU set to one or more radio bearers, which may be configured and / or dedicated to handle the transport of the PDU set. Such dedicated radio bearers, which may be identified by a set of IDs, may be the same as or different from the radio bearers used to transport conventional PDUs, which may not be associated with any PDU set and / or QoS requirements for the PDU set (e.g., PDU set latency bounds, PDU set error rate).

[0220] The WTRU may perform marking of QoS flows in the UL and / or DL ​​at the SDAP entity. For example, the WTRU may include one or more markings (e.g., indication, ID, SN) in PDUs (e.g., PDU headers) associated with a PDU set to possibly identify and / or ensure the integrity of the PDU set during processing at lower layers (e.g., PDCP, MAC) and / or higher layers (e.g., NAS). Such markings may be included, for example, in the SDAP header. Such markings may be performed by the WTRU based on configuration information (e.g., RRC) and / or assistance information received from the network. In another example, such markings may be performed based on detection of indications / markings (e.g., QFI ID, PDU set ID, SN, IP header markings) identified from SDUs / PDUs received from higher layers.

[0221] In an example, the WTRU may include markings associated with the PDU set based on a reflective QoS approach, where the WTRU may include markings (e.g., QFI, PDU set ID) for PDUs transmitted in the UL based on markings identified in PDUs received in the DL over the corresponding radio bearer.

[0222] The WTRU may be configured with one or more PDCP sublayers / entities for handling data transfer based on one or more PDU sets. To enable this, the WTRU may perform one or more of the following in the PDCP entities: maintaining PDCP sequence numbers (SNs); reordering and in-order delivery and / or discarding one or more PDU sets based on deadlines.

[0223] The WTRU may perform PDCP sequence number (SN) maintenance in the PDCP entity. For example, the WTRU may include SNs (e.g., start SN, intermediate SN, and / or end SN) in one or more PDUs / SDUs received from the SDAP / higher layer based on the association of the PDUs to a PDU set. The SNs for the PDU sets added by the WTRU may be generated using a similar or different configuration to that used to generate SNs for conventional PDUs (e.g., PDUs that are not associated with any PDU set).

[0224] In an example, the SN for a PDU set added by the WTRU may include a PDU set level ID / SN (e.g., an ID / SN associated with the PDU set), which may be common to one or more (e.g., all) PDUs associated with the PDU set and / or PDU level ID / SN. For example, a PDU set of N PDUs may include one or more of the following SN / IDs: 1st PDU{set level SN:1, PDU level SN:1}, 2nd PDU{set level SN:1, PDU level SN 2}, ..., Nth PDU{set level SN:1, PDU level SN:N}.

[0225] The SN for the PDU set added by the WTRU can ensure in-order delivery of the PDUs in the PDU set. For example, the receiving PDCP entity can reorder the received PDUs in the PDU set (e.g., in ascending order) based on the PDU-level and / or PDU-set-level SNs added by the transmitting PDCP entity. Such reordering of the PDUs may be performed by the receiving PDCP entity before transmitting the ordered PDUs in the PDU set to upper layers. The SN for the PDU set may be included in the PDCP header appended to each PDU.

[0226] The WTRU may perform reordering and in-order delivery in the PDCP entity. For example, the SNs for the PDU set added by the WTRU may ensure in-order delivery of the PDUs in the PDU set. For example, the receiving PDCP entity may reorder the received PDUs in the PDU set (e.g., in ascending order) based on the PDU-level and / or PDU-set-level SNs added by the transmitting PDCP entity. Such reordering of the PDUs may be performed by the receiving PDCP entity before transmitting the ordered PDUs in the PDU set to upper layers.

[0227] In an example, the transmitting and / or receiving PDCP entity may be configured with a reordering timer. Such a timer may be used to ensure that reordering of PDUs in a PDU set is performed at the receiving PDCP entity before expiration of the timer. If one or more PDUs in the PDU set are not received before expiration of the timer, the receiving PDCP entity may do one or more of the following: i) do not transmit the received PDUs to higher layers and / or discard the received PDUs in the PDU set; ii) send an indication (e.g. in a PDCP control PDU, MAC CE, DCI) to the transmitting entity (e.g. PDCP entity, MAC entity) indicating the status (e.g. ID / SN) of the received and / or not received PDUs; iii) transmit the received PDUs to higher layers and / or send a status indication of the received / not received PDUs; and / or iv) decide whether to extend the timer and / or send an indication to request delayed / lost PDUs based on the priority / importance ID / indication of the PDUs in the PDU set.

[0228] The WTRU may discard one or more PDU sets based on a deadline in the PDCP entity. In an example, the transmitting and / or receiving PDCP entities may be configured with a discard timer. Such a timer may be used to ensure that the PDUs in a PDU set are transmitted and / or received within a deadline. For example, a transmitting entity (e.g., a transmitting PDCP entity) may start a discard timer upon transmitting one or more PDUs of a PDU set, and the duration of the discard timer may be configured to be aligned with a delay boundary for transmitting the PDUs of the PDU set. In this case, if the transmitting entity receives a status indication (e.g., an ACK / NACK) from a receiving entity (e.g., a receiving PDCP entity) before expiration of the discard timer, the transmitting entity may stop / reset the discard timer and / or transmit the remaining PDUs in the PDU set (e.g., when an ACK is received) or retransmit a previous PDU (e.g., when a NACK is received). Otherwise, the transmitting entity may, for example, discard the remaining PDUs of the PDU set. In another example, a receiving entity (e.g., a receiving PDCP entity) may start a discard timer upon receiving one or more PDUs of the PDU set and / or after sending a status indication (e.g., ACK / NACK) to the transmitting entity. In this case, if the receiving entity receives a new PDU in the PDU set and / or a retransmitted PDU in the PDU set before the discard timer expires, it may stop / reset the discard timer and send the received PDU to upper layers. Otherwise, the receiving entity may discard the received PDU of the PDU set.

[0229] The WTRU may be configured with one or more MAC sublayers / entities for handling data transfer based on one or more PDU sets. One or more of the following may be performed by the WTRU in the MAC entity: configuration of LCH(s); mapping between logical channels and transport channels; multiplexing / demultiplexing of MAC SDUs / PDUs; scheduling information reporting; error correction with HARQ; priority handling between the WTRU's logical channels (e.g., via LCP); and / or priority handling between overlapping resources.

[0230] The WTRU may perform configuration of the LCH in the MAC entity. In an example, PDUs of a PDU set may be configured to be received from higher layers (e.g., RLC layer, PDCP layer) on one or more LCHs. LCH parameters (e.g., priority, BSD, PBR, LCH mapping restrictions) may be applied on a per-PDU set basis. For example, one or more of the following may be configured for different LCH parameters for processing the PDU set(s): PDU set priority (e.g., the same or different priority values ​​may be applied to one or more (e.g., all) PDUs in a PDU set); PDU set maxPUSCH duration (e.g., the maximum PUSCH duration may correspond to the total duration for transmitting one or more (e.g., all) PDUs in a PDU set); PDU set BSD (e.g., the BSD may correspond to the total BSD used when mapping / multiplexing one or more (e.g., all) PDUs in a PDU set); PDU set PBR (e.g., the PBR may correspond to the total PBR used when mapping / multiplexing one or more (e.g., all) PDUs in a PDU set); and / or one or more PDU set LCH mapping restrictions (e.g., the same or different LCH mapping restrictions may be applied to one or more (e.g., all) PDUs in a PDU set).

[0231] The WTRU may perform mapping between logical channels and transport channels at the MAC entity. For example, the WTRU may be configured with mapping configurations / rules / restrictions to perform mapping of PDUs associated with a PDU set in one or more logical channels to one or more transport channels. In an example, the WTRU may perform a one-to-one mapping between a logical channel containing PDUs of a PDU set to a (e.g., one) transport channel based on the configured mapping rule. In another example, the WTRU may be configured with mapping rules / restrictions to perform N-to-1, 1-to-M, or N-to-M mapping of PDUs associated with a PDU set in one or more LCHs to one or more transport channels. For example, when configured with 1-to-M mapping, the WTRU may map PDUs of a PDU set in one LCH to multiple transport channels, possibly based on a total payload or PDU count threshold associated with the transport channel. In this case, the (e.g., each) transport channel may be configured with a threshold corresponding to an allowed or available resource grant size. In another example, when configured with N-to-1 mapping, the WTRU may map PDUs of a PDU set received on multiple LCHs to a (e.g., one) transport channel, possibly based on a PDU set ID marking / indication in the PDU. Such mapping may be performed such that one or more (e.g., all) PDUs of a PDU set are transmitted in the same transport channel via one or more transport blocks.

[0232] The WTRU may perform multiplexing / demultiplexing of MAC SDUs / PDUs in a MAC entity. For example, the WTRU may be configured with rules / restrictions to support multiplexing / demultiplexing of one or more PDUs of a PDU set when mapping PDUs in a logical channel to transport blocks (TBs) in a transport channel, as the case may be. For example, the WTRU may be configured with multiplexing rules that indicate whether PDUs associated with a PDU set are multiplexed into the same or different transport blocks based on the type of PDU set, the total payload size of the PDU set, the number of PDUs in the PDU set, and / or the QoS requirements of the PDU set (e.g., latency, error rate, bit rate, priority), etc.

[0233] The WTRU may perform scheduling information reporting at the MAC entity. For example, the WTRU may trigger the transmission of an SR to request PUSCH resources for transmitting a BSR (e.g., new or normal MAC CE) when a new PDU set including one or more PDUs is received on an LCH (e.g., in a buffer of an LCH). The WTRU may transmit an SR when there are no available PUSCH resources, for example, corresponding to the LCH / LCG on which the PDU set was received or corresponding to another LCH / LCG with a lower priority, as the case may be. A new SR associated with a PDU set may be different from a conventional SR, which may not be associated with any PDU set.

[0234] In an example, the WTRU may trigger the transmission of a BSR when a new PDU set containing one or more PDUs is received in an LCH (e.g., a buffer of an LCH). In this case, the WTRU may transmit a BSR when other LCHs have empty buffers and / or when the LCH receiving the new PDU set has a higher priority than other LCHs, which may have previously triggered the transmission of an SR / BSR, e.g., due to the arrival of data. The WTRU may transmit a BSR on a per-LCG basis, which may be associated with the LCH on which the new PDU set is received. In an example, the WTRU may transmit a new BSR after the arrival of the first and / or last PDU associated with the PDU set in the LCH buffer. For example, the WTRU may start a counter upon receiving the first PDU associated with the PDU set and / or transmit a new BSR when the counter value is greater than or less than a preconfigured threshold. In another example, the WTRU may be preconfigured with a threshold corresponding to the total payload size of the PDU set (e.g., the sum of the payloads of one or more PDUs in the PDU set). The WTRU may transmit a new BSR when the total payload size of the PDU set is greater than or less than a preconfigured threshold.

[0235] The WTRU may send a BSR when a first PDU associated with a PDU set is received, and the BSR may indicate the expected payload of the PDU set and / or the number of PDUs expected in the PDU set. The WTRU may determine the expected payload and / or the number of PDUs in the PDU set based on a marking / indication (e.g., a PDU header) in the first PDU, possibly indicating a type of PDU set (e.g., I / P / B frame), and / or association information configured in the WTRU, possibly indicating a mapping between the type of PDU and the expected payload size / number of PDUs.

[0236] In an example, the WTRU may transmit different types of BSRs associated with requesting dynamic permission(s) for UL transmission of the PDUs in the PDU set. Such BSR types may include an event-triggered / regular BSR (e.g., transmitted by the WTRU when the PDUs of the PDU set arrive in the LCH buffer) or a periodic BSR (e.g., transmitted by the WTRU periodically to request UL permission for periodic transmission of the PDUs in the PDU set). In case of a periodic BSR, the periodicity applied for transmitting the BSR may be configured such that it may be aligned with the periodicity of the PDU set arrival from higher layers (e.g., the frame rate used by the codec, or the frame rate of the attitude data). The WTRU may send an indication to the network (e.g., in the RRC, MAC CE, UCI) to indicate the data arrival rate (e.g., frame rate) during initial configuration or when a change in the arrival rate is detected, so that the WTRU is configured with a periodic BSR with a particular periodicity value.

[0237] In an example, the WTRU may trigger transmission of an SR and / or a BSR (e.g., a preemptive BSR) based on expected arrival times and / or expected payload sizes of PDUs in the PDU set. For example, the WTRU may know and / or be configured with information regarding arrival times of PDUs in the PDU set (e.g., from higher layers). Such arrival times may be associated with arrival of periodic data, and the periodicity of the data may be aligned with a frame rate applied in a higher layer / application / codec. Based on an estimate of the arrival times of the PDUs, the WTRU may trigger transmission of an SR / BSR, possibly preemptively, to request UL permission to transmit a PDU after the PDU expected to be received. The WTRU may also estimate / predict payload sizes of expected PDUs in the PDU set based on tracking of previously received / transmitted PDUs and / or based on markings / indications in the PDUs (e.g., in the PDU header). To enable triggering of such SR / BSR, which may be preemptively transmitted prior to the arrival of data, the WTRU may be configured with one or more thresholds associated with an estimation / prediction of the data arrival time and / or the payload size of the expected data. The WTRU may trigger the SR / BSR when the estimated arrival time is higher, lower, or within a range of the threshold. The WTRU may trigger the SR / BSR when the estimated payload size of an expected PDU in the PDU set is higher, lower, or within a range of the threshold.

[0238] In an example, the WTRU may trigger transmission of multiple SRs / BSRs for receiving multiple dynamic grants to enable the WTRU to transmit one or more PDUs of a PDU set, possibly with a high total payload size and / or low latency. The WTRU may perform transmission of the PDUs in the PDU set in the UL, possibly using multiple TBs, which may be transmitted consecutively or within low latency. Such transmission over the multiple TBs may be performed based on the allocation of multiple dynamic grants. In this case, the WTRU may transmit a first BSR when receiving the PDUs of the PDU set in the buffers of one or more LCHs and the total payload size or PDU count is higher than a first threshold. The WTRU may then transmit a second BSR, for example, when the total payload or PDU count is higher than a second threshold. The first threshold may be associated with a default / average value corresponding to the total payload size or PDU count, and the second threshold may be associated with a higher than average or excess payload size, or excess PDU count, which may take into account variable PDUs in the PDU set. The WTRU may receive resource allocation in one or more dynamic grants, where a first dynamic grant may be used to transmit a default / average number of PDUs and a second dynamic grant may be used to transmit excess PDUs.

[0239] The WTRU may perform error correction through HARQ in the MAC entity. For example, the WTRU may be configured with one or more HARQ entities (e.g., per cell or per carrier), where the one or more (e.g., each) HARQ entities may handle one or more HARQ processes associated with the transmission and / or retransmission of PDUs associated with the PDU set. The HARQ processes configured for handling the (re)transmission of PDUs associated with the one or more PDU sets may be identified using a HARQ process ID, which may be the same as or different from the HARQ process ID associated with normal PDUs (e.g., which may not be part of any PDU set(s)). A HARQ process may be associated with the (re)transmission of one or more PDU sets, in which case the ID of the HARQ process may be associated with the ID of the PDU set and possibly used during the transmission of the PDUs (e.g., in the PDU header or MAC CE).

[0240] When the WTRU is configured with a HARQ entity at the transmitting entity (e.g., transmitting MAC entity at the WTRU) to handle (re)transmissions of the PDU set via a HARQ process, a corresponding HARQ entity at the receiving entity (e.g., receiving MAC entity in a gNB) may transmit a status indication (e.g., ACK / NACK) to the transmitting entity based on one or more PDUs and / or based on the PDU set. The receiving entity may transmit an ACK message, possibly with a PDU set ID and / or a HARQ process ID, to the transmitting entity (e.g., only when one or more (e.g., all) PDUs of the PDU set are successfully received / decoded at the receiving entity. Otherwise, when one or more PDUs are not successfully received / decoded, the receiving entity may transition a NACK message to the transmitting entity, possibly with a PDU ID, PDU set ID, and / or HARQ process ID. The receiving entity may transmit a NACK message when one or more PDUs of the PDU set are not successfully received / decoded before expiration of a configured timer.

[0241] In an example, when a WTRU is configured with HARQ per PDU set, the number of retransmissions allowed per PDU of the PDU set may be configured based on a PDU Set Delay Boundary (PSDB) and / or a PDU Set Error Rate (PSER) associated with the PDU set. For example, the number of HARQ retransmissions allowed per PDU in a PDU set may be determined as the PSDB divided by the product of the latency per retransmission and the number of PDUs per PDU set.

[0242] In another example, the number of allowed retransmissions may depend on the type of PDUs in the PDU set and / or the PDU set. For example, for a PDU set associated with an I frame, the WTRU may be configured with K1 allowed retransmissions, and for a PDU set associated with a P / B frame, the WTRU may be configured with K2 allowed retransmissions, where K2 may be greater than, equal to, or less than K1. For example, PDUs in a PDU set with an importance / priority value above a threshold may be transmitted with N1 allowed retransmissions, and PDUs with an importance / priority value below a threshold may be transmitted with N2 allowed retransmissions. One or more PDUs to be transmitted, including the first and second PDUs of the PDU set, may be transmitted with M1 retransmissions. Similarly, one or more PDUs to be transmitted, including the third and fourth PDUs of the PDU set, may be transmitted with M2 retransmissions, where the values ​​of M1 and M2 may depend, for example, on the importance / priority values ​​associated with the PDUs of the PDU set.

[0243] The WTRU may perform priority handling among its logical channels in the MAC entity (e.g., via the LCP). The WTRU may be configured to guarantee a PDU set-level delay bound (PSDB) during transmission of one or more PDUs of a PDU set by performing a priority handling procedure via the LCP. For a PDU set consisting of N PDUs, the WTRU may transmit the N PDUs within the configured PSDB value.

[0244] In an example, the WTRU may be configured by the network with a PDB value per PDU and / or with a priority value associated with the LCH carrying the PDU. The PDB value per PDU may be determined by dividing the PSDB by the number of PDUs in the PDU set. Such a PDU PDB value and / or associated priority value may enable the N PDUs in the PDU set to be transmitted within the PSDB value. To enable such transmission within the PSDB, the WTRU may indicate information regarding the number of PDUs per PDU set to the gNB. The information regarding the number of PDUs may be determined by the WTRU and / or indicated to the network semi-statically (e.g., in RRC) and / or dynamically (e.g., in RRC, MAC CE, DCI), based on detection of markings / indications in the PDUs of the PDU set, higher layer configurations / indications (e.g., whether the PDU set corresponds to an I-frame / P-frame), etc. Based on such information, the WTRU may receive from the network configuration information or activation / deactivation instructions regarding configuration parameters (e.g., priority, PBR, BSD, LCH limit) of the LCH that may be used to ensure PSDB of the PDU set.

[0245] The WTRU may be pre-configured with one or more LCHs with different LCH parameters (e.g., priority, PBR, BSR, LCH mapping restrictions). The WTRU may also be configured with one or more thresholds possibly associated with PDU counts. The WTRU may send an indication to the network (e.g., in MAC CE, SR / BSR) when the number of PDUs in a PDU set received from higher layers is greater than or less than a PDU count threshold. The WTRU may receive an indication from the network indicating activation / deactivation of a pre-configured LCH configuration that may be used to transmit PDUs in a PDU set in the PSDB.

[0246] The WTRU may be configured with rules / restrictions indicating which of the LCH configurations are used to transmit the PDUs in a PDU set for one or more PDU count values ​​and / or for different PSDB values. In this case, the WTRU may use a first set of LCHs when the PDU count in the PDU set is less than or greater than a first PDU count threshold or within a first PDU count range. Similarly, the WTRU may use a second set of LCHs when the PDU count in the PDU set is less than or greater than a second PDU count threshold or within a second PDU count range.

[0247] The WTRU may be configured to track the remaining latency (e.g., the difference between the PSDB and the actual latency) to transmit one or more remaining PDUs in the PDU set. The WTRU may select one or more appropriate LCHs with preconfigured parameters (e.g., priority, PBR) for the remaining PDUs to be transmitted in the PSDU. In this case, the WTRU may be configured with one or more timers that may be set after transmitting the first PDU of the PDU set. The WTRU may then perform the selection of the appropriate LCH when the number of remaining PDUs in the PDU set is greater than a threshold upon expiration of the timer.

[0248] The WTRU may perform priority handling among overlapping resources in the MAC entity. The WTRU may be configured with one or more resource configurations, including configured grants, bandwidth portions, carriers, cells, etc. Such resource configurations may be associated with different priority values. The WTRU may determine whether to use one or more resource configurations to transmit PDUs in a PDU set based on identifying a priority value of the resource configuration that matches a priority / importance value of the PDU and / or PDU set. For example, the WTRU may use a first resource configuration when the priority value associated with the PDU set is greater than a threshold and a second resource configuration when the priority value associated with the PDU set is less than a threshold. When the same resource or resource configuration assigned to one or more PDUs that are not part of any PDU set overlaps with one or more PDUs of the PDU set, the resource or resource configuration may be used even if any PDU has a higher priority.

[0249] In an example, the WTRU may be configured with one or more mapping restrictions that indicate whether the PDUs of the PDU set of the LCH may be mapped to one or more configured grant (CG) configurations. In this case, the LCH carrying the PDUs of the PDU set may be initially configured with a set of default CG and / or alternative CG configurations. Different CG configurations may be associated with different priority values. When the PDU set received on the LCH has a priority value lower than a threshold priority value, the WTRU may use the default CG. When the priority value of the PDU set is above the threshold priority value, the WTRU may use a second CG configuration, which may be selected from the set of alternative configurations based on the associated priority value.

[0250] The WTRU may change CG / SPS configuration parameters and / or select a CG / SPS configuration for (re)aligning with data transmission / reception. A WTRU configured with one or more configured grants (CG) and / or semi-persistent grants (SPS) configurations may periodically change parameters associated with the CG / SPS configurations based on a realignment periodicity value for realigning with periodic data transmission / reception. Alternatively, the WTRU may periodically select a new CG / SPS configuration based on one or more CG configurations (e.g., for UL transmission) and / or SPS configurations (e.g., for DL ​​reception), a realignment periodicity value.

[0251] The WTRU may be configured by the network with a default / initial CG / SPS configuration(s) and / or a default set of parameters associated with the CG / SPS configurations, which the WTRU may use initially upon receiving the configuration from the network. The WTRU may also be configured with a set of alternative CG / SPS configurations, parameters, and / or parameter values, to which the WTRU may change periodically based on a configured realignment periodicity value. Either the CG / SPS configurations or CG / SPS parameters may be used by the WTRU to transmit data in the UL or receive data in the DL in one or more data flows.

[0252] Parameters associated with a CG / SPS configuration configured in a WTRU may include, for example, one or more of an offset start timeslot for starting use of the CG / SPS resources, a periodicity of the CG / SPS resources in the corresponding CG / SPS configuration, an on / active duration associated with the CG / SPS resources (e.g., the number of consecutive time / frequency resources that the WTRU can use), and / or a stop timeslot for stopping use of the CG / SPS resources.

[0253] When changing any of the CG / SPS parameters or selecting a new CG / SPS configuration, the WTRU may send an indication to the network (e.g., via an RRC message, MAC CE, UCI) to indicate the parameter change (e.g., ID and / or value of the CG / SPS parameter) and / or configuration change (e.g., ID of the CG / SPS configuration). The WTRU may use the corresponding updated parameters or new CG / SPS configuration upon receiving a confirmation indication from the network and / or after expiration of a configured duration. If a reject indication is received from the network, the WTRU may fall back to using a default / initial CG / SPS configuration and / or a default set of parameters.

[0254] In an example, the parameters of the CG / SPS configuration may be associated with a frame rate corresponding to data expected to be transmitted / received by the WTRU. For video data having a frame rate of 60 frames per second (fps), the WTRU may be expected to transmit one or more PDUs in a PDU set associated with a frame in the UL periodically with a periodicity value of 1 / 60 or 16.66 ms. To transmit such video data, the WTRU may be configured with one or more CG configurations having periodicity values ​​of, for example, 16 ms and 2 ms for the on / active duration. When using such a CG configuration, after a number of timeslots / opportunities in which the WTRU transmits data in the UL during the on / active duration, the CG configuration may become misaligned with respect to the frame rate, possibly due to a non-integer periodicity value corresponding to the frame rate. In this case, the WTRU may be configured with a realignment periodicity value of, for example, 64 ms, so that it may periodically change one or more (e.g., either) of the parameters (e.g., offset start timeslot or on / active duration) and / or select a new CG configuration. The configured realignment periodicity applied by the WTRU may be based on assistance information, such as frame rate, provided by the WTRU to the network. The WTRU may be configured with a CG / SPS configuration and / or a realignment periodicity based on assistance information (e.g., frame rate) provided by the WTRU to the network.

[0255] The WTRU may change parameters associated with a CG / SPS configuration or select a new CG / SPS configuration upon detecting a triggering event, which may be one or more of the following: connectivity / session (re)configuration; receiving higher layer and / or application layer indication; modifying and / or updating data flows per application; measuring jitter; measuring radio links; detecting a change in the WTRU's mobility, and / or changing a power saving configuration.

[0256] The WTRU may change parameters associated with a CG / SPS configuration or select a new CG / SPS configuration when it detects connectivity / session (re)configuration. For example, the WTRU may change parameters when it receives / transmits any signaling message associated with RRC connection, RRC state, PDU session, and / or application layer session (re)configuration and / or when it changes the RRC state from RRC CONNECTED to RRC INACTIVE / IDLE or vice versa.

[0257] The WTRU may change parameters associated with a CG / SPS configuration or select a new CG / SPS configuration upon detecting receipt of a higher layer / application layer indication. For example, the WTRU may change parameters upon receiving an indication from a higher layer, a PDU (e.g., a marking in a header) or from the network indicating any of the following changes in the next data that may be transmitted / received using any of the CG / SPS configurations: data type (e.g., next frame change from P / B frame to I frame); failed higher layer frame (e.g., application layer failed to decode an I frame); traffic characteristics (e.g., number of PDUs in a PDU set is expected to be above or below a threshold, PDB or PSDB is expected or predicted to be above or below a threshold, PER or PSER is expected to be above or below a threshold, frame rate is above or below a threshold, etc.); priority of the data (e.g., priority value of a PDU or PDU set is expected to be above / below a threshold, and / or QFI or any QoS indication / marking (e.g., QFI value is expected to be greater / less than a threshold).

[0258] The WTRU may modify parameters associated with a CG / SPS configuration or select a new CG / SPS configuration when it detects a change / update in the data flows for each application. For example, the WTRU may modify parameters when adding one or more new flows and / or releasing existing flows associated with an application.

[0259] The WTRU may change parameters associated with a CG / SPS configuration or select a new CG / SPS configuration when it detects a jitter measurement. For example, the WTRU may change parameters when a measured jitter value (e.g., a difference between an expected time slot when data is expected to be received and an actual time slot when data is actually received) in one or more data flows is above or below a threshold.

[0260] The WTRU may change parameters associated with a CG / SPS configuration or select a new CG / SPS configuration when it detects measurements of a radio link, e.g., when the RSRP, RSRQ, and RSSI measurements of a signal, channel, beam, carrier, link, etc., that may be associated with one or more data flows transmitted / received by the WTRU, are above / below respective thresholds.

[0261] The WTRU may change parameters associated with a CG / SPS configuration or select a new CG / SPS configuration when it detects a change in the WTRU's movement. For example, the WTRU may change parameters when attitude / positioning measurements (e.g., location information, attitude in 6DoF) go above / below an attitude / location threshold.

[0262] The WTRU may change parameters associated with the CG / SPS configurations or select a new CG / SPS configuration when it detects a change in the power saving configuration. For example, the WTRU may change parameters when changing one or more (e.g., any) of the parameters and / or configurations associated with CDRX / DRX (e.g., cycle duration, on time, inactive time, etc.).

[0263] The WTRU may change parameters of the CG / SPS configuration or change to a new CG / SPS configuration upon detecting any changes to the motion-to-photon (MTP) or RTT latency, typically measured between the transmission of UL data during the active time of the CG configuration and the reception of DL data, possibly associated with the UL data, during the active time of the SPS configuration.

[0264] The WTRU may be configured by the network with one or more CG / SPS configurations based on, for example, statistical information related to RTT latency (e.g., average, standard deviation, minimum, maximum) provided by the WTRU in assistance information to a serving base station in the RAN. The WTRU may also be configured with one or more RTT thresholds (e.g., corresponding to a maximum or minimum difference in latency from an average / expected RTT latency value) associated with the CG / SPS configurations, which may indicate the effectiveness of using the CG / SPS configuration when transmitting and receiving data within the RTT latency.

[0265] When a WTRU is configured with a CG / SPS configuration, the WTRU may determine the RTT latency based on a measurement of the time difference between transmission and reception of associated data or based on another indication received from a higher layer. The WTRU may compare the measured RTT latency with a configured threshold to determine whether the CG / SPS configuration is valid for transmitting / receiving data. When the WTRU determines that the RTT latency is above / below the configured RTT threshold, the WTRU may send an indication / request to the network to change parameters of the CG / SPS configuration or select a new CG / SPS configuration such that data transmission / reception is aligned with the determined RTT latency.

[0266] The WTRU may be configured to process different types of PDU sets. For example, the WTRU may be configured to perform transmission and / or reception by using one or more types of transfer configurations and / or resource configurations based on the type of PDU set. The types of PDU sets may be differentiated based on one or more of the following: type of application / media data; PDU set size; QoS information; importance / priority information; traffic characteristics; intra-PDU set associations / dependencies; and / or expected type of transfer processing.

[0267] The types of PDU sets can be differentiated based on the type of application / media data, e.g., I-frame data, P-frame data, audio data, haptic data, etc. may correspond to different types of PDU sets.

[0268] The types of PDU sets can be differentiated based on PDU set size. For example, PDU sets can be differentiated based on payload size characteristics including total size, average size, minimum size and / or maximum size (e.g., in bits / bytes). Alternatively, PDU sets can be differentiated based on the number of PDUs per PDU set.

[0269] The types of PDU sets can be differentiated based on QoS information, for example, PDU sets can be differentiated based on PDU set-level QoS, including PDU set-level delay bound (PSDB), PDU set-level error rate (PSER), PDU set throughput, etc.

[0270] The types of PDU sets can be differentiated based on importance / priority information. For example, PDU sets may be differentiated based on PDU set-level importance / priority values. The PDU set-level importance / priority values ​​may correspond to one or more (e.g., all) PDUs in the PDU set (e.g., all PDUs have the same priority value and / or the priority value of each PDU is the same / similar to the priority value of the PDU set). The importance / priority values ​​of a subset of PDUs may be different from the PDU set-level importance / priority values ​​(e.g., some PDUs in a PDU set may have different importance / priority values ​​compared to other PDUs).

[0271] The types of PDU sets can be differentiated based on traffic characteristics. For example, PDU sets can be differentiated based on whether the associated traffic characteristics are aperiodic, semi-persistent, or periodic. For PDU sets with periodic characteristics (e.g., corresponding to a frame rate), different PDU sets (e.g., associated with different flows) can have different periodicity values.

[0272] The types of PDU sets may be differentiated based on intra-PDU set associations / dependencies. For example, PDU sets may be differentiated based on intra-PDU set association indications / information that may be carried by one or more PDUs of the PDU set. Some PDUs in a PDU set may carry start and / or end indications indicating the first and last PDUs of the PDU set. For example, some PDUs in a PDU set may indicate sequence numbers corresponding to the order in which the PDUs are generated and / or intended to be delivered during transmission. For some PDU sets, a first subset of one or more PDUs of the PDU set may include information corresponding to the remaining PDUs in the PDU set. Such information may include the number of PDUs in the PDU set, the size of the PDU set (e.g., total payload size), the latency for delivering the PDU set, and / or the importance / priority distribution of the PDUs in the PDU set (e.g., number of PDUs with high / low priority), etc.

[0273] The types of PDU sets may be differentiated based on the type of forwarding treatment expected. For example, the WTRU may be configured to differentiate between at least a first type of PDU set and a second type of PDU set when determining / selecting the type of forwarding treatment to apply. The first type of PDU set (e.g., Type 1) may correspond to the case where one or more (e.g., all) PDUs associated with the PDU set are expected to be delivered on the UL / DL within a QoS (e.g., PSDB, PSER). In this case, one or more (e.g., all) PDUs in the PDU set may have similar importance / priority values. The second type of PDU set (e.g., Type 2) may correspond to the case where one or more PDUs associated with the PDU set are associated with a different QoS and / or are delivered using a different forwarding treatment compared to other PDUs in the PDU set. For example, when one or more high importance / priority PDUs in the PDU set are received within the associated QoS, no adverse effect on application performance may be observed even when some of the other PDUs are delayed or lost.

[0274] When a WTRU is configured to transmit and / or receive different types of PDU sets (e.g., Type 1, Type 2), one or more of the procedures and / or techniques applicable at different protocol stack layers may be applied as described herein. For example, the functions / procedures that may be selected / determined and / or used by the WTRU at the SDAP sublayer (e.g., mapping between QoS flows and radio bearers), the PDCP sublayer (e.g., discarding a PDU set based on a deadline), the RLC sublayer, the MAC sublayer (e.g., multiplexing, scheduling), and / or the PHY sublayer may depend on the type of PDU set (e.g., Type 1, Type 2) transmitted / received by the WTRU.

[0275] The WTRU may be configured with an LCP restriction for processing the PDU set. For example, the WTRU may be configured with an LCP restriction when performing transmission of the PDU set. The LCP restriction may apply to one or more LCHs to which the PDUs of the PDU set are mapped.

[0276] An LCH that buffers and / or carries the PDUs of a PDU set may correspond to and / or be referred to as a PDU Set LCH Group (PSLG). In an example, when a PSLG consists of a single LCH, one or more (e.g., all) PDUs in a PDU set may be mapped to the same LCH or the same radio bearer. In another example, the PDUs in a PDU set may be mapped to different LCHs associated with a PSLG, possibly based on the priority / importance of the PDUs (e.g., based on markings in the PDU headers). Such mapping may be performed by a PDCP entity / sublayer or an SDAP entity / sublayer.

[0277] One or more PSLGs configured in the WTRU may be associated with different identifiers / IDs. Such configurations associated with PSLGs may be applied when triggering SR and / or BSR. For example, to trigger SR and / or BSR, the WTRU may be configured with thresholds (e.g., payload, PSDB, deadline) corresponding to LCHs in a PSLG. In this case, the WTRU may trigger SR and / or BSR, for example, when the total payload of a PDU / PDU set in an LCH associated with a PSLG goes above / below one or more thresholds. The SR and / or BSR triggered by the WTRU may carry the PSLG ID implicitly or explicitly.

[0278] The PDU set consisting of the first and second PDUs may be mapped to a first and a second LCH. The first and second LCHs may be grouped into a PSLG. When the WTRU is configured with PSLG-level LCP restrictions, the LCP restrictions and / or rules that may be applicable to the first LCH may also be applied (e.g., during scheduling and / or multiplexing) to the second LCH belonging to the PSLG. The WTRU may also be configured with per-LCH-level LCP restrictions, which may be the same or different from the PSLG-level LCP restrictions.

[0279] The LCP restrictions may be configured based on whether a Type 1 PDU set (e.g., all PDUs in a PDU set are of equal importance) or a Type 2 PDU set (e.g., some PDUs are more important than others) may be processed by the WTRU. For example, in the case of a Type 1 PDU set, one or more LCHs associated with a PSLG may be associated with the same or similar LCP restrictions / rules that the WTRU may be expected to follow during scheduling and / or multiplexing. In the case of a Type 2 PDU set, some LCHs associated with a PSLG may be configured with different LCP restrictions / rules compared to other LCHs in the PSLG.

[0280] The LCP restrictions associated with the PSLGs and / or LCHs carrying the PDUs of the PDU set may include one or more of the following: a set of allowed subcarrier spacings (SCSs), a maximum PUSCH duration / length, a set of serving cells, a number of PUSCH slots per PSLG, one or more priority values, one or more SR resources, and / or one or more resource configurations.

[0281] The LCP restrictions associated with the PSLGs and / or LCHs carrying the PDUs of a PDU set may include a set of permitted subcarrier spacings (SCS). For example, one or more LCHs in a PSLG may be permitted to use one or more sets of SCS, such as 15 khz, 30 khz, 60 khz, 120 khz, etc. Such SCS values ​​may be associated with a BWP, carrier, frequency band, etc. that the PSLG may be restricted to use. When one or more LCHs in a PSLG are configured with the same or different SCS values, the PDUs in the PDU set may be permitted to use the corresponding sets of SCS values ​​during transmission.

[0282] The LCP restrictions associated with the PSLGs and / or LCHs carrying the PDUs of the PDU set may include a maximum PUSCH duration / length. For example, when configured with a maximum PUSCH duration for one or more LCHs in a PSLG and / or PUSCH resource, the WTRU may schedule PDUs in the PDU set up to a maximum number of slots and / or a maximum number of OFDM symbols associated with the PUSCH duration / length, possibly in one PUSCH opportunity. Other PDUs or PDU sets (e.g., non-XR traffic) that can tolerate higher latency values ​​during UL transmission may not be scheduled by the WTRU along with PDUs / PDU sets (e.g., XR traffic) that use PUSCH resources configured with the maximum PUSCH duration / length.

[0283] The LCP restrictions associated with a PSLG and / or LCH carrying PDUs of a PDU set may include a set of serving cells. For example, when configured with a set of serving cells for one or more LCHs in a PSLG, a PDU / PDU set associated with an LCH / PSLG may use any of one or more component carriers, cells, BWPs, core sets, links, etc. during UL transmission. Other PDU / PDU sets not associated with an LCH / PSLG may not be allowed to use the set of serving cells.

[0284] The LCP restrictions associated with the PSLGs and / or LCHs carrying the PDUs of the PDU set may include a number of PUSCH slots per PSLG. For example, a WTRU may be configured with a number of PUSCH slots per PSLG. Such PUSCH slots may correspond to one or more resource configurations including, for example, configured grants (CGs) and / or dynamic grants (DGs). The WTRU may use a first PUSCH slot in a first CG and a second PUSCH slot in a second CG. Similarly, the WTRU may use the first and second PUSCH slots in one CG configuration.

[0285] The LCP restrictions associated with the PSLGs and / or LCHs carrying the PDUs of the PDU set may include one or more priority values, for example, the WTRU may be configured with one or more priority values ​​for the LCHs / PSLGs that the WTRU may be allowed to use / modify during transmission of the PDUs / PDU set.

[0286] The LCP restrictions associated with the PSLGs and / or LCHs carrying the PDUs of the PDU set may include one or more SR resources. For example, a WTRU may be configured with one or more configurations associated with a scheduling request (SR), which may be restricted to be used for one or more LCHs / PSLGs. Such SR configurations may include SR resources (e.g., time-frequency resources, grant size, etc.), periodicity value, semi-persistent duration (e.g., start / end timeslots), etc. In an example, the WTRU may be permitted to use the SR configuration (e.g., resources, periodicity) associated with an LCH when one or more (e.g., any) of the PDUs of the PDU set are mapped to an LCH. For example, for a set of LCHs in a PSLG that may be associated to transmit a PDU set with low latency and high throughput QoS, SR resources may be configured to be available with a high periodicity value.

[0287] The LCP restrictions associated with the PSLGs and / or LCHs carrying the PDUs of the PDU set may include one or more resource configurations. For example, the WTRU may be configured with one or more resource configurations, including a CG configuration and / or a DG configuration, which may be restricted to some LCHs and / or PSLGs. The PDUs of the PDU set mapped to an LCH / PSLG may use one or more (e.g., any) of the resource configurations restricted / allowed for the LCH / PSLG. In an example, a first LCH may be restricted to a first and a second CG configuration, and a second LCH may be restricted to a second CG configuration. The PDU set mapped to the first LCH may use resources in the first and the second CG configurations, for example. Other PDUs mapped to the second LCH may share resources in the second CG configuration with the PDUs mapped from the first LCH.

[0288] In an example, the LCHs of a PSLG may be restricted to use one or more CG configurations that may be configured with low periodicity, low CG cycle duration, and / or a large number of PUSCH slots per CG opportunity that may be associated with a PSDB of a PDU set. Given the constraints, other LCHs that may have PDUs that can tolerate longer delays (e.g., longer PUSCH durations) may not be multiplexed with PDUs of a PDU set that require, for example, to meet a low PSDB value when using a CG configuration.

[0289] In an example, an LCP restriction may be associated with and / or configured with certain conditions / criteria indicating scenarios when the restriction may be applied or when the restriction may be waived / relaxed. In this case, when the restriction is relaxed due to meeting some conditions / criteria, the WTRU may be allowed to use certain non-default configurations. Such non-default configurations may include configurations / resources associated with other LCHs, including possibly those not associated with a PSLG.

[0290] For example, when configured with LCP restrictions, the WTRU may be configured with conditions associated with one or more of channel quality, timer values, and / or QoS.

[0291] When configured with LCP restrictions, the WTRU may be configured with conditions associated with channel quality, e.g., the WTRU may be permitted to use a non-default resource configuration associated with one or more LCHs / PSLGs when the channel / link quality (e.g., RSRP measurement) meets a metric criterion (e.g., above / below one or more thresholds).

[0292] When configured with LCP restrictions, the WTRU may be configured with conditions associated with timer values. For example, the WTRU may be permitted to use non-default parameters (e.g., SCS, PUSCH duration) and / or resource configurations (e.g., CG, DG) as long as the configured timers are set and / or running. When the timers expire, the WTRU may be expected to fall back to the default restrictions / configurations.

[0293] When configured with LCP restrictions, the WTRU may be configured with conditions associated with QoS, for example, the WTRU may be allowed to use a non-default configuration and / or resources when it may be determined that one or more PDUs of a PDU set do not meet a delay bound (e.g., PSDB) or are approaching a deadline (e.g., above / below a deadline threshold) when transmitting using the restricted default configuration / resources.

[0294] A WTRU may be configured with one or more logical channel groups (LCGs) that may be intended to handle either multiplexing, scheduling, and / or transmission of one or more PDU sets. An LCG may be associated with one or more logical channels (LCHs), e.g., each LCH may be associated with different parameters including, e.g., priority, prioritized bit rate (PBR), and / or bucket size duration (BSD). One or more LCGs configured to handle a PDU set may be associated with one or more IDs / indexes. When configured with an LCG intended to handle a PDU set, the WTRU may send an indication (e.g., in BSR, new / extended BSR) to the base station when it receives data (e.g., from higher layers) in any of the LCH buffers associated with the LCG. The WTRU may indicate in the indication payload size information (e.g., total payload of the PDUs) associated with one or more PDUs of the PDU set. In an example, a WTRU may be configured with one or more LCGs, where each (e.g., each) LCG may be associated with a different number and / or combination of LCHs. The WTRU may select the most appropriate LCG to perform any of multiplexing, scheduling, and transmission of data in the UL based on data associated with a PDU set and / or traffic pattern information (e.g., total payload size, priority, reliability, latency bound) received from higher layers. For example, a WTRU may be configured with LCG1 associated with LCHs 1, 2, and 3, and LCG2 associated with LCHs 2, 3, and 4. When the WTRU receives data associated with a PDU set or data burst (e.g., from higher layers or an application) and / or the data is mapped to LCHs 1, 2, and 3, the WTRU may select LCG1 when sending an indication (e.g., BSR or new / extended BSR) to the base station. The WTRU may include the ID / index of the selected LCG in the indication.The benefit of a WTRU dynamically selecting one or more pre-configured LCGs when processing data associated with a PDU set and / or when sending an instruction to a base station may be, for example, to minimize overhead signaling and avoid fragmenting the PDU set during UL transmission.

[0295] The WTRU may transmit an indication to the base station indicating timing information associated with transmitting one or more PDU sets in the UL. In an example, the timing information may be transmitted by the WTRU in a MAC CE and / or an enhanced BSR. The timing information transmitted by the WTRU may include one or more of the following: a PDU Set Delay Boundary (PSDB) for transmitting the one or more PDU sets and / or a remaining delay for transmitting the remaining PDUs of the one or more PDU sets. The timing information may be transmitted explicitly (e.g., indicating an index / value of the PSDB or a remaining delay) or implicitly (e.g., using an LCG / LCH ID or a priority value in the indication that may be associated with the PSDB or the remaining delay). In an example, the indication including the timing information may be transmitted by the WTRU when requesting a UL resource grant for transmitting a new PDU set (e.g., in a BSR or an enhanced BSR). In an example, the indication including the timing information (e.g., a remaining delay) may be transmitted by the WTRU after transmitting some of the PDUs of the one or more PDU sets and / or when the remaining delay for transmitting some of the PDUs of the one or more PDU sets is above / below a delay threshold. In an example, an indication including implicit or explicit timing information may be sent by the WTRU to update a previously transmitted resource grant request (e.g., BSR). For example, the update indication sent by the WTRU may indicate either an updated payload size, an updated PSDB, and a request for an updated remaining delay, as well as a cancellation of the previous BSR.

[0296] The WTRU may determine an LCP configuration to apply to support the traffic attributes and QoS of the PDU set. For example, a PDU set may include one or more PDUs associated with a (e.g., one) unit of information generated in an application and is subject to a per-PDU-set level of quality of service (QoS). For example, the WTRU may determine whether to use a first LCP configuration (e.g., an LCP configuration for handling all non-empty LCHs) or a second LCP configuration (e.g., a new LCP configuration for handling only the LCHs associated with the PDU set) to transmit the PDU set in the UL based on the XR traffic QoS (e.g., a PDU set delay bound).

[0297] The WTRU may be configured to perform one or more of the following: The WTRU may receive configuration information from the network (e.g., gNB). For example, the configuration information may include a delay threshold associated with one or more PDU sets. The WTRU may receive data consisting of one or more PDU sets from a higher layer. The WTRU may determine a total payload size and a delay boundary for the one or more PDU sets. If the PDU set delay is less than the delay threshold associated with the PDU set and the total payload size is greater than the payload size threshold, the WTRU may perform one or more actions. If the PDU set delay boundary is greater than or equal to the delay threshold associated with the PDU set and / or the total payload size is greater than the payload size threshold, the WTRU may perform one or more actions. If the PDU set delay boundary is less than the delay threshold associated with the PDU set and / or the total payload size is less than the payload size threshold, the WTRU may perform one or more actions.

[0298] The WTRU may receive configuration information from a network (e.g., a gNB). For example, the configuration information may include one or more of the following: a first LCP configuration; a second LCP configuration; one or more delay thresholds associated with one or more PDU sets; one or more payload size thresholds associated with one or more PDU sets, and / or an LCP restriction indicating a restricted association between configured resources (e.g., SR resources, configured grants) and one or more LCHs.

[0299] The configuration information may include a first LCP configuration. For example, the first LCP configuration may process one or more (e.g., all) non-empty LCHs that may contain PDUs in the LCH buffer. The first LCP configuration may correspond to a default LCP configuration that may be used by the WTRU to process one or more (e.g., all) data / PDU types (e.g., PDU set, non-PDU set). The first LCP configuration may be activated and / or used by the WTRU after receiving the configuration information from the network. The first LCP configuration may include logical channel restrictions for the LCHs associated with the PDU set.

[0300] The configuration information may include a second LCP configuration. For example, the second LCP configuration may handle one or more LCHs (e.g., only) associated with the delivery of one or more PDU sets. The second LCP configuration and the LCHs associated with the PDU sets may be configured to ensure that PDU set-level and / or PDU set group-level QoS (e.g., latency, reliability, throughput) is met during UL transmission. A PDU set group may consist of one or more PDU sets that may be interdependent with each other (e.g., interdependent PDU sets within a PDU set group may consist of a common PDU set group ID in the packet header). The second LCP configuration may include logical channel restrictions for the LCHs associated with the PDU sets.

[0301] The configuration information may include one or more delay thresholds associated with one or more PDU sets, which may be used by the WTRU to determine an LCP configuration to be applied for multiplexing and scheduling PDUs of a PDU set / group of PDU sets during an UL transmission.

[0302] The configuration information may include one or more payload size thresholds associated with one or more PDU sets, for example, the payload size thresholds may be used to determine the total payload (e.g., in bits / bytes) of the PDU sets in a PDU set group and / or the PDUs in an interdependent PDU set.

[0303] The WTRU may receive data consisting of one or more PDU sets. For example, the received data may be associated with a single PDU set or multiple PDU sets (e.g., within a PDU set group or data burst), which may be interdependent with each other. Different PDU sets, which may or may not be interdependent with each other, may arrive at the WTRU at different time instances.

[0304] The WTRU may determine a total payload size and PDU delay information associated with a PDU set of one or more PDU sets (e.g., a delay bound for one or more PDU sets and / or a remaining delay amount for one or more PDU sets). For example, the WTRU may determine the total payload size by summing the payloads of one or more interdependent PDU sets. The WTRU may determine the delay bound for the PDU set based on the QoS markings in the packet headers (e.g., QFI, PDU set QFI, timestamp) and preconfigured association information indicating the QoS markings and delay bounds (e.g., interdependent within a PDU set group). The PDU delay information may include a remaining delay amount associated with (e.g., related to) the delay bound for the PDU set. For example, the WTRU may receive a delay bound for the PDU set. The delay bound may be a fixed value that may be indicated to the WTRU based on, for example, the PDU set header. The WTRU may (e.g., dynamically) determine the remaining delay amount as the difference between the delay bound and the duration that the PDU set spends on the logical channel (e.g., because the PDU set is received from a higher layer). For example, the WTRU may determine the remaining delay amount for the PDU set by subtracting the duration from the delay bound for the PDU set.

[0305] The WTRU may map the PDUs in the PDU set to one or more logical channels. The WTRU may select one or more logical channels for the PDU set based on, for example, the PDU delay information (e.g., PDU set delay bounds and / or remaining delay amount), a delay threshold, a total payload size of the PDU set, and / or a payload size threshold. The WTRU may then determine a logical channel prioritization (LCP) configuration associated with the selected logical channel based on the selected logical channel, the PDU delay information (e.g., PDU set delay bounds and / or remaining delay amount), a delay threshold, a total payload size of the PDU set, and / or a payload size threshold. For example, the WTRU may compare the delay information to the delay threshold and / or compare the total payload size to the payload size threshold.

[0306] If the PDU delay information (e.g., a PDU set delay bound and / or remaining delay amount) is less than a delay threshold associated with the PDU set and the total payload size is greater than a payload size threshold, the WTRU may perform one or more of the following actions: The WTRU may determine a set of one or more LCHs that may contain data associated with the PDU set (e.g., PDU sets in a PDU set group that may be interdependent). The WTRU may send an indication to the gNB (e.g., in a new BSR, MAC CE, and / or UCI). For example, the indication (e.g., in a new BSR) may indicate one or more of the delay information (e.g., delay bound and / or remaining delay amount for the PDU set), timing information associated with the one or more PDU sets (e.g., remaining time to transmit the remaining PDU / PDY set), the total payload size, a set (e.g., ID) of one or more LCHs that contain data associated with the one or more PDU sets (e.g., interdependent), and / or an LCG (LCH group) ID consisting of a group of LCHs that may contain data associated with the PDU set group. The WTRU may receive resource grant(s) from the gNB. For example, the resource grant may include one or more dynamic grants (e.g., single-slot or multi-slot) and / or configured grants. The WTRU may suspend use of the default / first LCP configuration for a duration associated with the delay boundary of the PDU set and may use the second LCP configuration. For example, the WTRU may suspend use of the first LCP configuration and use the second LCP configuration if there is no other data on any of the LCHs that has a higher priority than the data associated with the PDU set. The WTRU may multiplex one or more PDU sets onto one or more TBs using the second LCP configuration. For example, the WTRU may prioritize PDUs of the PDU set(s) over PDUs of higher priority LCHs. The WTRU may transmit prioritized PDUs of the PDU set.For example, multiplexing of the PDU sets may be performed in a MAC entity / sublayer in the WTRU. The second LCP configuration may be used for a duration associated with the delay bounds of the PDU sets. The WTRU may transmit a TB carrying one or more PDU sets using the resource grant(s) provided by the gNB. Once the WTRU has transmitted the TB, it may resume the first LCP configuration.

[0307] If the PDU delay information (e.g., a PDU set delay bound and / or a remaining delay amount) is greater than a delay threshold associated with the PDU set and / or the total payload size is greater than a payload size threshold, the WTRU may perform one or more of the following actions: The WTRU may decide to relax LCP restrictions in one or more LCHs, possibly associated with processing non-PDU sets. The WTRU may relax LCP restrictions for accessing resource grants associated with other LCHs (e.g., LCHs processing non-PDU sets). The WTRU may send an indication (e.g., in a new BSR, MAC CE, and / or UCI) to the gNB indicating the relaxation of the LCP restrictions. The WTRU may receive resource grant(s) from the gNB. The WTRU may multiplex the one or more PDU sets into one or more TBs using the first LCP configuration. The WTRU may transmit PDUs of the PDU set (e.g., TBs carrying one or more PDU sets) using the resource grant(s) from the other LCHs and / or any resources provided by the gNB.

[0308] If the PDU set delay bound is less than the delay threshold associated with the PDU set and / or the total payload size is less than the payload size threshold, the WTRU may perform one or more of the following actions: The WTRU may send an indication to the gNB (e.g., in a new BSR, MAC CE, and / or UCI). The indication (e.g., in a new BSR) may indicate one or more of the following: PDU delay information (e.g., PDU set delay bound and / or remaining delay amount) of the PDU set, timing information (e.g., remaining time to transmit remaining PDU / PDY sets) associated with the one or more PDU sets, total payload size, a set (e.g., ID) of one or more LCHs that contain data associated with the one or more PDU sets (e.g., interdependencies), an LCG (LCH group) ID consisting of a group of LCHs that may contain data associated with a PDY set group. The WTRU may receive resource grant(s) from the gNB. The WTRU may multiplex the one or more PDU sets into one or more TBs using the first LCP configuration. The WTRU may transmit a TB carrying one or more PDU sets using resources provided by the gNB.

[0309] 3 shows an example of a WTRU determining an LCP configuration to apply to support traffic attributes and QoS of a PDU set. As shown in FIG. 3, the WTRU may determine whether to use a first LCP configuration (e.g., LCP configuration 310) and / or a second LCP configuration (e.g., LCP configuration 312) to transmit a PDU set in the UL based on an XR traffic QoS (e.g., a PDU set delay bound). If a configured QoS condition (e.g., a delay threshold) is met, the WTRU may transmit the PDU set using the second LCP configuration.

[0310] For example, as shown in FIG. 3, there may be a PDU set 302 including one or more (e.g., five) PDUs associated with XR traffic, which may be labeled as PS1.1, PS1.2, PS1.3, PS1.4, and PS1.5. One or more of the PDUs in the PDU set 302 may be associated with a first priority (e.g., priority 1, shown as "Pri 1" in FIG. 3), and one or more other PDUs of the PDU set 302 may be associated with a second priority (e.g., priority 3, shown as "Pri 3" in FIG. 3). There may be one or more PDUs (e.g., standalone PDUs) that may be associated with non-XR traffic (e.g., PDU1 and PDU2 shown in FIG. 3). The PDUs associated with non-XR traffic may be associated with a third priority (e.g., priority 2, shown as "Pri 2" in FIG. 3). The third priority may be the same as or different from the first priority and / or the second priority.

[0311] The PDUs of the PDU set 302 and / or the standalone PDUs may be mapped to the LCHs, for example, based on their respective priorities. For example, as shown in FIG. 3, one or more first PDUs associated with a first priority (e.g., PDUs PS1.1, PS1.2, and PS1.3) may be mapped to the first LCH 304, one or more second PDUs associated with a second priority (e.g., PDUs PS1.4 and PS1.5) may be mapped to the second LCH 306, and one or more third PDUs associated with a third priority (e.g., PDUs PDU1 and PDU2) may be mapped to the third LCH 308. The WTRU may determine whether to use a first LCP configuration (e.g., the first LCP configuration 310 shown in FIG. 3) and / or a second LCP configuration (e.g., the first LCP configuration 312 shown in FIG. 3, which may be a new LCP for processing one or more of the logical channels 304, 306, 308) to transmit the PDU based on the XR traffic QoS. The WTRU may multiplex the data in the LCHs 304, 306, 308 into the TB based on the selected LCP configuration.

[0312] If the WTRU selects the first LCP configuration 310, the PDUs may be multiplexed into TBs based on the PDUs' respective priorities. For example, as shown in FIG. 3, if the WTRU selects the first LCP configuration 310, the WTRU may multiplex PS1.1, PS1.2, PS1.3, PDU2, and PDU1 into a first TB 314 and multiplex PDUs PS1.4 and PS1.5 into a second TB 316. The WTRU may transmit the first TB 314 and the second TB 316.

[0313] If the WTRU selects the second LCP configuration 312, the PDUs may be multiplexed into TBs based on grouping together the PDUs of the PDU set 302. For example, as shown in FIG. 3, if the WTRU selects the second LCP configuration 312, the WTRU may multiplex the PDUs of the PDU set 302 (e.g., PS1.1, PS1.2, PS1.3, PS1.4, and PS1.5) into a first TB 314 and multiplex the standalone PDUs PDU1 and PDU2 into a second TB 316. The WTRU may transmit the first TB 314 and the second TB 316.

[0314] For example, the WTRU may receive configuration information associated with one or more PDU sets. The configuration information may include a delay threshold. The WTRU may determine PDU delay information (e.g., a PDU set delay boundary and / or a remaining delay amount) associated with a first PDU set of the one or more PDU sets. For example, as described herein, the PDU delay information may include a remaining delay amount associated with a delay boundary of the first PDU set. The first PDU set may include multiple PDUs. The WTRU may transmit an indication of the PDU delay information to the network.

[0315] The WTRU may select one or more LCHs for the first PDU set and / or map the PDUs of the first PDU set to one or more LCHs. The WTRU may determine an LCP configuration associated with the selected logical channel based on the delay threshold and / or the PDU delay information. For example, the WTRU may select the first LCP configuration or the second configuration. The (e.g., each) LCP configuration may include a logical channel restriction for the logical channel(s) associated with the PDU set. The WTRU may compare the delay information to the delay threshold. If the delay information is less than or equal to the delay threshold, the WTRU may select the first LCP configuration. If the delay information is greater than the delay threshold, the WTRU may select the second LCP configuration.

[0316] The WTRU may transmit the PDU set using the determined LCP configuration. For example, transmitting the PDU set using the first LCP configuration may include prioritizing PDUs of the PDU set over PDUs of a higher priority logical channel and transmitting the prioritized PDUs of the PDU set. Transmitting the PDU set using the second LCP configuration may include prioritizing PDUs of one or more logical channels based on a descending order of priorities associated with the logical channels and transmitting the prioritized PDUs. The (e.g., each) LCP configuration may include one or more LCP parameters for at least one LCH. The LCP parameters may include (e.g., indicate) a prioritization of PDUs of the first PDU set relative to PDUs of a higher priority logical channel (e.g., PDUs of the second PDU set).

[0317] The processes and techniques described herein may be applied to other wireless technologies and to other services in any combination.

[0318] The WTRU may refer to a physical device identity or subscription related identity, e.g., a user identity such as MSISDN, SIP URI, etc., and the WTRU may refer to an application-based identity, e.g., a username that may be used per application.

[0319] The above-described processes may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium for execution by a computer and / or a processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, 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 in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, and / or any host computer.

Claims

1. 1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Receiving configuration information including a delay threshold associated with one or more sets of protocol data units (PDUs); determining PDU delay information associated with a set of PDUs of the one or more sets of PDUs, the set of PDUs including a plurality of PDUs; selecting one or more logical channels for the set of PDUs; determining a logical channel prioritization (LCP) configuration associated with the selected logical channel based on the delay threshold and the PDU delay information; and transmitting the set of PDUs using the determined LCP configuration.

2. transmitting the set of PDUs using the determined LCP configuration; prioritizing one or more of the PDUs of the set of PDUs over one or more PDUs associated with a higher priority logical channel; and transmitting the prioritized PDUs of the PDU set.

3. 2. The method of claim 1, wherein the LCP configuration includes a logical channel restriction for the logical channels of the PDU set.

4. The method of claim 1 , wherein the PDU delay information comprises a remaining delay amount associated with a delay boundary of the set of PDUs.

5. determining the LCP configuration, comparing the PDU delay information to a delay threshold; selecting a first LCP configuration as the LCP configuration under the condition that the PDU delay information is less than or equal to the delay threshold; and selecting a second LCP configuration as the LCP configuration on the condition that the PDU delay information is greater than the delay threshold.

6. 2. The method of claim 1, wherein the PDUs of the PDU set are associated with units of information generated in an application, and the PDUs of the PDU set are subject to a per-PDU set level of Quality of Service (QoS).

7. The method of claim 1 , further comprising: comparing a total payload size of the set of PDUs to a payload size threshold.

8. The method of claim 1 , further comprising: transmitting an indication of the PDU delay information to a network.

9. The method of claim 1 , wherein the LCP configuration includes one or more LCP parameters for at least one logical channel.

10. 10. The method of claim 9, wherein the set of PDUs is a first set of PDUs, and the one or more LCP parameters include a prioritization of the plurality of PDUs of the first set of PDUs relative to one or more PDUs of a second set of PDUs.

11. 1. A wireless transmit / receive unit (WTRU), comprising: a processor, the processor comprising: receiving configuration information including delay thresholds associated with one or more sets of protocol data units (PDUs); determining PDU delay information associated with a set of PDUs of the one or more sets of PDUs, the set of PDUs including a plurality of PDUs; selecting one or more logical channels for the set of PDUs; determining a logical channel prioritization (LCP) configuration associated with the selected logical channel based on the delay threshold and the PDU delay information; The WTRU is configured to transmit the set of PDUs using the determined LCP configuration.

12. The processor is configured to transmit the set of PDUs using the determined LCP configuration, prioritizing one or more of the PDUs of the PDU set over one or more PDUs associated with a higher priority logical channel; The WTRU of claim 11 , further comprising: being configured to transmit the prioritized PDUs of the PDU set.

13. The WTRU of claim 11 , wherein the LCP configuration includes a logical channel restriction for the logical channels of the PDU set.

14. The WTRU of claim 11 , wherein the PDU delay information comprises a remaining delay amount associated with a delay boundary of the set of PDUs.

15. The processor is configured to determine the LCP configuration, comparing the PDU delay information to a delay threshold; selecting a first LCP configuration as the LCP configuration under the condition that the PDU delay information is less than or equal to the delay threshold; The WTRU of claim 11 , further comprising: configured to select a second LCP configuration as the LCP configuration on a condition that the PDU latency information is greater than the latency threshold.

16. The WTRU of claim 11, wherein the PDUs of the PDU set are associated with units of information generated in an application, and the PDUs of the PDU set are subject to a per-PDU-set level of Quality of Service (QoS).

17. The WTRU of claim 11 , wherein the processor is further configured to compare a total payload size of the set of PDUs with a payload size threshold.

18. The WTRU of claim 11 , wherein the processor is further configured to transmit an indication of the PDU delay information to a network.

19. The WTRU of claim 11 , wherein the processor is further configured to map the plurality of PDUs to one or more logical channels.

20. 12. The WTRU of claim 11, wherein the LCP configuration includes one or more LCP parameters for at least one logical channel, the PDU set being a first PDU set, and the one or more LCP parameters including a prioritization of the plurality of PDUs of the first PDU set relative to one or more PDUs of a second PDU set.

Images