Sequential delivery of PDUs in PDU set in uplink

Abstract

A wireless transmit / receive unit (WTRU) may be configured to receive configuration information indicating one or more thresholds associated with one or more retransmissions of a plurality of protocol data units (PDUs) of a set of PDUs. The WTRU may be configured to transmit a plurality of PDUs in a PDU set. The WTRU may be configured to receive an indication that one or more PDUs in the set of PDUs are to be retransmitted. The WTRU may be configured to determine a second logical channel for retransmitting the PDUs in the set of PDUs based on at least one of the PDUs in the set of PDUs to be retransmitted being greater than the first threshold or a remaining delay budget for the PDUs in the set of PDUs to be retransmitted being less than a second threshold. The WTRU may be configured to retransmit a PDU in a PDU set.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 445,456, filed on February 14, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] The term Extended Reality (XR) can be a general term for different types of immersive experiences, including Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR), as well as the reality inserted into them. VR is a rendered version of the delivered visual and auditory scene. The rendering can be designed to mimic the visual (e.g., stereoscopic 3D) and auditory sensory stimuli of the real world as naturally as possible to the observer or user as they move within a limited area defined by the application. AR is a technology that provides users with additional information or artificially generated objects / items or content overlaid on their current environment. MR is an advanced form of AR in which some virtual elements are inserted into the physical scene to provide the illusion that these elements are part of the real scene. XR can include one or more (e.g., all) combined real and virtual environments and human-computer interactions generated by computer technology and wearable devices.

[0003] In the context of XR applications / services, the concept of immersion can refer to the senses being surrounded by a virtual environment, and the feeling of being physically and spatially present within that environment. Levels of virtuality can range from partial sensory input to fully immersive multi-sensory input, resulting in virtual reality becoming virtually indistinguishable from actual reality. Summary of the Invention

[0004] A Wireless Transmit / Receive Unit (WTRU) may include one or more processors. The WTRU may be configured to receive configuration information indicating one or more thresholds associated with one or more retransmissions of a plurality of PDUs in a Protocol Data Unit (PDU) set. The one or more thresholds may include at least one of a first threshold corresponding to the number of PDUs to be transmitted or a second threshold corresponding to the remaining delay budget. The WTRU may be configured to transmit a plurality of PDUs in the PDU set. Transmission of the plurality of PDUs in the PDU set may be associated with a first logical channel, which is associated with a first priority. The WTRU may be configured to receive an indication that one or more PDUs in the plurality of PDUs in the PDU set are to be retransmitted. The WTRU may be configured to determine a second logical channel to be used for the retransmission of one or more PDUs in the plurality of PDUs in the PDU set based on the number of one or more PDUs to be retransmitted in the plurality of PDUs in the PDU set being greater than the first threshold or the remaining delay budget of one or more PDUs to be retransmitted in the plurality of PDUs in the plurality of PDUs in the PDU set being less than at least one of the second thresholds. The WTRU may be configured to retransmit one or more PDUs in the plurality of PDUs in the PDU set. Retransmission of one or more PDUs in a PDU set can be associated with a second logical channel.

[0005] The WTRU can be configured to determine information about one or more PDUs to be retransmitted from a set of PDUs. This information may include the number of PDUs to be retransmitted and / or the remaining delay budget.

[0006] The WTRU can be configured to determine a second priority for one or more PDUs to be retransmitted from a set of PDUs. A second logical channel can be associated with the second priority. The indication may include an indication of one or more sequence numbers assigned to the one or more PDUs to be retransmitted from the set of PDUs and / or an indication of the second priority. The second logical channel to be used for the retransmission of one or more PDUs from the set of PDUs can be determined based on the number of one or more PDUs to be retransmitted from the set of PDUs being greater than a first threshold and / or the remaining delay budget of one or more PDUs to be retransmitted from the set of PDUs being less than a second threshold.

[0007] WTRU can be configured to update the first priority of one or more PDUs to be retransmitted from a set of PDUs based on one or more attributes of the PDU set. The one or more attributes of the PDU set may include the type of the PDU set, the importance of the PDU set, one or more payload sizes, the percentage of the PDU set to be retransmitted, and / or the number of PDUs in the PDU set.

[0008] The WTRU can be configured to retransmit one or more PDUs from a PDU set using a first logical channel associated with a first priority, provided that the number of PDUs to be retransmitted from a PDU set is less than a first threshold and / or the remaining delay budget of one or more PDUs to be retransmitted from a PDU set is greater than a second threshold.

[0009] A WTRU can be configured to transmit multiple PDUs from a PDU set in one or more batches. A WTRU can also be configured to determine the priority of a second batch of PDUs from the same PDU set based on the transmission status of the first batch.

[0010] The WTRU can be further configured to update the priority of one or more PDUs in a set of PDUs to be retransmitted during a retransmission, based on information associated with the sequence number (SN) gap. The information associated with the SN gap may include the number of SN gaps, the size of the SN gap, the length of the SN gap, and / or the phase of the SN gap.

[0011] WTRU can be configured to determine which PDUs in a PDU set to transmit using a default configuration. The default configuration may include one or more default priority values, a default mapping configuration, and / or one or more default logical control priority (LCP) parameters. Attached Figure Description

[0012] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments can be implemented.

[0013] Figure 1B The illustration based on one embodiment can be seen in Figure 1A The system diagram shows an example wireless transmit / receive unit (WTRU) used within the communication system.

[0014] Figure 1C The illustration based on one embodiment can be seen in Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used within the communication system shown.

[0015] Figure 1D The illustration based on one embodiment can be seen in Figure 1A The system diagram shows another example RAN and another example CN used in the communication system shown.

[0016] Figure 2A and Figure 2B The illustration shows an example forwarding configuration at the Access Layer (AS) for in-order data delivery.

[0017] Figure 3 The illustration shows an example process for updating the priority of missing PDUs based on delivery status indication and / or remaining delay.

[0018] Figure 4 The illustration shows an example process for triggering the recovery of lost and / or missing PDUs based on one or more PDU set attributes. Detailed Implementation

[0019] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. Communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, 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 Unique Word DFT Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0020] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments are contemplated to any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d—any of which can be referred to as a “station” and / or “STA”—can be configured to transmit and / or receive wireless signals and can include 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 Mi-Fi 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, and the like. Any of WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as WTRUs.

[0021] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be appreciated that base stations 114a and 114b may include any number of interconnected base station and / or network elements.

[0022] Base station 114a may be part of RAN 104 / 113, which 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 for radio services to a specific geographic area, which may be relatively fixed or may change over time. The cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, 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 utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

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

[0024] 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 establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

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

[0026] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, which can establish an air interface 116 using a new radio (NR).

[0027] 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 jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized 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).

[0028] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 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), and the like.

[0029] Figure 1ABase station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. 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 yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0030] 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 can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1A Although not shown, it will 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 may utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0031] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The 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 / 113 or a different RAT.

[0032] 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 for communicating 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 employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0033] Figure 1B This is a system diagram illustrating the example WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive 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 peripheral devices 138, etc. It will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0034] 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, and the like. Processor 118 may perform signal encoding, 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 will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0035] 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, for example, a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It will be appreciated that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0037] Transceiver 120 can be configured to modulate signals to be 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 for example enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0038] The processor 118 of WTRU 102 can be coupled to and receive user input data from: 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). The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information from and store data in any suitable type of memory (such as non-removable memory 130 and / or removable memory 132). 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 subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, and the like. In other embodiments, the processor 118 can access information from and store data in memory that is not physically located on WTRU 102 (such as a server or home computer (not shown)).

[0039] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for 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, and the like.

[0040] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0041] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® 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, and the like. Peripheral devices 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, attitude sensors, biosensors, and / or humidity sensors.

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

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

[0044] RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will 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 for communicating 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.

[0045] 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 UL and / or DL, and the like. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0046] 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 (or PGW) 166. While each of the foregoing elements is depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0047] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c 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, and so on. The MME 162 can provide control plane functions for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0048] 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 inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, and so on.

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

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

[0051] Despite WTRU in Figures 1A-1D While described as a wireless terminal, it is envisioned that in certain representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0052] In a representative embodiment, another network 112 may be a WLAN.

[0053] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access to or interfacing with a Distributed System (DS) or carry services within and / or out of the BSS to another type of wired / wireless network. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA (e.g., directly between the source and destination STAs) using Direct Link Establishment (DLS). In a particular representative embodiment, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the "self-organizing" communication mode in this document.

[0054] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide 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 a particular representative embodiment, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can listen on the primary channel. If the primary channel is listened to / detected by a particular STA and / or determined to be busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

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

[0056] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels—this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0057] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to the operating modes used in 802.11n and 802.11ac, the channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have specific capabilities (e.g., limited capabilities) including support (e.g., support only) specific and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0058] WLAN systems that support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The bandwidth of the primary channel can be 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 STAs that support the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and can be available.

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

[0060] Figure 1D This diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0061] RAN 113 may include gNBs 180a, 180b, and 180c, although it should be understood that RAN 113 may include any number of GNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, GNBs 180a and 108b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. 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 can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0062] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ 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 various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute durations).

[0063] 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 access to 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, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially 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 act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0064] 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 slicing 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, and the like. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0065] 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 possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0066] 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 be used 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 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 to customize CN support for WTRU 102a, 102b, and 102c based on the service types being used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and so on. AMF 162 can provide control plane functions for switching between RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0067] 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 service routes through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and so on. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0068] UPF 184a and 184b can be connected via the N3 interface to one or more of gNB 180a, 180b, and 180c in RAN 113. This N3 interface provides WTRU 102a, 102b, and 102c with access to a packet-switched network (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 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-destination PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and so on.

[0069] 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) acting as an interface between CN 115 and PSTN 108. Furthermore, CN 115 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. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to local DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and data networks (DNs) 185a and 185b.

[0070] Given Figures 1A-1D and Figures 1A-1D The corresponding descriptions herein regarding one or more of the functions of WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0072] One or more emulation devices may perform one or more functions (including all functions) but are not implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios in a test laboratory and / or in non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test equipment. Emulation devices may 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).

[0073] In extended reality (XR) applications, a wireless transmit / receive unit (WTRU) can transmit XR services (e.g., gestures, video data) comprising one or more Protocol Data Units (PDUs) and / or sets of PDUs in the uplink (UL), and / or receive XR services (e.g., video, audio, haptic feedback) in the downlink (DL). These services can be transmitted and / or received periodically or non-periodically in one or more data streams (e.g., QoS streams). During UL transmission, XR services can arrive at the WTRU from the application layer at different times and / or with different service attributes (e.g., variable payload size per PDU set, variable level importance per PDU set). To ensure quality of service (QoS) satisfaction (e.g., PDU set delay limit (PSDB), PDU set error rate (PSER)), timely prioritization, multiplexing, and scheduling, taking into account PDU set attributes, may be important. To ensure Quality of Experience (QoE), PDU sets generated at the application's transport side, or PDUs within different PDU sets, can be expected to be delivered to the application's receive side within QoS (e.g., PSDB) and in order.

[0074] In XR services, different PDUs or PDU sets can contribute to different user experiences (e.g., QoE). For example, from an application layer perspective, PDUs / PDU sets can be associated with different importance and / or priority values. As another example, one or more PDU sets transmitted sequentially in the time domain can depend on each other in different ways. In other words, unlike existing QoS frameworks where one or more (e.g., all) PDUs and / or PDU sets in a stream are provided with the same forwarding treatment based on the assumption of equal importance / priority, during scheduling and transmission in UL and / or DL, PDUs and / or PDU sets in XR service data bursts may need to be differentiated and handled differently at lower layers in a per-QoS manner, regardless of whether the PDUs and / or PDU sets are in one or more QoS streams.

[0075] Interdependencies between PDUs and / or PDU sets in single or multiple QoS flows can present different challenges in satisfying QoS at the PDU set level during transmission in UL and DL. For example, ensuring the correct mapping of interdependent PDU sets or data bursts received from higher layers in WTRU to one or more configured Data Radio Bearers (DRBs) and / or Logical Channels (LCHs), so that appropriate ordering and QoS forwarding processing of PDUs and / or PDU sets can be provided during data transmission, is a problem that remains unknown.

[0076] One or more Packet Data Convergence Protocol (PDCP) entities in the PDCP sublayer can support the maintenance of PDCP sequence numbers (SNs), reordering of PDUs, and ordered delivery. PDCP entities can perform retransmission or transmission of one or more (e.g., all) PDCP Service Data Units (SDUs) already associated with a PDCP SN in ascending order of the COUNT value associated with the PDCP SDU. Ordered / ordered delivery of PDUs within a PDU set or ordered delivery of a PDU set may not be supported.

[0077] When a SN gap is detected at the receiving PDCP entity, in-order delivery of PDUs can be supported at both the transmitting and receiving PDCP entities based on COUNT allocation (e.g., superframe number (HFN) and SN for each PDU) and the triggering of a reordering timer. Directly extending legacy mechanisms to support in-order delivery of PDUs and / or PDU sets can cause several problems. For example, these problems can include inefficient resource utilization (e.g., if all PDU sets are mapped to the same DRB / PDCP entity, PDU sets with low importance and / or priority are provided with the same priority level and resources as PDU sets with high importance / priority). As another example, these problems can include conflicts and / or trade-offs with differentiated QoS procedures at lower layers (e.g., prioritizing high-importance PDU sets before low-importance PDU sets during transmission at the Media Access Control (MAC) sublayer can result in out-of-order delivery).

[0078] Leaving the in-order delivery and reordering of PDU sets entirely to the application (e.g., via the use of a de-jitter buffer at the application) may come at the cost of reduced WTRU and PSDB for data delivery at the network. In this respect, a key challenge to address in the context of XR services (e.g., interdependent PDUs) is how to ensure in-order delivery of PDU sets while supporting differentiated QoS (e.g., prioritization) during data transmission.

[0079] The network may include any of the following: base stations (e.g., gNodeB (gNB), Transmit / Receive Point (TRP), Radio Access Network (RAN) node, access node), core network functions (e.g., AMF, SMF, Policy Control Function (PCF), Network Exposure Function (NEF)), and application functions (e.g., edge server function, remote server function).

[0080] A flow can correspond to one or more of the following: a QoS flow or a data flow (e.g., a data flow comprising one or more PDUs, PDU sets, or data bursts, which may be associated with one or more QoS requirements, such as latency, data rate, reliability, round-trip time (RTT) delay). Different flows that may originate from a common application / experience source and / or a group of flows intended to reach a common destination device / WTRU or associated device / WTRU can be referred to as associated flows or related flows.

[0081] A data unit can refer to one or more frames (e.g., media / video / audio frames or slices / snippets), PDUs, PDU sets, data bursts, frame groups / PDUs / PDU sets / data bursts.

[0082] QoE metrics and measurements can correspond to one of the application and / or higher-level metrics and measurements, which can be directly or indirectly detectable / visible at the WTRU and / or application function. For example, QoE metrics and measurements may or may not be directly visible / detectable at the base station. QoE metrics and measurements can be determined / performed based on QoS metrics / parameters (e.g., latency, data rate, reliability, RTT / motion-to-photon (MTP) delay).

[0083] Forwarding configurations can correspond to one of the following: radio bearers (e.g., DRB and / or signaling radio bearers (SRB), LCH), logical channel groups (LCG), configuration parameters in individual layers within the AS protocol stack (e.g., Serving Data Adaptation Control (SDAP), PDCP, Radio Link Control (RLC), MAC, physical layer (PHY), other new protocol layers), to be applied to assign COUNT / SN to PDU / PDU sets / data bursts and to ensure the in-order delivery of PDU sets or PDUs within different PDU sets at the transmit (Tx) and receive (Rx) PDCP entities, parameters associated with logical channel prioritization (LCP) (e.g., priority, prioritized bit rate (PBR), bucket size duration (BSD)), bandwidth portion (BWP), carrier, radio link / interface (Uu link, side link (SL)), and radio resources (e.g., a set of one or more frequency / time / space components such as symbols, time slots, subcarriers, resource elements, or beams). Radio resources can be associated with configuration licenses (CG), dynamic licenses (DG), and / or any other resource licenses or licensed free resources.

[0084] Mapping configurations can correspond to one of the parameters and / or configurations associated with mappings from one or more datasets. For example, a dataset can be one of a data unit, PDU, SDU, PDU set, data burst, application data (e.g., application data unit (ADU)) stream, or QoS stream (e.g., associated or unassociated). For example, a dataset can originate from the application layer, higher layers, and / or network to one or more radio bearers (e.g., DRB, SRB), sublayers or entities (e.g., SDAP, new layer, PDCP, RLC, MAC, PHY), LCH, carriers or component carriers (e.g., component carriers (CC) in a carrier aggregation (CA) configuration), bandwidth portions (BWP), and radio links / interfaces (e.g., Uu links or lateral links), which can be used to deliver data / PDUs in the UL direction or DL.

[0085] XR / application-aware data transmission / reception or XR / application-aware QoS handling can correspond to one of the following properties. For example, the property may include attributes associated with a PDU set, ADU, or data burst. A PDU set (e.g., media unit, video frame) may consist of one or more PDUs. PDUs within one or more PDU sets within a data burst may be interdependent at the application layer and / or lower layers (e.g., access layer (AS)-layer). As another example, the property may include a PDU set that may be associated with PDU set-level QoS requirements (e.g., data rate, latency, error rate, reliability), which may apply to one or more (e.g., all) PDUs associated with the PDU set. Different PDUs within a PDU set may be associated with individual PDU-level QoS requirements. As another example, a data burst may refer to data generated by an application within a short period of time, including PDUs from one or more PDU sets. Such attributes, associations, and interdependencies (e.g., within and / or between PDU sets), including indications of the start and / or end of PDU sets and / or data bursts (e.g., via sequence number, start / end indication), start and / or end times, duration, payload size, periodicity, importance / priority, and QoS (e.g., PSDB), can be visible to the AS layer (e.g., with associated IDs) and / or disposed at the AS layer, where said associations are perceived during data transmission in the UL and reception in the DL. For another example, application, higher-level importance, or priority can include different PDUs in a PDU set or all PDUs in a PDU set. Different PDUs in a PDU set or all PDUs in a PDU set can be associated with different application / higher-level importance / priority values. Such importance values ​​can correspond to spatial importance (e.g., the spatial location of video frames whose data is carried by a set of PDUs / PDUs, where a PDU and / or set of PDUs carrying field-of-view (FoV) spatial location can be associated with higher spatial importance than non-FoV spatial location) or temporal importance (e.g., the temporal sequence of video frames whose data is carried by a set of PDUs / PDUs, where a set of PDUs / PDUs carrying a basic video frame such as an I-frame can be associated with higher temporal importance than differential video frames such as P-frames / B-frames). During data transmission and reception, such importance values ​​can be visible to the AS layer (e.g., with associated ID / tag / indication) and may be enabled by application awareness. Another example could be QoS / data streams. An application's set of PDUs / PDUs can be encoded by the application and delivered to the WTRU (in the UL) or the network (in the DL) via one or more QoS / data streams.In this regard, different QoS flows carrying PDU / PDU sets associated with XR applications / experiences may be visible to the AS layer (e.g., with associated IDs) and / or disposed at the AS layer, where the association is perceived during data transmission and reception.

[0086] WTRU actions or behaviors that may be related to application actions and / or AS layer actions used to ensure / support differentiated QoS may correspond to one or more of the following: determination of metadata for an application (e.g., an XR application), determination and / or generation of application content, performance of measurements and reports, transmission or forwarding of data or PDUs or sets of PDUs, and handling of QoS associated with PDUs and / or sets of PDUs, and / or transmission or forwarding of information related to network and / or other WTRU connectivity.

[0087] Determining metadata can, for example, involve determining one or more of the following based on measurements in any spatial dimension: FoV / visual / spatial perimeter, 2D / 3D size, boundaries, spatial attributes, and FoV boundaries. Spatial dimensions can include, but are not limited to, longitude, latitude, altitude, depth, roll, pitch, and yaw in one or more coordinate systems (e.g., Cartesian, spherical). As another example, determining metadata can involve determining the quality of the FoV content, such as whether the FoV content is high-quality (in the case of images, this can be quantified and evaluated by image resolution, such as the number of megapixel densities). In one example, data from one or more PDUs, PDU sets, or data bursts can be associated with FoV content. As another example, determining metadata can involve determining the importance and / or priority of the FoV content. The importance of FoV content can be associated with the spatial and / or temporal importance of the content / data. For example, spatial / temporal importance values ​​can indicate the absolute or relative importance associated with the FoV content. For example, spatial importance can be associated with one or more of the following in a spatial dimension: a fragment, tile, slice, or location of the FoV. For example, temporal importance can be associated with one or more frames and / or subframes of FoV in the time dimension.

[0088] Determining application content may, for example, involve determining and / or capturing one or more 2D / 3D image and / or video frames. 2D / 3D image and / or video frames may be associated with FoV boundaries, perimeters, or limits defined by FoV metadata for themselves and / or on behalf of another WTRU and / or node. For FoV content mapping, WTRUs may use visual sensors (e.g., 2D / 3D cameras, LiDAR), RF sensors (e.g., RF transceivers, radar), audio sensors (e.g., sonar), and the like to determine image and / or video frames. In this document, FoV mapping may also be referred to as FoV content sensing or FoV content capture. For another example, determining application content may also include recording and / or capturing audio frames, as part of the real environment or as part of an audio track and / or audio file overlaid on an audio file originating from a source other than the currently mapped real environment.

[0089] For example, the WTRU can perform measurements of the user / WTRU and / or other objects with which the user can interact (e.g., virtual or real), location / spatial / attitude (e.g., orientation with respect to spatial dimensions (6DoF / 3DoF), 6 or 3 degrees of freedom of position / location), motion / velocity, and the like. The WTRU can periodically send and / or report attitude measurements to the network. When an event trigger is detected (e.g., a change in attitude measurement above / below a threshold), the WTRU can send and / or report attitude measurements to the network. For another example, the WTRU can perform measurements of one or more of the following: reference signals or channels (e.g., synchronization signal block (SSB), channel state information reference signal (CSI-RS), positioning reference signal (PRS), lateral link reference signal (RS)), Global Navigation Satellite System (GNSS) signals, unlicensed carriers, ultra-wideband signals, light detection and ranging (LIDAR) signals, visual signals, and the like. In yet another example, the WTRU can perform measurements of the radio link interface (e.g., Uu link, SL) associated with the WTRU. In another example, a WTRU can trigger the transmission and / or measurement of reference signals in one or more other WTRUs (e.g., via a Uu link and / or a lateral link). In yet another example, performing measurements and reporting can include sending measurement reports to the network and / or additional WTRUs.

[0090] Data may include, for example, one or more of media frames, image frames, video frames, sensor data, and measurement data (e.g., attitude measurements, link and / or channel measurements) determined by the WTRU, and may be used to support applications, services, or network requests associated with the WTRU. As another example, the WTRU may send and / or receive data to / from one or more destinations, including radio access network (RAN) nodes (e.g., gNBs), CN functions or entities, and application functions (e.g., hosted within the WTRU or network). As yet another example, during transmission / reception, the WTRU may perform the splitting and / or merging of data and / or PDUs from one or more QoS streams into one or more forwarding configurations.

[0091] Sending capability information to the network can include capabilities to support one or more traffic flows with different XR service patterns (e.g., a set of periodic / aperiodic PDUs with variable payload sizes). For example, sending capability information to the network can include capabilities to perform application layer measurements (e.g., QoE measurements, application buffer measurements, RTT measurements). As another example, sending capability information to the network can also include capabilities to detect changes in service patterns.

[0092] Sending WTRU inter-coordination capability information to the network may include capabilities to support one or more interfaces, and the ability to coordinate and / or interact with other WTRUs / devices (e.g., via the SL interface). For example, interaction with other WTRUs / devices may be co-located or non-co-located with the WTRU.

[0093] The receive configuration may include receiving Radio Resource Control (RRC) configuration from a Next Generation Node B (gNB) and / or receiving Non-Access Stratum (NAS) layer configuration from a CN.

[0094] Transmitting or forwarding information related to network and / or other WTRU connectivity may include sending and / or receiving ancillary data related to services, QoS, scheduling, and the like to support UL / DL transmissions. Transmitting or forwarding information related to network and / or other WTRU connectivity may also include sending requests for radio resources and / or resource grants (e.g., dynamic grants, semi-static / configurable grants).

[0095] When transmitting and / or receiving XR services, the solutions used at the WTRU to ensure in-order delivery of data and compliance with QoS can be discussed in detail below. The WTRU (in the UL at SDAP) or the network (in the DL) can identify data units using one or more of the following: sequence number (SN), QoS attributes, PDU set attributes, or timing and / or counting information. These data units include one or more PDUs, PDU sets, or data bursts associated with XR services received in one or more QoS streams. For example, the SN can be identified on a per-PDU, per-PDU set, or per-data burst basis. Different types of SNs can include COUNT, HFN, and PDU SN. QoS attributes can include QoS Flow Identifier (QFI), PSER, PSDB, or PDU Set Integrated Disposal Indication (PSIHI) (e.g., a flag indicating whether all PDUs in the PDU set are required to be delivered). PDU set attributes can include type, total payload size (e.g., bits / byte, number of PDUs), the starting PDU of the PDU set, or the ending PDU (end marker). A timestamp can indicate when a PDU was generated, the remaining relays, or the hop count (e.g., the hop count that has passed or remains).

[0096] The transmitting and / or receiving entities may use markers on the data units (e.g., in the PDU header) to perform specific actions associated with the in-order delivery of PDU / PDU sets. For example, the specific actions performed in association with the in-order delivery of PDU / PDU sets may include one or more of the following: inquiring about the existence of SN gaps, generating status reports (e.g., acknowledgment (ACK) / negative ACK (NACK) of the received SN), and triggering retransmissions.

[0097] Data units may include one or more PDUs, PDU sets, or data bursts associated with an XR service, having the same or different QoS requirements / characteristics. Mapping configurations can be used to map data units to one or more forwarding configurations. Different forwarding configurations can be configured to implement and / or enforce different QoS when transmitting PDUs / PDU sets. In one example, mapping configurations (e.g., at SDAP, PDCP) can be used to map PDU sets received from an application in one or more QoS streams to one or more forwarding configurations (e.g., DRBs with common / different PDCP entities or LHs with different configurations). Forwarding configurations can be associated and / or grouped to implement and / or ensure PDU set-level QoS. During mapping, parameter sets (e.g., priority, PBR, BSD) and / or configurations (e.g., LCP) can be applied at the forwarding configuration to implement and / or enforce PDU set-level or data burst-level QoS for PDUs / PDU sets in the buffer associated with the forwarding configuration.

[0098] PDUs or PDU bursts received from different PDU sets at the application layer and / or higher layers may have different expected QoS to be satisfied during transmission. For example, based on the determination of the expected QoS of the PDU / PDU sets received or to be received in the QoS stream, the WTRU can apply specific mappings, buffer / queue management, and adaptation mechanisms at one or more layers of the AS layer protocol stack (e.g., SDAP, PDCP, MAC). The expected QoS of the PDU / PDU sets can be satisfied and / or delivered to the network in order. As another example, the WTRU may expect to receive any one of the PDU / PDU sets in the DL from the network. Such mechanisms for satisfying the corresponding QoS and receiving PDU / PDU sets in order ensure QoE.

[0099] To meet QoS requirements and ensure in-order delivery of PDU / PDU sets, different layers in the forwarding configuration can be configured with different configuration parameters. For example, such configuration parameters may include support for PDU / PDU set reordering at the PDCP, support for Acknowledgment (AM) / Unacknowledgment (UM) mode at the RLC, LCP rules / restrictions and associated LCH parameters (e.g., PBR, BSD, priority) at the MAC, and the number of Hybrid Automatic Repeat Request (HARQ) transmissions. To ensure in-order delivery, specific parameters can be configured and / or adapted at the PDCP (e.g., SN dispatch, SN space adjustment, Robust Header Compression (ROHC)) and MAC (e.g., LCH adaptation) sublayers.

[0100] The term Expected QoS can be used to indicate the expected margin of a specific QoS metric (e.g., latency, data rate, reliability) before the arrival of data, including any of PDUs, PDU sets, and / or data bursts. The term Expected QoS can also be used to indicate the expected margin of a specific QoS metric (e.g., latency, data rate, reliability) when data is received at the WTRU (i.e., the QoS to be achieved / implemented during transmission). In one example, Expected QoS can correspond to the duration available from reception at the WTRU (e.g., from a higher layer) to successful delivery of data on a radio link (e.g., a Uu link or a side link). In another example, Expected QoS can also correspond to the Time-to-Live (TTL) of an individual PDU, PDU set, or data (e.g., the maximum time available for buffering, processing, and delivery). In this case, Expected QoS can be determined based on indications and / or markings in the PDU / PDU set (e.g., the QoS Flow Identifier (QFI) in the packet header of the PDU / PDU set, timestamps, PDU set IDs, and the like) and / or based on the use of timers. For example, the use of timers can be set when receiving PDUs / PDU sets and reset / stopped when the configured duration expires. Similar mechanisms (e.g., based on indicators / tags and / or timers) can be applied to changes between different mapping and / or forwarding configurations to ensure the expected QoS.

[0101] In some examples, the expected QoS can be stricter or more lenient than the default QoS metric applied to the PDU / PDU set. For instance, if the PDU set arrives late at the WTRU, its importance value can be indicated as high (e.g., above a threshold), or it has already experienced more latency and jitter at the application layer (e.g., due to the encoder), and the expected latency to be met by the PDU set on the unique user (U)u link can be lower than the default PSDB typically used to transmit PDUs in the PDU set. Alternatively, if the PDU set arrives early or its importance value is indicated as low (e.g., below a threshold), the expected latency on the Uu link can be considered more lenient than the PSDB typically used to transmit such PDUs.

[0102] In summary, the expected QoS can change dynamically based on the QoS and / or importance / priority indication experienced during reception, where for a fixed QoS (e.g., packet delay budget (PDB), packet error rate (PER), PSDB, PSER), an increase / decrease in the expected QoS before reception can be translated into a decrease / increase in the expected QoS on the radio link (e.g., Uu link).

[0103] In a solution family, the WTRU can be configured to support the transmission and / or reception of data units, which include any one of PDUs, PDU sets, and / or data bursts in one or more streams in the UL and / or DL. The transmission and / or reception of data units can result in the in-order delivery of data units while satisfying the QoS associated with the data units.

[0104] WTRU can support data transmission and / or reception that results in in-order data delivery based on one or more of the configuration, triggering events, conditions / criteria received from the network and / or application, and / or auxiliary networks to ensure in-order delivery during transmission.

[0105] The WTRU can be configured with one or more conditions and / or configurations associated with in-order delivery during UL transmission and / or DL ​​reception. These conditions and / or configurations may relate to or reflect the expected QoS to be achieved during transmission to the network (in the UL), reception at the WTRU (in the DL), or changes to such expected QoS.

[0106] Based on conditions and / or configuration, the WTRU can be configured to map data units of XR services received from higher layers / applications and / or update forwarding configurations, protocol stack parameters (including any new layers among SDAP, PDCP, RLC, MAC, PHY, and AS layers) during data transmission in the UL and / or DL, based on the detection of one or more configured trigger conditions. For example, actions associated with selective mapping may include configuring the WTRU to perform 1:1, N:1, or N:M mappings from one or more PDU sets to one or more forwarding configurations to enable flexible utilization of radio bearers and resources while ensuring in-order delivery and / or QoS satisfaction. As another example, actions associated with selective mapping may include configuring the WTRU to ensure in-order delivery (e.g., the order intended by the application / AS layer) when PDUs, PDU sets, and data bursts are transmitted in the UL and / or received in the DL. For another example, actions associated with selective mapping may include WTRUs that can also be configured to drop any of the PDUs, PDU sets, or data bursts that do not meet the associated QoS requirements, based on intra- or inter-PDU set dependency information.

[0107] Based on the aforementioned conditions and / or configuration, the WTRU can be configured to perform measurements and / or reports on XR services to be transmitted in the UL and / or received in the DL at either the AS layer and / or the application layer. The WTRU can be configured to periodically and / or, upon detection of any triggering condition, transmit any status reports / indications of the measurements performed by the WTRU on the XR services.

[0108] The WTRU can transmit auxiliary / status information associated with the in-order delivery of data units to the network. For example, the WTRU can send information to the network related to any XR service (e.g., association between PDUs and PDU sets, association / dependency between PDU sets in one or more data bursts), possibly to enable the network to be aware of service characteristics. WTRU actions are used to ensure in-order delivery during the transmission / reception of XR services.

[0109] Information associated with XR services / applications can be sent to the network by the WTRU. This information may include one or more message types. For example, these message types may include capability information, auxiliary information, preferred / desired configuration information (e.g., preferred forwarding and / or resources), configurations / parameters applied in the UL / DL, preferred delivery modes, status information / indications (e.g., associated with any of the AS layers), measurement / status reports (e.g., pending data in the buffer, remaining latency, ACK / NACK status), or request / response messages (e.g., requests to activate / deactivate configurations or parameter sets, requests for resources).

[0110] The information can be sent by the WTRU in various methods. These methods may include periodic sending (e.g., using one or more configured periodic values), non-periodic sending (e.g., as an update message when a triggering event / condition described herein is detected, or when a change in previously sent information is detected), and / or semi-permanent sending (e.g., sending periodic values ​​over a time window / duration).

[0111] In one example, the WTRU can switch between a first periodic value and a second periodic value for transmitting information. The switching of the WTRU can be based on the type of event detected (e.g., a change in the type of PDU set to be transmitted in the UL, or a buffer occupancy delay exceeding a threshold). In another example, the WTRU can switch between periodically and non-periodically transmitting information based on whether any changes and / or the amount of change have been identified in the information to be reported.

[0112] The WTRU can send information / instructions to the network via one or more message types. These message types may include RRC signaling and / or messages (e.g., via SRB1, SRB2, SRB3, SRB4), control PDUs associated with any of the AS layers (e.g., SDAP control PDUs, PDCP control PDUs), UL MAC CEs (e.g., new MAC CEs, regular buffer status reports (BSRs), periodic BSRs, padding BSRs, enhanced BSRs, preemptive BSRs, resilient BSRs (which may be scalable / adjustable by sending subsequent instructions and may not cancel earlier BSRs), uplink control information (UCIs) (e.g., single-bit SRs, multi-bit SRs, feedback, ACK / NACKA, channel state information (CSI) reports), physical uplink control channel (PUCCH), physical uplink control shared channel (PUSCH), non-AS (NAS) layer signaling (e.g., PDU session-related messages), or application layer signaling / messages.

[0113] Information sent to the network by the WTRU in any of the message types may include a combination of one or more of the following: identifier / ID, priority of the application / service supported by the WTRU, data flow associated with the application, device associated with the application, data / service type associated with the data flow of each application, service characteristics and / or parameters associated with any of the QoS flows, PDU sets and data bursts of each application, buffering information at the application layer / higher layer / AS layer, QoS requirements or expected QoS associated with the date, capability information associated with connectivity, capability information associated with WTRU actions / behaviors, preferred / desired configuration information, information about the update forwarding configuration applied at the WTRU, instructions for activating and / or deactivating configurations, and / or measurements associated with the application and / or AS layer.

[0114] WTRU can send one or more IDs and / or indexes. IDs and / or indexes may include IDs associated with applications (e.g., application ID, service ID, session ID, application configuration ID), group IDs (e.g., associated with a group of QoS flows, a group of forwarding configurations, or a device / WTRU group), IDs of individual QoS flows, mapping configurations, forwarding configurations, data unit type / message IDs and / or SNs (e.g., data burst ID, PDU set ID, PDU ID), and / or association IDs (e.g., IDs or SNs indicating associations and / or dependencies between one or more PDUs, PDU sets, data bursts, or flows).

[0115] For example, WTRU can send the ID of the supported application / service and / or information about the relative / absolute priority value associated with the supported application.

[0116] For example, the WTRU can send a number and / or ID associated with each data / QoS stream supported by an application. As another example, the WTRU can also send information about the relative / absolute priority values ​​associated with the data / QoS streams of the different supported applications.

[0117] For example, WTRU can send numbers and / or IDs associated with supported devices and / or device associations for each application.

[0118] For example, WTRU can send information about different data / QoS streams associated with an application, where data types can include video data (e.g., I-frame data, P-frame data, B-frame data), red-green-blue depth (RGB-D) data, 360-degree video data, haptic data, gesture / positioning data, audio data, and the like.

[0119] For example, the WTRU can send information about the service characteristics / patterns of different QoS flows, including whether the data is periodic, non-periodic, semi-permanent, quasi-periodic, and so on. Service characteristics may include one or more periodic values ​​for the flow. As another example, the WTRU can send information about the size of the PDU set and the expected number of PDUs per PDU set in one or more flows for each application. Information about the size of the PDU set or the number of PDUs per PDU set may also include statistical / distribution information, such as mean, minimum, maximum, and / or standard deviation values. Information associated with the PDU set may include indications of the start / first and / or end / last PDUs of the PDU set, as well as indications of the association / dependency of PDUs within the PDU set (e.g., the PDU set ID, importance / priority values). For another example, the WTRU can send information about data bursts in one or more QoS flows, including the number of PDU sets (e.g., instantaneous, average, maximum, minimum), the payload size of the data burst in bits / bytes (e.g., instantaneous, average, maximum, minimum), periodicity, importance / priority, start and end indications of the data burst (e.g., ID of the first PDU / PDU set, ID of the last PDU / PDU set), and dependency information within and across multiple data bursts (e.g., indicating whether PDU sets in one or more data bursts are related). For another example, the WTRU can send information related to jitter in the UL and / or DL. Jitter information that can be sent on a per-flow, per-PDU set, or per-PDU basis can include range, average, maximum, and minimum values. For another example, the WTRU can send information about the importance / priority of any of the data units (e.g., PDUs, PDU sets, data bursts) to be transmitted / received in the UL / DL. For another example, the WTRU can send an indication when any change in the UL / DL service mode is detected (e.g., periodic changes, changes in average payload size, changes in jitter range). For yet another example, the WTRU can send information about the predicted service mode in the UL and / or DL ​​for upcoming data (e.g., timing information indicating the expected data arrival slot, size, importance of the data to be received, prediction uncertainty, and / or confidence level).

[0120] For example, the WTRU can send information about the amount of data payload or buffering level at the application (e.g., about one or more configured thresholds), including data waiting to be delivered to a lower layer for UL transmission (e.g., SN) and / or data received in the DL that can wait to be delivered to a higher layer / application. In one example, buffering information can be reported in terms of an estimated or measured duration for which data waits in the buffer before being delivered to a lower layer or consumed by the application. In another example, buffering information can be reported for data buffered at the application layer / higher layer, new layer, SDAP, PDCP, RLC, MAC, LCG, LCH. In yet another example, buffering information can be reported at the granularity of one or more data units (e.g., PDU, PDU set, data burst) in terms of payload size (e.g., total, instantaneous, average, maximum, minimum). In yet another example, buffering information can be reported in terms of SN range (e.g., the SN associated with the first PDU / PDU set and / or the last PDU / PDU set).

[0121] For example, a WTRU can send QoS requirements or expected QoS for one or more flows or data units (e.g., PDUs, PDU sets, data bursts), including data rate, latency, reliability, absolute / relative priority values, and the like. Information regarding QoS requirements may also include statistical / distribution information such as mean, minimum, maximum, and standard deviation. As another example, a WTRU can also indicate that such QoS requirements or expected QoS can be supported at different QoS granularities. Different QoS granularities can include each PDU within a PDU set, each PDU subgroup (e.g., one or more PDUs), each PDU set, each PDU set group, each flow, or each session. The WTRU can also indicate a time window (e.g., start time, duration, end time) during which such QoS requirements or expected QoS can be applied at different QoS granularities.

[0122] For example, information about the interface may include the number and / or type of interface supported by the WTRU (e.g., New Radio (NR) Uu, NR SL, WiLAN, Bluetooth). As another example, capability information about the interface that may be supported by the WTRU and / or required by the WTRU to support any of the WTRU's actions and / or behaviors may include bandwidth, BWP, number of carriers, number of transmit antennas, number of receive antennas, and one or more of these.

[0123] For example, capability information related to WTRU actions, including visual sensing, that may be supported by and / or required by the WTRU (e.g., sensors or cameras associated with the WTRU) may include any of the following: FoV resolution (e.g., megapixel count), rendering viewport (e.g., viewport ID), FoV size (e.g., 120 degrees), aperture size, startup time, image quality (e.g., minimum / maximum range), battery life, sound / audio, and display calibration (e.g., corrections applied to distortion and chromatic aberration).

[0124] For example, the WTRU can send one or more preferred mapping configurations, forwarding configurations, and / or resource configurations (e.g., CG, DG) to the network, including specific parameters associated with the forwarding / resource configuration. Preference information can be used to support the in-order delivery of data units and / or to support any of the associated WTRU actions. In one example, when sending a request associated with a preferred configuration, the WTRU can associate and / or indicate weights and / or probability values ​​to different forwarding / resource configurations. For example, the weights and / or probability values ​​can be determined based on the likelihood of the configuration to be applied during transmission and other application / AS layer information / indications. The network can use such weight / probability information to determine and provide combined configurations to the WTRU, and / or to activate / deactivate configurations. For example, the configuration can be matched with weight values ​​indicated by the WTRU.

[0125] For example, information regarding updated forwarding configurations associated with supported and / or requested User Plane / Control Plane (UP / CP) configurations (e.g., radio bearers, LCHs, LCGs, links) may include absolute / relative importance / priority values ​​associated with UP / CP configurations (e.g., radio bearers, logical channels, links), or LCP configurations. In one example, WTRU may indicate updated LCP rules / restrictions (e.g., restrictions associated with the mapping from DRB / LCH to configured resource grants) that can be applied to the set of forwarding / resource configurations (e.g., CGs), whether such LCP rules / restrictions can be temporarily changed over a period of time, conditional LCP configurations applicable when an event of a specific configuration is detected (e.g., a surge in the number of PDUs / data with high QoS requirements), or fallback / default LCP configurations.

[0126] For example, a WTRU can send an indication to the network to request activation / deactivation of mapping / forwarding / resource configurations and / or parameters associated with said configurations that may be pre-configured in the WTRU. When sending the request indication, the WTRU may include the ID of the configuration / parameter. In one example, the request to activate / deactivate the configuration may be accompanied by information about the WTRU's actions, such as splitting / merging QoS flows / PDU sets / data bursts / PDUs.

[0127] For example, a WTRU can transmit signals, channels, radio links, carriers, and such measurements as Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), and Received Signal Strength Index (RSSI) that may be associated with one or more WTRU actions. As another example, a WTRU can transmit QoS-related measurements related to arrival time, the number of PDUs / PDU sets / data bursts received over a period of time, changes in QoS (e.g., increases / decreases in data rate, latency, or reliability), the lifetime associated with the PDU / PDU set / data burst, and the remaining time for delivering the PDU / PDU set / data burst.

[0128] The embodiments described herein and in the following sections of this invention may use any one or more of the above information (e.g., auxiliary information, preferred configuration) sent by the WTRU to the network.

[0129] The WTRU can receive configuration information associated with the in-order delivery of data units from the network. The WTRU can receive any procedures, mechanisms, rules, actions, and such configuration information associated with supporting in-order delivery during UL transmission and / or DL ​​reception of any of the data units (PDUs), PDU sets, and data bursts in one or more data / QoS flows.

[0130] WTRU may receive configuration information from the network periodically (e.g., with one or more configured periodic values), non-periodically / dynamically (e.g., status indications / information or requests / request messages), and / or on a semi-permanent basis (e.g., sent in periodic values ​​over time windows / durations).

[0131] The WTRU can receive configuration information via one or more message types. These message types may include RRC signaling and / or messages (e.g., dedicated / unicast signaling via SRB, broadcast / system information block (SIB)), control PDUs associated with any of the AS layers (e.g., SDAP control PDU, PDCP control PDU), DL MACCE, DCI, PDCCH, PUSCH, non-AS (NAS) layer signaling (e.g., PDU session establishment response or PDU session modification command), or application layer signaling / messages.

[0132] Configuration information that the WTRU can receive from the network may include mapping / forwarding / resource configuration and associated parameters, AS layer status information and / or indications, validity information and / or thresholds.

[0133] For example, the WTRU can receive one or more sets of configurations and / or parameters to be applied at different layers of the AS protocol stack, such as RRC, SDAP, PDCP, RLC, MAC, PHY, or any new layer. Configuration parameters to be applied at different layers may include Service Data Adaptation Protocol (SDAP) / PDCP, PDCP, Radio Link Control (RLC), Media Access Control (MAC), or Physical Layer (PHY).

[0134] SDAP / PDCP may include a 1-to-1, 1-to-M, or N-to-M mapping configuration, tags / indicators / IDs to be applied (e.g., associated with handling QoS flows, PDU sets, data bursts, and association information between PDU sets and data bursts), and a range of values ​​associated with importance / priority information to be identified in the PDU / PDU set. SDAP mapping configuration may refer to information and / or criteria used to map data units (e.g., PDUs, PDU sets, data bursts) at the SDAP layer to one or more PDCP entities / sublayers or DRBs. PDCP mapping configuration may refer to information and / or criteria used to map data units at the PDCP layer to one or more RLC entities / sublayers or LCHs. PDCP may include the ID and SN to be applied (e.g., a range of COUNT / HFN / SN values ​​to be applied to one or more PDU / PDU sets), an indication of whether to apply a per-PDU set level SN (e.g., a new HFN), an indication of whether to apply a new SN set on a per-PDU set basis (e.g., a new starting SN, a new SN range, a predefined SN gap), ROHC configuration, security / encryption parameters, and packet replication configuration (e.g., whether packet replication is activated / deactivated). When in-order delivery of PDU / PDU sets is supported, RLC may include whether to apply AM / UM / Transparent Mode (TM) and parameters associated with AM / UM / TM operations. MAC may include LCH parameters (e.g., priority, PBR, BSD at the PDU and / or PDU set level), LCP configuration (e.g., rules / restrictions / policies for PDU and / or PDU set level disposal, duration of changes between different LCP rules / policies), and configuration for multiplexing / assembly / reordering. PHY can include MCS, PUSCH configuration (e.g., the number of PUSCH opportunities per slot), and HARQ configuration.

[0135] For example, the WTRU can receive one or more resource configurations. In one example, a resource configuration may include configured licensed resources / configurations for UL data transmission. For example, parameters associated with CG resources / configurations may include periodicity, start offset, duration, BWP, digital / subcarrier spacing (SCS) value, number of PRBs, number of timings, number of PUSCH slots per timing, maximum number / duration / length of PUSCHs, one or more licensed MCS values, antenna port, and any such example. In another example, a resource configuration may include semi-persistent scheduling (SPS) resources / configurations for DL ​​data reception. For example, parameters associated with SPS resources / configurations may include periodicity, start offset, duration, BWP, digital / SCS value, number of physical resource blocks (PRBs), number of timings, number of physical downlink shared channel (PDSCH) slots per timing, maximum number / duration / length of PDSCHs, one or more licensed MCS values, antenna port, and any such example. In yet another example, a resource configuration may include dynamically licensed resources (e.g., triggered by UCI, SR, BSR, MAC CE) for UL data transmission. In another example, resource configuration may include dynamically scheduled resources for DL ​​data reception (e.g., triggered by DCI, PDCCH, MAC CE).

[0136] The WTRU can receive at least one set of configuration parameters associated with a default forwarding configuration (e.g., a default LCH set). For example, the default forwarding configuration can be activated and / or used during normal data transmission / reception. The WTRU can also receive additional sets of configuration parameters that may be associated with abnormal operation and may be activated and / or used upon detection of any of the triggering events / conditions (described herein).

[0137] The WTRU can receive default priority values ​​associated with resource configurations (e.g., CGs). For example, a first resource configuration can be associated with a first priority value. A second resource configuration can correspond to a second priority value. For example, the first and second resource configurations can be associated with the same application, and the first set of priority values ​​can be designed to achieve default QoS performance (e.g., default latency, default data rate), while the second set of priority values ​​can be designed to achieve exceptional QoS performance (e.g., surge / burst data rate, very low latency) when using PDU / PDU sets with the first and second resource configurations during transmission.

[0138] AS layer status information and / or indications may include identifiers and / or IDs, forwarding and / or resource configuration status, PDU and / or PDU set delivery status, and / or flow control.

[0139] For example, a WTRU can receive information about one or more IDs to be applied during transmission / reception. This information may include WTRU IDs, such as C-Radio Network Identifier (RNTI), I-RNTI, NAS ID, Temporary Mobile Subscriber Identity (TMSI) / International Mobile Subscriber Identity (IMSI). The information may include IDs associated with applications (e.g., application ID, service ID, session ID, application configuration ID). The information may include group IDs (e.g., associated with a group of QoS flows, a group of forwarding configurations, or a group of devices / WTRUs). The information may also include IDs for individual QoS flows, mapping configurations, and forwarding configurations. The information may also include data type / message IDs (e.g., PDU set ID, data burst ID, flow ID, PDU ID). The information may also include resource configuration IDs (e.g., CG ID, SPS ID).

[0140] For example, when using one or more forwarding / resource configurations, the WTRU can receive information about the implemented / achievable QoS (e.g., latency). For example, when transmitting / receiving any of the data units comprising PDUs, PDU sets, and data bursts, the WTRU can receive information regarding the achievable / realized data rate, latency (e.g., expected, remaining latency), reliability, and priority. The WTRU can also receive statistical / relative / absolute information associated with the implemented / achievable QoS, such as mean, maximum, minimum, standard deviation, and the like.

[0141] For example, the WTRU can receive status reports / feedback regarding SN gaps, including the SNs of PDUs not received at the network, the number of SN gaps, and the size of the SN gaps. Status reports can be received by the WTRU on a per-PDU set, per-data-burst, or per-data-unit group (e.g., within a time window). For example, a status report received by the WTRU can indicate ACK / NACK for the SNs of a PDU set that was successfully or unsuccessfully received. For example, the WTRU can receive status reports associated with the in-order delivery of a PDU set in bitmap form, where each bit in the bitmap can indicate ACK / NACK for the SN of a PDU that was received / not received within the PDU set.

[0142] For example, in one or more forwarding configurations, the WTRU can receive explicit or implicit flow control indications from the network indicating whether to start / increase / decrease / pause / stop the transmission of PDU / PDU sets, possibly in terms of achieving the indicated transmission rate, latency, reliability.

[0143] For example, the WTRU can receive validity information associated with forwarding / resource configuration, indicating whether / when the configuration can be considered valid or invalid based on one or more triggering events / conditions. When the configuration is determined to be invalid, the WTRU can also receive information about whether the configuration should be deactivated and / or released.

[0144] For example, the WTRU can receive information about the following: the WTRU's RRC state (e.g., CONNECTED, INACTIVE, IDLE) and / or whether the configuration is considered valid / invalid when transitioning between different RRC states.

[0145] For example, WTRU can receive instructions on whether to release any of the forwarding configurations.

[0146] Thresholds may include buffer occupancy thresholds, one or more PDU / PDU set payload size thresholds, one or more latency thresholds, one or more latency difference thresholds, and / or relevant time windows.

[0147] For example, a buffer occupancy threshold associated with any of the forwarding configurations can indicate the maximum / minimum amount of data units (e.g., in terms of total payload size / capacity) in one or more buffers (e.g., SDAP buffer, PDCP buffer, LCH buffer) at one or more granularities / types, including PDUs, PDU sets, and data bursts.

[0148] For example, the payload size threshold may be associated with one or more upper and / or lower limits for the total payload size (e.g., in bits or bytes) corresponding to one or more PDUs, PDU sets, and / or data bursts. In another example, the payload size threshold may be associated with one or more upper and / or lower limits for the total number of PDUs in a PDU set or the total number of PDU sets in a data burst.

[0149] A latency threshold may be associated with one or more upper and / or lower limits, which correspond to the maximum / minimum latency value and / or residual latency value (e.g., with respect to PSDB) associated with the reception, buffering, and / or transmission of any data unit (e.g., PDU, PDU set, data burst). The latency threshold may be intended to identify and / or determine the maximum / minimum latency tolerated by the network, application, and / or WTRU, which may be a result of latency caused by, for example, processing, jitter, transmission, congestion, and the like.

[0150] For example, the delay difference threshold can be associated with one or more upper and / or lower limits corresponding to the difference between a first delay value (e.g., the default delay) and a second delay value (e.g., the new / updated delay value).

[0151] For example, a relevant time window can correspond to the minimum time difference between two triggering events (e.g., buffer level measurement, PDU / PDU set arrival time), where the two events are considered relevant to each other when they occur within the relevant time window. When the two events occur outside the relevant time window, they are considered independent. In one example, the WTRU can use the relevant time window to determine whether to send an indication to the network (e.g., send a status report on the ordered reception of data units).

[0152] The embodiments described herein and in the following sections of this invention may use any one or more of the above configuration information received by the WTRU from the network.

[0153] The triggering events and / or conditions used to ensure in-order data delivery can be discussed as follows. A WTRU can be configured with one or more events / conditions associated with triggering one of the aforementioned WTRU actions, including sending auxiliary information / instructions / reports to the network, receiving configuration information / instructions from the network, sending instructions / requests for changing forwarding / resource configurations, etc.

[0154] When XR data units (e.g., PDUs, PDU sets, data bursts) are transmitted / received in one or more QoS streams, triggering events / conditions can be associated with ensuring in-order delivery of data units and / or used to meet expected QoS. Such triggering events / conditions can specify whether an action can be performed by the WTRU and which action can be performed by the WTRU. For example, such triggering events / conditions can specify when (at what time / slot) an action can be performed by the WTRU (e.g., when any of the following events / conditions / criteria are met). For example, the WTRU can determine / select one or more forwarding configurations (e.g., DRB, LCH) based on the detection of one or more triggering events / conditions to ensure in-order delivery. Conditions / events may include indications and / or information from the network, indications and / or information from the application layer and / or higher, buffer status and load at the forwarding configuration (e.g., DRB / LCH), configuration changes at the WTRU, timing and / or timestamp information that may be associated with the expected QoS; one or more measurements on the Uu link, compensation based on the state and / or expected QoS based on in-order delivery, properties associated with the link / channel associated with the forwarding configuration, and / or detection of QoS events (surge in payload size, high-importance data).

[0155] For example, the WTRU can receive from the network (e.g., gNB) indications regarding whether in-order delivery is feasible, the size and number of SN gaps, out-of-order reception, and the expected QoS of transmitting and / or receiving any XR data units on the Uu link (in UL and / or DL). Information can be received semi-statically, during / at configuration, or dynamically. For example, based on the indications / information received from the network, the WTRU can trigger actions described in the solution family described herein (e.g., determining / selecting mappings, forwarding, or resource configuration). For example, indications / information regarding in-order delivery can be given on a per PDU, per PDU set, per data burst, per QoS / data stream, per forwarding configuration, or per resource configuration basis. In another example, the WTRU may receive information from the gNB regarding in-order delivery and / or expected QoS, implicitly based on one or more of the following: the number of HARQ feedbacks received, the size and / or timing of resource grants (configured grants, dynamic grants) allocations, the allocation of retransmission grants corresponding to one or more forwarding configurations (e.g., LCH / DRB / BWP), and the de-prioritization of PUSCH / grants for one or more LCHs due to intra-WTRU / inter-WTRU prioritization. For example, when an indication is received from the network (e.g., in RRC, MAC CE, other control PDUs, or DCIs), the WTRU may be triggered to perform one or more WTRU actions. For example, the indication received by the WTRU may be related to a change / update of the WTRU's forwarding / resource configuration.

[0156] For example, when receiving an indication from the application layer / higher layers, the WTRU can perform any of its actions. The indication may include information about changes in service characteristics / patterns associated with the generation / processing / reception of XR data units in one or more flows. In one example, the application may indicate to the WTRU information about the expected number of QoS flows that can be associated with the application, the expected number of PDUs per PDU set, whether any of the PDUs in the PDU set is relevant, the expected set of frames / PDUs in subsequent moments (e.g., the next frame generation instance), the expected changes in the distribution of importance / priority of the generated PDUs, the expected increase / decrease in latency (e.g., due to processing at the codec / application), and / or jitter for delivering data units in the UL and / or DL, the expected changes in the lifetime associated with the data units, the expected changes in WTRU / user motion / movement (e.g., an increase / decrease in motion rate), and the like. For another example, the WTRU may receive an indication from the application layer / higher layers indicating the arrival (e.g., in batches / bursts) of one or more data units from an application in the WTRU (for the UL) or from an application in the network (for the DL). For example, information regarding the arrival of a PDU may include the expected timing of data unit generation at the application (e.g., time slot / frame) and the expected reception timing at the WTRU. This information may be indicated to the WTRU via, for example, timestamps and / or sequence numbers. As another example, based on an indication of the importance / priority of the transmitted data unit, the WTRU may be triggered to perform one or more WTRU actions. For example, upon receiving an indication including an importance / priority value above a threshold, the WTRU may trigger an action (e.g., change forwarding / resource configuration) for retransmitting lost / missing PDUs and / or transmitting PDUs with compensated (e.g., low latency) delays.

[0157] Buffer status may include at least one of the conditions associated with a measurement (e.g., compared to a threshold). The measurement may include the number of XR data units in one or more buffers associated with a forwarding configuration over a time period, the arrival / departure rate of data units in one or more buffers associated with a forwarding configuration, the average, maximum, and minimum size / capacity of data units in buffers associated with a forwarding configuration (e.g., the number of PDUs in an LCH buffer), a measure of the amount of time spent by one or more data units in a buffer associated with a forwarding configuration, and / or the number of forwarding configurations that satisfy conditions / thresholds associated with data volume, arrival rate, data units (e.g., total payload size), and such.

[0158] For example, if at least one data unit in the forwarding configuration (e.g., a UL LCH buffer waiting to be transmitted in the UL and / or a DL LCH / higher-level buffer waiting to be processed) is in the buffer for a period of time longer than a threshold time value, the WTRU may perform any of the actions described in the family of solutions in this paper (e.g., change the forwarding configuration and / or change the resource configuration).

[0159] For example, if the buffer status of the forwarding configuration exceeds a threshold, WTRU can perform any of the actions described in the solution family in this paper (e.g., send a report or status indication).

[0160] For example, other buffer state metrics can be monitored to determine expected QoS, such as the number of buffered data units that are above / below a configured threshold in one or more associated forwarding configurations, and / or the rate at which data units arrive / leave the buffer with respect to the configured arrival / departure rate.

[0161] For example, when a change to the mapping configuration, forwarding configuration, and / or resource configuration is determined, the WTRU can be triggered to perform one or more WTRU actions (e.g., sending an indication / report to the network), including changing at least one of the parameters at the mapping configuration (e.g., mapping QoS flows to a new forwarding configuration), DRB / LCH (e.g., priority, PDB, PBR, PSDB, PSER), LCP configuration, and / or resource configuration / parameters (e.g., CG, DG, SPS).

[0162] For example, when any of the Connected Mode Discontinuous Receive (CDRX) / Discontinuous Receive (DRX) configuration and the associated parameters applied at the WTRU are modified / updated, the WTRU can be triggered to perform one or more WTRU actions, which may affect the transmit / receive modes and / or QoS that are available during data transmission.

[0163] For example, the WTRU can track timing-related information (e.g., timestamps, sequence numbers, tags, or timing control PDUs) in one or more data units received in earlier time windows to determine latency or jitter. This timing information can then be used to determine whether / how in-order delivery is achieved, and whether QoS can be met for upcoming / new data units in the next time window.

[0164] In one example, timing information can be determined / indicated as deadlines / delay limits and / or lifetimes that can be met on a per PDU, per PDU set, per data burst, or per QoS flow basis. For example, timing information can be determined across one or more associated / related QoS flows, including associated UL flows and associated DL flows. In another example, timing information can also be determined / indicated on a count basis (e.g., data unit count). For example, when determining timing information and its impact on in-order delivery, the WTRU can trigger actions described in the solution family described herein (e.g., determining mapping / forwarding configuration).

[0165] In another example, the WTRU may periodically or based on the setting / expiration of a configured timer to send information / indications / reports to the network (described in another section of the invention).

[0166] The WTRU can perform measurements on the Uu link, such as those corresponding to RSRP, RSSI, Channel Quality Indicator (CQI), and CSI, to determine the expected QoS. Channel / load measurements performed over a specific configuration period can indicate whether a data unit can achieve the expected QoS during transmission and / or reception, or whether it is likely to exceed the QoS budget (e.g., PSDB). For example, based on measurements on the Uu link, the WTRU can trigger actions described in the solution family described herein (e.g., determining the mapping configuration).

[0167] In one example, the WTRU can determine the Uu link condition based on the number of ARQ / HARQ (ACK / NACK) feedback messages and / or Automatic Repeat Request (ARQ) / HARQ retransmissions made in one or more HARQ procedures associated with the forwarding configuration applied to the transmitted data unit. For example, the in-order delivery status (e.g., the size of the SN gap, the reordering delay) can be determined based on the (configured) mapping between feedback / retransmission (ReTx) counts and reordering delays in the UL and / or DL. For instance, a ReTx count above a threshold can translate to poor Uu link / channel condition and thus reduce the duration for reordering.

[0168] For example, when channel measurements (e.g., RSRP, RSSI, RSRQ, CQI, CSI) performed on the Uu link increase / decrease with respect to a configured threshold and / or remain above / below the threshold for a specific duration, the WTRU can be triggered to perform one or more WTRU actions and / or send an indication to the network.

[0169] For example, a WTRU can be triggered to perform a WTRU action when one or more QoS-related measurements (e.g., latency measured for a data unit in one or more forwarding configurations) exceed a certain threshold.

[0170] In another example, the WTRU can trigger the actions described in this family of solutions based on the determination of the duration / jitter or change in duration / jitter between the reception of consecutive PDUs associated with a PDU set or between the reception of consecutive PDU sets associated with a data burst and / or the reception of data units in one or more related streams in the UL and / or DL. For example, the WTRU can infer an increase / decrease in jitter between consecutive PDUs to determine whether the processing load at the application layer / higher layer is high or low. In this case, for example, to determine the duration, the WTRU can set a timer when the first data unit arrives and reset the timer when the associated second data unit arrives.

[0171] For example, during UL transmission and / or DL ​​reception, a WTRU can be triggered to perform one or more WTRU actions based on the determination of the in-order delivery status of one or more data units (e.g., the size of the SN gap) and / or the expected QoS, including an indication of whether the data unit arrives delayed or early. In this case, for example, by selecting an appropriate forwarding configuration, the WTRU can trigger an action such that delayed or early data units can be transmitted with a determined compensation amount. In one example, one or more actions can be triggered when a change in the expected QoS of a data unit (e.g., higher / lower) is detected to reach a specific threshold.

[0172] In one example, the WTRU can use a forwarding configuration that enables the compensation amount to be satisfied to determine the delayed PDU to be sent, where the compensation amount can be determined, for example, by subtracting the expected delay from the actual delay.

[0173] For example, the WTRU can be configured using properties specific to the forwarding configuration / link / channel. The forwarding configuration / link / channel can include forwarding configuration / link / channel priorities, or configuration parameters that enable / disable specific actions of the forwarding configuration / link / channel. For example, a forwarding configuration / link / channel configured with a high priority can allow the WTRU to change any configuration (regarding the initial or default configuration). For example, the WTRU can change parameters of a forwarding configuration associated with a high priority, as long as the change affects other lower priority forwarding configurations (e.g., only affecting other lower priority forwarding configurations).

[0174] For example, QoS events may include a surge of events that could be associated with an increase in the number of data units or the amount of data within a time window, indicated / marked with high importance / priority. Similarly, other QoS events may include, for example, QoS reductions associated with a decrease in the number of data units or the data / payload capacity within a time window.

[0175] For example, when one or more QoS events are detected, the WTRU may be triggered to perform one or more WTRU actions, taking into account the expected duration of the indicated / determined QoS events. Then, for example, after the detected QoS event has ended, the WTRU may perform other WTRU actions that could cause a fallback to the default configuration. In one example, when a surge event is detected (e.g., an increase in total payload or the number of PDU sets), the WTRU may trigger actions that change the resource configuration in the UL and / or DL ​​(e.g., updating the CG and / or SPS for the duration of the surge). When it is determined that the surge has decreased or the surge event has ended, the WTRU may fall back to using the default resource configuration in the UL and / or DL ​​(e.g., the default CG and / or SPS).

[0176] The WTRU can determine dependencies and / or associations between XR data units in sequence. The WTRU can determine whether a PDU transmitted in the UL and / or received in one or more streams in the DL is dependent on and / or associated with a data unit (e.g., a PDU set, a data burst). The WTRU can determine the association of a PDU with a PDU set and / or a data burst based on explicit indications and / or implicit parameters / identifiers detectable by the WTRU in the PDU or stream. In determining the association / dependency of a PDU with a PDU set and / or the association of a PDU / PDU set with a data burst, the WTRU can perform specific actions that can result in in-sequence delivery during transmission.

[0177] For example, parameters / identifiers used to determine the association between PDUs and data units can be configured in the WTRU (e.g., via RRC signaling, NAS layer signaling, and / or application / higher layer signaling). The WTRU can assign SNs to PDUs / PDU sets during UL transmission of data units based on the determination of dependency / association information between different data units. For example, when identifying that a first data unit and a second data unit may be interdependent, the WTRU can assign new starting SN values ​​(e.g., by resetting and starting COUNT, HFN, SN) and / or new SN value ranges to the first and second data units.

[0178] The parameters / identifiers used by WTRU to identify the association between PDU and data unit may include one or more identifiers, IDs, indexes or sequence numbers, priority or importance information associated with the flow, time or timing information in the associated flow, and / or explicit information from the application, higher layers or AS layers.

[0179] For example, when a public ID / index / SN associated with a PDU set is detected, the WTRU can determine the first and / or second PDUs in the same QoS flow, or different QoS flows can be associated with the PDU set. The ID can be detected within the PDUs in one or more QoS flows (e.g., in the header and / or payload). For example, the IDs of the PDU set and / or the applications associated with the PDU set can be pre-configured in the WTRU. For example, a similar set of IDs / indexes / SNs can be used to identify the association of one or more PDU sets with a data burst.

[0180] For example, a WTRU can determine that a first and / or second PDU in one or more QoS flows can be associated with a PDU set based on the detection of common and / or similar importance / priority indicators in PDUs within one or more QoS flows (e.g., in the header and / or payload). For example, the importance / priority indicators can be related to spatial or temporal indicators. In another example, when an importance / priority indicator detected by the WTRU (e.g., in the PDU header or payload) is higher than / lower than one or more importance / priority thresholds, the WTRU can determine which PDUs can be associated with the PDU set. For example, similar importance / priority indicators can be used to identify the association between a PDU / PDU set and a data burst.

[0181] For example, when a first PDU and / or a second PDU in one or more QoS flows is received or arrives at the WTRU within a duration / time window, the WTRU can determine that the PDU can be associated with a PDU set. For example, the duration / time window can correspond to the time difference between the reception times of the first PDU (e.g., at t1) and the second PDU (e.g., at t2) within the same QoS flow. Similarly, for example, the duration / time window can correspond to the time difference between the reception times of a PDU in the first QoS flow (e.g., at t1) and the reception times of a PDU in the second QoS flow (e.g., at t2). In this case, when the time difference (e.g., T2–t1) is less than a duration / time window threshold, the WTRU can determine that the first and second PDUs in the same or different QoS flows can be associated with a PDU set. In one example, the duration / time window threshold can be associated with the frame rate (e.g., 60Hz, 120Hz) used by the application / higher layer to generate the PDU / PDU set. For example, similar methods can be applied to determine the association between a PDU / PDU set and a data burst based on time / timing information. In another example, based on the general format and / or granularity of timing information (e.g., timestamps, packet counts, sequence numbers) carried in the PDU (e.g., header, payload), the WTRU can determine that the first and second PDUs in one or more streams can be associated with a set of PDUs or with a data burst.

[0182] For example, when receiving an explicit indication / message from a WTRU or a higher layer / AS layer in the network, the WTRU can determine that a first PDU and / or a second PDU in one or more QoS flows can be associated with a PDU set or data burst. In one example, the WTRU may receive timing information (e.g., period, burst time window / duration) in the indication that the PDU can be associated with during its period. In this case, for example, in addition to the timing information (e.g., burst duration), the WTRU may assume that the PDU may be unrelated and / or not associated with a PDU set or data burst.

[0183] The WTRU can select a forwarding configuration at the AS layer for in-order delivery. When performing UL transmission and / or DL ​​reception, the WTRU can receive one or more data units (e.g., PDU, PDU set, data burst) from a higher layer / application and can map the data units to one or more selected forwarding configurations (e.g., DRB and / or LCH) for in-order delivery.

[0184] Figure 2A and 2BThe illustration shows an example forwarding configuration for the AS layer for in-order data delivery. As shown, when performing UL transmission and / or DL ​​reception using the following, the WTRU can map one or more data units to select one or more forwarding configurations 200a-200e (e.g., DRB and / or LCH) for in-order delivery: (a) configuration 200a (e.g., PDU sets in multiple QFIs are mapped to multiple DRBs), (b) configuration 200b (e.g., PDU sets in multiple QFIs are mapped to a single DRB), (c) configuration 200c (e.g., PDU sets in multiple QFIs are mapped to a single DRB and multiple LCHs), (d) configuration 200d (e.g., PDU sets in a single QFI are mapped to a single DRB), and (e) configuration 200e (e.g., PDU sets in a single QFI are mapped to a single DRB and multiple LCHs).

[0185] In Figure 2AIn one example related to configuration 200a illustrated in the diagram, the WTRU can receive one or more PDUs associated with PDU sets 202a and 204a in QFI 206a and QFI 208a, respectively. The received PDU sets can be mapped to DRB1 (e.g., PDCP 212a) and DRB2 (e.g., PDCP 214a) at SDAP sublayers / entities 210a / 240a. To support ordered delivery of PDU sets, for example, SNs (e.g., counts) or other indicators / markers (described in other sections of the invention) can be added to PDU sets 202a and 204a at any of the SDAP sublayers / entities, new sublayers / entities below SDAP, or new sublayers / subfunctions / entities above PDCP 212a and PDCP 214a (e.g., higher / common PDCP sublayers). SNs can be dispatched on a per-PDU basis (e.g., for each PDU in a PDU set) and / or on a per-PDU set basis (e.g., for each PDU set). Each PDCP entity (e.g., PDCP 212a and PCDP 214a) can be configured to support the in-order delivery of PDUs in PDU sets 202a and 204a, respectively. For example, each PCDP entity can add an SN to the PDUs associated with PDU sets 202a and 204a, respectively. PDUs in PDU sets 202a and 204a can be mapped to LCH 216a and LCH 218a, possibly corresponding to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets into one or more TB and UL transmissions, MAC entities / sublayers 220a / 234a can ensure that the QoS of the PDU sets (e.g., PSDBs) in the corresponding LCHs is met, which may be based on PDU set parameters (e.g., priority, remaining delay), LCH parameters (e.g., priority, PBR, BSD), and / or the use of LCP procedures. Tx PHY entities / sublayers 222a can perform PHY layer processing (e.g., encoding, modulation, resource mapping, antenna mapping) on ​​the data prior to transmission. Transmitted data can be received at Rx PHY entities / sublayers 236a for PHY layer processing (e.g., demodulation, decoding). Data can be further processed at the received Rx MAC entity / sublayer 234a. Data can be mapped to LCHs 230a and 232a based on information in the PDU header. The data in LCH 230a and LCH 323a can be further mapped to Rx PDCP entities 226a and 228a, respectively.In an example associated with DL reception, the receiving PDCP entity (e.g., PDCP 226a and PDCP 228a of the WTRU) may, before delivering the PDU sets to higher layers, perform PDU reordering corresponding to PDU sets 202a and 204a, respectively, by the transport entity based on the SN or other indications of the PDUs within the PDU sets (described in other sections of the invention). Alternatively, for example, the SDAP entity or an entity above PDCP 226a and PDCP 228a may perform PDU reordering within PDU sets 202a and 204a, respectively, based on the SN. For example, the SDAP entity or an entity above PDCP 226a and PDCP 228a may perform PDU set reordering by the transport entity based on the SN or other indications associated with different PDU sets.

[0186] In Figure 2BIn one example related to configuration 200b illustrated in the diagram, the WTRU can receive one or more PDUs associated with PDU sets 202b and 204b in QFI 206b and QFI 208b, respectively. The received PDU sets can be multiplexed / mapped to DRB1 (e.g., PDCP 238b) at SDAP sublayers / entities 210b / 224b. To support ordered delivery of PDU sets, for example, SNs or other indications (described in other sections of the invention) can be added to PDU sets 202b and 204b (on a per-PDU basis and / or per-PDU set basis) at any of the SDAP sublayers / entities, new sublayers / entities below SDAP 210b, or PDCP 238b. PDUs in PDU sets 202b and 204b can be mapped to LCH 216b, possibly corresponding to RLC1. For example, during the scheduling and / or multiplexing of PDU sets into one or more TB and UL transmissions, the MAC entity / sublayer can ensure that the QoS of the PDU set (e.g., PSDB) in LCH 216b is satisfied, which may be based on PDU set parameters (e.g., priority, remaining delay, SN) and / or the use of LCP procedures. Tx PHY entity / sublayer 222b can perform PHY layer processing (e.g., encoding, modulation, resource mapping, antenna mapping) on ​​the data prior to transmission. The transmitted data can be received at Rx PHY entity / sublayer 236b for PHY layer processing (e.g., demodulation, decoding). The data can be further processed at the received Rx MAC entity / sublayer 234b. Data can be mapped to LCH 218b based on information in the PDU header. Data in LCH 218b can be further mapped to Rx PDCP entity 240b. In another example associated with DL reception, the receiving PDCP entity (e.g., PDCP 240b at the WTRU) may, before delivering the PDU sets to higher layers, perform PDU reordering corresponding to PDU sets 202b and 204b respectively, based on the SN or other indications associated with PDUs within and across different PDU sets (described in other sections of the invention). Alternatively, for example, an entity above SDAP entity 224b or PDCP 240b may perform PDU reordering within and across different PDU sets based on the SN.

[0187] In Figure 2AIn one example related to configuration 200c illustrated, the WTRU can receive one or more PDUs associated with PDU sets 202c and 204c in QFI 206c and QFI 208c, respectively. The received PDU sets can be mapped to DRB1 (e.g., PDCP 238c) at the SDAP sublayer / entity. To support ordered delivery of PDU sets, for example, SNs or other indications (described in other sections of the invention) can be added to PDU sets 202c and 204c on a per-PDU and / or per-PDU set basis at any of the SDAP sublayer / entity, a new sublayer / entity under SDAP, or PDCP 238c. The PDUs in PDU sets 202c and 204c can be mapped to LCH 216c and LCH 218c, which may correspond to RLC1 and RLC2, respectively. For example, during the scheduling and / or multiplexing of PDU sets into one or more TB and UL transmissions, MAC entities / sublayers 220c / 234c can ensure that the QoS of the PDU sets (e.g., PSDBs) in the corresponding LCHs can be satisfied, possibly based on PDU set parameters (e.g., priority) and / or using LCP procedures. Tx PHY entities / sublayers 222c can perform PHY layer processing (e.g., encoding, modulation, resource mapping, antenna mapping) on ​​the data prior to transmission. Transmitted data can be received at Rx PHY entities / sublayers 236c for PHY layer processing (e.g., demodulation, decoding). Data can be further processed at the receiving RxMAC entity / sublayer 234c. Data can be mapped to LCHs 230c and 232c based on information in the PDU header. Data in LCHs 230c and 232c can be further mapped to Rx PDCP entities 240c. Data in Rx PDCP entity 240c can be mapped to Rx SDAP entity 224c. In another example associated with DL reception, the receiving PDCP entity (e.g., PDCP 240c at the WTRU) can perform reordering on PDUs corresponding to PDU sets 202c and 204c, respectively, based on the SN or other indications associated with PDUs within and across different PDU sets (described in other sections of the invention), before delivering the PDU sets to higher layers. Alternatively, for example, SDAP entities 210c / 224c can perform reordering across different PDU sets based on the associated SN.

[0188] In Figure 2BIn another example related to configuration 200d illustrated, the WTRU can receive one or more PDUs associated with PDU sets 202d and 204d in QFI 206d. The received PDU sets can be mapped to DRB1 (e.g., PDCP 238d) at SDAP sublayer and / or entity 210d. To support ordered delivery of PDU sets, for example, SNs or other indications (described in other sections of the invention) can be assigned to PDU sets 202d and 204d on a per-PDU basis and / or per-PDU set basis at any of the SDAP sublayer and / or entity, a new sublayer and / or entity below SDAP 210d, or at PDCP 238d. PDUs in PDU sets 202d and 204d can be mapped to LCH 216d, possibly corresponding to RLC1. For example, during the scheduling and / or multiplexing of PDU sets into one or more TB and UL transmissions, the MAC entity and / or sublayers 220d / 234d can ensure that the QoS of the PDU set (e.g., PSDB) in LCH 216d can be satisfied, possibly based on PDU set parameters (e.g., priority) and / or using LCP procedures. The Tx PHY entity / sublayer 222d can perform PHY layer processing (e.g., encoding, modulation, resource mapping, antenna mapping) on ​​the data prior to transmission. The transmitted data can be received at the Rx PHY entity / sublayer 236d for PHY layer processing (e.g., demodulation, decoding). The data can be further processed at the receiving RxMAC entity / sublayer 234d. Data can be mapped to LCH 218d based on information in the PDU header. Data in LCH 218d can be further mapped to Rx PDCP entity 240d. Data in Rx PDCP entity 240d can be mapped to Rx SDAP entity 224d. In another example associated with DL reception, the receiving PDCP entity (e.g., PDCP 240d at WTRU) may, before delivering the PDU set to a higher layer, perform a reordering of PDUs corresponding to PDU sets 202d and 204d, respectively, based on the SN or other indications associated with PDUs within and across different PDU sets (described in other sections of the invention).

[0189] In Figure 2BIn another example related to the configuration 200e illustrated, the WTRU can receive one or more PDUs associated with PDU sets 202e and 204e in QFI 206e. The received PDU sets can be mapped to DRB1 (e.g., PDCP 238e) at SDAP sublayers and / or entities 210e. To support ordered delivery of PDU sets, for example, SNs or other indications (described in other sections of the invention) can be added to PDU sets 202e and 204e at any of the SDAP sublayers and / or entities, new sublayers and / or entities under SDAP, or at PDCP 238e. PDUs in PDU sets 202e and 204e can be mapped to LCH 216e and LCH 218e, possibly corresponding to RLC1 and RLC2, respectively, by PDCP 238e based on PDU set attributes (e.g., importance, payload size, number of PDUs, remaining delay, etc.). For example, during the scheduling and / or multiplexing of PDU sets into one or more TB and UL transmissions, the MAC entity and / or sublayers 220e / 234e can ensure that the QoS of the PDU set (e.g., PSDB) in the corresponding LCH can be satisfied, which may be based on PDU set parameters / attributes (e.g., priority) and / or the use of LCP procedures. The Tx PHY entity / sublayer 222e can perform PHY layer processing (e.g., encoding, modulation, resource mapping, antenna mapping) on ​​the data prior to transmission. The transmitted data can be received at the Rx PHY entity / sublayer 236e for PHY layer processing (e.g., demodulation, decoding). The data can be further processed at the received Rx MAC entity / sublayer 234e. Data can be mapped to LCH 230e and LCH 232e based on information in the PDU header. Data in LCH 230e and LCH 232e can be further mapped to the Rx PDCP entity 240e. Data in Rx PDCP entity 240e can be mapped to RxSDAP entity 224e. In another example associated with DL reception, the receiving PDCP entity (e.g., PDCP 240e at WTRU) can perform PDU reordering corresponding to PDU sets 202e and 204e respectively, based on SN or other indications associated with PDUs within and across different PDU sets (described in other sections of the invention), before delivering the PDU sets to higher layers.

[0190] The WTRU can support the in-order delivery of XR data units during UL transmission and / or DL ​​reception. When transmitting data to the network in the UL and / or receiving data in the DL, the WTRU can be configured to perform in-order / ordered delivery of data units associated with PDUs, PDU sets, data bursts, or groups thereof. For example, the procedures, criteria, and / or conditions for performing in-order delivery of data units can be configured by the network in the WTRU (e.g., via RRC signaling). In one solution, the network can send instructions to the WTRU regarding changes to the procedures, criteria, and / or conditions to perform in-order delivery of data units.

[0191] In examples related to UL transmission, the WTRU can receive one or more data units from a higher layer, including PDUs, PDU sets, and / or data bursts or groups thereof. The WTRU can forward the data units to lower layers during processing and transmit them within the UL, such that the data is received at the network in an order intended by the application, higher layers, and / or the network. For example, in the case of DL, the WTRU can receive one or more data units from the network. For example, before forwarding the data to higher layers, the WTRU can ensure that the received data units are arranged or interleaved in a specific order / sequence intended by the application, higher layers, and / or the network.

[0192] Operations / functionalities related to the in-order delivery of data units performed by the WTRU may include the allocation and / or dispatch of sequence numbers (SNs) or identifiers (IDs), retransmission of missing data units, and / or one or more of the following buffers used to ensure in-order delivery:

[0193] For example, SNs or IDs can be assigned / included for data units of different granularities, including on a per-PDU basis, a per-PDU set basis, a per-data burst basis, or a per-group basis for any one or more of the aforementioned data units. In this case, for example, for each of the PDU sets received from a higher layer, the WTRU can include a per-PDU set SN or ID. For example, such a per-PDU set SN or ID can be common and / or included in one or more (e.g., all) PDUs associated with said PDU set. The WTRU can assign SNs to PDU sets in a sequential, first-come-first-served manner, such that the PDU set that arrives first in time can be assigned SN x, the next arriving PDU set can be assigned SN x+1, and so on. PDUs within a PDU set can also be assigned SNs in the order they arrive within the PDU set. PDUs and / or PDU sets can be assigned numbers to associate dependencies between them. For example, (x, 1), (x, 2), and (x, 3) can be assigned by WTRU to PDUs 1, 2, and 3 of PDU set x.

[0194] In one solution, the WTRU can assign SNs to data units in an incremental manner based on criteria including the order in which it receives data units from higher layers, markers (e.g., SN, ID, timestamp, priority / importance) indicated by the higher layer / application within the data units (e.g., the data unit header), and the time window in which the data units are received. For example, a first set of PDUs received from a higher layer can be assigned a first SN, and a second set of PDUs received after the first set can be assigned a second SN, wherein the value of the second SN can be higher than that of the first SN.

[0195] In one solution, for an SN assigned and added to a data unit by a WTRU, there can be a start value and an end / upper value (e.g., a superframe number value). For example, if the end / upper value is exceeded, the WTRU can restart assigning SNs to newly received data units.

[0196] In one example, the upper limit of SN can be associated with a valid time value, a valid counter (e.g., an HFN range), a timer, or a delay limit value. In this case, as long as the valid time or counter value is valid, the WTRU can continue to increment SN from the initial / starting SN value during allocation until SN reaches the end / upper limit. If the valid time or counter is determined to be invalid, or the associated timer expires before reaching the end / upper limit, the WTRU can reset the SN allocation and use the starting SN value when allocating SN to newly received data units.

[0197] In one example, to differentiate between different PDU sets, the serial numbers (SNs) of the last PDU assigned to the first PDU set and the first PDU of the second PDU set can differ by a fixed SN gap or SN offset value. For example, when configured with an SN offset / gap value of 10, the last PDU in PDU set 1 can be assigned an SN value of 500, and the first PDU in subsequent PDU set 2 can be assigned an SN value of 510.

[0198] For example, in the case of UL transmission, the WTRU can retransmit any of the data units (e.g., PDUs, PDU sets, data bursts, or groups thereof) that may not have been successfully or sequentially received by the network. The WTRU can perform retransmission of data units when it receives a status indication or request indication from the network. For another example, when received in a status / request indication, the WTRU can retransmit one or more missing data units, which may indicate the SN of successfully received data or the SN of data not received by the network (e.g., SN gaps). In yet another example, the WTRU can also retransmit some data units. Data units may depend on or be associated with previously transmitted data or data requested for retransmission by the network. In yet another example, when retransmitting some missing data units, the WTRU can apply different forwarding configurations (e.g., using a more robust modulation and coding scheme (MCS), using different links, channels, beams, resources, resource sets) to ensure higher reliability during retransmission.

[0199] For example, in the case of DL reception, the WTRU can identify the SN of data units that may not have been received in order or are missing at the WTRU. The WTRU can then generate an indication and / or transmit an indication (e.g., a status indication, a request message) to the network, indicating the SN of successfully received data or the SN of data not received by the WTRU. The indication (e.g., a status / request indication) can be transmitted periodically by the WTRU or when one or more pre-configured events are detected (e.g., a timer expires, the number of missing data units (e.g., SN gaps) exceeds a threshold).

[0200] For example, when receiving an indication (e.g., a status indication, a request message) from the network, the WTRU may buffer any of the data units being transmitted or retransmitted in the UL. The WTRU may discard the buffered data units upon receiving an indication that the data units were successfully received in order. In another example, where the WTRU can receive any of the data units from the application layer / higher layers, the WTRU may buffer one or more data units that may be received out of order (e.g., receiving data with a later SN / ID / timestamp before data with an earlier SN / ID / timestamp) until all data is received in order, before sending the data units to the lower layers. Similarly, in the case of DL reception, the WTRU may buffer any of the out-of-order data units (e.g., receiving data with a later SN before data with an earlier SN) until all data is received in order, before sending the data to the application layer / higher layers. In another example, the WTRU may buffer data received out of order in the UL or DL ​​for a specific configured duration before forwarding the data or discarding the buffered data. For example, the duration may be associated with a latency budget associated with the data unit (e.g., PSDB). In one solution, the duration can be configured based on the number of out-of-order data units received (e.g., the size of the data units). For example, if some PDUs within a PDU set or some PDUs within a data burst are received out of order, the duration can be shorter compared to if some PDU sets are received out of order. In another solution, the duration can be configured based on the number of out-of-order data units received; for example, the more out-of-order data units received, the longer the WTRU buffers out-of-order data before forwarding / discarding the buffered data.

[0201] As described above, where the WTRU may have operational / functionality associated with the sequential delivery of data units (e.g., PDU, PDU set, data burst), the different entities / sublayers may include any one or more sublayers / subfunctions within or at the SDAP, PDCP, RLC, MAC (e.g., in one or more LCHs), PHY, and / or new sublayers.

[0202] In one example, where the WTRU can receive one or more data units (e.g., a set of PDUs) from a higher layer in one or more data / QoS flows, the WTRU can be configured to map the received data units to multiple DRBs (e.g., PDCP entities / sublayers). In this case, functionality to support in-order delivery (e.g., SN allocation, retransmission, reordering) can be performed at SDAP sublayers and / or entities, new layers between SDAP and one or more PDCP entities and / or sublayers, and / or one or more subfunctions and / or sublayers within the PDCP. For example, a subfunction / sublayer within the PDCP can be located at a higher level of the PDCP, which is common to one or more (e.g., all) lower-level PDCP entities to which a set of PDUs received from a higher layer / SDAP can be mapped.

[0203] In another example, the WTRU can be configured to map data units (e.g., PDU sets) received in one or more data / QoS streams to a single DRB (e.g., PDCP entity / sublayer). For example, functionality to support in-order delivery can be implemented at the SDAP sublayer / entity and / or the PDCP sublayer and / or entity.

[0204] WTRU can update the priority of missing PDUs based on delivery status indications and remaining delays.

[0205] In the example, the WTRU can update the priority of missing PDUs at the receiving entity (e.g., the network) based on delivery status indications (e.g., missing SNs) and the remaining delay associated with the data unit. For example, when data units (e.g., PDUs, PDU sets, data bursts) are transmitted in the UL, the solution can be applied at the transmission entity at the WTRU, including at SDAP, PDCP, new sublayers, and / or MAC. The solution can be applied when data units are lost during transmission or retransmission, or are not successfully received at the receiving entity (e.g., no PDUs from a PDU set are received within the PSDB). For example, the solution can be applied when a specific percentage (e.g., above a percentage threshold) of one or more (e.g., all) PDUs or a PDU set is expected to be received at the receiving entity at the network (e.g., RLC, PDCP, SDAP) to be considered a successful reception for in-order delivery.

[0206] In an example implementation of the solution, the WTRU may receive configuration information from the network, including at least one or more thresholds associated with the number of PDUs to be retransmitted (e.g., due to feedback received from the receiving entity regarding missing PDUs) and / or the remaining delay (e.g., the total delay budget / PSDB for the PDU set). For example, the configuration information may indicate one or more thresholds associated with one or more retransmissions of multiple PDUs. A first threshold of the one or more thresholds may be associated with the number of PDUs to be transmitted (e.g., corresponding to the number of PDUs to be transmitted). A second threshold of the one or more thresholds may be associated with the remaining delay budget (e.g., corresponding to the remaining delay budget).

[0207] The WTRU can receive one or more PDUs from a PDU set from higher layers and / or applications. The WTRU can assign SNs (e.g., COUNT, HFN, SN) to PDUs at transport entities (e.g., SDAP or PDCP), and / or deliver PDUs to lower layers including a first RLC entity and / or a first LCH associated with the initial priority / importance of the PDU set. For example, the WTRU can determine the initial priority / importance of the PDU set based on markers in the headers of the PDUs associated with the PDU set. For example, the WTRU can forward PDUs from the PDU set to a first RLC / LCH based on configured mapping rules that instruct the mapping of PDUs from the PDU set to the RLC / LCH based on the priority / importance of the PDU set. When the PDUs from the PDU set are mapped to the first LCH, the PDUs can then be further processed and transmitted in the UL. The first LCH can be associated with a first priority. For example, the WTRU can transmit PDUs from the PDU set via a first LCH associated with a first priority. The WTRU may start one or more timers when forwarding PDUs of a PDU set to a lower layer and / or when transmitting PDUs in the UL (e.g., a timer may be started when the first PDU of the PDU set is forwarded and / or transmitted). For example, the timer may be used to determine the remaining delay to satisfy the delay budget / PSDB associated with the PDU set when transmitting the remaining PDUs of the PDU set, and / or to determine the time elapsed before receiving a status indication from the network.

[0208] The WTRU can receive indications (e.g., status indications and / or feedback) regarding the reception of PDUs in a PDU set at the network. Status indications can be received from the receiving entity at the network or from a lower layer at the WTRU on a per-data-unit (e.g., per PDU, per PDU set, per data burst) or per-data-unit group basis, via one or more of the following: HARQ feedback, RLC feedback (RLC ACK / NACK), PDCP status report / feedback, and / or SDAP feedback. For example, a status indication can indicate the SN of PDUs in a PDU set that can be received (ACK) and / or not received (NACK), and the percentage of PDUs in the PDU set that were successfully received or not successfully received. For example, a status indication can be received in bitmap form, indicating the ACK / NACK of PDUs in a PDU set that have been successfully received or not successfully received and / or the SN associated with the PDU set. The WTRU can receive indications that one or more PDUs in the PDU set are to be retransmitted. For example, the instruction may indicate that one or more PDUs in the PDU set should be retransmitted.

[0209] The WTRU can determine information about PDUs to be retransmitted in the PDU set based on status indications and the remaining delay associated with the delay budget of the PDU set. For example, information about the PDUs may include the number of PDUs to be retransmitted, the serial number (SN) of the PDUs to be retransmitted, the remaining delay associated with the PDUs to be retransmitted (e.g., the remaining delay budget), and / or the priority of the PDUs to be retransmitted. This information can be used to determine subsequent WTRU actions to ensure the in-order delivery of PDUs in the PDU set.

[0210] The WTRU can determine the priority of PDUs to be retransmitted. For example, the WTRU can determine whether to update the priority of PDUs to be retransmitted. The WTRU can update the priority of PDUs to be retransmitted if the number of PDUs to be retransmitted is less than or equal to a threshold associated with the number of PDUs to be retransmitted, and / or if the determined remaining delay is less than or equal to the remaining delay threshold. For example, the WTRU can increase the priority of PDUs to be retransmitted so that they can be retransmitted with lower delay to satisfy the delay budget / PSDB associated with the PDU set. In the example, the WTRU can increase the priority by one or more values ​​(e.g., from priority level 5 (low) to priority level 2 (high)), where the amount of the priority increment can be determined based on any of the following: the amount of remaining delay, the number of PDUs to be retransmitted, the payload size of the PDUs to be retransmitted, the percentage of remaining PDUs for in-order delivery, the buffer level at the LCH (e.g., the number of pending PDUs), etc. The WTRU can select a second RLC / LCH associated with the determined updated priority, and / or can forward the PDUs to be retransmitted to the second RLC / LCH for retransmission in the UL. Such selection and forwarding of the PDUs to be retransmitted can be done at the transport PDCP entity at the WTRU. For example, the WTRU can determine the second LCH to be used for retransmitting PDUs based on the number of PDUs to be retransmitted being greater than a first threshold and / or the remaining delay budget of the PDUs to be retransmitted being less than a second threshold. The second LCH can... Additionally or alternatively, for example, if the number of PDUs to be retransmitted is higher than a threshold associated with the number of PDUs to be retransmitted, and / or if the determined remaining delay is greater than the remaining delay threshold, the WTRU may retain the initial priority of the PDUs to be retransmitted and forward the PDUs to the first RLC / LCH for retransmission in the UL.

[0211] In the example, the WTRU can determine whether and how to retransmit PDUs in a PDU set based on attributes such as the type of the PDU set, its importance, payload size (bits / byte), the number of PDUs in the PDU set, and the percentage of the PDU set to be retransmitted. This includes determining and / or updating the priority of the PDUs to be retransmitted. For example, for a PDU set that may require one or more (e.g., all) PDUs in the PDU set to be received to be considered a successful PDU set and / or a PDU set of a type that has high importance (e.g., above an importance threshold or includes a high importance flag), the WTRU can determine to increase the priority of the PDUs to be retransmitted (e.g., retransmit only).

[0212] In the example, where the WTRU can transmit PDUs in a PDU set in one or more batches within the UL, the WTRU can determine the priority of the second batch of PDUs to be assigned to the PDU set based on the transmission status of the first batch of PDUs in the PDU set (e.g., the number of PDUs to be retransmitted, remaining latency, percentage of the remaining PDU set) and / or PDU set attributes (e.g., type, importance, payload size, total number of PDUs). For example, if a certain percentage (e.g., above a percentage threshold) of the first batch of PDUs is successfully received, the WTRU can increase the priority of the second batch of PDUs (e.g., by forwarding the PDUs to a higher-priority LCH). For example, the priority increase can be performed to ensure that the second batch of PDUs is received with low latency and high reliability. Alternatively, for example, if a certain percentage of the first batch of PDUs is not successfully received (e.g., below a percentage threshold), the WTRU can decrease the priority of the second batch of PDUs (e.g., by forwarding the PDUs to a lower-priority LCH) or discard the second batch. For example, since the second batch of PDUs may be less useful if the first batch is not successfully received, priority can be reduced to minimize resource usage.

[0213] In the example, when triggered by one or more events associated with the in-order delivery of PDUs in a PDU set, the WTRU may determine to relax one or more LCP restrictions to use resources (e.g., configured licensed resources) and / or configurations associated with other high-priority LCHs. For example, when performing an LCP, the WTRU may prioritize (e.g., selectively prioritize) LCHs that include PDUs to be retransmitted in the PDU set, such that the PDUs can be multiplexed and / or retransmitted before PDUs in other LCHs with higher priority. Events associated with in-order delivery may include the detection of residual delay events (e.g., residual delay is below / above one or more thresholds), the detection of PDU priority events (e.g., the priority of the PDUs to be retransmitted is above / below a threshold), the detection of PDU payload events (e.g., the total payload of the PDUs or the number of PDUs to be retransmitted is above / below a threshold), and / or the status of transmission events (e.g., the percentage of successfully received or remaining PDU sets to be transmitted is above / below a threshold).

[0214] In the example, the WTRU can determine whether / how to update the priority of PDUs to be retransmitted during retransmission based on information associated with SN gaps. This information may include the number of SN gaps, the size / length of the SN gaps (e.g., the difference between the first and last SNs of the SN gap, or the range of the SN gaps), and the stage of the SN gaps (e.g., whether the SN gap was detected at the first stage of a PDU set including one or more PDUs or at the Nth stage of the PDU set, where N may refer to the difference between the first / last SN and the Nth SN in which the SN gap was detected). For example, the WTRU may retransmit the missing PDU associated with the largest SN gap with the highest priority, followed by the PDU associated with the next largest SN gap.

[0215] In the example, when transmitting PDUs from the PDU set, the WTRU can fall back to using the default / initial configuration based on one or more conditions, including the default priority value, the default mapping configuration at SDAP / PDCP, and / or the default LCP parameters at MAC. These conditions may include, for example, the reception of a status indication (e.g., successful reception of a PDU indicating transmission / retransmission), the percentage of remaining PDUs determined to be retransmitted being below a threshold, and the expiration of timers associated with delay budgets and / or retransmissions (e.g., discard timers, reordering timers).

[0216] Figure 3 An example of a process 300 for updating the priority of missing PDUs based on delivery status indication and / or remaining delay is described. For example... Figure 3 As shown, the WTRU (e.g., Tx PDCP entity 312) can assign SNs when transmitting PDUs (e.g., PDU 302, PDU 304, PDU 306) in PDU set 308 and forward the PDUs to LCH 320 (low priority) for UL transmission. The WTRU can update the priority of a PDU (e.g., PDU 304) in the missing PDU set at the network (e.g., receiving PDCP entity 326), for example, based on delivery status indication 322 (e.g., NACK indicating a missing SN) and / or the remaining delay associated with the PDU set. When transmitting PDU 304, the WTRU can forward PDU 304 via LCH 318 (high priority).

[0217] In an example related to the in-order delivery of PDUs in a PDU set within a UL, the WTRU may perform one or more actions. For example, the actions may include the WTRU receiving configuration information. This configuration information may include one or more thresholds associated with PDUs to be retransmitted (ReTx) and / or remaining delay. The actions may include the WTRU receiving one or more PDUs from an upper layer within the PDU set. The actions may include the WTRU assigning one or more SNs to the PDUs and / or delivering the PDUs to a first LCH associated with the initial priority of the PDU set for transmission. The actions may include the WTRU receiving a status indication from the NW (e.g., in a MAC CE) indicating that a PDU in the PDU set has not been successfully received. The actions may include the WTRU determining information about missing PDUs in the PDU set to be retransmitted (e.g., PDU priority) and / or remaining delay associated with the PDU set delay budget (PSDB) based on the status indication. If the number of missing PDUs is greater than a first threshold (e.g., threshold 1) and / or the remaining delay is less than a second threshold (e.g., threshold 2), the WTRU may update the priority of the missing PDUs to be retransmitted, select a second LCH associated with the updated priority, and / or deliver the missing PDUs to the second LCH for retransmission. If the number of missing PDUs is less than a first threshold (e.g., threshold 1) and / or the remaining delay is greater than a second threshold (e.g., threshold 2), the WTRU may deliver the missing PDUs to the first LCH for retransmission.

[0218] WTRU can determine whether and / or how to transmit a later-arriving PDU set based on the transmission status of an earlier / ongoing PDU set.

[0219] In the example, the WTRU can determine whether and / or how to perform the transmission of a second PDU set on top of an ongoing first PDU set in transit (e.g., partial or ongoing transit) based on the transmission status of the current PDU set and / or the attributes of the PDU set (e.g., PDU set importance, size, type). When the WTRU is transmitting multiple PDU sets in the UL, the WTRU can determine whether and / or how to perform the transmission of a second PDU set on top of an ongoing first PDU set in transit, where one or more PDUs from different PDU sets may arrive at the WTRU periodically or continuously from, for example, a higher layer / application. For example, the second PDU set may arrive at the WTRU later than the first PDU set. In the example, the second PDU set may depend on or be associated with the first PDU set, where such association can be determined based on application layer indications or transmission status at a lower layer. In the example, the first and second PDU sets may be associated with the same QoS flow (e.g., the two PDU sets have the same QoS requirements but may differ in importance) or different QoS flows.

[0220] In the example, the WTRU can receive configuration information from the network. The configuration information may include one or more thresholds associated with the percentage of the set of PDUs to be retransmitted (e.g., the percentage of missing PDUs delivered in order) or the number of PDUs to be retransmitted.

[0221] The WTRU can receive one or more PDUs from a first PDU set from a higher layer / application. The WTRU can assign SNs (e.g., COUNT, HFN, SN) to the PDUs at a transport entity (e.g., SDAP or PDCP), and / or can deliver PDUs from the first PDU set to a lower layer associated with a first DRB (e.g., first PDCP entity, first RLC / LCH). For example, the WTRU can determine the initial importance of the PDU set based on markers in the headers of the PDUs associated with the PDU set. The WTRU can forward the PDUs from the first PDU set to the first DRB based on configured mapping rules (e.g., at SDAP), which may instruct, for example, that the PDUs in the PDU set be mapped to the DRB based on the importance of the PDU set. Upon mapping the PDUs in the PDU set to the first / initial DRB / LCH, the PDUs can then be further processed and transmitted in the UL. The WTRU can also receive one or more PDUs from a second PDU set from a higher layer and / or application.

[0222] The WTRU may start one or more timers when forwarding PDUs from the first and / or second PDU sets to a lower layer and / or when transmitting PDUs in the UL (e.g., timers may be started when the first / last PDU in the PDU set is forwarded and / or transmitted). For example, timers may be used to determine the remaining delay for satisfying the delay budget / PSDB associated with the first and / or second PDU sets when transmitting the remaining PDUs in the PDU sets, to determine the time difference or lag between the transmission of PDUs in the first and second PDU sets (e.g., the difference between the last PDU in the first PDU set and the first PDU in the second PDU set), and / or to determine the time elapsed before receiving a status indication related to the status of the first and / or second PDU sets from the network.

[0223] The WTRU can receive status indications and / or feedback regarding the reception of PDUs in a first PDU set at the network. These status indications can be received on a per-data-unit basis (e.g., per PDU, per PDU set, per data burst) or per-data-unit group basis, via any of the following: HARQ feedback, RLC feedback (RLC ACK / NACK), PDCP status report / feedback, and SDAP feedback. For example, the status indication can indicate the serial numbers (SNs) of PDUs in the PDU set that may have been received (ACK) and / or not received (NACK), and the percentage of PDUs in the PDU set that were successfully received or not successfully received.

[0224] When receiving PDUs from a second PDU set (e.g., from a higher layer), the WTRU may update the priority of the PDUs in the first PDU set to be transmitted if certain conditions are met, including that the importance value (e.g., priority) of the second PDU set is greater than that of the first PDU set, the percentage of missing PDUs in the first PDU set is less than or equal to a threshold, and / or the remaining delay associated with the first PDU set is less than a delay threshold. Alternatively, when such conditions are detected, the WTRU may update the importance / priority of the PDUs in the second PDU set by, for example, decreasing the importance / priority of the second PDU set. In this case, the WTRU may increase the priority of the PDUs in the first PDU set to be retransmitted, and / or forward the PDUs to an LCH pre-configured with updated priorities for UL transmission, such that the PDUs in the first PDU set can be transmitted before the PDUs in the second PDU set.

[0225] Additionally or alternatively, if some of the conditions are not met (e.g., the percentage of missing PDUs in the first PDU set is greater than a threshold, and / or the remaining delay associated with the first PDU set is higher than a delay threshold), the WTRU may transmit an indication to the network to suspend the reordering of the first PDU set until at least some of the PDUs in the second PDU set are received. For example, the indication may be designed to prevent any recovery indication from the network to be triggered for retransmission of missing PDUs in the first PDU set, or to prevent the first PDU set from being discarded. The indication may be sent explicitly (e.g., in RLC / ARQ feedback, MAC CE, PDCP control indication, SDAP control indication) or implicitly (e.g., by preemptively transmitting PDUs in the second PDU set, even though the receiving entity may expect PDUs in the first PDU set). The WTRU may forward the PDUs in the second PDU set to the DRB / LCH corresponding to the importance / priority of the updated PDU set, and / or transmit the PDUs in the UL. For example, the WTRU may then transmit PDUs from the first PDU set to be retransmitted based on the PDU priority.

[0226] If the importance value of the second PDU set is less than or equal to the importance value of the first PDU set, the WTRU can transmit the PDUs in the first PDU set to be retransmitted via an initial DRB / LCH associated with the importance / priority of the PDU set. Then, the WTRU can transmit the PDUs in the second PDU set via a DRB / LCH associated with, for example, the importance / priority of the second PDU set.

[0227] In the example, when a specific condition is detected, the WTRU can determine to discard / abandon missing PDUs in the first PDU set by not retransmitting PDUs. The specific condition may include one or more of the following: the importance of the first PDU set is less than the importance of the second PDU set; the first and second PDU sets are associated with the same QoS flow; the remaining latency associated with the first PDU set is below a threshold; and / or the number of PDUs in the first PDU set to be retransmitted is above a threshold. When abandoning / discarding the PDU set, the WTRU may send an explicit indication to the network (e.g., via MAC CE, PDCP control PDU, SDAP control PDU) or an implicit indication (e.g., by not retransmitting PDUs in the first PDU set) to indicate any of the following: discarding the PDU set (PDU set ID / SN), terminating PDU set transmission, and releasing the reordering of the first PDU set.

[0228] In the example, the WTRU can determine, based on one or more conditions, to prioritize the transmission of a more recent version of a PDU set (e.g., a second PDU set) over an older version of a PDU set (e.g., a first PDU set) that may be in transit (e.g., partially delivered). These conditions may include the number of PDUs to be retransmitted being higher / lower than a threshold set, the percentage of PDU groups to be transmitted being higher / lower than a threshold set, and / or the remaining latency of the older version PDU set being higher / lower than a threshold set. For example, the WTRU can determine the version of a PDU set based on higher-layer / application indications (e.g., version ID / index, timestamp associated with the PDU set). In one example, if the number of missing PDUs in an older version PDU set in transit (e.g., the first PDU set) is lower than a threshold, the WTRU can send an instruction to the network to terminate the reordering of the first PDU set and discard any PDUs associated with the first PDU set. The WTRU can then transmit PDUs from the more recent version of the PDU set (e.g., the second PDU set). Alternatively, if the number of missing PDUs in the older version PDU set being transmitted is below a threshold, the WTRU may transmit the missing PDUs before transmitting the PDUs in the newer version PDU set.

[0229] In an example related to the sequential delivery of multiple consecutive PDU sets in the UL, the WTRU may perform one or more actions. For example, the actions may include the WTRU receiving configuration information. The configuration information may include a threshold associated with the maximum percentage of missing PDUs. The actions may include the WTRU receiving one or more PDUs from an upper layer. The actions may include the WTRU transmitting PDUs from a first PDU set to the NW via a first DRB / LCH associated with an initial importance value of the PDU set. The actions may include the WTRU receiving a status indication of the first PDU set from the NW (e.g., in a PDCP status report), the status indication indicating a SN that was not successfully received (e.g., a missing PDU). The actions may include the WTRU receiving one or more PDUs from a second PDU set from one or more upper layers. If the initial importance of the second PDU set is greater than the initial importance of the first PDU set, and if the percentage of missing PDUs in the first PDU set is less than or equal to a threshold, the WTRU may perform one or more of the following: update the importance value of the first PDU set (e.g., increase the priority of missing PDUs) and / or transmit the missing PDUs in the first PDU set via a second DRB / LCH associated with the updated importance. If the initial importance of the second PDU set is greater than the initial importance of the first PDU set, and if the percentage of missing PDUs in the first PDU set is greater than a threshold, the WTRU may perform one or more of the following: transmit an instruction to suspend the reordering of the first PDU set until after receiving PDUs from the second PDU set, and / or transmit the PDUs in the second PDU set via a third DRB / LCH associated with the importance of the second PDU set. If the initial importance of the second PDU set is less than the initial importance of the first PDU set, the WTRU may transmit the missing PDUs of the first PDU set via a first DRB / LCH associated with the initial importance / priority of the PDU set.

[0230] WTRU can determine whether and / or how to retransmit PDUs from multiple PDU sets based on the transmission status and PDU set attributes.

[0231] In the example, the WTRU can determine whether and / or how to perform retransmission of PDUs from the first and second PDU sets based on the transmission status of the PDU set (e.g., the number of missing PDUs) and / or the attributes of the PDU set (e.g., the importance, size, and type of the PDU set). For example, the WTRU can perform retransmission by updating the importance / priority associated with the PDU set and / or pausing the reordering of the corresponding PDUs at the receiving entity in the network.

[0232] For example, a WTRU can transmit multiple PDU sets in parallel within the UL via different DRBs / LCHs. In the example, the first and second PDU sets can be dependent on or associated with each other, where such association can be determined based on application layer indications or the state of transmission at lower layers. In the example, the first and second PDU sets can be associated with the same QoS flow (e.g., the two PDU sets have the same QoS requirements but can differ in importance) or different QoS flows.

[0233] In the example, the WTRU can receive configuration information from the network, including at least one or more thresholds associated with the percentage of the set of PDUs to be retransmitted (e.g., the percentage of missing PDUs delivered in order) or the number of PDUs to be retransmitted in one or more PDU sets.

[0234] The WTRU can receive one or more PDUs from a first PDU set and a second PDU set from a higher layer and / or application, where the first and second PDU sets may be associated with different importance and / or priority values. The WTRU can assign SNs (e.g., COUNT, HFN, SN) to PDUs and / or PDU sets at a transport entity (e.g., SDAP or PDCP), and / or deliver PDUs from the first PDU set to a lower layer associated with a first DRB (e.g., a first PDCP entity, a first RLC / LCH), and deliver PDUs from the second PDU set to a lower layer associated with a second DRB (e.g., a second PDCP entity, a second RLC / LCH). For example, the WTRU can determine the initial importance of the first and second PDU sets based on markers in the headers of the PDUs associated with the PDU sets. The WTRU can forward PDUs from the first and second PDU sets to the first and second DRBs, respectively, based on configured mapping rules (e.g., at SDAP), which may instruct, for example, that PDUs in the PDU sets are mapped to DRBs based on the importance of the PDU sets. When the PDUs in the PDU set are mapped to the first / initial DRB / LCH, the PDUs can then be further processed and transmitted in the UL.

[0235] The WTRU may start one or more timers when forwarding PDUs from the first and / or second PDU sets to a lower layer and / or when transmitting PDUs in the UL (e.g., timers may be started when the first / last PDU in the PDU set is forwarded and / or transmitted). For example, the timers may be used to determine the remaining delay required to satisfy the delay budget and / or PSDB associated with the first and / or second PDU sets when transmitting the remaining PDUs in the PDU sets, to determine the time difference or lag between the transmission of PDUs in the first and second PDU sets (e.g., the difference between the last PDU in the first PDU set and the first PDU in the second PDU set), and / or to determine the time elapsed before receiving a status indication related to the status of the first and / or second PDU sets from the network.

[0236] The WTRU can receive status indications and / or feedback regarding the reception of PDUs in the first and second PDU sets at the network. The status indications can be received from the receiving entity at the network or from a lower layer at the WTRU on a per-data-unit (e.g., per PDU, per PDU set, per data burst) or per-data-unit group basis, via any of the following: HARQ feedback, RLC feedback (RLC ACK / NACK), PDCP status report / feedback, and SDAP feedback. For example, the status indication can indicate the serial numbers (SNs) of PDUs in the first and second PDU sets that may have been received (ACK) and / or not received (NACK), and the percentage of PDUs in the PDU sets that were successfully received or not successfully received.

[0237] If any condition associated with the delivery status of the first PDU set with respect to the second PDU set is met, the WTRU may determine and / or select one or more PDU sets to temporarily prioritize during UL transmission. For example, the condition may include the percentage of missing PDUs in the first and second PDU sets (e.g., a PDU set may be selected if the percentage of missing PDUs is greater than / less than one or more thresholds). For another example, the condition may include the difference between the number of PDUs to be retransmitted in the first and second PDU sets (e.g., the first PDU set may be selected if the number of PDUs to be retransmitted in the first PDU set is greater than that in the second PDU set). For yet another example, the condition may include the remaining delay associated with the corresponding PSDB of the first and second PDU sets (e.g., a PDU set may be selected if the remaining delay for transmitting any remaining PDUs in the PDU set is greater than / less than one or more thresholds). For yet another example, the condition may include the difference between the remaining delays associated with the first and second PDU sets (e.g., the first PDU set may be selected if the remaining delay of the first PDU set is less than that of the second PDU set).

[0238] If one or more of the conditions described herein (e.g., any condition) are met, the WTRU may update the importance of the selected PDU set (e.g., the first or second PDU set). For example, the importance of the selected PDU set may be updated by updating the priority of its associated PDUs to be retransmitted (e.g., increasing the priority of PDUs to be retransmitted in the selected PDU set and / or decreasing or maintaining the priority of PDUs to be retransmitted in the unselected PDU set).

[0239] When updating the importance of the first / second PDU set, the WTRU may transmit an indication to the network suspending the reordering of the unselected PDU set (e.g., the ID / index of the PDU set) until one or more (e.g., all) PDUs or at least some of the PDUs in the selected PDU set are received. For example, the indication may be designed to prevent any recovery indication from the network to retransmit missing PDUs from the first PDU set, or to prevent the dropping of the second PDU set. The indication may be sent explicitly (e.g., in RLC / ARQ feedback, MAC CE, PDCP control indication, SDAP control indication) or implicitly (e.g., by preemptively transmitting PDUs from the first PDU set, although the receiving entity may anticipate PDUs from the second PDU set). The WTRU may forward the PDUs from the selected PDU set to the updated importance / priority DRB / LCH corresponding to the PDU set, and / or transmit the PDUs in the UL. For example, the WTRU may then transmit the PDUs from the unselected PDU set while transmitting the PDUs from the selected PDU set to be retransmitted.

[0240] In an example related to the parallel, sequential delivery of multiple PDU sets in the UL, the WTRU may perform one or more actions. For example, the actions may include the WTRU receiving configuration information. This configuration information may include a threshold associated with the maximum percentage of missing PDUs (e.g., the number of missing SNs). The actions may include the WTRU receiving one or more PDUs from a first PDU set and a second PDU set from an upper layer, which have different importance values. The actions may include the WTRU transmitting PDUs from the first PDU set to the NW via a first LCH and transmitting PDUs from the second PDU set to the NW using a second LCH. The actions may include the WTRU receiving a status indication (e.g., a PDCP status report) from the NW, indicating SNs within the first and second PDU sets that were not successfully received (e.g., missing PDUs in both sets). The actions may include the WTRU selecting a set of PDUs to be prioritized (e.g., temporarily prioritized) based on one or more percentage values ​​of missing PDUs in a first PDU set and a second PDU set, the difference in the number of PDUs to be retransmitted in the first PDU set and the second PDU set, the remaining latency associated with the corresponding PSDBs of the first PDU set and the second PDU set, and / or the difference in the remaining latency associated with the first PDU set and the second PDU set. The actions may include the WTRU updating the importance values ​​of the selected PDU set and / or the unselected PDUs (e.g., by increasing the priority of missing PDUs in the selected PDU set and / or decreasing the priority of missing PDUs in the unselected PDU set). The actions may include a WTRU transmission indication to suspend the reordering of the unselected PDU set until PDUs in the selected PDU set are received (e.g., the indication may include the ID / index of the selected PDU set). The actions may include the WTRU transmitting the missing PDUs in the selected PDU set via the DRB / LCH associated with the updated importance.

[0241] WTRU can determine whether and / or how to trigger the recovery of lost and / or missing PDUs in the PDU set based on PDU set attributes.

[0242] In the example, the WTRU can determine whether / how to trigger the recovery of lost / missing PDUs in the PDU set for in-order delivery based on attributes associated with the PDU set. These attributes may include the priority of PDUs that may be lost / missing at the WTRU and the Effective PDU Set Error Rate (PSER) determined by the WTRU. For example, when a data unit (e.g., PDU, PDU set, data burst) is received in the DL, one or more of the actions described herein may be performed at the receiving entity at the WTRU, including at SDAP, PDCP, new sublayer, and / or MAC. One or more of the actions described herein may be applied when a data unit is lost during transmission or retransmission, and / or is not successfully received at the receiving entity (no PDUs in the PDU set received within the PSDB and / or PSER). For example, one or more of the actions described herein may apply when receiving one or more (e.g., all) PDUs or a specific percentage (e.g., above a percentage threshold) of the PDU set or PDU set at the receiving entity at the WTRU (e.g., RLC, PDCP, SDAP) is considered a successful reception for in-order delivery.

[0243] In the example, the WTRU can receive configuration information from the network, including at least one or more thresholds associated with the PSER (e.g., the percentage of PDUs received in a PDU set with priority values ​​above the threshold) and the duration of a reordering timer associated with the reordering of PDUs in the PDU set.

[0244] The WTRU can receive a first PDU group from the network, comprising one or more PDUs from a PDU set. The WTRU can reorder the PDUs, possibly in ascending order, at any receiving entity (e.g., PDCP, SDAP), based on the SN (e.g., COUNT, HFN, SN) assigned by the transport entity at the network. When receiving PDUs from the PDU set from the network and / or from a lower layer (e.g., RLC / LCH), the WTRU can start one or more timers. For example, a timer can be started when the first PDU in the first PDU group is received, or when PDU reordering begins. Timers can be stopped and / or reset, for example, when the last PDU in the first PDU group is received, or when reordering is complete. The WTRU can also determine, based on the PDU reordering, whether any PDUs in the first group are missing for in-order delivery (e.g., SN gaps). While reordering the PDUs in the first group, the WTRU can receive a second PDU group, comprising one or more PDUs from the PDU set.

[0245] If any SN gap is detected in the first PDU group, the WTRU can initiate a PDU set reordering timer. The WTRU can determine the effective PSER based on the number of PDUs received in the first and second PDU groups with a specific priority (e.g., above a priority threshold). If the determined effective PSER is less than or equal to the configured PSER threshold, the WTRU can deliver the PDUs in the PDU set to the upper layer / application while reordering the PDUs in ascending order. For example, when delivering the reordered PDUs to the upper layer, the WTRU can stop and / or reset the timer. If the determined effective PSER is greater than the configured PSER threshold and / or if the PDU reordering timer expires, the WTRU can transmit a recovery indication to the network, indicating the SN of the missing, unreceived PDUs in the first or second PDU group. For example, this indication can be transmitted in RLC / ARQ feedback, MAC CE, PDCP control indication, or SDAP control indication.

[0246] In the example, the WTRU can be configured with different effective PSER thresholds associated with different PDU set attributes (e.g., PDU set type, PDU set importance / priority, PDU set size) and / or the mapping between the PSER threshold and the PDU set attributes. When reordering received PDUs in the PDU sets of the first and / or second PDU groups is performed, the WTRU can select the PSER threshold based on the PDU set attributes to determine whether to deliver the ordered PDUs to the upper layer or trigger a recovery indication.

[0247] In the example, where the WTRU can perform reordering across multiple PDU sets, the WTRU can delay delivering the second PDU set to the upper layer while waiting for the first PDU set, which may be in transit (e.g., only receiving a portion of the first PDU set). This solution can be applicable when, based on the SN assigned to the PDU sets, the first PDU set is expected to be delivered to the upper layer before the second PDU set. The decision to delay the delivery of the second PDU set can be made based on the delay caused or expected to be caused by receiving any remaining PDUs in the first PDU set and / or the relative importance / priority of the PDU sets relative to each other.

[0248] Figure 4 An example process 400 is described, which triggers the recovery of lost and / or missing PDUs in a PDU set based on one or more PDU set attributes. For example... Figure 4As shown, low-importance PDUs (e.g., PDUs 402 and 404) in PDU set 410 can be transmitted in low-priority LCH 424. High-importance PDUs (e.g., PDUs 406 and 408) in PDU set 412 can be transmitted in high-priority LCH 422. A WTRU (e.g., Rx PDCP entity 430) can delay the delivery of high-importance PDU set 412 to the upper layer based on the delay caused by receiving PDU set 410 and the relative importance of PDU set 410 with respect to PDU set 412, while waiting for low-importance PDUs (e.g., PDUs 402 and 404) in PDU set 410 to be transmitted. For example, if PDU set 410 is received within a delay threshold, Rx PDCP entity 430 can delay the delivery of PDU set 412 to the upper layer, such that PDU set 410 is delivered before PDU set 412.

[0249] In the example, the WTRU can perform one or more actions related to the in-order reception of PDUs in the PDU set in the DL and the triggering of recovery of missing PDUs. These actions may include WTRU reception configuration information. The configuration information may include a PSER threshold (e.g., the percentage of high-priority PDUs in the PDU set) and a reordering timer duration. The actions may include the WTRU receiving a first group of one or more PDUs from the NW. If any SN gap is detected in the first group, the WTRU may start a reordering timer to receive a second group of one or more PDUs from the NW, and / or determine the valid PSER based on the number of high-priority PDUs received in the first and second groups. If any SN gap is detected in the first group, and if the valid PSER is less than or equal to the threshold, the WTRU may deliver the PDU set to the upper layer after reordering the PDUs in ascending order. If any SN gap is detected in the first group, and if the valid PSER is greater than the threshold or the reordering timer expires, the WTRU may transmit a recovery indication to the NW, indicating the SN of the missing PDU in the PDU set.

[0250] WTRU can determine whether and / or how to pause and / or resume the reordering of PDUs in different PDU sets based on the detection of SN gaps.

[0251] In the example, the WTRU can determine whether and / or how to suspend and / or resume the reordering of PDUs associated with one or more PDU sets, which may be received in different PDU sets / bursts, based on the detection of SN gaps in different PDU groups. For example, when a data unit (e.g., PDU, PDU set, data burst) is received in the DL, one or more of the actions described herein can be performed at the receiving entity at the WTRU, including at SDAP, PDCP, new sublayer, and / or MAC. One or more of the actions described herein may apply when a data unit is lost during transmission or retransmission, or is not successfully received at the receiving entity (e.g., no PDU in the PDU set is received in the PSDB and / or PSER). One or more of the actions described herein may apply when a PDU set is implicitly distinguished based on SN gaps introduced by the transport entity during DL transmission (e.g., the PDU set ID is not explicitly indicated by the transport PDCP entity at the network).

[0252] In the example, the WTRU can receive configuration information from the network, including at least one or more thresholds associated with the reordering timer duration, which is related to the reordering of PDUs in one or more PDU sets. The WTRU can also receive one or more new PDU set SN gap values ​​in the configuration information, which correspond to the difference in SN values ​​between two consecutive PDU sets (e.g., the SN difference between the last PDU in the first PDU set and the first PDU in the second PDU set). The WTRU can receive a first PDU group from the network, comprising one or more PDUs from the PDU set. The WTRU may perform PDU reordering at any receiving entity (e.g., PDCP, SDAP) based on the SN (e.g., COUNT, HFN, SN) assigned by the transport entity at the network. Upon receiving PDUs from the PDU set from the network and / or from a lower layer (e.g., RLC / LCH), the WTRU may start one or more timers. For example, a timer may be started when the first PDU in the first PDU group is received, or when PDU reordering begins. Timers may be stopped and / or reset, for example, when the last PDU in the first PDU group is received, or when reordering is complete. While performing PDU reordering in the first PDU group, the WTRU can receive a second PDU group, comprising one or more PDUs from the PDU set. The WTRU may determine, based on the PDU reordering, whether there are any missing PDUs in the first and second PDU groups for in-order delivery (e.g., SN gaps).

[0253] If any SN gap corresponding to the configured new PDU set SN gap value is detected between any PDU in the first PDU group and any PDU in the second PDU group (e.g., between the last PDU in the first PDU group and the first PDU in the second PDU group), the WTRU may suspend the reordering of PDUs in the first PDU group and / or may buffer PDUs in the first PDU group. For example, PDUs in the first and second PDU groups may belong to different PDU sets, and thus, for example, the WTRU may not find any PDUs missing from the first PDU group in the second PDU group. After suspending reordering, the WTRU may start a reordering timer during which the WTRU may anticipate the reception of the third PDU group. If a third PDU group of one or more PDUs is received from the network, and if no missing PDUs from the first PDU group are detected in the third PDU group within the reordering timer, the WTRU may reorder the PDUs in the second and third PDU groups in ascending order and may deliver the PDUs to the upper layer when an end marker (e.g., the last SN of the PDU set or flag) is identified in the ordered PDUs. If a third PDU group is received from the network, and if any missing PDU from the first PDU group is detected in the third PDU group within the reordering timer, the WTRU can restore the PDU ordering in ascending order based on the PDUs received in the first and third PDU groups. The WTRU may deliver the PDU to the upper layer if an end marker is identified within the ordered PDUs.

[0254] During any of the steps associated with in-order delivery, the WTRU may provide network transmission status indication and / or feedback, indicating actions associated with in-order delivery and / or information about received / missing PDUs (e.g., SN gaps, ACK / NACK status of SNs), including the reception of PDUs in one or more PDU groups, detection of any SN gaps in a PDU group, pause / resumption of PDU reordering, and delivery of PDUs or upper layers.

[0255] In the example, the WTRU can perform one or more actions related to the sequential reception of multiple PDU sets in the DL. These actions may include WTRU reception configuration information. The configuration information may include the PDU set reordering duration. The actions may include the WTRU receiving a first group of one or more PDUs from the NW. The actions may include the WTRU determining the order of the PDUs based on the serial numbers (SNs) of the PDUs in the first group. The actions may include the WTRU receiving a second group of one or more PDUs from the NW. If an SN gap is detected between the last PDU in the first group and the first PDU in the second group, the WTRU may suspend the reordering of the PDUs in the first group and buffer the PDUs, start a reordering timer, receive a third group of one or more PDUs from the NW, and / or transmit a status indication (e.g., ACK / NACK) to the NW regarding the PDU set reordering status. If a gap in the serial number (SN) is detected between the last PDU in the first group and the first PDU in the second group, and if the expected SN is not detected in the third group within the reordering timer duration (e.g., a missing SN), the WTRU may perform one or more of the following: reorder the PDUs in the second and third groups in ascending order based on the PDU SN, or deliver the ordered PDUs to the upper layer when an end marker is identified. If a gap in the serial number (SN) is detected between the last PDU in the first group and the first PDU in the second group, and if the expected SN is detected in the third group within the reordering timer duration, the WTRU may restore the order of the PDUs in the first and third groups, and deliver the PDUs to the upper layer when an end marker is identified.

[0256] The WTRU may include one or more processors. The WTRU may be configured to receive configuration information during the sequential delivery of PDUs and / or sets of PDUs. For example, the WTRU may be configured to receive configuration information indicating one or more thresholds associated with one or more retransmissions of multiple Protocol Data Units (PDUs) in a PDU set. The one or more thresholds may include at least one of a first threshold corresponding to the number of PDUs to be transmitted or a second threshold corresponding to the remaining delay budget. The WTRU may be configured to transmit multiple PDUs in a PDU set. The transmission of multiple PDUs in the PDU set may be associated with a first logical channel, which is associated with a first priority. The WTRU may be configured to receive an indication that one or more of the multiple PDUs in the PDU set are to be retransmitted. The WTRU may be configured to determine a second logical channel to be used for retransmitting one or more of the multiple PDUs in the PDU set based on the number of one or more of the multiple PDUs in the PDU set to be retransmitted being greater than a first threshold or the remaining delay budget for one or more of the multiple PDUs in the PDU set to be retransmitted being less than at least one of a second threshold. The WTRU may be configured to retransmit one or more of the multiple PDUs in the PDU set. Retransmissions of one or more of the multiple PDUs in the PDU set can be associated with a second logical channel.

[0257] The WTRU can be configured to determine information about one or more PDUs in a set of PDUs to be retransmitted. This information may include one or more of the following: the number of one or more PDUs in the set of PDUs to be retransmitted, or the remaining delay budget.

[0258] The WTRU can be configured to determine a second priority for one or more PDUs in a set of PDUs to be retransmitted. A second logical channel can be associated with the second priority. The indication may include one or more of the following: an indication of one or more sequence numbers assigned to one or more PDUs in the set of PDUs to be retransmitted, or an indication of the second priority.

[0259] A second logical channel to be used for retransmitting one or more of the multiple PDUs in the PDU set can be determined based on the fact that the number of one or more of the multiple PDUs in the PDU set to be retransmitted is greater than a first threshold and the remaining delay budget of one or more of the multiple PDUs in the PDU set to be retransmitted is less than at least one of a second threshold.

[0260] WTRU can be configured to update the first priority of one or more PDUs in a set of PDUs to be retransmitted based on the attributes of the PDU set. The attributes of the PDU set may include one or more of the following: the type of the PDU set, the importance of the PDU set, the payload size, the percentage of the PDU set to be retransmitted, and / or the number of PDUs in the PDU set.

[0261] WTRU can be configured to retransmit one or more PDUs in a PDU set using a first logical channel associated with a first priority, provided that the number of one or more PDUs in the PDU set to be retransmitted is less than a first threshold and the remaining delay budget of one or more PDUs in the PDU set to be retransmitted is greater than a second threshold.

[0262] A WTRU can be configured to transmit multiple PDUs from a PDU set in one or more batches. A WTRU can also be configured to determine the priority of a second batch of PDUs from the same PDU set based on the transmission status of the first batch.

[0263] The WTRU can also be configured to update the priority of one or more PDUs in a set of PDUs to be retransmitted during a retransmission, based on information associated with the sequence number (SN) gap. The information associated with the SN gap may include one or more of the following: the number of SN gaps, the size of the SN gaps, the length of the SN gaps, and / or the phases of the SN gaps.

[0264] WTRU can be configured to determine which PDUs in a PDU set to transmit using a default configuration. The default configuration may include one or more of a default priority value, a default mapping configuration, and / or a default logical control priority (LCP) parameter.

Claims

1. A wireless transmit / receive unit (WTRU) including a processor, said processor being configured to: Receive configuration information indicating one or more thresholds associated with one or more retransmissions of a plurality of Protocol Data Units (PDUs) in a PDU set, the one or more thresholds including at least one of a first threshold corresponding to the number of PDUs to be transmitted or a second threshold corresponding to the remaining delay budget; The transmission of the plurality of PDUs in the PDU set is associated with a first logical channel of a first priority; Receive an indication to retransmit one or more of the plurality of PDUs in the PDU set; A second logical channel is determined to be used for retransmitting one or more of the PDUs in the PDU set based on the fact that the number of one or more of the PDUs in the PDU set to be retransmitted is greater than a first threshold or the remaining delay budget for one or more of the PDUs in the PDU set to be retransmitted is less than at least one of a second threshold. and Retransmit one or more of the plurality of PDUs in the PDU set using the second logical channel.

2. The WTRU of claim 1, wherein the WTRU is configured to determine information about one or more of the plurality of PDUs in the set of PDUs to be retransmitted, wherein the information includes the number of one or more of the plurality of PDUs in the set of PDUs to be retransmitted or one or more of the remaining delay budget.

3. The WTRU of claim 1, wherein the WTRU is configured to determine a second priority of one or more of the plurality of PDUs in the set of PDUs to be retransmitted, and wherein the second logical channel is associated with the second priority.

4. The WTRU of claim 3, wherein the indication includes one or more of an indication of one or more sequence numbers of one or more of the plurality of PDUs in the set of PDUs to be retransmitted, or an indication of a second priority.

5. The WTRU of claim 1, wherein a second logical channel to be used for retransmitting the one or more of the plurality of PDUs in the PDU set is determined based on the fact that the number of one or more of the plurality of PDUs in the PDU set to be retransmitted is greater than a first threshold and the remaining delay budget of one or more of the plurality of PDUs in the PDU set to be retransmitted is less than at least one of a second threshold.

6. The WTRU of claim 1, wherein the WTRU is configured to update the first priority of one or more of the plurality of PDUs in the PDU set to be retransmitted based on attributes of the PDU set, wherein the attributes of the PDU set include one or more of the following: type of PDU set, importance of PDU set, payload size, percentage of the PDU set to be retransmitted, or number of PDUs in the PDU set.

7. The WTRU of claim 1, wherein the WTRU is configured to retransmit one or more of the plurality of PDUs in the PDU set to be retransmitted using a first logical channel associated with a first priority, provided that the number of one or more of the plurality of PDUs in the PDU set to be retransmitted is less than a first threshold and the remaining delay budget of one or more of the plurality of PDUs in the PDU set to be retransmitted is greater than a second threshold.

8. The WTRU of claim 1, wherein the WTRU is further configured as follows: Transmit the plurality of PDUs in a PDU set in one or more batches; and Based on the transmission status of the first batch of PDUs in the PDU set, the priority to be assigned to the second batch of PDUs in the PDU set is determined.

9. The WTRU of claim 1, wherein the WTRU is further configured as follows: Based on information associated with the sequence number (SN) gap, the priority of one or more of the plurality of PDUs in the PDU set to be retransmitted during the retransmission is updated, wherein the information associated with the SN gap includes one or more of the number of SN gaps, the size of the SN gap, the length of the SN gap, or the phase of the SN gap.

10. The WTRU of claim 1, wherein the WTRU is further configured to determine to use a default configuration to transmit the plurality of PDUs in the PDU set, wherein the default configuration includes one or more of a default priority value, a default mapping configuration, or a default logical control priority (LCP) parameter.

11. A method comprising: Receive configuration information indicating one or more thresholds associated with one or more retransmissions of a plurality of Protocol Data Units (PDUs) in a PDU set, the one or more thresholds including at least one of a first threshold corresponding to the number of PDUs to be transmitted or a second threshold corresponding to the remaining delay budget; The transmission of the plurality of PDUs in the PDU set is associated with a first logical channel of a first priority; Receive an indication to retransmit one or more of the plurality of PDUs in the PDU set; A second logical channel is determined to be used for retransmitting one or more of the PDUs in the PDU set based on the fact that the number of one or more of the PDUs in the PDU set to be retransmitted is greater than a first threshold or the remaining delay budget for one or more of the PDUs in the PDU set to be retransmitted is less than at least one of a second threshold. and Retransmit one or more of the plurality of PDUs in the PDU set using the second logical channel.

12. The method of claim 11, further comprising: Determine information about one or more of the plurality of PDUs in the set of PDUs to be retransmitted, wherein the information includes the quantity of one or more of the plurality of PDUs in the set of PDUs to be retransmitted or one or more of the remaining delay budget.

13. The method of claim 11, further comprising: A second priority is determined for one or more of the plurality of PDUs in the set of PDUs to be retransmitted, wherein a second logical channel is associated with the second priority.

14. The method of claim 13, wherein the indication includes one or more of an indication of one or more sequence numbers of one or more of the plurality of PDUs in the set of PDUs to be retransmitted or an indication of a second priority.

15. The method of claim 11, wherein a second logical channel to be used for retransmitting the one or more of the plurality of PDUs in the PDU set is determined based on the fact that the number of one or more of the plurality of PDUs in the PDU set to be retransmitted is greater than a first threshold and the remaining delay budget of one or more of the plurality of PDUs in the PDU set to be retransmitted is less than at least one of a second threshold.

16. The method of claim 11, further comprising: Based on the attributes of the PDU set, update the first priority of one or more of the plurality of PDUs in the PDU set to be retransmitted, wherein the attributes of the PDU set include one or more of the following: type of PDU set, importance of PDU set, payload size, percentage of PDU set to be retransmitted, or number of PDUs in PDU set.

17. The method of claim 11, further comprising: If the number of one or more of the plurality of PDUs in the set of PDUs to be retransmitted is less than a first threshold and the remaining delay budget of one or more of the plurality of PDUs in the set of PDUs to be retransmitted is greater than a second threshold, the first logical channel associated with the first priority is used to retransmit one or more of the plurality of PDUs in the set of PDUs.

18. The method of claim 11, further comprising: Transmit the plurality of PDUs in a PDU set in one or more batches; and Based on the transmission status of the first batch of PDUs in the PDU set, the priority to be assigned to the second batch of PDUs in the PDU set is determined.

19. The method of claim 11, further comprising: Based on information associated with the sequence number (SN) gap, the priority of one or more of the plurality of PDUs in the PDU set to be retransmitted during the retransmission is updated, wherein the information associated with the SN gap includes one or more of the number of SN gaps, the size of the SN gap, the length of the SN gap, or the phase of the SN gap.

20. The method of claim 11, further comprising: Determine to use the default configuration to transmit the plurality of PDUs in the PDU set, wherein the default configuration includes one or more of the default priority value, default mapping configuration, or default logical control priority (LCP) parameter.

Images