Methods, architectures, apparatuses, and systems for buffer status report enhancements 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 for triggering reporting information related to a set of protocol data units (PDUs). The method may include determining that a remaining time for transmitting a set of PDUs (e.g., one or more PDUs) is below a remaining time threshold. The method may include transmitting report information related to the PDU set based on a determination that the remaining time is below the remaining time threshold. In various embodiments, the report information may indicate an amount of remaining data to be transmitted in the PDU set if the remaining time is below the remaining time threshold.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Patent Application 63 / 456,952, filed April 4, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure generally relates to the fields of communications, software, and coding, including, for example, methods, architectures, apparatus, and systems for enhancing buffer status reporting for extended reality (XR) services. Background Technology

[0004] Extended reality (XR) can include different types of immersive experiences, such as virtual reality (VR), augmented reality (AR), and mixed reality (MR), as well as transitional realities between them. XR applications can be associated with different types of XR services. The embodiments described herein are designed with the foregoing in mind. Summary of the Invention

[0005] This document describes methods, architectures, apparatuses, and systems for enhancing buffer status reporting for XR services. In one embodiment, this document describes a Wireless Transmit / Receive Unit (WTRU) including circuitry comprising any one of a processor, a transmitter, and a receiver. In one example, the circuitry can be configured to receive configuration information indicating a remaining time threshold for triggering reporting information associated with a set of Protocol Data Units (PDUs). The circuitry can be configured to determine that the remaining time for transmitting (e.g., one or more PDUs) in the PDU set is below the remaining time threshold. The circuitry can be configured to transmit reporting information associated with the PDU set based on the determination that the remaining time is below the remaining time threshold. In various embodiments, the reporting information can indicate the amount of remaining data to be transmitted in the PDU set when the remaining time is below the remaining time threshold.

[0006] In one implementation, a method can be implemented in a WTRU. In one example, the method may include receiving configuration information indicating a remaining time threshold for triggering reporting information associated with a set of Protocol Data Units (PDUs). The method may include determining that the remaining time for transmitting a portion (e.g., one or more PDUs) in the PDU set is below the remaining time threshold. The method may include transmitting reporting information associated with 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 the amount of remaining data to be transmitted in the PDU set when the remaining time is below the remaining time threshold. Attached Figure Description

[0007] A more detailed understanding can be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. As with the detailed description, the figures in these drawings are illustrative. Therefore, the drawings and detailed description should not be considered limiting, and other equivalent examples are possible and highly probable. Furthermore, the same reference numerals in the figures indicate the same elements, and wherein:

[0008] Figure 1A This is a system diagram illustrating an exemplary communication system;

[0009] Figure 1B It shows that it can be done Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown;

[0010] Figure 1C It shows that it can be done Figure 1A The system diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system.

[0011] Figure 1D It's shown in the diagram. Figure 1A The diagram shows another exemplary RAN and another exemplary CN used in the communication system.

[0012] Figure 2 This is a diagram illustrating an example of a Protocol Data Unit (PDU) set and a data burst;

[0013] Figure 3 This is a diagram illustrating an example of conditional switching configuration and execution;

[0014] Figure 4A and 4B This is a diagram illustrating six examples of forwarding configurations at the access layer used to map Extended Reality (XR) data units during uplink transmission;

[0015] Figure 5 This is a diagram illustrating an example method for transmitting buffer status report information;

[0016] Figure 6 This is a diagram illustrating an example method for transmitting report information; and

[0017] Figure 7 This is a diagram illustrating an example method for transmitting uplink service information. Detailed Implementation

[0018] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be implemented or combined with the embodiments and other examples described, disclosed, or otherwise expressly, implicitly, and / or inherently provided (collectively, the “Provided”). Although various embodiments in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any parts thereof are described and / or claimed herein, 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.

[0019] Exemplary communication system

[0020] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Regarding... Figure 1A-1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network can utilize, perform, or be arranged and / or adapted and / or configured to use the methods, apparatuses and systems provided herein.

[0021] Figure 1A This is a system diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, broadcasting, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail (ZT) Unique Word (UW) Fourier Transform (DFT) Extended OFDM (ZT-UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0022] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Any of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include / or be user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or MiFi devices, Internet of Things (IoT) devices, watches or other wearable devices, 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 industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the wireless transmission / reception units 102a, 102b, 102c, and 102d may be interchangeably referred to as UEs.

[0023] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly connect to at least one of WTRUs 102a, 102b, 102c, and 102d, for example, to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or Network 112. As an example, base stations 114a and 114b can be any of the following: base transceiver station (BTS), NodeB (NB), eNodeB (eNB), home NodeB (HNB), home eNodeB (HeNB), gNodeB (gNB), NR NodeB (NR NB), site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0024] 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 base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0026] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish the air interface 116. 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).

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

[0028] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0029] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0030] In one embodiment, the base station 114a and the wireless transmission / reception units 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA 2000 1X, CDMA 2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0031] Figure 1ABase station 114b can be, for example, a wireless router, a home NodeB, a home eNodeB, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA 2000, GSM, LTE-A, LTE-A Pro, NR, etc.) to establish any of small cells, pico cells, and femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0032] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions (such as user authentication). Although in Figure 1A Although not shown, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses any of the following radio technologies: GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, and Wi-Fi.

[0033] CN 106 / 115 can also be used as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or Network 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, Network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 114 or a different RAT.

[0034] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers to communicate with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which can use cellular-based radio technology, and with base station 114b, which can use IEEE 802 radio technology.

[0035] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other components / peripherals 138, etc. It is understood that WTRU 102 may include any sub-combination of the foregoing components while remaining consistent with the embodiments.

[0036] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it should be understood that the processor 118 and transceiver 120 may be integrated together, for example, in an electronic package or chip.

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

[0038] Although the transmitting / receiving element 122 is in Figure 1B While described as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. For example, WTRU 102 may use MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0039] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via various RATs, such as NR and IEEE 802.11.

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

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

[0042] 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) about the current location of the WTRU 102. In addition to, or alternatively to, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on the timing of signals received from two or more neighboring base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0043] The processor 118 may also be coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units providing additional features, functions, and / or wired or wireless connectivity. For example, components / peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Components / peripherals 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

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

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

[0046] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0047] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific 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. Figure 1C As shown, eNode-B 160a, 160b, and 160C can communicate with each other via the X2 interface.

[0048] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0049] The MME 162 can connect to each of the eNodes B160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0050] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during handover between eNode Bs, triggering paging when DL data is available to WTRUs 102a, 102B, and 102c, managing and storing the context of WTRUs 102a, 102B, and 102c, etc.

[0051] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0052] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with an IP gateway that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0053] Although WTRU is Figure 1A-1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use a wired communication interface with a communication network (e.g., temporary or permanent).

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

[0055] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or interfaces to a distributed system (DS) or another type of wired / wireless network carrying traffic entering and / or leaving the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. This peer-to-peer traffic can be sent between the source and destination STAs (e.g., directly between the source and destination STAs) using a direct link setup (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode cannot have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0056] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

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

[0058] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segmented parser that divides the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiving STA's receiver, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC), entities, etc.

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

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

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

[0062] Figure 1DThis is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR wireless technology. RAN 113 can also communicate with CN 115.

[0063] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c includes 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 and / or receive signals from WTRUs 102a, 102b, and 102c. Therefore, gNB 180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can 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 Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0064] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with Scalable Digital Numerology (SDN). For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or Transmission Time Intervals (TTIs) of varying lengths or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying lengths of absolute time).

[0065] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without needing to access other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate essentially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can serve as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0066] 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, network fragmentation support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0067] Figure 1DThe CN 115 shown may 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 the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0068] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing, for example, to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies (such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies (such as Wi-Fi)).

[0069] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure them to route traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0070] UPF 184a and 184b can connect to one or more of gNB 180a, 180b, and 180c in RAN 113 via the N3 interface. The N3 interface can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110), for example, to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

[0072] Given Figure 1A-1D and Figure 1A-1D As described herein, one or more of the functions described with respect to one or more of the following can be performed by one or more emulation components / devices (not shown): WTRU102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other components (one or more) / devices (one or more) described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0073] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more 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. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0074] One or more simulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in test scenarios within a test laboratory and / or an undeployed (e.g., tested) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices can be test equipment. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0075] For clarity, in the embodiments described herein, satisfied, unsatisfied conditions and configuration condition parameters are described relative to thresholds (e.g., values ​​greater than or less than a value (e.g., threshold), configuration values ​​(e.g., threshold), etc.). For example, a satisfied condition may be described as being above a value (e.g., threshold), and a unsatisfied condition may be described as being below a value (e.g., threshold). The embodiments described herein are not limited to threshold-based conditions. Any other kind of conditions and parameters (one or more) (e.g., belonging to or not belonging to a range of values) may be applied to the embodiments described herein.

[0076] In all embodiments described herein, (e.g., configuration) information can be described as being received by the WTRU from the network, for example, via system information or via any type of protocol message. Although not explicitly mentioned in the embodiments described herein, the same (e.g., configuration) information can be pre-configured in the WTRU (e.g., via any kind of pre-configuration method, such as via factory settings) so that the (e.g., configuration) information can be used by the WTRU without being received from the network.

[0077] Throughout the embodiments described herein, the statement "the WTRU can be configured to have certain information" is used interchangeably with "the WTRU can receive configuration information indicating certain information." Throughout the embodiments described herein, the statements "the WTRU can report certain information" and "the WTRU can be configured to report certain information" are equivalent, or can be used interchangeably with "the WTRU can transmit (e.g., report) information indicating certain information."

[0078] In the embodiments described herein, "a" and similar phrases shall be interpreted as "one or more" and "at least one". Similarly, any term ending with the suffix "(one or more)" shall be interpreted as "one or more" and "at least one". The term "may" shall be interpreted as "may, for example".

[0079] The symbol " / " (e.g., a forward slash) can be used in this article to mean "and / or", where, for example, "A / B" can imply "A and / or B".

[0080] In the embodiments described herein, the terms "serving base station," "base station," "gNB," and "network" (collectively, "gNB") are used interchangeably to designate any network element, such as a network element that acts 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.

[0081] In all embodiments described herein, any network element of the RAN or core network (CN) may be referred to herein as a “network”.

[0082] Extended Reality Overview

[0083] The term Extended Reality (XR) can include different types of immersive experiences, such as Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and any of the transitional realities between them.

[0084] Virtual reality (VR) can be viewed as a rendered version of the visual and audio scene being presented. The rendering can be designed to mimic the visual (e.g., stereoscopic 3D) and audio sensory stimuli of the real world to the observer (e.g., a user) as they can move within constraints defined by the application.

[0085] Augmented reality (AR) can correspond to an application in which additional information can be provided to the user, such as any of the artificially generated items and content overlaid on the current environment.

[0086] Mixed Reality (MR) can be seen as a higher form of AR, in which one or more virtual elements can be inserted into a physical scene to provide the illusion that these elements can be part of a real scene. XR can include any (e.g., all) combination of real and virtual environments and human-computer interactions generated by computer technology and / or wearable devices.

[0087] In the context of XR applications (e.g., services), the concept of immersion can refer to being surrounded by a virtual environment and providing the feeling of being physically and spatially present within that environment. The level of virtuality can range from partial sensory input to fully immersive multisensory input for virtual reality that is difficult to distinguish from actual reality.

[0088] In the embodiments described herein, XR devices may be associated with the ability to provide one or more levels of spatial tracking. XR devices may include one or more sensors to enable spatial tracking, such as, for example, any of a monocular / stereo / depth camera, a radio beacon, a Global Positioning System (GPS), an inertial sensor, etc. For example, spatial tracking may be performed at different levels, such as three degrees of freedom (DoF) (e.g., rotational motion along the X, Y, and Z axes) or six DoF (e.g., rotational and / or translational motion along the X, Y, and Z axes). For example, spatial tracking can lead to interaction to experience some form of virtual content. Users can move and / or interact with components within extended reality. For example, movement and / or interaction can involve any of movement, gestures, eye tracking, etc. Spatial tracking enables immersive XR experiences. For example, some form of head and / or motion tracking can ensure that simulated visual and audio components from the user's perspective can be updated to be associated with the user's movement. Inaccurate and / or delayed spatial tracking can cause user discomfort and / or motion sickness.

[0089] In the embodiments described herein, a WTRU can correspond to any XR device (e.g., a network element) that can have various form factors. For example, a WTRU (e.g., an XR WTRU) can include, but is not limited to, any of the following: head-mounted displays (HMDs), optical see-through glasses, camera-through HMDs for any of AR and MR, mobile devices with location tracking and cameras, wearable devices, etc. For example, different types of XR WTRUs can exist based on XR device functionality, such as any of a display, camera, sensor, sensor processing, wireless connectivity, XR / media processing, and power supply, the XR device functionality being provided by one or more devices, wearable devices, actuators, controllers, and / or accessories. One or more devices (e.g., network elements, WTRUs) can be grouped into collaborative XR groups to support any of XR applications, XR experiences, and XR services.

[0090] Examples of PDU sets and data bursts

[0091] In 5G networks, a QoS flow can represent the finest level of QoS differentiation within a PDU session. 5G QoS characteristics can be determined by a 5G QoS identifier (5QI) (e.g., associated with a 5QI). For example, each packet in a QoS flow can be processed (e.g., manipulated) according to the same QoS expectations.

[0092] For XR / media services, a set of data packets can be used to carry the payload of a PDU set (e.g., frames, video clips, video tiles). A PDU set may include one or more PDUs carrying the payload of an information unit (e.g., either a frame or a video clip) generated at the application layer.

[0093] At the media layer, packets within a PDU set can be decoded (e.g., processed) as a whole. For example, if all or at least a certain number of packets carrying frames / video segments are received (e.g., successfully delivered), the frames / video segments can be decoded (e.g., only). For example, if all frames a frame within a group of pictures (GOP) may depend on are successfully received, that frame can be decoded (e.g., only) by the client. For example, groups of packets within a PDU set can depend on each other (e.g., be associated) at the media layer. Ignoring such dependencies between packets within a PDU set can lead to inefficient scheduling from the 5G network. For example, the 5G network might randomly drop packets (one or more) and attempt to deliver other packets from the same PDU set, which may be useless to the client and could represent a waste of radio resources.

[0094] For example, if 5G networks can take into account the characteristics of PDU sets, any aspect of audio samples, haptic applications, and remote control operations can have improved performance. For instance, considering the dependencies between packets of PDU sets (e.g., frame / video slices) can allow 5G networks to enhance radio resource efficiency and improve the user experience.

[0095] The 3rd Generation Partnership Project (3GPP) is exploring enhancements to the current 5G QoS framework to support different QoS processing for PDU sets. PDU sets can carry different content, such as any element in an I / B / P frame, or fragments / plots within an I / B / P frame. For example, differentiated QoS processing could be studied, where the different importance of PDU sets can be considered, such as reducing resource waste by processing (e.g., processing) packets (e.g., PDUs) belonging to less important PDU sets (one or more).

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

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

[0098] Time to Live (TTL) (which may be equal to PSDB) can represent the time elapsed since the application layer received the first (e.g., initial) PDU of the PDU set. TTL can represent the amount of time before the transmission of the PDU set may be useless, as the receiver application may not be able to use the PDU set. In the embodiments described herein, the terms “TTL,” “remaining delay,” and “remaining time” are used interchangeably to represent (e.g., an ongoing) period of time after which the transmission of any remaining (e.g., yet-to-be-transmitted) delay-critical data may be useless and, for example, may be discarded. Delay-critical data may be referred to herein as a PDU set, one or more PDUs of a PDU set, one or more PDUs of one or more PDU sets, and any kind of delay-critical data set.

[0099] The PDU set error rate (PSER) can be an upper bound on the error rate of a PDU set that may have been processed by the sender of a link layer protocol (e.g., the Radio Link Control (RLC) layer), where one or more PDUs in the PDU set may not have been successfully received by their corresponding receivers and delivered to an upper layer (e.g., the Packet Data Convergence Protocol (PDCP) layer).

[0100] In the case that all PDUs of a PDU set are received (e.g., within the PSDB), one or more PDU sets may be used (e.g., only) at the application layer. Such one or more PDU sets may be marked with a PDU Set Synthesis Processing Indicator (PSIHI) (e.g., including marking information indicating the PDU Set Synthesis Processing Indicator).

[0101] Even if one or more parts of a PDU are not received, one or more sets of PDUs (e.g., even) are available.

[0102] Figure 2This is a schematic diagram illustrating examples of PDU sets and data bursts. For example, a WTRU can 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.

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

[0104] Example of NR measurement

[0105] Measurements performed by the WTRU can be used by the network for mobility determination (e.g., handover).

[0106] For example, in connected mode (e.g., RRC_CONNECTED), the WTRU can measure one or more beams of a cell, and the measurement results (e.g., power values) can be averaged to derive cell quality (e.g., a cell quality metric). For example, the WTRU can be configured to consider (e.g., measure) a subset of the detected beams. Filtering can be performed at at least two different levels, such as 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. Cell quality from beam measurements can be derived in the same manner for either serving cells (one or more) or non-serving cells (one or more). Measurement reports can contain information indicating the measurement results, such as the measurement results of X best beams when the WTRU is configured to do so via a gNB (X is an integer).

[0107] Measurement reporting can be configured to be either event-triggered or periodic. When the measurement reporting configuration is periodic, WTRU can send measurement report information at each reporting interval (ranging from, for example, 120 milliseconds to 30 minutes).

[0108] For event-triggered measurement reports, the WTRU can send measurement report information if one or more conditions associated with the event are met. The WTRU can continue to measure any of the serving cell and one or more neighbors, can report quantities (e.g., metrics), and can verify (e.g., evaluate) the quantity (e.g., metric) using any of the thresholds and offsets defined (e.g., indicated) in the reporting configuration. For example, the reported quantity (e.g., metric) and any of the event triggers can include any of the reference signal received power (RSRP), reference signal received quality (RSRQ), and signal-to-interference-plus-noise ratio (SINR).

[0109] In NR, there can be intra-RAT events and inter-RAT events.

[0110] Examples of events within RAT

[0111] In the first example of an in-RAT event (which we may refer to as an A1 event hereafter), a metric associated with the serving cell may meet a condition (e.g., may become above a threshold). For example, an A1 event can be used to cancel an ongoing handover process. This can be applied to situations where the WTRU can move to the cell edge, trigger a mobility process, and subsequently move back to good coverage before the mobility process is complete.

[0112] In the second example of an in-RAT event (which may be referred to herein as an A2 event), the metric associated with the serving cell may fail to meet the conditions (e.g., it may become worse than a threshold). An A2 event may not involve any neighboring cell measurements. An A2 event can be used, for example, to trigger a blind mobility procedure, or in cases where the network receives measurement report information that could be triggered by an A2 event in order to conserve WTRU power (e.g., not performing neighboring cell measurements if the serving cell quality is sufficiently good), the network may configure the WTRU for neighboring cell measurements.

[0113] In the third example of an in-RAT event (which may be referred to herein as an A3 event), the metric associated with a neighboring cell can satisfy a condition (e.g., it can become one offset better than a particular cell (SpCell)). The A3 event can be used, for example, during a handover process. For instance, SpCell can be the primary serving cell of any of the following: (i) a primary cell group (MCG) (e.g., the primary cell (PCell)) and (ii) a secondary cell group (SCG) (e.g., the primary-secondary cell (PSCell)). For example, in dual connectivity (DC) operations, the secondary node (SN) can configure an A3 event for a PSCell change triggered by the SN. This A3 event can be used in either conditional handover (CHO) or conditional PSCell change (CPC) operations.

[0114] In the fourth example of an event within the RAT (which may be referred to herein as an A4 event), a metric associated with a neighboring cell may satisfy a condition (e.g., may become above a threshold). For example, an A4 event may be used for a handover process that may not depend on the coverage of the serving cell (e.g., load balancing), where (e.g., even) if the serving cell conditions are excellent, the WTRU may switch to (e.g., a good) neighboring cell.

[0115] In the fifth example of an in-RAT event (which may be referred to herein as an A5 event), a first metric associated with SpCell may fail to meet a first condition (e.g., may become worse than a first threshold) and a second metric associated with a neighboring cell may meet a second condition (may become higher than a second threshold). An A5 event (e.g., similar to an A3 event) may be used for handover, for example. An A5 event (e.g., compared to an A3 event) may provide a handover triggering mechanism based on absolute measurements of the serving and neighboring cells, where an A3 event may be based on a relative comparison. For example, an A5 event may be suitable for time-critical handovers, such as when the serving cell weakens and the WTRU can be changed to another cell that may not meet the handover criteria for an A3 event.

[0116] In the sixth example of an event within the RAT (which we may refer to as the A6 event in this paper), the metric associated with the neighboring cell can satisfy a condition (e.g., it can become one offset better than the secondary cell (SCell)). The A6 event can be used, for example, for SCell addition and / or release.

[0117] Example of RAT inter-RAT events:

[0118] In the first example of an inter-RAT event (which may be referred to as the B1 event in this paper), the metric associated with the neighboring RATs may satisfy a condition (e.g., may become higher than a threshold). For the case of inter-RAT switching, the B1 event may correspond to the A4 event.

[0119] In the second example of an inter-RAT event (which may be referred to herein as event B2), the first metric associated with PCell may fail to meet the condition (e.g., it may become worse than the first threshold), and the second metric associated with neighboring cells in the inter-RAT may meet the second condition (e.g., it may become better than the second threshold). For the case of inter-RAT handover, event B2 corresponds to event A5.

[0120] For example, measurement event configuration (e.g., information) may include a trigger time (TTT), which can indicate the period of time during which event conditions can be met (e.g., satisfied) before the WTRU triggers an associated measurement report. The TTT can be set to a value ranging from zero (e.g., no TTT) to several minutes (up to five minutes in NR Rel-16).

[0121] Examples of NR conditional switching and conditional PSCell addition or modification

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

[0123] Traditional 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, for example, without receiving any measurement report information. For instance, the WTRU can be configured with an A3 event to trigger the sending of a measurement report in a dual-connectivity (DC) scenario when the metrics of a neighboring cell (e.g., radio signal level / quality (e.g., any of RSRP, RSRQ, etc.)) become better (e.g., higher) than the corresponding metrics of the primary serving cell (PCell) or the primary / secondary serving cell (PSCell). The WTRU can monitor either the serving cell or any of the neighboring cells and can send measurement report information when (e.g., configured) conditions are met. Upon receiving the measurement report information, the network (current serving network element / cell) can prepare an HO command (e.g., an RRC reconfiguration message indicating synchronized reconfiguration (e.g., reconfigurationWithSync)) and send the HO command to the WTRU. The WTRU can receive and execute the handover command, thereby connecting the WTRU to the target cell.

[0124] The difference between CHO and traditional switching is at least in that it can prepare more than one switching target (compared to a single target in the traditional case).

[0125] The difference between CHO and traditional handover is that WTRU cannot perform the handover in the same way as traditional handover (e.g., immediately). For example, WTRU can be configured to have any of one or more trigger conditions (e.g., a set of radio conditions), and WTRU can perform a handover to one of the objectives (e.g., only) if one or more trigger conditions are met.

[0126] For example, if the radio conditions toward the current serving cell are favorable (e.g., still are), a CHO command can be sent, thereby reducing two major points of failure in conventional handover, such as (1) the risk of failing to send measurement report information (e.g., when the link quality to the current serving cell drops below an acceptable level, for example, for measurement reports 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 drops below an acceptable level after the WTRU may have sent measurement report information and before the WTRU may have received the HO command).

[0127] The triggering condition for a Call for Omissions (CHO) can be based on the radio quality of either the serving cell or neighboring cells, such as any of the conditions used to trigger measurement reports in traditional NR / LTE. For example, a WTRU can be configured with a CHO, which can be associated with an A3 event-type triggering condition and an associated HO command. The WTRU can monitor the current and serving cells, and if the A3 event-type triggering condition is met, the WTRU may not send measurement report information, may execute the associated HO command, and may switch its connection to the target cell.

[0128] Figure 3 This diagram illustrates an example of conditional handover configuration and execution. For example, WTRU 30 can perform a conditional handover from source network element 31 to target network element 32. WTRU 30 can receive configuration information 301 from source network element 31 indicating any of one or more conditions (e.g., associated with either A3 or A5 events), one or more parameters associated with the one or more conditions (e.g., any of thresholds or offset values), and parameters associated with RRC reconfiguration. WTRU can monitor CHO conditions for target cell(s) candidates. If the conditions for target network element 32 are met, WTRU performs a handover to target network element 32 and sends CHO confirmation information 302 to target network element 32.

[0129] CHOs allow for the prevention of useless rebuilds in the event of a radio link failure. For example, a WTRU can be configured to have more than one CHO target, and the WTRU can experience a radio link failure (RLF) before any triggering condition of any of the target cells is met. Conventional operation may result in an RRC rebuild process, which can cause a disruption in the bearer used by the WTRU. With CHOs, if the WTRU terminates its cell with an associated CHO after an RLF is detected (e.g., the target cell may have already been prepared for it), the WTRU can (e.g., directly) execute the HO command associated with that target cell and may not continue the full rebuild process.

[0130] CPC and CPA can be seen as extensions of CHO for DC scenarios. For example, WTRU can be configured with one or more trigger conditions for any of the PSCell changes and additions, and when one or more trigger conditions are met, WTRU can execute any of the associated PSCell change and PSCell add commands.

[0131] To enable CHO / CPAC, define new conditional measurement events in NR. CHO / CPAC configurations associated with the event can be executed if the conditions associated with the event are met.

[0132] For example, if a candidate cell (e.g., a metric associated with the candidate cell) becomes better (e.g., higher) than either PCell or PSCell by an offset, the condition associated with event A3 (which may be referred to herein as CondEvent A3) can be satisfied.

[0133] For example, if a candidate cell (e.g., the metric associated with it) becomes better than a threshold (e.g., high), the condition associated with event A4 (which may be referred to herein as CondEvent A4) can be satisfied.

[0134] For example, the condition associated with event A5 (which may be referred to herein as CondEvent A5) can be satisfied if either PCell or PSCell (e.g., the first metric associated with it) becomes worse than (e.g., in absolute) the first threshold, and if the candidate cell (e.g., the second metric associated with it) becomes better than (e.g., in absolute) the second threshold (e.g., higher).

[0135] In addition to the radio-conditional events described herein, location- and time-conditional events have also been defined in NR (e.g., for cases like non-terrestrial networks (NTNs) where either the time or location of the mobile satellite cell is predictable, so that the WTRU can be instructed to perform CHO / CPAC based on either the time or location).

[0136] In the first example, the condition (which may be referred to as CondEvent D1 in this paper) can be satisfied when the distance between the WTRU and the first reference location (e.g., referenceLocation1) is greater than the first configuration threshold (e.g., Thresh1) and when the distance between the WTRU and the second reference location (e.g., referenceLocation2) of the conditional reconfiguration candidate is less than the second configuration threshold (e.g., Thresh2).

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

[0138] For example, similar to measurement reporting events, conditional event configuration information can include a trigger time (TTT), which can indicate the time period during which the event condition can be reached before the WTRU executes a CHO.

[0139] Example of a buffer status report

[0140] In the embodiments described herein, the terms "Uplink Buffer Status Report (BSR)," "Buffer Status Report (BSR)," and "BSR Information" are used interchangeably.

[0141] Uplink Buffer Status Report (BSR) allows for support for QoS-aware packet scheduling. In NR, BSR information can be reported at the Logical Channel Group (LCG) granularity. A WTRU can be configured with up to thirty-two Logical Channel Identifiers (LCIDs), which can be grouped into up to eight LCGs. For example, one or more WTRUs can be configured with more than thirty-two LCIDs and more than eight LCGs (e.g., a Mobile Terminal (MT) with an Integrated Backhaul Access (IAB) node can be configured with up to 65,855 LCIDs and 256 LCGs).

[0142] BSRs can be sent using MAC control elements (MAC CEs) and can be sent in either short or long BSR format. The short BSR format reports (e.g., only) data from one LCG, while the long BSR format reports data from more than one LCG.

[0143] A MAC control element (MAC CE) can be used to transmit a BSR. When a BSR is triggered (e.g., when new data arrives at the WTRU's transmission buffer), and when the WTRU has no available UL authorization (e.g., resources) to transmit a BSR, the WTRU can transmit a scheduling request (SR) to request UL resources to transmit the BSR.

[0144] Any of the following can be configured via RRC to control BSR: (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 logicalChannelGroup).

[0145] The MAC entity can determine the amount of UL data available for the logical channel, for example, based on a data volume calculation process performed at either the RLC or PDCP.

[0146] In data volume calculations, WTRU (e.g. at the RLC layer) may include any of the following: RLC data PDUs to be transmitted and / or retransmitted, RLC service data units (SDUs) (or segments of RLC SDUs) that may not yet be included in the RLC data PDUs, and any status messages to be transmitted, such as RLC STATUS PDUs as described in 3GPP TS 38.322 “Technical Specification NR; Radio Link Control (RLC) Protocol Specification (Release 17)” (V17.0.0).

[0147] The data volume calculation for the PDCP layer may include any of the following: any PDCP SDU that may not yet have been constructed into a PDCP data PDU, any PDCP data PDU that may not yet have been transmitted to a lower layer, any PDCP control PDU, and any PDCP SDU or PDU that can be retransmitted based on PDCP reconstruction and / or PDCP data recovery, as described in 3GPP TS 38.323 "Technical Specification NR; Packet Data Convergence Protocol (PDCP) Specification (Version 17)" (V17.0.0).

[0148] WTRU may trigger BSR if any of the following events occur.

[0149] In the first example, the WTRU can trigger the BSR if, for example, UL data belonging to a logical channel of an LCG becomes available to a MAC entity, and if the UL data belongs to a logical channel with a higher priority than any logical channel containing available UL data belonging to any LCG.

[0150] In the second example, the WTRU can trigger a BSR when UL data belonging to a logical channel of the LCG becomes available to the MAC entity, for example, and when no UL data is available on any logical channel belonging to the LCG. In either the first or second example, the BSR can be referred to as a "regular BSR".

[0151] In the third example, if UL resources are allocated and the WTRU has less data than allowed to send, the WTRU can trigger a BSR, and the number of padding bits can be equal to or greater than the size of the Buffer Status Report MAC CE plus its subheading. In the third example, the BSR can be referred to as a "Padding BSR".

[0152] In the fourth example, the WTRU can trigger a BSR if the 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 can (e.g., also) be referred to as a "regular BSR".

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

[0154] In the event that a regular BSR triggering event occurs simultaneously (e.g., concurrently) for more than one logical channel, (e.g., each) logical channel can trigger a separate regular BSR.

[0155] In the embodiments described herein, BSRs can be sent per LCG instead of per logical channel (LCH).

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

[0157] For example, LCHs with similar priorities can be linked to the same LCG. This allows gNB to differentiate between the amount of high-priority data and the amount of low-priority data.

[0158] Overview

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

[0160] XR services can include any of the interconnected sets of PDUs and data bursts, and can include PDUs of different importance (e.g., priority, type) within the same bearer (e.g., mapped to the same LCID, or mapped to different LCIDs belonging to the same LCG, etc.) and any of the PDU sets. For example, BSR triggering based solely on the arrival of new data or high-priority data may not allow for the resolution of XR service characteristics.

[0161] The embodiments described herein can allow for enhanced BSR triggering mechanisms in NR to accommodate the interrelationships and differences between PDU sets in XR and PDUs within any data burst.

[0162] An overview of BSR / SR triggering based on the remaining time for transmitting the PDU set and the amount of incomplete data for the PDU set.

[0163] The embodiments described herein can facilitate (e.g., accelerate) the transfer of a PDU set before the PSDB of the PDU set may have expired.

[0164] In one implementation, the WTRU can be configured to trigger a BSR / SR when at least one parameter associated with the transmission of the PDU set is satisfied. For example, the WTRU can be configured to trigger a BSR / SR when the TTL of the PDU set is lower than (e.g., a configured) time period (e.g., a threshold) and the amount of unprocessed data in the PDU set is higher than the buffer size (e.g., a threshold).

[0165] For example, in the first step, the WTRU may receive configuration (e.g., configuration information indicating the configuration) for sending a buffer status report (BSR) or scheduling request (SR) associated with the PDU set, wherein the BSR / SR may be triggered if one or more of the following conditions are met.

[0166] In the first example, a BSR / SR can be triggered if the amount of unprocessed (e.g., buffered) data in the PDU set (e.g., any of the multiple PDUs, data size in bytes, percentage of PDUs, etc.) is greater than (e.g., the configured buffer size, such as a threshold).

[0167] In the second example, BSR / SR can be triggered if the TTL of the PDU set is lower than (e.g., a configured time period, such as a threshold).

[0168] For example, in the second step, the WTRU can monitor either the size of the PDU set in the UL buffer or the TTL of the PDU set (e.g., the TTL of the LCG associated with the PDU set).

[0169] For example, in the third step, when it is determined that the buffer size of the PDUs to be transmitted in the PDU set is greater than the buffer size (e.g., a threshold) and / or the TTL is less than the time period (e.g., a threshold), the WTRU can transmit the BSR / SR associated with the PDU set.

[0170] Overview of BSR / SR triggering based on PDU set availability information

[0171] The embodiments described herein can allow information about a PDU set (e.g., detailed information) to be sent to the network, for example in a BSR, after the PDU set information becomes available at the WTRU and / or after the PDU set information may have changed during the PDU set's lifetime, enabling the network to schedule the WTRU in an improved manner. The information about the PDU set described herein (e.g., detailed information) 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 uplink traffic information" may be used interchangeably.

[0172] In one implementation, the WTRU can be configured to trigger one or more BSRs / SRs associated with a PDU set, which may depend on information about the PDU set available to the WTRU.

[0173] In the first example, after the arrival of any of the PDUs in the PDU set (e.g., any of the first, middle, or last PDUs), the WTRU may trigger a BSR / SR associated with the PDU set, provided that the WTRU has detailed information about the PDU set (e.g., the size of the PDU set (e.g., in terms of the number of PDUs), period, PSDB, type, importance, etc.). This detailed information may be included in the PDU header. In another example, the application layer may make detailed information available to the WTRU (e.g., its network layer). The WTRU may include detailed information about the PDU set in, for example, a BSR. In yet another example, simplified information may be provided, such as the size and timing window when all data is expected to be available at the WTRU buffer.

[0174] In the second example, if the WTRU does not have (e.g., detailed) information about the PDU set at that time (e.g., the PDUs may not include 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 associated with the PDU set after the arrival of the first PDU in 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 intermediate PDUs that may contain (e.g., detailed) information, or the last PDU in the PDU set that has (e.g., detailed) information, the WTRU may send a second BSR / SR associated with the PDU set, which may include correct (e.g., updated) size / timing information. The BSR / SR may include simplified (e.g., summarized) information, such as indications of requests for any resource with more / fewer resources, reductions / increases in preferred timing windows for resource availability, etc.

[0175] Overview of BSR / SR triggering based on radio conditions and conditions associated with the ongoing PDU set.

[0176] The embodiments described herein can facilitate (e.g., accelerate) the scheduling of an ongoing PDU set before a mobility event (e.g., handover) can be anticipated, 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 delays and / or UL interruptions during handover without causing PSDB expiration.

[0177] In one implementation, the WTRU can be configured to trigger BSR / SR based on any of the radio conditions (one or more) and conditions (one or more) associated with the ongoing set of PDUs.

[0178] For example, the WTRU can receive configuration for triggering a BSR / SR (e.g., configuration information indicating the configuration), which may depend on one or more of the following conditions.

[0179] In the first conditional example, a BSR / SR can be triggered based on one or more radio conditions for the source and / or the target.

[0180] In the second conditional example, BSR / SR can be triggered based on the remaining PDUs in the ongoing PDU set (e.g., any of the multiple ongoing PDU sets, the size of the remaining PDUs in the PDU set, etc.), where (i) all PDU sets can be considered, or (ii) a portion of the PDU set (e.g., only) can be considered (e.g., a PDU set with a type or importance, a PDU set with PSDB below a threshold, a PDU set with TTL below a threshold, a PDU set with (e.g., only) a percentage / number of PDUs to be transmitted, etc.).

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

[0182] the term

[0183] Throughout the embodiments described herein, the terms "node" and "network element" are used interchangeably.

[0184] In all embodiments described herein, the network may include, for example, any of the following: base stations (e.g., gNB, Transmit / Receive Point (TRP), RAN node, access node), core network functions (e.g., AMF), and application functions (e.g., edge server functions, remote server functions).

[0185] In all embodiments described herein, the term "source" may refer to the node or cell that the WTRU may have initially connected to.

[0186] In all embodiments described herein, the term "target" may refer to the node or cell that is switched due to either the CHO or the Dual Active Protocol Stack (DAPS) handover execution of the WTRU.

[0187] In the embodiments described herein, the terms “conditional switching,” “conditional configuration,” and “conditional reconfiguration” are used interchangeably.

[0188] This document describes embodiments relating to UL data transmission. In all embodiments described herein, expressions such as “PDU received at WTRU” may be referred to herein as “PDU received (e.g., obtained) from the application layer at WTRU radio buffer(s)(one or more).

[0189] Throughout the solution described in this article, the terms “PDU” and “group” are used interchangeably.

[0190] In the embodiments described herein, the term “trigger” may be used interchangeably with either “send” or “transmit”.

[0191] This document describes an implementation of a WTRU sending a BSR (Background Report) about a set of PDUs. A WTRU configured to send another (e.g., type) indication / information (e.g., any of non-BSR MAC CE, RRC message, etc.) providing reporting information about the set of PDUs can be used in the implementation described herein, wherein the WTRU may or may not include buffer size (e.g., tier) information. In the embodiments described herein, the terms BSR, reporting information, and uplink information report are used interchangeably.

[0192] In all embodiments described herein, a flow can correspond to either a QoS flow or a data flow (e.g., a data flow may include one or more PDUs or Application Data Units (ADUs) that may be associated with one or more QoS expectations (e.g., requirements) (e.g., latency, data rate, reliability, any of these). For example, different flows originating from a common (e.g., application, experience) source and / or intended to be sent to a common destination device (e.g., WTRU) or associated device (e.g., WTRU) may herein be referred to as associated flows or related flows.

[0193] In the embodiments described herein, the expression "forwarding configuration" may correspond to forwarding information indicating any of the following: (i) radio bearers (e.g., data radio bearers (DRBs) and / or signaling radio bearers), (ii) logical channels (LCHs), (iii) logical channel groups (LCGs), (iv) configuration parameters in various layers within the access layer (AS) protocol stack (e.g., any of the Service Data Adaptation Protocol (SDAP), PDCP, RLC, MAC, PHY, and other new protocol layers), and (v) configuration parameters related to logical channel optimization. The parameters associated with Priority Ordering (LCP) (e.g., any of priority, Prioritized Bit Rate (PBR), Buffer Size Period (BSD)) and (vi) Bandwidth Part (BWP), (vii) Carrier, (viii) Radio Link / Interface (Uu Link, Side Link (SL)) and (ix) Radio Resources (e.g., a set of one or more frequency / time / space resources, such as any of time slots, subcarriers, and beams). Radio Resources may be associated with configured licenses and / or dynamic licenses and / or any other licensed or unlicensed resources.

[0194] In the embodiments described herein, the expression “mapping configuration” may correspond to any of the following parameters and / or configurations associated with the following mapping: from one or more (1) application data (e.g., PDU set) streams, (e.g., associated or unassociated) QoS streams to (2) one or more radio bearers, SDAP, PDCP, LCH, carrier or component carriers (e.g., CC in CA configuration), BW, and radio links / interfaces (e.g., Uu links and / or side links), which may be used to deliver PDUs, for example, in the UL or DL ​​direction.

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

[0196] In a first example, which may be referred to as PDU set processing, a PDU set (e.g., any media unit or video frame) may include one or more PDUs. The PDU set may be associated with a PDU set-level QoS (e.g., requirement) attribute (e.g., any of data rate, latency, reliability), which may apply to one or more or all PDUs associated with the PDU set. Different PDUs in the PDU set may be associated with individual PDU-level QoS (e.g., requirement) attributes. Such associations and interdependencies may be visible to the AS layer (e.g., with associated IDs) and / or processed at the AS layer if the associations are known during data transmission and reception.

[0197] In a second example, which may be termed application / higher-level importance / priority, different PDUs or all PDUs in a PDU set can be associated with different application / higher-level importance / priority values. Such values ​​(e.g., importance, priority, rank) can correspond to spatial (e.g., importance) values ​​and / or temporal (e.g., importance) values. Spatial (e.g., importance) values ​​can include, for example, the spatial location of video frames whose data can be carried by the PDU / PDU set, where a PDU / PDU set carrying a field-of-view (FoV) spatial location can be associated with a higher spatial (e.g., importance) value compared to a non-FoV spatial location. Temporal (e.g., importance) values ​​can include, for example, a temporal sequence of video frames whose data can be carried by the PDU / PDU set, where a PDU / PDU set carrying a basic video frame (such as an I-frame) can be associated with a higher temporal (e.g., importance) value than a differential video frame (such as a P-frame / B-frame). For example, such (e.g., importance) values ​​are visible to the AS layer (e.g., with associated ID / tag / indicator), and are achieved through application awareness during data transmission and / or reception.

[0198] In a third example, which could be referred to as QoS flow processing, the application's PDU / PDU set can be encoded and passed by the application (e.g., a layer) via one or more QoS / data flows to the WTRU (e.g., for data flowing in the UL) or the network (e.g., for data flowing in the DL). For example, different QoS flows carrying PDU / PDU sets associated with an XR application (e.g., an experience) can be visible to the AS layer (e.g., with an associated ID) and / or processed at the AS layer if the association is known during data transmission and / or reception.

[0199] In all embodiments described herein, the statement “WTRU may be in the middle of transmitting / receiving packets belonging to any PDU set and data burst” can refer to a scenario where one or more PDUs in any PDU set and data burst may have been transmitted / received or may be transmitted / received, while other PDUs may remain in the WTRU / gNB buffer awaiting transmission. The expression “in progress PDU set or data burst” can be used to refer to incomplete PDUs in a PDU set or data burst (e.g., unsuccessfully transmitted in the UL case and awaiting transmission by the WTRU, and unsuccessfully received in the DL case and awaiting reception by the WTRU). The above expressions and terms can also be applied to situations where one or more packets associated with any of the PDU set, data burst, and QoS flow may be awaiting transmission at the application / higher layer and / or may not yet have arrived at the lower-layer buffer of the WTRU / gNB for UL / DL transmission. The WTRU / gNB may know which packets may be awaiting transmission at the application / higher layer based, for example, application (e.g., Non-Access Stratum (NAS)) layer indications and / or markings in previously received packet headers. The above expressions and terms can also be applied to non-XR services, which may include one or more independent PDUs in any QoS stream, for example, without any association with a PDU set, media / video frame or data burst.

[0200] For example, according to any implementation described herein, the WTRU may ignore (e.g., disregard) a BSR prohibition time that may be running due to a conventional BSR mechanism used to determine the triggering of a BSR for a PDU set (e.g., the WTRU may stop the BSR prohibition timer and may send a BSR associated with the PDU set).

[0201] In all embodiments described herein, the PDU set is used as an example of data that can send reporting information. The embodiments described herein are not limited to the PDU set, but can be applied to any kind of data, such as delay-critical data.

[0202] Throughout the embodiments described herein, the terms “PDU set” and “delayed critical data” are used interchangeably.

[0203] In all embodiments described herein, the terms “size of buffered data”, “amount of buffered data”, “amount of incomplete buffered data in a PDU set”, “buffer size of PDUs to be transmitted in a PDU set”, and “amount of remaining data to be transmitted in a PDU set / for a PDU set” are used interchangeably.

[0204] Configuration

[0205] The WTRU can receive configuration information to support any procedures, mechanisms, rules, actions, etc., related to buffer status reporting described herein. The WTRU can receive configuration information to support any procedures, mechanisms, rules, actions, etc., described herein at any time, such as when the WTRU is in connected mode, or when the WTRU can resume connection from a suspended state, or when the WTRU can establish a connection from an idle state or re-establish a connection after a failure.

[0206] This configuration information may be received by the WTRU from the network via any of the following: (i) HO commands (e.g., any RRC reconfiguration message indicating synchronous reconfiguration), (ii) CHO configuration, (iii) RRC recovery messages, and (iv) any other (e.g., RRC) messages.

[0207] For example, the WTRU can receive any configuration information element through any of the following: (i) broadcast signaling (e.g., SIB), (ii) dedicated signaling, (iii) NAS layer signaling, and (iv) application layer signaling (e.g., messages). Instances of dedicated signaling may include any RRC signaling and / or messages, such as any of the following: RRC reconfiguration, CHO configuration, DAPS HO command, RRC measurement report configuration, RRC recovery, RRC establishment, etc. An example of NAS layer signaling may include any of the following: PDU session establishment response and PDU session modification command.

[0208] The configuration information that the WTRU can receive from the network may include one or a combination of the following information.

[0209] For example, configuration information can indicate any of the following: mapping configuration, forwarding configuration, and resource configuration and / or corresponding parameters.

[0210] For example, WTRU can receive one or more sets of configuration and / or configuration parameters that will be applied to different layers of the protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, and any new layer). Configuration parameters can include any of the following parameters.

[0211] For example, SDAP parameters can indicate any of the following: one-to-one (e.g., 1 to 1), one-to-many (e.g., 1 to M), and many-to-many (e.g., N to M) mapping configurations; tags / indicators / IDs to be applied (e.g., associated with any of the QoS flows, PDU sets, or data bursts); association information indicating the 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.

[0212] For example, the PDCP parameter can indicate any of the rules and criteria used to map PDUs and / or sets of PDUs, and / or data bursts to two or more RLC entities / LCHs / branches.

[0213] For example, PDCP parameters can indicate any of the rules and criteria used to assign sequence numbers (e.g., any of the count range, superframe number (HFN) range, and SN range) to PDUs and / or PDU sets and / or data bursts.

[0214] For example, the PDCP parameter can indicate the robust header compression (RoHC) configuration applied to branches associated with the source and / or destination.

[0215] For example, PDCP parameters may include security (e.g., encryption) parameters to be applied to branches associated with the source and / or the destination.

[0216] For example, PDCP parameters may include indications and / or flags indicating whether any grouped replication is applied.

[0217] For example, PDCP parameters can include any of the rules and criteria used for discarding PDU sets and / or data bursts (e.g., discard timers).

[0218] For example, PDCP parameters may include any of the rules and standards used to ensure the orderly transmission of PDUs, and / or PDU sets and / or data bursts.

[0219] For example, RLC parameters can indicate the mode (e.g., acknowledged mode (AM), unacknowledged mode (UM), transparent mode (TM)) and the parameters to be applied to the branches associated with the source and / or the target.

[0220] For example, MAC parameters may indicate any of the rules and criteria applied to LCH / MAC entities in tributaries associated with the source and / or destination, including any of the following: (i) LCH parameters (e.g., priority, PBR, BSD), (ii) LCPs (e.g., rules and / or restrictions for handling PDU sets and / or data bursts, time periods for changing between different LCP rules), and (iii) configurations for multiplexing PDU sets / data bursts into transport blocks (TBs).

[0221] For example, the PHY parameter can indicate one or more Hybrid Automatic Repeat Request (HARQ) configurations (e.g., the number of repeats allowed).

[0222] The WTRU may receive information indicating at least one set of configuration parameters associated with a default configuration that may be activated and / or used during a first (e.g., normal) operation, such as for transmitting and / or receiving data during HO. The WTRU may also receive information indicating another set of configuration parameters that may be associated with a second (e.g., abnormal) operation, such as being activated and / or used when any triggering event / condition is detected during HO.

[0223] For example, configuration information may include validity information. For instance, the WTRU may receive validity information associated with any of the forwarding configuration, resource configuration, and BSR triggering configuration, indicating whether (e.g., when) the configuration can be considered valid or invalid based on one or more triggering events / conditions. The WTRU may also receive information indicating whether configurations can be deactivated and / or released when they are determined to be invalid.

[0224] Example of WTRU action

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

[0226] In the first example, WTRU actions can correspond to performing measurement and reporting actions. For example, the WTRU can perform measurements on any of the following: (1) the posture (e.g., 6DoD / 3DoD orientation, location / positioning) and (2) the rate of motion (e.g., movement) of any of the user, the WTRU, and any other object (e.g., virtual or real) that the user may interact with. The WTRU can periodically and after detecting an event trigger (e.g., a change in posture measurement values ​​above / below a threshold) send (e.g., report) information indicating the posture measurement results to the network.

[0227] For example, a WTRU can perform measurements of one or more of the following: (i) reference signals (e.g., any of the Synchronization Signal Block (SSB), Channel State Information Reference Signal (CSI-RS), Positioning Reference Signal (PRS), and Side Link Reference Signal (RS)); (ii) Global Navigation Satellite System (GNSS) signals; (iii) unlicensed carriers; (iv) ultra-wideband signals; (v) Light Detection and Ranging (LIDAR) signals; and (vi) visual signals, etc.

[0228] In another example, the WTRU can perform measurements on any wireless link interface associated with the WTRU (such as a Uu link, SL).

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

[0230] For example, performing measurement (one or more) and reporting actions (one or more) may include sending measurement report information to the network and / or another WTRU.

[0231] In the second example, the WTRU action could correspond to processing / forwarding data / PDU / PDU sets and processing the QoS associated with the PDU / PDU sets.

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

[0233] For example, a WTRU can send and / or receive data to / from one or more destinations, including any of the following: RAN nodes (e.g., gNBs), CN functions / entities, and application functions (e.g., hosted in a WTRU or network).

[0234] For example, when configured to perform DAPS handover and / or when configured with one or more DAPS radio bearers, the WTRU can transmit data to and / or receive data from a source and / or a target, including user plane and / or control plane data. In one example, the WTRU can perform such UL transmission and / or DL ​​reception one at a time via the source or target. In another example, the WTRU can perform such UL transmission and / or DL ​​reception simultaneously (e.g., concurrently) via the source and target (e.g., both).

[0235] For example, WTRU can perform any operation during transmission and / or reception that splits and merges data and / or PDUs from one or more QoS streams into one or more forwarding configurations.

[0236] In the third example, WTRU actions may correspond to processing / forwarding information related to connections to the network and / or other WTRUs.

[0237] For example, WTRU actions may include sending capability information to the network, which indicates any of the following: the ability to support one or more interfaces, the ability to coordinate with other WTRUs / devices, and / or (e.g., via the SL interface) interact with other WTRUs / devices, wherein, for example, the WTRU / device may be in the same location as the WTRU or in a different location.

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

[0239] For example, WTRU actions may include sending and / or receiving auxiliary data to / from a network associated with any of the services, QoS, scheduling, etc., used to support UL / DL transmissions.

[0240] For example, WTRU actions may include sending a request for radio resources and / or resource grants (e.g., dynamic grants, semi-static grants, or configuration grants).

[0241] For example, a WTRU action can correspond to triggering a HO and the data transmission / reception during the HO.

[0242] For example, WTRU actions may include determining whether and when to trigger initial access to the target.

[0243] For example, WTRU actions may include transmitting or receiving initial access messages to the target during HO execution.

[0244] For example, WTRU actions may include receiving RRC messages (such as HO commands) from a source.

[0245] For example, WTRU actions may include transmitting an RRC message to the target (e.g., RRC reconfiguration complete).

[0246] For example, WTRU actions may include determining whether to transmit any UL data (e.g., PDU sets, data bursts) to the source and / or destination.

[0247] For example, WTRU actions may include determining whether and when to release the connection to the source.

[0248] It involves various aspects of mapping PDU sets, bearers, logical channels, etc.

[0249] A PDU set may include one or more PDUs.

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

[0251] The size of a PDU set can be variable, from one PDU set to another.

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

[0253] The remaining latency (TTL) of the PDU set (e.g., related to the PSDB) can be equal to the PSDB minus the total time elapsed since the first PDU in the PDU set may have arrived (e.g., been stored) in the WTRU transport buffer.

[0254] In some examples, PDUs in a PDU set may have different characteristics (e.g., type, importance), and it may be desirable to determine the path of PDUs in the PDU set based on combinations of these characteristics (e.g., type, importance, etc.). For example, WTRU can determine or estimate the characteristics of different PDUs within the PDU set at the beginning of the first PDU in the PDU set (e.g., based on information from the application layer and / or based on information about the headers of the first or first few PDUs at the beginning of the first PDU set, etc.).

[0255] For example, a data burst may contain sets of PDUs with different characteristics (e.g., different types, sizes, importance levels, PSDBs, etc.), and it may be desirable to determine the path of the data burst based on combinations of the characteristics of the PDU sets. For example, WTRU may determine or estimate the characteristics of different PDU sets in the data burst at the beginning of the first PDU set (e.g., based on information from the application layer and / or based on the header information of the first or first few PDUs at the beginning of the first PDU set, etc.).

[0256] During UL transmission, the WTRU can perform a mapping of data units (e.g., any of PDUs, PDU sets, or data bursts) received from an upper layer (e.g., an application) in one or more QoS flows (e.g., QoS Flow Identifiers (QFIs)) to one or more forwarding configurations, which include combinations of different DRBs and / or LCHs.

[0257] Figure 4A and 4B This is a diagram showing six examples of forwarding configurations used at the AS layer for mapping XR data units during UL transmission.

[0258] In one example relating to the first configuration 41, the WTRU may receive one or more PDUs associated with the first PDU set 411 and the second PDU set 412 in the first QFIQFI1 and the second QFIQFI2, respectively. The received PDU sets may be mapped at the SDAP sublayer / entity to a first DRB (e.g., PDCP1) and a second DRB (e.g., PDCP2). For example, each PDCP entity (e.g., PDCP1 and PDCP2) may be configured to support sequential 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, for example, corresponding to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets 411, 412 into one or more TBs for UL transmission, the MAC entity / sublayer can, for example, ensure that the QoS (e.g., PSDB) of PDU sets 411, 412 in each LCH is met based on PDU set parameters (e.g., priority) and / or by using the LCP procedure.

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

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

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

[0262] In another example related to the fifth configuration 45, the WTRU may receive one or more PDUs associated with the first PDU set 451 and the second PDU set 452 in QFIQFI1. The received PDU sets 451, 452 may be mapped to a DRB (e.g., PDCP) at the SDAP sublayer / entity. The PDUs of the first PDU set 451 and the second PDU set 452 may be mapped to the first LCH1 and the second LCH2, for example, which correspond to RLC1 and RLC2 respectively. For example, during the scheduling and / or multiplexing of PDU sets 451, 452 into one or more TBs for UL transmission, the MAC entity / sublayer may, for example, ensure that the QoS (e.g., PSDB) of PDU sets 451, 452 in the respective LCHs is satisfied based on PDU set parameters (e.g., priority) and / or using the LCP procedure.

[0263] 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 in QFIQFI1. The received PDU sets 461, 462 may be mapped at the SDAP sublayer / entity to a first DRB DRB1 (e.g., PDCP1) and a second DRB DRB2 (e.g., PDCP2). Each PDCP entity (e.g., PDCP1 and PCDP2) may be configured to support ordered delivery of 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, for example, which correspond to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets 461, 462 into one or more TBs for UL transmission, the MAC entity / sublayer can, for example, ensure that the QoS (e.g., PSDB) of PDU sets 461, 462 in each LCH is met based on PDU set parameters (e.g., priority) and / or by using the LCP procedure.

[0264] Examples of BSRs associated with one or more PDU sets

[0265] A BSR triggered according to any of the embodiments described herein can be a conventional BSR. For example, a BSR may include information about an LCG and the corresponding buffer level. A WTRU can be configured to ensure that an LCG corresponding to a set of PDUs that may have triggered a BSR is included in the BSR. For example, if a PDCP of a bearer containing a set of PDUs is associated with an LCH x, and if that LCH x is mapped to an LCG y, information about LCG y can be included in the BSR. In determining the buffer level to be reported in the BSR, the WTRU can be configured to consider (e.g., only consider) buffered data from one or more sets of PDUs that may have triggered a BSR. For example, non-XR traffic mapped to an LCH may not be counted in the buffer calculation, where the LCH may be mapped within the same LCG as the XR traffic that triggered the BSR. In another example, XR traffic mapped to the same LCG and belonging to a class that may not yet have triggered a BSR may not be counted in the buffer calculation.

[0266] Depending on the available UL authorization, the WTRU may include information about other LCGs (e.g., LCGs that may not have XR services, such as no PDU set that can be mapped to them, or LCGs that contain XR services other than those that may have generated BSRs).

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

[0268] For example, a BSR can indicate the PDU set identifier.

[0269] For example, BSR can indicate the importance level of a PDU set.

[0270] For example, BSR can indicate the PDU set type.

[0271] For example, a BSR can indicate whether the PDU set integration processing indication (PSIHI) is (e.g., indicating whether the PDU set (e.g., all) of the PDUs can be received at the receiver application layer before the PDU set can be decoded / used).

[0272] For example, BSR can indicate the PDU set PSDB.

[0273] For example, a BSR can indicate the TTL of a set of PDUs (e.g., when constructing a BSR).

[0274] For example, a BSR can indicate the total size of the PDU set (e.g., the number of PDUs, the size in bytes, etc.).

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

[0276] For example, a BSR can indicate the size of the set of PDUs that may (e.g., still) be transmitted at the application layer (e.g., as an absolute value, as a percentage of the total PDU set size, in bytes, in the number of PDUs, etc.). For example, a BSR can indicate one or more time windows / size values ​​that indicate the expected size of the data and the expected time window when said data is expected to be available at the WTRU.

[0277] Information regarding any of the importance level, type, PSDB, TTL, and PDU set size can be either (e.g., actual) values ​​or index values, which can be used to refer to one or more values. For example, a PSDB can be categorized 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, etc.), and the BSR can include (e.g., only) index n associated with the PSDB.

[0278] Different BSR buffer size index tables can be configured 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.). Considering that PDU sets may have different ranges of PDU set sizes, determining the BSR report size to include the maximum possible PDU size regardless of the PDU set characteristics may not be efficient.

[0279] A BSR associated with a PDU set may contain (e.g., only) information about one PDU set or more than one PDU set (e.g., based on UL authorization).

[0280] WTRU can be configured to send a BSR for one or more PDU sets without using MAC CE, and to send a BSR for one or more PDU sets using RRC messages. For example, if the BSR is for multiple PDU sets and / or if additional information such as buffer level information is to be included, sending buffer-related information via RRC instead of MAC CE can allow for more detailed information to be included.

[0281] SR aspect

[0282] In all embodiments described herein, the WTRU may trigger the SR (i.e., as in conventional NR operation) if the WTRU has determined that the conditions for triggering the BSR can be met and if no UL resources are available to send the BSR.

[0283] An SR that can be sent based on a BSR associated with a PDU set triggered according to any of the embodiments described herein may differ from an SR sent based on a conventional BSR. For example, different SR resources can be configured (e.g., associated) for different types of PDU sets associated with the BSR and the BSR triggering conditions / causes (e.g., so that the network can be implicitly informed from the resources on which the SR can be sent, what kind of PDU set the BSR can reference, the cause that may have triggered the BSR, etc.). In one example, the WTRU may be configured with a periodic Physical Uplink Control Channel (PUCCH) resource for periodically sending SRs, wherein the configured periodic value of the Physical Uplink Shared Channel (PUSCH) resource may be associated with one or more periodic values ​​of the XR service (e.g., a periodic PDU set).

[0284] Periodicity of periodic BSR and PDU sets

[0285] In one implementation, the WTRU can be configured to send periodic BSR reports for one or more PDU sets. For example, the WTRU can be configured to send BSR reports for every nth PDU, based on any of the following: PDU set type, importance, PSDB range, etc.

[0286] In one example, a periodic BSR can be configured to have a period that matches the period of the ongoing PDU set (e.g., it can be equal to the PDU set period, or it can be a multiple thereof). In cases where there is more than one ongoing PDU set with different periods (e.g., period 1, period 2, period 3, etc.), the WTRU can be configured to send the periodic BSR with a period equal to any of the periods of the PDU sets, such as the maximum period, minimum period, average / median period, etc. For example, the WTRU can be configured to use the period of any of the PDU sets with the highest importance, a specific type, etc.

[0287] BSR for network triggering of one or more PDU sets

[0288] The implementation described herein focuses on BSRs 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.

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

[0290] This document has described an embodiment using an example of BSR / SR triggering. WTRU can use signaling from any protocol layer (e.g., any information from uplink control information (UCI), MAC CE, RRC, etc.), any information about the PDU set that is sent autonomously and / or at the request of the network (e.g., dynamic information indicating pending transmission (e.g., the size of the buffer in progress) and any information from static or semi-static information indicating the type or importance of the PDU set) to apply to the embodiments described herein.

[0291] The WTRU can be configured with behavior that can depend on any of the active bearers and application types. For example, the WTRU can be configured to apply any behavior according to any embodiment described herein if an active VR application is present, otherwise apply conventional behavior. In another example, the WTRU can be configured to apply the behavior according to any embodiment described herein if any active XR service (e.g., any of AR, VR, MR, etc.) is present. In yet another example, the WTRU can be configured to restrict operation according to any embodiment described herein to (e.g., only to) sets of PDUs and / or data bursts belonging to one or more bearers and / or LCHs and / or application types (e.g., any of AR, VR, MR, etc.).

[0292] This document has described embodiments using examples of enhancements related to XR applications and / or bearers. The embodiments described herein can be equally applied to any kind of service (e.g., application) where interdependencies may exist between PDUs, where the PDUs carried may have different types (e.g., importance), where bursts of interrelated PDUs may be received in a burst or half-cycle manner, etc. The embodiments described herein based on PDU sets, data bursts, frames, etc., can be applied to (e.g., mapped to) the behavior of this type of service / application / business.

[0293] BSR triggering based on conditions associated with PDU set delivery

[0294] For example, the conditions associated with PDU set delivery can be based on either the remaining time for PDU set delivery or the amount of incomplete data in the PDU set.

[0295] In one implementation, the WTRU can be configured to trigger a BSR / SR when at least one parameter associated with the transmission of the PDU set is satisfied. For example, the WTRU can be configured to trigger a BSR / SR when the TTL of the PDU set is lower than (e.g., a configured) time period (e.g., a threshold) and the amount of incomplete data in the PDU set is higher than the buffer size (e.g., a threshold).

[0296] For example, in the first step, the WTRU may receive configuration (e.g., configuration information indicating the configuration) for sending a buffer status report (BSR) or scheduling request (SR) associated with the PDU set, wherein the BSR / SR may be triggered if one or more of the following conditions are met.

[0297] In the first example, a BSR / SR can be triggered if the amount of incomplete (e.g., buffered) data in the PDU set (e.g., any of the number of PDUs, data size in bytes, percentage of PDUs, etc.) is greater than (e.g., the configured buffer size, such as a threshold).

[0298] In the second example, BSR / SR can be triggered if the TTL of the PDU set is lower than (e.g., a configured time period, such as a threshold).

[0299] For example, in the second step, the WTRU can monitor either the size of the PDU set in the UL buffer or the TTL of the PDU set (e.g., the TTL of the LCG associated with the PDU set).

[0300] For example, in the third step, when it is determined that the buffer size of the PDUs to be transmitted in the PDU set is greater than the buffer size (e.g., a threshold) and / or the TTL is less than the time period (e.g., a threshold), the WTRU can transmit the BSR / SR associated with the PDU set.

[0301] Examples of BSR triggering based on TTL and / or buffer level

[0302] In one implementation, the WTRU can be configured to trigger a BSR (Breakthrough Reporting) upon satisfaction of a first (e.g., time) condition (e.g., when the TTL of the PDU set is below a first threshold). This first threshold may be referred to herein as TTL_threshold. The first threshold for triggering BSR / reporting information associated with the PDU set (e.g., the LCG associated with the PDU set) may be indicated in the configuration information received by the WTRU. The configuration information (e.g., received by the WTRU) may indicate a PSDB (Power-Only Filtering Database) that will be used to calculate the TTL of the PDU set, so that the TTL can be compared with the first threshold to trigger BSR / reporting information associated with the PDU set.

[0303] In one example, TTL_threshold can be an absolute time period value (e.g., five milliseconds).

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

[0305] In one implementation, the WTRU can be configured to trigger a BSR when a second (e.g., buffer) condition is met, wherein the amount of buffered data in the PDU set (e.g., at any of PDCP, RLC, MAC) exceeds a second threshold, which may be referred to herein as buffer_threshold. The second threshold to be used to trigger BSR / reporting information associated with the PDU set can be indicated in the configuration information received by the WTRU.

[0306] In one example, buffer_threshold can be an absolute value (e.g., 500KB).

[0307] In another example, buffer_threshold can 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.).

[0308] In one implementation, the WTRU can be configured with one or more condition parameters (e.g., associated with one or more conditions), such as TTL_threshold and buffer_threshold. The WTRU can also be configured to trigger a BSR when it is determined that at least one of the conditions (e.g., a threshold) is met.

[0309] In one implementation, the WTRU can be configured to have at least two condition parameters (e.g., associated with at least two conditions), such as TTL_threshold and buffer_threshold. The WTRU can be further configured to trigger a BSR when it is determined that at least two conditions (e.g., two thresholds) are met.

[0310] In one embodiment, the WTRU may be configured to have multiple TTL_thresholds and buffer_thresholds (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).

[0311] In one embodiment, the configuration of multiple TTL_threshold and buffer_threshold values ​​can be explicit. For example:

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

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

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

[0315] etc.

[0316] In one embodiment, WTRU can be configured to have a relationship between conditional parameters (e.g., TTL_threshold and buffer_threshold) associated with different conditions. For example, when both thresholds are percentage values, WTRU can be configured to apply a linear mapping between the two thresholds, such as TTL_threshold = alpha * buffer_threshold. For example, if alpha equals 1, WTRU can trigger BSR if x% of the PSDB remains and WTRU has buffered more than x% of the PDU set. In another example, if alpha equals 2, WTRU can trigger BSR if x% of the PSDB remains and WTRU has buffered more than 0.5x% of the PDU set. Further constraints can be configured to ensure that this behavior is effective only when TTL_threshold is below a certain value (e.g., only in that case). For example, WTRU can be configured to apply the mapping only when TTL_threshold is below 40% (e.g., no BSR is triggered until 60% of the PSDB has passed).

[0317] In one solution, the WTRU can compare the buffer size with the buffer_threshold, which can be the amount of PDU set data already available in the WTRU (Radio Protocol Layer) buffer (e.g., PDCP and / or RLC and / or MAC, etc.).

[0318] In one implementation, the WTRU can compare the buffer size to a buffer_threshold that may take into account (e.g., include) PDUs in the PDU set that may not yet be available (e.g., stored) at the WTRU (Radio Protocol Layer) buffers (e.g., PDCP and / or RLC and / or MAC, etc.). For example, the WTRU may be informed of the size of the PDU set (e.g., header information in the first PDU received from the application layer), and the WTRU can determine the current buffer level by subtracting the amount (e.g., number) of data (e.g., PDUs) that has already been transmitted from the total PDU set size.

[0319] In one implementation, the WTRU can be configured to check (e.g., determine) how many PDUs or what percentage of the PDU set can (e.g., still) be transmitted (e.g., at the WTRU buffer) when a PDU is received from the application layer, and if that amount is greater than a threshold, the WTRU can trigger a BSR.

[0320] In one implementation, if a percentage / number of PDUs in the PDU set are buffered at the WTRU and no BSR associated with the PDU set is sent, the WTRU can be configured to send a BSR associated with the PDU set.

[0321] Control the number of BSRs sent

[0322] In one implementation, the WTRU can be configured to trigger a BSR associated with the PDU set if it has not been triggered prior to a previous BSR associated with the PDU set (e.g., during a prohibited period) triggered according to any implementation described herein. For example, if the prohibited period is set to infinity, the BSR associated with the PDU set may be sent only once, for example.

[0323] In one implementation, the WTRU can be configured to trigger a PDU-set-related (e.g., associated) BSR if the TTL and / or buffer level have changed by more than one value (e.g., any of quantity and percentage) since a previous BSR associated with a PDU set triggered according to any of the implementations described herein. For example, the WTRU can be configured to send a PDU-set-related (e.g., associated) BSR when the TTL is below 40% and the buffer remaining amount is above 50%. The WTRU can also be configured to send a subsequent BSR associated with the same PDU set when the TTL is below 10% and the buffer remaining amount is above 30%, and so on.

[0324] In one implementation, the WTRU can be configured not to trigger a BSR associated with the PDU set (e.g., related to the PDU set) during a prohibited period, provided that the BSR may have already been triggered based on a conventional BSR triggering mechanism, the BSR includes information about the LCG that may be associated with the PDU set, and the PDU set is already in progress when the conventional BSR may have been sent (e.g., some PDUs in the PDU set are already buffered in the WTRU). In a variation of this embodiment, instead of a prohibited time, the restriction can be in terms of increasing the buffer level since the conventional BSR was transmitted. For example, the WTRU can be configured to trigger a BSR associated with the PDU set (e.g., related to the PDU set) after the conventional BSR if more data (e.g., a percentage or absolute value) than the PDU set is buffered at the WTRU.

[0325] Aspects related to PDU set characteristics

[0326] In one implementation, WTRU can be configured to apply the behavior of any implementation described herein to any PDU set (e.g., regardless of any of the PDU set characteristics, such as PDU set type, importance, PSDB range, etc.).

[0327] In one implementation, WTRU can be configured to apply the behavior of any implementation described herein (e.g., only) to a set of PDUs for one or more characteristics, such as (e.g., only) to a set of PDUs for an importance level, and / or (e.g., only) to a set of PDUs for a type, and / or (e.g., only) to a set of PDUs for a PSDB value (or range), and / or (e.g., only) to a set of PDUs for a size (e.g., the number of PDUs in the set is greater than a value), and so on.

[0328] In one implementation, the WTRU can be configured to apply any different thresholds and different behaviors based on the characteristics of the PDU set. For example, the buffer level and / or TTL threshold used to trigger a BSR for a PDU set of any of the first importance level, first type, and first PSDB can be different from the buffer level and / or TTL threshold used for a PDU set of any of the second importance level, second type, and second PSDB, etc. Other parameters, such as the timer disable described herein, can be configured based on the PDU set type, importance, and any of the PDU set PSDB, etc.

[0329] Aspects related to multiple ongoing PDU sets

[0330] For example, there can be multiple sets of PDUs in progress (e.g., awaiting transmission).

[0331] In one implementation, the WTRU can monitor (one or more) BSR triggering conditions for (e.g., each) PDU set independently of other PDU sets (and can trigger the BSR independently if the conditions (one or more) of the PDU set (one or more) are met).

[0332] In one implementation, the WTRU may monitor (e.g., monitor only) one or more of the following BSR triggering conditions for a PDU set or subset of PDU sets: (i) importance level (e.g., monitor / trigger BSR for the PDU set with the highest importance), (ii) PDU set type (e.g., monitor / trigger BSR for the I-frame PDU set), (iii) PDU set with PSDB less than / greater than a value, (iv) PDU set with size greater than / less than a value, etc.

[0333] In one implementation, the WTRU may trigger a BSR based on any of the implementations described herein, and the WTRU may include information about (e.g., only) one set of PDUs in the PDU set, such as satisfying conditions (e.g., the set of PDUs with the highest importance, time, etc.) and / or information about more than one set of PDUs, such as satisfying conditions (e.g., the set of PDUs with an importance level higher than one level, the set of PDUs with a TTL lower than one level, etc.). Determining to include information about one or more PDU sets may further depend on the UL authorization information received by the WTRU. For example, if the UL authorization 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 authorization information is associated with a smaller number of resources, the WTRU may include (e.g., only) information about the PDU sets that satisfy conditions such as the highest importance, the shortest PSDB / TTL, etc.

[0334] In one embodiment, a disable timer that can be started when a BSR associated with a PDU set (e.g., associated with a PDU set) can prevent the transmission of subsequent BSRs associated with any PDU set (e.g., associated with any PDU set).

[0335] In one embodiment, a disable timer that can be started when a BSR associated with a PDU set (e.g., associated with a PDU set) can prevent (e.g., only) the transmission of subsequent BSRs associated with the same PDU set (e.g., associated with the same PDU set).

[0336] In one embodiment, a disable timer that can be started when a BSR associated with a PDU set can be sent can prevent (e.g., only) the transmission of a subsequent BSR associated with (e.g., associated with) a PDU set that has a QoS expectation (e.g., requirement) equal to or lower than that of a PDU set that may trigger a BSR (e.g., a longer PSDB, lower importance, etc.).

[0337] BSR triggering based on available information associated with the PDU set

[0338] In one implementation, the WTRU can be configured to trigger one or more BSRs / SRs associated with a PDU set, which may depend on information about the PDU set available to the WTRU. For example, the WTRU may receive configuration information that instructs (e.g., triggers) to report uplink service information associated with the PDU set, such as based on whether the information associated with the PDU set is available and / or changes over time.

[0339] In the first example, (e.g., only if) the WTRU has (e.g., detailed) information about the PDU set (e.g., any of the following: PDU set size (e.g., number of PDUs), period, PSDB, type, importance, etc.), the WTRU can trigger a BSR / SR associated with the PDU set after the arrival of a PDU in the set (e.g., the first PDU, the middle PDU, the last PDU). This (e.g., detailed) information can be included in the PDU header. In another example, the application layer can make (e.g., detailed) information available to the WTRU (e.g., its network layer). The WTRU can include (e.g., detailed) information about the PDU set in, for example, a BSR. In yet another example, simplified information can be provided, such as any of the size and timing window when (e.g., all) data is expected to be available at the WTRU buffer.

[0340] In the second example, if the WTRU does not have (e.g., detailed) information about the PDU set at that time (e.g., the PDUs may not include 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 (e.g., including initial / first information) associated with the PDU set after the arrival of the first PDU in 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 intermediate PDUs that may contain (e.g., detailed) information, may receive the last PDU in the PDU set that has (e.g., detailed) information, etc.), the WTRU may send a second BSR / SR associated with the PDU set, which may include the correct (e.g., updated) size / timing information. The BSR / SR may include simplified (e.g., summarized) information, such as indications of requests for any resource with more / fewer resources, reduction / increase of the preferred timing window for resource availability, etc.

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

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

[0343] In another example, when the first PDU of the PDU set is received at the WTRU buffer (e.g., in the packet header or as separate information), the PDU set information becomes available at the WTRU.

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

[0345] In another example, PDU set information becomes available at the WTRU when the last PDU of the PDU set is received at the WTRU buffer (e.g., in the packet header or as a separate message). If there is an indication that this is likely the last PDU of the PDU set, then the PDU size information can be implicitly determined by the WTRU.

[0346] In another example, PDU set information becomes available at WTRU after the last PDU in the PDU set has been received.

[0347] One or more PDU set information can be implicitly determined from other information (e.g., any of the following: (i) the mapping between PDU set type / importance and QoS flow identifier, (ii) the mapping between PDU set PSDB and PDU set type / importance, (iii) the mapping between PDU set importance and PDU set type, etc., (iv) the interrelationship or dependency between PDU sets in different related flows).

[0348] In one implementation, the WTRU can be configured to trigger a BSR associated with the PDU set (e.g., related to the PDU set) upon receiving the first PDU of the PDU set (e.g., even if limited or no detailed information about the PDU set is available at that time).

[0349] In one implementation, triggering a BSR upon receiving the first PDU of a PDU set may depend on whether the WTRU knows at least one of the following: (i) the type of the PDU set (e.g., triggering a BSR upon receiving the first PDU of a PDU set of a given type), (ii) the importance of the PDU set (e.g., triggering a BSR upon receiving the first PDU of a PDU set of a given importance), (iii) the PSDB (e.g., triggering a BSR upon receiving the first PDU of a PDU set only if the PSDB is below a threshold), and so on.

[0350] In one implementation, the WTRU can be configured to trigger a BSR associated with (e.g., related to) the PDU set upon receiving the last PDU of the PDU set.

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

[0352] In one implementation, when a percentage of the PDUs in the PDU set are received at the WTRU (Radio Equipment) buffer (e.g., when 50% of the PDUs in the PDU set are received), the WTRU can be configured to trigger a BSR associated with the PDU set (e.g., associated with the PDU set).

[0353] In an implementation where the WTRU has limited information about the PDU set (e.g., upon receiving the first PDU), this information may not include any size information, and the WTRU may send the size information in another message (e.g., any of MAC CE, RRC message, special SR, etc.) (e.g., instead of BSR).

[0354] In one implementation, the WTRU can be configured to send a traditional BSR (e.g., a buffer level indication at the LCG level) when the WTRU has limited or no information about the PDU set.

[0355] In one implementation, if the WTRU has limited or no information about the PDU set size when the BSR is triggered, the WTRU may include anticipated (e.g., envisioned) size information in the BSR. For example, the WTRU may estimate the size based on the size of a previous PDU set with the same characteristics (e.g., any of the following: PDU set type, importance level, etc.).

[0356] In one embodiment, the WTRU can be configured to include timing information (e.g., a time window when (e.g., the entire) set of PDUs might be expected to become available at the WTRU). In one example, the WTRU may include one or more size / timing information in a 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.).

[0357] In one implementation, the WTRU can trigger a first BSR associated with (e.g., linked to) the PDU set using limited / first information about the PDU set, and the WTRU can subsequently learn more detailed PDU set information. The WTRU can be configured to send a subsequent BSR that adds (e.g., modifies) information (e.g., previously sent) to the first BSR. For example, information about the PDU set can be sent (e.g., in a subsequent / second BSR) based on changes to previous / initial information reported previously / initially (e.g., in the first BSR).

[0358] For example, when the WTRU receives the first PDU from the application layer (e.g., the header may have already indicated that the PDU set is an important PDU set), it may have already sent a first BSR associated with (e.g., related to) the PDU set. For example, the first BSR might indicate that there is no size information, or it might indicate an estimated (e.g., expected) size and / or timing information. The WTRU may later receive more detailed information about the PDU set. For example, the WTRU might receive an intermediate PDU in the PDU set that indicates the size of the PDU set. In another example, the WTRU might receive the last PDU in the PDU set, and the WTRU might know the size of the PDU set. In yet another example, the WTRU might receive separate information about the size of the PDU set from the application layer. For example, the WTRU might send an updated BSR that may include detailed information. In one example, updating the BSR can indicate a reference to the previous BSR (e.g., the BSR can indicate either the BSR ID or the counter) and can include incremental / full information (e.g., any of the following: 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.).

[0359] In one implementation, after determining the details about the PDU set, the WTRU may include any of the special flags and indicators in the header of the PDUs in the PDU set that the WTRU may be sending, to indicate to the network that the WTRU may have detailed (e.g., complete) information about the PDU set. The network may send a message to the WTRU requesting the WTRU to send the detailed information about the PDU set (e.g., the WTRU may send the requested details in any of the subsequent BSR, RRC messages, etc.).

[0360] In one implementation, if the WTRU has indicated a different size (e.g., lower or higher) than the actual size of the PDU set in the first BSR that the WTRU may have sent, the WTRU may include information indicating that difference in the second BSR.

[0361] In one implementation, after obtaining detailed information about the PDU set, if the detailed information is similar (e.g., comparable) to the information provided in the first BSR (e.g., the current size is within a percentage of the size reported in the first BSR, the data arrival timing is within a percentage of the data arrival window indicated in the first BSR, etc.), the WTRU may send information confirming that the first BSR may have been sent along with the estimated information (e.g., any of the size, data arrival timing (e.g., arrival time), etc.).

[0362] In one implementation, WTRU can be configured to apply one or more behaviors described herein based on PDU set characteristics.

[0363] For example, (for example, only) if the importance level of the PDU set is equal to the value x, the WTRU can send a BSR on the first PDU in the PDU set.

[0364] For example, if detailed information about the PDU set (e.g., all of it) is available at the receiving point of the first PDU, the WTRU can send a BSR on the first PDU of the PDU set whose importance level is equal to or less than the value y.

[0365] For example, for a PDU with one or more characteristics (e.g., type), the WTRU may (e.g., only) send a BSR when the last PDU is received.

[0366] For example, for a PDU with one or more characteristics (e.g., type), the WTRU may (e.g., only) send a BSR after details about the PDU set become available.

[0367] For example, for a PDU of a certain type and / or importance, WTRU can send at most one BSR (e.g., the first PDU, even if details are not available at this time).

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

[0369] For example, (e.g., only if there is space available to fill the BSR) a BSR can be sent with respect to a set of PDUs of (e.g., given) type, PSDB, size.

[0370] In one implementation, the WTRU can be configured to trigger a subsequent BSR associated with the PDU set if a period of prohibition has elapsed since a first BSR associated with the PDU set may have been sent with (e.g., initial, limited, first) information. For example, if (e.g., detailed, subsequent, second) information may have become available, the WTRU may wait until the prohibition period expires before sending a subsequent (e.g., updated) BSR. For example, the WTRU may suppress the sending of (e.g., detailed, subsequent, second, updated) information about the PDU set in the BSR during a period of prohibition following the sending of (e.g., initial, limited, first) information about the PDU set in the first BSR. In a variation, this behavior may depend on the characteristics of the PDU set. For example, the WTRU may be configured to ignore the prohibition period if one or more characteristics associated with the PDU that triggered the BSR meet certain conditions (e.g., it is a PDU set of importance level x, type y, has a PSDB less than z, etc.).

[0371] In one implementation, the WTRU can be configured to trigger a subsequent BSR associated with the PDU set if detailed information about the PDU set becomes available within a given period of time after the first BSR associated with the PDU set is sent.

[0372] In one implementation, WTRU can be configured to apply any of the behaviors described herein (e.g., only) to a set of PDUs for one or more features. For example, WTRU can be configured to apply any of the behaviors described herein (e.g., only) to a set of PDUs for any of the following: (i) importance level, (ii) type, (iii) PSDB value / range, (iv) size (e.g., the number of PDUs in the set is greater than the value), etc.

[0373] In one implementation, the WTRU may have multiple ongoing (e.g., pending transmission) PDU sets. The WTRU may independently monitor the triggering conditions for subsequent BSRs for different PDU sets (and may independently trigger subsequent BSRs after detailed information about (e.g., each) PDU set becomes available).

[0374] In one implementation, the WTRU may have multiple ongoing (e.g., pending transmission) PDU sets (e.g., to be transmitted). The WTRU may monitor the subsequent BSR of one (e.g., only) PDU set or subset of the PDU set based on one or more of the following: (i) importance level (e.g., monitoring / triggering the subsequent BSR of the PDU set with the highest importance), (ii) PDU set type (e.g., monitoring / triggering the subsequent BSR of the I-frame PDU set), (iii) (e.g., only) PDU sets with a PSDB value less than one can trigger a subsequent BSR, and (iv) (e.g., only) PDU sets with a size greater than one can trigger a subsequent BSR, etc.

[0375] In one implementation, the WTRU may have multiple ongoing (e.g., pending transmission) PDU sets. The WTRU may trigger a BSR based on any of the embodiments described herein. The WTRU may include information about one (e.g., only) of the PDU sets (e.g., the PDU set with the highest importance, a given time, etc.), or may include information about more than one PDU set that meets certain criteria (e.g., a PDU set with an importance level higher than one level, a PDU set with a TTL / PSDB less than a threshold, etc.). Determining to include information about one or more PDU sets may be further based on UL authorization information received by the WTRU. For example, if the UL authorization information is associated with a large number of resources, the WTRU may include information about more than one (e.g., all) PDU sets. If the UL authorization information is associated with a smaller number of resources, the WTRU may include information about (e.g., only) PDU sets that meet certain criteria (e.g., any of the highest importance, shortest PSDB / TTL, etc.).

[0376] Condition-based BSR triggering

[0377] In one implementation, the WTRU can be configured to trigger BSR / SR based on any of the radio conditions (one or more) and conditions (one or more) associated with the ongoing set of PDUs.

[0378] For example, the WTRU can receive configuration for triggering a BSR / SR (e.g., configuration information indicating the configuration), which may depend on one or more of the following conditions.

[0379] In the first conditional example, a BSR / SR can be triggered based on one or more radio conditions for the source and / or the target.

[0380] In the second conditional instance, a BSR / SR can be triggered based on the remaining PDUs in the ongoing PDU set (e.g., any of the following: the number of ongoing PDU sets, the size of the remaining PDUs in the PDU set, etc.), where (i) all PDU sets can be considered, or (ii) a portion of the PDU sets can be considered (e.g., only a portion, such as a PDU set with a certain type or importance, a PDU set with a PSDB below a threshold, a PDU set with a TTL below a threshold, a PDU set with (e.g., only) a percentage / number of PDUs to be transmitted, etc.).

[0381] Under any conditions, the WTRU can send a BSR / SR to the network that includes information about the ongoing set of PDUs.

[0382] In one implementation, the WTRU can be configured to trigger the BSR based on one or more radio conditions.

[0383] For example, a WTRU can trigger a BSR if the cell radio quality metric (e.g., RSRP) associated with the current serving cell fails to meet quality conditions (e.g., below a threshold).

[0384] For example, a WTRU can trigger a BSR if the cell radio quality metric associated with the current serving cell fails to meet quality conditions (e.g., it is more than a threshold worse than the quality metric of neighboring cells).

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

[0386] Any radio conditions associated with any quality metric can be applied to the embodiments described herein, wherein the quality metric is associated with either the serving cell or a neighboring cell used to trigger BSR.

[0387] For example, in addition to or as an alternative to measurement reports, any measurement event (e.g., A1 to A6, etc.) can be configured to trigger a BSR.

[0388] In one implementation, when the WTRU (e.g., also) sends a measurement report, the buffer status information can be sent in an RRC message (e.g., in the measurement report, and / or in a different RRC message, etc.). Sending buffer-related information via RRC allows for the inclusion of more detailed information compared to a MAC CE-based BSR.

[0389] In one implementation, a BSR can be triggered based on one or more radio conditions, independent of the ongoing PDU set and / or independent of the amount of PDU set data that can be buffered at the WTRU.

[0390] In one embodiment, a BSR can be triggered if one or more (e.g., wireless) conditions for triggering a BSR are met and the (e.g., total) size of the buffered PDUs (e.g., all) of the ongoing PDU set meets a condition (e.g., above / below a threshold (e.g., total_buffer_threshold)). The size and / or condition (e.g., the threshold) can be in any of the bytes and number of PDUs.

[0391] In one implementation, the buffer size to be compared with total_buffer_threshold may include PDUs from one or more (related, ongoing) PDU sets that may not yet be available at the WTRU (Radio Protocol Layer) buffers (e.g., PDCP and / or RLC and / or MAC, etc.). For example, the size of the PDU set can be notified to the WTRU (e.g., based on header information in a first PDU received from the application layer), and the WTRU can determine the current total buffer level by subtracting the amount (e.g., number) of data (e.g., PDUs) from the total PDU set (one or more) size.

[0392] In one implementation, the WTRU can be configured with a set of radio conditions and buffer conditions (e.g., thresholds). For example, the WTRU can be configured to trigger a BSR based on any of the examples below.

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

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

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

[0396] In an embodiment, (for example) only the first type of PDU set may be included in the total buffer calculation, which may be compared with a threshold.

[0397] In one embodiment, (e.g., only) the set of PDUs of first importance may be included in the total buffer calculation.

[0398] In one embodiment, (e.g., only) a set of PDUs that satisfy a condition (e.g., PSDB is less than a threshold) may be included in the total buffer calculation.

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

[0400] In one embodiment, (e.g.) only the set of PDUs that meet the size criteria (e.g., a set of PDUs that is greater than / less than n PDUs, less than / greater than x bytes, etc.) can be included in the total buffer calculation.

[0401] In one embodiment, separate (e.g., different) buffer condition parameters (e.g., total_buffer_threshold) can be configured for different PDU sets (e.g., PDU sets with any of the following: type, importance level, PSDB range, size range, etc.). These (e.g., each) PDU sets can be further associated with one or more radio condition thresholds. For example, the WTRU can be configured to trigger BSR if any of the radio conditions and buffer conditions are met for one or more of the PDU sets of any of the following: type(s), importance level(s), PSDB range(s), etc. In another example, the WTRU can be configured to trigger BSR if (only) more than one of the conditions(s) of the following (or only all PDU sets) of any of the following (e.g., type(s), importance level(s), PSDB range(s), etc.) are met.

[0402] In one embodiment, either the buffer level and the wireless level condition parameters (e.g., threshold(one or more)) can be configured to be associated with a specific PDU set (e.g., a PDU set identified by a PDU set identifier (e.g., an identifier)) (e.g., dedicated to that specific PDU set).

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

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

[0405] In one embodiment, a BSR may include information about (e.g., only) a set of PDUs that may have triggered a BSR.

[0406] In one embodiment, a BSR may include (e.g., also include) information about a set of PDUs that may not have yet triggered a BSR (e.g., resource availability based on UL authorization).

[0407] In one implementation, the WTRU can be configured to trigger the BSR after recovery from the RLF (e.g., rebuilding, performing a CHO after the RLF causes the selection of a CHO-prepared cell, etc.) (e.g., immediately).

[0408] In one implementation, the WTRU can be configured to trigger the BSR immediately after a switchover is performed (e.g., immediately after receiving an HO command, performing a DAPS HO, a CHO, etc.).

[0409] In one implementation, the WTRU can be configured to trigger the BSR immediately after a transition from an idle (e.g., IDLE and inactive) state (e.g., in the case of a state transition triggered by the arrival of a set of UL PDUs based on any of the first type, first size, first importance, etc.).

[0410] In one implementation, the WTRU can be configured with a CHO configuration, which can be configured with two radio conditions (e.g., thresholds): a first radio threshold for triggering BSR (e.g., neighboring cell > serving cell + Thresh1), and a second radio threshold for triggering the execution of the CHO (e.g., neighboring cell > serving cell + Thresh2, where Thresh2 > Thresh1). Buffer-level associated conditions can be applied together with the first radio threshold (e.g., together; for example, if the buffer-related condition (e.g., threshold) is not met for the corresponding (e.g., ongoing) PDU set, then BSR may not be triggered).

[0411] In one implementation, the WTRU can be configured with a CHO configuration, which may include a radio threshold (e.g., neighboring cell > serving cell + Thresh1) and time period information. Upon meeting radio conditions, the WTRU can trigger a BSR (e.g., if a buffer-related threshold is met for the corresponding (e.g., ongoing) PDU set (e.g., also), and can wait (e.g., perform a CHO) until the configured time period has elapsed since the conditions were met and one or more of the PDU sets (one or more) that may have triggered the BSR were successfully transmitted.

[0412] In implementations, according to any of the embodiments described herein, if, for example, one or more buffer-related conditions for an ongoing PDU set(s) ...

[0413] Figure 5 This is a diagram illustrating an example method 500 for sending buffer status report information. Method 500 can be implemented in a WTRU.

[0414] As shown at 510, the WTRU can determine that one or more (e.g., first) conditions (e.g., remaining time for said transmission) associated with a transmission of one or more PDU sets can be satisfied, wherein, for example, a PDU set may include more than one PDU associated with each other.

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

[0416] In various implementations, the one or more conditions may be satisfied if the amount of buffered data that the WTRU will transmit and that is associated with one or more PDU sets satisfies a first condition.

[0417] In various embodiments, the first condition can be satisfied if the amount of buffered data to be transmitted by the WTRU exceeds a first threshold.

[0418] In various implementations, the amount of buffered data to be transmitted by the WTRU that satisfies the first condition may include PDUs from different PDU sets, wherein PDUs from different PDU sets may be associated with the same characteristics.

[0419] In various embodiments, the same characteristics may include any of the PSDBs of the same type, the same importance, and a value less than one.

[0420] In various embodiments, one or more conditions may be satisfied if the TTL associated with one or more PDU sets satisfies the second condition.

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

[0422] In various implementations, one or more of the conditions can be met if the first PDU in the PDU set is available for transmission by the WTRU.

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

[0424] In various implementations, after the WTRU has transmitted the first (e.g., buffer status) report information, information indicating one or more characteristics associated with the PDU set is available to the WTRU.

[0425] In various embodiments, one or more conditions may be satisfied if one or more radio conditions relating to either the source network element or the target network element are satisfied.

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

[0427] In various embodiments, one or more radio conditions can be satisfied if the first radio quality associated with the source network element is lower than the second radio quality associated with the target network element by a fourth threshold.

[0428] In various embodiments, one or more radio conditions may be satisfied if the radio quality associated with the target network element is above a fifth threshold.

[0429] In various implementations, the WTRU may also receive configuration information indicating one or more conditions associated with the transmission of one or more PDU sets.

[0430] In various implementations, the WTRU may receive first configuration information indicating a first condition associated with the remaining time for transmitting the PDU set.

[0431] In various embodiments, the first condition can be satisfied if the remaining time for transmitting the PDU set is less than a first threshold.

[0432] In various embodiments, a first condition can be met if the remaining time for transmitting the PDU set is less than a first threshold. In various embodiments, first configuration information can indicate the first threshold.

[0433] In various embodiments, the WTRU can determine that a second condition associated with the size of the buffered data can be met, and can transmit report information based on the determination that the second condition can be met.

[0434] In various implementations, the WTRU may receive second configuration information that indicates a second condition associated with the size of the buffered data.

[0435] In various embodiments, the second condition can be satisfied if the size of the buffered data is higher than the second threshold.

[0436] In various embodiments, the second condition can be satisfied if the size of the buffered data exceeds a second threshold. In various embodiments, the second configuration information can indicate the second threshold.

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

[0438] In various embodiments, the same characteristics may include any of the PSDBs of the same type, the same importance, and lower values.

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

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

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

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

[0443] Figure 6 This is a diagram illustrating an example method 600 for transmitting reporting information. Method 600 can be implemented in a WTRU. The WTRU may include circuitry comprising any of a processor, memory, transmitter, and 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 for triggering reporting information associated with a PDU set. As shown at 620, the WTRU may determine that the remaining time for transmitting a PDU set (e.g., one or more PDUs in the PDU set) is below the remaining time threshold. As shown at 630, the WTRU may transmit reporting information associated with 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 when the remaining time is below the remaining time threshold.

[0444] In various embodiments, the amount of remaining data to be transmitted in the PDU set can be indicated as an absolute value (e.g., in a report message).

[0445] In various embodiments, the amount of remaining data to be transmitted in the PDU set can be indicated in bytes (e.g., in a report message).

[0446] In various embodiments, the amount of remaining data to be transmitted in the PDU set (e.g., in a reporting message) can be indicated by an index involving one or more values.

[0447] In various embodiments, the report information may indicate the remaining time for transmitting the PDU set. In various embodiments, the indicated remaining time may be the remaining time at the time the report information is constructed.

[0448] In various embodiments, configuration information can be received in the radio resource control message.

[0449] In various embodiments, report information can be received in the MAC CE.

[0450] In various embodiments, a PDU set may include more than one PDU that can be associated with each other.

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

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

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

[0454] Figure 7 This is a diagram illustrating an example method 700 for transmitting uplink service information. Method 700 can be implemented in a WTRU. The WTRU may include circuitry, which includes any of a processor, memory, transmitter, and receiver. The circuitry may be configured to process method 700. As shown at 710, the WTRU may receive configuration information indicating uplink service information related to a reported PDU set. As shown at 720, the WTRU may transmit uplink service information based on (1) uplink service information becoming available or (2) uplink service information changing compared to previously reported uplink service information. In various embodiments, the uplink service information may indicate the identifier, arrival time, and service period of the PDU set.

[0455] In various implementations, the WTRU can suppress the transmission of subsequent uplink service information of the PDU set for a period of time after the uplink service information has been transmitted.

[0456] Any features, variations, or embodiments described for the method are compatible with apparatus for processing the disclosed method, devices including circuitry, computer program products including program code instructions, and non-transitory computer-readable storage media storing program instructions, wherein the circuitry includes any of a memory, a processor, a transmitter, and a receiver (e.g., operatively coupled to a processor), the circuitry being configured to process the disclosed method.

[0457] While features and elements have been provided for the foregoing in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure should not be limited to the specific embodiments described in this application, which are intended to illustrate various aspects. Many modifications and variations are possible without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly provided so, elements, actions, or instructions used in the description of this application should not be construed as critical or essential to the invention. Functionally equivalent methods and apparatus within the scope of this disclosure, in addition to those listed herein, will be apparent to those skilled in the art based on the foregoing description. These modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terminology of the appended claims and the full scope of their legally enjoyed equivalents. It should be understood that this disclosure is not limited to any particular method or system.

[0458] For simplicity, the foregoing embodiments are discussed in terms of the terminology and structure of devices with infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as sound waves.

[0459] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is 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 multiple images displayed over time. As another example, when referenced 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 transmitting and / or receiving unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a wireless and / or wired (e.g., tetherable) device configured with some or all of the structure and functions of a WTRU; (iv) a wireless and / or wired device configured with fewer than all the structure and functions of a WTRU; or (iv) a similar device. Figure 1A-1DDetails of exemplary WTRUs (which may be representative of any WTRU described herein) are provided. As another example, the various embodiments disclosed above and below herein are described as utilizing head-mounted displays. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and some or all of the contents of this disclosure and the various disclosed embodiments can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information for providing an adaptive, realistic experience.

[0460] Furthermore, the methods provided herein can 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-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0461] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the wide variety of applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be considered as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery) that provides any suitable voltage.

[0462] Furthermore, in the embodiments provided above, note the processing platform, computing system, controller, and other devices including the processor. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions can be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as being “executed,” “computer-executed,” or “CPU-executed.”

[0463] Those skilled in the art will understand that the actions and symbols representing operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits that can cause transformations or reductions of electrical signals and the maintenance of data bits at memory locations in a memory system, thereby reconfiguring or otherwise altering the operation of the CPU and other signal processing. The memory location maintaining the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the provided methods.

[0464] Data bits can also be maintained on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system. The computer-readable medium can include cooperative or interconnected computer-readable media that reside exclusively on the processing system or are distributed among multiple interconnected processing systems that may be located locally on or remotely from the processing system. It should be understood that the embodiments are not limited to the aforementioned memories, and other platforms and memories may support the provided methods.

[0465] In exemplary embodiments, any operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0466] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software is often (but not always, as the choice between hardware and software may become important in some cases) a design choice representing a trade-off between cost and efficiency. Various vehicles (e.g., hardware, software, and / or firmware) can exist to implement the processes and / or systems and / or other technologies described herein, and the preferred vehicle can vary depending on the context of deploying the processes and / or systems and / or other technologies. For example, if the implementer determines that speed and accuracy are paramount, the implementer may choose a vehicle that is primarily hardware and / or firmware. If flexibility is paramount, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0467] The foregoing detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Where such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or in combination by a wide variety of hardware, software, firmware, or virtually any combination thereof. In embodiments, several portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented, wholly or partially equivalently, in an integrated circuit as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuit systems and / or writing code for software and / or firmware according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as various forms of program products, and that exemplary embodiments of the subject matter described herein are applicable regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disks, CDs, DVDs, digital magnetic tapes, computer memory, etc., and transmission media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0468] Those skilled in the art will recognize that it is common practice in the art to describe devices and / or processes in the manner set forth herein, and subsequently to integrate such described devices and / or processes into data processing systems using engineering practice. 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 number of experiments. Those skilled in the art will recognize that a typical data processing system generally includes one or more of the following: a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, drivers, a graphical user interface and applications, one or more interactive devices such as a touchpad or touchscreen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or numbers). A typical data processing system can be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0469] The topics described herein sometimes illustrate different components included within or connected to different other components. It should be understood that the architectures described in this way are merely examples, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components implementing the same functionality is actively “associated” to achieve the desired functionality. Therefore, any two parts combined in this document to achieve a particular function can be considered “associated” with each other to achieve the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated parts can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two parts that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of being operablely coupled include, but are not limited to, physically matable and / or physically interactive components, and / or components that can wirelessly interact and / or perform wireless interactions, and / or logically interactive and / or logically interactive components.

[0470] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art can convert plural to singular and / or singular to plural as needed by the context and / or application. For clarity, various singular / plural substitutions may be explicitly described herein.

[0471] Those skilled in the art will understand that, in general, the terminology used herein, and particularly in the appended claims (e.g., the body of the appended claims), is intended to be “open-ended” (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “comprising” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if the intent is to recite a specific number of claims, such intent will be explicitly stated in the claims, and without such a statement, such intent does not exist. For example, the term “single” or similar language may be used where the intent is only for one item. To aid understanding, the appended claims and / or the description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce the recitation of claims. However, the use of such a phrase should not be construed as implying that the introduction of a claim recount by the indefinite article "a" limits any particular claim to include only one such recount, even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" (e.g., "a" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles for introducing a claim recount. Furthermore, even if a specific number of claims recount is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the number recounted (e.g., simply stating "two recounts" without other modifiers means at least two recounts, or two or more recounts). Furthermore, in instances where the convention of "at least one of A, B, and C" is used, such a construction is generally intended to be understood by those skilled in the art (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). In instances where the convention of "at least one of A, B, or C" is used, such a construction is generally intended to be understood by those skilled in the art (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). Those skilled in the art will also understand that any transitional conjunctions and / or phrases that actually present two or more alternative terms, whether in the specification, claims, or drawings, should be understood to imply the possibility of including one, any one, or both of these terms. For example, the phrase “A or B” would be understood to include the possibility of “A” or “B” or “A and B”.Furthermore, as used herein, the term "any of the following" followed by a list of multiple items and / or multiple categories is intended to include "any of the following," "any combination of the following," "any many of the following," and / or "any combination of the following": items alone or in combination with other items and / or items of other categories. Additionally, as used herein, the term "set" is intended to include any number of items, including zero. Furthermore, as used herein, the term "quantity" is intended to include any quantity, including zero. And the term "mutltiple" as used herein is intended to be synonymous with "a plurality."

[0472] Furthermore, in the case of the description of features or aspects of this disclosure in accordance with the Markush group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup member of the Markush group.

[0473] As those skilled in the art will understand, for any and all purposes, such as providing a written description, all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily considered sufficiently descriptive and such that the same scope can be decomposed into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. Those skilled in the art will also understand that all terms such as “up to,” “at least,” “greater than,” “less than,” etc., include the listed numbers and refer to a scope that can subsequently be decomposed into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group having 1-3 cells means a group having 1, 2, or 3 cells. Similarly, a group having 1-5 cells means a group having 1, 2, 3, 4, or 5 cells, and so on.

[0474] Furthermore, the claims should not be construed as limited to the provided order or elements unless otherwise stated. Additionally, the use of the term "for a means of..." in any claim is intended to invoke 35 U.S.C. § 112, paragraph 6 (35 U.S.C. § 112, ...). The claim format is either device plus function, and any claim without the term "for a device" does not have such an intent.

Claims

1. A wireless transmit / receive unit (WTRU) comprising circuitry including any one of a processor, a memory, a transmitter, and a receiver, said circuitry being configured to: Receive configuration information, which indicates the remaining time threshold for triggering reporting information related to the Protocol Data Unit (PDU) set; It is determined that the remaining time for transmitting one or more PDUs in the PDU set is less than the remaining time threshold; as well as Based on the remaining time being lower than the remaining time threshold, report information related to the PDU set is transmitted, wherein the report information indicates the amount of remaining data to be transmitted in the PDU set when the remaining time is lower than the remaining time threshold.

2. The WTRU of 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 any one of claims 1 to 2, wherein the amount of the remaining data to be transmitted in the PDU set is indicated in bytes.

4. The WTRU of claim 1, wherein the amount of the remaining data to be transmitted in the PDU set is indicated by an index referencing 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 transmitting the PDU set.

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

7. The WTRU according to any one of claims 1 to 6, wherein the reporting information is received in a Media Access Control Element (MAC CE).

8. The WTRU according to any one of claims 1 to 7, wherein the PDU set comprises more than one PDU associated with each other.

9. The WTRU according to any one of claims 1 to 8, wherein the configuration information indicates a second threshold, the second threshold being used to trigger reporting information associated with the PDU set.

10. The WTRU of claim 9, wherein the circuitry is further configured to determine that the amount of remaining data to be transmitted in the PDU set is higher than the second threshold, wherein the reporting information is transmitted based on the determination that the amount of remaining data to be transmitted in the PDU set is higher than the second threshold.

11. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information, which indicates the remaining time threshold for triggering reporting information related to the Protocol Data Unit (PDU) set; It is determined that the remaining time for transmitting one or more PDUs in the PDU set is less than the remaining time threshold; as well as Based on the remaining time being lower than the remaining time threshold, report information related to the PDU set is transmitted, wherein the report information indicates the amount of remaining data to be transmitted in the PDU set when the remaining time is lower than the remaining time threshold.

12. The method of claim 11, wherein the amount of remaining data to be transmitted in the PDU set is indicated as an absolute value.

13. The method according to any one of claims 11 to 12, wherein the amount of the remaining data to be transmitted in the PDU set is indicated in bytes.

14. The method of claim 11, wherein the amount of the remaining data to be transmitted in the PDU set is indicated by an index referencing one or more values.

15. The method according to any one of claims 11 to 14, wherein the reporting information indicates the remaining time for transmitting the PDU set.

16. The method according to any one of claims 11 to 15, wherein the configuration information is received in a radio resource control message.

17. The method according to any one of claims 11 to 16, wherein the reporting information is received in a Media Access Control Element (MAC CE).

18. The method according to any one of claims 11 to 17, wherein the PDU set comprises more than one PDU associated with each other.

19. The method according to any one of claims 11 to 18, wherein the configuration information indicates a second threshold, the second threshold being used to trigger reporting information related to the PDU set.

20. The method of claim 19, further comprising determining that the amount of remaining data to be transmitted in the PDU set is higher than the second threshold, wherein the report information is transmitted based on the determination that the amount of remaining data to be transmitted in the PDU set is higher than the second threshold.

Images