Method, architecture, apparatus, and system for enhancing buffer status reporting for XR traffic

Abstract

In one embodiment, a method implemented in a WTRU is described. In one example, the method may include receiving configuration information indicating a remaining time threshold to be used to trigger reporting information related to a protocol data unit (PDU) set. The method may include determining that a remaining time for transmission of (e.g., one or more PDUs) in the PDU set is below the remaining time threshold. The method may include transmitting reporting information related to the PDU set based on the determination that the remaining time is below the remaining time threshold. In various embodiments, the reporting information may indicate an amount of remaining data to be transmitted in the PDU set for which the remaining time is below the remaining time threshold.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Patent Application No. 63 / 456,952, filed on April 4, 2023, which is hereby incorporated by reference in its entirety.

[0002] The present disclosure generally relates to the fields of communication, software, and coding, including, for example, methods, architectures, devices, and systems for enhancing buffer status reporting of extended reality (XR) traffic.

Background Art

[0003] Extended reality (XR) can include different types of immersive experiences such as, for example, virtual reality (VR), augmented reality (AR), and mixed reality (MR), and realities interpolated therebetween. XR applications can be associated with different types of XR traffic. The embodiments described below are designed with the above in mind.

Summary of the Invention

[0004] Methods, architectures, apparatuses, and systems for enhancing buffer status reports for XR traffic are described herein. In one embodiment, a wireless transmit / receive unit (WTRU) including circuitry including any of a processor, a transmitter, and a receiver is described herein. In an example, the circuitry may be configured to receive configuration information indicating a remaining time threshold to be used to trigger reporting information related to a set of protocol data units (PDUs). The circuitry may be configured to determine that a remaining time for transmission of (e.g., one or more PDUs) in the PDU set is below the remaining time threshold. The circuitry may be configured to transmit reporting information related to the PDU set based on the determination that the remaining time is below the remaining time threshold. In various embodiments, the reporting information may indicate an amount of remaining data to be transmitted in the PDU set for which the remaining time is below the remaining time threshold.

[0005] In one embodiment, the method may be implemented in a WTRU. In an example, the method may include receiving configuration information indicating a remaining time threshold to be used to trigger reporting information related to a set of protocol data units (PDUs). The method may include determining that a remaining time for transmission of (e.g., one or more PDUs) in the PDU set is below the remaining time threshold. The method may include transmitting reporting information related to the PDU set based on the determination that the remaining time is below the remaining time threshold. In various embodiments, the reporting information may indicate an amount of remaining data to be transmitted in the PDU set for which the remaining time is below the remaining time threshold.

Brief Description of the Drawings

[0006] A more detailed understanding may be provided from the following detailed description in conjunction with the accompanying drawings, which are given by way of illustration. The figures of such drawings, like the detailed description, are examples. Accordingly, the figures and the detailed description should not be regarded as limiting, and other equally effective examples are possible and likely. Further, similar reference numerals (the “reference”) in the figures indicate similar elements.

[0007]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0008] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. It will be understood, however, that such embodiments and examples may be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples explicitly, implicitly, and / or inherently (collectively "provided") described, disclosed, or otherwise provided herein. In this specification, various embodiments are described and / or claimed in which an apparatus, system, device, etc. and / or any element thereof performs various operations, processes, algorithms, functions, etc. and / or any part thereof, but it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc. and / or any element thereof is configured to perform any operation, process, algorithm, function, etc. and / or any part thereof.

[0009] Exemplary Communication System

[0010] The methods, apparatuses, and systems provided herein are well-suited for communication including both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with reference to FIGS. 1A-1D. In FIGS. 1A-1D, various elements of the network may utilize, execute in accordance with, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatuses, and systems provided herein.

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

[0012] As shown in Figure 1A, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, which may all be referred to as "stations" and / or "STAs," can be configured to transmit and / or receive wireless signals and can be user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), home electronics devices, devices operating in commercial and / or industrial wireless networks, etc. (or can be any of these). Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0013] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as, for example, CN106 / 115, the Internet 110, and / or network 112. By way of example, base stations 114a, 114b may be any of a base transceiver station (BTS), Node-B (NB), eNode-B (eNB), Home Node-B (HNB), Home eNode-B (HeNB), gNode-B (gNB), NR Node-B (NR NB), a site controller, an access point (AP), a wireless router, etc. Although base stations 114a, 114b are each depicted as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0016] More specifically, as described above, the communication system 100 can be a multiple access system and can use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a of RAN104 / 113 and WTRU102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish an air interface 116 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

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

[0018] In one embodiment, the base station 114a and WTRU102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using New Radio (NR).

[0019] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by transmissions sent between multiple types of radio access technologies and / or multiple types of base stations (e.g., eNBs and gNBs).

[0020] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., WiMAX (Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communication (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0021] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connections in a local area such as, for example, an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by drones, for example), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (such as, for example, WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of a small cell, a pico cell, or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0022] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video delivery, etc., and / or may implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same or a different radio access technology (RAT) as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize New Radio (NR) radio technology, CN 106 / 115 can communicate with another RAN (not shown) employing any of GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0023] CN106 / 115 may also function as a gateway for the WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use a common communication protocol such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 may include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 may include another CN connected to one or more RANs that may use the same RAT or a different RAT as the RAN104 / 114.

[0024] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include a multimode function (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in FIG. 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and a base station 114b that may employ an IEEE802 wireless technology.

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

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

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

[0028] Although the transmit / receive element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. For example, 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 via the air interface 116.

[0029] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have a multimode capability. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

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

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

[0032] 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 instead of, the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or may determine its location based on the timing of signals received from two or more neighboring base stations. It will be understood that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with one embodiment.

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

[0034] WTRU 102 may include a full-duplex radio in which the transmission and reception of some or all of a signal (e.g., associated with a particular subframe for both uplink (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference either via hardware (e.g., a choke) or via signal processing through a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for the transmission and reception of some or all of a signal (e.g., associated with a particular subframe for either uplink (e.g., for transmission) or downlink (e.g., for reception)).

[0035] Figure 1C is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0036] RAN 104 can include eNodeBs 160a, 160b, 160c, but it will be understood that RAN 104 can include any number of eNodeBs while remaining consistent with one embodiment. Each of eNodeBs 160a, 160b, 160c can include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, eNode-B 160a can, for example, transmit radio signals to and receive radio signals from WTRU 102a using multiple antennas.

[0037] Each of eNodeBs 160a, 160b, 160c is associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), etc. As shown in Figure 1C, eNodeBs 160a, 160b, 160c can communicate with each other via the X2 interface.

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

[0039] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can authenticate users of the WTRUs 102a, 102b, 102c, activate / deactivate bearers, select a specific serving gateway during the initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0040] The SGW 164 can be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and transfer user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions such as fixing the user plane during eNode B handover, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the contexts of the WTRUs 102a, 102b, 102c.

[0041] The SGW 164 can be connected to the PGW 166, and the PGW 166 can provide the WTRUs 102a, 102b, 102c with access to a packet switched network such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0042] CN106 may facilitate communication with other networks. For example, CN106 may provide access to a circuit-switched network such as the PSTN108 to the WTRU102a, 102b, 102c to facilitate communication between the WTRU102a, 102b, 102c and a conventional landline communication device. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and the PSTN108. In addition, CN106 may provide the WTRU102a, 102b, 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

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

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

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

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

[0047] A high throughput (HT) STA may use a 40 MHz wide channel for communication via a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel to form, for example, a 40 MHz wide channel.

[0048] A very high throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. A 40 MHz and / or 80 MHz channel may be formed by combining a plurality of consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels, or by combining two non - consecutive 80 MHz channels, which may be referred to as an 80 + 80 configuration. In the case of the 80 + 80 configuration, after channel encoding, the data may pass through a segment parser that can divide the data into two streams. The inverse fast fourier transform (IFFT) process and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the aforementioned operations for the 80 + 80 configuration are reversed, and the combined data may be sent to the medium access control (MAC) layer, entity, etc.

[0049] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV white space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support machine-type communication (MTC) such as MTC devices in a macro coverage area. The MTC device may have limited capabilities, including certain capabilities, e.g., support for a certain and / or limited bandwidth (e.g., support only for these). The MTC device may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0050] A WLAN system that can support a plurality of channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA from among all STAs operating in a BSS that supports a minimum bandwidth operation mode. In an example of 802.11ah, the primary channel is 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only this) even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the state of the primary channel. For example, due to an STA transmitting to an AP (supporting only the 1 MHz operation mode), when the primary channel is in operation, most of the frequency band remains in an inoperative state and, even if it may be available, the entire available frequency band may be considered to be in operation.

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

[0052] FIG. 1D is a system diagram showing RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, 102c via air interface 116 by adopting NR radio technology. RAN 113 can also communicate with CN 115.

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

[0054] WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or varying durations of absolute time of varying lengths).

[0055] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, and 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchor points. In a stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c can communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNodeBs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNodeBs 160a, 160b, and 160c can function as the mobility anchor for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

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

[0057] CN 115 shown in FIG. 1D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and at least one data network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it will be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0058] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can authenticate users of WTRUs 102a, 102b, and 102c, support network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), select specific SMFs 183a and 183b, manage registration areas, terminate NAS signaling, perform mobility management, etc. Network slicing can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on, for example, the type of services being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. AMF 182a and 182b can provide control plane functions for switching between 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 Wi-Fi for example.

[0059] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0060] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N3 interface, which can provide access to a packet-switched network such as the Internet 110 for WTRU102a, 102b, and 102c, for example, to facilitate communication between WTRU102a, 102b, and 102c and IP-compatible devices. UPF184a and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0061] CN115 may facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. Additionally, CN115 can provide access to other network 112 for WTRU102a, 102b, 102c, and other network 112 may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data network (DN) 185a, 185b through UPF184a, 184b via an N3 interface with UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0062] In view of FIGS. 1A-1D and the corresponding descriptions of FIGS. 1A-1D, one or more or all of the functions described herein with respect to any of WTRU102a-d, base stations 114a-b, eNodeBs 160a-c, MME162, SGW164, PGW166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other element(s) / device(s) described herein may be performed by one or more emulation elements / devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

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

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

[0065] For clarity, satisfying a condition, not satisfying a condition, and configuring a condition parameter are described throughout the embodiments described herein as being relative to a threshold (e.g., greater than or less than a value (e.g., a threshold)), constituting a value (e.g., a threshold), etc. For example, satisfying a condition can be described as being greater than a value (e.g., a threshold), and not satisfying a condition can be described as being less than a value (e.g., a threshold). The embodiments described herein are not limited to threshold-based conditions. Any other type of condition and parameter (e.g., belonging or not belonging to a range of values) can be applicable to the embodiments described herein.

[0066] Throughout the embodiments described herein, (e.g., configuration) information can be described as being received by a WTRU from a network, e.g., through system information or via any type of protocol message. Although not explicitly mentioned throughout the embodiments described herein, the same (e.g., configuration) information can be pre-configured in a WTRU (e.g., via factory settings, e.g., via any type of pre-configuration method) so that this (e.g., configuration) information can be used by the WTRU without being received from a network.

[0067] Throughout the embodiments described herein, the expression "a WTRU can be configured with something" can be used interchangeably with "a WTRU can receive configuration information indicating something". Throughout the embodiments described herein, the expressions "a WTRU can report something" and "a WTRU can be configured to report something" are equivalent to, or can be used interchangeably with, "a WTRU can transmit information indicating something (e.g., reporting information)".

[0068] In the embodiments described herein, the terms "a" and "an" and similar phrases should be construed as "one or more" and "at least one". Similarly, any term ending with the suffix "(s)" should be construed as "one or more" and "at least one". The term "may" should be construed as "for example, may".

[0069] The symbol " / " (for example, forward slash) may be used herein to represent "and / or", and for example, "A / B" may imply "A and / or B".

[0070] Throughout the embodiments described herein, the terms "serving base station", "base station", "gNB", "network", collectively "gNB" may be used interchangeably to designate any network element, such as a network element that functions as a serving base station. The embodiments described herein are not limited to gNBs and are applicable to any other type of serving base station.

[0071] Throughout the embodiments described herein, any network element of the RAN or core network (CN) may be referred to herein as a "network".

[0072] Overview of Extended Reality

[0073] The term "extended reality (XR)" may include different types of immersive experiences, such as, for example, any of virtual reality (VR), augmented reality (AR), mixed reality (MR), and any reality interpolated between them.

[0074] Virtual reality (VR) can be regarded as a rendered version of a delivered visual and auditory scene. The rendering can be designed to mimic the visual (e.g., stereoscopic 3D) and auditory sensations of the real world for an observer (e.g., a user) when the observer (e.g., the user) can move within the limits defined by the application.

[0075] Augmented reality (AR) can correspond to an application that can provide a user with additional information such as, for example, either artificially generated items and content overlaid on the current environment.

[0076] Mixed reality (MR) can be regarded as an advanced form of AR that aims to provide an illusion in which one or more virtual elements are inserted into a physical scene and these elements can be part of the real scene. XR can include any (e.g., all) combined environments of reality and virtuality and human-machine interactions generated by computer technology and / or wearables.

[0077] The concept of immersion in the context of an XR application (e.g., service) can refer to providing a sense of being surrounded by a virtual environment and a sense of being physically and spatially located within the virtual environment. The level of virtuality can range from partial sensory input to fully immersive multi-sensory input that aims for virtual reality indistinguishable from actual reality.

[0078] In the embodiments described in this specification, the XR device may be associated with the ability to provide spatial tracking to one or more degrees. The XR device may include one or more sensors enabling spatial tracking, such as, for example, a monocular camera / stereo camera / depth camera, a wireless beacon, a global positioning system (GPS), an inertial sensor, or the like. For example, spatial tracking may be implemented at different levels, such as, for example, 3 degrees of freedom (DoF) (e.g., rotational movement along the X, Y, and Z axes), 6 DoF (e.g., rotational movement and / or translational movement along the X, Y, and Z axes). For example, spatial tracking may provide an interaction for experiencing some form of virtual content. The user may act within the extended reality and / or interact with components within the extended reality. For example, the action and / or interaction may include any of movement, gesture, gaze tracking, etc. Spatial tracking may enable an immersive XR experience. For example, some form of head tracking and / or motion tracking may ensure that the simulated visual and auditory components from the user's perspective are updated to be associated with the user's movement. Incorrect and / or delayed spatial tracking may result in discomfort and / or a feeling of motion sickness for the user.

[0079] In the embodiments described herein, a WTRU may correspond to any XR device (e.g., a network element) that can be of various form factors. For example, a WTRU (e.g., an XR WTRU) may include, but is not limited to, any of the following: a head-mounted display (HMD), an optical see-through glasses, any camera see-through HMD for AR and MR, a mobile device with position tracking and a camera, a wearable, etc. For example, different types of XR WTRUs may exist based on XR device functions provided by one or more devices, wearables, actuators, controllers, and / or accessories, such as any of a display, a camera, a sensor, sensor processing, wireless connection, XR / media processing, and power supply. One or more devices (e.g., network elements, WTRUs) may be grouped into a cooperative XR group to support any of an XR application, an XR experience, and an XR service.

[0080] Examples of PDU sets and data bursts

[0081] In a 5G network, a QoS flow may represent the finest level of granularity for QoS differentiation in a PDU session. 5G QoS characteristics may be determined (e.g., associated) by a 5G QoS identifier (5QI). For example, each packet in a QoS flow may be handled (e.g., processed) according to the same QoS expectation value.

[0082] In the case of XR / media services, a group of packets may be used to carry the payload of a PDU set (e.g., a frame, a video slice, a video tile, etc.). A PDU set may include one or more PDUs that carry the payload of one unit of information generated at the application level (e.g., either a frame or a video slice, etc.).

[0083] In the media layer, the packets of a PDU set can be decoded (e.g., processed) together. For example, a frame / video slice can be decoded (e.g., only in that case) when all or at least a certain amount of the packets carrying the frame / video slice have been received (e.g., properly delivered). For example, the frames within a group of pictures (GOP) of a picture can be decoded by a client (e.g., only in that case) when all the frames on which the frame may depend have been properly received. For example, a group of packets within a PDU set can depend on each other (e.g., be associated with each other) in the media layer. Failing to consider such dependencies among the packets within a PDU set can result in low scheduling efficiency from the 5G network. For example, the 5G network may randomly drop a packet and attempt to deliver other packets of the same PDU set, which may not be useful to the client and may indicate a waste of radio resources.

[0084] For example, when the 5G network can consider PDU set characteristics, any of the auditory samples, tactile applications, and remote control operations can have improved performance. For example, considering the dependencies among the packets of a PDU set (e.g., frame / video slice, etc.) can enable the 5G network to improve radio resource efficiency and promote the user experience.

[0085] The third generation partnership project (3GPP) is considering enhancing the current 5G QoS framework to support different QoS treatments for PDU sets. The PDU set can carry different contents, such as, for example, I / B / P frames and slices / tiles within I / B / P frames. For example, differentiated QoS treatment can be considered when different importance levels of PDU sets can be taken into account, by treating (e.g., processing) packets (e.g., PDUs) belonging to less important PDU sets differently (e.g., reducing resource waste).

[0086] A data burst can include a set of data PDUs generated and sent by an application over a short time period. A data burst can include any number of PDUs belonging to one or more PDU sets.

[0087] The PDU set delay budget (PSDB) can represent the upper limit of the time by which a PDU set can be delayed between a WTRU at the UPF and an N6 termination point (e.g., a network element of the 5G network at the N6 termination point). For example, the PSDB can be the upper limit of the time from the reception of the first PDU of the PDU set at the WTRU until the last PDU of the PDU set can be received at the network (e.g., base station or UPF) (e.g., at the application layer).

[0088] The time to live (TTL), which may be equal to the PSDB, may represent the elapsed time since the reception of the first (e.g., the initial) PDU of a set of PDUs from the application layer. The TTL may represent the amount of time until the transmission of the PDU set may become useless because the receiving application may not be able to use the PDU set. In the embodiments described herein, the terms "TTL", "remaining delay", and "remaining time" may be used interchangeably to refer to a (e.g., ongoing) time period after which the transmission of any remaining (e.g., not yet transmitted) delay-critical data may become useless and may, for example, be discarded. Delay-critical data may be referred to herein as any of a PDU set, one or more PDUs of a PDU set, one or more PDUs of one or more PDU sets, and any type of delay-critical data set.

[0089] The PDU-set error rate (PSER) may be an upper limit of the error rate of a set of PDUs that may be processed by a sender of a link-layer protocol (e.g., a radio link control (RLC) layer), where one or more PDUs within the PDU set may not be successfully received by the corresponding receiver and may not be delivered to an upper layer (e.g., a packet data convergence protocol (PDCP) layer).

[0090] One or more PDU sets may be available for use at the application layer if and only if all PDUs of the PDU set are received (e.g., within the PSDB). Such one or more PDU sets may be flagged (e.g., may include flag information indicating a PSIHI) using a PDU set integrated handing indication (PSIHI).

[0091] One or more PDU sets may be usable if one or more parts of the PDU are not received (e.g., even in that case).

[0092] Figure 2 is a diagram showing an example of a PDU set and a data burst. For example, a WTRU may transmit a first data burst 21 and a second data burst 22. The first data burst 21 may include a first PDU set 211, a second PDU set 212, and a third PDU set 213. The first PDU set 211 may include seven PDUs associated with the same I-frame. The second PDU set 212 may include eight PDUs associated with the same I-frame. The third PDU set 213 may include five PDUs associated with the same P-frame.

[0093] The second data burst 22 may include a first PDU set 221 and a second PDU set 222. The first PDU set 221 of the second data burst 22 may include nine PDUs associated with the same I-frame. The second PDU set 222 of the second data burst 22 may include six PDUs associated with the same B-frame.

[0094] Examples of measurements in NR

[0095] Measurements performed by a WTRU may be used by the network for mobility decisions (e.g., handover, etc.).

[0096] For example, in a connection mode (e.g., RRC_CONNECTED, etc.), the WTRU may measure one or more beams of a cell, and the measurement results (e.g., power values, etc.) may be averaged to derive cell quality (e.g., a cell quality metric). For example, the WTRU may be configured to consider (e.g., measure) a subset of the detected beams. Filtering may be performed at at least two different levels, e.g., at the physical layer to derive beam quality and at the radio resource control (RRC) level to derive cell quality from one or more beams. The cell quality from beam measurements may be derived in the same way for both the serving cell and non-serving cells. The measurement report may include information indicating the measurement results of the X best beams (where X is an integer) if the WTRU is configured by the gNB to do so, for example.

[0097] The measurement report may be configured either in an event-triggered manner or periodically. If the measurement report is configured periodically, the WTRU may be able to send measurement report information every reporting interval (which may range, for example, from 120 milliseconds to 30 minutes).

[0098] In the case of an event-triggered measurement report, the WTRU may be able to send measurement report information when one or more conditions associated with the event are satisfied. The WTRU may continue to measure either the serving cell or one or more neighbors and may report a quantity (e.g., a metric), and this quantity (e.g., a metric) may be verified (e.g., evaluated) using either a threshold and / or an offset defined (e.g., indicated) in the reporting configuration. For example, either the reported quantity (e.g., a metric) or the trigger for the event may include any of reference signal received power (RSRP), reference signal received quality (RSRQ), and signal-to-interference-plus-noise ratio (SINR).

[0099] In NR, there can be intra-RAT events and inter-RAT events within a radio access technology (RAT).

[0100] Examples of intra-RAT events

[0101] In a first example of an intra-RAT event that may be referred to herein as an A1 event, a metric associated with a serving cell may satisfy a condition (e.g., may become higher than a threshold). The A1 event may be used, for example, to cancel an ongoing handover procedure. This may be applicable when the WTRU can move towards the cell edge, trigger a mobility procedure, and then return within good coverage before the mobility procedure is completed.

[0102] In a second example of an intra-RAT event that may be referred to herein as an A2 event, a metric associated with a serving cell may not satisfy a condition (e.g., may become worse than a threshold). The A2 event may or may not involve any neighbor cell measurements. The A2 event may be used, for example, to trigger a blind mobility procedure, or the network may configure the WTRU for neighbor cell measurements when the network receives measurement report information triggered by the A2 event (e.g., to not perform neighbor cell measurements when the serving cell quality is good enough to save the WTRU battery).

[0103] In a third example of an in-RAT event that may be referred to as an A3 event in this specification, the metric associated with a neighbor cell may satisfy a condition (e.g., may be offset better than a special cell (SpCell)). The A3 event may be used, for example, for a handover procedure. For example, the SpCell may be a primary serving cell of either (i) a master cell group (MCG), e.g., a primary cell (PCell), and (ii) a secondary cell group (SCG), e.g., a primary secondary cell (PSCell). For example, in dual connectivity (DC) operation, a secondary node (SN) may configure an A3 event for a PSCell change triggered by the SN. The A3 event may be used for either a conditional handover (CHO) or a conditional PSCell change (CPC).

[0104] In a fourth example of an in-RAT event that may be referred to as an A4 event in this specification, the metric associated with a neighbor cell may satisfy a condition (e.g., may become higher than a threshold). The A4 event may be used for a handover procedure that may not depend on the coverage of the serving cell (e.g., load balancing such that a WTRU may be handed over to a (e.g., good) neighbor cell even when the serving cell conditions are excellent).

[0105] In a fifth example of an in-RAT event that may be referred to as an A5 event herein, the first metric associated with the SpCell may not satisfy the first condition (e.g., it may become worse than the first threshold), and the second metric associated with the neighbor cell may satisfy the second condition (it may become higher than the second threshold). The A5 event may be used, for example, for handover (similar to, for example, the A3 event). The A5 event may provide a handover trigger mechanism based on the absolute measurement values of the serving cell and the neighbor cell (in contrast to, for example, the A3 event, which may be based on relative comparison). For example, the A5 event may be suitable for time-critical handovers, for example, when the serving cell becomes weak and the WTRU may change towards another cell that does not meet the criteria for an A3 event handover.

[0106] In a sixth example of an in-RAT event that may be referred to as an A6 event herein, the metric associated with the neighbor cell may satisfy the condition (e.g., it may be offset better than a secondary cell (SCell)). The A6 event may be used, for example, for SCell addition and / or release.

[0107] Examples of inter-RAT events:

[0108] In a first example of an inter-RAT event that may be referred to as a B1 event herein, the metric associated with the inter-RAT neighbor may satisfy the condition (e.g., it may become higher than the threshold). The B1 event may correspond to the A4 event in the case of an inter-RAT handover.

[0109] In a second example of an inter-RAT event that may be referred to as a B2 event in this specification, the first metric associated with the PCell may not meet the condition (e.g., it may become worse than the first threshold), and the second metric associated with the inter-RAT neighbor cell may meet the second condition (e.g., it may become higher and better than the second threshold). The B2 event may correspond to the A5 event in the case of an inter-RAT handover.

[0110] For example, the measurement event configuration (e.g., information) may include a time to trigger (TTT) indicating the duration for which the event condition may be met (e.g., satisfied) before the WTRU may trigger an associated measurement report. The TTT may be set to a value in the range of zero (e.g., no TTT) to several minutes (up to 5 minutes in NR Rel-16).

[0111] Examples of NR conditional handover and conditional PSCell addition or change

[0112] NR Rel-16 introduced the concepts of conditional handover (CHO) and conditional PSCell addition / change (CPA / CPC, collectively referred to as CPAC) to reduce the likelihood of radio link failure (RLF) and handover failure (HOF).

[0113] A legacy LTE / NR handover can be triggered, for example, by measurement report information. In another example, the network can send an HO command to the WTRU without, for example, receiving measurement report information. For example, in the case of dual connectivity (DC), the WTRU can be configured with an A3 event to trigger the sending of a measurement report when the metric of a neighbor cell (e.g., any of the radio signal level / quality (e.g., RSRP, RSRQ, etc.)) becomes better (e.g., higher) than the corresponding metric of the primary serving cell (PCell) or the corresponding metric of the primary secondary serving cell (PSCell). The WTRU can monitor either the serving cell or a neighbor cell and can send measurement report information when (e.g., configured) conditions are met (e.g., satisfied). When the network receives the measurement report information, the network (the current serving network element / cell) can prepare an HO command (e.g., an RRC reconfiguration message indicating reconfiguration with sync (e.g., reconfigurationWithSync)) and can send the HO command to the WTRU. The WTRU can receive and execute the HO command, as a result of which the WTRU connects to the target cell.

[0114] CHO may differ from legacy handover in that at least two or more handover targets can be prepared (as compared to a single target in the legacy case).

[0115] CHO may further differ from legacy handover in that the WTRU may not execute the handover (e.g., immediately) as in the case of legacy handover. For example, the WTRU can be configured with one or more trigger conditions (e.g., a set of radio conditions), and the WTRU can execute a handover towards one of the targets when one or more of the trigger conditions are met (e.g., only in that case).

[0116] For example, a CHO command may be sent when the radio conditions for the current serving cell are (e.g., still) favorable, thereby reducing two main obstacle points in legacy handover, e.g., (1) the risk of failing to send measurement report information (e.g., when the link quality to the current serving cell falls below the acceptable level for a measurement report triggered in a normal handover), and (2) the risk of failing to receive a handover command (e.g., when the link quality to the current serving cell falls below an acceptable level after the WTRU has been able to send a measurement report but before it can receive an HO command).

[0117] The trigger condition for CHO may be based on the radio quality of either the serving cell or a neighbor cell, such as any of the conditions that may be used in legacy NR / LTE to trigger a measurement report. For example, the WTRU may be configured with a CHO associated with an A3 event similar to the trigger condition and the associated HO command. The WTRU may monitor the current cell and the serving cell, and if the A3 event trigger condition is satisfied, the WTRU may not be able to send measurement report information, may execute the associated HO command, and may switch its connection towards the target cell.

[0118] Figure 3 is a diagram showing an example of conditional handover configuration and execution. For example, the WTRU 30 may perform a conditional handover from the source network element 31 to the target network element 32. The WTRU 30 may receive configuration information 301 from the source network element 31 indicating any of one or more conditions (e.g., associated with either an A3 event or an A5 event), one or more parameters associated with the one or more conditions (e.g., either a threshold value, an offset value, etc.), and a parameter associated with RRC reconfiguration. The WTRU may monitor the CHO conditions for the target cell candidates. If the conditions are satisfied for the target network element 32, the WTRU performs a handover towards the target network element 32 and sends CHO confirmation information 302 to the target network element 32.

[0119] CHO may be able to prevent unnecessary re - establishment in case of radio link failure. For example, a WTRU may be composed of two or more CHO targets, and the WTRU may experience a radio link failure (RLF) before any of the trigger conditions with any of the targets are satisfied. In the conventional operation, an RRC re - establishment procedure that may cause an interruption time for the bearers of the WTRU may have been brought about. When using CHO, after detecting an RLF, if the WTRU reaches a cell associated with the CHO (for example, if the target cell is already prepared for the CHO), the WTRU may execute (for example, directly) the HO command associated with this target cell and may not need to continue the complete re - establishment procedure.

[0120] CPC and CPA can be regarded as an extension of CHO for the DC scenario. For example, a WTRU may be composed of one or more trigger conditions for either PSCell change or addition, and when one or more of the trigger conditions are satisfied, the WTRU may execute either the associated PSCell change command or the PSCell addition command.

[0121] To enable CHO / CPAC, new conditional measurement events are defined in NR. When the conditions associated with the event are satisfied, the CHO / CPAC configuration associated with this event can be executed.

[0122] For example, the condition associated with event A3 (which may be referred to as CondEvent A3 in this specification) can be satisfied when the candidate cell (the metric associated with it) has a better (for example, higher) offset amount than either the PCell or the PSCell.

[0123] For example, the condition associated with event A4 (which may be referred to as CondEvent A4 in this specification) can be satisfied when the candidate cell (the metric associated with it) becomes better (for example, higher) than a threshold value.

[0124] For example, the conditions associated with event A5 (which may be referred to herein as CondEvent A5) may be satisfied when either the PCell or the PSCell (e.g., a first metric associated therewith) becomes worse than a first (e.g., absolute) threshold, and when a candidate cell (e.g., a second metric associated therewith) becomes better (e.g., higher) than a second (e.g., absolute) threshold.

[0125] In addition to the radio condition-based conditional events described herein, location-based and time-based conditional events are also defined in NR (e.g., in a scenario similar to a non-terrestrial network (NTN) where either the time and location of a mobile satellite cell may be predictable, such that the WTRU may be instructed to perform CHO / CPAC based on either time and location).

[0126] In a first example, the condition (which may be referred to herein as CondEvent D1) may be satisfied when the distance between the WTRU and a first reference location (e.g., referenceLocation1) becomes greater than a first configured threshold (e.g., Thresh1), and when the distance between the WTRU and a second reference location (e.g., referenceLocation2) of a conditional reconfiguration candidate becomes less than a second configured threshold (e.g., Thresh2).

[0127] In a second example, the condition (which may be referred to herein as CondEvent T1) may be satisfied when the time measured at the WTRU becomes greater than a first configured threshold (e.g., Thresh1) and less than a second configured threshold (e.g., Thresh2).

[0128] For example, similar to a measurement report event, the conditional event configuration information may include a time to trigger (TTT) indicating a duration for which an event condition may be satisfied before the WTRU may perform CHO.

[0129] Example of buffer status report

[0130] Throughout the embodiments described herein, the expressions “uplink buffer status report (BSR)”, “buffer status report (BSR)”, and “BSR information” may be used interchangeably.

[0131] The uplink buffer status report (BSR) may enable providing support for QoS-aware packet scheduling. In NR, BSR information may be reported at the logical channel group (LCG) granularity. A WTRU may be composed of up to 32 logical channel identifiers (LCIDs), which may be grouped into up to 8 LCGs. For example, one or more WTRUs may be composed of 33 or more LCIDs and 9 or more LCGs (e.g., the mobile termination (MT) of an integrated backhaul access (IAB) node may be composed of up to 65,855 LCIDs and 256 LCGs).

[0132] The BSR may be sent using a MAC control element (MAC CE) and may be sent in either a short BSR format for reporting data for one LCG (e.g., only one LCG) or a long BSR format for reporting data from two or more LCGs.

[0133] Multiple BSRs may be transmitted using multiple MAC control elements (MAC CE). When the BSR is triggered (e.g., when new data arrives at the WTRU's transmission buffer) and the WTRU does not have available UL grant (e.g., resources) to send the BSR, a scheduling request (SR) may be sent by the WTRU to request UL resources to send the BSR.

[0134] To control the BSR, any one of (i) a periodic BSR timer (which may be referred to herein as periodicBSR - Timer), (ii) a retransmission BSR timer (which may be referred to herein as retxBSR - Timer), (iii) an applied logical channel SR delay timer (which may be referred to herein as logicalChannelSR - DelayTimerApplied), (iv) a logical channel SR delay timer (which may be referred to herein as logicalChannelSR - DelayTimer), (v) a logical channel SR mask (which may be referred to herein as logicalChannelSR - Mask), and (vi) a logical channel group (which may be referred to herein as aslogicalChannelGroup) may be configured via RRC.

[0135] The MAC entity may determine the amount of UL data available for a logical channel, for example, according to data volume calculation procedures implemented in either RLC and PDCP.

[0136] In data volume calculation, the WTRU may include, for example in the RLC layer, any RLC data PDUs that may be pending for transmission and / or retransmission, RLC service data units (SDUs) (or segments of RLC SDUs) that may not yet be included in the RLC data PDUs, and any pending status messages such as RLC STATUS PDUs described in, for example, 3GPP TS 38.322 "Technical Specification NR; Radio Link Control (RLC) protocol specification (Release 17)" (V17.0.0).

[0137] Data volume calculation in the PDCP layer may include any PDCP SDUs for which PDCP data PDUs may not be constructed, PDCP data PDUs that may not yet be transmitted to the lower layer, any PDCP control PDUs, and any PDCP SDUs or PDUs that may be retransmitted based on PDCP re-establishment and / or PDCP data recovery as described in 3GPP TS 38.323 "Technical Specification NR; Packet Data Convergence Protocol (PDCP) Specification (Release 17)" (V17.0.0).

[0138] The WTRU may trigger a BSR when any of the following events occur.

[0139] In a first example, the WTRU may trigger a BSR when UL data for a logical channel belonging to an LCG becomes available, for example, to the MAC entity, and when this UL data belongs to a logical channel having a priority higher than the priority of any logical channel containing available UL data belonging to any LCG.

[0140] In a second example, the WTRU may trigger a BSR when UL data for logical channels belonging to an LCG becomes available to, for example, the MAC entity, and when none of the logical channels belonging to the LCG contain available UL data. In either the first or second example, the BSR may be referred to as a "regular BSR".

[0141] In a third example, the WTRU may trigger a BSR when UL resources are allocated and the amount of data the WTRU has is less than what the resources may enable the WTRU to send, and the number of padding bits may be greater than or equal to the size of the buffer status report MAC CE with its subheader added. In the third example, the BSR may be referred to as a "padding BSR".

[0142] In a fourth example, the WTRU may trigger a BSR when a retransmission BSR timer (e.g., retxBSR-Timer) expires and at least one of the logical channels belonging to the LCG contains UL data. In the fourth example, the BSR may (e.g., the BSR may also) be referred to as a "regular BSR".

[0143] In a fifth example, the WTRU may trigger a BSR when a periodic BSR timer (e.g., periodicBSR-Timer) expires, in which case the BSR may be referred to as a "periodic BSR".

[0144] If a regular BSR trigger event occurs at the same time (e.g., simultaneously) for two or more logical channels, (e.g., each) logical channel may trigger one separate regular BSR.

[0145] In the embodiments described herein, the BSR may be sent per LCG rather than per logical channel (LCH).

[0146] In the embodiments described herein, an LCG may contain a single LCH (e.g., only a single LCH).

[0147] For example, LCHs with the same priority may be linked to the same LCG. This may enable the gNB to differentiate between the volume of high-priority data and the volume of low-priority data.

[0148] Overview

[0149] The NR BSR may be triggered, for example, via a timer (e.g., a periodic BSR) and / or based on the arrival of new UL data to be transmitted (e.g., if this data belongs to a logical channel having a priority higher than the priority of any logical channel containing available UL data belonging to any LCG, or if none of the logical channels belonging to the LCG contain available UL data).

[0150] XR traffic may include either a set of related PDUs and data bursts, and may include either PDUs and sets of PDUs of different importance (e.g., priority, type) within the same bearer (e.g., a bearer mapped to the same LCID, or a bearer mapped to different LCIDs belonging to the same LCG). For example, a BSR trigger based on the arrival of new data or high-priority data (e.g., based only on that) may not be able to address XR traffic characteristics.

[0151] The embodiments described herein may be able to enhance the NR BSR trigger mechanism to adapt to the interrelationships and differences of PDUs within either a set of PDUs or a data burst in XR.

[0152] Overview of BSR / SR trigger based on the remaining time for delivery of a set of PDUs and the amount of unprocessed data for the set of PDUs.

[0153] The embodiments described herein may be able to expedite (e.g., accelerate) the transmission of a set of PDUs before the PSDB of the set of PDUs may expire.

[0154] In one embodiment, the WTRU may be configured to trigger a BSR / SR when at least one parameter associated with the transmission of a PDU set satisfies a condition. For example, the WTRU may be configured to trigger a BSR / SR when the TTL for a PDU set falls below a (configured) duration (e.g., threshold), and the amount of unprocessed data for the PDU set exceeds a buffer size (e.g., threshold).

[0155] For example, in a first step, the WTRU may receive a configuration (e.g., configuration information indicating it) for sending a buffer status report (BSR) or a scheduling request (SR) related to a PDU set, and in that case, the BSR / SR may be triggered when one or more of the following are conditions and are satisfied.

[0156] In a first example, the BSR / SR may be triggered when the amount of unprocessed (e.g., buffered) data for that PDU set (e.g., any of the number of PDUs, data size in bytes, percentage of PDUs, etc.) exceeds a (configured) buffer size (e.g., threshold).

[0157] In a second example, the BSR / SR may be triggered when the TTL for a PDU set falls below a (configured) duration (e.g., threshold).

[0158] For example, in a second step, the WTRU may monitor either the size of the PDU set in the UL buffer or the TTL of the PDU set (e.g., of the LCG associated therewith).

[0159] For example, in a third step, if it is determined that the buffered size of the queued PDUs for a PDU set exceeds a buffer size (e.g., threshold) and / or the TTL falls below a duration (e.g., threshold), the WTRU may send a BSR / SR related to the PDU set.

[0160] Overview of BSR / SR Triggers Based on Information Available to the PDU Set

[0161] The embodiments described herein may enable information about a PDU set (e.g., detailed) to be sent to the network, e.g., in a BSR, after the information becomes available to the WTRU and / or after the PDU set information may have changed during the lifetime of the PDU set, such that the network can schedule the WTRU in an improved manner. The (e.g., detailed) information about the PDU set described herein may be referred to as PDU set information. In the embodiments described herein, the terms "PDU set information", "detailed PDU set information", "uplink traffic information", and "PDU set related information for uplink traffic" may be used interchangeably.

[0162] In one embodiment, the WTRU may be configured to trigger one or more BSR / SRs related to the PDU set that may depend on information available to the WTRU about the PDU set.

[0163] In a first example, the WTRU may trigger a BSR / SR related to the PDU set when, after the arrival of a PDU of the PDU set (e.g., any of the first PDU, intermediate PDU, final PDU), the WTRU has (e.g., only in that case) information (e.g., any of the size (e.g., in number of PDUs), periodicity, PSDB, type, importance, etc.) about the PDU set (e.g., detailed). The (e.g., detailed) information may be included in the PDU header. In another example, the (e.g., detailed) information may be made available to the WTRU (at the network layer) by the application layer. The WTRU may include the (e.g., detailed) information about the PDU set, e.g., in the BSR. In another example, reduced information may be provided, such as either the size and timing window when (e.g., all) data may be expected to be available in the WTRU buffer.

[0164] In a second example, after the arrival of the first PDU of a PDU set, if at that time the WTRU does not have (e.g., detailed) information about the PDU set (e.g., the PDU may not contain detailed information, or the WTRU may not have obtained (e.g., detailed) information from the application layer), the WTRU may trigger a first BSR / SR related to the PDU set. The WTRU may include, for example, "expected" data size / timing information in this first BSR. If (e.g., detailed) information about the PDU set becomes available later (e.g., the WTRU may receive an intermediate PDU that may contain (e.g., detailed) information, may receive the last PDU of the PDU set that has (e.g., detailed) information, etc.), the WTRU may send a second BSR / SR related to the PDU set that may include correct (e.g., updated) size / timing information. The BSR / SR may include reduced (e.g., summarized) information indicating a request for, for example, more / less resources, reducing / increasing a preferred timing window for resource availability, etc.

[0165] Overview of BSR / SR Triggering Based on Either Radio Conditions or Conditions Related to an Ongoing PDU Set

[0166] The embodiments described herein may enable the scheduling of an ongoing PDU set to be expedited (e.g., accelerated) before a mobility event (e.g., handover) is expected to occur so that PDUs belonging to the same PDU set can be transmitted via the same path (e.g., cell, network element), and thus may experience similar latency and / or UL interruption during handover and may not cause PSDB expiration.

[0167] In one embodiment, the WTRU may be configured to trigger a BSR / SR based on either radio conditions or conditions related to an ongoing PDU set.

[0168] For example, the WTRU may receive a configuration (e.g., configuration information indicating it) for triggering BSR / SR that depends on one or more of the following conditions.

[0169] In a first example of a condition, the BSR / SR may be triggered based on one or more radio conditions towards a source or / and a target.

[0170] In a second example of a condition, the BSR / SR may be triggered based on the remaining PDUs of an ongoing PDU set (e.g., either the number of ongoing PDU sets, the size of the remaining PDUs of a PDU set, etc.), where (i) all PDU sets may be considered, or (ii) only a part of the PDU sets (e.g., only some) may be considered (e.g., PDU sets of a certain type or importance, PDU sets having a PSDB below a threshold, PDU sets having a TTL below a threshold, PDU sets having a percentage / number of pending PDUs (e.g., only such PDU sets), etc.).

[0171] If any of the conditions are met, the WTRU may send a BSR / SR including information about the ongoing PDU set to the network.

[0172] Term

[0173] Throughout the embodiments described herein, the terms "node" and "network element" may be used interchangeably.

[0174] Throughout the embodiments described herein, the network may include, for example, a base station (e.g., gNB, transmit / receive point (TRP), RAN node, access node), a core network function (e.g., AMF), and an application function (e.g., edge server function, remote server function).

[0175] Throughout the embodiments described herein, the term "source" may refer to the node or cell to which the WTRU may originally be connected.

[0176] Throughout the embodiments described herein, the term "target" may refer to the node or cell to which the WTRU may be handed over by either a CHO or a dual active protocol stack (DAPS) handover execution.

[0177] Throughout the embodiments described herein, the terms "conditional handover", "conditional configuration", and "conditional reconfiguration" may be used interchangeably.

[0178] In this specification, embodiments related to UL data transmission are described. Throughout the embodiments described herein, expressions such as "PDU received at the WTRU" may be referred to herein as "PDU received (e.g., obtained) at the WTRU radio buffer from the application layer".

[0179] Throughout the solutions described herein, the terms "PDU" and "packet" may be used interchangeably.

[0180] Throughout the embodiments described herein, the term "trigger" may be used interchangeably with either "send" or "transmit".

[0181] In this specification, embodiments in which the WTRU sends a BSR for a PDU set are described. A WTRU configured to send another (e.g., another type of) indication / information (e.g., any of a non-BSR MAC CE, an RRC message, etc.) providing report information for a PDU set, which may or may not include buffer size (e.g., level) information, may be applicable to the embodiments described herein. In the embodiments described herein, the terms BSR, report information, and uplink information report may be used interchangeably.

[0182] Throughout the embodiments described herein, a flow may correspond to either a QoS flow or a data flow (e.g., a data flow may include one or more PDU or application data units (ADUs) that may be associated with one or more QoS expectations (e.g., requirements), such as latency, data rate, reliability). Different flows originating from a common (e.g., application, experience) source and / or directed to a common destination device (e.g., a WTRU) or group of associated devices (e.g., a WTRU) may be referred to as associated flows or correlated flows.

[0183] Throughout the embodiments described in this specification, the expression "transfer configuration" may correspond to transfer information indicating any of: (i) a radio bearer (e.g., a data radio bearer (DRB) and / or a signaling radio bearer (SRB)), (ii) a logical channel (LCH), (iii) a logical channel group (LCG), (iv) configuration parameters in individual layers within an access stratum (AS) protocol stack (e.g., any of service data adaptation protocol (SDAP), PDCP, RLC, MAC, PHY, other new protocol layers), (v) parameters associated with logical channel prioritization (LCP) (e.g., any of priority, prioritized bit rate (PBR), buffer size duration (BSD)), (vi) a bandwidth part (BWP), (vii) a carrier, (viii) a radio link / interface (Uu link, sidelink (SL)), and (ix) a radio resource (e.g., a set of one or more frequency / time / space resources such as any of a time slot, a subcarrier, and a beam). The radio resource may be associated with a configured grant, and / or a dynamic grant, and / or any other resource grant or grant-free resource.

[0184] Throughout the embodiments described herein, the expression "mapping configuration" may correspond to any of the following parameters and / or configurations associated with the mapping from one or more (1) application data (e.g., PDU sets) flows, QoS flows (e.g., related or unrelated) to (2) one or more radio bearers, SDAP, PDCP, LCH, carriers or component carriers (e.g., CCs in a CA configuration), BWPs, and radio links / interfaces (e.g., Uu link and / or sidelink), and may be used, for example, to deliver PDUs in the UL or DL direction.

[0185] Throughout the embodiments described herein, the expression "XR / application-aware data transmission / reception" or "XR / application-aware QoS processing" may correspond to any of the following three examples.

[0186] In a first example, which may be referred to as PDU set processing, a PDU set (e.g., either a media unit or a video frame) may include one or more PDUs. The PDU set may be associated with PDU set-level QoS (e.g., requirement) characteristics (e.g., any of data rate, latency, reliability) that may be applicable to one or more or all of the PDUs associated with the PDU set. Different PDUs within the PDU set may be associated with individual PDU-level QoS (e.g., requirement) characteristics. Such associations and interdependencies may be visible to the AS layer (e.g., using associated IDs) and / or recognized during data transmission and reception and processed in the AS layer.

[0187] In a second example that may be referred to as application / higher layer importance / priority, different PDUs in a PDU set, or all PDUs in a PDU, may be associated with different application values / higher layer importance values / priority values. Such (e.g., importance, priority, rank) values may correspond to spatial (e.g., importance) values and / or temporal (e.g., importance) values. Spatial (e.g., importance) values may include, for example, the spatial position of a video frame that data may be carried by a PDU / PDU set, in which case a PDU / PDU set carrying a field of view (FoV) spatial position may be associated with a higher spatial (e.g., importance) value than a non-FoV spatial position). Temporal (e.g., importance) values may include, for example, the temporal sequence of a video frame that data may be carried by a PDU / PDU set, in which case a PDU / PDU set carrying a base video frame such as an I-frame may be associated with a higher temporal (e.g., importance) value than a differential video frame such as a P-frame / B-frame). Such (e.g., importance) values may be visible at the AS layer (e.g., using an associated ID / marker / indicator) during data transmission and reception, enabled, for example, by application recognition.

[0188] In a third example that may be referred to as QoS flow processing, a PDU / PDU set of an application is encoded and may be delivered to a WTRU by an application (e.g., layer) (e.g., in the case of data flowing in the UL) or to the network (e.g., in the case of data flowing in the DL) via one or more QoS / data flows. For example, different QoS flows carrying a PDU / PDU set associated with an XR application (e.g., experience) may be visible at the AS layer (e.g., using an associated ID) and / or the association may be recognized during data transmission and / or reception and processed at the AS layer.

[0189] Throughout the embodiments described herein, the expression "the WTRU may be in the middle of transmitting / receiving a packet belonging to either a PDU set or a data burst" may refer to a scenario where one or more PDUs of either the PDU set or the data burst have already been transmitted / received, or may be transmitted / received, while others may remain pending in the WTRU buffer / gNB buffer. The expression "ongoing PDU set or data burst" may be used to refer to the unprocessed (e.g., remaining that were not successfully transmitted, in the case of UL, the remaining that were not successfully received as should be transmitted by the WTRU, in the case of DL, the remaining that should be received by the WTRU) PDUs within the PDU set or data burst. The above expressions and terms may also apply to a scenario where one or more packets associated with either a PDU set, a data burst, and a QoS flow may be pending in the application / upper layer and / or may not have yet arrived at the lower layer buffer in the WTRU / gNB for UL / DL transmission. The WTRU / gNB may recognize packets that may be pending in the application / upper layer, for example, based on the indication and / or marking of the application (e.g., non-access stratum (NAS)) layer within a previously received packet header. The above expressions and terms may also apply to non-XR traffic that may include one or more stand-alone PDUs within any QoS flow without any association with, for example, a PDU set, a media frame / video frame, or a data burst.

[0190] For example, the WTRU may, in some cases (e.g., the WTRU may stop the BSR prohibition timer and send a BSR related to the PDU set), not consider (e.g., ignore) the BSR prohibition time that may be executed due to the legacy BSR mechanism for determining to trigger a BSR for a PDU set according to any of the embodiments described herein.

[0191] Throughout the embodiments described herein, the PDU set is used as an example of data for which reporting information may be transmitted. The embodiments described herein are not limited to PDU sets and may be applicable to any type of data, such as, for example, delay-critical data.

[0192] Throughout the embodiments described herein, the terms "PDU set" and "delay-critical data" may be used interchangeably.

[0193] Throughout the embodiments described herein, the terms "size of buffered data", "amount of buffered data", "amount of unprocessed buffered data of the PDU set", "buffered size of PDUs pending in the PDU set", and "amount of remaining data to be transmitted in / for the PDU set" may be used interchangeably.

[0194] Configuration aspects

[0195] The WTRU may receive configuration information for supporting any of the procedures, mechanisms, rules, actions, etc. described herein in relation to buffer status reporting. The WTRU may receive configuration information for supporting any of the procedures, mechanisms, rules, actions, etc. described herein at any time, such as, for example, when the WTRU may be in a connected mode, or when the WTRU may be resuming connection from a suspended state, or when the WTRU may be establishing a connection from an idle state, or when the WTRU may be re-establishing a connection after a failure.

[0196] The configuration information may be received by the WTRU from the network via, for example, any of (i) an HO command (e.g., any RRC reconfiguration message indicating reconfiguration using synchronization), (ii) a CHO configuration, (iii) an RRC resume message, and (iv) any other (e.g., RRC) message.

[0197] For example, a WTRU may receive any configuration information element via one of (i) broadcast signaling (e.g., SIB), (ii) dedicated signaling, (iii) NAS layer signaling, and (iv) application layer signaling (e.g., a message). Examples of dedicated signaling may include any RRC signaling and / or message, such as, for example, RRC reconfiguration, CHO configuration, DAPS HO command, RRC measurement report configuration, RRC resume, RRC setup, etc. Examples of NAS layer signaling may include either a PDU session establishment response or a PDU session modification command.

[0198] Configuration information that may be received by the WTRU from the network may include one or more combinations of the following information.

[0199] For example, the configuration information may indicate either a mapping configuration, a transfer configuration, and / or a resource configuration and / or corresponding parameters.

[0200] For example, the WTRU may receive a set of one or more configurations and / or configuration parameters applied in different layers of the protocol stack (e.g., any of SDAP, PDCP, RLC, MAC, PHY, and any new layer). The configuration parameters may include any of the following parameters.

[0201] For example, SDAP parameters may indicate any of a one-to-one (e.g., 1:1) mapping configuration, a one-to-many (e.g., 1:M) mapping configuration, and a many-to-many (e.g., N:M) mapping configuration, a marking / indication / ID to apply (e.g., associated with any of a QoS flow, a PDU set, a data burst), association information indicating an association between PDUs, PDU sets, and / or data bursts, and a range of values associated with the importance / priority of PDUs, PDU sets, and / or data bursts.

[0202] For example, the PDCP parameters may indicate either rules and criteria for mapping PDUs, and / or PDU sets, and / or data bursts to two or more RLC entities / LCHs / legs.

[0203] For example, the PDCP parameters may indicate either rules and criteria for allocating sequence numbers for PDUs, and / or PDU sets, and / or data bursts (such as, for example, any one of a count range, a hyper frame number (HFN) range, and an SN range).

[0204] For example, the PDCP parameters may indicate a robust header compression (RoHC) configuration for application to legs associated with a source and / or a target.

[0205] For example, the PDCP parameters may include security (such as encryption) parameters for application to legs associated with a source and / or a target.

[0206] For example, the PDCP parameters may include an instruction and / or a flag indicating whether to apply any packet duplication.

[0207] For example, the PDCP parameters may include either rules and criteria (such as a discard timer) for discarding PDU sets and / or data bursts.

[0208] For example, the PDCP parameters may include either rules and criteria for ensuring in-order delivery of PDUs, and / or PDU sets, and / or data bursts.

[0209] For example, the RLC parameters may indicate a mode (e.g., acknowledge mode (AM), unacknowledged mode (UM), transparent mode (TM), etc.) and parameters applied to a leg associated with a source and / or target.

[0210] For example, the MAC parameters may indicate any of the rules and criteria for applying to LCH / MAC entities within a leg associated with a source and / or target, including (i) LCH parameters (e.g., priority, PBR, BSD), (ii) LCP (e.g., rules and / or restrictions for handling PDU sets and / or data bursts, duration for changing between different LCP rules), and (iii) any configuration for multiplexing a PDU set / data burst into a transport block (TB).

[0211] For example, the PHY parameters may indicate one or more hybrid automatic repeat request (HARQ) configurations (e.g., the number of permitted retransmissions).

[0212] The WTRU may receive information indicating at least one set of configuration parameters associated with a default configuration, and the default configuration may be activated and / or used during a first (e.g., normal) operation for transmitting / receiving data, for example, during handover (HO). The WTRU may (e.g., the WTRU may also) receive information indicating another set of configuration parameters associated with a second (e.g., exceptional) operation that may be activated and / or used, for example, when detecting any trigger event / condition during HO.

[0213] For example, the configuration information may include validity information. For example, the WTRU may receive validity information associated with any of a transfer configuration, a resource configuration, and a BSR trigger configuration, and the validity information may indicate whether (e.g., when) a configuration may be considered valid or invalid based on one or more of trigger events / conditions. The WTRU may (e.g., the WTRU may also) receive information indicating whether a configuration should be deactivated and / or released when it is determined that the configuration is invalid.

[0214] Examples of WTRU actions

[0215] Throughout the embodiments described herein, for example, WTRU actions related to application actions and / or AS layer actions may correspond to any of the following examples of WTRU actions.

[0216] In a first example, the WTRU action may correspond to performing a measurement and reporting an action. For example, the WTRU may perform any measurement of (1) the posture (e.g., 6DoD / 3DoD orientation, location / position), and (2) the speed of movement (e.g., movement) of any of the user, the WTRU, and any other object (e.g., virtual or real) with which the user may interact. The WTRU may send / report information indicating the posture measurement value (e.g., report) to the network either periodically or after detecting an event trigger (e.g., a change in the posture measurement value above / below a threshold).

[0217] For example, the WTRU may perform one or more measurements of (i) a reference signal (e.g., any of a synchronization signal block (SSB), a channel state information reference signal (CSI-RS), a positioning reference signal (PRS), a sidelink reference signal (RS)), (ii) a global navigation satellite system (GNSS) signal, (iii) an unlicensed carrier, (iv) an ultra-wideband signal, (v) a light detection and ranging (LIDAR) signal, (vi) a visual signal, etc.

[0218] In another example, the WTRU may perform measurements of any of the radio link interfaces associated with the WTRU (e.g., Uu link, SL).

[0219] For example, the WTRU may trigger the transmission and / or measurement of reference signals in one or more other WTRUs (e.g., via the Uu link and / or the sidelink).

[0220] For example, performing measurements and reporting actions may include sending measurement report information to the network and / or another WTRU.

[0221] In a second example, the WTRU action may correspond to the processing / transfer of data / PDU / PDU set and the processing of QoS associated with the PDU / PDU set.

[0222] For example, the data may include any of media (e.g., images, video frames), sensor data, and measurement data (e.g., attitude measurements, link / channel measurements) determined by the WTRU to support, for example, application / service / network requirements associated with the WTRU.

[0223] For example, a WTRU may send and / or receive data to / from one or more destinations including a RAN node (e.g., a gNB), a CN function / entity, an application function (e.g., hosted in the WTRU or in the network).

[0224] For example, a WTRU may send and / or receive data including user plane and / or control plane data to / from a source and / or a target when, for example, it is configured to perform a DAPS handover and / or when it is configured with one or more DAPS radio bearers. In one example, such UL transmission and / or DL reception may be performed by the WTRU one at a time via a source or a target. In another example, such UL transmission and / or DL reception may be performed by the WTRU at the same time (e.g., simultaneously) via a source and a target (e.g., both).

[0225] For example, a WTRU may perform either splitting and merging of data and / or PDUs within one or more QoS flows into one or more transfer configurations during transmission and / or reception.

[0226] In a third example, a WTRU action may correspond to processing / transferring information related to connectivity with the network and / or other WTRUs.

[0227] For example, a WTRU action may include sending to the network capability information indicating either the ability to support one or more interfaces, e.g., the ability to cooperate and / or interact with other WTRUs / devices (e.g., via an SL interface) which may or may not be collocated with the WTRU.

[0228] For example, a WTRU action may include receiving configuration information including receiving RRC configuration information from a gNB and / or NAS layer configuration information from a CN.

[0229] For example, a WTRU action may include sending and / or receiving assistance data associated with any of traffic, QoS, scheduling, etc. to support UL / DL transmission to / from the network.

[0230] For example, a WTRU action may include sending a request for wireless resources and / or resource grants (e.g., either dynamic grants, semi-static / configured grants).

[0231] For example, a WTRU action may correspond to triggering HO and data transmission / reception during HO.

[0232] For example, a WTRU action may include determining whether and when to trigger an initial access to a target.

[0233] For example, a WTRU action may include sending or receiving an initial access message to a target during HO execution.

[0234] For example, a WTRU action may include receiving an RRC message (e.g., HO command) from a source.

[0235] For example, a WTRU action may include sending an RRC message (e.g., RRC reconfiguration complete) to a target.

[0236] For example, a WTRU action may include determining whether to send any UL data (e.g., PDU set, data burst) to a source and / or a target.

[0237] For example, a WTRU action may include determining whether and when to release a connection to a source.

[0238] Aspects related to the mapping of PDU sets to bearers, logical channels, etc.

[0239] The PDU set may include another PDU.

[0240] For example, the PDU set may include a PDU corresponding to one type of frame (e.g., an I-frame), for example, only to that frame. In another example, the PDU set may include PDUs corresponding to different types of frames (such as I-frames, P-frames, B-frames, etc.).

[0241] The size of the PDU set may be variable for each PDU set.

[0242] The PDU set delay budget (PSDB) may be the time from the reception of the first PDU of the PDU set in the WTRU (e.g., from the application layer) until the last packet of the PDU set can be received in the network (e.g., a base station or UPF) and / or the application server.

[0243] The time to live (TTL), which may be referred to as the remaining delay for the PDU set (e.g., related to the PSDB), may be equal to the total time elapsed since the first PDU of the PDU set could arrive (e.g., be stored) in the WTRU transmission buffer, minus the PSDB.

[0244] In some examples, the PDUs within the PDU set may have different characteristics (e.g., type, importance), and it may be desirable to determine a path for the PDUs of the PDU set based on the combination of characteristics (e.g., type, importance, etc.) of the PDUs within the PDU set. For example, the WTRU may be able to determine or estimate the characteristics of different PDUs within the PDU set at the start of the first PDU of the PDU set (e.g., based on information from the application layer and / or based on information regarding the header of the first PDU or the first few PDUs at the start of the first PDU set).

[0245] For example, a data burst may include a set of PDUs with different characteristics (e.g., any of different types, sizes, importance levels, PSDB, etc.), and it may be desirable to determine a path for the data burst based on the combination of characteristics of the set of PDUs. For example, a WTRU may be able to determine or estimate the characteristics of different PDU sets within a data burst at the start of the first PDU set within the data burst (e.g., based on information from the application layer and / or based on information regarding the header of the first PDU or the first few PDUs at the start of the first PDU set).

[0246] During UL transmission, a WTRU may perform mapping of data units (e.g., any of PDUs, PDU sets, data bursts) received from an upper layer (e.g., an application) in one or more QoS flows (e.g., QoS flow identifier (QFI)) to one or more transfer configurations including different combinations of DRBs and / or LCHs.

[0247] Figures 4A and 4B are diagrams showing six examples of transfer configurations in the AS layer for mapping XR data units during UL transmission.

[0248] In one example related to the first configuration 41, the WTRU may receive one or more PDUs associated with a first PDU set 411 and a second PDU set 412 at a first QFI QFI1 and a second QFI QFI2, respectively. The received PDU sets may be mapped to a first DRB (e.g., PDCP1) and a second DRB (e.g., PDCP2) in the SDAP sublayer / entity. For example, (e.g., each) PDCP entity (e.g., PDCP1 and PCDP2) may be configured to support in-order delivery of PDUs in the first PDU set 411 and the second PDU set 412, respectively. The PDUs of the first PDU set 411 and the second PDU set 412 may be mapped to a first LCH LCH1 and a second LCH LCH2, respectively, corresponding to RLC1 and RLC2, for example. The MAC entity / sublayer may ensure that the QoS of the PDU sets 411, 412 (e.g., PSDB) in each LCH matches, for example, during scheduling and / or multiplexing of one or more TBs of the PDU sets 411, 412 for UL transmission, based on, for example, PDU set parameters (e.g., priority) and / or using LCP procedures.

[0249] In one example related to the second configuration 42, the WTRU may receive one or more PDUs associated with a first PDU set 421 and a second PDU set 422 at a first QFI QFI1 and a second QFI QFI2, respectively. The received PDU sets 421, 422 may be multiplexed / mapped to a DRB (e.g., PDCP) in the SDAP sublayer / entity. The PDUs of the first PDU set 421 and the second PDU set 422 may be mapped to an LCH corresponding to RLC, for example. The MAC entity / sublayer may ensure that the QoS of the PDU sets 421, 422 (e.g., PSDB) in the LCH matches, for example, during scheduling and / or multiplexing of one or more TBs of the PDU sets 421, 422 for UL transmission, based on, for example, PDU set parameters (e.g., priority, SN) and / or using LCP procedures.

[0250] In one example related to the third configuration 43, the WTRU may receive one or more PDUs associated with a first PDU set 431 and a second PDU set 432 at a first QFI QFI1 and a second QFI QFI2, respectively. The received PDU sets 431, 432 may be mapped to a DRB (e.g., PDCP) in the SDAP sublayer / entity. The PDUs of the first PDU set 431 and the second PDU set 432 may be mapped to a first LCH LCH1 and a second LCH LCH2, respectively, corresponding to a first RLC RLC1 and a second RLC RLC2, for example. The MAC entity / sublayer may ensure that the QoS of the PDU sets 431, 432 (e.g., PSDB) in each LCH matches, for example, based on PDU set parameters (e.g., priority) and / or using LCP procedures during scheduling and / or multiplexing of one or more TBs of the PDU sets 431, 432 for UL transmission.

[0251] In another example related to the fourth configuration 44, the WTRU may receive one or more PDUs associated with a first PDU set 441 and a second PDU set 442 at QFI QFI1. The received PDU sets 441, 442 may be mapped to a DRB (e.g., PDCP) in the SDAP sublayer / entity. The PDUs of the first PDU set 441 and the second PDU set 442 may be mapped to an LCH corresponding to RLC, for example. The MAC entity / sublayer may ensure that the QoS of the PDU sets 441, 442 (e.g., PSDB) in the LCH matches, for example, based on PDU set parameters (e.g., priority) and / or using LCP procedures during scheduling and / or multiplexing of one or more TBs of the PDU sets 441, 442 for UL transmission.

[0252] In another example related to the fifth configuration 45, the WTRU may receive one or more PDUs associated with a first PDU set 451 and a second PDU set 452 at QFI QFI1. The received PDU sets 451, 452 may be mapped to a DRB (e.g., PDCP) in the SDAP sublayer / entity. The PDUs of the first PDU set 451 and the second PDU set 452 may be mapped to a first LCH LCH1 and a second LCH LCH2, corresponding to RLC1 and RLC2 respectively. The MAC entity / sublayer may ensure that the QoS of the PDU sets 451, 452 (e.g., PSDB) in each LCH matches, for example, during scheduling and / or multiplexing of one or more TBs of the PDU sets 451, 452 for UL transmission, based on, for example, PDU set parameters (e.g., priority), and / or using LCP procedures.

[0253] In one example related to the sixth configuration 46, the WTRU may receive one or more PDUs associated with a first PDU set 461 and a second PDU set 462 at QFI QFI1. The received PDU sets 461, 462 may be mapped to a first DRB DRB1 (e.g., PDCP1) and a second DRB DRB2 (e.g., PDCP2) in the SDAP sublayer / entity. Each PDCP entity (e.g., PDCP1 and PCDP2) may be configured to support in-order delivery of the PDUs in the first PDU set 461 and the second PDU set 462 respectively. The PDUs of the first PDU set 461 and the second PDU set 462 may be mapped to a first LCH LCH1 and a second LCH LCH2, corresponding to RLC1 and RLC2 respectively. The MAC entity / sublayer may ensure that the QoS of the PDU sets 461, 462 (e.g., PSDB) in each LCH matches, for example, during scheduling and / or multiplexing of one or more TBs of the PDU sets 461, 462 for UL transmission, based on, for example, PDU set parameters (e.g., priority), and / or using LCP procedures.

[0254] Examples of BSRs related to one or more PDU sets

[0255] A BSR triggered according to any embodiment described herein may be a legacy BSR. For example, the BSR may include information on LCGs and corresponding buffer levels. The WTRU may be configured to ensure that an LCG corresponding to a PDU set that may have triggered the BSR can be included in the BSR. For example, if the PDCP of a bearer containing the PDU set is associated with LCHx and this LCHx is mapped to LCGy, information about LCGy may be included in the BSR. When determining the buffer level for reporting in the BSR, the WTRU may be configured to consider the buffered data (e.g., only that data) of the PDU set that may have triggered the BSR. For example, non-XR traffic mapped to an LCH that may be mapped within the same LCG as XR traffic that may have triggered the BSR may not be counted in the buffer calculation. In another example, XR traffic belonging to an XR traffic that is mapped to the same LCG and has no possibility of triggering the BSR may not be counted in the buffer calculation.

[0256] Depending on the available UL grant, the WTRU may include information about other LCGs (e.g., LCGs that may not have XR traffic, e.g., LCGs to which the PDU sets may not be mapped, or LCGs that include XR traffic other than the XR traffic that may have generated the BSR).

[0257] A BSR triggered according to any embodiment described herein may use a (e.g., new) BSR format (e.g., of the reporting information / message), and the BSR format may include information about PDU sets rather than just information at the LCG level (e.g., only that information). For example, the BSR may include information indicating one or more of the following elements.

[0258] For example, the BSR may indicate PDU set identification information.

[0259] For example, the BSR may indicate the PDU set importance level.

[0260] For example, the BSR may indicate the PDU set type.

[0261] For example, the BSR may or may not indicate a PDU set integration handling instruction (PSIHI) (e.g., indicating whether all PDU(s) of the PDU set can be received at the receiver application layer before the PDU set can be decoded / used).

[0262] For example, the BSR may indicate the PDU set PSDB.

[0263] For example, the BSR may indicate the PDU set TTL (e.g., at the time of construction of the BSR).

[0264] For example, the BSR may indicate the total PDU set size (e.g., either the number of PDUs, the size in bytes, etc.).

[0265] For example, the BSR may indicate the size of the buffered data of the PDU set in the WTRU (e.g., radio) buffer (e.g., either as an absolute value, as a percentage of the total PDU set size, in bytes, in number of PDUs, etc.).

[0266] For example, the BSR may indicate the size of the data of the PDU set that may still be pending in the application layer (e.g., either as an absolute value, as a percentage of the total PDU set size, in bytes, in number of PDUs, etc.). For example, the BSR may indicate one or more time window / size values indicating the expected size of the data and the time window within which the data is expected to become available at the WTRU.

[0267] Information about any of importance level, type, PSDB, TTL, and PDU set size may be either a (e.g., actual) value or an index value that can be used to refer to one or more values. For example, the PSDB may be classified into n categories (e.g., 0 if the PSDB is less than x1, 1 if the PSDB is between x1 and x2,..., n if the PSDB is greater than xn), and the BSR may include an index n (e.g., only that) associated with the PSDB.

[0268] Different BSR buffer size index tables for different PDU set characteristics (e.g., a first table for a first type of PDU set, a second table for a second type of PDU set, etc.) may be configured. Considering that PDU sets may have different ranges of PDU set sizes depending on their characteristics, it may not be efficient to determine the size of the BSR report to include the maximum possible PDU size regardless of the PDU set characteristics.

[0269] The BSR related to a PDU set may include information (e.g., only that) about one PDU set or two or more PDU sets (e.g., based on UL grants).

[0270] The WTRU may be configured to send the BSR of one or more PDU sets using an RRC message instead of using a MAC CE to send the BSR of one or more PDU sets. By sending buffer related information via RRC instead of a MAC CE, it may be possible to include more detailed information, for example, when the BSR is for multiple PDU sets and / or when additional information to buffer level information should be included.

[0271] SR mode

[0272] If the WTRU determines that conditions for triggering a BSR may be satisfied through embodiments described herein, and there may be no available UL resources for sending the BSR, the WTRU may trigger an SR (i.e., as in legacy NR operation).

[0273] The SR that may be sent based on a BSR related to a PDU set triggered according to any embodiment described herein may be different from the SR sent based on a legacy BSR. For example, different SR resources may be configured (e.g., associated) for different types of PDU set-related BSRs and BSR trigger conditions / causes (e.g., so that the network may be implicitly notified from the resources where the SR may be sent about what type of PDU set this BSR may be referring to and what may have caused the trigger of the BSR, etc.). In one example, the WTRU may be configured with periodic physical uplink control channel (PUCCH) resources for sending SRs periodically, in which case the configured periodicity value of the physical uplink shared channel (PUSCH) resources may be associated with one or more periodicity values of XR traffic (e.g., periodic PDU sets).

[0274] Periodic BSR and Periodicity of PDU Sets

[0275] In one embodiment, the WTRU may be configured to send periodic BSR reports regarding one or more PDU sets. For example, the WTRU may be configured to send BSR reports for every nth PDU, for a certain PDU set type, importance, or PSDB range, etc.

[0276] In one example, the periodic BSR may be configured with a periodicity that matches the periodicity of the ongoing set of PDUs (e.g., may be equal to the PDU set periodicity or a multiple thereof). When two or more PDU sets with different periodicities (e.g., periodicity 1, periodicity 2, periodicity 3, etc.) are ongoing, the WTRU may be configured to send a periodic BSR with a periodicity equal to any of the maximum periodicity, minimum periodicity, average / median periodicity, etc. of the periodicities of the PDU sets. For example, the WTRU may be configured to use the periodicity of any PDU set such as the PDU set with the highest importance, a certain type of PDU set, etc.

[0277] Network-triggered BSR for one or more PDU sets

[0278] The embodiments described herein focus on BSRs that are triggered based on one or more conditions monitored by the WTRU. In other examples, the network may explicitly request a BSR (and / or other PDU set related information) from the WTRU. For example, the network may request the WTRU to send information and buffer status about one or more PDU sets.

[0279] For example, the network may send a request to the WTRU to send information indicating the buffer level of a PDU set and / or additional information (e.g., indicating any of type, importance, PSDB, etc.) by explicitly indicating the PDU set identification information. In another example, the network may be able to indicate a PDU sequence number (e.g., only that), and the WTRU may be able to implicitly determine the PDU set from that number (e.g., the WTRU may be able to send information about the PDU set to which the indicated PDU may belong).

[0280] In this specification, embodiments have been described using examples of BSR / SR triggers. Automatically and / or in response to a request from the network, any information (e.g., either dynamic information indicating in reservation (e.g., the size of an in-progress buffer) and static or semi-static information indicating, e.g., a PDU set type or importance) sent by the WTRU for a PDU set using signaling in any protocol layer (e.g., any of uplink control information (UCI), MAC CE, RRC, ...) may be applicable to the embodiments described herein.

[0281] The WTRU may be configured with behavior that depends on either the active bearer and / or the application type. For example, the WTRU may be configured to apply any behavior according to any of the embodiments described herein when there is an active VR application and to apply legacy behavior otherwise. In another example, the WTRU may be configured to apply the behavior according to any of the embodiments described herein when there is any active XR traffic (e.g., any of AR, VR, MR, etc.). In another example, the WTRU may be configured to limit the operation according to any of the embodiments described herein to PDU sets and / or data bursts (e.g., only those) belonging to one or more bearers and / or LCHs and / or application types (e.g., any of AR, VR, MR, etc.).

[0282] In this specification, embodiments have been described using examples of enhancements related to XR applications and / or bearers. The embodiments described herein may be equally applicable to any type of service (e.g., application) when there may be interdependence between PDUs, when the PDUs of a bearer may be of different types (e.g., importance), when bursts of related PDUs may be received in burst units or semi-periodically, etc. The embodiments described herein with respect to PDU sets, data bursts, frames, etc. may be applicable (e.g., mapping) to the behavior of such types of services / applications / traffic.

[0283] BSR trigger based on conditions associated with PDU set delivery

[0284] For example, the conditions associated with PDU set delivery may be based on either the remaining time for delivery of the PDU set and / or the amount of unprocessed data for the PDU set.

[0285] In one embodiment, the WTRU may be configured to trigger BSR / SR when at least one parameter associated with transmission of a PDU set satisfies a condition. For example, the WTRU may be configured to trigger BSR / SR when the TTL for a PDU set is below a (e.g., configured) duration (e.g., threshold) and the amount of unprocessed data for the PDU set exceeds a buffer size (e.g., threshold).

[0286] For example, in a first step, the WTRU may receive a configuration (e.g., configuration information indicating it) for sending a buffer status report (BSR) or scheduling request (SR) related to a PDU set, in which case the BSR / SR may be triggered when one or more of the following conditions are satisfied.

[0287] In a first example, the BSR / SR may be triggered when the amount of unprocessed (e.g., buffered) data for the PDU set (e.g., any of the number of PDUs, data size in bytes, percentage of PDUs, etc.) exceeds a (e.g., configured) buffer size (e.g., threshold).

[0288] In a second example, the BSR / SR may be triggered when the TTL for the PDU set is below a (e.g., configured) duration (e.g., threshold).

[0289] For example, in a second step, the WTRU may monitor either the size of the PDU set in the UL buffer and / or the TTL of the PDU set (e.g., of the LCG associated therewith).

[0290] For example, in the third step, if it is determined that the buffered size of the PDU in the PDU set waiting for transmission exceeds the buffer size (e.g., a threshold value), or / and the TTL is less than the duration (e.g., a threshold value), the WTRU may transmit a BSR / SR related to the PDU set.

[0291] Example of BSR trigger based on TTL and / or buffered level

[0292] In one embodiment, the WTRU may be configured (e.g., may receive configuration information indicating to trigger) to trigger a BSR when a first (e.g., time) condition is satisfied (e.g., when the TTL of the PDU set is less than a first threshold value). This first threshold value may be referred to as TTL_threshold herein. The first threshold value to be used to trigger BSR / reporting information related to the PDU set (e.g., the LCG associated therewith) may be indicated in the configuration information received by the WTRU. The configuration information (e.g., received by the WTRU) may indicate the PSDB to be used to calculate the TTL of the PDU set so that the TTL can be compared with the first threshold value to trigger BSR / reporting information related to the PDU set.

[0293] In one example, the TTL_threshold may be an absolute duration value (e.g., 5 milliseconds).

[0294] In another example, the TTL_threshold may be a percentage of the PSDB of the PDU set (e.g., 25% of the PSDB).

[0295] In one embodiment, the WTRU may be configured to trigger a BSR when a second (e.g., buffer) condition is satisfied (e.g., when the amount of buffered data for its set of PDUs (e.g., in any of PDCP, RLC, MAC) exceeds a second threshold). This second threshold may be referred to herein as buffer_threshold. The second threshold to be used to trigger BSR / reporting information related to the PDU set may be indicated in the configuration information received by the WTRU.

[0296] In one example, buffer_threshold may be an absolute value (e.g., 500 Kbytes).

[0297] In another example, buffer_threshold may be a percentage of the PDU set size (e.g., 25% of the total PDU set size, 40% of the PDUs in the PDU set, etc.).

[0298] In one embodiment, the WTRU may be configured with one or more condition parameters (e.g., related to one or more conditions) such as, for example, TTL_threshold and buffer_threshold. The WTRU may be further configured to trigger a BSR when it determines that at least one of the conditions (e.g., thresholds) is met.

[0299] In one embodiment, the WTRU may be configured with at least two condition parameters (e.g., related to at least two conditions) such as, for example, TTL_threshold and buffer_threshold. The WTRU may be further configured to trigger a BSR when it determines that at least two conditions (e.g., both thresholds) are met.

[0300] In one embodiment, the WTRU may be configured with a plurality of TTL_threshold values and buffer_threshold values (e.g., a first (e.g., high) TTL threshold corresponding to a first (e.g., high) buffer threshold, and a second (e.g., low) TTL threshold corresponding to a second (e.g., low) buffer threshold).

[0301] In one embodiment, the configuration of the plurality of TTL_threshold values and buffer_threshold values may be explicit. For example:

[0302] buffer_threshold1 = 20%, TTL_threshold1 = 30%

[0303] buffer_threshold2 = 50%, TTL_threshold2 = 50%

[0304] buffer_threshold3 = 85%, TTL_threshold3 = 70%,

[0305] etc.

[0306] In one embodiment, the WTRU may be configured with a relationship between condition parameters associated with different conditions (e.g., TTL_threshold and buffer_threshold). For example, if the (e.g., both) thresholds are percentage values, the WTRU may be configured to apply a linear mapping between the two thresholds, e.g., TTL_threshold = alpha * buffer_threshold. For example, if alpha is equal to 1, the WTRU may trigger a BSR when x% (e.g., only x%) of the PSDB remains and the WTRU is buffering more than x% of the PDU set. In another example, if alpha is equal to 2, the WTRU may trigger a BSR when x% (e.g., only x%) of the PSDB remains and the WTRU is buffering more than 0.5x% of the PDU set, etc. Further constraints may be configured to ensure that such behavior may be valid only when (e.g., only if) the TTL_threshold falls below a certain value. For example, the WTRU may be configured to apply the mapping only when (e.g., only if) the TTL_threshold is below 40% (e.g., the BSR cannot be triggered before 60% of the PSDB has elapsed).

[0307] In one solution, the buffer size that may be compared to the buffer_threshold by the WTRU may be the amount of PDU set data that may already be available in the WTRU (radio protocol level) buffer (e.g., PDCP and / or RLC and / or MAC, etc.).

[0308] In one embodiment, the buffer size that can be compared by the WTRU to the buffer_threshold may consider (e.g., may include) PDUs of a set of PDUs that may not yet be available (e.g., not stored) in the WTRU (radio protocol level) buffer (such as PDCP and / or RLC and / or MAC, etc.). For example, the WTRU may become notified about the size of the set of PDUs (e.g., from header information within a first PDU received from the application layer), and the WTRU may determine the current buffer level by subtracting the amount (e.g., number) of data (e.g., PDUs) of the set of PDUs that may already have been sent from the total set of PDU sizes.

[0309] In one embodiment, the WTRU may be configured to check (e.g., determine) how many or what percentage of the PDUs of the set of PDUs may still be pending (e.g., in the WTRU buffer) for transmission (e.g., still) when the PDU is received from the application layer, and if that amount is greater than a threshold, the WTRU may trigger a BSR.

[0310] In one embodiment, the WTRU may be configured to send a BSR related to the set of PDUs if a certain percentage / number of the PDUs of the set of PDUs are buffered in the WTRU and a BSR related to the set of PDUs cannot be sent.

[0311] Control of the number of BSRs sent

[0312] In one embodiment, the WTRU may be configured to trigger a BSR related to (e.g., associated with) a set of PDUs if a previous BSR related to (e.g., associated with) the set of PDUs, triggered according to any of the embodiments described herein, was not triggered before (e.g., within) a prohibited duration. For example, if the prohibited duration is set to infinity, the BSR related to the set of PDUs may be sent only once, for example.

[0313] In one embodiment, the WTRU is configured to trigger a BSR related to (e.g., associated with) a PDU set when the TTL and / or buffer level changes beyond a certain value (e.g., either a quantity or a percentage value) after a previous BSR related to (e.g., associated with) the PDU set has been triggered according to any of the embodiments described herein. For example, the WTRU may be configured to send a BSR related to (e.g., associated with) a PDU set when the TTL drops below 40% and the buffer remains above 50%. The WTRU may be further configured to send a subsequent BSR related to (e.g., associated with) the same PDU set when the TTL drops below 10% and the buffer remains above 30%, etc.

[0314] In one embodiment, the WTRU is configured not to trigger a BSR related to (e.g., associated with) a PDU set during a prohibited duration after a BSR has been triggered based on a legacy BSR trigger mechanism when the BSR contains information about an LCG with which the PDU set may be associated and the PDU set was already in progress when the legacy BSR could have been sent (e.g., some PDUs of the PDU set were already buffered in the WTRU). In one variation of this embodiment, instead of a prohibited time, the limitation may relate to an increase in the buffer level after the transmission of the legacy BSR. For example, the WTRU may be configured to trigger a BSR related to (e.g., associated with) a PDU set after a legacy BSR when more data than a certain amount (e.g., a percentage or an absolute value) of the PDU set is buffered in the WTRU.

[0315] Aspects related to PDU set characteristics

[0316] In one embodiment, the WTRU may be configured to apply the behavior according to any of the embodiments described herein to any PDU set (regardless of PDU set characteristics such as, for example, PDU set type, importance level, PSDB range, etc.).

[0317] In one embodiment, the WTRU may be configured to apply the behavior according to any of the embodiments described herein to a PDU set of one or more characteristics, for example, to a PDU set of a certain importance level (e.g., only to), and / or to a PDU set of a certain type (e.g., only to), and / or to a PDU set of a certain PSDB value (or range) (e.g., only to), and / or to a PDU set of a certain size (e.g., the number of PDUs within a PDU set exceeding a certain value) (e.g., only to).

[0318] In one embodiment, the WTRU may be configured to apply either different thresholds and different behaviors depending on the characteristics of the PDU set. For example, the buffer level and / or TTL threshold that may be used to trigger a BSR for a PDU set of any of a first importance level, a first type, and a first PSDB may be different from those for a PDU set of any of a second importance level, a second type, and a second PSDB. Other parameters such as the prohibited timer described herein may be configured for each of the PDU set type, PDU set type importance, and PDU set PSDB.

[0319] Aspects related to multiple ongoing PDU sets

[0320] For example, there may be multiple ongoing (e.g., pending) PDU sets.

[0321] In one embodiment, the WTRU may monitor the BSR trigger conditions for (e.g., each) PDU independently from other PDU sets (and may also trigger the BSR independently if the conditions are met for a PDU set).

[0322] In one embodiment, the WTRU may monitor BSR trigger conditions for one or a subset (e.g., only that one) of the PDU sets based on, for example, (i) importance level (e.g., monitoring / triggering the BSR for the set of PDUs having the highest importance), (ii) PDU set type (e.g., monitoring / triggering the BSR for the I-frame PDU set), (iii) PDU sets having a PSDB smaller / larger than a certain value, (iv) PDU sets having a size larger / smaller than a certain value, etc.

[0323] In one embodiment, the WTRU may trigger a BSR based on any of the embodiments described herein, and the WTRU may include information about one (e.g., only that one) of the PDU sets that meet a certain condition (e.g., the PDU set having the highest importance, time, etc.) and / or information about two or more of the PDU sets that meet a certain condition (e.g., the PDU set having an importance level above a certain level, the PDU set having a TTL below a certain level, etc.). The decision to include information about one or more PDU sets may further depend on the UL grant information received by the WTRU. For example, if the UL grant information is associated with a large number of resources, the WTRU may include information about (e.g., all) the PDU sets, and if the UL grant information is associated with a smaller number of resources, the WTRU may include information about the PDU sets that meet a certain condition, e.g., the PDU set having the highest importance, the shortest PSDB / TTL, etc. (e.g., only that one).

[0324] In one embodiment, a prohibit timer that may be started when a BSR related to (e.g., associated with) a PDU set is sent may prevent the transmission of subsequent BSRs related to (e.g., associated with) any PDU set.

[0325] In one embodiment, a prohibition timer that may be started when a BSR related to (e.g., associated with) a PDU set can be sent may prevent the transmission (e.g., only the transmission) of a subsequent BSR related to (e.g., associated with) the same PDU set.

[0326] In one embodiment, a prohibition timer that may be started when a BSR related to (e.g., associated with) a PDU set can be sent may prevent the transmission (e.g., only that) of a subsequent BSR related to (e.g., associated with) a PDU set having a QoS expectation value (e.g., requirement) (e.g., any of a longer PSDB, lower importance, etc.) below the PDU set that may have triggered the BSR.

[0327] BSR Trigger Based on Available Information Related to PDU Set

[0328] In one embodiment, a WTRU may be configured to trigger one or more BSRs / SRs related to a PDU set depending on information available to the WTRU about the PDU set. For example, the WTRU may receive configuration information indicating (e.g., triggering) that it reports PDU set related information regarding uplink traffic based on, for example, the fact that information related to the PDU set is available and / or changes over time.

[0329] In a first example, after the arrival of a PDU in a PDU set (e.g., any one of a first PDU, an intermediate PDU, a last PDU), the WTRU may trigger a BSR / SR related to the PDU set if and only if the WTRU has (e.g., detailed) information about the PDU set (e.g., any one of the size of the PDU set (e.g., in terms of the number of PDUs), periodicity, PSDB, type, importance, etc.). The (e.g., detailed) information may be included in the PDU header. In another example, the (e.g., detailed) information may be made available to the WTRU (at the network layer) by the application layer. The WTRU may include (e.g., detailed) information about the PDU set in, for example, the BSR. In another example, reduced information such as either the size and the timing window when it can be expected that (e.g., all) data is available in the WTRU buffer may be provided.

[0330] In a second example, after the arrival of the first PDU of a PDU set, the WTRU may trigger a first BSR / SR related to the PDU set (e.g., including initial / first information) if at that time the WTRU does not have (e.g., detailed) information about the PDU set (e.g., the PDU may not contain detailed information, or the WTRU may not have obtained (e.g., detailed) information from the application layer). The WTRU may include, for example, "expected" data size / timing information in this first BSR. If (e.g., detailed) information about the PDU set becomes available later (e.g., the WTRU may receive an intermediate PDU that may contain (e.g., detailed) information, may receive the last PDU of the PDU set having (e.g., detailed) information, etc.). The WTRU may send a second BSR / SR related to the PDU set that may include correct (e.g., updated) size / timing information. The BSR / SR may include reduced (e.g., summarized) information indicating a request for, for example, more / less resources, a preferred timing window for resource availability to reduce / increase, etc.

[0331] In one embodiment, the WTRU may be configured to trigger a BSR related to (e.g., associated with) a PDU set if (e.g., only if) information about the PDU set is available (e.g., becomes available). The PDU set information may indicate one or more of: (i) PDU set identification information (ID), (ii) PDU set importance level, (iii) PDU set type, (iv) PSDB, (v) size (e.g., either in bytes or number of PDUs), (v) the first and / or last PDU of the PDU set (e.g., via start / end indication), (vi) the time (e.g., either relative or absolute) at which (e.g., all) PDUs of the PDU set are expected to be available in the WTRU (radio level) buffer, and (vii) PSIHI indicator.

[0332] In one example, the PDU set information may become available at the WTRU before the first PDU of the PDU set can be received in the WTRU buffer (e.g., information about a future PDU set can be received from the application layer).

[0333] In another example, the PDU set information may become available at the WTRU when the first PDU of the PDU set can be received in the WTRU buffer (e.g., in the packet header or as separate information).

[0334] In another example, the PDU set information may become available at the WTRU when an intermediate PDU of the PDU set can be received in the WTRU buffer (e.g., in the packet header or as separate information).

[0335] In another example, the PDU set information may become available at the WTRU when the last PDU of the PDU set can be received in the WTRU buffer (e.g., in the packet header or as separate information). The PDU size information may be implicitly determined by the WTRU if there is an indication that this can be the last PDU of the PDU set.

[0336] In another example, the PDU set information may become available at the WTRU after the last PDU of the PDU set has been received.

[0337] One or more PDU set information may be implicitly determined from other information (e.g., (i) mapping between PDU set type / importance and QoS flow identifier, (ii) mapping of PDU set PSDB to PDU set type / importance, (iii) mapping of PDU set importance to PDU set type, etc., (iv) any of the interrelationships or dependencies between PDU sets in different correlated flows).

[0338] In one embodiment, the WTRU may be configured to trigger a BSR related to (e.g., associated with) the PDU set when the first PDU of the PDU set is received (e.g., whether limited information (e.g., only that) about the PDU set is available at that time or detailed information is not available).

[0339] In one embodiment, triggering the BSR upon receipt of the first PDU of the PDU set may be conditional on the WTRU recognizing at least one of the following: (i) PDU set type (e.g., the BSR may be triggered upon receipt of the first PDU of a certain (e.g., given) type of PDU set), (ii) PDU set importance (e.g., the BSR may be triggered upon receipt of the first PDU of a certain (e.g., given) importance PDU set), (iii) PSDB (e.g., the BSR may be triggered upon receipt of the first PDU of the PDU set when the PSDB is below a threshold (e.g., only in that case)), etc.

[0340] In one embodiment, the WTRU may be configured to trigger a BSR related to (e.g., associated with) the PDU set when the last PDU of the PDU set is received.

[0341] In one embodiment, the WTRU may be configured to trigger a BSR related to (e.g., associated with) a PDU set when one or more of the following conditions are not met when the last PDU of the PDU set is received. (i) The first PDU of the PDU set is still buffered in the WTRU, and (ii) either the percentage or the number of PDUs in the PDU set is still buffered in the WTRU.

[0342] In one embodiment, the WTRU may be configured to trigger a BSR related to (e.g., associated with) a PDU set when a percentage of the PDUs in the PDU set are received in the WTRU (radio) buffer (e.g., when 50% of the PDUs in the PDU set are received).

[0343] In an embodiment, if the WTRU has limited information (e.g., when the first PDU is received) about the PDU set that does not include size information, the WTRU may send the size information in another message (e.g., any of a MAC CE, an RRC message, a special SR, etc.) instead of, for example, the BSR.

[0344] In one embodiment, the WTRU may be configured to send a legacy BSR (e.g., an LCG level buffer level indication) when the WTRU has limited information or no detailed information about the PDU set.

[0345] In one embodiment, when the WTRU has limited information or no information about the size of the PDU set when the BSR can be triggered, the WTRU may include expected (e.g., predicted) size information in the BSR. For example, the WTRU may estimate the size based on the size of a previous PDU set having the same characteristics (e.g., any of a PDU set type, importance level, etc.).

[0346] In one embodiment, the WTRU may be configured to include timing information (e.g., a time window in which a set of PDUs (e.g., the whole set) can be expected to become available at the WTRU). In one example, the WTRU may include one or more size / timing information in one BSR (e.g., indicating that data of size x can be expected within time t1, additional data of size y can be expected within t2 after t1, etc.).

[0347] In one embodiment, the WTRU may trigger a first BSR related to (e.g., associated with) a set of PDUs having limited / first information about the set of PDUs, and the WTRU may later recognize detailed PDU set information. The WTRU may be configured to send a subsequent BSR that adds (e.g., modifies) information in the first BSR (e.g., previously sent). For example, information about the set of PDUs may be sent (e.g., in a subsequent / second BSR) based on the fact that the information about the set of PDUs has changed from the previous / first information previously / first reported (e.g., in the first BSR).

[0348] For example, when receiving a first PDU from the application layer, the WTRU may send a first BSR related to (e.g., associated with) the PDU set (e.g., the header may indicate the PDU set as an important PDU set). For example, the first BSR may not indicate size information, or the first BSR may indicate an estimated (e.g., expected) size and / or timing information. The WTRU may receive detailed information about the PDU set later. For example, the WTRU may receive an intermediate PDU of the PDU set that indicates the size of the PDU set. In another example, the WTRU may receive the last PDU of the PDU set, and the WTRU may recognize the PDU set size. In another example, the WTRU may receive separate information about the size of the PDU set from the application layer. For example, the WTRU may be able to send an updated BSR that can include detailed information. In one example, the updated BSR may indicate a reference to a previous BSR (e.g., the BSR may indicate either a BSR ID or a counter), and may include delta / full information (e.g., total size information of the PDU set, the difference between the previously indicated size and the newly determined value, absolute timing information about the PDU set, the difference between the previously indicated timing information and the newly determined information, etc.).

[0349] In one embodiment, after determining detailed information about the PDU set, the WTRU may include either a special flag or an indicator in the header of the PDU of the PDU set that the WTRU may send, in order to indicate to the network that the WTRU may have detailed (e.g., complete) information about the PDU set. The network may send the WTRU information for requesting the WTRU to send detailed information about the PDU set (e.g., the WTRU may send the requested detailed information in any of a subsequent BSR, an RRC message, etc.).

[0350] In one embodiment, if the WTRU indicates a size in the first BSR that it can send that is different (e.g., smaller or larger) than the actual size of the PDU set, the WTRU may include information indicating the difference in the second BSR.

[0351] In one embodiment, after obtaining detailed information about the PDU set, if the WTRU determines that this detailed information is similar (e.g., corresponding) to the information provided in the first BSR (e.g., current size within a percentage of the size reported in the first BSR, data arrival timing having a percentage of the data arrival window shown in the first BSR, etc.), the WTRU may send information to confirm the first BSR that was sent along with the estimated information (e.g., any of size, data arrival timing (e.g., arrival time), etc.).

[0352] In one embodiment, the WTRU may be configured to apply one or more of the behaviors described herein based on PDU set characteristics.

[0353] For example, the WTRU may send a BSR on the first PDU of the PDU set if the PDU set is of an importance level equal to value x (e.g., only in that case).

[0354] For example, the WTRU may send a BSR on the first PDU of the PDU set for PDU sets of an importance level below value y if detailed information about the PDU set (e.g., all) is available upon receipt of the first PDU (e.g., only in that case).

[0355] For example, for one or more characteristics (e.g., type) of PDU, the WTRU may send a BSR upon receipt of the last PDU (e.g., only upon receipt).

[0356] For example, for one or more characteristics (e.g., type) of PDU, the WTRU may send a BSR after the detailed information about the PDU set becomes available (e.g., only after that).

[0357] For example, for a PDU of a certain type and / or importance level, the WTRU may send at most one BSR (e.g., the first PDU even if detailed information is not available at that time).

[0358] For example, the WTRU may not send a BSR for any set of PDUs of (e.g., a given) type, PSDB, size, importance level, etc.

[0359] For example, a BSR for a set of PDUs of (e.g., a given) type, PSDB, or size may be sent (e.g., only in that case) if there is space available for padding BSRs.

[0360] In one embodiment, the WTRU may be configured to trigger a subsequent BSR related to the PDU set when a (e.g., prohibited) duration has elapsed since a first BSR related to the PDU set was sent with (e.g., initial, limited, first) information. For example, if (e.g., detailed, subsequent, second) information becomes available, the WTRU may wait until the expiration of the prohibited duration before sending a subsequent (e.g., updated) BSR. For example, after sending (e.g., initial, limited, first) information about the PDU set in the first BSR, the WTRU may refrain from sending (e.g., detailed, subsequent, second, updated) information about the PDU set in the BSR for a (e.g., prohibited) duration. In a variant, this behavior may depend on the characteristics of the PDU set. For example, the WTRU may be configured to ignore the prohibited duration if one or more characteristics associated with the PDU triggering the BSR satisfy a certain condition (e.g., the PDU set is of importance level x, is of type y, has a PSDB less than z, etc.).

[0361] In one embodiment, the WTRU may be configured to trigger a subsequent BSR related to a PDU set if (e.g., only if) detailed information about the PDU set becomes available within a (e.g., given) duration after transmission of a first BSR related to the PDU set.

[0362] In one embodiment, the WTRU may be configured to apply any of the behaviors described herein to a PDU set having one or more characteristics (e.g., only to). For example, the WTRU may apply any of the behaviors described herein to a PDU set having (i) a certain importance level, (ii) a certain type, (iii) a certain PSDB value / range, (iv) a certain size (e.g., the number of PDUs within a PDU set exceeding a certain value), etc. (e.g., only to).

[0363] In one embodiment, the WTRU may have a plurality of ongoing (e.g., pending) PDU sets (e.g., to be transmitted). The WTRU may independently monitor the trigger conditions for subsequent BSRs for different PDU sets (and may independently trigger subsequent BSRs after detailed information about a (e.g., each) PDU set becomes available).

[0364] In one embodiment, the WTRU may have a plurality of ongoing (e.g., pending) PDU sets (e.g., to be transmitted). The WTRU may monitor the trigger conditions for subsequent BSRs for one or a subset of PDU sets (e.g., only that one) based on one or more of, for example, (i) importance level (e.g., monitoring / triggering a subsequent BSR for the PDU set having the highest importance), (ii) PDU set type (e.g., monitoring / triggering a subsequent BSR for an I-frame PDU set), (iii) a PDU set having a PSDB less than a certain value (e.g., only that one) may trigger a subsequent BSR, (iv) a PDU set having a size greater than a certain value (e.g., only that one) may trigger a subsequent BSR, etc.

[0365] In one embodiment, a WTRU may have a plurality of ongoing (e.g., pending) PDU sets (e.g., to be transmitted). The WTRU may trigger a BSR based on any of the embodiments described herein. The WTRU may include information about one of the PDU sets (e.g., the PDU set having the highest importance, a given time, etc.) (e.g., only that one), or information about two or more PDU sets that meet a certain condition (e.g., PDU sets having an importance level above a certain level, PDU sets having a TTL / PSDB below a certain threshold, etc.). The decision to include information about one or more PDU sets may further follow UL grant information received by the WTRU. For example, if the UL grant information is associated with a large number of resources, the WTRU may include information about two or more (e.g., all) PDU sets. If the UL grant information is associated with fewer resources, the WTRU may include information about a PDU set (e.g., only that PDU set) that meets a certain condition (e.g., having any of the highest importance, the shortest PSDB / TTL, etc.).

[0366] BSR Trigger Based on Certain Conditions

[0367] In one embodiment, the WTRU may be configured to trigger a BSR / SR based on either radio conditions or conditions related to ongoing PDU sets.

[0368] For example, the WTRU may receive a configuration (e.g., configuration information indicating it) for triggering a BSR / SR that depends on one or more of the following conditions.

[0369] In a first example of a condition, the BSR / SR may be triggered based on one or more radio conditions towards a source and / or a target.

[0370] In a second example of the condition, the BSR / SR may be triggered based on the remaining PDUs of the ongoing PDU set (e.g., either the number of ongoing PDU sets, the size of the remaining PDUs of the PDU set, etc.), in which case (i) all PDU sets may be considered, or (ii) only a part of the PDU sets (e.g., only some) may be considered (e.g., PDU sets of a certain type or importance, PDU sets with a PSDB below a threshold, PDU sets with a TTL below a threshold, PDU sets with a percentage / number of pending PDUs (e.g., only such PDU sets), etc.).

[0371] If any of the conditions are satisfied, the WTRU may send a BSR / SR to the network that includes information about the ongoing PDU set.

[0372] In one embodiment, the WTRU may be configured to trigger the BSR depending on one or more radio conditions.

[0373] For example, the WTRU may trigger the BSR if a cell radio quality metric (e.g., RSRP) associated with the current serving cell does not meet a quality condition (e.g., is below a threshold).

[0374] For example, the WTRU may trigger the BSR if a cell radio quality metric associated with the current serving cell does not meet a quality condition (e.g., is worse than a threshold by more than the quality metric of a neighbor cell).

[0375] For example, the WTRU may trigger the BSR if a quality metric associated with a neighbor serving cell meets a quality condition (e.g., becomes better than a threshold).

[0376] Any radio state associated with any quality metric associated with either the serving cell or a neighbor cell for triggering the BSR may be applicable to the embodiments described herein.

[0377] For example, any measurement event (e.g., A1 to A6, etc.) may be configured to trigger a BSR in addition to, or instead of, a measurement report.

[0378] In one embodiment, when the WTRU is sending a measurement report (e.g., also a measurement report), the buffer status information may be sent in an RRC message (e.g., within the measurement report and / or in a different RRC message, etc.). Sending buffer-related information via RRC may allow for including more detailed information compared to a MAC CE-based BSR.

[0379] In one embodiment, the BSR may be triggered according to one or more radio states, regardless of whether there is an ongoing PDU set and / or regardless of the amount of PDU set data that may be buffered in the WTRU.

[0380] In one embodiment, the BSR may be triggered when one or more (e.g., radio) conditions for triggering the BSR are satisfied and the (e.g., total) size of the buffered PDUs of an (e.g., all) ongoing PDU set satisfies a certain condition (e.g., exceeds / falls below a certain threshold (e.g., total_buffer_threshold)). The size and / or condition (e.g., threshold) may be either in bytes or in the number of PDUs.

[0381] In one embodiment, the buffer size compared to total_buffer_threshold may include PDUs of an (associated, ongoing) PDU set that may not yet be available in the WTRU (radio protocol level) buffer (e.g., PDCP and / or RLC and / or MAC, etc.). For example, the WTRU may be notified of the size of a PDU set (e.g., from header information within a first PDU received from the application layer), and the WTRU may determine the current total buffer level by subtracting the amount (e.g., number) of data (e.g., PDUs) of the PDU set that has already been sent from the total PDU set size.

[0382] In one embodiment, the WTRU may be configured with a set of radio conditions and buffer conditions (e.g., thresholds). For example, the WTRU may be configured to trigger a BSR according to any of the following examples.

[0383] In a first example, the WTRU may be configured to trigger a BSR when a radio quality metric (e.g., RSRP) associated with the serving cell is less than a first threshold (RSRP < RSRP_threshold_1) and the amount of buffered data is less than or equal to a first buffer threshold (total_buffer ≤ total_buffer_threshold_1).

[0384] In a second example, the WTRU may be configured to trigger a BSR when a radio quality metric (e.g., RSRP) associated with the serving cell is between a first threshold and a second threshold (e.g., RSRP_threshold_1 and RSRP_threshold_2) and the amount of buffered data is less than or equal to a second buffer threshold (e.g., total_buffer ≤ total_buffer_threshold_2).

[0385] In a third example, the WTRU may be configured to trigger a BSR when a radio quality metric (e.g., RSRP) associated with the serving cell is between a second threshold and a third threshold (e.g., RSRP_threshold_2 and RSRP_threshold_3) and the amount of buffered data is less than or equal to a third buffer threshold (e.g., serving cell RSRP between RSRP_threshold_2 and RSRP_threshold_3 and total_buffer ≤ total_buffer_threshold_3).

[0386] In an embodiment, a first type of PDU set (e.g., only that) may be included in the total buffer calculation that is compared to a threshold.

[0387] In one embodiment, a PDU set of a first importance level (e.g., only it) may be included in the total buffer calculation.

[0388] In one embodiment, a PDU set of PSDBs that satisfy a certain condition (e.g., a PSDB less than a certain threshold) (e.g., only it) may be included in the total buffer calculation.

[0389] In one embodiment, a PDU set of a first TTL (e.g., only it) (e.g., calculated when a BSR can be constructed) may be included in the total buffer calculation.

[0390] In one embodiment, a PDU set of a size that satisfies a certain condition (e.g., more / less than n PDUs, smaller / larger than x bytes, etc.) (e.g., only it) may be included in the total buffer calculation.

[0391] In one embodiment, separate (e.g., different) buffer condition parameters (e.g., total_buffer_threshold) may be configured for different PDU sets (e.g., any of different types, importance levels, PSDB ranges, size ranges, etc.), and these may be further associated with one or more radio condition thresholds (e.g., each). For example, a WTRU may be configured to trigger a BSR when either a radio condition or a buffer condition is satisfied for one of the PDU sets of any of type, importance level, PSDB range, etc. In another example, a WTRU may be configured to trigger a BSR when conditions are met for two or more (or only when met for all) of the PDU sets of any of type, importance level, PSDB range, etc.

[0392] In one embodiment, either a buffer level or a radio level condition parameter (e.g., a threshold) may be configured to be associated (e.g., be specific thereto) with a specific PDU set (e.g., identified by PDU set identification information (e.g., an identifier)).

[0393] In the embodiments described herein, the buffer-related threshold may be a percentage of the PDU set that can be buffered (corresponding) rather than the number of buffered PDUs (e.g., if PDU set size information is available).

[0394] In the embodiments described herein, the buffer-related threshold may be a percentage of the total size of the PDU set that can be buffered (corresponding) rather than the total buffer size of the PDU set (e.g., if PDU set size information is available).

[0395] In one embodiment, the BSR may include information about the PDU set that could have triggered the BSR (e.g., only that).

[0396] In one embodiment, the BSR may also include information about PDU sets that may not have triggered the BSR (e.g., based on UL grant available resource availability).

[0397] In one embodiment, the WTRU may be configured to trigger a BSR after (e.g., immediately after) recovery from an RLF (e.g., any of re-establishment, cell selection after RLF that leads to selection of a cell prepared by CHO, performing CHO after cell selection after RLF, etc.).

[0398] In one embodiment, the WTRU may be configured to trigger a BSR after (e.g., immediately after) performing a handover (e.g., any of legacy HO after receiving an HO command, performing DAPS HO, CHO, etc.).

[0399] In one embodiment, the WTRU may be configured to trigger a BSR after (e.g., immediately after) transitioning from an idle (e.g., either IDLE or INACTIVE) state (e.g., if the state transition was triggered based on the arrival of a UL PDU set of any of a first type, a first size, a first importance, etc.).

[0400] In one embodiment, the WTRU may be configured with a CHO configuration that consists of two radio conditions (e.g., thresholds), namely, a first radio threshold (e.g., neighbor cell > serving cell + thresh1) for triggering a BSR, and a second radio threshold (e.g., neighbor cell > serving cell + thresh2, where thresh2 > thresh1) for triggering the execution of a CHO. Conditions related to the buffer level may be applied together with (e.g., along with) the first radio threshold (e.g., the BSR may not be triggered if the buffer-related conditions (e.g., thresholds) are not met for the corresponding (e.g., ongoing) PDU set).

[0401] In one embodiment, the WTRU may be configured with a CHO configuration that includes a radio threshold (e.g., neighbor cell > serving cell + thresh1) and duration information. When the radio condition is met, the WTRU may trigger a BSR (e.g., when the buffer-related threshold for the corresponding (e.g., ongoing) PDU set is also met), and may wait (e.g., for the execution of a CHO) until the configured duration has elapsed after either the condition has been met or one or more of the PDU sets for which the BSR could be triggered have been successfully transmitted.

[0402] In an embodiment, for example, according to any of the embodiments described herein, the WTRU may receive a handover command that instructs (e.g., requests) the WTRU to perform a HO (e.g., immediately) if one or more buffer-related conditions for an ongoing PDU set are not met. In another example, if one or more buffer-related conditions for an ongoing PDU set are met, the WTRU may be configured to wait for a duration (e.g., as indicated in the HO command) before performing a HO and may send a BSR. The WTRU may perform the HO command after the configured duration has elapsed since the receipt of the HO command or after one or more of the corresponding PDU sets for which the BSR could be triggered have been successfully transmitted.

[0403] Figure 5 is a diagram illustrating an exemplary method 500 for transmitting buffer status report information. For example, method 500 may be implemented in a WTRU.

[0404] As shown at 510, the WTRU may determine that one or more (e.g., first) conditions associated with the transmission of one or more PDU sets (e.g., remaining time therefor) may be satisfied, in which case, for example, the PDU set may include two or more PDUs that may be associated with each other.

[0405] As shown at 520, based on determining that one or more (e.g., first) conditions may be satisfied, the WTRU may transmit first (e.g., buffer status) report information related to one or more PDU sets. In various embodiments, the report information may indicate the remaining time for the transmission of the PDU set and at least the size of the buffered data for the PDU set.

[0406] In various embodiments, one or more conditions may be satisfied when the amount of buffered data associated with one or more PDU sets to be transmitted by the WTRU satisfies a first condition.

[0407] In various embodiments, the first condition may be satisfied when the amount of buffered data to be transmitted by the WTRU exceeds a first threshold.

[0408] In various embodiments, the amount of buffered data that satisfies the first condition to be transmitted by the WTRU may include PDUs of different PDU sets, in which case, the PDUs of different PDU sets may be associated with the same characteristic.

[0409] In various embodiments, the same characteristic may include any of a certain same type, a certain same importance level, and a PSDB below a certain value.

[0410] In various embodiments, one or more conditions may be satisfied when the TTL associated with one or more PDU sets meets a second condition.

[0411] In various embodiments, the second condition may be satisfied when the TTL associated with one or more PDU sets is below a second threshold.

[0412] In various embodiments, one or more conditions may be satisfied when the first PDU of a PDU set is available for transmission by a WTRU.

[0413] In various embodiments, the WTRU may further transmit second (e.g., buffer status) reporting information indicating one or more characteristics associated with the PDU set.

[0414] In various embodiments, information indicating one or more characteristics associated with the PDU set may be available to the WTRU after the WTRU may have transmitted first (e.g., buffer status) reporting information.

[0415] In various embodiments, one or more conditions may be satisfied when one or more radio conditions towards either the source network element and the target network element are met.

[0416] In various embodiments, one or more radio conditions may be satisfied when the radio quality associated with the source network element is below a third threshold.

[0417] In various embodiments, one or more radio conditions may be satisfied when a first radio quality associated with the source network element is below a fourth threshold by a second radio quality associated with the target network element.

[0418] In various embodiments, one or more radio conditions may be satisfied when the radio quality associated with the target network element exceeds a fifth threshold.

[0419] In various embodiments, the WTRU may further receive configuration information indicating one or more conditions associated with the transmission of one or more PDU sets.

[0420] In various embodiments, the WTRU may receive first configuration information indicating a first condition associated with the remaining time for the transmission of a PDU set.

[0421] In various embodiments, the first condition may be satisfied when the remaining time for the transmission of the PDU set is below a first threshold.

[0422] In various embodiments, the first condition may be satisfied when the remaining time for the transmission of the PDU set is below a first threshold. In various embodiments, the first configuration information may indicate the first threshold.

[0423] In various embodiments, the WTRU may determine that a second condition associated with the size of buffered data may be satisfied, and the reporting information may be transmitted based on the determination that the second condition may be satisfied.

[0424] In various embodiments, the WTRU may receive second configuration information indicating a second condition associated with the size of buffered data.

[0425] In various embodiments, the second condition may be satisfied when the size of the buffered data exceeds a second threshold.

[0426] In various embodiments, the second condition may be satisfied when the size of the buffered data exceeds a second threshold. In various embodiments, the second configuration information may indicate the second threshold.

[0427] In various embodiments, the buffered data may include PDUs of different PDU sets, and the PDUs of different PDU sets may be associated with the same characteristics.

[0428] In various embodiments, the same characteristic may include any of the same type, the same importance, and a PSDB below a certain value.

[0429] In various embodiments, the reporting information may indicate one or more characteristics associated with a PDU set.

[0430] In various embodiments, the reporting information may indicate the size of the buffered data, either as a percentage or an absolute value of the PDU set size.

[0431] In various embodiments, the reporting information may indicate the size of the buffered data, either as the number of bytes or the number of PDUs.

[0432] In various embodiments, the first configuration information and the second configuration information may be received in the same configuration information (e.g., message) or in different configuration information (e.g., different messages).

[0433] FIG. 6 is a diagram illustrating an exemplary method 600 for transmitting reporting information. For example, method 600 may be implemented in a WTRU. The WTRU may comprise circuitry including any of a processor, a memory, a transmitter, and a receiver. The circuitry may be configured to process method 600. As shown at 610, the WTRU may receive configuration information indicating a remaining time threshold to be used to trigger reporting information related to a PDU set. As shown at 620, the WTRU may determine that the remaining time for transmission of a PDU set (e.g., one or more PDUs in the PDU set) may be below the remaining time threshold. As shown at 630, the WTRU may transmit reporting information related to the PDU set based on the remaining time being below the remaining time threshold. In various embodiments, the reporting information may indicate the amount of remaining data to be transmitted in the PDU set where the remaining time is below the remaining time threshold.

[0434] In various embodiments, the amount of remaining data to be transmitted in the PDU set may be indicated as an absolute value (e.g., in the reporting information).

[0435] In various embodiments, the amount of remaining data to be transmitted in the PDU set may be indicated in bytes (e.g., in the reporting information).

[0436] In various embodiments, the amount of remaining data to be transmitted in the PDU set may be indicated as an index that refers to one or more values (e.g., in the reporting information).

[0437] In various embodiments, the reporting information may indicate the remaining time for transmission of the PDU set. In various embodiments, the remaining time indicated may be the remaining time at the time of construction of the reporting information.

[0438] In various embodiments, the configuration information may be received within a radio resource control message.

[0439] In various embodiments, the reporting information may be received within a MAC CE.

[0440] In various embodiments, the PDU set may include two or more PDUs that may be associated with each other.

[0441] In various embodiments, the configuration information may indicate a second threshold to be used to trigger reporting information related to the PDU set.

[0442] In various embodiments, the WTRU may determine that the amount of remaining data to be transmitted in the PDU set may exceed a second threshold. In various embodiments, the reporting information may be transmitted based on the determination that the amount of remaining data to be transmitted in the PDU set may exceed a second threshold.

[0443] In various embodiments, the reporting information may indicate one or more characteristics associated with the PDU set.

[0444] FIG. 7 is a diagram illustrating an exemplary method 700 for transmitting uplink traffic information. For example, method 700 may be implemented in a WTRU. The WTRU may comprise circuitry including any of a processor, a memory, a transmitter, and a receiver. The circuitry may be configured to process method 700. As shown at 710, the WTRU may receive configuration information indicating that it is to report PDU set related information for uplink traffic. As shown at 720, the WTRU may send uplink traffic information based on (1) the uplink traffic information being available, or (2) the uplink traffic information having changed from previous uplink traffic information that was previously reported. In various embodiments, the uplink traffic information may indicate the identification of the PDU set, the arrival time, and the traffic periodicity.

[0445] In various embodiments, the WTRU may refrain from sending subsequent uplink traffic information for the PDU set for a certain duration after sending the uplink traffic information.

[0446] Any characteristic, variation, or embodiment described with respect to the method is compatible with an apparatus device comprising means for processing the disclosed method, compatible with a device comprising circuitry including any of a memory, a processor, a transmitter, and a receiver (e.g., operatively coupled to the processor) configured to process the disclosed method, compatible with a computer program product comprising program code instructions, and compatible with a non-transitory computer-readable storage medium storing the program instructions.

[0447] In the foregoing, the features and elements are provided in specific combinations, but it will be understood by those skilled in the art that each feature or each element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in this application, and these embodiments are intended as illustrations of various aspects. As will be apparent to those skilled in the art, many modifications and variations may be made without departing from the spirit and scope of the present invention. Any element, operation, or instruction used in the description of this application should not be construed as important or essential to the present invention unless explicitly presented as such. In addition to those listed herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims, and is limited together with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

[0448] The foregoing embodiments have been considered in relation to the terminology and structure of infrared-compatible devices (i.e., infrared radiation emitters and receivers) for the sake of brevity. However, the embodiments considered are not limited to these systems and can also be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0449] It should also be understood that the terms used in this specification are for the purpose of describing particular embodiments only and are not intended to be limiting. As used herein, the term "video" or the term "image" can mean any of a snapshot, a single image, and / or a plurality of images displayed over time. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote", and / or the term "head-mounted display" or its abbreviation "HMD" can mean or include (i) a wireless transmit and / or receive unit (WTRU), (ii) any of some embodiments of a WTRU, (iii) a wireless and / or wired (e.g., tetherable) device configured to have some or all of the structure and functionality of a WTRU, (iii) a wireless and / or wired device configured to have less structure and functionality than all of the structure and functionality of a WTRU, or (iv) the like. Details of exemplary WTRUs that can represent any WTRU listed herein are provided herein with respect to FIGS. 1A - 1D. As another example, the various embodiments disclosed herein and the various embodiments below are described as utilizing a head-mounted display. One of ordinary skill in the art will recognize that devices other than a head-mounted display can be utilized and that some or all of the present disclosure and the various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other devices can include a drone or other device configured to stream information for providing an augmented reality experience.

[0450] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0451] Without departing from the scope of the present invention, variations of the methods, apparatuses, and systems provided above are possible. Considering the various embodiments that may be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, the embodiments provided herein include portable devices that may include or utilize any suitable voltage source, such as a battery that provides any suitable voltage.

[0452] Furthermore, in the above embodiments, attention should be paid to the processing platform, computing system, controller, and other devices including a processor. These devices may include at least one central processing unit (CPU) and memory. According to the convention of those skilled in the art of computer programming, references to operations, and symbolic representations of operations or instructions may be implemented by various CPUs and memories. Such operations, and operations or instructions may be referred to as "executed", "executed by a computer", or "executed by a CPU".

[0453] Those skilled in the art will understand that operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents data bits that can cause a resultant conversion or reduction of electrical signals, maintains the data bits in memory locations of the memory system, thereby restructuring or otherwise changing the operation of the CPU and the processing of other signals. The memory location where the data bits are maintained is a physical location that has specific electrical, magnetic, optical, or organic characteristics corresponding to or representing the data bits. Embodiments are not limited to the platforms or CPUs mentioned above, and it should be understood that other platforms and CPUs can support the provided methods.

[0454] Data bits can also be maintained on a computer-readable medium including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by a CPU. The computer-readable medium may include cooperative or interconnected computer-readable media that are exclusively present on the processing system or are distributed among a plurality of interconnected processing systems that are local or remote to the processing system. Embodiments are not limited to the memories mentioned above, and it should be understood that other platforms and memories can support the provided methods.

[0455] In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile body, a network element, and / or any other computing device.

[0456] There is little difference between a hardware implementation and a software implementation of an aspect of the system. Whether to use hardware or software is generally (although in some situations the choice between hardware and software may be critical) a design choice representing a cost-effectiveness trade-off. There may be various vehicles (e.g., hardware, software, and / or firmware) by which the processes and / or systems and / or other techniques described herein may be effective, and the preferred vehicle may vary depending on the situation in which the processes and / or systems and / or other techniques are deployed. For example, if the implementer determines that speed and accuracy are of utmost importance, the implementer may primarily select a hardware and / or firmware vehicle. If flexibility is of utmost importance, the implementer may primarily select a software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0457] In the foregoing detailed description, various embodiments of devices and / or processes have been shown through the use of block diagrams, flowcharts, and / or examples. As long as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof. In one embodiment, some portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, some aspects of the embodiments disclosed herein may be implemented equivalently in an integrated circuit as one or more computer programs operating on one or more computers (e.g., as one or more programs operating on one or more computer systems), as one or more programs operating on one or more processors (e.g., as one or more programs operating on one or more microprocessors), as firmware, or as substantially any combination thereof, and it will be recognized by those skilled in the art that designing the circuitry and / or writing the code for the software and / or firmware are within the scope of the skill of those in the art in light of this disclosure. Additionally, it will be understood by those skilled in the art that the mechanisms of the subject matter described herein can be distributed as various forms of program products, and that representative embodiments of the subject matter described herein apply regardless of the particular type of signal transmission medium used to actually carry out the distribution. Examples of signal transmission media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memories, and the like, as well as transmission media such as digital and / or analog communication media (e.g., optical fiber cables, waveguides, wired communication links, wireless communication links, etc.).

[0458] One of ordinary skill in the art would recognize that it is common in the art to describe a device and / or process in the manner described herein and then, using engineering techniques, integrate such described device and / or process into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. One of ordinary skill in the art would recognize that a typical data processing system generally includes one or more of a system unit housing, a video display device, memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, operating systems, drivers, graphical user interfaces, and computing entities such as application programs, one or more interaction devices such as touch pads or screens, and / or a control system including feedback loops and control motors (e.g., feedback for detecting position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components as typically found in a data computing / communication system and / or a network computing / communication system.

[0459] The subject matter described in this specification may refer to different components that are included within or connected to different other components. Such depicted architectures are merely examples, and it should be understood that in practice, many other architectures that achieve the same functionality may be implemented. Conceptually, any arrangement of components for achieving the same functionality is effectively "associated" so that the desired functionality can be achieved. Thus, any two components in this specification that are combined to achieve a particular function can be considered to be "associated" with each other such that the desired functionality is achieved, regardless of the architecture or intervening components. Similarly, any two components thus associated can be considered to be "operably connected" or "operably coupled" to each other for achieving the desired function, and any two components that can be associated in this way may be considered to be "operably combinable" with each other for achieving the desired function. Specific examples of operably combinable include, but are not limited to, components that are physically fittable and / or physically interact, and / or components that wirelessly interact and / or wirelessly interact, and / or components that logically interact and / or are logically interactable.

[0460] Regarding the use of substantially any plural and / or singular terms in this specification, one of ordinary skill in the art can convert from plural to singular and / or from singular to plural as appropriate for the context and / or application. In this specification, various singular / plural permutations may be explicitly described for clarity purposes.

[0461] In general, it will be understood by those skilled in the art that the terms used in this specification, particularly in the appended claims (e.g., the body of the appended claims), are generally intended to be "non-limiting" terms (e.g., the term "comprising" should be interpreted as "comprising, but not limited to", the term "having" should be interpreted as "having at least", and the term "including" should be interpreted as "including, but not limited to"). Further, where a specific number of introductions of a claim is intended, such intent will be expressly stated in the claim, and it will be understood by those skilled in the art that where there is no such statement, there is no such intent. For example, if only one item is intended, the term "single" or similar words may be used. To assist understanding, the following appended claims and / or the description in this specification may include the use of introductory phrases such as "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to limit any particular claim that includes a recitation introduced by an indefinite article such as "a" or "an" to an embodiment that includes only such one recitation, even if the same claim includes both an introductory phrase such as "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same is true for the use of definite articles used to introduce claim recitations. In addition, even where a specific number of introductions of a claim is expressly stated, it will be recognized by those skilled in the art that such statement should be interpreted to mean at least the number stated (e.g., a simple statement of "two recitations" without other modifiers means at least two recitations, or two or more recitations).Furthermore, when notations similar to "at least one of A, B, and C, etc." are used, generally, such a structure is intended in the meaning that those skilled in the art would understand the notation (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). When notations similar to "at least one of A, B, or C, etc." are used, generally, such a structure is intended in the meaning that those skilled in the art would understand the notation (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). It should be further understood by those skilled in the art that any substantially discrete words and / or phrases presenting two or more alternative terms in any of the specification, claims, or drawings are intended to contemplate the possibility of including one of the terms, any of the terms, or both terms. For example, the phrase "A or B" should be understood to include the possibilities of "A" or "B" or "A and B". Further, as used herein, the term "any of" following a list of a plurality of items and / or a list of a plurality of categories of items is intended to include "any of", "any combination of", "any plurality of", and / or "any plurality of combinations of" the items and / or categories of items, either individually or in combination with other items and / or other categories of items. Further, as used herein, the term "set" is intended to include any number of items including zero. Additionally, as used herein, the term "number" is intended to include any number including zero. Also, as used herein, the term "plurality" is intended to be synonymous with "multiple".

[0462] In addition, when a feature or aspect of the present disclosure is described in terms of a Markush group, one of ordinary skill in the art will recognize that the present disclosure is thereby also described in terms of any individual element or subgroup of elements of the Markush group.

[0463] As will be understood by those of ordinary skill in the art, for any purpose, such as for the purpose of providing a written description, all ranges disclosed herein also include any possible subranges and combinations of subranges thereof. Any recited range can be readily recognized as enabling, with sufficient explanation, that the same range can be decomposed into at least equal halves, thirds, fourths, fifths, tenths, etc. By way of non-limiting example, each range discussed herein may be readily decomposed into lower thirds, middle thirds, and upper thirds, etc. Also, as will be understood by those of ordinary skill in the art, all words such as "up to", "at least", "more than", "less than", etc. include the recited number and, as discussed above, further mean ranges that can be decomposed into subranges. Finally, as will be understood by those of ordinary skill in the art, ranges include each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0464] Furthermore, the claims should not be read as being limited to the order provided or to the elements provided, unless specifically so recited. In addition, in any claim, the use of the term "means for" is not intended to invoke 35 U.S.C. § 112, paragraph 6, or means-plus-function claim format, and any claim that does not have the term "means for" is not so intended.

Claims

1. A wireless transmit / receive unit (WTRU) comprising a circuit including any one of a processor, a memory, a transmitter, and a receiver, receiving configuration information indicating a remaining time threshold to be used for triggering reporting information related to a protocol data unit (PDU) set; determining that a remaining time for transmission of one or more PDUs in the PDU set is less than the remaining time threshold; transmitting reporting information related to the PDU set indicating an amount of remaining data to be transmitted in the PDU set for which the remaining time is less than the remaining time threshold, based on the remaining time being less than the remaining time threshold. A WTRU comprising a circuit configured for.

2. The WTRU according to claim 1, wherein the amount of the remaining data to be transmitted in the PDU set is indicated as an absolute value.

3. The WTRU according to claim 1 or 2, wherein the amount of the remaining data to be transmitted in the PDU set is indicated in bytes.

4. The WTRU according to claim 1, wherein the amount of the remaining data to be transmitted in the PDU set is indicated as an index pointing to one or more values.

5. The WTRU according to any one of claims 1 to 4, wherein the reporting information indicates the remaining time for the transmission of the PDU set.

6. The WTRU according to any one of claims 1 to 5, wherein the configuration information is received within a radio resource control message.

7. The WTRU according to any one of claims 1 to 6, wherein the reporting information is received within a media access control control element (MAC CE).

8. The WTRU according to any one of claims 1 to 7, wherein the PDU set includes two or more PDUs associated with each other.

9. The WTRU according to any one of claims 1 to 8, wherein the configuration information indicates a second threshold to be used for triggering reporting information related to the PDU set.

10. The circuit is further configured to determine that the amount of the remaining data to be transmitted in the PDU set exceeds the second threshold, and the reporting information is transmitted based on the determination that the amount of the remaining data to be transmitted in the PDU set exceeds the second threshold. The WTRU according to claim 9.

11. The method is implemented in a wireless transmit / receive unit (WTRU), receiving configuration information indicating a remaining time threshold to be used for triggering reporting information related to a protocol data unit (PDU) set, determining that a remaining time for transmission of one or more PDUs in the PDU set is below the remaining time threshold, and transmitting, based on the remaining time being below the remaining time threshold, reporting information related to the PDU set indicating an amount of remaining data to be transmitted in the PDU set for which the remaining time is below the remaining time threshold. A method comprising the steps of: **Claim 12** The method according to claim 11, wherein the amount of remaining data to be transmitted in the PDU set is indicated as an absolute value. **Claim 13** The method according to claim 11 or 12, wherein the amount of remaining data to be transmitted in the PDU set is indicated in bytes. **Claim 14** The method according to claim 11, wherein the amount of remaining data to be transmitted in the PDU set is indicated as an index pointing to one or more values. **Claim 15** The method according to any one of claims 11 to 14, wherein the reporting information indicates the remaining time for the transmission of the PDU set. **Claim 16** The method according to any one of claims 11 to 15, wherein the configuration information is received within a radio resource control message. **Claim 17** The method according to any one of claims 11 to 16, wherein the reporting information is received within a media access control control element (MAC CE). **Claim 18** The method according to any one of claims 11 to 17, wherein the PDU set includes two or more PDUs associated with each other. **Claim 19** The method according to any one of claims 11 to 18, wherein the configuration information indicates a second threshold to be used for triggering reporting information related to the PDU set. **Claim 20** The method according to claim 19, further comprising determining that the amount of remaining data to be transmitted in the PDU set exceeds the second threshold, and wherein the reporting information is transmitted based on the determination that the amount of remaining data to be transmitted in the PDU set exceeds the second threshold.

Images