Methods for handling QOS and latency for xr

Abstract

Methods and apparatuses are provided for handling of quality of service (QoS) and latency. A method may include receiving configuration information indicating parameters associated with a first logical channel prioritization (LCP) configuration and parameters associated with a second LCP configuration and determining an arrival time associated with a protocol data unit (PDU) set at which at least one PDU of the PDU set is available to be sent in at least one uplink transmission. The method may include receiving information indicating a PDU set delay budget (PSDB) and a PDU set delay deadline (PSDD). The method may include determining, based on the arrival time, the PSDB, and the PSDD, a remaining amount of time to send PDUs of the PDU set and determining a time duration during which to apply the second LCP configuration. The method may include sending, during the determined time duration, the PDUs of the PDU set.

Description

METHODS FOR HANDLING QOS AND LATENCY FOR XRCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 552,534, filed February 12, 2024, the contents of which are incorporated herein by reference.BACKGROUND

[0002] The term extended Reality (XR) may be an umbrella term for different types of immersive experiences including Virtual Reality (VR), Augmented Reality (AR) and Mixed Reality (MR) and the realities interpolated among them. Virtual Reality (VR) may be a rendered version of a delivered visual and audio scene. The rendering is designed to mimic the visual (e.g. stereoscopic 3D) and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Augmented Reality (AR) may refer to the delivery of additional information or artificially generated objects / items or content overlaid upon a user’s current environment. Mixed Reality (MR) is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene. XR may include all real-and-virtual combined environments and humanmachine interactions generated by computer technology and wearables.

[0003] The notion of immersion in the context of XR appl ications / services may refer to the sense of being surrounded by the virtual environment as well as providing the feeling of being physically and spatially located in the virtual environment. The levels of virtuality may range from partial sensory inputs to fully immersive multi- sensory inputs leading to a virtual reality practically indiscernible from actual reality.SUMMARY

[0004] Methods and apparatuses are provided for handling of quality of service (QoS) and latency. A method may include receiving configuration information indicating parameters associated with a first logical channel prioritization (LCP) configuration and parameters associated with a second LCP configuration and determining an arrival time associated with a protocol data unit (PDU) set at which at least one PDU of the PDU set is available to be sent in at least one uplink transmission. The method may include receiving information indicating a PDU set delay budget (PSDB) and a PDU set delay deadline (PSDD). The method may include determining, based on the arrival time, the PSDB, and the PSDD, a remaining amount of time to send PDUs of the PDU set and determining a time duration during which to apply the second LCP configuration. The method may include sending, during the determined time duration, the PDUs of the PDU set.BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

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

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

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

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

[0010] FIG. 2 is an illustration of a scenario in which a protocol data unit (PDU) set delay budget (PSDB) is inadequate to fulfill a QoS.

[0011] FIG. 3 is a flow diagram illustrating The overall a generalized procedure consistent with one solution described herein;

[0012] FIG. 4 is a flow diagram illustrating a generalized procedure consistent with another solution described herein; and

[0013] FIG. 5 is a flow diagram illustrating a generalized procedure consistent with another solution described herein.DETAILED DESCRIPTION

[0014] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0015] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though itwill be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fl device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0016] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[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 and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

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

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

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

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

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

[0025] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 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. 1 A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

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

[0029] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or moremicroprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

[0035] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-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 e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0050] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0052] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g , only support for) certain and / or limited bandwidths The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0053] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802 11 n, 802.11ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

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

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

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

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

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

[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 of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0060] The CN 106 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0061] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b,management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 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 SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

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

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

[0065] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

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

[0068] The acronym 6DOF may be used to refer to the term "6 Degrees of Freedom". The acronym ACK may be used to refer to the term "Acknowledgement". The acronym ADU may be used to refer to the term "Application Data Unit". The acronym AR may be used to refer to the term "Augmented Reality". The acronym AS may be used to refer to the term "Access Stratum". The acronym AM may be used to refer to the term "Acknowledgement Mode". The acronym BLER may be used to refer to the term "Block Error Rate". The acronym BSR may be used to refer to the term "Buffer Status Report". The acronym BSD may be used to refer to the term "Bucket Size Duration". The acronym BWP may be used to refer to the term "Bandwidth Part”. The acronym CAP may be used to refer to the term "Channel Access Priority". The acronym CAPC may be used to refer to the term "Channel Access Priority Class". The acronym CCA may be used to refer to the term "Clear Channel Assessment". The acronym CCE may be used to refer to the term "Control Channel Element" The acronym CE may be used to refer to the term "Control Element". The acronym CG may be used to refer to the term "Configured Grant or Cell Group". The acronym CP may be used to refer to the term "Cyclic Prefix". The acronym CP-OFDM may be used to refer to the term "Conventional OFDM (relying on cyclic prefix)". The acronym CQI may be used to refer to the term "Channel Quality Indicator" The acronym CRC may be used to refer to the term "Cyclic Redundancy Check". The acronym CSI may be used to refer to the term "Channel State Information". The acronym CW may be used to refer to the term "Contention Window". The acronym CWS may be used to refer to the term "Contention Window Size". The acronym CO may be used to refer to the term "Channel Occupancy". The acronym DAI may be used to refer to the term "Downlink Assignment Index". The acronym DCI may be used to refer to the term "Downlink Control Information". The acronym DFI may be used to refer to the term "Downlink Feedback Information" The acronym DG may be used to refer to the term "Dynamic Grant". The acronym DL may be used to refer to the term "Downlink". The acronym DM-RS may be used to refer to the term "Demodulation Reference Signal". The acronym DRB may be used to refer to the term "Data Radio Bearer". The acronym eLAA may be used to refer to the term "Enhanced Licensed Assisted Access". The acronym FDRA may be used to refer to the term"Frequency Domain Resource Allocation". The acronym FeLAA may be used to refer to the term "Further Enhanced Licensed Assisted Access". The acronym FoV may be used to refer to the term "Field of View". The acronym FPS may be used to refer to the term "Frames per Second". The acronym HARQ may be used to refer to the term "Hybrid Automatic Repeat Request". The acronym LAA may be used to refer to the term "Licensed Assisted Access" The acronym LBT may be used to refer to the term "Listen-Before-Talk". The acronym LCP may be used to refer to the term "Logical Control Prioritization". The acronym LCH may be used to refer to the term "Logical Channel". The acronym LTE may be used to refer to the term "Long Term Evolution (e.g., from 3GPP LTE R8 and up)". The acronym NACK may be used to refer to the term "Negative Acknowledgement". The acronym MAC may be used to refer to the term "Medium Access Control". The acronym MCS may be used to refer to the term "Modulation and Coding Scheme". The acronym MIMO may be used to refer to the term "Multiple Input Multiple Output". The acronym MT may be used to refer to the term "Mobile Termination". The acronym MTP may be used to refer to the term "Motion-to-Photon". The acronym NAS may be used to refer to the term "Non-Access Stratum". The acronym NR may be used to refer to the term "New Radio". The acronym network may be used to refer to the term "Network". The acronym OFDM may be used to refer to the term "Orthogonal Frequency-Division Multiplexing". The acronym PBR may be used to refer to the term "Prioritized Bit Rate". The acronym PDB may be used to refer to the term "Packet Delay Budget". The acronym PHY may be used to refer to the term "Physical Layer". The acronym PUCCH may be used to refer to the term "Physical Uplink Control Channel". The acronym PUSCH may be used to refer to the term "Physical Uplink Shared Channel”. The acronym PDSCH may be used to refer to the term "Physical Downlink Shared Channel". The acronym PID may be used to refer to the term "Process ID" The acronym PC may be used to refer to the term "Paging Occasion". The acronym PRACH may be used to refer to the term "Physical Random Access Channel". The acronym PS may be used to refer to the term "PDU Set". The acronym PSS may be used to refer to the term "Primary Synchronization Signal". The acronym PSDB may be used to refer to the term "PDU Set Delay Bound". The acronym PSER may be used to refer to the term "PDU Set Error Rate". The acronym PSIHI may be used to refer to the term "PDU Set Integrated Handling Indicator". The acronym QFI may be used to refer to the term "QoS Flow Identifier". The acronym RA may be used to refer to the term "Random Access (or procedure)" The acronym RACH may be used to refer to the term "Random Access Channel". The acronym RAR may be used to refer to the term "Random Access Response". The acronym RCU may be used to refer to the term "Radio Access Network Central Unit". The acronym RF may be used to refer to the term "Radio Front End". The acronym RLF may be used to refer to the term "Radio Link Failure". The acronym RLM may be used to refer to the term "Radio Link Monitoring" The acronym RNTI may be used to refer to the term "Radio Network Identifier". The acronym RO may be used to refer to the term "RACH Occasion". The acronym RRC may be used to refer to the term "Radio Resource Control" The acronym RRM may be used to refer to the term "Radio Resource Management". The acronym RS may be used to refer to the term "Reference Signal". The acronym RSRP may be used to refer to the term "Reference Signal Received Power". The acronym RSSI may be used to refer to the term "Received Signal Strength Indicator". The acronym RLC may be used to refer to the term"Radio Link Control". The acronym RTT may be used to refer to the term "Round Trip Time". The acronym SDAP may be used to refer to the term "Service Data Adaptation Protocol". The acronym SR may be used to refer to the term "Scheduling Request". The acronym SDU may be used to refer to the term "Service Data Unit". The acronym SUV may be used to refer to the term "Start and Length Indicator Value". The acronym SRS may be used to refer to the term "Sounding Reference Signal" The acronym SS may be used to refer to the term "Synchronization Signal". The acronym SSS may be used to refer to the term "Secondary Synchronization Signal". The acronym SWG may be used to refer to the term "Switching Gap (in a self- contained subframe)". The acronym SPS may be used to refer to the term "Semi-Persistent Scheduling". The acronym SUL may be used to refer to the term "Supplemental Uplink". The acronym Sync may be used to refer to the term "Synchronization". The acronym TB may be used to refer to the term "Transport Block". The acronym TBS may be used to refer to the term "Transport Block Size" The acronym TDRA may be used to refer to the term "Time Domain Resource Allocation". The acronym TRP may be used to refer to the term "Transmission I Reception Point". The acronym TSC may be used to refer to the term "Time-Sensitive Communications". The acronym TSN may be used to refer to the term "Time-Sensitive Networking". The acronym UCI may be used to refer to the term "Uplink Control Indication". The acronym UL may be used to refer to the term "Uplink". The acronym UTO may be used to refer to the term "Unused Transmission Occasion". The acronym URLLC may be used to refer to the term "Ultra-Reliable and Low Latency Communications". The acronym WBWP may be used to refer to the term "Wide Bandwidth Part". The acronym WLAN may be used to refer to the term "Wireless Local Area Networks" and to related technologies (e g., in an IEEE 8O2.xx domain). The acronym VR may be used to refer to the term "Virtual Reality". The acronym XR may be used to refer to the term "Extended Reality".

[0069] In the examples and embodiments described herein, a WTRU as referred to herein may correspond to a XR device / node, which may come in variety of form factors. For example, a WTRU (e.g. an XR WTRU) may include, but is not limited to the following: a Head Mounted Display (HMD), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with positional tracking and camera, wearables, haptic gloves, haptic body suit, haptic shoes, or other equipment associated with the support or provision of XR applications, experiences, or services. In addition to the above, several different types of XR WTRUs may be envisioned based on XR device functions for e.g. as display, camera, sensors, sensor processing, wireless connectivity, XR / Media processing and power supply, to be provided by one or more devices, wearables, actuators, controllers and / or accessories. One or more device / nodes / WTRUs may be grouped into a collaborative XR group for supporting any of XR applications, experience, or services.

[0070] In XR services and applications, traffic may include data and / or PDUs that may be associated with an application data unit (ADU), a PDU set, or data burst. In an example, PDUs belonging to a PDU set may be associated with different segments or components of a video frame or a video slice. A data burst may include one or more PDU sets that may be transmitted / received over a time window. For example, a number of PDUs in a PDU set or data burst transmitted in an UL direction and / or received in a DL direction may be dependent on the type of the media frame (e.g. 3D video frame, audio frame).

[0071] In XR applications, the WTRU may transmit XR traffic including one or more PDUs / PDU sets in the UL direction (e.g. pose, gesture, video data) and / or receive XR traffic (e.g., video, audio, or haptic data) in a DL direction. Such traffic may be transmitted and / or received periodically or aperiodically in one or more data flows (e.g. QoS flows). During UL transmissions, XR traffic may arrive from application layer at WTRU and / or from different devices / terminals / WTRUs (e.g., via sidelink) at different time instances. Such XR traffic may be characterized by different attributes such as variable payload sizes per PDU set, variable number of PDUs per PDU set, variable per-PDU / PDU set level importance and different levels of inter-dependencies between PDUs / PDUs sets. Such XR traffic (e.g. PDU / PDU sets) received by the WTRU may also experience different delays, jitter, data rate and loss rate. For ensuring QoS and high user experience (QoE) it is important that data transmission / reception and other associated functions (e.g prioritization, multiplexing, scheduling) are done on timely basis with XR awareness (e.g. awareness of PDU set attributes).

[0072] An introduction to various problems addressed by one or more solutions is provided herein. When using existing techniques, a WTRU supporting an XR experience may be receiving data units (e.g. PDUs, PDU sets, data bursts, and / or bitstreams) from higher layers or different devices, such as AR glasses and haptics gloves. Data units may be received, for example, via a sidelink (SL) interface or via an air interface (Uu). Such data units, which may have variable payload sizes, different periodicity, jitter and different inter-dependencies may be further processed and transmitted by the WTRU in the UL direction.

[0073] Third Generation Partnership Project (3GPP) Release 18 (R18) enhancements related to capacity may enable, for example: multiple Configured Grant (CG) PUSCH transmission occasions in a period of a single CG PUSCH configuration; dynamic indications of unused CG PUSCH occasion(s) based on Uplink Control Information (UCI) by the WTRU; buffer status report (BSR) enhancements including at least new BSR Table(s); delayed reporting of buffered data in uplink; and / or discarding operation of PDU Sets for DL and UL. Enhancements related to power savings may include DRX support for XR frame rates corresponding to noninteger periodicities (e.g., through semi-static mechanisms such as RRC signaling). R18 enhancements for XR awareness may enable signaling, by a CN, of semi-static information per QoS flow (e.g. PDU set QoS parameters), dynamic information per PDU set (PDU Set information and Identification) and End of Data Burst indication. R18 enhancements for XR awareness may also enable provisioning (e.g., by a WTRU) of XR traffic assistance information such as periodicity, and / or UL traffic arrival information.

[0074] A short description of one or more problems addressed is provided herein A PDU Set Delay Budget (PSDB) may be a time between reception of a first PDU (e.g., at the UPF in the DL direction, and at the WTRU in the UL direction) and the successful delivery of the last arrived PDU of a PDU Set (at the WTRU in DL, at the UPF in UL). be used today for L2 procedures (e.g., scheduling, discard, etc.) and may supersedes a Packet Delay Budget (PDB) when available. The PSDB may be constant per QoS flow and may be counted from the time the first PDU of a PDU set is received. A PDU Set Delay Deadline (PSDD) may be understood as an absolute deadline by which the application may need to have received the PDU set. These terms may be defined with greater specificity in paragraphs further below.

[0075] FIG. 2 is a diagram illustrating the transmission timing of PDU sets according to different scenarios. The illustration in FIG. 2 may be applicable or relevant to solutions described in further detail in paragraphs below. As shown in FIG. 2, one or more PDUs of PDU sets A, B, C, and / or D may arrive at (or may be received at lower layers) a network node (e.g., a base station) when being transmitted in a downlink direction or may arrive at (or may be received at lower layers) a WTRU when being transmitted in an uplink direction. The actual arrival time, shown by elements 211 , 221, 231 , and 241 respectively, may be earlier than, equal to, or later than an expected or nominal arrival time. The network node or WTRU that is to transmit a PDU set may perform scheduling to meet a PSDD, which may be configured, determined, or otherwise known for a particular PDU set.

[0076] In the example of PDU set A, which arrives “just in time” as shown at 211 or without any jitter (i.e., deviation from its nominal arrival time), the scheduler may schedule the transmission 221 of PDU set A within its PSDB 213. For PDU set A which arrives just in time, it may benefit the network and / or WTRU to know information on / relative to the PSDD (e.g., information about a PSDD 214 associated with PDU set A, such as a remaining time 213a with respect to PSDD 214 associated with PDU set A) for scheduling and / or multiplexing purposes.

[0077] In the example of PDU set B, which arrives at 221 , earlier than its nominal arrival time, having experienced jitter (expressed as -Y ms). The scheduler may schedule the transmission 222 of PDU set B within its PSDB 223 In this case, it may be beneficial for the scheduler during multiplexing, for example, if there is other data that needs to be delivered more urgently and can be expedited / transmitted before PDU set B to meet the QoS of the other data while also meeting the QoS of PDU set B. Thus, the remaining time 223a is determined based on the PSDB 223 and the PSDD 224

[0078] In the case of PDU set C, which arrives late as shown at 231 (having experienced jitter expressed as +X ms), the schedule may schedule the transmission of PDU set C as shown at 232 in accordance with the PSDB 233 such that there is no remaining time with respect to the PSDD 234 during which other data could be expedited / transmitted before PDU set C. Here, PDU set C is transmitted as shown at 232 at or just before the PSDD.

[0079] In the case of PDU set D as shown at 241 , FIG. 2 illustrates a scenario in which PSDB is inadequate to fulfill a QoS. At shown at 241 , PDU set D arrives very late (having experienced jitter expressed as +Z ms). The PSDB 243 may provide the WTRU with insufficient time to transmit PDU set D prior to the PSDD 244. For instance, as shown at 243a and 243b respectively, the transmission may be able to, or unable to, meet a QoS associated with the data.

[0080] In other words, as illustrated in FIG 2, the PSDB alone may not allow a WTRU to meet QoS (e.g., a QoS requirement), for example as shown where PDU set D arrives Z ms after its expected / nominal arrival time, possibly due to jitter. On the other hand, PDU set B may have arrived Y ms earlier than its expected / nominal arrival time, possibly due to jitter. While the PSDB 223 may allow the WTRU to meet the QoS, it may be beneficial that the WTRU inform the network that it has more time to schedule PDU set B whichmay be beneficial to the network to optimize its scheduling operations It may also be beneficial for the WTRU during multiplexing if, for example, there is other data that needs to be delivered more urgently and can be expedited / transmitted before PDU set B to meet the QoS of the other data while also meeting the QoS of PDU set B. Similarly for PDU set A which arrives just in time, it may benefit the network and / or WTRU to know information on / relative to the PSDD 214 (e.g., information about a PSDD of the PDU set, such as a remaining time with respect to the PSDD 214 of the PDU set) for scheduling and / or multiplexing purposes.

[0081] In summary, it may not always be possible to use the legacy approach (PSDB) to meet the QoS (PDU set D). Achieving the same QoS but at a lower cost in terms of resource usage may be useful to the network for scheduling operations and / or to the WTRU for multiplexing operations (PDU set A and PDU set B). A remaining question addressed herein may be how to ensure that PDU sets are delivered to the application on time according to the PSDD.

[0082] Relevant definitions of various terminology are provided herein A PDU Set Delay Budget (PSDB) may be the time between reception of the first PDU (at the UPF in DL, at the WTRU in UL) and the successful delivery of the last arrived PDU of a PDU Set (at the WTRU in DL, at the UPF in UL). PSDB may be an optional parameter and when provided, the PSDB may supersede the PDB PDU Set Delivery Deadline (PSDD) may be an absolute deadline wherein last PDU of a PDU set needs to be received at the application so that the application can make use of the PDU set. Awareness of application buffering / processing may take into account the PDU set delivery deadline to relax the real PDB.

[0083] A number of solutions, which are presented in greater detail in subsequent paragraphs, are summarized herein. In some solutions involving multiplexing, a WTRU may switch from priority-based LCP methods to methods for selecting an LCP that take into consideration a remaining time with respect to PSDD , for example, for a given time duration. In legacy approaches, LCP methods may only consider the priority of the logical channel and the QoS of the data. These legacy approaches may utilize a static approach based on a static QoS (PSDB, constant per QoS flow throughout XR session).

[0084] In some cases, the time to serve a lower priority PDU set may be smaller than the time to serve a higher priority PDU set— in other words, the lower priority PDU set may be more time-critical than the higher priority PDU set. In an example, a WTRU may configured with a first logical channel, LCH 1 , of priority 1 and a second logical channel, LCH 2, of priority 2. In this scenario, priority 1 is greater than priority 2. The WTRU may need to transmit PDU set A and PDU set B, where PDU set A has a higher importance / priority than PDU set B. Under a legacy approach, LCP will always map PDU set A to LCH 1 and PDU set B to LCH 2, even if the time to serve PDU set B is less than the time to serve PDU set A.

[0085] To address this situation, based on the time to serve the PDU set, the WTRU may determine a time duration to temporarily relax a default LCP configuration and activate another LCP configuration under which prioritization is based on a remaining time with respect to the PSDD to serve a PDU set.

[0086] FIG. 3 is a flow diagram illustrating a generalized procedure consistent with one solution described herein. A procedure as shown in FIG. 3 may be carried out in one or more of the following steps.

[0087] As shown at 310, a WTRU may receive (e.g., from an application) information indicating (or e.g., associated with, or relating to) a PSDB and / or a PSDD. As shown at 320, the WTRU may receive (e.g., from a network) information indicating or associated with a first LCP configuration, a second LCP configuration, and / or rules for determining a time duration during which to apply the second LCP configuration. The first LCP configuration may be referred to, for example, as a default LCP configuration, a legacy LCP configuration, or a primary LCP configuration. The second LCP configuration may be referred to as ‘‘an LCP configuration other than the default LCP configuration,” as “LCP config’,” as “a secondary LCP configuration,” or as “another LCP configuration" The second LCP configuration may include, or provide, or be accompanied by rules for determining a time duration during which to apply the second LCP configuration. Using the second LCP configuration, the WTRU may perform multiplexing according to a remaining time with respect to PSDD.

[0088] As shown at 330, the WTRU may receive a PDU set A at time TA. At 340, the WTRU may determine the time to serve PDU set A, tA, based on the arrival time of PDU set A, TA, and the PSDD. For example, the time to serve PDU set tA(which may be referred to equivalently herein as the “margin”) may be calculated as TA- PSDD + PSDB. If tA< 0, as shown at 345, the WTRU may apply the first LCP configuration. If tA> 0, as shown at 350, the WTRU may determine the time duration d to apply the second LCP configuration based on value of tA. The WTRU (e g., a MAC entity configured the WTRU) may apply the second LCP configuration for the time duration of d milliseconds as shown at 360. The WTRU may revert back to the first LCP configuration as shown at 370.

[0089] Some solutions may involve a routing approach. In legacy approaches, if a legacy QoS framework (PSDB) is used, the same QoS will be achieved, but at a cost of higher resource usage. Using the PSDD instead may provide additional time for multiplexing and allow the network to do better resource provisioning. Based on the PSDD and time of arrival of the PDU set, the WTRU may determine the priority of the PDU set and the appropriate LCH to map it to.

[0090] FIG. 4 is a flow diagram illustrating a generalized procedure consistent with another solution described herein. A procedure as shown in FIG. 4 may be carried out in one or more of the following steps.

[0091] As shown at 410, a WTRU may receive (e.g., from an application) information indicating (or e.g., associated with, or relating to) a PSDB and / or a PSDD. At 420, the WTRU may receive (e.g., from the network) configuration information (e.g., associated with one or more DRB(s), LCH(s), and corresponding mapping rules, etc.) specifying priority information for a first LCH (LCH 1) and a second LCH (LCH 2), where priority 1 > priority 2, or mapping PDU setA to LCH 1 (e.g., according to QoS profile). As shown at 430, the WTRU receives PDU set A at time TA. At 440, the WTRU determines the time to serve PDU set A, tA, based on arrival time of PDU set A TAand PSDD. For example, tAmay be determined by the expression | PS DD - TA|. If time to serve PDU set A tA> 0, as shown in FIG. 5, the WTRU may relax the PSDB of PDU set A. For instance, as shown at 450, the WTRU (PDCP) determines the priority of PDU set A based on tAand association info between tAand priority, and at 460, the WTRU (PDCP) selects an appropriate LCH to map PDU set A.

[0092] Some solutions may involve a discarding approach. In legacy approaches, if a legacy QoS framework (PSDB) is used, when one or more PDUs of a PDU set do not arrive on time (i.e., within the discardTimer value, which may be set based on the PSDB), the WTRU may discard the remaining PDUs of the PDU set. Such discarding may not be necessary. Using the PSDD may provide additional time for PDCP discard.

[0093] In summary, based on the PSDD and time of arrival of the PDU set, the WTRU may adjust the PDCP discardTimer value since the PDUs arriving beyond the PSDB for QoS flows where PSIHI is set are still useful to the application.

[0094] FIG. 5 is a flow diagram illustrating a generalized procedure consistent with another solution described herein. A procedure as shown in FIG. 5 may be carried out in one or more of the following steps. As shown at 510, a WTRU may receive (e.g., from an application) information indicating (or e.g., associated with, or relating to) a PSDB and / or a PSDD. At 520, the WTRU may receive (e.g., from the network) information indicating one or more discardTimer values and one or more values indicating associated remaining time(s) during which to serve a PDU set. At 530, the WTRU receives PDU set A at time TA. At 540, the WTRU determines the time to serve PDU set A, U, based on the arrival time of PDU set A, TA, and PSDD. For example, 1A may be calculated as |PSDD - TA|. Based on the time to serve PDU set A IA, the WTRU may select a discardTimer value to apply (e.g., at PDCP) as shown at 550.

[0095] Solutions proposed herein are described in greater detail in the following paragraphs A brief statement of assumptions and definitions are provided as follows. Throughout the examples described herein, the network may include any of a base station (e.g. gNB, TRP, RAN node, access node), core network function (e g. AMF, SMF, PCF, NEF) and / or application function (e.g. edge server function, remote server function), for example.

[0096] Throughout the examples described herein, the term “flow” may correspond to one or more of: QoS flows or data flows (e.g. flow of data consisting of one or more PDUs, PDU sets or data bursts, which may be inter-dependent with one and another and / or associated with one or more QoS requirements, e.g. latency, data rate, reliability, RTT latency) Different flows, possibly originating from a common application / experience source and / or intended to a common destination device / WTRU or group of associated devices / WTRU may be referred to as associated flows or correlated flows.

[0097] Throughout the examples described herein, a data unit may refer to any of: one or more frames (e.g. media / video / audio frame or slice / segment), PDUs, PDU sets, data bursts, group of frames / PDUs / PDU- sets / data bursts, bitstreams. Such data units, which may be transmitted or received by the WTRU sequentially (e g. one after the other) or in parallel (e.g. over different channels / links / resources), may or may not be interdependent with each other.

[0098] Throughout the examples described herein, a forwarding configuration may correspond to any of the following: radio bearers (e.g. data radio bearer (DRB), signaling radio bearers (SRB), transport radio bearer, PDU set bearer); logical channels (LCHs), logical channel groups (LCGs); configuration parameters in theindividual layers within the AS protocol stack (e.g. SDAP, PDCP, RLC, MAC, PHY, other new protocol layers); parameters associated with logical channel prioritization (LCP) (e.g. priority, PBR, BSD), BWPs, carriers, radio links / interfaces (Uu links, SLs); or radio resources (e.g set of one or more frequency / time / spatial resources such as symbols, slots, subcarriers, resource elements or beams). For example, radio resources may be associated with configurated grants (CG), dynamic grants (DG) and / or any other resource grants or grant free resources.

[0099] Throughout description provided herein, in any illustration and / or description, PDU Set 1 may refer to one or more PDU sets with similar PDU Set level QoS requirements (e.g., same or similar PSDB1 , PSER1, PSII indication, etc.). Similarly, PDU Set 2 may refer to one or more PDU sets with similar PDU Set level QoS requirements (e.g., same or similar PSDB2, PSER2, PSII indication, etc.). In other words, PDU set 1 may not necessarily refer to a single / singular PDU set. Similarly for PDU set 2, PDU set 3, etc. PDU Set 1 may be a PDU Set type I or a PDU Set type II. Similarly for PDU Set 2, PDU Set 3, PDU Set A, PDU Set B, etc. which may be a PDU Set type I or a PDU Set type II. Type I PDU sets, for example, cannot tolerate any loss / delay of any PDU within the PDU set, i.e., loss / delay outside of the bounds of the PSDB for any PDU of the PDU set may render the remaining PDUs of the PDU set useless since the application may need all the PDUs of the PDU set to successfully decode the PDU set. Type II PDU sets can tolerate some loss / delay of PDUs within the PDU set.

[0100] Throughout the solutions described herein, PDU sets and their associated characteristics / properties, may be understood as follows. A PDU set may comprise of one or more data units (e g. PDUs) associated with a media unit, or a video frame / slice. Such data units within a PDU set or data burst may be inter-dependent with each other at the application layer and / or lower layers (e.g. AS-layers).

[0101] The attributes / properties of different PDU sets may be different from each other in terms of, for example, the number of PDUs in a PDU set, payload sizes, intra-PDU set correlation, importance / priority of the data units, status of transmission (e.g. percentage of PDUs of one or more data units transmitted / received successfully), and effective data rate and / or effective reliability associated with transmission.

[0102] In some examples, such attributes associated with PDU sets may be visible at one or more lower layers (e g. at PDCP, RLC, MAC, PHY sub-layers / layers), possibly for supporting additional actions (e.g. prioritizing, mapping to an LCH, multiplexing into one or more TBs, scheduling) based on any of the following:

[0103] Markings in the data units may be understood as follows. Markings may include sequence numbers, IDs, indexes, timestamps, and time offset values (e.g. with respect to a reference time), which may be included in a header of a data unit. Such markings may be made by higher layers, any preceding sub-layer / layer, or another device / WTRU.

[0104] A WTRU may be configured to receive an indication such as a control PDU (e.g. application / higher / NAS layer indication, PDCP control PDU, RLC control PDU, MAC CE, DCI / UCI). Such indication may be received by WTRU from a higher / preceding layer, from another device / WTRU (e g. over a SL interface) and / or from network, for example.

[0105] The mapping of data units from a higher layer to a configuration associated with a lower layer may be understood as follows. For example, a WTRU may have visibility of higher layer attribute(s) at a lower layer when mapping the PDUs to one or more radio bearers, logical channels (LCHs), TBs or HARQ processes that may be configured to provide similar forwarding treatment.

[0106] Mechanisms for tracking attributes of PDUs at any buffer associated with a sublayer, radio bearer logical channel, or HARQ process(es), may be understood as follows. For example, the WTRU may track attributes associated with a PDU set based on, for example: a time elapsed since reception of a first PDU of a PDU set, a remaining time for the PDUs of a PDU set to meet a PSDB, jitter between the arrival of one or more PDUs within / across PDU sets, and / or a percentage / payload size of remaining PDUs of a PDU set expected to be received.

[0107] Restrictions associated with a sublayer, radio bearer, logical channel and / or HARQ process to which the data units of PDU sets may be mapped, may be understood as follows. In some examples, a WTRU may have visibility of the data units and determine corresponding actions (e.g. how or whether to perform prioritization per LCP, or perform mapping to restricted CG configurations, TBs, or HPIs) based on the configured restrictions associated with the one or more sublayers, radio bearers and / or LCHs to which the data units may be mapped.

[0108] A data burst may refer to data produced by an application (e.g., over a short period of time), and may include PDUs from one or more PDU Sets. Attributes, associations and / or inter-dependencies (e.g. intra- PDU set and / or inter-PDU set attributes, associations, and / or inter-dependencies), including a start / end indication of a PDU set / data burst (e.g., via sequence number, start / end indication, timestamp), start / end time, duration, payload sizes, periodicity, importance / priority, and / or QoS (e g. PSDB) may be visible to the AS- layers (e.g., with associated IDs) and / or handled at the AS layers with awareness of the association with the data during transmission and reception (e g., for UL and / or DL directions).

[0109] Application / high layer importance / priority may be understood as follows. Different PDUs (e.g., a subset of PDU or individual PDUs) in a PDU set, or alternatively, all PDUs in a PDU set, may be associated with different values indicating an or importance / priority of the PDU(s). The values may correspond to a spatial importance (e g. spatial position of a video frame whose data is carried by the PDU / PDU set, where PDUs / PDU set carrying FoV spatial positions may be associated with a higher spatial importance than non-FoV spatial positions) or temporal importance (e.g. time sequence of the video / application frame whose data is carried by the PDU / PDU set, where PDUs or PDU sets carrying base video frames such as l-frame may be associated with a higher temporal importance than differential video frames such as P-frame / B-frame). Such values may be visible to the AS layers during data transmission and reception.

[0110] QoS / data flows may be understood as follows. PDUs / PDU sets associated with an application may be encoded and delivered by the application to a WTRU (in UL) or a network (in DL) via one or more QoS / data flows. In this regard, the different QoS flows carrying the PDUs / PDU sets associated with an XR- 72 -application / experience may be visible to the AS-layers and / or handled at the AS layers with the awareness of such association during data transmission and reception.

[0111] In the examples provided herein, the following definitions of traffic characteristics and PDU set-level QoS requirements may be applicable. A PDU Set Delay Budget (PSDB) may refer to the time between reception of the first PDU (at the UPF in DL, at the WTRU in UL) and the successful delivery of the last arrived PDU of a PDU Set (at the WTRU in DL, at the UPF in UL). PSDB may be an optional parameter, and when provided, the PSDB may supersede the PDB.

[0112] A PDU Set Integrated Handling Indication (PSIHI) may indicate whether all PDUs of the PDU Set are needed for the usage of PDU Set by application layer.

[0113] A PDU Set Error Rate (PSER) may define an upper bound for a rate of non-congestion related PDU Set losses between a RAN and a WTRU.

[0114] Jitter may refer to variation with respect to an expected time instance during which one or more data units may be received or transmitted. For example, for a set of data units that may be expected to be received periodically at different periodic time instances, jitter may refer to a variation with respect to periodic time instances (e.g. for a data unit that may be received Ti ms in advance or T2ms later than an expected time instance at T, the jitter range is T2- Ti). Jitter may refer to an instantaneous value or a statistical value (e.g. average, variance, standard deviation, max / min).

[0115] The term “remaining delay” may refer to a time duration remaining for receiving or transmitting one or more PDUs of a PDU set before the PSDB. The remaining delay may also be referred to as the time to live (TTL) associated with a PDU set.

[0116] Throughout the examples described herein, a multi-PUSCH CG may correspond to one or more configured resources or configured grant (CG) configurations, where each CG configuration may include a set of consecutive or non-consecutive PUSCH occasions per slot and / or per CG period. In some examples, a multi- PUSCH CG may include one or more CG periods (e.g. each CG period may repeat periodically with a certain periodicity value). A CG period in a multi-PUSCH CG may include one or more consecutive or non-consecutive slots. A slot in a CG period of a multi-PUSCH CG may include one or more consecutive or non-consecutive PUSCH occasions. A PUSCH occasion in a slot / CG period of a multi-PUSCH CG may include one or more consecutive or non-consecutive symbols with a certain symbol length (e.g. time domain resources). A PUSCH occasion may include one or more resource blocks or resource block groups in the frequency domain.

[0117] Throughout the examples described herein, PUSCH usage may refer to any of the number, location, position or timing of one or more PUSCH occasions in one or more slots or periods, which may be associated with one or more multi-PUSCH CG configurations.

[0118] Throughout the examples described herein, a PDU set may refer to a PDU set in its integrity and / or the PDUs that make up the PDU set. A PDU set may include one or more PDUs. At the application, a PDU set (i.e., all PDUs making up the PDU set) may be considered as one frame. One PDU set may include one or more PDUs. Some PDU sets may be of the PDU Set Integrated Handling Indication (PSIHI) type. In suchcases, all PDUs of the PDU set may need to be received at the application by the PSDB and / or PSDD for the application to be able to decode the PDU set. Other PDU sets may not be of the PSIHI type. In these cases, the application may still be able to decode the PDU set if a portion of the PDUs of the PDU set are lost and / or delayed beyond the PSDB and / or PSDD In some cases, successful reception of, for example, 80% of the PDUs of the PDU set may be sufficient for the successful decoding of the PDU set at the application, in other cases, successful reception of, for example, 70% of the PDUs of the PDU set may be sufficient for the successful decoding of the PDU set at the application.

[0119] Throughout the examples described herein, the time windows, durations, or time instances described by the phrases a 'time to serve a PDU set’, ‘remaining time to serve a PDU set’, 'time to serve PDUs of a PDU set’, 'remaining time to serve PDUs of a PDU set’ or a 'remaining time’ may refer to a time to process and / or perform operations on a PDU set and / or PDUs of a PDU set and / or remaining PDUs of a PDU set in the protocol stack. Operations may include, for example, routing the PDU set and / or PDUs of the PDU set to a logical channel and / or multiplexing the PDU set and / or PDUs of the PDU set from one or more logical channel(s) into a transport block, discarding of PDUs and / or PDU sets at PDCP, etc. Such 'remaining time to serve a PDU set’ may be determined by the WTRU based on, for example, the elapsed time since the arrival of a reference PDU (e.g. first, nth, last PDU of the PDU set) and PSDD / PSDB.

[0120] The PDU Set Delay Deadline (PSDD) is described in further detail herein A WTRU may receive from the network one or more PSDD values. For example, the PSDD value may be constant per QoS flow and the WTRU may receive the PSDD for the QoS flow from the higher / application layers during handshake at the start of the XR session. In some solutions, a PSDD value may change dynamically. A change in the PSDD value may be signaled to the WTRU from the higher / application layers The WTRU may assume that the latest received PSDD applies to the ongoing traffic until reception of a new / updated PSDD from the application. The PSDD may be set or applied according to any one or more of the following. The PSDD may be: set for all traffic; set for all ongoing XR traffic; set for all UL traffic; set for all DL traffic; set for all ongoing XR UL traffic; set for all ongoing XR DL traffic; set per QoS flow; set per DRB; set per PDCP entity / sublayer; set per SDAP entity / sublayer; set for upcoming traffic for a time duration; set for upcoming XR traffic for a time duration; set for upcoming XR UL traffic for a time duration; and / or set for upcoming XR DL traffic for a time duration.

[0121] The determination of the (remaining) time to serve a PDU set is described herein. Time keeping may be performed at any layer in the protocol stack (e.g., SDAP, PDCP, MAC). At the PDCP layer for example, time keeping may make use and / or repurpose and / or account for an existing PDCP discard timer and / or there may be a new discard timer per PDU set that is started on reception of the first PDU of the PDU set for example. The value of TA which represents the arrival time of the PDU set at the lower layers (e.g , PDCP) in that case may be based on the arrival time of one reference PDU of the PDU set, for example, arrival time of the first PDU of the PDU set and / or arrival time of the last / end PDU of the PDU set and / or arrival time of the median PDU of the PDU set.

[0122] In the examples provided herein, a “timer” such as the PDCP discard timer (or any other timer referred to herein) may be implemented by a processor, circuitry, software, algorithms or other computer- implemented means through for measuring time. In other words, a “timer” refer to a logical implementation for measuring a duration of time. A timer may be started or initiated in a first time instance and may be stopped at a second time instance. The duration (also referred to as a window or interval) between the first time instance and the second instance may be determined or measured in terms of units such as milliseconds (ms), for example, or in terms of frames, subframes, slots, or symbols.

[0123] In some solutions, a WTRU may determine a remaining time and / or the length of time required for the XR application at a receiving entity to receive PDUs of a PDU set (e g., a video frame to be displayed) based on the arrival time of the PDUs and / or the PDU set and the PSDD and / or PSDB. In some examples, the WTRU may start receiving, e.g., from higher layers, one or more PDUs of a PDU set in the buffer including explicit and / or implicit information from application / high layers / network indicating the traffic characteristic and QoS parameters. The information received together with the PDU sets may include or indicate a traffic periodicity indicating regular periods of time at which WTRU should expect PDU sets to arrive in the buffer The information may include the PSDB, the PSER, PDU set size and / or indications regarding the first and the last PDUs of the PDU-set. Additionally, or alternatively, the WTRU may receive a PSDD value related to the maximum length of time it should take before a PDU set can be received and processed by the application layer at a receiving entity. The WTRU may receive the traffic information in the packet header of the first packet / PDU in the PDU-set.

[0124] In some scenarios, the WTRU may start to receive all PDUs of the PDU set simultaneously or one after the other with negligible delay in between the arrival times of PDUs such that all PDUs of the PDU set will share a common arrival time TA. In another scenario, PDUs of a PDU set may arrive at the WTRU one after the other with some time apart such that each of N PDUs of the PDU set have an associated arrival time TAI < TA2 < . .. <TAN. In some scenarios, the WTRU may receive PDUs of a PDU set in subsets of PDUs such that each of M subsets of PDUs belonging to the PDU set may arrive apart from each other at times TA_SI < TA_S2 < .... <TA_SM while PDUs within a subset may arrive simultaneously Ideally, the WTRU may expect to start receiving PDUs of a PDU set at the periodic instances of time (e.g., TA+P) known to it from the traffic characteristic of the application. However, the presence of jitter may introduce random variations with respect to an expected arrival time of the start PDUs of a PDU sets around the periodic time instances. For example, for a set PDUs that may be expected to be received periodically at periodic time instances, jitter during the generation of the traffic may introduce variation with respect to the periodic time instances (e.g. PDU sets may be received -Y ms in advance or +X ms later than an expected time instance at T such that the jitter range between T-Y and T+X) the first PDUs of the PDU sets are expected to arrive at the lower layers in the WTRU (e g., at the UPF in DL, at the WTRU buffer in UL). As a result, the arrival time for the starting PDUs of a PDU set may be characterized by a random arrival time, TA, may range between -Y ms and X ms around a nominal 0ms for example. Depending on the nature of the arrival of PDUs of a PDU set, the arrival time TAmay also define the arrival time of the entire PDU set if all PDUs or the PDU set are considered to have arrivedsimultaneously. If PDUs of a PDU set arrive separately further in time one from another and / or in subset of PDUs, then, TA, and its association with the nominal arrival time T as defined by the traffic periodicity may only be used to describe the arrival time of the first PDU and / or subset of PDUs of the PDU set while TAI, TA2, ....TN may indicate the arrival times of subsequent N PDUs and / or subset of PDUs.

[0125] In some solutions, the WTRU may determine the remaining time and / or delay, tA, that is available to serve and / or process PDUs of a PDU based on the arrival time of PDUs of the PDU set, the PSDB and / or the PSDD. Depending on the sequence of arrival of PDUs, e.g , PDUs of a PDU set arriving simultaneously, PDUs of a PDUs set arriving in subset of PDUs and / or each PDU of a PDU set arriving separately, the WTRU may need to determine the remaining time required to serve the PDU set and / or for subset of PDUs and / or for each PDU of the PDU set. Additionally, depending on the scenario considered, the WTRU may determine the remaining time relative to the PSDD and / or the PSDB. In some solutions, the WTRU may only need to determine a single remaining time value tA= PSDD - TAor tA= PSDB - TA corresponding to the scenario in which all PDUs of a PDU set arrive simultaneously based on the arrival time, TA, of the PDU set. In some solutions, the WTRU may use the following equation to determine / compute the time to serve the PDU set and / or remaining time to serve the PDU set A: time to serve PDU set tA= TA- PSDD + PSDB.

[0126] In some solutions, such as where PDUs of a PDU set may arrive sequentially at the lower layers in the WTRU, e.g., from the application in the WTRU, the WTRU may compute or determine multiple remaining time and / or delay values, via any one or more of the following equations. For example, tA_sn = PSDD - TA_sn or tA_sn = PSDB - TA sn may be determined corresponding to each of the N PDUs or each of the M subsets of PDUs of the PDU set. In some solutions, if the different PDUs of the PDU set arrive sequentially at different arrival times, the WTRU may consider one reference PDU of the PDU set and compute the time to serve the PDU set based on the arrival time of the reference PDU of the PDU set which may be the first PDU of the PDU set or the last PDU of the PDU set.

[0127] Solutions relating to LCP configuration(s) and switching from priority-based to remaining time-based methods are described herein

[0128] A WTRU may be configured or may receive an indication from the network to perform one or more actions, referred to herein as LCP-related actions and / or ‘special’ LCP-related action. Such action(s) may take into account the PSDD and / or the remaining time with respect to the PSDD. The WTRU may receive such an indication from the network in any of MAC CE / DCI or other DL signaling to perform the one or more actions, and / or the WTRU may measure the remaining time with respect to the PSDD and / or the remaining time with respect to the PSDB. Based on the amount of the remaining time, the WTRU may determine to perform the one or more actions. In some examples, such an indication received from the network may indicate the use of a PSDB-based configuration and / or PSDD-based configuration, based on which the WTRU may determine or switch to a suitable LCP configuration. In one or both cases, the actions may include any one or more steps or operations described in the following paragraphs

[0129] An action may include selecting another LCP configuration based on the PSDD / PSDB value and / or the remaining time with respect to the PSDD / PSDB value.

[0130] An action may include the WTRU receiving one or more LCP configurations during RRC (re)configuration procedure with an indication of one LCP configuration as the 'default one. The ‘default LCP configuration may be the one activated by default, unless indicated otherwise by the network and / or unless the WTRU meets the rules / criteria configured by the network to activate a non-default LCP configuration For example, activation / deactivation of a LCP configuration may be signaled by the network to the WTRU via any one of RRC signaling, and / or MAC CE(s), and / or DCI. In some examples, the WTRU may have been preconfigured with one or more LCP configurations where each LCP configuration may involve different logical channels and different logical channel parameters.

[0131] In some examples, a WTRU may be preconfigured with two LCP configurations where one LCP configuration may be considered a ‘default’ LCP configuration which is based on the legacy configuration (e.g., configurations which may be been in use up until Release 18, which may consider parameters such as priority and PBR) and the other one may be a ‘special’ LCP configuration which considers the PSDD / PSDB and / or remaining time, e.g., a remaining time with respect to PSDB and / or remaining time with respect to PSDD when multiplexing PDUs into a MAC PDU.

[0132] In some examples, the WTRU may be preconfigured with two LCP configurations where one LCP configuration is the default LCP configuration and the other / ’special’ LCP configuration is one where for which the WTRU may be able to adjust the parameters of the LCP configuration. For example, for the other / ’special’ LCP configuration, the WTRU may be configured to adjust / increase / decrease a number of logical channels as part of the LCP configuration, adjust / increase / decrease a priority of the one or more logical channel(s) as part of the LCP configuration, adjust / increase / decrease a PBR of the one or more logical channel(s) as part of the LCP configuration, and / or make other adjustments when the ‘special’ LCP configuration is activated.

[0133] In some examples, a WTRU may receive an activation / deactivation indication from the network e.g., in a MAC CE or other logically equivalent signaling, which may indicate the LCP configuration to be applied. In some examples, the signaling may constitute a simple activation request including the ID of the LCP configuration to apply. The WTRU may apply this LCP configuration until it receives another indication (e.g., from the network), for example, a deactivation indication with the ID of the currently activated LCP configuration, a simple deactivation indication which serves to indicate to deactivate the currently activated LCP configuration, an activation indication with the ID of the LCP configuration that is currently not activated, a simple activation indication which serves as an indication to activate the other LCP configuration (which may also serve as an indication to deactivate the currently activated one, and so on and so forth. In some solutions, the WTRU may always apply the default LCP configuration until / unless it receives a request / indication from the network to activate the ‘special’ LCP configuration.

[0134] In some examples, the WTRU may also receive from the network an indication of the time duration for which to activate / apply a certain LCP configuration.-7J -

[0135] In some solutions, an indication of the time duration may be transmitted by the network to the WTRU every time the network wants to activate a LCP configuration.

[0136] In some solutions, the WTRU may apply the default LCP configuration until it receives a request / ind ication from the network to activate the ‘special’ LCP configuration. This activation request may also carry an indication of a time duration for which to apply the ‘special’ LCP configuration.

[0137] In some solutions, the ‘special’ LCP configuration may consider the PSDD / PSDB and / or the remaining time with respect to the PSDD and / or the remaining time with respect to the PSDB when determining the PDUs and / or PDU sets to be multiplexed into the MAC PDU.

[0138] In some solutions, the ‘special’ LCP configuration may consider the PSDD / PSDB and / or the remaining time with respect to the PSDD and / or remaining time with respect to the PSDB when determining the PDUs and / or PDU sets to be multiplexed into the MAC PDU. In some examples, the ‘special’ LCP configuration may consider the PSDD / PSDB and / or the remaining time with respect to the PSDD and / or remaining time with respect to the PSDB when determining the PDUs and / or PDU sets to be multiplexed into the MAC PDU in addition to the LCH parameters that legacy LCP considers during multiplexing (e.g , PBR, priority).

[0139] In some solutions, the ‘special’ LCP configuration may consider the PSDD / PSDB and / or the remaining time with respect to the PSDD and / or remaining time with respect to the PSDB when determining the PDUs and / or PDU sets to be multiplexed into the MAC PDU. In some solutions, the ‘special’ LCP configuration may consider the PSDD / PSDB and / or the remaining time with respect to the PSDD and / or remaining time with respect to the PSDB when determining the PDUs and / or PDU sets to be multiplexed into the MAC PDU, in addition to the LCH parameters that legacy LCP considers during multiplexing (e.g , PBR, priority) as well as other parameters of the PDU set that may include any one or more of those described in the following paragraphs.

[0140] Other parameters may include a PDU set priority and / or PDU set importance. For example, if it is a very important PDU set (e.g., importance value exceeding a preconfigured threshold), the WTRU may determine to only use the default LCP configuration that already takes into account the priority of the data, and is likely to map the PDU set to a high-priority LCH. In such case, the WTRU may not activate the ‘special’ LCP configuration.

[0141] Other parameters may include a PDU set type, which may indicate whether the PDU set corresponds to a PDU Set Integral Handling indicator (PSIHI) type; in such case, all the PDUs of the PDU set may be needed by the application for the successful decoding of the PDU set. Alternatively or additionally, a PDU set may be of another type whereby only a subset of PDUs of the PDU set are needed for the successful decoding of the PDU set at the application. That subset may correspond to, for example, 90%, 50%, 40%, or another percentage of PDUs of the PDU set that are needed at the application for the successful decoding of the PDU set.

[0142] Other parameters may include the type of frame that the PDU set corresponds to, i.e., whether the PDU set corresponds to a l-frame, P-frame, B-frame, any other type of frame according to the application, whether it is a primary or secondary or tertiary frame, and / or whether it is a first frame or a differential frame etc.

[0143] Other parameters may include an importance and / or priority of the PDUs of the PDU set. Different PDUs of a PDU set may have or be associated with a different importance and / or priority which may have been set by the application. For example, different PDUs within a PDU set may correspond to different parts of a ‘frame’ or ‘picture’. For example, different PDUs may correspond to the primary part versus the differential part and have different importance and / or priority value.

[0144] Other parameters may include a number of PDUs in the PDU set. For instance, if the number of PDUs in the PDU set is larger than a preconfigured number threshold and the remaining time with respect to the PSDD is less than a preconfigured time threshold, the WTRU may determine to also consider the remaining time with respect to the PSDD when selecting an LOP configuration to multiplex the PDUs into a MAC PDU. This may be advantageous since, with a fast-approaching deadline of the remaining time with respect to the PSDD, there may not be sufficient time and / or resources (e.g., limited size of MAC PDU) to serve the PDU set with a large number of PDUs using a legacy LCP, which may only consider LCH parameters such as priority and PBR may not ensure that the remaining time criteria is met.

[0145] Other parameters may include a remaining number of PDUs in the PDU set. For instance, if the remaining number of PDUs in the PDU set is larger than a preconfigured number threshold and the remaining time with respect to the PSDD is less than a preconfigured time threshold, the WTRU may determine to also consider the remaining time with respect to the PSDD when selecting an LCP configuration since with a fastapproaching deadline of the remaining time with respect to the PSDD and a large number of remaining PDUs of the PDU set to be multiplexed into a MAC PDU, there may not be sufficient time and / or resources (e.g., limited size of MAC PDU) to multiplex all the PDUs of the PDU set using legacy LCP that only considers LCH parameters such as priority and PBR and may not ensure that the remaining time criteria is met

[0146] Other parameters may include a size of PDU set, e.g., in bytes, kB, MB, or another unit of information. For instance, if the size of the PDU set is larger than a preconfigured threshold (e.g , > x bytes) and the remaining time with respect to the PSDD is less than a preconfigured time threshold, the WTRU may determine to also consider the remaining time with respect to the PSDD when selecting an LCP configuration to multiplex the PDUs into a MAC PDU. This may be advantageous since, with a fast-approaching deadline of the remaining time with respect to the PSDD, there may not be sufficient time and / or resources (e.g., limited size of MAC PDU) to serve the large PDU set using a legacy LCP, which may only consider LCH parameters such as priority and PBR and may not ensure that the remaining time criteria is met.

[0147] Other parameters may include a size of remaining PDUs of PDU set, e.g., in bytes, kB, MB, etc. For instance, if the size of the remaining PDUs of the PDU set is larger than a preconfigured threshold (e.g., > x bytes) and the remaining time with respect to the PSDD is less than a preconfigured time threshold, the WTRUmay determine to also consider the remaining time with respect to the PSDD when selecting an LCP configuration. This may be advantageous since, with a fast-approaching deadline of the remaining time with respect to the PSDD and a large size of the remaining PDUs of the PDU set to be multiplexed into a MAC PDU, there may not be sufficient time and / or resources (e.g., limited size of MAC PDU) to multiplex all the PDUs of the PDU set using a legacy LCP that only considers LCH parameters such as priority and PBR and may not ensure that the remaining time criteria is met.

[0148] Other parameters may include dependencies between different data units, such as dependencies between PDUs of a PDU set, dependencies between different PDU sets, and / or dependencies between different data bursts

[0149] Other parameters may include a First PDU of the PDU set indicator, an End PDU of PDU set indicator, and / or an End of data burst indicator.

[0150] In some examples, the WTRU may also be preconfigured with rules / conditions specifying when to activate the ‘special’ LCP configuration. For example, any one or more of the rules described in the following paragraphs may apply.

[0151] The WTRU may be configured with one or more rules or conditions to activate the ‘special’ LCP configuration after it has measured a remaining time value with respect to the PSDD below a certain threshold preconfigured by the network.

[0152] The WTRU may be configured with one or more rules or conditions to activate the ‘special’ LCP configuration after it has measured a remaining time value with respect to the PSDB below a certain threshold preconfigured by the network.

[0153] The WTRU may be configured with one or more rules or conditions to activate the ‘special’ LCP configuration after it has measured a remaining time value with respect to the PSDD below a certain threshold preconfigured by the network for a number of PDU sets greater than a certain number threshold preconfigured by the network. In some solutions, this may be a consecutive number of PDU sets with remaining time value with respect to PSDD exceeding the threshold. In some solutions, it may be non-consecutive PDU sets with remaining time value with respect to PSDD exceeding the threshold. In some solutions, this may be a consecutive number of PDU sets with remaining time value with respect to PSDD exceeding the threshold within a certain time period. In some solutions, it may be non-consecutive PDU sets with remaining time value with respect to PSDD exceeding the threshold within a certain time period.

[0154] The WTRU may be configured with one or more rules or conditions to activate the ‘special’ LCP configuration after it has measured a remaining time value with respect to the PSDB below a certain threshold preconfigured by the network a certain number of times that exceed another threshold preconfigured by the network.

[0155] The WTRU may be configured with one or more rules or conditions to activate the ‘special’ LCP configuration after it has measured a remaining time value with respect to the PSDD below a certain thresholdpreconfigured by the network a certain number of times that exceed another threshold preconfigured by the network.

[0156] The WTRU may be configured with one or more rules or conditions to activate the ‘special’ LCP configuration after it has measured a certain jitter in the uplink data coming from the application in the WTRU. For instance, if jitter is larger than a preconfigured threshold from the network, the WTRU is configured to activate the ‘special’ LCP configuration. In some solutions, this may be based on an instantaneous jitter value that the WTRU has just measured. For example, the WTRU may have an expected arrival time of the data, e.g., based on knowledge of the uplink traffic periodicity. If the data arrives later or earlier than the expected arrival time, this may constitute a positive or negative jitter value based on whether it is early arrival or late arrival. The WTRU may compute the instantaneous jitter value by determining the difference between the actual arrival time of the data and the expected arrival time of the data. This may be done on the granularity of a data burst and / or PDU set and / or PDU. When the instantaneous jitter value exceeds a threshold preconfigured by the network, the WTRU may activate the 'special' LCP configuration. In some solutions, this may be based on jitter statistics that the WTRU has measured over a period of time. For example, the WTRU may compute the instantaneous jitter value as described in examples above multiple times over a time duration to get data on the jitter statistics over some time. The jitter statistics may, for example, constitute a mean / average / min / max / median jitter value. In some examples, if the mean and / or median jitter value exceeds a preconfigured threshold from the network, the WTRU may activate the ‘special’ LCP configuration.

[0157] In some examples, the WTRU may be configured to activate the ‘special’ LCP configuration after receiving an explicit indication from the network. The WTRU may receive such an indication from the network, for example, after the WTRU has transmitted an indication of the PSDD to the network and / or an indication of the remaining time with respect to the PSDD and / or an indication of the remaining time with respect to the PSDB. The WTRU may transmit indications of any of the PSDD, the remaining time with respect to the PSDD, and / or the remaining time with respect othe PSDB, e.g., in a Delay Status Report (DSR) and / or a Buffer Status Report (BSR) to the network (e.g., a base station such as a gNB, a TRP, or a network node).

[0158] In some examples, after sending a certain number of DSR reports, the WTRU may receive an indication from the network to activate the ‘special’ LCP configuration.

[0159] Even after following the rules / conditions configured by the network to activate the ‘special’ LCP configuration, the WTRU may still need to send a request to the network to request activating the special 'LCP configuration’. Following this indication, the WTRU may be able to activate the LCP configuration for some time, or the WTRU may need to wait for an acknowledgement from the network before it can activate the special ‘LCP configuration’. In some solutions, the acknowledgement from the network may carry information on the time duration to activate the ‘special’ LCP configuration.

[0160] In some solutions, the ‘special’ LCP configuration may only apply to a subset of LCHs. In one solution, the ‘special’ LCP configuration may only apply to certain grants, e.g., some grants allocated by the network may carry an indication to indicate to the WTRU that it may use the ‘special’ LCP configuration to fillin PDUs into that grant. In some solutions, the network may specify each grant whereby the WTRU may be allowed to apply the 'special’ LCP configuration to fill in the grant In some solutions, the network may specify a maximum number of grants that the WTRU may be allowed to apply the ‘special’ LCP configuration to fill in those grants; in some examples those grants may be consecutive, in some examples those grants may be non-consecutive.

[0161] In some solutions, the WTRU may be configured to apply the ‘special’ LCP configuration based on a volume of data per LCH with a PSDD and / or PSDB and / or remaining time with respect to PSDB and / or remaining time with respect to PSDD less than a certain time threshold. For example, if the volume of data in LCH A, which has a remaining time with respect to PSDD that is below a time threshold, T 1 ms, is larger than a volume threshold V 1 , the WTRU may be configured to apply the ‘special’ LCP configuration.

[0162] Routing solutions involving LCH switching are described herein. In some solutions, the WTRU may be configured or may receive an indication from the network to perform one or more actions that take into account the PSDD and / or the remaining time with respect to the PSDD. Such actions may be referred to herein as LCP-related actions and / or ‘special’ LCP-related actions The WTRU may receive an indication from the network in any of a MAC CE, DCI, or other logically equivalent DL signaling to perform the one or more actions. Alternatively, or additionally, the WTRU may measure the remaining time with respect to the PSDD and / or the remaining time with respect to the PSDB and, based on the amount of the remaining time, the WTRU may determine to perform the one or more actions. In any of such cases, the actions may include any one or more of the steps described in the following paragraphs.

[0163] In some actions, a WTRU may select a LCH based on the PSDD / PSDB value and / or the remaining time with respect to the PSDD / PSDB value, also referred to as a ‘special’ LCH herein. For example, the WTRU may have been configured or preconfigured with multiple LCHs, each with different priorities and rules concerning when or how to select an LCH. In a legacy system, based on the DRB (parameters) that the data is mapped to, the WTRU may simply select an LCH. In such legacy approaches, the DRB: LCH mapping may be static. In accordance with examples described herein, however, the WTRU (e.g., a PDCP entity or another logically equivalent entity implemented in or configured at a WTRU) may consider the PSDD and / or the remaining time with respect to the PSDD, possibly in addition to the priority and / or importance of the PDU set and map the PDU set to an LCH accordingly.

[0164] In some examples, there may be multiple LCHs mapped to one DRB. In legacy systems, a DRB:LCH mapping = 1 :M may apply only for the case of Dual connectivity and Carrier Aggregation. In accordance with one or more examples described herein, multiple LCHs may be mapped to one DRB. The WTRU may be configured with the parameters for all the LCHs (e.g., priority of each LCH). The WTRU (e.g., a PDCP entity or another logically equivalent entity implemented in or configured at a WTRU) would consider the PSDD and / or the remaining time with respect to the PSDD, possibly in addition to the priority and / or importance of the PDU set and select the appropriate LCH to map the PDU set from the DRB

[0165] In some solutions, the WTRU may only consider the PSDD and / or the remaining time with respect to the PSDD when selecting the LCH to map the PDU set to.

[0166] In some solutions, the WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to other parameters of the PDU set / data when selecting the LCH to map the PDU set to, as described in the following paragraphs.

[0167] The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to PDU set priority. The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to the PDU set importance.

[0168] The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to the PDU set type. As described substantially in paragraphs above, the PDU set type may determine whether the PDU set corresponds to a PDU Set Integral Handling indicator (PSIHI) type, i.e., a PDU set whereby all the PDUs of the PDU set are needed by the application for the successful decoding of the PDU set. Alternatively, or additionally, the PDU set may be of another type whereby only a subset of PDUs of the PDU set are needed for the successful decoding of the PDU set at the application The subset may correspond to, for example, 90%, 50%, 40% or a different percentage, of PDUs of the PDU set that are needed at the application for the successful decoding of the PDU set.

[0169] The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to the type of frame that the PDU set corresponds to, i.e., whether the PDU set corresponds to a l-frame, P- frame, B-frame, any other type of frame according to the application, whether it is a primary or secondary or tertiary frame, whether it is a first frame, a differential frame, or another type of frame.

[0170] The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to the importance and / or priority of the PDUs of the PDU set. In some examples, Different PDUs of a PDU set may have different importance and / or priority which may have been set by the application. For example, different PDUs within a PDU set may correspond to different parts of the ‘frame’ or ‘picture’, for example, the primary part versus the differential part and have different importance and / or priority value.

[0171] The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to a number of PDUs in the PDU set. For example, if the number of PDUs in the PDU set is larger than a preconfigured number threshold and the remaining time with respect to the PSDD is less than a preconfigured time threshold, the WTRU may determine to also consider the remaining time with respect to the PSDD when selecting an LCH to map the PDU set to. This may be advantageous since the priority of the default LCH (i.e., the LCH the PDU set would have been mapped to if only traditional parameters (e.g., priority) were considered) may not be sufficient to transmit all the PDUs of the PDU set if the number of PDUs of the PDU set is larger than the preconfigured threshold.

[0172] The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to a remaining number of PDUs in the PDU set. For example, if the remaining number of PDUs in the PDU set is larger than a preconfigured number threshold and the remaining time with respect to the PSDD is less thana preconfigured time threshold, the WTRU may determine to also consider the remaining time with respect to the PSDD when selecting an LCH to map the remaining PDUs of the PDU set to. This may be advantageous since the priority of the default LCH (i.e., the LCH the remaining PDUs of the PDU set would have been mapped to if only traditional parameters (e.g., priority) were considered) may not be sufficient to transmit all the remaining PDUs of the PDU set if the remaining number of PDUs of the PDU set is larger than the preconfigured threshold.

[0173] The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to a size of the PDU set, e.g., in bytes, kB, MB, or another unit of information. For example, if the size of the PDU set is larger than a preconfigured threshold (e.g., > x bytes) and the remaining time with respect to the PSDD is less than a preconfigured time threshold, the WTRU may determine to also consider the remaining time with respect to the PSDD when selecting an LCH to map the PDU set to. This may be advantageous since the priority of the default LCH, (i.e., the LCH the PDU set would have been mapped to if only traditional parameters (e.g., priority) were considered) may not be sufficient to transmit all the PDUs of the PDU set if the size of the PDU set is larger than the preconfigured threshold.

[0174] The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to a size of remaining PDUs of PDU set, e.g., in bytes, kB, MB, etc. For example, if the size of the remaining PDUs of the PDU set is larger than a preconfigured threshold (e.g., > x bytes) and the remaining time with respect to the PSDD is less than a preconfigured time threshold, the WTRU may determine to also consider the remaining time with respect to the PSDD when selecting an LCH to map the remaining PDUs of the PDU set to since the priority of the default LCH, i.e., the LCH the remaining PDUs of the PDU set would have been mapped to if only traditional parameters (e.g , priority) were considered may not be sufficient to transmit all the remaining PDUs of the PDU set if the size of the remaining PDUs of the PDU set is larger than the preconfigured threshold.

[0175] The WTRU may consider the PSDD and / or the remaining time with respect to the PSDD in addition to dependencies between different data units, which may include dependencies between PDUs of a PDU set, dependencies between different PDU sets, dependencies between different data bursts, a first PDU of PDU set indicator, an end PDU of PDU set indicator, or an end of data burst indicator.

[0176] In some solutions, the WTRU may have been preconfigured with multiple LCHs, out of which one or more LCH(s) are configured with corresponding rules or conditions by which only the PSDD and / or a remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) are considered when selecting such LCH(s). In some examples, when the remaining time with respect to the PSDD is below a configured (or reconfigured) threshold, the WTRU may select the one or more LCH(s) based on rules for considering the remaining time (i.e., as opposed to traditional / legacy LCH(s) configured with rules or conditions by which the priority of the data is considered in their selection). In some examples, when the PSDD is below a configured (or reconfigured) threshold, the WTRU may select the one or more LCH(s) based on rules for considering the time / PSDD duration (i.e., as opposed to traditional / legacy LCH(s) configured withrules or conditions by which the priority of the data is considered in their selection). If there are more than one LCH(s) configured with rules or conditions by which the PSDD and / or remaining time (e.g., with respect to PSDD and / or PSDB) are considered in their selection, the WTRU may select the LOH based on the amount / length of the PSDD and / or remaining time. For example, if LCH A1 and LCH A2 are configured with rules or conditions by which only the PSDD and / or remaining time are considered in their selection, and the priority of A1 is greater than the priority of A2, if a remaining time with respect to PSDD of a PDU set < 10ms, the WTRU may be configured to select LCH A1 ; if a remaining time with respect to PSDD of a PDU set < 20ms, the WTRU may be configured to select LCH A2.

[0177] In some solutions, the WTRU may have been preconfigured with multiple LCHs, out of which one or more LCH(s) are configured with rules or conditions by which the PSDD and / or remaining time (e.g., remaining time with respect to PSDB and / or a remaining time with respect to PSDD) are considered in their selection in addition to the legacy / traditional parameters (e.g., priority of the data and LCH) In an example, LCH B1 and LCH B2 may be configured with rules or conditions by which the PSDD and / or remaining time are considered in their selection. The priority of LCH B1 may be greater than the priority of LCH A2, the remaining time with respect to PSDD of PDU set 1 may be < 10ms, and the remaining time with respect to PSDD of PDU set 2 may be < 10ms, where 10ms may be the threshold for selecting an LCH with consideration of the remaining time. In such case, if PDU set 1 has higher importance / priority compared to PDU set 2, the WTRU may be configured to select LCH B1 for mapping of PDU set 1 and select LCH B2 for mapping of PDU set 2.

[0178] In some solutions, the WTRU may also be preconfigured with rules / conditions for selecting an LCH with consideration of the PSDD / PSDB and / or remaining time (e.g , a remaining time with respect to PSDB and / or a remaining time with respect to PSDD). For example, any one or more of the following rules may apply.

[0179] In some rules, the WTRU may be configured to select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) after it has measured a remaining time value with respect to the PSDD below a certain threshold that is configured or preconfigured by the network.

[0180] In some rules, the WTRU may be configured select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or remaining time with respect to PSDD) after it has measured a remaining time value with respect to the PSDB below a certain threshold that is configured or preconfigured by the network.

[0181] In some rules, the WTRU may be configured select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) after it has measured a remaining time value with respect to the PSDD that is below a certain threshold configured or preconfigured by the network for a number of PDU sets greater than a certain number threshold preconfigured by the network. In some solutions, the number of PDU sets may be a consecutive number of PDU sets for which a remaining time value with respect to PSDD exceeds the threshold. In some solutions, the number of PDU sets may be a number of non-consecutive PDU sets for which a remaining time value withrespect to PSDD exceeds the threshold. In some solutions, the number of PDU sets may be a consecutive number of PDU sets for which a remaining time value with respect to PSDD exceeds the threshold within a certain time period. In some solutions, the number of PDU sets may be non-consecutive PDU sets for which a remaining time value with respect to PSDD exceeds the threshold within a certain time period.

[0182] In some rules, the WTRU may be configured to select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) after it has measured a remaining time value with respect to the PSDB that is below a certain threshold configured or preconfigured by the network a certain number of times that exceeds another threshold configured or preconfigured by the network.

[0183] In some rules, the WTRU may be configured to select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) after it has measured a remaining time value with respect to the PSDD that is below a certain threshold configured or preconfigured by the network a certain number of times that exceeds another threshold configured or preconfigured by the network.

[0184] In some rules, the WTRU may be configured to select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) after it has measured a certain jitter in the uplink data coming from the application in the WTRU. In some examples if jitter is larger than a threshold (which may be configured or preconfigured by the network), the WTRU may be configured to select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD). In some solutions, the jitter may be based on an instantaneous jitter value that the WTRU has recently or just measured. For example, the WTRU may determine an expected arrival time of the data, for instance, based on knowledge of an uplink traffic periodicity. If the data arrives later or earlier than the expected arrival time, this may constitute a positive or negative jitter value based on whether it is early arrival or late arrival. The WTRU may compute the instantaneous jitter value by determining the difference between the actual arrival time of the data and the expected arrival time of the data. This may be done on the granularity of a data burst and / or PDU set and / or PDU. When the instantaneous jitter value exceeds a threshold, which may be configured or preconfigured by the network, the WTRU may select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or remaining time with respect to PSDD). In some solutions, the determined jitter may be based on or include jitter statistics that the WTRU has measured over a period of time For example, the WTRU may compute an instantaneous jitter value as described in examples above multiple times over a time duration to obtain or generate data on the jitter statistics over some time. The jitter statistics may for example include a mean / average / min / max and / or median jitter value. In some examples, if the mean and / or median jitter value exceeds a preconfigured threshold from the network, the WTRU may select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD).

[0185] In some rules, the WTRU may be configured to select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) after receiving an explicit indication from the network. The WTRU may receive such an indication from the network after the WTRU has transmitted an indication of the PSDD and / or an indication of the remaining time with respect to the PSDD and / or an indication of the remaining time with respect to the PSDB to the network (e g., a base station such as a gNB, a network node, or a TRP), for example in a Delay Status Report (DSR) and / or a Buffer Status Report (BSR) sent by the WTRU.

[0186] In some rules, after sending a certain number of DSR reports, the WTRU may receive an indication from the network to select an LCH based on the PSDD / PSDB and / or remaining time (e.g , a remaining time with respect to PSDB and / or a remaining time with respect to PSDD).

[0187] In some rules, even after following the rules / conditions configured by the network to select an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or remaining time with respect to PSDD), the WTRU may still need to send a request to the network to request selection of an LCH . Following this indication, the WTRU may be able to select an LCH for some time or the WTRU may need to wait for an acknowledgement from the network before it can select the ‘special’ LCH. In some solutions, the acknowledgement from the network may carry information such as the time duration during which the WTRU is allowed to use / select the ‘special’ LCH.

[0188] In some solutions, the WTRU may be configured to select an LCP restriction based on the PSDD / PSDB value and / or the remaining time with respect to the PSDD / PSDB value, herein referred to as a ‘special’ LCP restriction. For example, the WTRU may have been configured or preconfigured with one or more LCP restrictions. For example, an LCH may be temporarily blocked by the network to allow the WTRU to prioritize the ‘special’ one or more LCH(s) that may be selected with consideration of the PSDD and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD). The triggers for when the WTRU would apply this LCP restriction may include all or any of the triggers for when the WTRU may switch to the ’special’ LCP configuration that considers remaining time, for example. The triggers for when the WTRU would apply this LCP restriction may also include all or any of the triggers for when the WTRU may switch to a ’special’ LCH that may be selected with consideration of the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or remaining time with respect to PSDD).

[0189] In some solutions, such a routing solution, i.e., selection of a default LCH versus a traditional LCH from legacy specifications (e.g., Release 18 and earlier) may be performed at any layer in the WTRU (e.g., at PDCP layer in the WTRU). The WTRU (e g. a PDCP entity implemented at the WTRU) may have awareness of the PSDD and / or PSDB and / or remaining time with respect to PSDD and / or remaining time with respect to PSDB for example. For example, the WTRU may have awareness of the PSDD and / or PSDB from internal signaling in the WTRU from the application. For example, the WTRU (e.g. PDCP entity) may measure the remaining time of the PDU set (e g., a remaining time with respect to PSDD and / or remaining time with respect to PSDB). In some solutions, the WTRU may use existing mechanisms (e.g., a discardTimerat the PDCP entityor layer) to keep track of the remaining time with respect to PSDD and / or remaining time with respect to PSDB. In some solutions, there may be new mechanisms (e.g, at the PDCP entity or layer) to keep track of the remaining time with respect to PSDD and / or remaining time with respect to PSDB. These may include, for example, a new discard timer whereby the discard timer value is based on the PSDD and / or a new discard timer whereby the discard timer value is based on the PSDB The WTRU (e.g., a PDCP entity implemented at the WTRU) may start the timer upon reception of the PDUs of the PDU set, which may all arrive at once or may arrive sequentially. Time of reception of PDUs of the PDU set (IA) may correspond to the time of arrival of PDU(s) of the PDU set at the lower layers in the WTRU (e.g , PDCP). The (remaining) time to serve the PDU set (i.e, route the PDU set and / or PDUs of the PDU set to a logical channel and / or multiplex the PDU set and / or PDUs of the PDU set into from one or more logical channel(s) into a MAC PDU) may be computed based on the arrival time of the PDUs of the PDU set and the PSDD and / or PSDB and / or remaining time with respect to PSDD and / or remaining time with respect to PSDB.

[0190] In some solutions, the WTRU may require an acknowledgement from the network following determination of routing a PDU set and / or PDUs of a PDU set to an LCH that is selected with consideration of the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or remaining time with respect to PSDD). The WTRU may not be allowed to use the ‘special’ LCH unless an ACK to do so is received from the network.

[0191] In some solutions, the ‘special’ LCP configuration and / or LCP related action (e.g., determining to use an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD)) may only apply to a subset of LCHs. In some solutions, the ‘special’ LCP configuration and / or LCP related action may only apply to certain grants For example, some grants allocated by the network may carry an indication to indicate to the WTRU that it may use the ‘special’ LCP configuration and / or undertake an LCP related action (e.g., use an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) to fill in PDUs into that grant. In some solutions, the network may specify each grant whereby the WTRU may be allowed to apply the ‘special’ LCP configuration and / or LCP related action (e.g., use an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) to fill in the grant. In some solutions, the network may specify a maximum number of grants that the WTRU may be allowed to apply the 'special' LCP configuration and / or LCP related action to fill in those grants; in some examples those grants may be consecutive, while in other examples those grants may be non- consecutive.

[0192] In some solutions, the WTRU may be configured to apply the ‘special’ LCP configuration and / or LCP related action (e.g, use an LCH based on the PSDD / PSDB and / or remaining time (e.g, a remaining time with respect to PSDB and / or a remaining time with respect to PSDD) based on the volume of data per LCH with a PSDD and / or PSDB and / or remaining time with respect to PSDB and / or remaining time with respect to PSDD less than a certain time threshold. For example, if the volume of data in LCH A, whose remaining time with respect to PSDD is below a time threshold T 1 ms, is larger than a volume threshold V1 , the WTRU may beconfigured to use an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or remaining time with respect to PSDD).

[0193] Solutions for determining a duration, d, during which to apply a new LCP configuration, perform LCH switching, or apply LCP restrictions are described herein.

[0194] In some solutions, the network may determine the time duration d for which the WTRU is allowed to carry out a LCP related action (e.g., activate the ‘special’ LCP configuration, activate the ‘special’ LCP restriction, route PDUs and / or PDU sets to an LCH based on the PSDD / PSDB and / or remaining time (e.g., a remaining time with respect to PSDB and / or a remaining time with respect to PSDD)). The network may transmit an indication of the time duration d to the WTRU e.g., via DCI, MAC CE, RRC (re)configuration messages, PDCP control PDU(s), or other logically equivalent messages or signaling.

[0195] In some solutions, the WTRU may be configured to determine the time duration d during which the WTRU is allowed to perform any of the aforementioned LCP related actions. This determination may be based on and / or be a function of, for example, any one or more of the following parameters or conditions.

[0196] One such parameter or condition may be the (remaining) time to serve PDU set tA. For example, a smaller (remaining) time tAmay trigger the WTRU to perform an LCP-related action while a longer tAmay not since the WTRU may be able to serve the PDU set (i e., deliver the PDU set within its QoS) using legacy procedures

[0197] One such parameter or condition may be the PSDD of the PDU set. For example, for data with a very small value PSDD, the WTRU may be configured to apply the ‘special’ LCP configuration for a longer duration d versus that for data with average value of PSDD, as the latter may be served with the legacy procedures

[0198] One such parameter or condition may be the PSDB of the PDU set. For example, a condition may be a number of times tAis below a configured or preconfigured threshold. For example, if the number of times is below a threshold is larger than a configured or preconfigured threshold, the WTRU may determine to apply a longer time duration d versus than in the scenario where the number of times tAis below a threshold is smaller than a configured or preconfigured threshold.

[0199] One such parameter or condition may be the number of times tAis below a preconfigured threshold within a certain time duration In some solutions, the WTRU may still need an acknowledgement from the network following the determination of the duration d to confirm that it is allowed to carry out the LCP related action for this time duration. The WTRU may send a request to the network requesting to perform the LCP related action The request may also carry or indicate the determined time duration d In some solutions, the WTRU may receive a confirmation from the network (i.e., in a message or a signal) indicating to proceed and apply or perform the LCP related action for the time duration d. In some solutions, the WTRU may receive or determine a NACK, in which case it may not apply any ‘special’ LCP related action. In some solutions, the WTRU may receive a message from the network with another time duration d, different from the one requested by the WTRU to the network.

[0200] In some solutions, the network may set a maximum time whereby the WTRU is permitted to apply or perform any LCP related action, and the network may indicate this time duration to the WTRU via a DCI, MAC CE, RRC, or other logically equivalent messages or signaling. In some cases, the time duration d, which may be determined by the WTRU, for example, may need to be less than or equal to the maximum time duration. If the WTRU determines a time duration d larger than the indicated maximum time duration, the WTRU may only apply or perform a LCP related action for the time duration d. In some solutions, the WTRU may send an indication to the network to request a larger limit on the time duration d, e.g., d+t ms. In some solutions, the WTRU may only be allowed to request a longer time duration d a maximum number of times. If exceeded, the WTRU may only apply or perform an LCP-related action for a time duration d.

[0201] Solutions in which a WTRU reverts back to a default configuration, i.e., a default LCP configuration, or default LCH priority, are described herein. In some solutions, the WTRU may be configured to revert back to the default configuration, e.g., the default LCP configuration, the default LCHs, and / or deactivate any ‘special’ LCP restriction(s) based on one or more conditions or requirements. One condition may be that the time duration d is over. One condition may be the expiration of a timer and / or counter, for example, based on time duration d. One condition may be the reception of an indication from the network to revert back to the default configuration and / or deactivate any ‘special’ LCP related configuration. One condition may be the (re)measurement of jitter, such as if jitter is found to be minimal, e g., below a preconfigured threshold. One condition may be the reception of an updated PSDB (e.g., from an application), or the reception of an updated PSDD (e.g , from application), such as if the updated PSDD is large (e g., larger than a preconfigured threshold), the WTRU may be configured to revert back to legacy procedures.

[0202] Solutions in which a WTRU applies a discardTimer based on PSDD or a remaining time with respect to PSDD are described herein. In some embodiments described herein, a WTRU may be configured with multiple discardTimer values. In a legacy system, the WTRU may be configured with one discardTimer value per PDCP entity, which may be configured by the network based on the PDB of the packets.

[0203] In some solutions, the WTRU may receive from the network configuration information indicating multiple discardTimer values per PDCP entity, where each discardTimer timer value may be a standalone value. In some solutions, the WTRU may receive from the network a configuration for multiple discardTimer values per PDCP entity, where each discardTimer timer value may be associated with a PSDD value. In some solutions, the WTRU may receive from the network a configuration for multiple discardTimer values per PDCP entity, where each discardTimer timer value may be associated with a remaining time value with respect to a PSDD value. In some solutions, the WTRU may receive from the network a configuration for multiple discardTimer values per PDCP entity, where each discardTimer timer value may be associated with a remaining time value with respect to a PSDB value.

[0204] In some solutions, the WTRU may receive from the network a configuration for multiple discardTimers per PDCP entity, where each discardTimer timer may be a standalone timer. In some solutions, the WTRU may receive from the network a configuration for multiple discardTimers per PDCP entity whereeach discardTimer may be associated with a PSDD value. In some solutions, the WTRU may receive from the network a configuration for multiple discardTimers per PDCP entity where each discardTimer may be associated with a remaining time value with respect to a PSDD value. In some solutions, the WTRU may receive from the network a configuration for multiple discardTimers per PDCP entity, where each discardTimer may be associated with a remaining time value with respect to a PSDB value.

[0205] In some solutions, the WTRU may receive from an application a PSDD value and / or PSDB value corresponding to the traffic. Alternatively, or additionally, a PSDD value and / or PSDB may be associated with the QoS flow of the traffic that the WTRU (e.g., an SDAP in the WTRU) may have awareness of. Based on the PSDD value and / or remaining time with respect to PSDD and / or PSDB value and / or remaining time with respect to PSDB value, the WTRU may select the discardTimer and / or discardTimer value according to the configuration it received from the network.

[0206] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and 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, or any host computer.

Claims

CLAIMSWhat is Claimed:

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information indicating first parameters associated with a first logical channel prioritization (LCP) configuration and second parameters associated with a second LCP configuration; determining an arrival time associated with a protocol data unit (PDU) set at which at least one PDU of the PDU set is available to be sent in at least one uplink transmission; receiving information indicating a PDU set delay budget (PSDB) and information indicating a PDU set delay deadline (PSDD) associated with the PDU set; determining, based on the arrival time, the PSDB, and the PSDD, a remaining amount of time to send PDUs of the PDU set; based on a determination that the remaining amount of time to send the PDUs of the PDU set is less than a threshold or a determination that the remaining amount of time to send the PDUs of the PDU set is greater than zero, determining a time duration during which to apply the second LCP configuration; and sending, during the determined time duration, the PDUs of the PDU set in one or more uplink transmissions using the second parameters associated with the second LCP configuration.

2. The method of claim 1, further comprising applying the first parameters associated with the first LCP configuration after the determined time duration has elapsed3. The method of claim 1 or 2, wherein the remaining amount of time to send PDUs of the PDU set is determined based on an arrival time of a first PDU of the PDU set or a last PDU of the PDU set.

4. The method of any of claims 1 to 3, further comprising sending, during the determined time duration, PDUs of another PDU set in one or more uplink transmissions using the second parameters associated with the second LCP configuration.

5. The method of claim 4, wherein the PDUs of the PDU set are associated with a first quality of service (QoS) and the PDUs of the another PDU set are associated with a second QoS that is different from the first QoS.

6. The method of claim 4 or 5, wherein at least one PDU of the another PDU set is sent before the PDUs of the PDU set.

7. The method of any of claims 1 to 6, wherein the first LCP configuration is a default LCP configuration.

8. The method of any of claims 1 to 7, wherein the arrival time is a time at which one or more of the PDUs of the PDU set arrive in a buffer.

9. The method of any of claims 1 to 8, further comprising receiving an indication that all PDUs of the PDU Set are needed for the usage of the PDU Set by an application layer.

10. The method of any of claims 1 to 9, further comprising receiving information indicating a plurality of PSDDs associated with different traffic types.

11. A wireless transmit / receive unit (WTRU) comprising: a processor; and a transceiver; the processor and the transceiver configured to receive configuration information indicating first parameters associated with a first logical channel prioritization (LCP) configuration and second parameters associated with a second LCP configuration; the processor configured to determine an arrival time associated with a protocol data unit (PDU) set at which at least one PDU of the PDU set is available to be sent in at least one uplink transmission; the processor and the transceiver configured to receive information indicating a PDU set delay budget (PSDB) and information indicating a PDU set delay deadline (PSDD) associated with the PDU set; the processor configured to determine, based on the arrival time, the PSDB, and the PSDD, a remaining amount of time to send PDUs of the PDU set; the processor configured to, based on a determination that the remaining amount of time to send the PDUs of the PDU set is less than a threshold, or a determination that the remaining amount of time to send the PDUs of the PDU set is greater than zero, determine a time duration during which to apply the second LCP configuration; and the processor and the transceiver configured to send, during the determined time duration, the PDUs of the PDU set in one or more uplink transmissions using the second parameters associated with the second LCP configuration.

12. The WTRU of claim 11 , the processor further configured to apply the first parameters associated with the first LCP configuration after the determined time duration has elapsed.

13. The WTRU of claim 11 or 12, wherein the remaining amount of time to send PDUs of thePDU set is determined based on an arrival time of a first PDU of the PDU set or a last PDU of the PDU set.

14. The WTRU of any of claims 11-13, the processor further configured to send, during the determined time duration, PDUs of another PDU set in one or more uplink transmissions using the parameters associated with the second LCP configuration.

15. The WTRU of claim 14, wherein the PDUs of the PDU set are associated with a first quality of service (QoS) and the PDUs of the another PDU set are associated with a second QoS that is different from the first QoS.

16. The WTRU of claim 14 or 15, wherein at least one PDU of the another PDU set is sent before the PDUs of the PDU set.

17. The WTRU of any of claims 11 to 16, wherein the first LCP configuration is a default LCP configuration.

18. The WTRU of any of claim 11 to 17, wherein the arrival time is a time at which one or more of the PDUs of the PDU set arrive in a buffer.

19. The WTRU of any of claims 11-18, the processor and the transceiver further configured to receive an indication that all PDUs of the PDU Set are needed for the usage of the PDU Set by an application layer.

20. The WTRU of any of claims 11-19, the processor and the transceiver further configured to receive information indicating a plurality of PSDDs associated with different traffic types.

Images