Logical control prioritization enhancements for delay-critical data in extended reality

Abstract

Systems, methods, and instrumentalities are described herein that may be associated with logical control prioritization (LCP) enhancements for delay-critical data in extended reality (XR). In examples, a device may be configured to receive configuration information that may include at least one of a first prioritized bit rate (PBR) value, a second PBR value associated with a secondary type of data, or condition(s) to determine the secondary type of data. The device may receive a grant for transmission of a medium access control packet data unit (MAC PDU). The device may fill the MAC PDU with data up to the second PBR value based on the determined secondary type of data being in a buffer after the WTRU has filled the MAC PDU with data up to the first PBR value. The device may transmit a transport block (TB) associated with the MAC PDU in the received grant.

Description

LOGICAL CONTROL PRIORITIZATION ENHANCEMENTS FOR DELAY-CRITICAL DATA IN EXTENDED REALITYCROSS-REFERENCE TO RELATED APPLICATIONS

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

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

[0003] Systems, methods, and instrumentalities are described herein that may be associated with logical control prioritization (LCP) enhancements for delay-critical data in extended reality (XR).

[0004] In examples, a device (e.g., a wireless transmit / receive unit (WTRU)) may be configured to receive configuration information. The configuration information may include at least one of a first prioritized bit rate (PBR) value, a second PBR value associated with a secondary type of data (e.g., delay-critical data), or condition(s) to determine the secondary type of data. The device may receive a grant for transmission (e.g., uplink transmission) of a medium access control protocol data unit (MAC PDU) (e.g., a grant for an uplink transmission associated with a MAC PDU). The device may determine the secondary type of data (e.g., whether a data set is the secondary type of data). In examples, the secondary type of data (e.g., whether the data set is the secondary type of data) may be determined based on the condition(s) received in the configuration information. In examples, the condition(s) may include at least one of a remaining PDU set delay budget (PSDB) of the data set (e.g., the secondary type of data), a duration the data set (e.g., the secondary type of data) stays in the buffer, an importance of the data set (e.g., the secondary type of data), or a priority of the data set (e.g., the secondary type of data).

[0005] The device may determine an amount of data associated with a MAC PDU based on the first PBR value or the second PBR value. In examples, the device may fill the MAC PDU with data up to the second PBR value (e.g., based on the secondary type of data being in a buffer and based on the device filling (e.g., after the device has filled) the MAC PDU with data up to the first PBR value. In examples, the second PBR value may be applied on a per data radio bearer (DRB) basis, per logical channel (LCH) basis, or per PDU set basis. In examples, the data filled up to the second PBR value may be the secondary type of data or may be any type of data. The device may transmit a transport block (TB) associated with the MAC PDU in the received grant for transmission.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 A 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. 1 C 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. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.DETAILED DESCRIPTION

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

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

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

[0013] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combinationof 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.

[0014] The base stations 114a, 114b may communicate with one or more ofthe 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).

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

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

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

[0018] 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 multipletypes of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).

[0019] 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, CDMA20001X, 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.

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

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

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

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

[0024] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / recei ve 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.

[0025] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, 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. 1B 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.

[0026] 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 I , 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.

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

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

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

[0030] 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 maybe 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.

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

[0032] 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 handsfree 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, and / or a humidity sensor.

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

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

[0035] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c overthe air interface 116. In oneembodiment, 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.

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

[0037] The CN 106 shown in FIG. 1 C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements 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.

[0038] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an 81 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.

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

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

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

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

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

[0044] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an 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 (I BSS) 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.

[0045] 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 via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance(CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g. , every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

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

[0047] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 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).

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

[0049] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which 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., MTCtype devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0050] 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.11 ah is 6 MHz to 26 MHz depending on the country code.

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

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

[0053] 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 ofthe wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and / or lasting varying lengths of absolute time).

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

[0055] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

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

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

[0058] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

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

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

[0061] In view of Figures 1A-1D, and the corresponding description of Figures 1A-1D, 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.

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

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

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

[0065] Systems, methods, and instrumentalities are described herein that may be associated with logical control prioritization (LCP) enhancements for delay-critical data in extended reality (XR).

[0066] In examples, a device (e.g., a wireless transmit / receive unit (WTRU)) may be configured to receive configuration information. The configuration information may include at least one of a first prioritizedbit rate (PBR) value, a second PBR value associated with a secondary type of data (e.g., delay-critical data), or condition(s) to determine the secondary type of data. The device may receive a grant for transmission (e.g., uplink transmission) of a medium access control protocol data unit (MAC PDU) (e.g., a grant for an uplink transmission associated with a MAC PDU). The device may determine the secondary type of data (e.g., whether a data set is the secondary type of data). In examples, the secondary type of data (e.g., whether the data set is the secondary type of data) may be determined based on the condition(s) received in the configuration information. In examples, the condition(s) may include at least one of a remaining PDU set delay budget (PSDB) of the data set (e.g., the secondary type of data), a duration the data set (e.g., the secondary type of data) stays in the buffer, an importance of the data set (e.g., the secondary type of data), or a priority of the data set (e.g., the secondary type of data).

[0067] The device may determine an amount of data associated with a MAC PDU based on the first PBR value or the second PBR value. In examples, the device may fill the MAC PDU with data up to the second PBR value (e.g., based on the secondary type of data being in a buffer and based on the device filling (e.g., after the device has filled) the MAC PDU with data up to the first PBR value. In examples, the second PBR value may be applied on a per data radio bearer (DRB) basis, per logical channel (LCH) basis, or per PDU set basis. In examples, the data filled up to the second PBR value may be the secondary type of data or may be any type of data. The device may transmit a transport block (TB) associated with the MAC PDU in the received grant for transmission.

[0068] 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. VR may be a rendered version of a delivered visual and audio scene. The rendering may be 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. AR may be if a user is provided with information (e.g., additional information), artificially generated objects / items, or content overlaid upon their current environment. MR may be 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 may be part of the real scene. XR may include (e.g., all) real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. The notion of immersion in the context of XR applications / services may refer to the sense of being surrounded by the virtual environment and may (e.g., may also) provide the feeling of being physically and spatially located in the virtual environment. The levels of virtuality may range from partialsensory inputs to fully immersive multi-sensory inputs which may lead to a virtual reality practically indiscernible from actual reality.

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

[0070] In XR applications, the WTRU may transmit XR traffic including one or more PDUs / PDU sets in UL (e.g., pose, gesture, video data) and / or may receive XR traffic in DL (e.g., video, audio, haptics). Such traffic may be transmitted and / or received periodically or aperiodically in one or more data flows (e.g., quality of service (QoS) flows). During UL transmissions, XR traffic may arrive from an application layer at a WTRU and / or from different devices / terminals / WTRUs (e.g., via sidelink, wifi, or wired connection) 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 (e.g., may also) experience different delays, jitter, data rate, and loss rate. Data transmission / reception and other associated functions (e.g., prioritization, multiplexing, scheduling) may be done on a timely basis with XR awareness (e.g., awareness of PDU set attributes) (e.g., for ensuring QoS and high user experience (e.g., QoE)).

[0071] In example LCP procedures, the data may be multiplexed in a MAC PDU before a scheduled grant. First, the WTRU may multiplex, for a MAC PDU, data in from a different data radio bearer (DRB)Zlogical channel (LCH) up to their respective PBR in the descending order of LCH priority. The WTRU may (e.g., may then) multiplex data from the DRB / LCH with nonzero data in decreasing priority order until data (e.g., all data) in the DRB / LCH is served or the scheduled grant is filled. As a result, these LCP procedure may be based on PBR and priorities (e.g., which may be intended to enforce priorities and avoid starving any of the flows).

[0072] Example PDU set(s), which may include one or multiple PDUs, may be introduced to manage PDUs that may have a similar impact to application. A MAC control element (MAC CE) delay status report (DSR) may be introduced to report amounts of data with delay-criticality. The WTRU may prioritize high priority data regardless of delay-criticality. As a result, delay-critical having lower priority data may not betransmited in time. Examples of enabling transmission of delay-critical data while preserving the priority and avoiding starvation of other data are provided herein.

[0073] In examples, the WTRU may fill a MAC PDU up to a second PBR value with data if the WTRU has already filled the transport block (TB) with data up to a first PBR value and there is still data of the secondary type (e.g., delay-critical data) to transmit in the buffer.

[0074] In examples, the WTRU may receive configuration information. The configuration information may include one or more: a first PBR value (e.g., within a first set of PBR values), a second PBR value (e.g., within a second set of PBR values) associated with a secondary type of data (e.g., delay-critical data), or condition(s) to determine the secondary type of data. The WTRU may receive a grant for a transmission (e.g., uplink transmission) of a MAC PDU (e.g., a grant for an uplink transmission associated with a MAC PDU). The WTRU may determine the secondary type of data (e.g., whether a data set is the secondary type of data) based on the condition(s) (e.g., configured condition(s)). In examples, the condition(s) (e.g., configured condition(s)) may include the remaining PSDB of the data set (e.g., secondary type of data). In examples, the condition(s) (e.g., configured condition(s)) may include the duration the data set (e.g., secondary type of data) stays in the buffer. In examples, the condition(s) may include the importance of the data set (e.g., secondary type of data). In examples, the condition(s) may include the priority of the data set (e.g., secondary type of data).

[0075] The WTRU may determine an amount of data associated with a MAC PDU based on the first PBR value or the second PBR value (e.g., fill the MAC PDU with data up to the second PBR value based on the secondary type of data being in the buffer (e.g., still being in the buffer) after (e.g., once) the WTRU has exhausted the first PBR (e.g., has filled the MAC PDU with data up to the first PBR value)). In examples, the WTRU may apply the second PBR value on a per DRB, a per LCH, or a per PDU set basis. In examples, the WTRU may fill the MAC PDU with secondary data up to the second PBR value. In examples, the WTRU may fill the MAC PDU with any data up to the second PBR value. The WTRU may transmit the TB associated with the MAC PDU in the received grant.

[0076] These examples may allow the WTRU to access a secondary type of data (e.g., delay-critical data), which may help avoid a potential failure in reception of an entire PDU set due to one or more PDUs of the PDU set not being delivered successfully. These examples may (e.g., may also) allow the receiver to perform selective out-of-order delivery to reduce the decoding delay of packets.

[0077] The term “the WTRU is configured with something” may be used to indicate that the WTRU is preconfigured with something, or the WTRU receives the network configuration of something. The network configuration (e.g., configuration information) may be received via a system information block (SIB), a dedicated RRC message, a MAC CE, or downlink control information (DCI). For example, “the WTRU is configured with a threshold” may be equivalent to the WTRU is preconfigured (e.g., the WTRU stores the configuration) with the threshold or the WTRU receives, from the network, an SIB, a radio resource control (RRC), a MAC CE, and / or a DCI, the threshold.

[0078] 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 associated PDUs. At the application, a PDU set (e.g., 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 require all PDUs of the PDU set at the application layer by the PDU set delay budget (PSDB) and / or PDU set delay deadline (PSDD) for the application to be able to decode the PDU set. Other PDU sets may not be of the PDU set integrated handling indication (PSIHI) type (e.g., the application may still be able to decode the PDU set if some PDUs of the PDU set are lost and / or delayed beyond the PSDB and / or PSDD). In examples, successful reception of 80% of the PDUs of the PDU set may be sufficient for the successful decoding of the PDU set at the application. In examples, successful reception of 70% of the PDUs of the PDU set may be sufficient for the successful decoding of the PDU set at the application.

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

[0080] Service data unit (SDU) and packet data unit (PDU) may be used interchangeably. SDU-segment and PDU-segment may be used interchangeably. Descriptions for PDU may be used for SDU and vice versa. Descriptions for PDU-segment may be used for SDU-segment and vice versa.

[0081] A data set may be used to represent / indicate / describe one or more of the following: a PDU / PDU- segment (e.g., a RLC PDU-segment); one or more inter-dependent PDUs; a PDU set; multiple associated PDU sets, or a data burst.

[0082] For one or more inter-dependent PDUs, a data set may include two inter-dependent PDUs, which may require coordinated transmission / reception between the two PDUs. For example, the two interdependent PDUs may require to be received / transmitted within a synchronization window. For example, a first PDU may be required to be transmitted / recei ved successfully so that transmission / reception of a second PDU may be useful. Otherwise, if the WTRU fails to transmit / receive the first PDU, transmission / reception of the second PDU may not be necessary. The WTRU may discard the second PDU.

[0083] For one or more subsets of a PDU set, the WTRU may be configured to transmit a PDU set, which may include multiple subsets of the PDU set. The subset (e.g., each subset) of the PDU set may be associated with one PDU importance. The subsets (e.g., each subset) of PDU may be associated with one type of PDU in the PDU set. A data set may be used to describe one or more subsets of a PDU set.

[0084] For multiple associated PDU sets, a data set may include two or more inter-dependent PDU sets, which may require coordinated transmission / reception (e.g., inter-dependent PDU sets in multiple interdependent QoS flows). For example, the inter-dependent PDU sets may be required to be received / transmitted within a synchronization window. For example, a first PDU set may be required to be transmitted / recei ved successfully so that transmission / reception of a second PDU set may be useful. Otherwise, if the WTRU fails to transmit / receive the first PDU set, transmission / reception of the second PDU set may not be necessary. The WTRU may discard the second PDU set. A data set may be used to describe two or more inter-dependent PDU sets, in which the inter-dependent PDU sets may be from interdependent QoS flow (e.g., for multi-modality). The inter-dependent QoS flows may be mapped to the same DRB / LCH or a different DRB / LCH.

[0085] For a data burst, the data burst may be produced by the application in a short period of time, including PDUs from one or more PDU sets.

[0086] PDU-set and PDU set may be equivalent and PDU-set or PDU set may be used interchangeably with the data set.

[0087] A PDU may be used to describe the PDU in any of non-access stratum (NAS), service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), radio link control (RLC), medium access control (MAC), physical layer (PHY), and / or a newly defined layer.

[0088] A QoS / QoE associated with a data set may be used to indicate / describe one or more of the following: one or more parameters (e.g., QoS / QoE parameters) of a PDU / PDU-segment associated withthe data set; one or more parameters of a PDU set (e.g., QoS / QoE parameters) associated with the data set; one or more parameters of a data burst associated with the data set; or one or more redundancy parameters (e.g., application layer forward error correction ratio (AL-FEC ratio) associated with the data set).

[0089] For the one or more parameters (e.g., QoS / QoE parameters) of a PDU / PDU-segment associated with the data set, the parameters of a PDU / PDU-segment may include one or more of the following: PDU set importance; the priority associated with the PDU; the latency requirement; the synchronization window; the remaining synchronization window and / or the remaining time to serve (e.g., to transmit / receive) the PDU; the reliability requirement of the PDU (e.g., packet error rate (PER)); the maximum data burst volume (MDBV); the traffic type of PDU / PDU-segment (e.g., periodic vs. aperiodic); the periodicity of the PDU / PDU-segment; or the size of the PDU / PDU-segment.

[0090] For the PDU set importance, the PDU set importance may be used to indicate the importance of the PDU set associated with the PDU, the relative importance of the PDU in the PDU set, the relative importance of the PDU in a data burst, and / or the relative importance of the PDU in the QoS flow.

[0091] For the latency requirement of the PDU / PDU-segment, the latency requirement of the PDU / PDU- segment may include: a PDB; or a remaining PDB.

[0092] For the synchronization window, the synchronization window may be used to describe the synchronization requirement between two or more interdependent PDUs. For example, to satisfy the QoE requirement of an XR service, the WTRU may (e.g., may need to) deliver two interdependent PDUs within the synchronization window. When transmitting / receiving (e.g., upon transmission / reception of) the first PDU, the WTRU may (e.g., may need to) transmit / receive the second inter-dependent PDU within the synchronization window.

[0093] For the remaining synchronization window and / or the remaining time to serve (e.g., to transmit / receive) the PDU, the remaining synchronization window and / or remaining time to serve may be used to describe the remaining time to serve the second PDU when transmitting / receiving (e.g., upon transmission / reception of) the first inter-dependent PDU (e.g., due to synchronization requirement between the PDU and another inter-dependent PDU). For example, the WTRU may transmit / receive the first PDU. The WTRU may (e.g., may need to) transmit / receive another inter-dependent PDU. The WTRU may (e.g., may then) initialize a timer (e.g., sync-timer) to track the synchronization between the two PDUs. Thecurrent value of timer (e. g. , sync-timer) may be used to indicate the remaining synchronization window and / or the remaining time to transmit / receive the PDU.

[0094] For the one or more parameters of a PDU set (e.g., QoS / QoE parameters) associated with the data set, the parameters of the PDU set may include one or more of the following: PDU set importance; PDU set priority; the synchronization window; the remaining synchronization window and / or the remaining time to serve (e.g., to transmit / receive) the PDU set; the latency requirement associated with the PDU set; the PDU set integrated handling indication (PSI HI); the type of the PDU set; the reliability requirement of a PDU set (e.g., such as PDU set error rate (PSER)); the volume o the PDU set; the type of PDU set (e.g., periodic or aperiodic); or the periodicity of the PDU set.

[0095] For the PDU set importance (e.g., PSI), the PSI may be used to indicate the relative importance of a PDU set compared to other PDU sets within a QoS Flow.

[0096] For the synchronization window, the synchronization may be used to describe the synchronization requirement between two or more inter-dependent PDU sets or the synchronization requirement between one PDU set and one or more other PDUs. For example, to satisfy the QoE requirement of an XR service, the WTRU may (e.g., may need to) deliver two interdependent PDU sets within the synchronization window. When transmitting / receiving (e.g., upon transmission / reception of) the first PDU set, the WTRU may (e.g., may need to) transmit / receive the second inter-dependent PDU set within the synchronization window.

[0097] For the remaining synchronization window and / or the remaining time to serve (e.g., to transmit / receive) the PDU set, the remaining synchronization window and / or the remaining time to serve may be used to describe the remaining time to serve the second PDU set when transmitting / receiving (e.g., upon transmission / reception of) the first inter-dependent PDU set (e.g., due to synchronization requirement between the PDU set and another inter-dependent PDU set). For example, the WTRU may transmit / receive the first PDU set. The WTRU may (e.g., may need to) transmit / receive another inter-dependent PDU set. The WTRU may (e.g., may then) initialize a timer (e.g., syncTimer) to track the synchronization between the two PDU sets. The current value of timer (e.g., syncTimer) may be used to indicate the remaining synchronization window and / or the remaining time to transmit / receive the second PDU set.

[0098] For the latency requirement associated with the PDU set, the latency requirement may include one or more of: a PSDB (e.g., which may be used to indicate the maximum time between reception of the first PDU (e.g., at the user plane function (UPF) in DL, at the WTRU in UL) and the successful delivery ofthe last arrived PDU of a PDU set (e. g . , at the WTRU in DL, at the UPF in UL) (e.g., PSDB may be an optional parameter and if provided, the PSDB supersedes the PDB)); the remaining PSDB; the nominal PSDB associated with the PDU set; or the PSDD (e.g., which may be the 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).

[0099] For the PSIHI, the PSIHI may indicate whether PDUs (e.g., all PDUs) of the PDU set may be needed for the usage of PDU set by an application layer.

[0100] For the type of the PDU set, the type of the PDU set may include one or more of the following: the first type of PDU set, which may require reliable delivery of all PDUs in the set; the secondary type of PDU set, in which the transmission of a PDU set may be unsuccessful if at least one (e.g., possibly specific) PDU fails transmission; or the third type of PDU set, in which the transmission of a PDU set may be successful when X PDUs of the PDU set of Y PDUs are received (e.g., if forward error correction (FEC) is used or if additional layered encoding is used and assigned to the same PDU set).

[0101] For the reliability requirement of a PDU set (e.g., such as PDU set error rate (PSER)), the reliability requirement may be used to indicate one or more of the following: an upper bound for the rate of PDU sets that may have been processed by the sender of a link layer protocol (e.g., RLC in RAN of a 3GPP access) but may not be successfully delivered by the corresponding receiver to the upper layer (e.g., PDCP in RAN of a 3GPP access); an upper bound for the rate of PDUs per PDU set that may have been processed by the sender of a link layer protocol (e.g., RLC in RAN of a 3GPP access) but may not be successfully delivered by the corresponding receiver to the upper layer (e.g., PDCP in RAN of a 3GPP access); or an upper bound for the rate of PDUs per PDU set may be not successfully received by the receiver of the upper layer (e.g., PDCP in RAN of a 3GPP access).

[0102] For the volume of the PDU set, the volume of the PDU set may include one or more of the following: the size of each PDU; or the number of PDUs in the PDU set.

[0103] For the one or more parameters of a data burst associated with the data set, the one or more parameters may include the volume of the data burst, which may include one or more of the following: the size of each PDU in the data burst; the number of PDU sets in the data burst; or the volume of each PDU set in the data burst.

[0104] For the one or more redundancy parameters (e.g, AL-FEC ratio) associated with the data set, the one or more redundancy parameters may be used to indicate the number of required PDUs to decodethe PDU set. In examples, a data set may be a PDU set, in which the receiver may need to successfully receive at least K out of N PDUs in the PDU set to successfully decode the PDU set (e.g., successfully decode a video frame at Application layer). K or the ratio between K and N (i.e. , K / N) may be used as one of the QoS / QoE parameters for the PDU set to represent the redundancy parameter for the PDU set. In examples, a data set may be a PDU set, which may include multiple subsets of the PDU set. The WTRU may be required to successfully transmit a ratio or a certain number of PDUs of subsets (e.g., each subset) of the PDU set to satisfy a certain QoS / QoE requirement. The ratio of PDUs (e.g., each PDU) may be used as one or more QoS / QoE parameters for the PDU set to represent the redundancy parameters for the PDU set.

[0105] QoS / QoE of a PDU / PDU-segment may be used to describe the QoS / QoE of the PDU / PDU- segment itself and the QoS / QoE associated with the PDU set of the PDU / PDU-segment. The QoS / QoE of a PDU / PDU-segment may include one or more of PDU importance, priority, latency requirement of the PDU / PDU-segment, MDBV, type of PDU / PDU-segment, the periodicity of the PDU / PDU-segment, the size of the PDU / PDU-segment, PDU set importance, PDU set priority, a latency requirement associated with the PDU set (e.g., PSDB, remaining PSDB, PSDD, PSIHI), a reliability requirement of the PDU set (e.g., PSER), the volume of the PDU set, the volume of the data burst associated with the PDU / PDU-segment, or one or more redundancy parameters (e.g., AL-FEC ratio) of the data set associated with the PDU / PDU- segment.

[0106] The parameters associated with a DRB / LCH / PDU-set may include one or more of the following: the delay-critical handling being enabled / disabled, the RLC mode (e.g., acknowledgement mode (AM), unacknowledgement mode (UM), TM), the priority, the PBR (e.g., PBR values may be applied on respective DRB, LCH, or PDU set basis), the bucket size duration (BSD), the set of allowed serving cells from the cell group, the set of allowed carriers, the set of allowed subcarrier spacings (SCSs), the maximum / minimum physical uplink shared channel (PUSCH) duration, the minimum / maximum grant size, the maximum / minimum modulation and coding scheme (MCS), the minimum number of repetitions associated with the grant, the allowed configured grant (CG) types (e.g., type 1 CG, type 2 CG), the list of allowed CGs, the list of allowed PHY priorities, or a channel access priority class (CAPC). For the delay-critical handing being enabled / disabled, if the DRB / LCH / PDU-set is configured with delay-critical handling disabled, the DRB / LCH / PDU-set may not include delay-critical data or LCP enhancement may not be considered for this DRB / LCH / PDU-set. Otherwise, if the DRB / LCH / PDU-set is configured with delay-criticalhandling enabled, the DRB / LCH / PDU-set may include delay-critical data and / or LCP enhancement may be considered for this DRB / LCH / PDU-set.

[0107] In examples, a WTRU may be configured (e.g., receiving configuration information) with one or more conditions to determine the secondary type of data. The WTRU may (e.g., may then) determine whether a data set belongs to the secondary type of data. If the configured condition is satisfied, the data set may belong to the secondary type of data. Otherwise, the data set may belong to the other type of data. The WTRU may be configured with one or more of the following secondary type of data: the delay-critical data; the importance data; or the high priority data. If determining the secondary type of data, the WTRU may (e.g., may then) perform LCP enhancement for the secondary type of data. The secondary type of data may be used interchangeably with any of the above types of data.

[0108] In examples, a WTRU may first determine whether a data set is a secondary type of data (e.g., delay-critical data). Such a decision may be made based on one or more of the following (e.g., the condition(s) described herein): one or more parameters associated with the DRB / LCH / PDU-set (e.g., delay- critical handling being enabled / disabled, the priority of the data set (e.g., secondary data), the PBR, the BSD, the CAPC) of the data set; one or more QoS / QoE parameters associated with the data set; the arrival time associated with the data set with respect to the expected arrival time; the age of the data set; the value of a timer associated with the data set; or the buffer status of the WTRU.

[0109] For the one or more parameters associated with the DRB / LCH / PDU-set (e.g., delay-critical handling being enabled / disabled, the priority, the PBR, the BSD, the CAPC) of the data set, the WTRU may be configured with two types of DRBs / LCHs / PDU-sets, in which the first set of DRBs / LCHs / PDU-sets may be associated with delay-critical data and the second set of DRBs / LCHs may be associated with non-delay- critical data. The WTRU may (e.g., may then) determine whether the data set is delay-critical data or not based on whether the data set is associated with the first or the second set of DRBs / LCHs / PDU-sets. The WTRU may determine that the data set is delay-critical data if the data set is associated with the first set of DRBs / LCHs / PDU-sets. Otherwise, if the data set is associated with the second set of DRBs / LCHs / PDU- sets, the WTRU may determine that the data set is non-delay-critical data.

[0110] For the one or more parameters associated with the DRB / LCH / PDU-set (e.g., delay-critical handling being enabled / disabled, the priority, the PBR, the BSD, the CAPC) of the data set, the WTRU may determine the data set as a secondary type of data (e.g., delay critical data) if the priority associated with the DRB / LCH / PDU-set is greater than a configured threshold. Otherwise, the WTRU may determine that the data set is non-delay-critical data.

[0111] For the one or more QoS / QoE parameters associated with the data set, the WTRU may determine a PDU as a secondary type of data (e.g., delay-critical data) based on the remaining PSDB associated with the PDU of the PDU set. If the remaining PSDB of the PDU in the PDU set is smaller than a configured threshold, the WTRU may determine that the PDU is delay-critical. Otherwise, the WTRU may determine that the PDU is non-delay-critical data. The WTRU may determine whether the PDU set is delay- critical or not based on a remaining PSDB associated with the PDU set. If the remaining PSDB is smaller than a configured threshold, the WTRU may determine the PDU set as delay-critical. Otherwise, the WTRU may determine the PDU set as non-delay-critical data.

[0112] For the one or more QoS / QoE parameters associated with the data set, the WTRU may determine the data set (e.g., PDU, PDU set) as a secondary type of data (e.g., delay-critical data) if the importance of the data set is greater than a configured threshold. Otherwise, if the importance of the data set is smaller than a configured threshold, the WTRU may determine the data set as non-delay-critical data.

[0113] For the one or more QoS / QoE parameters associated with the data set, the WTRU may determine a data set as delay-critical data if the remaining synchronization window and / or the synchronization window associated with the data set is smaller than a configured threshold. Otherwise, if the remaining synchronization window and / or the synchronization window associated with the data set is larger than the configured threshold, the WTRU may determine the data set as non-delay-critical data.

[0114] For the one or more QoS / QoE parameters associated with the data set, the WTRU may determine a data set as delay-critical if the volume of the data is larger than a configured threshold. Otherwise, the WTRU may determine that the data set as non-delay-critical data.

[0115] For the arrival time associated with the data set with respect to the expected arrival time, the WTRU may consider the data set as delay-critical data if the gap between its late arrival time and the expected arrival time is greater than a configured threshold. Otherwise, if the data set arrives before the expected arrival time or the gap between its late arrival time and the expected arrival time is smaller than the configured threshold, the WTRU may consider the data set as non-delay-critical data.

[0116] For the arrival time associated with the data set with respect to the expected arrival time, the WTRU may be configured to associate a DRB / LCH / PDU-set with a configured grant. The WTRU may (e.g., may then) consider the data set as delay-critical data if the gap between its arrival time and the configured grant (e.g., the last PUSCH resource in the period) in a period is smaller than a threshold or it arrives after the configured grant resource in a CG period.

[0117] For the age of the data set, the age of the data set may be determined based on the time the data set stays in the buffer. For example, the WTRU may consider the data set as a secondary type of data (e.g., delay-critical data) if the age of the data set (e.g., the time the data set stays in the buffer) is larger than a configured threshold. Otherwise, the WTRU may consider the data set as non-delay-critical.

[0118] For the value of a timer associated with the data set, the value of the timer may be used to determine the remaining time to serve the data set before discarding the data set. In examples, the WTRU may be configured with a timer (e.g., delay-critical-timer) to help determine whether a data set is delay critical or not. When the data set arrives (e.g., upon arrival of the data set), the WTRU may start the timer. The initial value of the timer may be configured or may be determined based on the QoS / QoE associated with the data set (e.g., nominal PSDB, PSDB, remaining PSDB, PSDD). The WTRU may (e.g., may then) determine the data set as delay-critical data if the current value of the timer is smaller than a configured threshold.

[0119] For the buffer status of the WTRU, the buffer status may include at least one of the buffer status associated with the DRB / LCH / PDU-set of the data set, the buffer status associated with the configured set of DRB / LCH / PDU-set, or the buffer status of all the DRBs / LCHs / PDU-sets. In examples, the buffer status of a DRB / LCH / PDU-set may be based on the amount of data in the DRB / LCH / PDU-set. In examples, the buffer status of a DRB / LCH / PDU-set may be based on the amount of data arriving before the considered data set. In examples, the WTRU may consider the data set as delay-critical if the number of PDUs in the DRB / LCH / PDU-set associated with the data set is larger than a configured threshold. Otherwise, the WTRU may consider the data set as non-delay-critical. In examples, the WTRU may consider the data set as delay-critical if the number of PDUs in the in the DRB / LCH / PDU-set ahead of one or more PDUs of the data set is larger than a configured threshold. Otherwise, the WTRU may consider the data set as non- delay-critical. This approach may be motivated to consider the amount of data to be served before the current data set to be served in a DRB / LCH / PDU-set. In examples, the WTRU may consider the data set as delay-critical if the number of PDUs in the DRB / LCH / PDU-set associated with the data set is larger than a configured threshold. Otherwise, the WTRU may consider the data set as non-delay-critical.

[0120] In examples, the WTRU may determine whether a data set (e.g., a PDU, a PDU set) is delay- critical or not based on whether the associated DRB / LCH / PDU-set is configured with delay-critical handling enabled / disabled and based on the remaining PSDB of the data set. If the DRB / LCH / PDU-set is configured with delay-critical handling enabled / disabled and the remaining PSDB of the data set is smaller than a configured threshold, the WTRU may consider the data set as delay-critical data. Otherwise, if theDRB / LCH / PDU-set is configured with delay-critical handling disabled or the remaining PSDB of the data set is larger than the configured threshold, the WTRU may consider the data set as non-delay-critical data.

[0121] In examples, the WTRU may determine whether a data set (e.g., a PDU, a PDU set) is delay- critical or not based on whether the associated DRB / LCH / PDU-set is configured with delay-critical handling enabled / disabled and based on the value of an associated timer to track the delay-criticality of the data set. For a data set in a DRB / LCH / PDU-set configured with delay-critical handling enabled, the WTRU may start a timer (e.g., delay-critical-timer) when the data set arrives (e.g., upon arrival of the data set). In examples, the WTRU may start a timer for the whole data set, in which the WTRU may perform integrated handling of the whole data set (e.g., the PDU set). The WTRU may start the timer when the first PDU of the data set arrives (e.g., upon arrival of the first PDU of the data set). The WTRU may start the timer at a configured time (e.g., the expected arrival time of the data set). The WTRU may consider the data set as delay-critical data if the value of the timer is smaller than a configured threshold. The timer threshold may be configured per DRB / LCH. In examples, the WTRU may start a timer for PDUs (e.g., each PDU) of the data set. The WTRU may (e.g., may then) consider the PDU as delay-critical data if the value of the timer is smaller than a configured threshold. The timer threshold may be configured per LCH / DRB. The initial value of a timer (e.g., delay-critical-timer) may be determined based on one or more of the following: configuration by the network; arrival time of the data set (e.g., the arrival time of the first PDU of the data set, the last PDU of the data set, and / or each PDU of the data set); or one or more QoS / QoE parameters associated with the data set (e.g., PSDB, PSDD, nominal PSDB).

[0122] For configuration by the network, the WTRU may be configured with the initial value of a timer (e.g., delay-critical-timer) for each DRB / LCH / PDU-set with delay-critical handling enabled. The WTRU may (e.g., may then) start the timer with the initial value of the timer configured for the DRB / LCH / PDU-set associated with the data set.

[0123] For the arrival time of the data set (e.g., the arrival time of the first PDU of the data set, the last PDU of the data set, and / or each PDU of the data set), for a PDU of a PDU set, the WTRU may start a timer when the PDU arrives (e.g., upon the arrival of the PDU). The WTRU may determine the initial value of timer based on the gap between the arrival time of the PDU and the expected arrival time of the PDU. The WTRU may increase the initial value of the timer if the PDU arrives before the expected arrival time. The WTRU may decrease the initial value of the timer if the PDU arrives after the expected arrival time.

[0124] For the one or more QoS / QoE parameters associated with the data set (e.g., PSDB, PSDD, nominal PSDB), for a PDU set, the WTRU may start a timer for a PDU of the PDU set or the WTRU maystart a timer for the entire PDU set. The initial value of the timer may be associated with the PSDB of the PDU set.

[0125] For the one or more QoS / QoE parameters associated with the data set (e.g., PSDB, PSDD, nominal PSDB), for a PDU set, the WTRU may start a timer for a PDU of the PDU set or the WTRU may start a timer for the entire PDU set. The initial value of the timer may be determined based on the PSDD of the PDU set. The WTRU may determine the remaining time to the delivery deadline of the PDU set. The WTRU may (e.g., may then) determine the initial value of the timer based on the remaining time to the delivery deadline of the PDU set.

[0126] In examples, the WTRU may have two inter-dependent PDU sets (e.g., for multi-modality XR application), which may require synchronization transmission / reception. The two PDU sets may be required to be transmitted / received within a synchronization window. The WTRU may (e.g., may then) determine whether a PDU set (e.g., the second PDU set) is a delay-critical data or not based on whether the associated DRB / LCH / PDU-set is configured with delay-critical handling enabled / disabled and based on the value of an associated timer to track the synchronization requirement between itself and the other associated PDU set (e.g., the first PDU set). If the PDU set (e.g., the second PDU set) is associated with a delay-critical handling disabled DRB / LCH, the WTRU may consider the PDU set as non-delay-critical data. If the PDU set is associated with delay-critical handling enabled DRB / LCH, the WTRU may consider the PDU set as delay-critical data if the value of a timer (e.g., sync-timer) is smaller than a configured threshold, which may be configured per DRB / LCH. The WTRU may start the timer (e.g., sync-timer) based on one or more of the following: the arrival of the PDU set itself (e.g., the second PDU set); the arrival of the inter-dependent PDU set (e.g., the first PDU set); or successful transmission / reception of the interdependent PDU set (e.g., the first data set).

[0127] The initial value of the timer (e.g., sync-timer) may be determined based on one or more of the following: configuration by the network; arrival time of the first and / or second inter-dependent PDU set; one or more QoS / QoE parameters (e.g., synchronization window, remaining synchronization window) associated with the data set (e.g., the data set including two inter-dependent PDU sets); or successful transmission / reception time (e.g., the slot) of the inter-dependent PDU set (e.g., the first PDU set).

[0128] For the configuration by the network, the WTRU may be configured with the initial value of a timer (e.g., sync-timer) for each DRB / LCH / PDU-set supporting coordinated transmission / reception among interdependent PDU sets. The WTRU may (e.g., may then) start the timer with the initial value of the timer configured for the DRB / LCH / PDU-set associated with the PDU set.

[0129] For the arrival time of the first and / or second inter-dependent PDU set, the second PDU set may arrive after the successful transmission / reception of the first PDU set. The WTRU may start the sync-timer when the second inter-dependent PDU set arrives (e.g., upon the arrival of the second inter-dependent PDU set). The WTRU may (e.g., may then) determine the initial value of the sync-timer based on the gap between the arrival time of the second inter-dependent PDU set and the successful transmission and / or reception of the first PDU set.

[0130] For the one or more QoS / QoE parameters (e.g., synchronization window, remaining synchronization window) associated with the data set (e.g., the data set including two inter-dependent PDU sets), the initial value of the sync-timer may be based on the synchronization window requirement between two inter-dependent PDUs. The WTRU may start the timer upon successful transmission / reception of the first PDU set.

[0131] For successful transmission / reception time (e.g., the slot) of the inter-dependent PDU set (e.g., the first PDU set), the second inter-dependent PDU set may arrive after the successful transmission / reception of the first PDU set. The WTRU may (e.g., may then) start a sync-timer when the second PDU set arrives (e.g., upon the arrival of the second PDU set) to determine the delay-criticality of the second PDU set. The service may require the first and second PDU set to be transmitted / received within a synchronization window. The WTRU may (e.g., may then) consider the gap between the successful transmission / reception time of the first PDU set to determine the initial value of the sync-timer. The WTRU may subtract the gap between the time the WTRU starts the sync-timer and the successful transmission / reception time of the first PDU in the initial value of the sync-timer. As such, the WTRU may have less time to transmit the second PDU set if the WTRU successfully transmits / receives the first PDU set sooner.

[0132] In examples, the WTRU may determine whether a data set (e.g., a PDU, a PDU set) is delay- critical or not based on whether the associated DRB / LCH / PDU-set is configured with delay-critical handling enabled / disabled, the importance of the data set, and the value of an associated timer (e.g., delay-critical- timer, sync-timer). The WTRU may consider a data set as delay-critical data if the data set is associated with a delay-critical handling enabled DRB / LCH, the importance of the data set is greater than a configured threshold, and the value of one timer (e.g., delay-critical-timer, sync-timer) associated with the data set is smaller than a configured threshold. Otherwise, the WTRU may consider the data set as non delay-critical data.

[0133] In examples, the WTRU may determine whether each individual PDU is delay-critical or not. In examples, the WTRU may determine whether the entire PDU set is delay-critical or not. If any PDU of the PDU set is delay-critical, the WTRU may decide that the entire PDU set is delay-critical data. The WTRU may determine whether to evaluate the delay-criticality for the entire PDU set or each individual PDU in a PDU set based on one or more of the following: one or more parameters associated with the DRB / LCH; or one or more QoS / QoE parameters associated with the data set.

[0134] For one or more parameters associated with the DRB / LCH, the WTRU may be configured per DRB / LCH / PDU-set whether to evaluate the delay-criticality of the whole PDU set or individual PDU. The WTRU may (e.g., may then) evaluate the delay-criticality for the whole PDU set if the DRB / LCH / PDU-set is configured with PDU-set delay-criticality evaluation.

[0135] For the one or more QoS / QoE parameters associated with the data set, the WTRU may evaluate the delay-criticality for the entire PDU setif PSIHI is enabled for the PDU set. Otherwise, if PSIHI is disabled, the WTRU may evaluate the delay-criticality of each individual PDU in the PDU set.

[0136] For the one or more QoS / QoE parameters associated with the data set, the WTRU may evaluate the delay-criticality for the entire PDU set if the AL-FEC ratio associated with the PDU set is larger than a configured threshold. Otherwise, if the AL-FEC ratio associated with the PDU set is smaller than a configured threshold, the WTRU may evaluate the delay-criticality of each individual PDU in the PDU set.

[0137] Examples of a WTRU performing LCP enhancements for a secondary type of data (e.g., delay- critical) are provided herein. In examples, the WTRU may receive a grant from the network (e.g., dynamic grant or configured grant). The WTRU may perform an LCP procedure to multiplexing data from one or more DRBs / LCHs / PDU-sets to a MAC PDU. In examples, the WTRU may perform an existing LCP procedure without considering the secondary type of data (e.g., delay-critical data) in the buffer. In examples, the WTRU may perform an LCP enhancement procedure. The WTRU may determine one or more of the following in the LCP procedure of a MAC PDU: whether to consider starvation parameter (e.g., Bj) in selecting the DRB / LCH / PDU-set j to fulfill a PBR parameter; which DRBs / LCHs / PDU-sets to select / restrict to multiplex for the MAC PDU; which DRB / LCH / PDU-set to prioritize (e.g., the selection order of DRBs / LCHs / PDU-sets to multiplex in the MAC PDU); or if one DRB / LCH / PDU-set is selected to multiplex in the MAC PDU.

[0138] For whether to consider a starvation parameter (e.g., Bj) in selecting the DRB / LCH / PDU-set j to fulfill a PBR parameter, the WTRU may first consider (e.g., only consider) starvation parameter (e.g., Bj) forDRBs / LCHs / PDU-sets without secondary type of data (e.g., delay-critical) in the LCP procedure. For a DRB / LCH / PDU-setwith non-positive Bj, the WTRU may (e.g., may only) select the DRB / LCH / PDU-setto fulfill a PBR parameter if it has secondary type of data (e.g., delay-critical). Otherwise, the WTRU may not select the DRB / LCH / PDU-setto fulfill the PBR parameter.

[0139] For which DRBs / LCHs / PDU-sets to select / restrict to multiplex for the MAC PDU, the WTRU may select DRB / LCH / PDU-set with secondary type of data (e.g., delay-critical) to (e.g., only to) multiplex in a MAC PDU. This approach may be motivated to help the network in prioritizing the secondary type of data (e.g., delay-critical).

[0140] For which DRB / LCH / PDU-setto prioritize (e.g., the selection order of DRBs / LCHs / PDU-sets to multiplex in the MAC PDU), the WTRU may determine which DRB / LCH / PDU-set to prioritize in the LCP procedure of a MAC PDU. In examples, the WTRU may prioritize DRBs / LCHs / PDU-sets according to the priority associated with each DRB / LCH / PDU-set.

[0141] For which DRB / LCH / PDU-setto prioritize (e.g., the selection order of DRBs / LCHs / PDU-sets to multiplex in the MAC PDU), the WTRU may prioritize the DRB / LCH / PDU-set according to the availability and / or the amount of the secondary type of data (e.g., delay-critical) in the buffer. The WTRU may first prioritize the DRBs / LCHs / PDU-sets with secondary type of data (e.g., delay-critical). Among the DRBs / LCHs / PDU-sets with secondary type of data (e.g., delay-critical), the WTRU may prioritize the DRB / LCH / PDU-set in the descending order of the amount of the secondary type of data (e.g., delay- critical). Among the DRBs / LCHs / PDU-sets with secondary type of data (e.g., delay-critical), the WTRU may prioritize the DRB / LCH / PDU-set in the descending order of the priority of each DRB / LCH / PDU-set. The WTRU may (e.g., may then) prioritize DRB / LCH / PDU-setwith other type of data (e.g., non-delay-critical).

[0142] For which DRB / LCH / PDU-setto prioritize (e.g., the selection order of DRBs / LCHs / PDU-sets to multiplex in the MAC PDU), the WTRU may prioritize the DRBs / LCHs / PDU-sets according to the delay requirement (e.g., remaining PSDB, PSDD) of the data associated with the DRB / LCH / PDU-set. For example, the WTRU may prioritize the DRBs / LCHs / PDU-sets according to the lowest remaining PSDB of a PDU set in each DRB / LCH / PDU-set.

[0143] For which DRB / LCH / PDU-setto prioritize (e.g., the selection order of DRBs / LCHs / PDU-sets to multiplex in the MAC PDU), the WTRU may prioritize the DRBs / LCHs / PDU-sets according to the importance of the PDU sets (e.g., PSI) associated with each DRB / LCH / PDU-set.

[0144] For if one DRB / LCH / PDU-set is selected to multiplex in the MAC PDU, the WTRU may determine one or more of the following: which data to multiplex in the MAC PDU; which PDU / PDU-segment to prioritize to multiplex in the MAC PDU (e.g., the order of the PDU / PDU-segment to multiplex in the MAC PDU); or the amount of data (e.g., number of PDUs / PDU-segments).

[0145] For which data to multiplex in the MAC PDU, in the LCP procedure, the WTRU may (e.g., may first) multiplex secondary type of data (e.g., only secondary type of data) (e.g., delay-critical data) of the DRB / LCH / PDU-set in the MAC PDU. Selecting the secondary type of data (e.g., only the secondary type of data (e.g., delay-critical data)) of a DRB / LCH / PDU-set to multiplex in the MAC PDU may result in an out-of- order transmission as the WTRU may skip other type of data in the MAC PDU for transmission. The WTRU may (e.g., may then) indicate such out-of-order transmission (e.g., in the MAC header of the MAC PDU) to the receiver.

[0146] For which data to multiplex in the MAC PDU, the WTRU may (e.g., may second) multiplex both the secondary type of data (e.g., delay-critical data) and other data of the DRBs / LCHs / PDU-sets in the MAC PDU.

[0147] For which PDU / PDU-segment to prioritize to multiplex in the MAC PDU (e.g., the order of the PDU / PDU-segment to multiplex in the MAC PDU), the WTRU may select the PDU / PDU-segment in sequence. In examples, the WTRU may select both the secondary type of data (e.g., delay-critical data) and other type of data to multiplex in the MAC PDU, in which the WTRU may (e.g., may first) prioritize in sequence the secondary type of data (e.g., delay-critical data) and the WTRU may (e.g., may then) prioritize in sequence other data.

[0148] For which PDU / PDU-segment to prioritize to multiplex in the MAC PDU (e.g., the order of the PDU / PDU-segment to multiplex in the MAC PDU), the WTRU may select the data in each DRB / LCH / PDU- set according to the delay requirement (e.g., remaining PSDB, PSDD) of the data associated with the DRB / LCH / PDU-set. For example, the WTRU may prioritize selecting the PDU / PDU-segment with a lower remaining PSDB.

[0149] For which PDU / PDU-segment to prioritize to multiplex in the MAC PDU (e.g., the order of the PDU / PDU-segment to multiplex in the MAC PDU), the WTRU may prioritize the data according to the importance of the associated PDU sets (e.g., PSI) associated with each DRB / LCH / PDU-set. The WTRU may sequentially select the PDU / PDU-setfrom a high importance PDU set first.

[0150] For the amount of data (e.g., number of PDUs / PDU-segments), the amount of data may include at least one of the amount of all data, the amount of the secondary type of data (e.g., delay-critical data), or the amount of other data to multiplex in the MAC PDU. In examples, in the LCP procedure, the WTRU may (e.g., may first) determine the amount of secondary type of data (e.g., delay-critical data) and / or the amount of total data to multiplex in the MAC PDU from the DRB / LCH / PDU-set. For example, the WTRU may select the secondary type of data (e.g., delay-critical data) until the amount of the secondary type of data (e.g., delay-critical data) reaches a configured value. For example, the WTRU may select in sequence data until the amount of secondary type of data (e.g., delay-critical data) reaches a configured value of a parameter. For example, the WTRU may select in sequence data until the amount of selected data reach a configured value of a parameter. In examples, the WTRU may (e.g., may second or may then) determine to multiplex data in the DRB / LCH / PDU-set until all data are selected or all secondary type of data (e.g., delay-critical data) are selected, or the resource is filled.

[0151] Decisions for the LCP procedure, which may include the decisions for the entire LCP procedure and the decisions for each action of the LCP procedure, may be determined based on one or more of the following: the availability / amountof secondary type of data (e.g., delay-critical) in each DRB / LCH / PDU-set; a configured first PBR value and optional second PBR value for the WTRU; one or more QoS / QoE parameters associated with the data in the DRB / LCH / PDU-set; or an indication / configuration from the network.

[0152] For the availability / amountof secondary type of data (e.g., delay-critical) in each DRB / LCH / PDU- set, the WTRU may determine whether to perform an additional action or to modify an action in the LCP procedure based on the availability / amount of secondary type of data (e.g., delay-critical) in one or more DRBs / LCHs / PDU-sets. For example, if there is at least one DRB / LCH / PDU-set having secondary type of data (e.g., delay-critical), the WTRU may perform an LCP enhancement procedure. Otherwise, the WTRU may perform a different LCP procedure.

[0153] For the availability / amountof secondary type of data (e.g., delay-critical) in each DRB / LCH / PDU- set, the WTRU may prioritize a DRB / LCH / PDU-set having the highest amount of secondary type of data (e.g., delay-critical) in the LCP procedure.

[0154] For the availability / amountof secondary type of data (e.g., delay-critical) in each DRB / LCH / PDU- set, the WTRU may select a DRB / LCH-PDU-set regardless of the value of its starvation parameter (e.g., Bj) in the LCP procedure if it has secondary type of data (e.g., delay-critical).

[0155] For the configured first PBR value and optional second PBR value for the WTRU, the configured first PBR value and optional second PBR value for the WTRU may be used to enable transmission of the secondary type of data (e.g., delay-critical) while still preserving the priority and avoid starvation of other data. Each second PBR value may be configured for the WTRU per DRB / LCH / PDU-set and applied for the configured DRB / LCH / PDU-set in the LCP procedure of a MAC PDU, configured per set of DRBs / LCHs / PDU-sets and applied for the set of DRBs / LCHs / PDU-sets or for each DRB / LCH / PDU-set in the set of DRBs / LCHs / PDU-sets, and / or configured per MAC PDU and applied for each MAC PDU.

[0156] For one or more QoS / QoE parameters associated with the data in the DRB / LCH / PDU-set, the WTRU may determine the order of DRB / LCH / PDU-set to prioritize based on one or more of the QoS / QoE parameters (e.g., PSDB, remaining PSDB, PSI) of the data associated with the DRB / LCH / PDU-set.

[0157] For an i n d ication / confi g uration from the network, the indication / configuration from the network may be conveyed to the WTRU via a DCI, a MAC CE, and / or an RRC. In examples, the WTRU may receive an indication / configuration from the network whether to prioritize secondary type of data (e.g., delay-critical). For example, the WTRU may receive a DCI from the network which may have one bit indication to indicate whether the WTRU should prioritize the secondary type of data (e.g., delay-critical) or not. If the codepoint is “1 ”, the WTRU may prioritize the secondary type of data (e.g., delay-critical). Otherwise, if the codepoint is “0”, the WTRU may not prioritize the secondary type of data (e.g., delay- critical). The DCI may (e.g., may also) schedule the transmission resource, in which the WTRU may perform the secondary type of data (e.g., delay-critical) prioritization to multiplex data to transmit in the scheduled grant. For example, the WTRU may receive a configured grant from the network (e.g., type-1 configured grant and type-2 configured grant). The WTRU may (e.g., may then) be indicated (e.g., in an RRC of type-1 configured grant, in a DCI or an RRC of type-2 configured grant) by the network whether the configured grant can be used to prioritize secondary type of data (e.g., delay-critical). If the configured grant can be used to prioritize secondary type of data (e.g., delay-critical), the WTRU may prioritize secondary type of data (e.g., delay-critical). The WTRU may prioritize the secondary type of data (e.g., delay-critical) during the LCP procedure. For example, the WTRU may multiplex in the MAC PDU data from the DRBs / LCHs / PDU-sets associated with (e.g., only associated with) the secondary type of data (e.g., delay- critical). The WTRU may not multiplex data from DRBs / LCHs / PDU-sets not associated with the secondary type of data (e.g., delay-critical). For example, the WTRU may (e.g., may first) prioritize to multiplex data from the DRBs / LCHs / PDU-sets associated with the secondary type of data (e.g., delay-critical). The WTRU may (e.g., may then) multiplex data from DRBs / LCHs / PDU-set associated with other data.

[0158] In examples, the WTRU may be configured with multiple LCP procedures (e.g., an LCP procedure without prioritizing the secondary type of data (e.g., delay-critical) and an LCP enhancement procedure prioritizing secondary type of data (e.g., delay-critical)). The WTRU may (e.g., may then) determine which LCP procedure (e.g., default LCP procedure, LCP enhancement procedure) based on the indication from the network.

[0159] In examples, the WTRU may determine whether to perform out-of-order LCP procedure, in which the WTRU may selectively prioritize secondary type of data (e.g., delay-critical) over other data in a DRB / LCH / PDU-set, based on the indication / configuration from the network. The WTRU may perform an out-of-order LCP procedure if an out-of-order is indicated / configured from the network. Otherwise, the WTRU may perform in-order LCP procedure, in which the WTRU may select in sequence data from each DRB / LCH / PDU-set.

[0160] In examples, the WTRU may fulfill the first and second PBR values in one action. The WTRU may fill data in the MAC PDU as follows. The WTRU may sequentially select a DRB / LCH / PDU-set to fill the MAC PDU. For example, the WTRU may fill the DRB / LCH / PDU-set without the secondary type of data (e.g., delay-critical) until fulfilling the first PBR value. The WTRU may fill the DRB / LCH / PDU-set having the secondary type of data (e.g., delay-critical) until fulfilling the second PBR value. For example, for each DRB / LCH / PDU-set, the WTRU may first fulfill the first PBR value. If there is still the secondary type of data (e.g., delay-critical) remaining in the DRB / LCH / PDU-set, the WTRU may second fulfill the second PBR value.

[0161] In examples, the WTRU may fulfill the first and second PRB values in two actions. For example, the WTRU may fulfill the first PBR value first and then the WTRU may fulfill the second PBR value. For example, the WTRU may fulfill the second PBR value first and then the WTRU may fulfill the first PBR value. The WTRU may fulfill the first PBR value for all DRBs / LCHs / PDU-sets first. Afterward, for any DRB / LCH / PDU-set having secondary type of data (e.g., delay-critical) remaining, the WTRU may fulfill the second PBR value. The WTRU may first fulfill the second PBR value for the DRBs / LCHs / PDU-sets having secondary type of data (e.g., delay-critical). The WTRU may sequentially select DRBs / LCHs / PDU-sets having secondary type of data (e.g., delay-critical) and fill the data in the MAC PDU until fulfilling the second PBR value. The WTRU may then fulfill the first PBR value for all DRBs / LCHs / PDU-sets. The WTRU may sequentially select a DRB / LCH / PDU-set and fill the data in the MAC PDU until fulfilling the first PBR value.

[0162] In examples, for one action (e.g., the first action) of the LCP procedure, the WTRU may determine to prioritize a DRB / LCH / PDU-set having a secondary type of data (e.g., delay-critical data). The WTRU may perform the following procedure. First, the WTRU may (e.g., may only) select DRBs / LCHs / PDU-sets having the secondary type of data (e.g., delay-critical data) to multiplex in the MAC PDU. The order of the DRB / LCH / PDU-set to select in this action (e.g., first action) may be determined based on a configured order. For example, it may be selected based on the priority associated with the DRB / LCH / PDU-set and / or the amount of the secondary type of data (e.g., delay-critical data) in the DRB / LCH / PDU-set. The WTRU may determine how to select data (e.g., the order and the amount of data to be selected) in the DRB / LCH / PDU-set (e.g., after selecting one DRB / LCH / PDU-set to multiplex data in the MAC PDU).

[0163] In examples, the WTRU may select data in sequence. The amount of data may be selected based on one or more of the following conditions being satisfied: the amount of data in the DRB / LCH / PDU- set multiplexed in the MAC PDU reaching a configured value (e.g., a first PBR value or a second PBR value), the amount of the secondary type of data (e.g., delay-critical data) from the DRB / LCH / PDU-set multiplexed in the MAC PDU reaching a configured value (e.g., a second PBR value), all the secondary type of data (e.g., delay-critical data) of the DRB / LCH / PDU-set being selected, or all data of the DRB / LCH / PDU-set being selected. This approach may guarantee in-of-order delivery of the DRB / LCH / PDU-sets per MAC PDU (e.g., each DRB / LCH / PDU-set per MAC PDU). In examples, the WTRU may (e.g., may only) select the secondary type of data (e.g., delay-critical data) in sequence to multiplex in the MAC PDU until the amount of secondary type of data (e.g., delay-critical data) reaches a configured value (e.g., the second PBR value configured for the DRB / LCH / PDU-set) or until all the secondary type of data (e.g., delay-critical data) of the DRB / LCH / PDU-set is selected. This approach may introduce out-of- order delivery as the WTRU may selectively select the secondary type of data (e.g., delay-critical) in the DRB / LCH / PDU-set to multiplex in the MAC PDU.

[0164] In examples, for one action (e.g., the first action) of the LCP procedure, the WTRU may consider DRB / LCH / PDU-set (e.g., all DRB / LCH / PDU-sets) to multiplex in the MAC PDU. In this action, to consider the secondary type of data (e.g., delay-critical), the WTRU may selectively select more data for a DRB / LCH / PDU-set having the secondary type of data (e.g., delay-critical) data compared to the case of a DRB / LCH / PDU-set not having the secondary type of data (e.g., delay-critical). First, the WTRU may sequentially select a DRB / LCH / PDU-set to multiplex data in the MAC. The order of DRB / LCH / PDU-set to select in this action (e.g., the first action) may be determined based on a configured order. For example, theD RB / LCH / PD U-set may be selected based on at least one of the priority associated with the DRB / LCH / PDU-set, the availability, or the amount of delay-critical data in the DRB / LCH / PDU-set. The WTRU may determine how to select data (e.g., the order and the amount of data to be selected) in the DRB / LCH / PDU-set (e.g., after one DRB / LCH / PDU-set is selected to multiplex data in the MAC PDU).

[0165] In examples, the WTRU may determine the order and the amount of data to multiplex in the MAC PDU from the beginning of the action (e.g., the first action). If the DRB / LCH / PDU-set does not include the secondary type of data, the WTRU may select data to multiplex in the MAC PDU up to the first configured PBR (e.g., the first PBR value). Otherwise, if the DRB / LCH / PDU-set includes the secondary type of data (e.g., delay-critical), the WTRU may determine the order and amount of data to multiplex in the MAC PDU. The WTRU may select data in sequence (e.g., without prioritizing secondary type of data). In examples, the WTRU may select in sequence the secondary type of data (e.g., delay-critical) only. In examples, the WTRU may select in sequence the secondary type of data (e.g., delay-critical) first and then in sequence other data (e.g., non-delay-critical data) afterward. The amount of data to multiplex in the MAC PDU may be determined based on the amount of total data multiplexed in the MAC PDU, and / or the amount of secondary type of data (e.g., delay-critical) multiplexed in the MAC PDU. The WTRU may multiplex data from the DRB / LCH / PDU-set in the MAC PDU until one or more of the following conditions are satisfied: the amount of data from the DRB / LCH / PDU-set multiplexed in the MAC PDU reaches a configured PBR value (e.g., the second PBR value), the amount of secondary type of data (e.g., delay-critical) from the DRB / LCH / PDU-set multiplexed in the MAC PDU reaches a value (e.g., the second PBR value), all secondary type of data (e.g., delay-critical) in the DRB / LCH / PDU-set are selected, or all data in the DRB / LCH / PDU-set are selected.

[0166] In examples, the WTRU may determine the order and the amount of data to multiplex in the MAC PDU in two stages. In the first stage, the WTRU may first multiplex data from the DRB / LCH / PDU-set in the MAC PDU until at least one of the following occurs: a configured value of a parameter (e.g., the first PBR value) is reached, all data is selected, or all secondary type of data (e.g., delay-critical) is selected. In this stage (e.g., the first stage), the WTRU may select data in sequence (e.g., without prioritizing between the secondary type of data).

[0167] In examples, the WTRU may only select in sequence secondary type of data (e.g., delay-critical). In examples, the WTRU may select in sequence secondary type of data (e.g., delay-critical) first and then in sequence other data (e.g., non-delay-critical) afterward. The WTRU may (e.g., may then) determine whether to perform the second stage based on one or more of: the remaining data in the D RB / LCH / P DU-set, or the remaining secondary type of data (e.g., delay-critical) in the DRB / LCH / PDU-set The WTRU may determine to perform the second stage if the WTRU still has remaining data in the DRB / LCH / PDU-set and / or if the WTRU still has secondary type of data (e.g., delay-critical) in the DRB / LCH / PDU-set. In the second stage, the WTRU may multiplex data from the DRB / LCH / PDU-set in the MAC PDU until at least one of the following occurs: the amount of data from the DRB / LCH / PDU-set multiplexed in the MAC PDU reaches a configured value (e.g., the second PBR value), the amount of secondary type of data (e.g., delay-critical) from the DRB / LCH / PDU-set in the MAC PDU reaches a configured value (e.g., the second PBR value), the amount of additional secondary type of data (e.g., delay-critical) from the DRB / LCH / PDU- set in the MAC PDU reaches a configured value (e.g., the second PBR value), all data is selected, or all secondary type of data (e.g., delay-critical) is selected. In this stage (e.g., the second stage), the WTRU may select data in sequence (e.g., without prioritizing secondary type of data (e.g., delay-critical)). In examples, the WTRU may only select in sequence secondary type of data (e.g., delay-critical). In examples, the WTRU may select in sequence secondary type of data (e.g., delay-critical) first and then in sequence other data afterward.

[0168] In examples, after fulfilling the first and / or second PBR values, the WTRU may sequentially select a DRB / LCH / PDU-set according to an order to fill the MAC PDU until all the data in the DRB / LCH / PDU-set is selected or the grant is fulfilled. The order of DRB / LCH / PDU-set may be selected based on the priority associated with the DRB / LCH / PDU-set, the amount of secondary type of data (e.g., delay-critical) in the DRB / LCH / PDU-set, and / or the QoS (e.g., delay requirement such as remaining PSDB, PSDD, PSDB, the importance of the PDU set) of the data associated with the DRB / LCH / PDU-set.

[0169] In examples, the WTRU may be limited / restricted to perform LCP enhancement in a configured condition. If the configured condition is satisfied, the WTRU may be allowed to perform LCP enhancement for the secondary type of data (e.g., delay-critical). Otherwise, the WTRU may not be allowed to perform LCP enhancement. The WTRU may be configured with one or more of the following conditions to perform LCP enhancement: the amount of transmitted data associated with the LCP enhancement being smaller than a configured threshold; after transmitting uplink control information (UCI) / MAC CE (e.g., a scheduling request (SR) and / or a buffer status report (BSR)) to the network; the amount of data in a configured subset of DRBs / LCHs / data-sets being smaller than a configured threshold; or the QoS associated with a configured subset of DRBs / LCHs / data-sets (e.g., ultra-reliable and low latency communications (URLLC) data) satisfying a configured condition.

[0170] For the amount of transmitted data associated with the LCP enhancement being smaller than a configured threshold, the WTRU may count the LCP enhancement related data periodically. In the configuration periods (e.g., in each configured period), the WTRU may be allowed to perform LCP enhancement for a maximum configured amount of associated data. In examples, the WTRU may reset counting the amount of data associated with the LCP enhancement after transmitting buffer information to the network (e.g., via MAC CE such as BSR, DSR, or a new designed MAC CE).

[0171] For after transmitting UCI / MAC CE (e.g., SR, BSR) to the network, the WTRU may be allowed to perform LCP enhancement after the WTRU transmits buffer information (e.g., MAC CE such BSR, DSR) to the network for a configured duration. This approach may be motivated to help the network accelerate transmission of the secondary type of data (e.g., delay-critical). For after transmitting UCI / MAC CE (e.g., SR, BSR) to the network, the WTRU may be not allowed to perform LCP enhancement after the WTRU transmits UCI / MAC CE (e.g., SR / BSR) to the network for a configured duration. The WTRU may be allowed to perform LCP enhancement beyond the configured duration. This approach may be motivated to allow the gNB to perform proper scheduling without WTRU performing LCP enhancement if SR / BSR is transmitted.

[0172] For the amount of data in a configured subset of DRBs / LCHs / data-sets being smaller than a configured threshold, the WTRU may be configured with a set of high priority data (e.g., URLLC). The WTRU may be allowed to perform LCP enhancement for its secondary type of data (e.g., delay-critical) (e.g., for XR service) if the amount of URLLC data is smaller than a configured threshold (e.g., the URLLC data may not be affected by the LCP enhancement procedure).

[0173] For the QoS associated with a configured subset of DRBs / LCHs / data-sets (e.g., URLLC data) satisfying a configured condition, the WTRU may be allowed to perform LCP enhancement for the secondary type of data (e.g., delay-critical) if the discardTimer associated with a configured subset of DRBs / LCHs / Data-Sets is larger than a configured threshold (e.g., the data is not urgent for transmission). This approach may be motivated to mitigate the QoS degradation of other services if XR service is enhanced.

[0174] The WTRU may indicate one or more information elements regarding the LCP enhancement procedure to the network, which may help the WTRU and the network to synchronize in the transmission / reception of data. For example, if out-of-order selection to prioritize selecting the secondary type of data (e.g., delay-critical) is performed, the WTRU may create a SN gap among PDUs. Such information may be indicated to the gNB. The WTRU may indicate one or more of the following to thenetwork regarding the LCP enhancement procedure: whether out-of-order selection is performed for one or more DRBs / LCHs / PDU-sets in the MAC PDU; SN information of the skipped SDU / PDU during the LCP enhancement procedure (e.g., which SNs is skipped, or the skipped SN gap); or the information regarding the remaining secondary type of data, which may include the remaining PSDB and the amount of data.

[0175] In examples, such information may be indicated to the gNB via a MAC header of the associated MAC PDU resulting from the LCP enhancement procedure. In examples, such information may be indicated in the RLC (e.g., control RLC), which may be used to indicate that the missing SNs are intentionally skipped due to the LCP enhancement procedure. In examples, such information may be indicated in a MAC CE.

[0176] The information regarding skipped SNs due to the LCP enhancement procedure may be reported in PDCP (e.g., in a PDCP status report). Such a report may be conveyed to the gNB and / or WTRU during a handover (HO) procedure, which may help both entities synchronize in the PDCP status.

[0177] In examples, the WTRU may fill a MAC PDU up to a second PBR value with data if the WTRU has already filled the transport block (TB) with data up to a first PBR value and there is still data of the secondary type (e.g., delay-critical data) to transmit in the buffer.

[0178] In examples, the WTRU may receive configuration information. The configuration information may include one or more: a first PBR value, a second PBR value associated to a secondary type of data, or condition(s) to determine the secondary type of data. The WTRU may receive a grant for a transmission of a MAC PDU. The WTRU may determine the secondary type of data based on the condition(s) (e.g., configured condition(s)). In examples, the condition(s) (e.g., configured condition(s)) may include the remaining PSDB of the secondary type of data. In examples, the condition(s) (e.g., configured condition(s)) may include the duration the secondary type of data stays in the buffer.

[0179] The WTRU may fill the MAC PDU with data up to the second PBR value based on the secondary type of data being in the buffer (e.g., still being in the buffer) after (e.g., once) the WTRU has exhausted the first PBR (e.g., has filled the MAC PDU will data up to the first PBR value). In examples, the WTRU may apply the second PBR value on a per DRB or per PDU set basis. In examples, the WTRU may fill the MAC PDU with secondary data up to the second PBR value. In examples, the WTRU may fill the MAC PDU with any data up to the second PBR value. The WTRU may transmit the TB associated with the MAC PDU in a grant (e.g., the received grant).

[0180] These examples may allow the WTRU to access a secondary type of data (e. g . , delay-critical data), which may help avoid a potential failure in reception of an entire PDU set due to one or more PDUs of the PDU set not being delivered successfully. These examples may (e.g., may also) allow the receiver to perform selective out-of-order delivery to reduce the decoding delay of packets.

[0181] The WTRU may determine if there is delay-critical data in the buffer. The introduced LCP enhancement procedure may enable prioritization of delay-critical data as a function of an additional configured PBR value associated with delay-critical data that extends to the current PBR configuration.

[0182] In examples, the WTRU may be receive configuration information. The configuration information may include or more conditions for a data set to be a secondary type of data (e.g., delay-critical data). For example, the one or more conditions may include one of more of the PDUs having a remaining PSDB or PSDD being smaller than a configured threshold, the PDUs with an associated delay-critical-timer being smaller than a configured threshold, or the dependent PDUs with the remaining synchronization window being smaller than a configured threshold.

[0183] The WTRU may be configured with PBR values per DRB / LCH / PDU-set (e.g., the WTRU may apply each PBR value on a respective DRB / LCH / PDU set basis (e.g., apply a first PBR value (e.g., within the first set of PBR values) and a second PBR value (e.g., within the second set of PBR values) per DRB / LCH / PDU-set (e.g., apply a first PBR value and a second PBR value on a per DRB / LCH / PDU set basis))). The WTRU may receive a grant for uplink transmission (e.g., dynamic grant / configured grant). The WTRU may perform an LCP enhancement procedure (e.g., based on the amount of data associated with the MAC PDU) by determining how much data (e.g., how many PDUs) from each DRB / LCH / PDU-set to multiplex in the MAC PDU based on the availability / amount of a secondary type of data (e.g., delay-critical data) in each DRB / LCH / PDU-set and based on the configured value of the second PBR value.

[0184] For example, the WTRU may select (e.g., may only select) a DRB / LCH / PDU-set having the secondary type of data (e.g., delay-critical data). For each selected DRB / LCH / PDU-set, the WTRU may (e.g., may then) fill (e.g., fill the MAC PDU) with the secondary type of data (e.g., delay-critical data) until (e.g., only until) fulfilling the second PRB value or until the secondary type of data (e.g., delay-critical data (e.g., all delay-critical data)) from the DRB / LCH / PDU-set is selected. For each selected DRB / LCH / PDU-set, the WTRU may (e.g., may also) fill in sequence data (e.g., any data) until fulfilling the second PBR value from DRBs / LCHs / PDU-sets having the secondary type of data (e.g., delay-critical data) to multiplex in the MAC PDU.

[0185] For example, the WTRU may sequentially select each DRBs / LCHs / PDU-set If the DRBs / LCHs / PDU-sets have the secondary type of data (e.g., delay-critical data), the WTRU may fill data until fulfilling both the first and second PBR values. Otherwise, the WTRU may fill data until fulfilling the first PBR value. The WTRU may transmit the TB associated with the MAC PDU in a grant (e.g., the received grant).

[0186] These examples may allow the WTRU to prioritize the delay-critical data for transmission and may allow flexible implantation of how to meet one or more PBR values associated with either delay-critical data or non-delay-critical data.

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

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

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

Claims

CLAIMSWhat is Claimed:

1. A wireless transmit / recei ve unit (WTRU), comprising: a processor configured to: receive configuration information, wherein the configuration information comprises at least a first prioritized bit rate (PBR) value and a second PBR value; receive a grant for an uplink transmission; determine an amount of data associated with a medium access control protocol data unit (MAC PDU) based on the first PBR value or the second PBR value; and transmit a transport block (TB) associated with the MAC PDU in the received grant.

2. The WTRU of claim 1 , wherein the determination of the amount of data associated with the MAC PDU is a determination to fill the MAC PDU with data up to the second PBR value.

3. The WTRU of claim 2, wherein the determination to fill the MAC PDU with data up to the second PBR value is based on the MAC PDU being filled with data up to the first PBR value and a secondary type of data being in a buffer.

4. The WTRU of claim 3, wherein the data filled up to the second PBR value is the secondary type of data or is any type of data.

5. The WTRU of claim 3, wherein the configuration information further comprises at least one condition to determine whether a data set is the secondary type of data, and wherein the processor is further configured to: determine the data set is the secondary type of data based on the at least one condition.

6. The WTRU of claim 5, wherein the at least one condition is an importance of the data set, a priority of the data set, a remaining PDU set delay budget (PSDB) of the data set, or a duration the data set stays in a buffer.

7. The WTRU of claim 1 , wherein the processor is further configured to:perform a logical channel prioritization (LCP) enhancement procedure based on the amount of data associated with the MAC PDU, wherein the amount of data associated with the MAC PDU is based on an amount of a secondary type of data associated with a data radio bearer (DRB), logical channel (LCH), or PDU set.

8. The WTRU of claim 7, wherein the processor is further configured to: fill the MAC PDU with the secondary type of data until all of the secondary type of data of the DRB, LCH, or PDU set is selected.

9. The WTRU of claim 7, wherein the processor is further configured to: based on the DRB, LCH, or PDU set having the secondary type of data, fill the MAC PDU up to the first PBR value and up to the second PBR value.

10. The WTRU of claim 1 , wherein the first PBR value and the second PBR value is applied on a per DRB basis, a per LCH basis, or a per PDU set basis.

11. The WTRU of claim 1, wherein: the first PBR value is within a first set of PBR values, the second PBR value is within a second set of PBR values, and the processor is further configured to: apply each PBR value within the first set of PBR values on a respective DRB basis, LCH basis, or PDU set basis; and apply each PBR value within the second set of PBR values on a respective DRB basis, LCH basis, or PDU set basis.

12. A method associated with a wireless transmit / receive unit (WTRU), comprising: receiving configuration information, wherein the configuration information comprises at least a first prioritized bit rate (PBR) value and a second PBR value; receiving a grant for an uplink transmission; determining an amount of data associated with a medium access control protocol data unit (MAC PDU) based on the first PBR value or the second PBR value; andtransmitting a transport block (TB) associated with the MAC PDU in the received grant.

13. The method of claim 12, wherein the determination of the amount of data associated with the MAC PDU is a determination to fill the MAC PDU with data up to the second PBR value based on the MAC PDU being filled with data up to the first PBR value and a secondary type of data being in a buffer.

14. The method of claim 13, wherein the configuration information further comprises at least one condition to determine whether a data set is the secondary type of data, further comprising: determining the data set is the secondary type of data based on the at least one condition, wherein the at least one condition is an importance of the data set, a priority of the data set, a remaining PDU set delay budget (PSDB) of the data set, or a duration the secondary type of data stays in the data set.

15. The method of claim 12, further comprising: performing a logical channel prioritization (LCP) enhancement procedure based on the amount of data associated with the MAC PDU, wherein the amount of data associated with the MAC PDU is based on an amount of a secondary type of data associated with a data radio bearer (DRB), logical channel (LCH), or PDU set.

Images