Upper layer reliability for XR traffic flow

Abstract

Systems, methods, and devices for wireless communication. Configuration information indicating a configuration for an acknowledgement mode (AM) radio link control (RLC) entity is received. A packet data unit (PDU) set is received by a packet data convergence protocol (PDCP) entity. The AM RLC entity is configured for retransmission based on at least one condition, wherein the at least one condition includes PDU set characteristics and / or PDU set transmission status. And transmitting the PDU set through the AM RLC entity. An RLC state PDU indicating an RLC state is received. One or more PDUs in the set of PDUs are retransmitted by the RLC entity in response to the RLC status. In some implementations, the PDU set characteristics include a priority level of the PDU set and / or a type of the PDU set. In some implementations, the PDU set transmission state includes a time to live (TTL) threshold.

Description

[0001] Cross-referencing of background-related applications This application claims the benefits of U.S. Provisional Application Serial Nos. 63 / 531,193, 63 / 531,197, 63 / 531,201, and 63 / 531,204, all filed on August 7, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] The term Extended Reality (XR) can refer to different types of immersive experiences, including Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and / or realities in between. Some XR service and / or application traffic flows may include data and / or Packet Data Units (PDUs), which may be associated with Application Data Units (ADUs), PDU sets, or data bursts. PDUs belonging to a PDU set may be associated with different segments and / or components of a video frame or video slice. In some implementations, a data burst may include one or more PDU sets that may be transmitted and / or received within a time window. For example, in some implementations, the number of PDUs in a PDU set or data burst transmitted in the uplink (UL) and / or received in the downlink (DL) may depend on the type of media frame (e.g., a 3D video frame or audio frame). Summary of the Invention

[0003] Some implementations provide a method for wireless communication implemented in a Wireless Transmit / Receive Unit (WTRU). Configuration information indicating the configuration for an Acknowledgment Mode (AM) Radio Link Control (RLC) entity is received. A set of Packet Data Units (PDUs) is received via a Packet Data Convergence Protocol (PDCP) entity. The AM RLC entity is configured for retransmission based on at least one condition, wherein the at least one condition includes PDU set characteristics and / or PDU set transmission status. The PDU set is transmitted via the AM RLC entity. An RLC status PDU indicating the RLC status is received. One or more PDUs in the PDU set are retransmitted via the RLC entity in response to the RLC status.

[0004] In some implementations, PDU set characteristics include the priority level of the PDU set and / or the type of the PDU set. In some implementations, the PDU set transmission status includes a time-to-live (TTL) threshold, a PDU set error rate (PSER) threshold, an uplink (UL) buffer level for the PDU set, and / or the remaining percentage of the PDU set to be transmitted.

[0005] In some implementations, the at least one condition includes a network condition. In some implementations, the at least one condition includes a radio condition. In some implementations, the at least one condition includes a WTRU condition. In some implementations, the WTRU condition includes a buffer level. In some implementations, the RLC status indicates that at least one PDU in the PDU set has not been received.

[0006] In some implementations, the AM RLC entity is configured to enable retransmission in response to a value associated with the PDU set satisfying a threshold associated with at least one condition. In some implementations, the AM RLC entity is configured to disable retransmission in response to a value associated with the PDU set satisfying a threshold associated with at least one condition.

[0007] Some implementations provide a WTRU. The WTRU includes circuitry configured to receive configuration information indicating configuration for an AM RLC entity. The WTRU also includes circuitry configured to receive a first PDU set via a PDCP entity. The WTRU further includes circuitry configured to configure the AM RLC entity for retransmission based on at least one condition, wherein the at least one condition includes PDU set characteristics and / or PDU set transmission status. The WTRU also includes circuitry configured to transmit the PDU set via the AM RLC entity. The WTRU further includes circuitry configured to receive RLC status PDUs indicating an RLC status. The WTRU further includes circuitry configured to retransmit one or more PDUs in the PDU set via the RLC entity in response to an RLC status.

[0008] In some implementations, PDU set characteristics include the PDU set priority level and / or the PDU set type. In some implementations, the PDU set transmission status includes a TTL threshold, a PSER threshold, the PDU set UL buffer level, and / or the remaining percentage of the PDU set to be transmitted.

[0009] In some implementations, the at least one condition includes a network condition. In some implementations, the at least one condition includes a radio condition. In some implementations, the at least one condition includes a WTRU condition. In some implementations, the WTRU condition includes a buffer level. In some implementations, the RLC status indicates that at least one PDU in the PDU set has not been received.

[0010] In some implementations, the AM RLC entity is configured to enable retransmission in response to a value associated with the PDU set satisfying a threshold associated with at least one condition. In some implementations, the AM RLC entity is configured to disable retransmission in response to a value associated with the PDU set satisfying a threshold associated with at least one condition.

[0011] Some implementations provide a method for wireless communication. Data is transmitted through one of a plurality of Radio Link Control (RLC) entities. Each of the plurality of RLC entities operates in a different mode. The data is transmitted through the one of the plurality of RLC entities based on at least one condition. In some implementations, the data includes a set of Packet Data Units (PDUs). In some implementations, the at least one condition includes PDU set characteristics, PDU set transmission status, WTRU condition, and / or network condition. In some implementations, the PDU set characteristics include an importance level; the PDU set transmission status includes a TTL threshold, a PSER threshold, a UL buffer level, and / or the remaining percentage of the PDU set to be transmitted; the WTRU condition includes radio condition and / or buffer level; and the network condition includes radio condition and / or buffer level. In some implementations, each of the plurality of RLC entities operates in one of an acknowledged mode (AM), an unacknowledged mode (UM), or a transparent mode (TM). Some implementations provide a WTRU, system, processor, network element, base station, access point, site, integrated circuit, and / or memory configured to perform the method for wireless communication.

[0012] Some implementations provide a method for wireless communication. Data is transmitted via a Radio Link Control (RLC) entity. The RLC entity is configured for retransmission based on at least one condition. In some implementations, the data includes a set of PDUs. In some implementations, the at least one condition includes PDU set characteristics, PDU set transmission status, WTRU conditions, and / or network conditions. In some implementations, the PDU set characteristics include an importance level; the PDU set transmission status includes a TTL threshold, a PSER threshold, a UL buffer level, and / or the remaining percentage of the PDU set to be transmitted; the WTRU conditions include radio conditions and / or buffer levels; and the network conditions include radio conditions and / or buffer levels. In some implementations, the RLC is configured to enable retransmission in response to a value associated with the data satisfying a threshold associated with the at least one condition. Some implementations provide a WTRU, system, processor, network element, base station, access point, site, integrated circuit, and / or memory configured to perform the method for wireless communication.

[0013] Some implementations provide a method for wireless communication. Data is transmitted via a Packet Data Convergence Protocol (PDCP) associated with multiple RLC entities. The data is transmitted through multiple RLC entities based on at least one condition. In some implementations, the data includes a set of PDUs. In some implementations, the at least one condition includes PDU set characteristics, PDU set transmission status, WTRU conditions, and / or network conditions. In some implementations, the PDU set characteristics include an importance level; the PDU set transmission status includes a TTL threshold, a PSER threshold, an UL buffer level, and / or a remaining percentage of the PDU set to be transmitted; the WTRU conditions include radio conditions and / or buffer levels; and the network conditions include radio conditions and / or buffer levels. In some implementations, the PDCP is configured to transmit the data through multiple RLC entities in response to a value associated with the data satisfying a threshold associated with the at least one condition. Some implementations provide a WTRU, system, processor, network element, base station, access point, site, integrated circuit, and / or memory configured to perform the method for wireless communication.

[0014] Some implementations provide a method for wireless communication. Data is transmitted through a first RLC entity among a plurality of RLC entities. A copy of the data is transmitted through a second RLC entity among the plurality of RLC entities based on conditions associated with the data transmission through the first RLC entity. In some implementations, the data includes a set of PDUs. In some implementations, the at least one condition includes the length of time since the data transmission through the first RLC entity, the data reception status from the network, radio conditions on the links associated with one or more RLC entities, and / or the uplink (UL) buffer level on the links associated with one or more RLC entities. In some implementations, the at least one condition depends on PDU set characteristics and / or PDU set transmission status. In some implementations, a PDCP is configured to transmit a copy of the data through a second RLC entity among the plurality of RLC entities in response to a value associated with the data transmission through the first RLC entity satisfying a threshold associated with the at least one condition. Some implementations provide a wireless transmit / receive unit (WTRU), system, processor, network element, base station, access point, site, integrated circuit, and / or memory configured to perform the method for wireless communication. Attached Figure Description

[0015] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which the same reference numerals denote the same elements, wherein: Figure 1AThis is a system diagram illustrating an exemplary communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B This illustrates that, according to an embodiment, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used in the communication system shown; Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1A System diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used in the communication system shown; Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shown illustrates another example RAN and another example CN used in the communication system. Figure 2 This is a line graph showing an exemplary set of PDUs received over time; Figure 3 This is a block diagram illustrating an exemplary protocol view with a separate bearer; Figure 4 This is a block diagram showing an overview model of the RLC sublayer; Figure 5 This is a flowchart illustrating an exemplary process including conditional RLC entity handover performed for wireless communication; Figure 6 This is a flowchart illustrating another exemplary process performed for wireless communication, including an adaptive RLC entity; Figure 7 This is a flowchart illustrating another exemplary process performed for wireless communication; Figure 8 This is a flowchart illustrating another exemplary process performed for wireless communication; Figure 9 This is a flowchart illustrating another exemplary process performed for wireless communication, including an adaptive RLC entity; and Figure 10 This is a flowchart illustrating another exemplary process performed for wireless communication, including an adaptive RLC entity. Detailed Implementation

[0016] The following acronyms and abbreviations are used in this article: 6DOF (six degrees of freedom) ACK confirmation ADU Application Data Unit AR (Augmented Reality) AS Access Layer AM Confirmation Mode BLER block error rate BSR Buffer Status Report BSD Bucket Size Duration BWP bandwidth portion CAP channel access priority CAPC Channel Access Priority Categories CCA Idle Channel Assessment CCE Control Channel Element CE control elements CG configuration authorization or cell group CP cyclic prefix CP-OFDM vs. Conventional OFDM (depending on the cycle prefix) CQI Channel Quality Indicator CRC Cyclic Redundancy Check CSI Channel State Information CW Competition Window CWS Competition Window Size CO channel occupancy DAI Downlink Allocation Index DCI Downlink Control Information DFI downlink feedback information DG Dynamic Licensing DL downlink DM-RS demodulation reference signal DRB data radio bearer eLAA Enhanced Licensing Assisted Access FDRA Frequency Domain Resource Allocation FeLAA Further Enhanced Authorized Assisted Access FoV field of view FPS (Frames Per Second) HARQ Hybrid Automatic Repeat Request LAA Authorized Assisted Access LBT Listen before you speak LCP Logical Channel Priority Processing LCH Logical Channel LTE Long Term Evolution (e.g., from 3GPP LTE R8 and later) NACK (Negative) MAC Media Access Control MCS modulation and coding scheme MIMO (Multiple Input Multiple Output) MT mobile terminal MTP moving to photons NAS Non-Access Layer NR New Radio NW Network OFDM (Orthogonal Frequency Division Multiplexing) PBR Priority Bit Rate PDB Packet Delay Budget PDCP (Packet Data Convergence Protocol) PDU (Packet Data Unit) PHY physical layer PUCCH (Physical Uplink Control Channel) PUSCH Physical Uplink Shared Channel PDSCH (Physical Downlink Shared Channel) PID (Process ID) PO paging timing PRACH (Physical Random Access Channel) PSS Master Synchronization Signal PSDB PDU Set Delay Limits PSER PDU set error rate PSIHI PDU Overall Processing Indicator QFI QoS Flow Identifier RA (Random Access or Procedure) RACH Random Access Channel RAR Random Access Response RCU Radio Access Network Central Unit RF front end RLF wireless link failure RLM Wireless Link Monitoring RNTI (Radio Network Identifier) RO RACH timing RRC (Radio Resource Control) RRM Wireless Resource Management RS reference signal RSRP reference signal received power RSSI Received Signal Strength Indicator RLC Wireless Link Control RTT round trip time SDAP Service Data Adaptation Protocol SR scheduling request SDU Service Data Unit SLIV start and length indicators SRS Detection Reference Signal SS synchronization signal SSS auxiliary synchronization signal SWG switching interval (in a self-contained subframe) SPS Semi-Persistent Scheduling SUL supplements uplink TB transfer block TBS (Transfer Block Size) TDRA Time Domain Resource Allocation TRP Transmit / Receive Point TSC Time-Sensitive Communication Time-Sensitive Networking (TSN) UCI Uplink Control Indicator UL uplink UTO unused transmission opportunities URLLC Ultra-Reliable Low-Latency Communication WBWP wide bandwidth portion WLAN (Wireless Local Area Network) and related technologies (IEEE 802.xx domain) VR Virtual Reality XR Extended Reality Figure 1A This diagram illustrates an exemplary 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 Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0017] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a Station (STA)) may be configured to transmit and / or receive wireless signals and may include 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, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0018] 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 (e.g., CN 106, Internet 110, and / or other networks 112). As an example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (e.g., gNodeBs (gNBs)), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0019] Base station 114a may be part of RAN 104, 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area (which may be relatively fixed or may vary over time). A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0020] 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.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0021] 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 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

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

[0023] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

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

[0025] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), 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), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

[0026] Figure 1ABase station 114b can be, for example, a wireless router, home Node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area (e.g., commercial premises, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drones), roads, etc.). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another 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 have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106.

[0027] RAN 104 can communicate with CN 106, 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, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but it should be understood, RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which may be using NR radio technology, CN 106 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0028] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing ordinary legacy 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 that may employ the same RAT as or a different RAT than RAN 104.

[0029] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capabilities (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 a base station 114a that can employ cellular-based radio technology and with a base station 114b that can employ IEEE 802 radio technology.

[0030] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) 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 should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0031] 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), any other type of integrated circuit (IC), a state machine, etc. 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 should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0034] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via various RATs (e.g., NR and IEEE 802.11).

[0035] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from these devices. 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 and store information from any type of suitable memory (e.g., 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, etc. In other embodiments, the processor 118 can access and store information from memory that is not physically located on WTRU 102 (e.g., on a server or home computer (not shown)).

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

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

[0038] The processor 118 can also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide 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 video), 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, etc. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0039] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a specific subframe used for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit that reduces or substantially eliminates self-interference through hardware (e.g., a choke) or through signal processing by a processor (e.g., a separate processor (not shown) or through processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a specific subframe used for either UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0040] Figure 1C This is a system diagram of RAN 104 and CN 106 according to an 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.

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

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

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

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

[0045] 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 typically routes and forwards 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, and managing and storing the context of WTRUs 102a, 102b, and 102c.

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

[0047] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include, 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 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.

[0048] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network. In a representative embodiment, the other network 112 may be a WLAN.

[0049] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more sites (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to its respective destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send a traffic flow to the AP, and the AP can deliver the traffic flow 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 the source STA and the destination STA (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0050] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can have a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented, for example in an 802.11 system. For CSMA / CA, each STA (including the AP) can listen on the primary channel. If a particular STA detects / investigates and / or determines that the primary channel is busy, that particular STA can back off. In a given BSS, at any given time, there can be only one STA (e.g., only one site) transmitting.

[0051] 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 to form a 40 MHz wide channel.

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

[0053] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah have reduced channel operating bandwidth and carrier capacity. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV blank spectrum (TVWS), while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities supporting (e.g., only supporting) certain 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).

[0054] WLAN systems that support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can still 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 Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because STAs supporting only the 1 MHz operating mode are transmitting to the AP, all available frequency bands can be considered busy even if most of the available band remains idle.

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

[0056] Figure 1D This is a system diagram of RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0057] RAN 104 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 104 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 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, 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 can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, 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).

[0058] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using multiple or scalable subframe lengths or transmission time intervals (TTIs) (e.g., containing a variable number of OFDM symbols and / or a continuously variable absolute time length).

[0059] 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 accessing other RANs (such as 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 (e.g., 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 and 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.

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

[0061] Figure 1DThe CN 106 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. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

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

[0063] SMF 183a and 183b can connect to AMF 182a and 182b in CN 106 via the N11 interface. SMF 183a and 183b can also connect to UPF 184a and 184b in CN 106 via the N4 interface. SMF 183a and 183b can select and control UPF 184a and 184b, and configure service flow routing through UPF 184a and 184b. SMF 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

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

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

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

[0067] The simulation device can be designed to test one or more other devices in a laboratory environment and / or a carrier network environment. For example, the one or more simulation devices can perform one or more of the functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices can also perform one or more of the functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing and / or performing tests using over-the-air wireless communication.

[0068] The one or more simulation devices can perform one or more (including all) of the functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices can be utilized 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. The one or more simulation devices can be test equipment. The simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0069] Some implementations involve extended reality. The term Extended Reality (XR) can refer to different types of immersive experiences, including Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and / or realities in between. In some implementations, VR can refer to a rendered version of the delivered visual and audio scene. Rendering can simulate the visual (e.g., stereoscopic 3D) and / or audio sensory stimuli of the real world for an observer or user as they move within limits defined by the application, for example, as naturally as possible. In some implementations, AR can refer to additional information, artificially generated objects and / or items, and / or content superimposed on the user's current environment. In some implementations, MR can refer to a form of AR in which some virtual elements are inserted into the physical scene, for example, to provide the illusion that these elements are part of the real scene. In some implementations, XR can refer to all real and virtual combinations of environments and human-computer interactions generated by computer technology and wearable devices.

[0070] In some implementations, within the context of XR applications and / or services, immersion can refer to the user's feeling of being surrounded by a virtual environment and / or the user's feeling of being physically and spatially present in the virtual environment. In some implementations, the level of virtuality can range from partial sensory input to fully immersive multisensory input, making virtual reality virtually indistinguishable from actual reality.

[0071] In some implementations, a WTRU can correspond to any XR device and / or node, and can have various form factors. In some implementations, a WTRU (e.g., an XR WTRU) can include, but is not limited to, head-mounted displays (HMDs), optical see-through glasses and camera-based see-through HMDs for AR and MR, mobile devices with location tracking and cameras, wearable devices, haptic gloves, haptic body suits, haptic shoes, etc. In some implementations, several different types of XR WTRUs can provide or be based on XR device functionality, such as displays, cameras, sensors, sensor processing, wireless connectivity, XR and / or media processing and / or power supply, provided, for example, by one or more devices, wearable devices, actuators, controllers, and / or accessories. In some implementations, one or more devices, nodes, and / or WTRUs can be grouped into collaborative XR groups, for example, to support XR applications, experiences, and / or services.

[0072] Some XR services and / or applications may involve traffic flows that can include data and / or PDUs, which may be associated with ADUs, PDU sets, or data bursts. In an example, PDUs belonging to a PDU set may be associated with different segments and / or components of a video frame or video strip. In some implementations, a data burst may include one or more PDU sets that can be transmitted and / or received within a time window. For example, in some implementations, the number of PDUs in a PDU set or data burst transmitted in the UL and / or received in the DL may depend on the type of media frame (e.g., 3D video frames, audio frames).

[0073] In some XR applications, the WTRU transmits XR service streams (e.g., including gesture, gesture, and / or video information) comprising one or more PDUs and / or PDU sets in the UL, and / or receives XR service streams (e.g., including video, audio, and / or haptic information) in the DL. In some implementations, such service streams can be transmitted and / or received periodically or non-periodically in one or more data streams (e.g., QoS streams). In some implementations, for example during UL transmission, XR service streams can arrive at the WTRU from the application layer at different times and / or from different devices, terminals, and / or WTRUs (e.g., via side links). In some implementations, such XR service streams can be characterized by different attributes, such as variable payload size per PDU set, variable number of PDUs per PDU set, variable importance at the PDU level and / or PDU set level, and different levels of interdependence between PDUs and / or PDU sets. In some implementations, such XR traffic flows (e.g., PDUs and / or sets of PDUs) received by the WTRU may also experience varying latency, jitter, data rates, and / or loss rates. In some implementations, timely XR-aware (e.g., awareness of PDU set attributes) performance of data transmission and / or reception and / or other related functions (e.g., priority handling, multiplexing, and / or scheduling) can have the advantage of improving QoS and / or user experience (QoE).

[0074] Some implementations involve PDU sets and data bursts. In some 5G system (5GS) implementations, the QoS flow is the finest-grained QoS distinction within a PDU session. 5G QoS characteristics can be determined by 5QI. Therefore, in some implementations, each packet in the QoS flow can be processed according to the same QoS requirements.

[0075] For XR and / or XR media services, a set of packets is used to carry the payload of a PDU set (e.g., frames, video strips, and / or tiles). A PDU set may include one or more PDUs carrying the payload of a single unit of information (e.g., a frame, video strip, and / or tile) generated at the application level.

[0076] At the media layer, packets within such a PDU set can be decoded as a whole and / or processed in other ways. For example, in some implementations, a frame, video strip, and / or chunk can only be decoded if some or all of the packets carrying the frame, video strip, and / or chunk are successfully delivered. Similarly, in some implementations, frames within a Group of Pictures (GOP) can only be decoded by the client if the client successfully receives all the frames that the frame depends on. Therefore, in some implementations, groups of packets within a PDU set can be described as having inherent dependencies on each other at the media layer. In some implementations, 5GS may perform scheduling inefficiently if such dependencies between packets within a PDU set are not considered. For example, 5GS might randomly drop one or more packets but attempt to deliver other packets from the same PDU set that are useless to the client, thus wasting radio resources.

[0077] In some implementations, audio samples, haptic applications, and / or remote control operations can benefit if 5GS takes into account the characteristics of PDU sets. Some implementations that leverage this dependency between PDU set groups (e.g., frames, video strips, and / or chunks) can have the advantage of improved efficiency and / or enhanced user experience.

[0078] Some implementations offer enhancements to the current 5GS QoS framework to support different QoS processing for PDU sets. PDU sets can carry different content, such as I / B / P frames, stripes / chunks within I / B / P frames, etc. Some implementations provide differentiated QoS processing, taking into account the different importance of PDU sets, for example, by processing packets (i.e., PDUs) belonging to less important PDU sets (or multiple sets) differently to reduce resource waste.

[0079] A set of data PDUs generated and sent by an application over a period of time (e.g., a relatively short period of time) can be called a data burst. In some implementations, a data burst may include multiple PDUs belonging to one or more PDU sets.

[0080] Figure 2This is a line graph showing data 200 received over time, illustrating an example of how the WTRU receives information in PDU sets and data bursts. Data 200 includes a first data burst 202 and a second data burst 252. The first data burst 202 includes a first PDU set 210, a second PDU set 220, and a third PDU set 250. In this example, the first PDU set 210 is an I-frame containing 7 PDUs. Each PDU includes a sequence number for identification (numbered 1-7 in this example). The second PDU set 220 is an I-frame containing 8 PDUs. Each PDU includes a sequence number for identification (numbered 1-8 in this example). The third PDU set 230 is a P-frame containing 5 PDUs. Each PDU includes a sequence number for identification (numbered 1-5 in this example).

[0081] The second data burst 252 comprises a first PDU set 260 and a second PDU set 270. In this example, the first PDU set 260 is an I-frame containing 9 PDUs. Each PDU includes a sequence number for identification (numbered 1-9 in this example). The second PDU set 270 is a B-frame containing 6 PDUs. Each PDU includes a sequence number for identification (numbered 1-6 in this example).

[0082] In some implementations, the PDU set delay budget (PSDB) refers to the upper limit of the time that the PDU set can be delayed between the N6 termination point at the WTRU and the UPF. In some implementations, PSDB refers to the PDU set delay budget (e.g., the time from receiving the first PDU of the PDU set at the WTRU to receiving (e.g., correctly receiving) the last PDU of the PDU set at the receiving side).

[0083] In some implementations, the Time-to-Live (TTL) of a PDU set refers to how much of the PSDB (Power Supply Depth) remains for that PDU. For example, if the PSDB is x milliseconds (ms), and y ms have elapsed since the first PDU in the PDU set became available for transmission at the remote WTRU, then the TTL is xy ms.

[0084] In some implementations, the PDU set error rate (PSER) refers to the upper limit of the ratio of PDU sets that have been processed by the sender of the link layer protocol (e.g., RLC layer) but whose PDUs have not been successfully delivered to the upper layer (e.g., PDCP layer) by the corresponding receiver.

[0085] In some implementations, if a PDU set is associated with and / or marked with a PDU Set Overall Processing Instruction (PSIHI), all PDUs in the PDU set must be successfully received at the receiving entity / application so that the information contained within the PDU set is useful (e.g., even if all PDUs in the PDU set except for one PDU are successfully received, the application may not be able to combine and / or render the information in the PDUs in the PDU set).

[0086] In some implementations, a set of PDUs can still be available even if a portion of the PDU is not received.

[0087] Some implementations involve how the WTRU receives information about PDU sets. In some implementations, the WTRU may obtain information about the size of the PDU set and / or data burst (e.g., the size of frames and / or PDUs and / or PDU sets and / or PDU cluster groups) and / or other information (e.g., PSDB, PDU set type and / or importance, etc.) through any one or more of the following methods.

[0088] For example, in some implementations, the WTRU can receive one or more indications about the size of the PDU set from the application and / or the upper layer. In some implementations, this indication can be received in the first packet of the PDU set and / or in the packet header of the PDU.

[0089] In some implementations, the WTRU can receive one or more indications from the application and / or upper layers, based on which the WTRU can infer the size of the PDU set. For example, in some implementations, the WTRU can receive indications about the first and last packets in the PDU set, which may be indicated, for example, in the headers of the first and last packets.

[0090] In some implementations, the WTRU can receive size information, for example, at a granular level (e.g., a finer-grained level). For instance, in some implementations, the WTRU can receive indications from the application and / or upper layers regarding the typical size of different frames (e.g., I-frames, P-frames, and / or B-frames). In some implementations, packets at the first, last, and / or other locations in the PDU set may include information indicating their type (e.g., corresponding to an I-frame or P-frame) and / or that the packet is the first, last, and / or other location in the PDU set. In some implementations, based on this information, the WTRU can estimate the size of the PDU set.

[0091] In some implementations, such as in encoding schemes where different types of frames are encoded into different traffic streams (e.g., based on GOPs, where a single video frame is an I-frame or a P-frame), the WTRU can receive an indication to link the data stream to the frame type, for example, only once at the start of the session.

[0092] For example, in some implementations, the indication from the application and / or upper layer to the WTRU may be or include a bit, where “0” may correspond to a data stream with I-frames and “1” may correspond to a data stream with P-frames. Note that in other implementations, any other suitable indication may also be available (e.g., where the bit is reversed or other encoding is used to indicate the frame type).

[0093] In some implementations, the WTRU can receive information about the PDU set size on a PDU set basis and / or per stream basis (e.g., in a GOP-based encoding scheme). In some implementations, this exchange can occur at the start of the XR session. In some implementations, the WTRU can receive updates throughout the XR session (e.g., periodic updates), (e.g., periodically, or, for example, only when the information changes (e.g., the PDU set size changes)).

[0094] In some implementations, WTRU can receive information about multiple PDU sets (e.g., at the granularity of PDU cluster groups) from the application and / or upper layers. In some implementations, the application and / or upper layers can group PDU sets based on similarity between the individual PDU sets (e.g., same size, type, importance / priority, etc.).

[0095] In some implementations, the importance of data can be indicated from the application and / or upper layers to the WTRU at different data unit granularities (e.g., per frame and / or per PDU and / or per PDU set and / or per PDU cluster group, etc.). In some implementations, importance indication can be given per data unit, or it can be given for the first data unit, with no indication sent for subsequent data units until and / or unless the importance changes. In some implementations, importance indication can include bitwise binary indications and / or flags, such as indicating whether the data is sufficiently important (e.g., having an importance level above a threshold) to require special handling. In some implementations, importance indication can be based on a table mapping different QoS levels in a traditional QoS framework to different importance levels.

[0096] For example, in some implementations, the four most important QoS levels from the QoS framework can be marked as important, allowing the WTRU to determine that any data mapped to a radio bearer with corresponding QoS flows from the four most important QoS levels may need to be transmitted before being switched to another cell and / or gNB or other node b, base station, or infrastructure equipment. In some implementations, any data mapped to a radio bearer with QoS flows from the remaining QoS levels can be transmitted only after the HO (Hosting Operation) is complete. In some implementations, the indication of importance can override QoS levels from the traditional QoS framework in certain situations (e.g., if data in the buffer is about to expire).

[0097] Some implementations involve separate bearers in dual connectivity (DC). In DC, in some implementations, the WTRU is served by two nodes, each consisting of a set of cells, which may be referred to as the primary cell group (MCG) and the secondary cell group (SCG). In some implementations, the bearer may be associated only with the MCG or only with the SCG, or the bearer may be configured as a separate bearer.

[0098] Figure 3 This is a block diagram illustrating an exemplary protocol view 300 of a separated bearer. Protocol view 300 shows a separated bearer between WTRU 302, gNB1 304, and gNB2 306. In some implementations, WTRU 302 is associated with a PDCP entity 304, and the network-side peer PDCP entity may terminate at one of the gNBs (or other node b, base station, or infrastructure equipment), either the primary node or the secondary node. In this example, the network-side termination is at PDCP entity 310 at gNB1 304. gNB1 304 and gNB2 306 include RLC entities 312 and 314, MAC entities 316 and 318, and PHY entities 320 and 322, respectively. WTRU 302 includes corresponding RLC entities 324 and 326, MAC entities 328 and 330, and PHY entities 332 and 334, communicating with gNB1 304 and gNB2 306 as shown.

[0099] In some implementations, within the DL, the CN can send data to the gNB (or other node b, base station, or infrastructure equipment) where the PDCP terminates, and the network is responsible for sending data directly to the WTRU (e.g., PDCP PDU) via the link between that gNB (or other node b, base station, or infrastructure equipment) and the WTRU, or forwarding the PDCP PDU to gNB2 (or other node b, base station, or infrastructure equipment) (e.g., via the Xn interface), and gNB2 (or other node b, base station, or infrastructure equipment) will send data to the WTRU via its own link with the WTRU. For example, in some implementations, the CN can send data to gNB1 304 for direct transmission to WTRU 302, or gNB1 304 can forward data to gNB2 306, and gNB2 306 can transmit data from itself to WTRU 302.

[0100] In some implementations, within the UL, the WTRU is configured with one link / path as the primary path and the other as the secondary path. In some implementations, a threshold, which may be referred to as the UL separation buffer threshold, can also be configured. In some implementations, if the UL buffer size used for the bearer is less than this threshold, the PDCP will only push data to the RLC associated with the primary path. However, if the amount of data in the buffer becomes greater than the threshold, the WTRU can push data to either path (e.g., in some implementations, this is left to the WTRU implementation). For example, in some implementations, WTRU 302 can configure the path from RLC 324 to RLC 312 at gNB1 304 as the primary path and the path from RLC 326 to RLC 314 at gNB2 306 as the secondary path. If the UL buffer size used for the bearer is less than the UL separation buffer threshold, the PDCP 308 will only push data to RLC 324. If the size of the UL buffer used for this bearer becomes larger than the threshold, the PDCP 308 can push the data to the RLC 324, RLC 326, or both.

[0101] Some implementations involve packet duplication. In some implementations, packet duplication is a mechanism performed at the PDCP layer (e.g., after generating a PDCP PDU from a PDCP SDU, applying encryption and / or integrity protection, performing header compression and / or generating a SN, etc.), where the same PDCP PDU is forwarded to the receiver via multiple paths and / or links. In some implementations, this can be implemented in DC or carrier aggregation (CA) scenarios. In some implementations, since the two packets (i.e., the same packets forwarded via different links and / or paths) are identical, the receiving PDCP entity can determine whether and / or when a duplicate PDU has been received and / or can discard it (e.g., by detecting the reception of a PDU with the same SN as the received PDU).

[0102] In some implementations, in the case of DC, the WTRU is configured with a separate bearer to enable packet replication. In some implementations, in the case of CA, the WTRU is also configured with multiple RLC entities and associated logical channels.

[0103] In some implementations, replication in the downlink is network-controlled (e.g., fully network-controlled). In some implementations, received copies are dropped by the WTRU at the PDCP level. In some implementations, in the uplink, replication can be enabled and / or disabled (also known as activated and / or deactivated) using a downlink MAC CE received from the network. In some implementations, in the case of CA, additional restrictions (in some cases called logical channel restrictions) are configured to facilitate that packets and one or more duplicate versions are not transmitted over the same carrier (e.g., a logical channel will be configured to use only UL resources licensed on the same carrier). In some implementations, packet replication provides the benefit of enhanced reliability. However, in some implementations, packet replication reduces system throughput, which may lead to increased resource consumption, for example, due to the same packets being transmitted multiple times over different links (e.g., in the case of DC) or carriers (e.g., in the case of CA).

[0104] Some implementations involve the Radio Link Control (RLC) protocol. The RLC protocol is a Layer 2 protocol, situated between the PDCP and MAC protocols. In some implementations, the tasks (e.g., primary tasks) of the NR RLC protocol include one or more of the following: transmitting upper-layer protocol data units (PDUs) in one of three modes (Acknowledged Mode (AM), Unacknowledged Mode (UM), and / or Transparent Mode (TM)); error correction via Automatic Repeat Request (ARQ) (e.g., for AM data transmission only); segmentation and reassembly of RLC SDUs (e.g., UM and AM); resegmentation of RLC data PDUs (e.g., AM); duplicate detection (e.g., AM); RLC SDU dropping (e.g., UM and AM); RLC reconstruction; and / or protocol error detection (e.g., AM).

[0105] In some implementations of LTE, data multiplexing is performed twice: RLC SDUs from one logical channel are concatenated into an RLC PDU at the RLC layer, and RLC PDUs from different logical channels are multiplexed into a MAC PDU at the MAC layer. In some implementations, the MAC PDU carries information about the same data fields in both the RLC and MAC headers and / or subheaders. In some implementations, RLC concatenation receives input from the MAC layer scheduling, i.e., it interacts with the MAC layer to construct an RLC PDU with a size suitable for each UL grant. In some implementations, RLC concatenation can be performed, for example, within a single scheduling cycle after receiving a scheduling decision (e.g., uplink grant size) and after the LCP (Logical Channel Priority Processing) procedure at the MAC layer. In some implementations, this means that neither the RLC nor the MAC layer can perform any preprocessing before receiving grant information. In some implementations, this may limit the very high data rate and latency requirements of NR compared to LTE. Therefore, in some implementations, the concatenation process can be removed from the NR RLC layer, and the RLC can send the PDCP packet to the MAC immediately after adding the header. After receiving the scheduling authorization and transport block size (TBS) indication at the MAC layer, it can concatenate and / or multiplex data from multiple RLC PDUs and send them over the air interface.

[0106] In some implementations, LTE RLC also includes reordering functionality. In some implementations, particularly in NR, this functionality has been removed from the RLC and left to the PDCP, as the PDCP already has reordering capabilities. In some implementations, this has the advantage of improved latency, for example, because delivering out-of-order RLC packets to the PDCP allows for earlier decryption of those packets. In some implementations, data transmission or reception can be performed in each RLC mode. In some implementations, separate entities are used for transmission and reception in TM and UM, but in AM, a single RLC entity performs both transmission and reception.

[0107] Figure 4 This is a block diagram of the communication interface 400 between WTRU 402 and WTRU (or gNB) 452, showing an overview model of an exemplary RLC sublayer, which illustrates this point. In this example, WTRU 402 includes a receive TM RLC entity 404, a transmit TM RLC entity 406, a receive UM RLC entity 408, a transmit UM RLC entity 410, and a transmit and receive AM RLC entity 412. WTRU 402 includes an upper layer 440 and a lower layer 445. WTRU 452 includes a transmit TM RLC entity 454, a receive TM RLC entity 456, a transmit UM RLC entity 458, a receive UM RLC entity 460, and a transmit and receive AM RLC entity 462. WTRU 452 includes an upper layer 490 and a lower layer 495.

[0108] In WTRU (or gNB) 452, the transmitting TM RLC entity 454 receives PDUs from the upper layer 490 via the RLC channel interface, as shown in the figure, and transmits these PDUs to the receiving TM RLC entity 404 of WTRU 402 via the logical channel interface, lower layers 495 and 445, and radio interface 499, as shown in the figure. The receiving TM RLC entity 404 transmits the PDUs to the upper layer 440 via the RLC channel interface, as shown in the figure.

[0109] In WTRU 402, the transmitting TM RLC entity 406 receives PDUs from the upper layer 440 via the RLC channel interface, as shown in the figure, and transmits these PDUs to the receiving TM RLC entity 456 of WTRU (or gNB) 452 via the logical channel interface, lower layers 445 and 495, and radio interface 499, as shown in the figure. The receiving TM RLC entity 456 transmits the PDUs to the upper layer 490 via the RLC channel interface, as shown in the figure.

[0110] In WTRU (or gNB) 452, the transmitting UM RLC entity 458 receives PDUs from the upper layer 490 via the RLC channel interface, as shown in the figure, and transmits these PDUs to the receiving UM RLC entity 408 of WTRU 402 via the logical channel interface, lower layers 495 and 445, and radio interface 499, as shown in the figure. The receiving UM RLC entity 408 transmits the PDUs to the upper layer 440 via the RLC channel interface, as shown in the figure.

[0111] In WTRU 402, the transmitting UM RLC entity 410, as shown in the figure, receives PDUs transmitted from the upper layer 440 via the RLC channel interface, and transmits these PDUs to the receiving UM RLC entity 460 of WTRU (or gNB) 452 via the logical channel interface, lower layers 445 and 495, and radio interface 499. The receiving UM RLC entity 460, as shown in the figure, transmits the PDUs to the upper layer 490 via the RLC channel interface.

[0112] In WTRU (or gNB) 452, the transmit and receive AM RLC entity 462, as shown in the figure, receives PDUs from the upper layer 490 via the RLC channel interface, and transmits these PDUs to the transmit and receive AM RLC entity 412 of WTRU 402 via the logical channel interface, lower layers 495 and 445, and radio interface 499, as shown in the figure. The transmit and receive AM RLC entity 412, as shown in the figure, transmits the PDUs to the upper layer 440 via the RLC channel interface.

[0113] In WTRU 402, the transmit and receive AM RLC entity 412, as shown in the figure, receives PDUs from the upper layer 440 via the RLC channel interface, and transmits these PDUs to the transmit and receive AM RLC entity 462 of WTRU 402 via the logical channel interface, lower layers 495 and 445, and radio interface 499. The transmit and receive AM RLC entity 462, as shown in the figure, transmits the PDUs to the upper layer 490 via the RLC channel interface.

[0114] In some implementations, only data PDUs (which may be referred to as TMD and UMD) are supported in TM and UM. In some implementations, AM mode includes both data and control PDUs. Some implementations include only one control PDU defined in RLC, which may be referred to as a status PDU, as described below.

[0115] In some implementations, the TMD PDU has no header, contains the PDCP PDU received by the RLC, and is forwarded to the MAC as is. In some implementations, the UMD PDU includes a data field and a UMD PDU header. In some implementations, the UMDPDU header is byte-aligned. In some implementations, segmentation can be applied for UM and AM. In some implementations, the MAC layer informs the RLC layer of the available transport block size that can be scheduled and transmitted. In some implementations, if the RLC PDU size is larger than the available TB size, the RLC layer segments the RLC SDU into multiple PDUs. In some implementations, if the UMD PDU includes a complete RLC SDU (i.e., no PDCP PDU segmentation), the UMD PDU header only includes the SI (Segmentation Information) and Reserved (R) fields. In some implementations, the SI field is a 2-bit field indicating whether the RLC PDU contains a complete RLC SDU or the first, middle, or last segment of an RLC SDU (e.g., 00: complete SDU, 01: first segment of RLC SDU, 10: last segment of RLC SDU, 11: middle segment of RLC SDU). In some implementations, in the case of segmentation, the first and last segments will only include the SN and SI fields, while for middle segments, an additional field called SO (segment offset) is included, indicating the byte position of the RLC SDU segment within the original RLC SDU. In some implementations, the UMDPDU SN can be configured to be 6 or 12 bits. In some implementations, UM is similar to TM except for the segmentation aspect and header. On the other hand, in some implementations, AM provides reliability through retransmission (via Automatic Repeat Request, ARQ). Therefore, in some implementations, each AM PDU has an SN (e.g., even if it is not segmented). In some implementations, the SN used for AM can be configured as 12 or 18 bits. In some implementations, the RLC transmission window is a sliding window, including transmitted packets that have not yet been ACKed by the receiving RLC entity (e.g., when a low-numbered SN packet is received, the window can move to the right, allowing more packets to be transmitted). In some implementations, a larger SN may result in more unacknowledged RLC packets in the transmitting entity; however, in some implementations, the SN will incur more overhead.

[0116] In some implementations, the AM RLC header (e.g., additionally) includes a flag (D / C) indicating whether it is a data PDU or a control PDU. In some implementations, a polling bit may also be available in the AM RLC header, which can be used by the sending RLC entity to trigger the receiving RLC entity to send a status report. In some implementations, the RLC entity can be configured to set the polling bit, for example, based on the number of bytes / PDUs being transmitted (e.g., per X PDUs, per Y bytes, etc.). In some implementations, a polling disable timer can be configured to prevent subsequent STATUS reports from being triggered, for example, within a threshold time (e.g., a short period) after another STATUS report. In some implementations, similar to the UMD header, the AMD may also include an SI field and may include an SO field for segmentation.

[0117] In some implementations, the status PDU is an RLC AM control PDU sent from the receiving RLC entity (e.g., from the gNB in ​​the case of UL, and from the WTRU in the case of DL), indicating the receiving-side RLC status (e.g., which packets were received, which packets are pending reception, and / or lost). In some implementations, the transmitting RLC entity can use this information to determine how to advance the RLC transmission window and also determine which packets need to be retransmitted. In some implementations, the RLC AM entity can be configured with a maximum retransmission counter (e.g., which can take values ​​from 1 to 32, or any other suitable range of values ​​in other implementations). In some implementations, the retransmission count for a packet can be incremented each time it is retransmitted, and if the maximum retransmission count is reached for any RLC packet (e.g., if the retransmission count is set to 2 and no packet is received after the second retransmission, i.e., the third transmission including the first transmission), the RLC entity can indicate this to the RRC entity, which can consider this a radio link failure (RLF), and if the WTRU is operating in the DC (e.g., using the SCG if the failed RLC entity is in the MCG, and using the MCG if the failed RLC entity is in the SCG), a reconstruction or recovery via alternative link failure can be triggered.

[0118] In some implementations, the WTRU supporting the XR experience can receive data units (e.g., PDUs, PDU sets, data bursts, bit streams) from upper layers or different devices (e.g., AR glasses and haptic gloves, e.g., via SL). In some implementations, such data units (which may have variable payload sizes, different periodicity, jitter, and different interdependencies) can be further processed by the WTRU and transmitted in the UL.

[0119] In some implementations, capacity-related enhancements may include any one or more of the following: i) multiple CG PUSCH transmission opportunities within a single configuration grant (CG) PUSCH configuration period, ii) dynamic indication by the WTRU of unused CG PUSCH opportunities based on uplink control information (UCI), iii) buffer status reporting (BSR) enhancements including at least a new BSR table, iv) delay reporting of buffered data in the uplink, and / or v) PDU set drop operations for DL ​​and UL. In some implementations, power-saving enhancements may include DRX support for XR frame rates corresponding to non-integer periodicity (via at least a semi-static mechanism, such as RRC signaling). In some implementations, enhancements for XR awareness may include any one or more of the following: i) semi-static information (e.g., PDU set QoS parameters), dynamic information (PDU set information and identifier), and signaling indicating the end of data bursts provided by the CN for each QoS flow, and / or ii) XR traffic flow auxiliary information provided by the WTRU, such as periodicity and UL traffic flow arrival information.

[0120] In some implementations, the QoS requirements of a service semi-statically determine the QoS-related settings of one or more bearers associated with the service, as well as one or more logical channels associated with those bearers. In some implementations, this can be accomplished by configuring appropriate PDCP, RLC, logical channels, etc., associated with bearers aligned with the service requirements through network settings. For example, in some implementations, if latency is more important than reliability, the bearer may be associated with a transparent RLC entity. In some implementations, if the required reliability is higher than a threshold reliability amount (e.g., very high), the RLC may be set to AM mode, and additional replication via another carrier (in the case of CA) or another link (in the case of DC) may be enabled to achieve carrier and / or link diversity.

[0121] In some implementations, the QoS requirements of PDUs in a PDU set can be flexible within the context of an XR service flow. For example, in some implementations, PDUs at the beginning of a PDU set transmission can be handled in a more lenient manner compared to PDUs sent close to the PSDB expiration date. As used herein, "lenient manner" refers to low priority and low urgency (e.g., we can prioritize other more urgent data). In some cases, if a certain percentage of PDUs in the PDU set are received, the receiving side (e.g., the receiving application) may be able to decode the message, so the remaining PDUs in the set can be delivered in a best-effort manner afterward.

[0122] Therefore, in some implementations, applying a larger maximum RLC retransmission count for reliability or always using replication may be suboptimal for the entire PDU set.

[0123] Several issues concern latency versus reliability in single-connection and / or non-CA connection scenarios. In some implementations, such as in non-CA / non-DC operation, the reliability of a given bearer can be increased by associating that bearer with an RLC AM entity (e.g., allowing a larger number of RLC retransmissions). However, in other implementations, this may increase latency, reduce throughput, and / or increase overhead and / or processing (e.g., SN in the header, RLC window management that requires more buffering while waiting for RLC ACKs and limits maximum achievable throughput, etc.).

[0124] Several issues concern latency versus reliability in CA / DC scenarios. In some implementations, such as those in CA / DC operation, the reliability of a given bearer can be increased by performing replication via multiple carriers and / or links. However, in other implementations, this may increase the total resources used to transmit a given data. In some implementations, for non-XR traffic flows, replication is network-determined (e.g., activation and / or deactivation) and is semi-statically configured (e.g., via MAC CE). In some implementations, in an XR context, as described above, the QoS requirements of PDUs in a PDU set change during the PDU set's lifecycle, and the MN / SN may not always be aware of the PDU set's requirements / characteristics (e.g., high UL traffic). Therefore, in some implementations, always activating replication may be resource-inefficient, while not always deactivating it may compromise and / or reduce reliability.

[0125] Some implementations involve how the WTRU can dynamically adapt reliability-related operations and / or configurations (e.g., PDCP replication, RLC mode / retransmission mechanisms, etc.) for the bearer based on the resilient QoS requirements of different PDUs in the PDU set being transmitted. Some implementations include solutions related to conditional RLC entity handover. For example, in some implementations, higher latency for PDUs in the PDU set may be acceptable at the beginning of the PDU set because the TTL (Time to Live) of the PDU set is highest; however, as the TTL approaches zero, higher latency may become undesirable.

[0126] In some implementations, a PDCP entity can be associated with multiple RLC entities with different modes (e.g., three RLC entities: one RLC AM, one RLC UM, and one RLC TM). In some implementations, the WTRU can be configured conditionally to determine when to push PDCP PDUs from the PDU set to which RLC entity, depending on PDU set characteristics (e.g., importance level), the current PDU set transmission status (e.g., thresholds considering TTL, PSER, UL buffer level, remaining percentage of PDUs to be transmitted, etc.), and the current WTRU and / or network conditions (e.g., radio conditions, buffer level).

[0127] In an exemplary implementation involving conditional RLC entity switching, the WTRU may operate as follows: The WTRU may receive a configuration of a DRB / PDCP associated with two or more associated RLC entities (e.g., three RLC entities: one RLC AM, one RLC UM, and one RLC TM) having different operating modes, wherein one of the RLC entities is configured as the primary / default RLC entity. In some implementations, different RLC entities may share the same logical channel or have separate logical channels. In some implementations, the WTRU may receive a conditional configuration to dynamically determine the RLC entity for the PDUs in the PDU set used to transmit the DRB. In some implementations, conditions may include one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs; the percentage of remaining PDUs to be transmitted in the PDU set (or, if the PDUs in the PDU set may have different sizes, the percentage of the remaining data to be transmitted in the PDU set); PSER (either for the PDU set of interest or averaged across multiple PDU sets); PDU set importance or PDU importance; UL buffer level (UL buffer level of the DRB of interest, or total UL buffer level); radio conditions (e.g., RSRP threshold, RLC retransmission count, HARQ NACK / ACK level, etc.); and / or explicit indications from the network.

[0128] In some implementations, the WTRU can be further configured to determine the default / initial RLC entity (e.g., based on PDU set characteristics). The WTRU can begin transmitting PDCP PDUs via / through the default RLC entity. The WTRU can monitor conditions used to determine the RLC entity to be used for PDCP. The WTRU can select the RLC entity based on the monitored conditions / thresholds, PDU set characteristics and transmission status, and current UE / network conditions. The WTRU can send an indication to the network (e.g., gNB / DU) regarding RLC entity handover (e.g., the last SN (RLC or PDCP) transmitted with the previous RLC entity, the first SN (RLC or PDCP) transmitted with the current RLC entity, etc.). The WTRU can transmit PDCPPDUs through the determined RLC entity (and associated logical channels).

[0129] Some implementations include solutions associated with adaptive RLC entities. For example, in some implementations, the DRB / PDCP is associated with an RLC AM entity that dynamically adapts its behavior and / or operations (e.g., enabling and / or disabling retransmissions) based on PDU set characteristics (e.g., importance level), the current PDU set transmission status (e.g., thresholds considering TTL, PSER, UL buffer level, remaining percentage of PDU set to be transmitted, etc.), and current WTRU and / or network conditions (e.g., radio conditions, buffer level).

[0130] In an exemplary implementation involving an adaptive RLC entity, the WTRU may operate as follows: The WTRU may receive configurations for the DRB and the associated RLC AM entity, which has a default maximum retransmission count value. The WTRU may receive configurations for conditions used to determine whether to disable (maximum retransmission = 0) / enable RLC retransmission (e.g., maximum retransmission > 1). In some implementations, the conditions may include one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs; the percentage of remaining PDUs to be transmitted in the PDU set (or, for example, the percentage of remaining data to be transmitted in the PDU set if the PDUs in the PDU set can have different sizes); PSER (either for the PDU set of interest or averaged across multiple PDU sets); PDU set or PDU importance; UL buffer level (UL buffer level of the DRB of interest, or total UL buffer level); radio conditions (e.g., RSRP threshold, RLC retransmission count, HARQ NACK / ACK level, etc.); and / or explicit indications from the network (e.g., MAC CE).

[0131] The WTRU can begin sending PDCP PDUs via / through the default RLC AM settings. The WTRU can monitor conditions for enabling / disabling RLC retransmission. The WTRU can select the RLC AM retransmission count based on the monitored conditions / thresholds and current UE / network conditions (e.g., setting it to zero disables retransmission). In some implementations, if retransmission is disabled, the WTRU can clear buffered RLC AM packets awaiting ACK. The WTRU can send indications to the gNB / DU regarding enabling / disabling retransmission (e.g., RLC control PDU, RLC header, (MAC CE), etc.). The WTRU can be configured to disable retransmission-based RLF triggering (and subsequent re-establishment) for that RLC entity (but maximum retransmission-based RLF triggering on other RLC entities can still operate as in conventional techniques).

[0132] Some implementations include solutions related to conditional PDCP replication. For example, in some implementations, the PDCP and / or bearer are associated with multiple RLC entities associated with different carriers (e.g., CA case) or links (e.g., DC case). In some implementations, the WTRU is configured conditionally for when to replicate PDUs in the PDU set, based on PDU set characteristics (e.g., importance level), the current PDU set transmission status (e.g., thresholds considering TTL, PSER, UL buffer level, remaining percentage of PDUs to be transmitted, etc.), and the current WTRU and / or network conditions (e.g., radio conditions, buffer level).

[0133] In an exemplary implementation involving conditional PDCP replication, the WTRU may operate as follows: The WTRU may be configured to support CA or DC. The WTRU may receive a DRB (separate) configuration having one or more RLC entities, where each RLC is associated with a specific carrier (e.g., in the case of CA) or a specific link / cell group (e.g., in the case of DC). The WTRU can receive configuration of conditions for determining whether to replicate at least a subset of the DRB's PDU set, PDCP PDUs, default replication mode (on or off), and default path (e.g., RLC entity). These conditions may include one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs; the percentage of remaining PDUs to be transmitted in the PDU set (or, if the PDUs in the PDU set can have different sizes, the percentage of remaining data to be transmitted in the PDU set); PSER (e.g., the minimum percentage of PDUs in the PDU set expected to be successfully received at the receiving entity); the importance of the PDU set or PDUs; UL buffer levels (UL buffer levels on the primary path, UL buffer levels on alternative paths, total UL buffer levels, considering only the bearers of interest, etc.); and / or radio conditions (e.g., RSRP threshold, RLC retransmission count, HARQ NACK / ACK level, etc.).

[0134] In some implementations, if the default replication mode is ON, the WTRU can begin applying PDCP replication. The WTRU can monitor conditions used to enable and / or disable PDCP replication. The WTRU can determine the replication status, and if the determined replication status is ON, the WTRU sends the PDCP PDU through two RLC entities after processing it (e.g., applying security, adding headers, etc.). When PDCP replication is turned on and / or off, the WTRU can notify the network.

[0135] Some implementations include solutions related to conditional transmissions via a second path. For example, in some implementations, the PDCP and / or bearer are associated with multiple RLC entities, each associated with a different carrier (e.g., CA case) or link (e.g., DC case). In some implementations, the WTRU is configured to transmit the PDCP PDU via one RLC entity (e.g., the default path, a currently licensed path, etc.), and, for example, if certain conditions are not met (e.g., within a given time), the WTRU can transmit a copy of the PDU via another RLC entity (e.g., considering RLC status reception indicating ACK / NACK reception associated with the first transmission within a given time, buffer level on the first path, radio conditions on the first path / carrier, etc.). In some implementations, different conditions can be configured for different PDU set characteristics (e.g., importance level) and transmission states (e.g., TTL, percentage of PDUs transmitted, etc.). In some implementations, the WTRU can also be configured to switch the default path thereafter until the second set of conditions is met or a certain amount of time has elapsed.

[0136] In an exemplary implementation involving conditional RLC entity handover, the WTRU may operate as follows: The WTRU may be configured to support CA or DC. The WTRU may receive a configuration of a DRB (e.g., decoupled) having one or more RLC entities, where each RLC is associated with a specific carrier (e.g., in the case of CA) or a specific link and / or path (e.g., in the case of DC), and one of the RLC entities is set to default. The WTRU may receive a configuration of conditions for determining, for example, to retransmit a PDCP PDU via a second path after a given configured time length has elapsed since data transmission on the first path and before packet reception has been acknowledged, where the conditions may include one or more thresholds such as: receiving one or more NACKs (e.g., RLC status indicating NACK for this PDU, RLC status indicating NACK for other PDUs, etc.); HARQ retransmission count; buffer level on the first or second path; and / or radio link quality on the first and / or second paths.

[0137] In some implementations, the conditions may further depend on PDU set characteristics (e.g., importance level) and the current PDU set transmission status (e.g., TTL, percentage of remaining PDUs to be transmitted in the PDU set, etc.). In some implementations, after processing the PDCP PDU (e.g., applying security, adding headers, etc.), the WTRU may initially send packets via the first / default path.

[0138] In some implementations, if the configured time has elapsed and the packet reception has not yet been acknowledged, the WTRU can check the conditions for retransmitting the packet. If one or more conditions for retransmission via another path or other paths are met, the WTRU can send a copy of the PDCP PDU via the other path or other paths. The WTRU can be configured, for example, to stop attempting to retransmit the packet of interest via the first path after the WTRU has sent a copy of the PDCP PDU via the other path or other paths.

[0139] To address a variety of problems and / or implement a variety of solutions (as described above), various aspects have been envisioned. For example, as discussed herein, in some implementations, the network may include any one of base stations (e.g., gNB, TRP, RAN node, access node), core network functions (e.g., AMF, SMF, PCF, NEF), and application functions (e.g., edge server functions, remote server functions).

[0140] As discussed in this paper, in some implementations, a flow can correspond to either 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 interdependent and / or associated with one or more QoS requirements (e.g., latency, data rate, reliability, RTT latency)). Different flows that may originate from a common application / experience source and / or are intended to reach a common destination device / UE / WTRU or associated device / UE / WTRU group can be referred to as associated flows or related flows.

[0141] As discussed herein, in some implementations, a data unit can refer to any of the following: one or more frames (e.g., media, video and / or audio frames, stripes and / or segments), PDUs, PDU sets, data bursts, frame groups, PDU groups, PDU set groups, data burst groups, and / or bitstreams. In some implementations, such data units (which may be transmitted or received sequentially (e.g., one after another) or in parallel (e.g., via different channels / links / resources) by WTRUs) may or may not depend on each other.

[0142] As discussed herein, in some implementations, forwarding configuration can correspond to any of the following: radio bearers (e.g., data radio bearers (DRB), signaling radio bearers (SRB), transport radio bearers, PDU set bearers); logical channels (LCH), logical channel groups (LCG); configuration parameters in various layers within the AS protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, and / or other protocol layers (e.g., new protocol layers)); parameters associated with logical channel priority processing (LCP) (e.g., priority, PBR, BSD), BWP, carriers, radio links, and / or interfaces (e.g., Uu links, SL); and / or radio resources (e.g., one or more frequency, time, and / or spatial resource sets, such as symbols, time slots, subcarriers, resource elements, and / or beams). For example, in some implementations, radio resources can be associated with configuration grants (CG), dynamic grants (DG), and / or any other resource-granted or ungranted resources.

[0143] As discussed herein, in some implementations, a PDU set and / or its associated characteristics and / or attributes may refer to any one or more of the following: A PDU set may include one or more data units (e.g., PDUs) associated with a media unit or video frame and / or stripe. In some implementations, such data units within a PDU set or data burst may depend on each other at the application layer and / or lower layers (e.g., the AS layer). In some implementations, the attributes and / or characteristics of a PDU set may differ from each other in terms of, for example, the number of PDUs in the PDU set, payload size, correlation within the PDU set, importance and / or priority of data units, transmission status (e.g., the percentage of PDUs successfully sent / received) and / or effective data rate and / or effective reliability associated with the transmission.

[0144] In the example, such attributes associated with a PDU set may be visible at one or more lower layers (e.g., at PDCP, RLC, MAC, PHY sublayers / layers) and may be used to support additional actions (e.g., priority handling, mapping to LCH, multiplexing to one or more TBs, scheduling) based on any of the following: (1) Markings in the data unit. For example, such markings may include, for example, a sequence number, ID, index, timestamp, and / or time offset value (e.g., relative to a reference time) in the header of the data unit. In some implementations, such markings may be performed by an upper layer, any preceding sublayer / layer, and / or another device and / or WTRU. (2) Received indications, such as control PDUs (e.g., application, upper layer, and / or NAS layer indications, PDCP control PDUs, RLC control PDUs, MAC CEs, and / or DCI / UCIs). In some implementations, such indications may be received by the WTRU, for example, from an upper layer and / or preceding layer, from another device and / or WTRU (e.g., via SL), and / or from the network. (3) Mapping data units from the upper layer to configurations associated with the lower layer. For example, when a PDU is mapped to one or more radio bearers, logical channels (LCHs), TBs, and / or HARQ processes that can be configured to provide similar forwarding processing, the WTRU can have visibility of upper-layer attributes at the lower layer. (4) Tracking PDU attributes at any buffer associated with the sublayer, radio bearer, logical channel, or HARQ process. For example, the WTRU can track attributes associated with a PDU set based on any of the following: time elapsed since the first PDU in the PDU set was received, remaining time for PDUs in the PDU set to satisfy the PSDB, jitter between arrivals of one or more PDUs within and / or across the PDU set, percentage of remaining PDUs expected to be received in the PDU set, and / or payload size. (5) Restrictions associated with the sublayer, radio bearer, logical channel, and / or HARQ process to which data units of a PDU set can be mapped. For example, the WTRU can have visibility of the data unit and can determine appropriate actions based on configuration constraints associated with one or more sublayers, radio bearers, and / or LCHs to which the data unit can be mapped (e.g., performing priority processing for each LCP, performing mapping to restricted CG configurations, TB, HPI).

[0145] As discussed in this paper, in some implementations, a data burst can refer to data generated by an application over a period of time (e.g., a short time period), including PDUs from one or more PDU sets. Such attributes, associations, and interdependencies (e.g., within and / or between PDU sets) can include start and / or end indications for PDU sets / data bursts (e.g., via sequence number, start / end indication, timestamp), start and / or end times, duration, payload size, periodicity, importance and / or priority, and / or QoS (e.g., PSDB), which can be visible to the AS layer (e.g., with associated IDs) and / or can be processed at the AS layer to be aware of the association during data transmission in the UL and data reception in the DL.

[0146] As discussed herein, in some implementations, application and / or upper-layer importance and / or priority can refer to different PDUs in a PDU set, or all PDUs in a PDU set, being associated with different importance and / or priority values. In some implementations, such importance values ​​can correspond to, for example, spatial importance (e.g., the spatial location of video frames carried by the PDU and / or PDU set, where a PDU and / or PDU set carrying a FoV spatial location can be associated with higher spatial importance compared to a non-FoV spatial location) and / or temporal importance (e.g., the temporal sequence of video and / or application frames carried by the PDU and / or PDU set, where a PDU and / or PDU set carrying a basic video frame (e.g., an I-frame) can be associated with higher temporal importance compared to differential video frames (e.g., P-frames and / or B-frames). In some implementations, such importance values ​​can be visible to the AS layer during data transmission and reception.

[0147] As discussed herein, in some implementations, QoS and / or data streams may refer to the application's PDUs and / or PDU sets being encoded by the application and / or delivered to the WTRU (in the UL) or network (in the DL) via one or more QoS and / or data streams. In some implementations, different QoS streams carrying PDUs and / or PDU sets associated with the XR application and / or experience may be visible to the AS layer and / or may be processed at the AS layer during data transmission and reception to perceive this association.

[0148] As discussed in this paper, in some implementations, service flow characteristics and PDU set-level QoS requirements can be applied: (1) PDU set delay budget (PSDB) can refer to the time between receiving the first PDU (e.g., at the UPF in DL, at the WTRU in UL) and the last arriving PDU in the PDU set successfully delivered (e.g., at the WTRU in DL, at the UPF in UL). In some implementations, PSDB is an optional parameter and, if provided, can replace PDB. (2) PDU set overall processing indication (PSIHI) can indicate whether all PDUs in the PDU set are required by the application layer for using the PDU set. (3) PDU set error rate (PSER) can refer to the upper limit of the non-congestion-related PDU set loss rate between the RAN and WTRU. (4) Jitter can refer to the variation relative to the expected time instance during which one or more data units can be received or transmitted. For example, jitter can refer to the variation relative to the periodic time instance for a set of data units expected to be received periodically at different periodic time instances (e.g., for data units received 1 millisecond before or 2 milliseconds after the expected time instance T, the jitter range is T2 – T1). Jitter can refer to instantaneous values ​​or statistical values ​​(e.g., mean, variance, standard deviation, maximum / minimum). (5) Remaining delay can refer to the remaining time length before receiving or transmitting one or more PDUs in the PDU set before the PSDB. Remaining delay can also be referred to as the time to lifetime (TTL) associated with the PDU set.

[0149] As discussed herein, in some implementations, a multi-PUSCH CG may correspond to one or more configuration resources or configuration authorization (CG) configurations, where each CG configuration may include a set of consecutive or discontinuous PUSCH opportunities per slot and / or per CG period. In the examples, a multi-PUSCH CG may include one or more CG periods (e.g., where each CG period may repeat periodically with some periodicity value); CG periods in a multi-PUSCH CG may include one or more consecutive or discontinuous slots; slots in a CG period of a multi-PUSCH CG may include one or more consecutive or discontinuous PUSCH opportunities; and / or PUSCH opportunities in slots and / or CG periods of a multi-PUSCH CG may include one or more consecutive or discontinuous symbols having a certain symbol length (e.g., time-domain resources). In some implementations, PUSCH opportunities may include one or more resource blocks or groups of resource blocks in the frequency domain.

[0150] As discussed herein, in some modes (e.g., three RLC entities: one RLC AM, one RLC UM, and one RLC TM), WTRU is configured with associated conditions. In implementation, PUSCH usage can refer to the number, location, positioning, or timing of one or more PUSCH events in one or more slots or periods associated with one or more multi-PUSCHCG configurations. As discussed herein, in some implementations, the terms path and carrier can be used interchangeably. As discussed herein, in some implementations, the terms group and PDU can be used interchangeably.

[0151] Some implementations include solutions related to conditional RLC entity handover. For example, in some implementations, a PDCP entity is associated with multiple RLC entities with different modes in order to push the PDCP PDU in the PDU set to which RLC entity based on PDU set characteristics (e.g., importance level) and the current PDU set transmission status (e.g., thresholds considering TTL, PSER, UL buffer level, remaining percentage of PDU set to be transmitted, etc.) and current WTRU / network conditions (e.g., radio conditions, buffer level).

[0152] In an exemplary implementation involving conditional RLC entity handover, the WTRU may operate as follows: The WTRU may receive a DRB / PDCP configuration associated with two or more associated RLC entities (e.g., three RLC entities: one RLC AM, one RLC UM, and one RLC TM) having different operating modes, wherein one of the RLC entities is configured as the primary / default RLC entity. In some implementations, different RLC entities may share the same logical channel or have separate logical channels.

[0153] The WTRU can receive configuration of conditions for determining the RLC entity of PDUs in the PDU set used to transmit the DRB, wherein the conditions may include one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs; the percentage of remaining PDUs to be transmitted in the PDU set (or the percentage of remaining data to be transmitted in the PDU set if the PDUs in the PDU set may have different sizes); PSER (either for the PDU set of interest or averaged across multiple PDU sets); PDU set importance or PDU importance; UL buffer level (UL buffer level of the DRB of interest, or total UL buffer level); radio conditions (e.g., RSRP threshold, RLC retransmission count, HARQ NACK / ACK level, etc.); and / or explicit indications from the network.

[0154] The WTRU can be configured to determine the default / initial RLC entity (e.g., based on PDU set characteristics). The WTRU can begin sending PDCP PDUs via / through the default RLC entity. The WTRU can monitor the conditions for the RLC entity to be used. This can be done continuously (e.g., for each PDCP PDU to be sent) or periodically (e.g., the period can be defined based on time, the number / percentage of PDUs / bytes sent in the PDU set, the number / percentage of PSDBs already passed, etc.). The WTRU can also receive explicit indications from the network (e.g., MAC CE, RLC control and / or status PDUs, etc.) indicating the RLC entity to be used thereafter.

[0155] The WTRU can select an RLC entity based on monitored conditions / thresholds and current WTRU and / or network conditions. For example, the WTRU can send handover instructions to the gNB and / or DU (e.g., in cases where a handover to / from a PDU set is in progress). The WTRU can send PDCPPDUs through the identified RLC entity (e.g., and the associated logical channel).

[0156] Some implementations include solutions related to WTRUs configured with PDCP entities and multiple RLC entities per PDCP. In some implementations, each PDCP entity can be associated with multiple RLC entities, but this is only done in CA or DC scenarios, where different RLC entities are associated with and / or limited to only one carrier (e.g., in CA) or one link, path, and / or destination node (e.g., in DC). This is because the reason for configuring multiple RLC entities is to utilize link and / or carrier diversity to achieve higher reliability (e.g., in the case of replication, for both CA and DC scenarios) and / or higher throughput (e.g., in the case of split bearer path switching methods (DC scenario), as in CA scenario, multiple RLC entities may not be needed to utilize throughput from multiple carriers). In some such cases, the RLC patterns of the two legs can be assumed to be the same (because the QoS requirements of the bearer may not change regardless of whether split bearer and / or replication are used).

[0157] In some implementations, the WTRU can be configured with a PDCP entity associated with multiple RLC entities, where each RLC entity is configured to operate in a different mode. For example, in some implementations, a first RLC entity associated with the PDCP entity can be configured in RLC AM mode, while a second RLC entity can be configured in RLC TM mode. In some implementations, the WTRU is configured in this manner even if it is not operating in a CA or DC. In some implementations, different RLC entities can use separate logical channels. In some implementations, different RLC entities can use a common logical channel.

[0158] Some implementations include solutions related to WTRUs configured with conditions for determining the initial and / or default RLC entities. In some implementations, one of the RLC entities is explicitly configured by the network to the initial / default mode (e.g., RLCAM entity, RLC UM entity, or RLC TM entity).

[0159] In some implementations, the WTRU may determine the initial and / or default mode, for example, based on one or more characteristics of the PDU set associated with the PDCP entity of interest. For instance, in some implementations, if the WTRU receives the first PDU of the PDU set and has PDU set information (e.g., received with the first PDU or prior from the application layer), such as the PSDB or importance level, the WTRU will use this information to determine whether to begin transmission with an RLC AM, RLC UM, or RLC TM entity. For example, in some implementations, for a first subset of PDUs in the PDU set, the WTRU may determine to begin transmission with an RLC AM entity, while for a second subset of PDUs, the WTRU may determine to continue using the same RLC AM entity or change / switch to an RLC TM entity. In some implementations, this determination to begin transmission with an RLC entity configured with a specific mode may be based on PDU set information and / or characteristics. For example, if the PSDB is greater than a certain configured threshold, it starts with an AM entity; if the PDSB is less than a certain configured threshold, it starts with a TM entity; if the importance level is higher than a certain configured threshold, it starts with an AM entity; if the importance level is lower than a certain configured threshold, it starts with a TM entity; if the PDU set is a PSIHI PDU set, it starts with an AM entity; if the PDU set is expected to have PDUs greater than a certain configured threshold, it starts with a UM and / or AM entity (e.g., with allowed segmentation); and so on.

[0160] In some implementations, WTRU can determine the initial and / or default mode based on the current WTRU conditions. For example: if the UL buffer level is above a certain threshold, it starts with a TM and / or UM entity; if the UL buffer level is below a certain threshold, it starts with an AM entity; if the WTRU overheat level is above a certain threshold, it starts with a TM / UM entity; if the WTRU overheat level is below a certain threshold, it starts with an AM entity; if the WTRU battery level is above a certain threshold, it starts with an AM entity; if the WTRU battery level is below a certain threshold, it starts with a TM / UM entity; if the experienced / historical / recent UL throughput is greater than a certain threshold, it starts with an AM entity; if the experienced / historical / recent UL throughput is below a certain threshold, it starts with a TM and / or UM entity; and so on.

[0161] In some implementations, the WTRU is configured to determine the initial RLC entity to use based on one or more radio conditions. For example, if the radio quality (e.g., RSRP / RSRQ) is below a configured threshold, the AM entity is used; if the radio quality (e.g., RSRP / RSRQ) is above a configured threshold, the TM / UM entity is used; and so on. In some implementations, the WTRU may determine the initial and / or default RLC entity based on the WTRU implementation.

[0162] Some implementations include WTRU-related solutions configured with conditions for determining the current RLC entity that depend on the characteristics of the PDU set.

[0163] In some implementations, WTRU is configured to determine the RLC entity to use based on one or more characteristics of the PDU set associated with the PDCP entity of interest. For example: if the PSDB is greater than a threshold (e.g., a configured threshold), an AM entity is used; if the PDSB is less than a threshold (e.g., a configured threshold), a TM entity is used; if the importance level is higher than a threshold (e.g., a configured threshold), an AM entity is used; if the importance level is lower than a threshold (e.g., a configured threshold), a TM entity is used; if the PDU set is a PSIHI PDU set, an AM entity is used; if the PDU set is expected to have PDUs greater than a threshold (e.g., a configured threshold), a UM / AM entity (i.e., allowing segmentation) is used; and so on.

[0164] In some implementations, WTRU is configured to determine the RLC entity to use based on the current PDU set transmission status. For example: if the TTL is greater than a threshold (e.g., a configured threshold), the AM entity is used; if the TTL is less than a threshold (e.g., a configured threshold), the TM entity is used; if the remaining number / percentage of PDUs in the PDU set (or the remaining actual amount / percentage of the total PDU set data to be transmitted) is less than a threshold (e.g., a configured threshold), the AM entity is used; and so on.

[0165] In some implementations, WTRU is configured to determine the RLC entity to use based on one or more WTRU conditions. For example: if the UL buffer level is above a threshold (e.g., a configured threshold), the TM / UM entity is used; if the UL buffer level is below a threshold (e.g., a configured threshold), the AM entity is used; if the WTRU overheat level is above a threshold (e.g., a configured threshold), the TM / UM entity is used; if the WTRU overheat level is below a threshold (e.g., a configured threshold), the AM entity is used; if the WTRU battery level is above a threshold (e.g., a configured threshold), the AM entity is used; if the WTRU battery level is below a threshold (e.g., a configured threshold), the TM / UM entity is used; if experienced / historical / recent UL throughput is greater than a threshold (e.g., a configured threshold), the AM entity is used; if experienced / historical / recent UL throughput is less than a threshold (e.g., a configured threshold), the TM / UM entity is used; and so on.

[0166] In some implementations, the WTRU is configured to determine the RLC entity to use based on one or more radio conditions. For example: if the radio quality (e.g., RSRP / RSRQ, etc.) is below a threshold (e.g., a configured threshold), the AM entity is used; if the radio quality (e.g., RSRP / RSRQ, etc.) is above a threshold (e.g., a configured threshold), the TM / UM entity is used; if the number of RLC retransmissions (when using the RLC AM entity) is below a level (e.g., a threshold level) within a given time, the TM / UM entity is used; if the number of RLC retransmissions (of other RLC entities of other PDCP entities) is above a level (e.g., a threshold level) within a given time, the AM entity is used; if the number of HARQ retransmissions (or the percentage of HARQ retransmissions relative to new HARQ transmissions) is below a level (e.g., a threshold level) within a given time, the TM / UM entity is used; and / or if the number of HARQ retransmissions (or the percentage of HARQ retransmissions relative to new HARQ transmissions) is above a level (e.g., a threshold level) within a given time, the AM entity is used, and so on.

[0167] In some implementations, the WTRU continuously checks the conditions for switching RLC entities (e.g., for each PDCP PDU or one or more subsets of PDUs in a set of PDUs to be sent, the WTRU checks the conditions to determine the RLC entity to be used for that RLC entity). In some implementations, the WTRU checks the conditions for switching RLC entities periodically (e.g., at a configured period (e.g., period 0 starts when the first PDU in the PDU set is sent, period 1 starts after period 0+ periods, etc., and the WTRU uses the same RLC entity within a period, etc.)). In some implementations, the period can be a time length or the number of PDUs and / or bytes sent, etc. In some implementations, the WTRU can receive explicit instructions from the network regarding which RLC entity to use.

[0168] Some implementations include solutions related to preventing frequent handovers. For example, as mentioned above, the WTRU can be configured with a trigger time (TTT) to perform the handover. For instance, in some implementations, the trigger condition must meet at least the TTT before the condition is considered satisfied. In some implementations, a common TTT value can be configured for all conditions, or each condition can have a separate TTT value.

[0169] In some implementations, the WTRU can be further configured with a disable timer that indicates how long the WTRU should wait before performing another RLC handover. In some implementations, the disable timer can be a duration value, or it can be based on data size (e.g., number of bytes, number of RLC / PDCP packets to be sent, etc., which must be sent in an RLC entity before a handover can be performed, etc.), and so on.

[0170] In some implementations, the WTRU can be configured to override the disable timer under certain conditions. For example, in some implementations, when using an RLC AM entity and without switching the RLC entity's disable timer, if the TTL drops below a certain value and / or percentage, and the remaining PDUs to be transmitted in the PDU set exceed a certain percentage, the WTRU can ignore and / or stop the disable timer and can switch to RLC TM mode.

[0171] Some implementations include solutions related to the WTRU sending indications to the network. For example, in some implementations, the WTRU may send an indication to the network when determining the initial and / or default RLC entity, for example, based on any of the solutions described above (or, for example, a WTRU-based implementation). In some implementations, this indication regarding the selected RLC entity may be implicit (e.g., the network may determine the selected RLC entity based on which RLC entity the first PDU in the PDU set was received) or explicit (e.g., the WTRU may send an indication, such as in the MAC CE, RLC control PDU, RLC header, etc.). In some implementations, the latter helps the network determine the selected RLC entity even if the RLC entities share the same logical channel and / or the RLC entity handover occurs before the first packet arrives at the network (e.g., the first packet is delayed during RLC AM retransmission, while the second packet is sent via TM mode and received before the first packet).

[0172] In some implementations, the WTRU sends an indication to the network after determining the switching RLC entity based on any of the solutions described above (or based on the WTRU implementation). In some implementations, this indication regarding the selected RLC entity can be implicit (e.g., the network determines the selected RLC entity based on the determination that data has begun arriving via an RLC entity different from the one from which the previously received packets were received) or explicit (e.g., the WTRU sends an indication, such as in the MAC CE, RLC control PDU, RLC header, etc.). In some implementations, the latter helps the network determine the selected RLC entity even if the RLC entities share the same logical channel and / or the switching of the RLC entity occurs before the last packet sent using the previous RLC entity arrives at the network (e.g., a packet with SN x is delayed during RLC AM retransmission in the RLC entity, while SN x+1 is sent and correctly received via TM mode. If the network receives SN x after SN x+1, it might incorrectly determine that a second handover back to AM mode has occurred if only an implicit indication is used).

[0173] Some implementations include solutions related to the deep learning (DL) aspect. Some of the exemplary implementations described above are for the UL (e.g., how the WTRU dynamically determines RLC entities and how it notifies the network), and in some implementations, network behavior is undefined and / or left to the network implementation. Some implementations include RLC receiver-side behavior at the WTRU to support similar dynamic handover of RLC entities in the DL.

[0174] In some implementations, the WTRU can be configured to receive an indication from the network to switch the receive RLC entity associated with the PDCP entity. In some implementations, this indication can be implicit (e.g., determining that data has been received through an RLC entity and associated logical channel that are different from the RLC entity and logical channel used for one or more previous packets) or explicit (e.g., MAC CE, RLC control PDU, flags in the RLC header, etc.).

[0175] In some implementations, after determining that the receiving RLC entity has switched from the AM RLC entity to the UM / TM, the WTRU can be configured to reset some state variables and counters of the RLC receiving window that is switching from / to it (e.g., initializing the left edge of the receiving window to the first SN (e.g., 0), setting the retransmission count to 0, resetting all timers (e.g., disable / polling timers), etc.).

[0176] In some implementations, the WTRU may determine to retain the serial number (SN) of the PDUs associated with the previous RLC entity after switching to a new RLC entity. In some implementations, the WTRU may reset a timer, for example, when switching to a new RLC entity. In some implementations, this retention of the SN of the previous RLC entity may be to help avoid interrupting processes at the receiving entity (e.g., PDU reordering at the receiving PDCP entity).

[0177] Some implementations include solutions related to other aspects. In some of the exemplary implementations described above, the buffer level can be, for example, the total buffer level or the buffer level of certain bearers (e.g., bearers with certain QoS profiles, such as those bearers with more stringent latency and / or bit rate requirements than a certain level or compared to the bearer configuration of the PDCP entity of interest).

[0178] In some implementations, such as those described above, the WTRU can be configured with any combination of the aforementioned conditions. For example, in some implementations, if the TTL is below threshold 1 and the radio quality is above threshold 2, and the PDU set has an importance level higher than x, then an RLC AM entity is used, and so on.

[0179] In some implementations, such as those described above, WTRU can be configured to consider not only the current value, but also the average and / or filtered value over a configured time window, or the rate of change of the value, or the threshold can be based on other statistical measures (e.g., the average, standard deviation, minimum / maximum value, etc. over the evaluation period).

[0180] In some implementations, such as those described above, it is assumed that all PDUs in a PDU set have the same importance level (i.e., each PDU set has one importance level). However, in some implementations, such a solution is suitable for situations where different PDUs in a PDU set can have different importance levels. In some implementations, in such cases, RLC entity determination is performed at the PDU level.

[0181] In some implementations, RLC entity switching can take effect immediately. For example, if switching from AM to UM / TM, packets awaiting retransmission can be cleared from the RLC AM buffer, or they will be retransmitted once via TM / UM (e.g., the AM entity notifies the PDCP, and the PDCP pushes the PDCP packets of interest to the TM entity).

[0182] In some implementations, RLC entity handover only applies to newly received PDCP packets after the RLC entity handover (e.g., if the handover is determined on a packet-by-packet basis, then it includes the current PDCP packets). In such cases, in some implementations, there may be handover cycles using multiple RLC entities simultaneously (e.g., RLC AM is used to complete the transmission of packets awaiting retransmission, while new packets are sent via RLC TM).

[0183] In some implementations, multiple RLC entities can be active simultaneously. For example, in some implementations, during a handover cycle, a process waits for packets already transmitted in one RLC entity to be correctly transmitted while new packets are transmitted through another RLC entity. In some implementations, RLC entities are selected based on PDU importance (e.g., if PDUs within a PDU set can have different importance levels), and PDUs with higher importance than a certain level are sent through the RLC AM entity, while PDUs with lower importance are sent through the RLC TM entity, and so on.

[0184] Figure 5 This is a flowchart illustrating an exemplary process for wireless communication performed by a WTRU, including conditional RLC entity switching, such as discussed further above. At 502, the WTRU receives PDCP configurations associated with multiple RLC entities. At 504, the WTRU receives configurations for determining which RLC entity to transmit data through. At 506, the WTRU monitors the conditions. At 508, data is transmitted through one RLC entity based on the conditions. Other implementations include additional steps, fewer steps, and / or different steps, such as those described above.

[0185] Some implementations include solutions associated with adaptive RLC entities. For example, in some implementations, the DRB and / or PDCP are associated with an RLC AM entity that dynamically adapts its behavior and / or operation (e.g., enabling / disabling retransmissions) based on PDU set characteristics (e.g., importance level) and the current PDU set transmission status (e.g., thresholds considering TTL, PSER, UL buffer level, remaining percentage of PDU set to be transmitted, etc.) and current WTRU and / or network conditions (e.g., radio conditions, buffer level).

[0186] In an exemplary implementation involving an adaptive RLC entity, the WTRU may operate as follows: The WTRU may receive the configuration of the DRB and the associated RLC AM entity, which has a default maximum retransmission count value.

[0187] The WTRU can receive configurations for determining whether to disable (e.g., maximum retransmission = 0) and / or enable RLC retransmission (e.g., maximum retransmission > 1). In some implementations, the conditions may include one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs; the percentage of remaining PDUs to be transmitted in the PDU set (or, if the PDUs in the PDU set can have different sizes, the percentage of remaining data to be transmitted in the PDU set); PSER (either for the PDU set of interest or averaged across multiple PDU sets); PDU set or PDU importance; UL buffer level (UL buffer level of the DRB of interest, or total UL buffer level); radio conditions (e.g., RSRP threshold, RLC retransmission count, HARQ NACK / ACK level, etc.); and / or explicit indications from the network (e.g., MAC CE).

[0188] The WTRU can begin sending PDCP PDUs via / through the default RLC AM settings. The WTRU can receive monitoring conditions for enabling / disabling RLC retransmission. The WTRU can select the RLC AM retransmission count based on the monitored conditions / thresholds and current UE / network conditions (e.g., setting it to zero disables retransmission). In some implementations, if retransmission is disabled, the WTRU can clear the buffered RLC AM packets awaiting ACK. The WTRU can send instructions to the gNB / DU regarding disabling / enabling retransmission: for example, RLC control PDUs, RLC headers, (MAC CE), etc. The WTRU can be configured to disable, for example, RLF triggering based on the number of retransmissions (and subsequent retransmissions) for that RLC entity (e.g., RLF triggering based on the maximum retransmission count on other RLC entities can still operate as in conventional techniques).

[0189] Some implementations include solutions related to the RLC entity that obtains PDU set information. In some implementations, the PDCP notifies the RLC entity of the PDU set information (e.g., explicitly or as part of the PDCP header information). This information may include static PDU set characteristics (e.g., PSDB, number of PDUs, size, PSIHI, and / or importance level) or dynamic PDU set characteristics (e.g., TTL). In some implementations, this is facilitated by the PDCP notifying the WTRU's RRC and the RRC configuring the RLC entity.

[0190] In some implementations, the network uses PDU set information to configure RLC entities (e.g., the WTRU may have previously transmitted the PDU set information to the gNB and / or DU, or the network may have received the information through other means, such as packet inspection, communication with the application server, etc.).

[0191] Some implementations include solutions associated with RLC AM entities that have adaptive retransmission behavior. In some implementations (e.g., in legacy NR / LTE), the RLC AM entity is associated with a certain SN space (e.g., 12 or 18 bits) and a maximum number of retransmissions. If an RLC packet is not received correctly (e.g., as determined by the RLC state PDU received from a peer RLC entity), in some implementations, the packet can be retransmitted. If the packet is still not received after the maximum number of retransmissions, in some implementations, the WTRU will determine that the radio link is not good enough and declare a Radio Link Failure (RLF), which may lead to connection re-establishment. In some implementations, the maximum number of retransmissions is a semi-static RLC configuration parameter. In some implementations, this parameter can be set between 1 and 32 (e.g., if set to 1, at least one retransmission is allowed before declaring an RLF; if set to 32, 32 retransmissions are allowed, etc.).

[0192] In some implementations, the WTRU can be configured with an RLC AM entity, which can be configured with a maximum retransmission count of 0, indicating that although the RLC entity operates in AM mode, it will not perform retransmissions. In some implementations, if the RLC AM entity is configured with a maximum retransmission count of 0, it will advance the RLC transmission window as if the packet had been correctly received at the receiving end (e.g., as if an RLC status PDU acknowledging receipt of the packet had been received). That is, the packet is pushed to the MAC immediately after being received from the RLC.

[0193] In some implementations, the WTRU can be configured with an RLC AM entity, which can be configured with a maximum retransmission count greater than 1. After a certain number of allowed retransmissions, it can clear the packets of interest and advance the RLC transmission window as if the packets were correctly received at the receiving end (i.e., as if an RLC status PDU acknowledging receipt of the packet was received). In some implementations, the WTRU can be configured with an RLC AM entity where the maximum retransmission count is variable from one RLC packet to another (e.g., the first packet may have a maximum retransmission count of 1, the second packet may have a maximum retransmission count of 3, and so on). In some implementations, the maximum retransmission count is common to all RLC packets in the transmission buffer. For example, if the maximum retransmission count is 3 and there is a packet that is already in its second retransmission, if the maximum retransmission count is changed to 2, the WTRU can remove the packet from the retransmission list as if it had just received a status PDU indicating correct reception.

[0194] Some implementations include solutions related to actions when the maximum retransmission count is reached for a given RLC packet. In some implementations, if the retransmission count is set to 0, the WTRU disables retransmission count-based RLF triggering for that RLC entity.

[0195] In some implementations, the WTRU can be configured to disable RLF triggering for the RLC entity when the maximum retransmission count for a packet is reached, even if the retransmission count is higher than 0. That is, as described in the solutions above, the WTRU can behave as if the packet was correctly received and its retransmission buffer was emptied. In some implementations, the WTRU can be configured to log information about the number of RLC packets that have reached the maximum retransmission count. For example, this could be a log stored at the WTRU containing information such as the SN of the packet of interest, timestamp, and the radio conditions at the time. Alternatively, the WTRU can maintain statistics about such events (e.g., the number of occurrences, frequency of occurrence, percentage of packets experiencing the event, etc.). In some implementations, the WTRU can be configured to send the logged information when requested by the network. In some implementations, the WTRU can be configured to send the logged information if certain conditions are met (e.g., periodically, when the number of occurrences since the last report exceeds a certain level, when the number of occurrences within a given time period exceeds a certain level, when the report size is greater than a certain value, etc.).

[0196] In some implementations, the WTRU can be configured to send an indication of its recorded information (e.g., based on conditions similar to those described above for sending reports). In some implementations, the WTRU can be configured with conditions, such as triggering an RLF and subsequent retransmission if it cannot send more than a certain number of packets before reaching the retransmission count. In some implementations, this can be constrained by a time duration (e.g., failing to correctly send a certain number of packets within the retransmission count within a given duration). In some implementations, reaching the maximum retransmission and clearing the packets may not be counted as a failure event if a status PDU indicating a successful last retransmission is received later. In some implementations, disabling RLF triggering can be packet-specific. For example, for certain packets (e.g., packets containing very important PDCP PDUs), in some implementations, an RLF can still be triggered if the WTRU fails to send the packet after attempting the maximum allowed retransmissions for that packet.

[0197] Some implementations include solutions related to WTRUs configured with conditions for determining whether to enable and / or disable retransmissions and the number of retransmissions. In some implementations, the WTRU is configured to determine, for example, whether (and at most how many times) to apply retransmissions to packets of the RLC entity based on one or more characteristics of the PDU set associated with the RLC entity of interest. For example: if PSDB is less than threshold 1, then RLC retransmission is disabled; if PSDB is between threshold 1 and threshold 2, then the maximum retransmission count is set to 1; if PSDB is between threshold 2 and threshold 3, then the maximum retransmission count is set to 2, and so on; if the importance level is below threshold 1, then RLC retransmission is disabled; if the importance level is between threshold 1 and threshold 2, then the maximum retransmission count is set to 1; if the importance level is between threshold 2 and threshold 3, then the maximum retransmission count is set to 2; if the importance level is above threshold 3, then the maximum retransmission count is set to 3, and so on; if the PDU set is a PSIHI PDU set, then RLC retransmission is always enabled; if the RLC PDU size is greater than threshold 1, then RLC retransmission is disabled, and so on.

[0198] In some implementations, the WTRU is configured to determine whether (and at most how many times) to apply retransmissions to packets of the RLC entity based on the transmission status of the PDU set. For example: (1) If the TTL is below a certain configured threshold, retransmission is disabled; if the TTL is between threshold 1 and threshold 2, the maximum retransmission count is set to 1; if the TTL is between threshold 2 and threshold 3, the maximum retransmission count is set to 2, and so on. (2) If the number and / or percentage of remaining packets in the PDU set is higher than a certain configured threshold, retransmission is disabled; if the number and / or percentage of remaining packets in the PDU set is between threshold 1 and threshold 2, the maximum retransmission count is set to 1; if the number and / or percentage of remaining packets in the PDU set is between threshold 2 and threshold 3, the maximum retransmission count is set to 2; if the number and / or percentage of remaining packets in the PDU set is less than threshold 3, it is set to 3, and so on.

[0199] In some implementations, WTRU is configured to determine whether (and at most how many times) to apply retransmissions to packets of RLC entities based on one or more WTRU conditions. For example: (1) If the UL buffer level is above a certain threshold, retransmission is disabled; if the UL buffer level is between threshold 1 and threshold 2, the maximum retransmission count is set to 1; if the UL buffer level is between threshold 2 and threshold 3, the maximum retransmission count is set to 2, and so on. (2) If experienced, historical, and / or recent UL throughput is below a certain threshold, retransmission is disabled; if experienced, historical, and / or recent UL throughput is between threshold 1 and threshold 2, the maximum retransmission count is set to 1; if experienced, historical, and / or recent UL throughput is between threshold 2 and threshold 3, the maximum retransmission count is set to 2, and so on.

[0200] In some implementations, the WTRU is configured to determine whether (and at most how many times) to apply retransmissions to packets of an RLC entity based on one or more WTRU conditions. For example, retransmissions are disabled if the radio quality (e.g., RSRP / RSRQ, etc.) is above a certain threshold (e.g., a configured threshold); the maximum retransmission count is set to 1 if the radio quality is between threshold 1 and threshold 2; the maximum retransmission count is set to 2 if the radio quality is between threshold 2 and threshold 3, and so on. In some implementations, the WTRU continuously checks the conditions used to determine the maximum RLC retransmission count (e.g., for each RLC PDU to be transmitted for the first time, the WTRU checks the conditions to determine the maximum retransmission count to be associated with that RLC packet).

[0201] In some implementations, the WTRU periodically (e.g., at a configured period (e.g., period 0 starts when the first RLC PDU in the PDU set is sent, period 1 starts after period 0+ periods, etc., and the WTRU uses the same maximum retransmission count value within a period, etc.)) checks the conditions used to determine the maximum RLC retransmission count. In some implementations, the period can be a time length or the number of PDUs / bytes sent, etc. In some implementations, the WTRU can receive explicit indication from the network about which maximum retransmission count to apply (e.g., in the MAC CE, RLC control PDU, information in the RLC packet header, etc.).

[0202] Some implementations include solutions related to the WTRU sending an indication to the network based on changes in the maximum retransmission count. In some implementations, the WTRU sends an indication to the network (e.g., in the MAC CE, RLC control PDU, RLC header, etc.) after changing the maximum retransmission count (e.g., disabling retransmission or triggering an RLF based on reaching the maximum retransmission count) (e.g., based on any of the solutions mentioned above (or the WTRU implementation, etc.)). In some implementations, this can help the network advance the receive RLC window size (e.g., if it is waiting for some packet retransmissions). In some implementations, the indication can be a simple flag (e.g., retransmission disabled or enabled), or it can contain detailed information (e.g., the SN at / when retransmission is disabled / enabled in the RLC PDU, the new maximum retransmission count, etc.).

[0203] Some implementations include solutions related to the deep learning (DL) aspect. For example, some of the solutions mentioned above involve the UL (e.g., how the WTRU dynamically determines the RLC entity and how it notifies the network), and network behavior is undefined (because it is usually left to the network implementation). In some implementations, if similar dynamic switching of RLC entities is supported in the DL, the RLC receiver-side behavior is provided at the WTRU.

[0204] In some implementations, the WTRU can be configured to receive from the network an indication that retransmission of RLC entities is disabled and / or enabled (e.g., MAC CE, RLC control PDU, information in the RLC packet header, RRC message, etc.), and based on this indication, the WTRU can advance the receive window accordingly (e.g., if there are lost packets that the WTRU is waiting for the network to retransmit, it can advance the receive window as if those packets were received after receiving the indication that retransmission is now disabled).

[0205] In some implementations, the WTRU may receive an indication, for example, when the peer RLC sending entity at the network disables retransmission, to enable out-of-order delivery for the PDCP entity associated with the RLC entity of interest (if not already configured). In some implementations, this indication may be the same as the one from the network indicating that RLC retransmission is disabled, or it may be a separate indication (e.g., a PDCP control PDU sent from the network).

[0206] In some implementations, the WTRU may receive an indication, for example, when the peer RLC sending entity at the network enables retransmission, to disable in-order delivery for the PDCP entity associated with the RLC entity of interest (if not already configured). In some implementations, this indication may be the same as the one from the network indicating RLC retransmission enablement, or it may be a separate indication (e.g., a PDCP control PDU sent from the network).

[0207] Some implementations include solutions related to other aspects. For example, in some of the above, the buffer level can be the total buffer level or the buffer level of certain bearers (e.g., bearers with certain QoS profiles, such as those with more stringent latency / bitrate requirements than a certain level or compared to the bearer configuration of the PDCP entity of interest, etc.).

[0208] In some implementations, WTRU can be configured with any combination of the above conditions. For example, retransmission is enabled if the TTL is above threshold 1, the radio quality is below threshold 2, and the PDU set has an importance level higher than x, and so on. In some implementations, WTRU can be configured to consider not only the current value, but also the average and / or filtered value over a configured time window, or the rate of change of the value, or the threshold can be based on any other statistical metric (e.g., the average, standard deviation, minimum / maximum value, etc. over the evaluation period).

[0209] In some of the above implementations, it is assumed that all PDUs in a PDU set have the same importance level (i.e., each PDU set has one importance level). However, some implementations are suitable for situations where different PDUs in a PDU set can have different importance levels. In some implementations, in such cases, it may be necessary to determine the maximum RLC retransmission count value at the PDU level.

[0210] Some implementations include alternative solutions. For example, in some implementations mentioned above, it can be assumed that the RLC entity always operates in RLC AM mode and the maximum retransmission count is determined dynamically (e.g., at the packet level, for all packets in the current transmission or retransmission buffer, for all packets within a given time length, etc.).

[0211] In some implementations, the WTRU may be configured with an RLC entity that is configured to operate in multiple modes (e.g., RLC AM, UM, or TM), where the mode is determined based on any conditions used in the exemplary implementations described above to determine whether retransmission is enabled and, if so, what maximum retransmission count is used. In some implementations, this may be based on one or more of the following: PDU set characteristics of the PDUs in the PDU set (e.g., importance level, PSDB, PSIHI, etc.); the current state of the PDU set transmission (e.g., TTL, percentage / number of remaining PDUs to be transmitted in the PDU set, PSER, etc.); current WTRU conditions (e.g., UL buffer level, throughput, etc.); current network conditions (e.g., radio conditions, number and / or percentage of retransmissions by RLC or lower layers, etc.); and / or explicit indications from the network.

[0212] In some implementations, the WTRU can be configured to send an indication whenever it changes and / or switches the RLC mode of a given RLC entity. In some implementations, this can be an explicit indication (e.g., MAC CE, RLC PDU header, RLC control PDU, etc.).

[0213] In some implementations, a change in RLC mode may only affect the new RLC PDU, or in others, it may affect all packets currently in the RLC transmission or retransmission window (e.g., if the mode switches from AM to TM, the WTRU may clear all packets waiting for ACK in the receive buffer, etc.).

[0214] In some implementations, a change in RLC mode can cause the WTRU to start or stop processing and / or apply a serial number (SN) to packets (e.g., stopping SN application when switching from AM to TM). In cases where multiple handovers are possible (e.g., starting in AM due to poor radio conditions, switching to TM when radio conditions improve, switching back to AM if radio conditions worsen again, etc.), the WTRU can be configured to restart sequence numbering and / or continue numbering from the last sequence number used when the RLC entity was previously in AM mode.

[0215] Figure 6This is a flowchart illustrating an exemplary process for wireless communication (e.g., performed by a WTRU), which includes an adaptive RLC entity, such as those discussed further above. At 602, the WTRU receives the configuration of the RLC entity. At 604, the WTRU receives the configuration for determining whether to enable or disable RLC retransmission. At 606, the WTRU receives data and monitors the conditions. At 608, the WTRU retransmits the data via the RLC entity based on the conditions. Other implementations include additional steps, fewer steps, and / or different steps, such as those described above.

[0216] Figure 7 This is a flowchart illustrating another exemplary process 700 for wireless communication (e.g., performed by a WTRU), which includes an adaptive RLC entity, such as those discussed further above. At 702, the WTRU transmits a set of PDUs through the RLC entity. Under condition 704, where the condition is met, the RLC entity is configured to enable retransmission. Under condition 706, where the condition is not met, the RLC entity is configured to disable retransmission. Other implementations include additional steps, fewer steps, and / or different steps, such as those described above.

[0217] Figure 8 This is a flowchart illustrating another exemplary process 800 for wireless communication (e.g., performed by a WTRU), which includes an adaptive RLC entity, such as those discussed further above. At 802, the WTRU's RLC entity is configured for retransmission. In some embodiments, the WTRU's RLC entity is configured for retransmission based on PDU set conditions, PDU set transmission conditions, network conditions, and / or WTRU conditions. At 1004, the WTRU transmits the PDU set via the RLC entity. At 804, the PDU set is transmitted via the RLC entity configured for retransmission.

[0218] Some implementations include solutions related to conditional PDCP replication. For example, in some implementations, the PDCP and / or bearer are associated with multiple RLC entities associated with different carriers (CA case) or links (DC case). For example, in some implementations, the WTRU is configured conditionally to determine which PDUs in the PDU set to replicate based on PDU set characteristics (e.g., based on importance level) and / or the current PDU set transmission status (e.g., based on thresholds considering TTL, PSER, UL buffer level, remaining percentage of PDUs to be transmitted, etc.) and current WTRU and / or network conditions (e.g., radio conditions and / or buffer level).

[0219] In an exemplary implementation involving conditional PDCP replication, the WTRU may operate as follows: The WTRU may be configured to support CA or DC. The WTRU may receive a DRB (separate) configuration having one or more RLC entities, where each RLC is associated with a specific carrier (e.g., in the case of CA) or a specific link / cell group (e.g., in the case of DC).

[0220] The WTRU can receive configuration of conditions for determining whether to copy at least a subset of the DRB's PDU set, PDCPPDUs, default copy mode (e.g., on or off), and default path (e.g., RLC entity). These conditions may include one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs; the percentage of remaining PDUs to be transmitted in the PDU set (or, if the PDUs in the PDU set can have different sizes, the percentage of remaining data to be transmitted in the PDU set); PSER (e.g., the minimum percentage of PDUs in the PDU set expected to be successfully received at the receiving entity); the importance of the PDU set or PDUs; the UL buffer level (e.g., the UL buffer level on the primary path, the UL buffer level on alternative paths, the total UL buffer level, considering only the bearers of interest, etc.); and / or radio conditions (e.g., RSRP threshold, RLC retransmission count, HARQ NACK / ACK level, etc.).

[0221] If the default replication mode is ON, the WTRU can begin applying PDCP replication. The WTRU can monitor the conditions used to enable / disable PDCP replication. The WTRU can determine the replication status. If the determined replication status is ON, the PDCP PDU is sent through two RLC entities after processing the PDCPPDU (e.g., applying security, adding headers, etc.). The WTRU can notify the network when PDCP replication is turned on and / or off.

[0222] In some implementations, WTRU is configured to determine whether replication should be applied at the PDCP level based on one or more characteristics of the PDU set associated with the PDCP entity of interest. For example, in some implementations, WTRU may operate as follows: If the PSDB is greater than a configured threshold, WTRU may apply replication; otherwise, it may not. If the importance level is higher than a configured threshold, WTRU may always apply replication; if the importance level is lower than a configured threshold, it may never apply replication; and if the importance level is between two thresholds, replication may be determined at the group level based on other conditions (such as those discussed herein). If the PDU set is a PSIHI PDU set, WTRU may apply replication. If the PDU set size is greater than a certain threshold size, WTRU may not apply replication, or it may apply replication to at most a certain size and / or percentage of PDUs in the PDU set (e.g., first x%, last x%, WTRU determines which groups to replicate based on other conditions discussed herein, up to a specified x%, etc.), and so on.

[0223] In some implementations, the WTRU is configured to determine whether replication should be applied at the PDCP level based on the current transmission status of the PDU set. For example, in some implementations, the WTRU may operate as follows: If the TTL is greater than a threshold (e.g., a configured threshold), the WTRU may apply replication. If the TTL is less than a threshold (e.g., a configured threshold), the WTRU may not apply replication. If the remaining number and / or percentage of PDUs in the PDU set (or the remaining actual amount and / or percentage of the total PDU set data to be transmitted) is less than a threshold (e.g., a configured threshold), the WTRU may apply replication; and so on.

[0224] In some implementations, the WTRU is configured to determine whether replication should be applied at the PDCP level based on one or more WTRU conditions associated with the UL buffer level. In some implementations, such a UL buffer can be associated with any buffer at the PDCP, RLC, or LCH. For example, in some implementations, the WTRU may operate as follows: If the UL buffer level on the default path / carrier is above a certain threshold, the WTRU may apply replication; otherwise, it may not apply replication. If the UL buffer level on a non-default path / carrier is below a certain threshold, the WTRU may apply replication; otherwise, it may not apply replication. If the UL buffer level on the default path and / or carrier is below a certain threshold and the UL buffer level on a non-default path and / or carrier is below another threshold, the WTRU may apply replication; and so on.

[0225] In some implementations, the WTRU is configured to determine whether to apply replication at the PDCP level based on one or more radio conditions. For example, in some implementations, the WTRU may operate as follows: If the radio quality (e.g., RSRP / RSRQ, etc.) of the default path and / or carrier is below a configured threshold, the WTRU may apply replication. If the radio quality (e.g., RSRP / RSRQ, etc.) of the default path and / or carrier is above a configured threshold, the WTRU may not apply replication. If, within a given time period, the number, percentage, and / or frequency of RLC and / or HARQ retransmissions in the first path (e.g., across all bearers, only involving the bear of interest / PDCP, etc.) is above a certain level, the WTRU may apply replication. If, within a given time period, the number, percentage, and / or frequency of RLC and / or HARQ retransmissions in the first path (e.g., across all bearers, only involving the bear of interest / PDCP, etc.) is below a certain level, the WTRU may not apply replication. If a UL license is available on a non-default path, and that UL license may not be used or needed by other bearers / packets already associated / buffered on that path (e.g., no buffered data, the priority of the bearer of interest is high enough to ensure that the packet will be scheduled before other pending data, large configuration licenses, etc.), then WTRU can apply replication.

[0226] In some implementations, the WTRU continuously checks whether the PDCP PDU is being replicated (e.g., for each PDCP PDU to be sent, the WTRU checks the conditions). In some implementations, the WTRU periodically checks the conditions for replication; for example, at a configured period (e.g., period 0 starts when the first PDU in the PDU set is sent, period 1 starts after period 0+ periods, etc., and the replication status for that PDCP entity is set to ON or OFF for a given duration based on the determination / checking of the conditions). In some implementations, the period can be a time length or the number of PDUs and / or bytes.

[0227] Some implementations involve solutions where the WTRU sends instructions to the network. For example, in some implementations, the WTRU can enable or disable replication without explicitly notifying the network.

[0228] In some implementations, the WTRU can notify the network when replication is enabled or disabled. In some implementations, the indication may include additional information about the reason for enabling and / or disabling replication (e.g., which of the conditions for enabling and / or disabling replication was triggered, etc.). Alternatively, the indication may indicate preferences for enabling and / or disabling replication (e.g., including the start time and / or duration for enabling and / or disabling replication).

[0229] In some implementations, such information can be useful for the network to appropriately allocate resources to the WTRU and other UEs. For example, in some implementations, if the WTRU notifies the network that replication is enabled, the network can attempt to allocate more resources to the WTRU (e.g., on a non-default path / carrier) for the data to be replicated. On the other hand, in some implementations, if the WTRU notifies the network that replication is disabled, the network can release resources (e.g., any resources) that may have been provided by the WTRU for the data to be replicated, and these resources (e.g., configuration authorization, etc.) can be made available to other WTRUs.

[0230] In some implementations, instead of enabling or disabling replication itself, the WTRU can send an indication to the network that conditions for enabling or disabling replication have been met, and the network can then enable and / or disable replication based on this indication (e.g., using a traditional mechanism of activating / deactivating replication via MAC CE). In some implementations, if replication is enabled, the WTRU can send a Buffer Status Report (BSR) to the network (e.g., to the secondary node if the default path is the primary node, and vice versa, etc.). In some implementations, the BSR can indicate expected data (e.g., new replicated data) that will arrive on a new path.

[0231] Some implementations include solutions related to other aspects. For example, in some of the above, the buffer level can be the total buffer level or the buffer level of certain bearers (e.g., bearers with certain QoS profiles, such as those with stricter latency and / or bit rate requirements than a certain level or compared to the bearer configuration of the PDCP entity of interest, etc.).

[0232] In some implementations, WTRU can be configured with any combination of the above conditions. For example, in some implementations, WTRU can apply replication if the TTL is below threshold 1 and the radio quality on the default path / carrier is below threshold 2, and so on. In some implementations, WTRU can be configured to consider not only the current value, but also the average and / or filtered value over a configured time window, or the rate of change of the value, or the threshold can be based on any other statistical metric (e.g., average, standard deviation, minimum / maximum value, etc. over the evaluation period).

[0233] In some of the above implementations, it is assumed that all PDUs in a PDU set have the same importance level (i.e., each PDU set has one importance level). However, some implementations are suitable for situations where different PDUs in a PDU set may have different importance levels. In some implementations, in such cases, it may be necessary to perform PDCP replication determination at the PDU level.

[0234] In some implementations of the above, the WTRU can be configured with a replication state change prohibition timer, which indicates how long the WTRU should wait before it can change the replication state. In some implementations, in the case of periodic replication checks, the period can be considered the same as the prohibition timer (e.g., since the WTRU checks the conditions for the replication state each period, it will not be able to change the replication state within a time shorter than the period). However, in some implementations, where the replication state can be changed ad-hoc, the prohibition timer can be started each time the replication state changes, and replication may not change before the prohibition time elapses.

[0235] In some implementations, the prohibition on a PDU set can be "sticky," meaning the replication state can be changed only once, and will not change for the remainder of the PDU set. In some implementations, the WTRU determines the replication state at the beginning of the PDU set and continues to use that determined replication state (i.e., replicate or not replicate) for the remainder of the PDU set transmission. In some implementations, the WTRU can be configured to change the replication state a maximum of a certain number of times during the lifetime of the PDU set.

[0236] Figure 9 This is a flowchart illustrating an exemplary process for wireless communication performed by a WTRU, including conditional PDCP replication, such as discussed further above. At 902, the WTRU receives configurations for multiple RLC entities. At 904, the WTRU receives configurations for determining whether to transmit data through multiple RLC entities. At 906, the WTRU monitors the conditions. At 908, the WTRU transmits data through multiple RLC entities based on the conditions. Other implementations include additional steps, fewer steps, and / or different steps, such as those described above.

[0237] Some implementations include solutions related to conditional retransmissions via a second path. For example, in some implementations, the PDCP / bearer is associated with multiple RLC entities, each associated with a different carrier (CA case) or link (DC case). In some implementations, the WTRU is configured to first send the PDCP PDU via one RLC entity (e.g., the default path, a currently licensed path, etc.), and if certain conditions are not met (e.g., within a given time), the WTRU sends a copy of the PDU via another RLC entity (e.g., considering RLC status reception indicating ACK / NACK reception associated with the first transmission within a given time, buffer level on the first path, radio conditions on the first path / carrier, etc.). In some implementations, different conditions can be configured for different PDU set characteristics (e.g., importance level) and transmission states (e.g., TTL, percentage of PDUs sent, etc.). In some implementations, the WTRU can be configured to switch the default path after that until the second set of conditions is met or a certain amount of time has elapsed.

[0238] In an exemplary implementation involving conditional retransmission via a second path, the WTRU may operate as follows: The WTRU may be configured to support CA or DC. The WTRU may receive a DRB (separate) configuration having one or more RLC entities, where each RLC is associated with a specific carrier (e.g., in the case of CA) or a specific link / path (e.g., in the case of DC), and one of the RLC entities is set to default.

[0239] The WTRU can receive configuration conditions to determine whether to retransmit a PDCP PDU via a second path after a given configured time length has elapsed since data was transmitted on the first path and before the packet reception has been acknowledged. These conditions may include one or more thresholds such as: receiving one or more NACKs (e.g., RLC status indicating NACKs for this PDU, RLC status indicating NACKs for other PDUs, etc.); HARQ retransmission count; buffer level on the first or second path; and / or radio link quality on the first and / or second paths. The conditions may further depend on PDU set characteristics (e.g., importance level) and the current PDU set transmission status (e.g., TTL, percentage of remaining PDUs to be transmitted in the PDU set, etc.).

[0240] After processing the PDCP PDU (e.g., applying security, adding headers, etc.), the WTRU can send packets via the first and / or default path. If the configured time has elapsed and the reception of the packet has not been acknowledged, the WTRU can check the conditions for retransmitting the packet. If the conditions for retransmission via another path or other paths are met, the WTRU can send a copy of the PDCP PDU via that other path or other paths. The WTRU can be configured to stop attempting to retransmit the packet of interest via the first path after sending the copy. In some implementations, the WTRU is configured with conditions to determine whether to retransmit (e.g., send a copy) the PDCP PDU via a second path after sending it via the first path.

[0241] In some implementations, the conditions for retransmission may include a configured time period elapsed after the transmitted packet has passed through the first path, and one or more of the following being met within the configured time period: no acknowledgment has been received for the packet of interest; one or more RLC status PDUs indicating the loss of an RLC PDU containing the PDCP PDU of interest have been received; one or more RLC status PDUs indicating a certain number (or percentage) of lost RLC PDUs have been received; a certain number (or percentage) of HARQ retransmissions have been detected after the transmitted packet has passed through the first path; an increase in the UL buffer level has been detected on the first path; a decrease in the UL buffer level has been detected on the second path; the radio link quality on the first path has been detected to be below a certain threshold (which may be an average / filtered value over the time period); and / or the radio link quality on the second path has been detected to be above a certain threshold (which may be an average / filtered value over the time period).

[0242] In some implementations, the conditions for retransmission via another path (e.g., configured wait time length, number of RLC status PDUs indicating RLC PDU loss, number / percentage of HARQ retransmissions, level of UL buffer level increase / decrease, radio quality levels on the first and second paths, etc.) depend on the characteristics of the PDU (e.g., PDU set importance, PSDB, PSHI, etc.). That is, the WTRU can be configured with multiple sets of values ​​for different characteristics of the PDU set (e.g., different wait time lengths for different PSDBs or PDU set importance, etc.).

[0243] In some implementations, the conditions for retransmission via another path (e.g., configured wait time length, number of RLC-state PDUs indicating RLC PDU loss, number / percentage of HARQ retransmissions, level of UL buffer level increase / decrease, radio quality levels on the first and second paths, etc.) depend on the state of the PDU set transmission (e.g., TTL, PSER, percentage of PDUs still to be transmitted in the PDU set, etc.). That is, the WTRU can be configured with multiple sets of values ​​for different transmission states of the PDU set (e.g., different wait time lengths for different TTLs, etc.). For example, in some implementations, the WTRU can be configured to apply a longer wait time length when the TTL is high, compared to when the TTL is low.

[0244] In some implementations, the fulfillment of the retransmission condition only affects a specific packet. In some implementations, instead of checking the retransmission condition for all packets after each packet is sent via the first path, the WTRU can be configured to check the condition periodically (e.g., every x ms, every n PDUs, etc.). In some implementations, if the retransmission condition for that packet is met, the WTRU can be configured to retransmit all packets sent via the first path before that packet but still awaiting acknowledgment via the second path. In some implementations, not all of these packets are retransmitted, but only a certain number and / or percentage of these packets are retransmitted.

[0245] In some implementations, the WTRU may stop retransmitting / sending the packet via the first path after determining that it has been retransmitted via the second path (e.g., all RLC PDUs containing the PDCP PDU are cleared from the RLC's transmission buffer on the first path). In such cases, in some implementations, the WTRU may need to send information about this event to the network (e.g., so that the receiving RLC entity at the network does not have to wait for packets that will no longer be transmitted). In some implementations, this can be accomplished via MAC CE, RLC header information, RLC control PDUs, etc.

[0246] In some implementations, after determining that a packet will be retransmitted via the second path, the WTRU can pause the use of the first path to send any new data for the PDCP of interest for a given configured time length or until other conditions are met (e.g., when the second path is used, a retransmission to the first path is determined, the buffer level on the first path has dropped to a certain level, the radio quality on the first link is now above a certain threshold, the number / percentage of HARQ retransmissions on the first path or RLC status PDUs indicating lost PDUs have dropped below a certain threshold, etc.).

[0247] In some implementations, the buffer level can be the total buffer level or the buffer level of certain bearers (e.g., bearers with certain QoS profiles, such as those with more stringent latency / bit rate requirements than a certain level or compared to the bearer configuration of the PDCP entity of interest, etc.).

[0248] In some implementations, it can be assumed that the PDUs in a PDU set have the same level of importance (i.e., each PDU set has one level of importance). However, some implementations are also applicable when different PDUs in a PDU set can have different levels of importance. For example, in some implementations, the wait time for important PDUs can be set to be shorter than the wait time for unimportant PDUs, and so on.

[0249] Figure 10 This is a flowchart illustrating an exemplary process for wireless communication performed by a WTRU, including conditional retransmissions, such as those discussed further above. At 1002, the WTRU receives configurations for multiple RLC entities. At 1004, the WTRU receives configurations for determining whether to send a copy of the data via a second RLC entity. At 1006, the WTRU sends data via a first RLC entity. At 1008, the WTRU sends a copy of the data via the second RLC entity based on the conditions. Other implementations include additional steps, fewer steps, and / or different steps, such as those described above.

[0250] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and optical media (e.g., CD-ROMs and digital versatile optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A method for wireless communication implemented in a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information, which indicates the configuration for confirming the mode (AM) radio link control (RLC) entity; Receive Packet Data Unit (PDU) sets through the Packet Data Convergence Protocol (PDCP) entity; The AM RLC entity is configured for retransmission based on at least one condition, wherein the at least one condition includes PDU set characteristics and / or PDU set transmission status. The PDU set is transmitted through the AM RLC entity; Receive the RLC status PDU indicating the RLC status; as well as In response to the RLC status, one or more PDUs in the PDU set are retransmitted through the RLC entity.

2. The method of claim 1, wherein the PDU set characteristics include the priority level of the PDU set and / or the type of the PDU set.

3. The method of claim 1, wherein the PDU set transmission status includes a time-to-live (TTL) threshold, a PDU set error rate (PSER) threshold, an uplink (UL) buffer level of the PDU set, and / or the remaining percentage of the PDU set to be transmitted.

4. The method of claim 1, wherein the at least one condition includes network conditions.

5. The method of claim 1, wherein the at least one condition includes radio conditions.

6. The method of claim 1, wherein the at least one condition includes a WTRU condition.

7. The method of claim 6, wherein the WTRU condition includes a buffer level.

8. The method of claim 1, wherein the RLC status indicates that at least one PDU in the PDU set has not been received.

9. The method of claim 1, wherein the AM RLC entity is configured to enable retransmission in response to a value associated with the PDU set satisfying a threshold associated with the at least one condition.

10. The method of claim 1, wherein the AM RLC entity is configured to disable retransmission in response to a value associated with the PDU set satisfying a threshold associated with the at least one condition.

11. A wireless transmit / receive unit (WTRU), comprising: A circuit configured to receive configuration information indicating the configuration of a confirmation mode (AM) radio link control (RLC) entity; A circuit configured to receive a first set of packet data units (PDUs) via a packet data convergence protocol (PDCP) entity; A circuit configured to configure the AM RLC entity for retransmission based on at least one condition, wherein the at least one condition includes PDU set characteristics and / or PDU set transmission status; A circuit configured to transmit the PDU set via the AM RLC entity; A circuit configured to receive an RLC status PDU indicating the RLC status; as well as A circuit configured to retransmit one or more PDUs in the PDU set via the RLC entity in response to the RLC state.

12. The WTRU of claim 11, wherein the PDU set characteristics include the priority level of the PDU set and / or the type of the PDU set.

13. The WTRU of claim 11, wherein the PDU set transmission status includes a time-to-live (TTL) threshold, a PDU set error rate (PSER) threshold, an uplink (UL) buffer level of the PDU set, and / or the remaining percentage of the PDU set to be transmitted.

14. The WTRU of claim 11, wherein the at least one condition includes network conditions.

15. The WTRU of claim 11, wherein the at least one condition includes a radio condition.

16. The WTRU of claim 11, wherein the at least one condition includes WTRU conditions.

17. The WTRU of claim 16, wherein the WTRU condition includes a buffer level.

18. The WTRU of claim 11, wherein the RLC status indicates that at least one PDU in the PDU set has not been received.

19. The WTRU of claim 11, wherein the AM RLC entity is configured to enable retransmission in response to a value associated with the PDU set satisfying a threshold associated with the at least one condition.

20. The WTRU of claim 11, wherein the AM RLC entity is configured to disable retransmission in response to a value associated with the PDU set satisfying a threshold associated with the at least one condition.

Images