Higher layer reliability for XR traffic

Abstract

A system, method, and device for wireless communication. Configuration information is received indicating the configuration for an Acknowledgment Mode (AM) Radio Link Control (RLC) entity. 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, the at least one condition including the characteristics of the PDU set and / or the transmit status of the PDU set. The PDU set is transmitted via the AM RLC entity. An RLC status PDU indicating the RLC status is received. One or more PDUs of the PDU set are retransmitted via the RLC entity in response to the RLC status. In some implementations, the characteristics of the PDU set include the priority level and / or the type of the PDU set. In some implementations, the transmit status of the PDU set includes a Time to Live (TTL) threshold.

Description

Technical Field

[0003]

[0001] This application relates to the reliability of the upper layer for XR traffic.

Background Art

[0002] Cross - reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 531,193, filed on August 7, 2023; U.S. Provisional Patent Application No. 63 / 531,197, filed on August 7, 2023; U.S. Provisional Patent Application No. 63 / 531,201, filed on August 7, 2023; and U.S. Provisional Patent Application No. 63 / 531,204, filed on August 7, 2023, the contents of which are incorporated herein by reference.

[0003] The term Extended Reality (XR) can refer to various types of immersive experiences, including Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and / or realities positioned in between them. Some XR services and / or application traffic 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 video frames or video slices. In some implementations, a data burst may include one or more PDU sets, which may be transmitted and / or received over a certain time frame. 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 frame or audio frame).

Summary of the Invention

[0004] Several implementations provide methods for wireless communication implemented in a Wireless Transmitter / Receiver Unit (WTRU). Configuration information is received indicating the configuration for an Acknowledgment Mode (AM) Radio Link Control (RLC) entity. 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, the at least one condition including the characteristics of the PDU set and / or the transmission status of the PDU set. The PDU set is transmitted via the AM RLC entity. An RLC status PDU indicating the RLC status is received. One or more PDUs of the PDU set are retransmitted via the RLC entity in response to the RLC status.

[0005] In some implementations, the characteristics of a PDU set include the PDU set's priority level and / or the PDU set's type. In some implementations, the PDU set's transmit status includes the Time To Live (TTL) threshold, the PDU Set Error Rate (PSER) threshold, the PDU set's uplink (UL) buffer level, and / or the percentage of remaining PDU sets to be transmitted.

[0006] In some implementations, at least one condition includes a network condition. In some implementations, at least one condition includes a wireless condition. In some implementations, 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 was not received.

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

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

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

[0010] In some implementations, at least one condition includes a network condition. In some implementations, at least one condition includes a wireless condition. In some implementations, 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 was not received.

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

[0012] Several implementations provide a method for wireless communication. Data is transmitted through one of several radio link control (RLC) entities. Each of the RLC entities operates in a different mode. Data is transmitted through one of the RLC entities based on at least one condition. In some implementations, the data includes a set of packet data units (PDUs). In some implementations, at least one condition includes the characteristics of the PDU set, the transmit status of the PDU set, the WTRU condition, and / or the network condition. In some implementations, the characteristics of the PDU set include the importance level, the transmit status of the PDU set includes the TTL threshold, PSER threshold, UL buffer level, and / or the percentage of remaining PDU sets to be transmitted, the WTRU condition includes the radio condition and / or buffer level, and the network condition includes the radio condition and / or buffer level. In some implementations, each of the RLC entities operates in either acknowledgment mode (AM), unacknowledged mode (UM), or transparent mode (TM). Several implementations provide wireless transmit / receive units (WTRUs), systems, processors, network elements, base stations, access points, stations, integrated circuits, and / or memory configured to implement methods for wireless communication.

[0013] Several implementations provide a method for wireless communication. Data is transmitted by 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, at least one condition includes characteristics of the PDU set, the transmission status of the PDU set, a WTRU condition, and / or a network condition. In some implementations, the characteristics of the PDU set include a severity level, the transmission status of the PDU set includes a TTL threshold, a PSER threshold, a UL buffer level, and / or a percentage of the remaining PDU set to be transmitted, the WTRU condition includes a radio condition and / or a buffer level, and the network condition includes a radio condition and / or a buffer level. In some implementations, the RLC is configured to enable retransmission in response to a value associated with the data meeting a threshold associated with at least one condition. Several implementations provide a WTRU, a system, a processor, a network element, a base station, an access point, a station, an integrated circuit, and / or memory configured to implement a method for wireless communication.

[0014] Several implementations provide a method for wireless communication. Data is transmitted using a Packet Data Convergence Protocol (PDCP) associated with multiple RLC entities. Data is transmitted in more than one of the multiple RLC entities based on at least one condition. In some implementations, the data includes a PDU set. In some implementations, at least one condition includes the characteristics of the PDU set, the transmit status of the PDU set, a WTRU condition, and / or a network condition. In some implementations, the characteristics of the PDU set include a severity level, the transmit status of the PDU set includes a TTL threshold, a PSER threshold, a UL buffer level, and / or a percentage of the remaining PDU sets to be transmitted, the WTRU condition includes a radio condition and / or a buffer level, and the network condition includes a radio condition and / or a buffer level. In some implementations, the PDCP is configured to transmit data in more than one of the multiple RLC entities in response to a value associated with the data satisfying a threshold associated with at least one condition. Some implementations provide memory configured to implement WTRUs, systems, processors, network elements, base stations, access points, stations, integrated circuits, and / or methods for wireless communication.

[0015] Several implementations provide a method for wireless communication. Data is transmitted on a first RLC entity among multiple RLC entities. A copy of the data is transmitted on a second RLC entity among multiple RLC entities based on conditions associated with the transmission of data on the first RLC entity among multiple RLC entities. In some implementations, the data includes a PDU set. In some implementations, at least one condition includes the time elapsed since the transmission of data on the first RLC entity, the status of data reception from the network, the radio conditions on the link associated with one or more of the RLC entities, and / or the uplink (UL) buffer level on the link associated with one or more of the RLC entities. In some implementations, at least one condition depends on the characteristics of the PDU set and / or the transmission status of the PDU set. In some implementations, the PDCP is configured to transmit a copy of the data on a second RLC entity among multiple RLC entities in response to a value associated with the transmission of data on the first RLC entity among multiple RLC entities meeting a threshold associated with at least one condition. Some implementations provide memory configured to implement wireless transmit / receive units (WTRUs), systems, processors, network elements, base stations, access points, stations, integrated circuits, and / or methods for wireless communication. [Brief explanation of the drawing]

[0016] A more detailed understanding can be obtained from the following explanation, which is provided as an example along with the attached drawings, and similar reference numbers in the drawings refer to the same elements. [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A, according to an embodiment. [Figure 1C] FIG. 1A is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the communication system shown in FIG. 1A according to an embodiment. [Figure 1D] FIG. 1B is a system diagram showing a further exemplary RAN and a further exemplary CN that can be used within the communication system shown in FIG. 1A according to an embodiment. [Figure 2] FIG. 2 is a line graph showing an exemplary set of PDUs received over time. [Figure 3] FIG. 3 is a block diagram showing an exemplary protocol view of a split bearer. [Figure 4] FIG. 4 is a block diagram showing a schematic model of the RLC sublayer. [Figure 5] [[ID=十七]]FIG. 5 is a flowchart showing an exemplary procedure implemented for wireless communication including conditional switching of RLC entities. [Figure 6] FIG. 6 is a flowchart showing another exemplary procedure implemented for wireless communication including an adaptive RLC entity. [[ID=二十二]] [Figure 7] FIG. 7 is a flowchart showing another exemplary procedure implemented for wireless communication. [Figure 8] FIG. 8 is a flowchart showing another exemplary procedure implemented for wireless communication. [Figure 9] FIG. 9 is a flowchart showing another exemplary procedure implemented for wireless communication including an adaptive RLC entity. [Figure 10] FIG. 10 is a flowchart showing another exemplary procedure implemented for wireless communication including an adaptive RLC entity. DETAILED DESCRIPTION OF THE INVENTION <s

[0017] The following acronyms and abbreviations are used in this specification. 6DOF Six Degrees of Freedom ACK Acknowledgment ADU Application Data Unit AR Augmented Reality AS Access Stratum AM Acknowledgement Mode BLER Block Error Rate BSR Buffer Status Report BSD Bucket Size Duration BWP Bandwidth Part CAP Channel Access Priority CAPC Channel Access Priority Class CCA Clear Channel Assessment CCE Control Channel Element CE Control Element CG Configured Grant or Cell Group CP Cyclic Prefix CP-OFDM (Cyclic Prefix Based) Conventional OFDM CQI Channel Quality Indicator CRC Cyclic Redundancy Check CSI Channel State Information CW Contention Window CWS Contention Window Size CO Channel Occupancy DAI Downlink Allocation Index DCI Downlink Control Information DFI Downlink Feedback Information DG Dynamic Grant DL Downlink DM-RS Demodulation Reference Signal DRB Data Radio Bearer eLAA Extended License Assisted Access FDRA Frequency Domain Resource Allocation FeLAA Further Extended License Assisted Access FoV Field of View FPS Frames Per Second HARQ Hybrid Automatic Repeat Request LAA License Assisted Access LBT Listen Before Talk LCP Logical Channel Prioritization LCH Logical Channel LTE, for example, Long-Term Evolution of 3GPP LTE R8 and later. NACK Negative ACK MAC Media Access Control MCS Modulation and Coding Scheme MIMO Multi-Input Multi-Output MT Mobile Incoming Calls MTP Motion to Photon NAS Non-Access Layer NR New Radio NW Network OFDM (Orthogonal Frequency Division Multiplexing) PBR preferred bitrate PDB Packet Latency 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 Opportunities PRACH Physical Random Access Channel PSS Primary Sync Signal PSDB PDU set delay limit PSER PDU set error rate PSIHI PDU Set Batch Processing Indicator QFI QoS Flow Indicator RA Random Access (or Procedure) RACH Random Access Channel RAR Random Access Response RCU (Radio Access Network Central Unit) RF Wireless Frontend RLF Wireless Link Failure RLM Wireless Link Monitoring RNTI (Radio Network Identifier) RO RACH opportunity 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 Adaptive Protocol SR scheduling request SDU Service Data Unit SLIV start and length indicator values SRS Sounding Reference Signal SS synchronization signal SSS Secondary Synchronization Signal SWG (Switching Gap in a Self-Contained Subframe) SPS Semi-Persistent Scheduling SUL Auxiliary Uplink TB transport block TBS Transport Block Size TDRA Time Domain Resource Allocation TRP Transmit / Receive Point TSC Time Sensitive Communications TSN Time-Sensitive Networking UCI Uplink Control Display UL Uplink UTO Unused Sending Opportunities URLLC: Ultra-high reliability and low latency communication WBWP wideband portion WLAN (Wireless Local Area Network) and related technologies (IEEE 802.xx domain) VR (Virtual Reality) XR Extended Reality

[0018] Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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 spread OFDM (ZT-UW-DFT-S-OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multicarrier (FBMC).

[0019] As shown in Figure 1A, 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, but it will be understood that the disclosed embodiments conspiracy to include any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be called 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, contract-based units, pagers, mobile 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 wearables, head-mounted displays (HMDs), vehicles, drones, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain situations), consumer electronics, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may be referred to interchangeably with WTRU.

[0020] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be next-generation node B such as a base transceiver station (BTS), node B, e-node B (eNB), home node B, home e-node B, g-node B (gNB), and New Radio (NR) node B, site controller, access point (AP), and wireless router. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0021] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. Base stations 114a and / or base stations 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, sometimes referred to as cells (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide coverage of a wireless service to a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one 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.

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

[0023] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish an air interface 116 using broadband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

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

[0025] In the embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, which can establish an air interface 116 using NR.

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

[0027] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0028] In Figure 1A, base station 114b may be a wireless router, home node B, home enode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in localized areas such as businesses, residences, vehicles, campuses, industrial facilities, aerial walkways (e.g., for drone use), and roads. In one embodiment, base station 114b and WTRU 102c, 102d may implement radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRU 102c, 102d may implement radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRU 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106.

[0029] RAN104 may communicate with CN106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or implement high-level security features such as user authentication. Although not shown in Figure 1A, it should be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs employing the same RAT as RAN104 or different RATs. For example, in addition to being connected to RAN104 which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0030] CN106 may also serve as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing simple telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as TCP, User Datagram Protocol (UDP), and / or IP in the Transmission Control Protocol (TCP) / Internet Protocol (IP) suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 or a different RAT.

[0031] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (i.e., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks on different wireless links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a which may employ cellular-based radio technology and base station 114b which may employ IEEE 802 radio technology.

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

[0033] The processor 118 may be a general-purpose processor, a dedicated 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. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0036] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmit / receive element 122 and to demodulate the signal to be received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate over multiple RATs, such as NR and IEEE 802.11, for example.

[0037] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (for example, a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from them. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data therein. 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 identification module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data therein.

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

[0039] 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) regarding the current location of the WTRU 102. In addition to, or instead of, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) on the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while remaining consistent with the embodiment.

[0040] The processor 118 may also be coupled to other peripherals 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, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripherals 138 may include one or more sensors. The sensor may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0041] WTRU102 may include a full-duplex radio such that some or all of the transmission and reception of a signal (e.g., associated with a particular subframe for both UL (e.g., for transmission) and DL (e.g., for reception) may be parallel and / or simultaneous). The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference, either through hardware (e.g., chokes) or signal processing via a processor (e.g., a separate processor (not shown) or processor 118). In embodiments, WTRU102 may include a half-duplex radio such that some or all of the transmission and reception of a signal (e.g., associated with a particular subframe for either UL (e.g., for transmission) or DL ​​(e.g., for reception) may be asynchronous.

[0042] Figure 1C is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c over the air interface 116. RAN104 may also communicate with CN106.

[0043] RAN104 may include enodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of enodes B while remaining consistent with the embodiment. Each of the enodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c on the air interface 116. In one embodiment, enodes B160a, 160b, and 160c may implement MIMO technology. Thus, enode B160a may use multiple antennas, for example, to transmit a wireless signal to WTRU102a and / or receive a wireless signal from WTRU102a.

[0044] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c can communicate with each other over the X2 interface.

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

[0046] MME162 may be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and may act as a control node. For example, MME162 may be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. MME162 may provide control plane functions for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0047] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions such as anchoring the user plane during handovers between e-nodes B, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0048] SGW164 may also be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0049] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional land-line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 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.

[0050] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in some typical embodiments, such a terminal may use a wired communication interface with a communication network (for example, temporarily or permanently). In a typical embodiment, the other network 112 may be a WLAN.

[0051] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access rights or interfaces to a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic originating outside the BSS and destined for an STA may arrive via an AP and be delivered to the STA. Traffic originating at an STA to a destination outside the BSS may be sent to an AP for delivery to its respective destination. Traffic between STAs within a BSS may be transmitted, for example, through an AP, where the source STA may send the traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS is considered and / or may be referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) using a Direct Link Setup (DLS). In some typical embodiments, the DLS may use 802.11e DLS or 802.11z tunneling DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as the “ad hoc” communication mode.

[0052] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may have a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width. The primary channel may also be the operating channel of the BSS and may be used by an STA to establish a connection with the AP. In some typical embodiments, collision-avoiding carrier-sensing multiple access (CSMA / CA) may be implemented, for example, in an 802.11 system. In CSMA / CA, an STA (e.g., any STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA may withdraw. A single STA (e.g., just one station) may transmit at any given time on a given BSS.

[0053] A high-throughput (HT) STA may use a 40MHz wide channel for communication, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0054] Ultra-high throughput (VHT) STAs may support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels may be formed by combining consecutive 20MHz channels. 160MHz channels may be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, the latter sometimes referred to as an 80+80 configuration. In an 80+80 configuration, the data after channel coding may pass through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately for each stream. The streams may be mapped to two 80MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of a receiving STA, the above operation of the 80+80 configuration may be reversed, and the combined data may be transmitted to a media access control (MAC).

[0055] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. 802.11af and 802.11ah reduce channel operating bandwidth and carriers compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including some capability, e.g., support for some and / or limited bandwidth (e.g., only support for that). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0056] A WLAN system that can support multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by one of the STAs among all STAs operating in the BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports 1MHz operating mode) is transmitting to the AP, then all available frequency bands may be considered busy even if the majority of the available frequency band remains idle.

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

[0058] Figure 1D is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 may employ NR radio technology to communicate with WTRU102a, 102b, and 102c over the air interface 116. RAN104 may also communicate with CN106.

[0059] RAN104 may include gNB180a, 180b, and 180c, but it will be understood that RAN104 may include any number of gNBs while remaining consistent with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c on the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU102a, for example. In embodiments, gNB180a, 180b, and 180c may implement carrier aggregation techniques. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In embodiments, gNB180a, 180b, and 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0060] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may differ for different transmissions, different cells, and / or different parts of the wireless transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTI) of varying or scalable lengths (e.g., containing a variable number of OFDM symbols and / or lasting for a variable absolute time).

[0061] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in the unlicensed band. In a non-standalone configuration, WTRU102a, 102b, and 102c may communicate with and / or connect to gNB180a, 180b, and 180c while also communicating with and / or connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c may implement the DC principle to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c, and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, e-nodes B160a, 160b, and 160c may act as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c may provide additional coverage and / or throughput for the servicing WTRU102a, 102b, and 102c.

[0062] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, interconnection between DC, NR and E-UTRA, routing of user plane data to user plane functions (UPF) 184a and 184b, and routing of control plane information to access and mobility management functions (AMF) 182a and 182b. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other over the Xn interface.

[0063] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. While these elements are shown as part of CN106, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0064] AMF182a and 182b may be connected to one or more gNB180a, 180b, and 180c in RAN104 via the N2 interface and may act as control nodes. For example, AMF182a and 182b may be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating non-accessible layer (NAS) signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-high reliability low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for MTC access. AMF182a, 182b may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0065] SMF183a and 183b can be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b 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.

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

[0067] CN106 can facilitate communication with other networks. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 may provide WTRU102a, 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, WTRU102a, 102b, and 102c may be connected to local DN185a and 185b via UPF184a and 184b through the N3 interface to UPF184a and 184b, and via the N6 interface between UPF184a and 184b and DN185a and 185b.

[0068] As can be seen from Figures 1A to 1D and their corresponding descriptions, one or more or all of the functions described herein may be implemented by one or more emulation devices (not shown) with respect to one or more of the functions described herein, with respect to WTRU 102a to d, base stations 114a to b, e-nodes B160a to c, MME 162, SGW 164, PGW 166, gNB 180a to c, AMF 182a to b, UPF 184a to b, SMF 183a to b, DN 185a to b, and / or any other devices described herein. An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0069] Emulation devices may be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more emulation devices may perform one or more or all 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 in a communication network. One or more emulation devices may perform one or more or all of the functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices may be directly coupled to another device for the purpose of testing and / or performing tests using over-the-air wireless communications.

[0070] One or more emulation devices may perform one or more functions, including all functions, without being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory and / or in a test scenario in an undeployed (e.g., experimental) wired and / or wireless communication network to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0071] Several implementations relate to Extended Reality. The term Extended Reality (XR) can refer to various types of immersive experiences, including virtual reality (VR), augmented reality (AR), mixed reality (MR), and / or realities placed between them. In some implementations, VR can refer to a rendered version of the audiovisual scene being delivered. Rendering can simulate the viewing angle of the real world (e.g., stereoscopic 3D) and / or auditory stimuli to the observer or user as naturally as possible, for example, as they move within limits defined by the application. 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 several virtual elements are inserted into a physical scene, for example, creating the illusion that those elements are part of a real scene. In some implementations, XR can refer to all reality-virtual fusion environments and human-machine interactions generated by computer technology and wearables.

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

[0073] In some implementations, a WTRU can correspond to any XR device and / or node, which may take on various form factors. In some implementations, a WTRU (e.g., an XR WTRU) may include, but is not limited to, head-mounted displays (HMDs), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with position tracking and cameras, wearables, haptic gloves, haptic bodysuits, haptic shoes, etc. In some implementations, several different types of XR WTRUs may provide, or be based on, XR device functionality, such as a display, camera, sensors, sensor processing, wireless connectivity, XR and / or media processing and / or power supply, which should be provided by, for example, one or more devices, wearables, actuators, controllers, and / or accessories. In some implementations, one or more devices, nodes, and / or WTRUs may be grouped into a collaborative XR group, for example, to support an XR application, experience, and / or service.

[0074] Some XR services and / or applications may involve traffic that may contain data and / or PDUs, which may be associated with application data units (ADUs), PDU sets, or data bursts. In some examples, 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 contain one or more PDU sets, which may be transmitted and / or received over a time frame. For example, in some implementations, the number of PDU sets or PDUs in a data burst transmitted in the UL and / or received in the DL may depend on the type of media frame (e.g., 3D video frame, audio frame).

[0075] In some XR applications, a WTRU transmits XR traffic (e.g., including pause, gesture, and / or video information) containing one or more PDUs and / or sets of PDUs at the UL, and / or receives XR traffic (e.g., including video, audio, and / or haptic information) at the DL. In some implementations, such traffic may be transmitted and / or received periodically or irregularly in one or more data flows (e.g., QoS flows). In some implementations, for example, during a UL transmission, XR traffic may arrive at its WTRU from the application layer and / or from different devices, terminals, and / or WTRUs (e.g., via sidelinks) at different times. In some implementations, such XR traffic may be characterized by different attributes, such as a variable payload size per PDU set, a variable number of PDUs per PDU set, a variable level of importance per PDU and / or per PDU set, and / or different levels of interdependence between PDUs and / or PDU sets. In some implementations, such XR traffic received by a WTRU (e.g., PDUs and / or PDU sets) may also experience different delays, jitter, data rates, and / or loss rates. In some implementations, performing data transmission and / or reception, as well as other related functions (e.g., prioritization, multiplexing, and / or scheduling), in a timely manner along with XR awareness (e.g., awareness of PDU set attributes) can have the advantage of improving QoS and / or user experience (QoE).

[0076] In some implementations, this relates to PDU sets and data bursts. In some 5G system (5GS) implementations, QoS flow is the finest granularity of QoS distinctions within a PDU session. 5G QoS characteristics can be determined by 5QI. Therefore, in some implementations, each packet in a QoS flow may be treated according to the same QoS requirements.

[0077] For XR and / or XR media services, groups of packets are used to carry the payload of a PDU set (e.g., frames, video slices, and / or tiles). A PDU set may contain one or more PDUs carrying a payload of a unit of information generated at the application level (e.g., frames, video slices, and / or tiles).

[0078] At the media layer, packets in such a PDU set may be decoded as a whole and / or treated differently as a whole. For example, in some implementations, frames, video slices, and / or tiles may only be decoded if some or all of the packets carrying the frame, video slice, and / or tile have been successfully delivered. For example, in some implementations, a frame in a group of pictures (GOP) may only be decoded by the client if all the frames on which that frame depends have been successfully received. Thus, in some implementations, groups of packets in a PDU set may be referred to as having inherent dependencies on each other at the media layer. If such dependencies between packets in a PDU set are not considered, in some implementations, 5GS may perform scheduling with low efficiency. For example, 5GS may randomly drop one or more packets while attempting to deliver other packets in the same PDU set that are useless to the client, thus wasting radio resources.

[0079] In some implementations, audio samples, haptic applications, and / or remote control operations can benefit if 5GS takes into account the characteristics of the PDU set. Some implementations that leverage such dependencies between packets (e.g., frames, video slices, and / or tiles) in the PDU set may have the advantage of increased efficiency and / or improved user experience.

[0080] Several implementations offer improvements to the current 5GS QoS framework to support different QoS handling for PDU sets. PDU sets can carry different content, such as I / B / P frames, slices / tiles within I / B / P frames, etc. Some implementations provide differentiated QoS handling that takes into account the different importance of PDU sets, for example, by treating packets (i.e., PDUs) belonging to less important PDU sets (or sets of sets) differently, for example, to reduce resource waste.

[0081] A set of data PDUs generated and transmitted by an application over a certain period (for example, a relatively short period) can be called a data burst. In some implementations, a data burst may contain multiple PDUs belonging to one or more PDU sets.

[0082] Figure 2 is a line graph showing the data 200 received over time, illustrating an exemplary way in which 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 seven PDUs. Each PDU contains a serial number for identification (numbered 1 through 7 in this example). The second PDU set 220 is an I-frame containing eight PDUs. Each PDU contains a serial number for identification (numbered 1 through 8 in this example). The third PDU set 230 is a P-frame containing five PDUs. Each PDU contains a serial number for identification (numbered 1 through 5 in this example).

[0083] The second data burst 252 contains the first PDU set 260 and the second PDU set 270. In this example, the first PDU set 260 is an I-frame containing nine PDUs. Each PDU contains a serial number for identification (in this example, they are numbered 1 through 9). The second PDU set 270 is a B-frame containing six PDUs. Each PDU contains a serial number for identification (in this example, they are numbered 1 through 6).

[0084] In some implementations, the PDU set delay budget (PSDB) refers to the upper limit of the time a PDU set may be delayed between the WTRU and the N6 termination point in the UPF. In some implementations, the PSDB refers to the PDU set delay budget (for example, the time from the reception of the first PDU in the PDU set in the WTRU to the time when the last PDU in the PDU set is received (e.g., properly received) at the application layer in the receiver).

[0085] In some implementations, the Time To Live (TTL) of a PDU set refers to how much of the PDU's PSDB remains. For example, if the PSDB is x milliseconds (ms) and yms have passed since the first PDU in the PDU set became available for transmission at the remote WTRU, then the TTL is x-yms.

[0086] In some implementations, the PDU set error rate (PSER) refers to the upper limit of the percentage of PDU sets being processed by a link layer protocol (e.g., RLC layer) where not all PDUs in the set are successfully delivered to a higher layer (e.g., PDCP layer) by the corresponding receiver.

[0087] In some implementations, if a PDU set is associated with and / or marked using PDU Set Batch Processing Display (PSIHI), then for the information contained in the PDU set to be useful, all PDUs in the PDU set must be successfully received by the receiving entity / application (for example, even if all but one of the PDUs in the PDU set are successfully received, the application may not be able to combine and / or render the information in the PDUs of the PDU set).

[0088] In some implementations, some PDU sets may be usable even if a portion of the PDU is not received.

[0089] Several implementations concern 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 the frame and / or PDU and / or PDU set and / or group of PDU sets), as well as other information such as the PSDB, PDU set type, and / or importance, in any one or more of several ways.

[0090] For example, in some implementations, the WTRU may receive one or more indications from the application and / or higher layers about the size of the PDU set. In some implementations, this indication may be received in the packet header of the first packet and / or in the PDUs of the PDU set.

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

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

[0093] In some implementations, for example, in encoding schemes where different types of frames are encoded into different traffic streams (e.g., GOP-based encoding schemes where a single video frame is either an I-frame or a P-frame), the WTRU may receive an indication that associates the data flow with the frame type, for example, only once at the start of the session.

[0094] For example, in some implementations, the representation of the WTRU from the application and / or higher layer may be a bit, or may include bits, where "0" corresponds to a data flow with an I-frame and "1" corresponds to a data flow with a P-frame. Note that in other implementations, any other suitable representation (e.g., if the bits are inverted) may be available, or other encoding may be used to indicate the frame type.

[0095] In some implementations, the WTRU may receive information about the size of each PDU set, and / or per flow (for example, in a GOP-based encoding scheme). In some implementations, this exchange may occur at the start of an XR session. In some implementations, the WTRU may receive updates (e.g., periodic updates) throughout the XR session (e.g., periodically), or only when there is a change in the information (e.g., a change in the size of the PDU set).

[0096] In some implementations, the WTRU may receive information from the application and / or higher layers regarding multiple PDU sets (e.g., the granularity of the group of PDU sets). In some implementations, the application and / or higher layers may group PDU sets based on similarities between individual PDU sets (e.g., same size, type, importance / priority, etc.).

[0097] In some implementations, data importance may be indicated to the WTRU from the application and / or higher layers at different data unit granularities (e.g., importance per frame and / or per PDU and / or per PDU set and / or per group of PDU sets). In some implementations, importance indications may be indicated for each individual data unit, or for the first data unit, and no indications may be sent for subsequent data units until the importance changes, and / or as long as there is no change. In some implementations, importance indications may include bitwise binary indications and / or flags indicating, for example, whether the data is important enough to require special handling (e.g., having importance above a threshold level). In some implementations, importance indications may be based on tables that map different QoS levels in legacy QoS frameworks to different importance levels.

[0098] For example, in some implementations, the four most important QoS levels from the QoS framework may be flagged as important, and as a result, the WTRU may determine that any data mapped to the radio bearer, accompanied by the corresponding QoS flows from those four most important QoS levels, may need to be transmitted before transitioning to another cell and / or gNB or other node b, base station, or infrastructure equipment. In some implementations, any data mapped to the radio bearer, accompanied by QoS flows from the remaining QoS levels, may wait until the HO has finished being transmitted. In some implementations, the indication of importance may take precedence over QoS levels from the conventional QoS framework in some cases (e.g., when data in a buffer is about to expire).

[0099] Several implementations relate to split bearers in dual connectivity (DC). In some DC implementations, the WTRU is served by two nodes, each containing a set of cells, which may be called the master cell group (MCG) and the secondary cell group (SCG). In some implementations, the bearer may be associated with only the MCG or only the SCG, or the bearer may be configured as a split bearer.

[0100] Figure 3 is a block diagram showing an exemplary protocol view 300 of a split bearer. The protocol view 300 shows a bearer split between WTRU 302, gNB1 304, and gNB2 306. In some implementations, WTRU 302 is associated with one PDCP entity 304, and the network-side peer PDCP entity may be terminated in one of the gNBs (or other node b, base station, or infrastructure equipment), either the master gNB or the secondary gNB. In this example, the network-side termination is in PDCP entity 310, gNB1 304. gNB1 304 and gNB2 306 each contain RLC entities 312, 314, MAC entities 316, 318, and PHY entities 320, 322, respectively. WTRU302 includes corresponding RLC entities 324, 326, MAC entities 328, 330, and PHY entities 332, 334, communicating with gNB1 304 and gNB2 306, as shown.

[0101] In some implementations, in DL, the CN may transmit data to the gNB (or other node b, base station, or infrastructure equipment) to which the PDCP is terminated, and transmit the data (e.g., PDCP PDU) directly to the WTRU via a link between that gNB (or other node b, base station, or infrastructure equipment) and the WTRU, or it may be the network's responsibility to forward the PDCP PDU to gNB2 (or other node b, base station, or infrastructure equipment) (e.g., via the Xn interface), and the gNB (or other node b, base station, or infrastructure equipment) transmits the data to the WTRU via a link between it and its own WTRU. For example, in some implementations, the CN may transmit the data to gNB1 304 for direct transmission to WTRU302, or gNB1 304 may forward the data to gNB2 306, and gNB2 306 may transmit the data from itself to WTRU302.

[0102] In some implementations, the WTRU in the UL is configured with one link / path as the primary path and the other as the secondary path. In some implementations, a threshold, sometimes called the UL split buffer threshold, may also be configured. In some implementations, if the UL buffer size for its bearer is less than this threshold, the PDCP pushes data only to the RLC associated with the primary path. However, if the amount of data in the buffer exceeds the threshold, the WTRU may push the data to either path (for example, in some implementations, this is left to the implementation of the WTRU). For example, in some implementations, WTRU302 may configure the path from RLC324 to RLC312 in gNB1 304 as the primary path, and the path from RLC326 to RLC314 in gNB2 306 as the secondary path. If the UL buffer size for the bearer is less than the UL split buffer threshold, the PDCP308 pushes the data only to RLC324. If the UL buffer size for the bearer exceeds a threshold, PDCP308 may push data to either RLC324, RLC326, or both.

[0103] Some implementations involve packet duplication. In some implementations, packet duplication is a mechanism implemented at the PDCP layer (e.g., after a PDCP PDU is generated from a PDCP SDU, after encryption and / or integrity protection is applied, after header compression is performed, and / or after an SN is generated) so that the same PDCP PDU is forwarded to the receiver via multiple paths and / or links. In some implementations, this can be achieved in DC or carrier aggregation (CA) scenarios. In some implementations, since two packets (i.e., the same packet forwarded via different links and / or paths) are identical, a receiving PDCP entity can determine whether and / or when a duplicate PDU is received, as well as / or discard the duplicate PDU (e.g., by detecting the receipt of a PDU with the same SN as a PDU already received).

[0104] In some implementations, for DCs, the WTRU is configured using split bearers to enable packet duplication. In some implementations, for CAs, the WTRU is also configured using multiple RLC entities and associated logical channels.

[0105] In some implementations, replication is network-controlled (e.g., fully network-controlled) on the downlink. In some implementations, received replications are discarded by the WTRU at the PDCP level. In some implementations, replication can be enabled and / or disabled (also known as activated and / or deactivated) on the uplink using the downlink MAC CE received from the network. In some implementations, for CAs, additional constraints (in some cases known as logical channel constraints) are configured to facilitate the transmission of packets and one or more replicated versions over the same carrier (e.g., a logical channel is configured to use only UL resources allocated to the same carrier). In some implementations, packet replication offers the benefit of improved reliability. However, in some implementations, packet replication can reduce system throughput by, for example, the same packet being transmitted multiple times over different links (e.g., for DCs) or carriers (e.g., for CAs), which can result in increased resource consumption.

[0106] Several implementations relate to the Radio Resource Control (RLC) protocol. The RLC protocol is a Layer 2 protocol that lies between the PDCP protocol and the MAC protocol. In some implementations, the tasks of the NR RLC protocol (e.g., the main task) include one or more of the following: transporting upper-layer protocol data units (PDUs) in one of three modes (acknowledgment mode (AM), unacknowledgment mode (UM), and / or transparent mode (TM)); error correction via automatic retransmission requests (ARQ) (e.g., for AM data transport 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 discarding (e.g., UM and AM); RLC re-establishment; and / or protocol error detection (e.g., AM).

[0107] In some implementations, in LTE, data multiplexing is implemented twice: once by concatenating an RLC SDU from one logical channel into one RLC PDU in the RLC layer, and again by multiplexing RLC PDUs from different logical channels into one MAC PDU in the MAC layer. In some implementations, the MAC PDU thus carries information about the same data fields in both the RLC header and / or subheader and the MAC header and / or subheader. In some implementations, the RLC concatenation takes input from MAC layer scheduling; that is, it interacts with the MAC layer to construct an RLC PDU of the appropriate size for each UL grant. In some implementations, the RLC concatenation may be performed, for example, within one scheduling cycle, after the LCP (Logical Channel Prioritization) procedure has occurred in the MAC layer, upon receiving a scheduling decision (e.g., uplink grant size). In some implementations, this means that neither the RLC layer nor the MAC layer can perform any preprocessing before the grant information is received. In some implementations, this can limit the data rate and latency requirements of NR, which are very high compared to LTE. Therefore, in some implementations, the concatenation procedure may be removed from the NR RLC layer, and the RLC may immediately send the PDCP packet to the MAC after header addition, and after the MAC layer receives the scheduling grant and transport block size (TBS) indication, it may concatenate and / or multiplex the data from multiple RLC PDUs and send it over the air interface.

[0108] In some implementations, LTE RLC also includes a sorting function. In some implementations, in NR, this function is removed from RLC and left to the PDCP, as the PDCP already has a sorting function. In some implementations, this has the advantage of improving latency, for example, because delivering out-of-order RLC packets to the PDCP may allow for faster decoding of the out-of-order packets. In some implementations, data transmission or reception can occur 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.

[0109] Figure 4 is a block diagram of the communication interface 400 between WTRU402 and WTRU(or gNB)452, showing an exemplary RLC sublayer schematic model, which illustrates this. In this example, WTRU402 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. WTRU402 includes upper layer 440 and lower layer 445, and WTRU452 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. WTRU452 includes upper layer 490 and lower layer 495.

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

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

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

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

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

[0115] In WTRU402, the transmit and receive AM RLC entity 412 receives PDUs from upper layer 440 on the RLC channel interface as shown, and transmits these PDUs to the transmit and receive AM RLC entity 462 of WTRU402 on the radio interface 499 via lower layers 495 and 445 through the logical channel interface as shown. The transmit and receive AM RLC entity 462 transports the PDUs to upper layer 490 via the RLC channel interface as shown.

[0116] In some implementations, only data PDUs (which may be called TMDs and UMDs) are supported in TM and UM modes. In some implementations, AM mode includes both data and control PDUs. In some implementations, only one control PDU is included in RLC, which may be called a status PDU, as described below.

[0117] In some implementations, the TMD PDU has no header and contains the PDCP PDU received by the RLC, which is then forwarded directly to the MAC. In some implementations, the UMD PDU contains data fields and a UMD PDU header. In some implementations, the UMD PDU header is byte-aligned. In some implementations, segmentation may be applied to the UM and AM. In some implementations, the MAC layer informs the RLC layer of available transport block sizes that are greater than what can be scheduled and transmitted. In some implementations, if the RLC PDU size is greater than the available TB size, the RLC layer segments the RLC SDU into multiple PDUs. In some implementations, if the UMD PDU contains the complete RLC SDU (i.e., no segmentation of the PDCP PDU), the UMD PDU header contains only the SI (Segmentation Information) and Reserve (R) fields. In some implementations, the SI field is a 2-bit field indicating whether the RLC PDU contains the complete RLC SDU or the first, middle, or last segment of the RLC SDU (e.g., 00: complete SDU, 01: first segment of the RLC SDU, 10: last segment of the RLC SDU, 11: middle segment of the RLC SDU). In some implementations, for segmentation, the first and last segments contain only the SN and SI fields, while the middle segment contains an additional field, which may be called SO (segment offset), indicating the position of the RLC SDU segment within the original RLC SDU in bytes. In some implementations, the UMD PDU SN can be configured as 6 or 12 bits. In some implementations, the UM is similar to the TM, except for the segmentation aspect and header. The AM, on the other hand, in some implementations, provides reliability via retransmission (via automatic retransmission requests, ARQ). Therefore, in some implementations, each AM PDU has an SN (even if it is not segmented).In some implementations, the SN for AM can be configured as 12 or 18 bits. In some implementations, the RLC transmit window is a sliding window containing transmitted packets that have not yet been acknowledged by the receiver RLC entity (for example, as a small number of SN packets are received, the window can be advanced to the right, allowing more packets to be transmitted). In some implementations, a larger SN means more RLC packets may remain unresolved at the transmitting entity, but in some implementations, the SN incurs more overhead.

[0118] In some implementations, the AM RLC header may include (for example, additionally) a flag (D / C) indicating whether it is a data PDU or a control PDU. In some implementations, polling bits are also available in the AM RLC header, which can be used by the transmitting RLC entity to trigger the receiving RLC entity to send a status report. In some implementations, the RLC entity may be configured to set the polling bits, for example, depending on the number of bytes / PDUs being transmitted (e.g., every X PDUs, every Y bytes). In some implementations, a poll-block timer may be configured to prevent successive status reports from being triggered, for example, within a threshold time (e.g., a short time). In some implementations, the AMD, like the UMD header, may also include an SI field and an SO field for segmented packets.

[0119] In some implementations, the status PDU is an RLC AM control PDU sent from the receiving RLC entity (e.g., from the gNB for ULs, from the WTRU for DLs) indicating the receiver RLC status (e.g., which packets are received, and which packets are pending and / or missing). In some implementations, the transmitting RLC entity may determine how to advance the RLC transmit window and, based on this information, also determine which packets need to be retransmitted. In some implementations, the RLC AM entity may be configured with a maximum retransmission counter (e.g., this can be a value from 1 to 32, or any other appropriate range in other implementations). In some implementations, whenever a packet is retransmitted, the retransmission count for that packet may be incremented, and when the maximum retransmission count is reached for any RLC packet (for example, when the retransmission count is set to 2 and the packet is not received after the second retransmission, i.e., the third transmission including the first transmission), the RLC entity may indicate this to the RRC entity, which may consider this a radio link failure (RLF), and if the WTRU was operating at the DC, it may trigger a re-establishment or fault recovery via an alternative link (for example, using the SCG if the failed RLC entity was in the MCG, or using the MCG if the failed RLC entity was in the SCG).

[0120] In some implementations, a WTRU supporting an XR experience may receive data units (e.g., PDUs, PDU sets, data bursts, bitstreams) from higher layers or from different devices such as AR glasses and haptic gloves (e.g., via the SL). In some implementations, such data units, which may have variable payload sizes, different periods, jitter, and different interdependencies, may be further processed and transmitted by the WTRU in the UL.

[0121] In some implementations, capacity improvements may include any one or more of the following: i) multiple CG PUSCH transmission opportunities during the duration of a single configured Grant (CG) PUSCH configuration; ii) dynamic display of unused CG PUSCH opportunities based on Uplink Control Information (UCI) by WTRU; iii) Buffer Status Reporting (BSR) improvements including at least a new BSR table; iv) delayed reporting of buffered data on the uplink; and / or v) discarding of PDU sets for DL ​​and UL. In some implementations, power saving improvements may include DRX support for XR frame rates corresponding to non-integer periods (at least through a semi-static mechanism, e.g., RRC signaling). In some implementations, improvements to XR recognition may include any one or more of the following: i) semi-static information per QoS flow (e.g., PDU set QoS parameters), dynamic information per PDU set (PDU set information and identification information), and signaling by CN of data burst end indications, and / or ii) preparation by WTRU of XR traffic support information, e.g., period, UL traffic arrival information.

[0122] In some implementations, the QoS requirements of a service are semi-statically determined by the QoS-related settings of one or more bearers associated with the service and one or more logical channels associated with one or more bearers. In some implementations, this can be achieved by appropriately configuring network settings such as PDCPs, RLCs, and logical channels associated with the bearers, aligned with the service requirements. For example, in some implementations, if latency is more important than reliability, bearers may be associated with transparent RLC entities. In some implementations, if the required reliability exceeds a threshold amount of reliability (e.g., very high), the RLC may be set to AM mode, and replication over another carrier (in the case of a CA) or another link (in the case of a DC) may also be additionally enabled for carrier and / or link diversity.

[0123] In some implementations, under XR traffic conditions, the QoS requirements for PDUs in a PDU set can be flexible. For example, in some implementations, the first PDU in a PDU set transmission may be treated more leniently compared to PDUs in the PDU set that are sent closer to the PSDB expiration. Herein, lenient means lower priority, lower urgency (e.g., prioritizing other more urgent data). In some cases, once a certain percentage of PDUs in a PDU set have been received, the receiver (e.g., the receiver's application) may be able to decode the message, and thus the remaining PDUs in the PDU set may then be delivered on a best-effort basis.

[0124] Therefore, in some implementations, applying a higher maximum RLC retransmission count or always using replication for reliability across the entire PDU set may not be optimal.

[0125] Some issues concern latency versus reliability in single connectivity and / or non-CA connectivity situations. In some implementations, for example, in non-CA / non-DC operation, the reliability of a given bearer can be improved by associating the bearer with an RLC AM entity (e.g., with a greater number of RLC retransmissions allowed). However, in some implementations, this can increase latency, decrease throughput, and / or increase overhead and / or processing (e.g., having an SN in the header, which leads to the need for more buffering while RLC window management awaits an RLC ACK, limiting the maximum achievable throughput).

[0126] Some issues relate to latency versus reliability in CA / DC scenarios. In some implementations, for example in CA / DC operation, the reliability of a given bearer can be increased by performing replication across multiple carriers and / or links. However, in some implementations, this can increase the overall resources used to transmit a given data. In some implementations, for non-XR traffic, replication is determined by the network (e.g., activated and / or deactivated) and configured semi-statically (e.g., via MAC CE). In some implementations, in XR scenarios, as discussed above, the QoS demands of PDUs in a set of PDUs change during the lifetime of the PDU set, and the MN / SN may not always be aware of the demands / characteristics of the PDU set (e.g., UL-heavy traffic). Therefore, in some implementations, always keeping replication active may be inefficient in terms of resources, while always keeping it deactivated may sacrifice and / or reduce reliability.

[0127] Several implementations concern how the WTRU can dynamically adapt reliability-related behaviors and / or configurations (e.g., PDCP replication, RLC mode / retransmission mechanism, etc.) for the bearer in accordance with the flexible QoS demands of different PDUs in the PDU set being transported by the bearer. Some implementations include strategies for conditional RLC entity switching. For example, in some implementations, higher latency of the PDUs in the PDU set may be acceptable at the beginning of the PDU set because the PDU set's TTL (Time To Live) is highest, but higher latency may be undesirable as the TTL approaches zero.

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

[0129] In exemplary implementations of conditional RLC entity switching, the WTRU may operate as follows: The WTRU may receive a DRB / PDCP configuration associated with two or more associated RLC entities with different operating modes (e.g., three RLC entities, one RLC AM, one RLC UM, and one RLC TM), with one of the RLC entities 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 for dynamically determining which RLC entity to send PDUs for the DRB's PDU set. In some implementations, the conditions may include one or more of the following thresholds: TTL of the PDU set to which the PDU belongs, the percentage of PDUs in the remaining PDU sets to be transmitted (or, if the PDUs in the PDU sets can be of different sizes, the percentage of the amount of data in the remaining PDU sets to be transmitted), PSER (either for the PDU set in question or averaged over several PDU sets), the importance of the PDU set or the importance of the PDUs, the UL buffer level (of the DRB in question or the overall UL buffer level), radio conditions (e.g., RSRP threshold, RLC retransmission count, HARQ NACK / ACK level, and / or others), and / or explicit indications from the network.

[0130] In some implementations, the WTRU may be further configured to determine a default / initial RLC entity (for example, based on the characteristics of the PDU set). The WTRU may initiate transmission of PDCP PDUs via / through the default RLC entity. The WTRU may monitor conditions for determining which RLC entity should be used for PDCP. The WTRU may select an RLC entity based on monitored conditions / thresholds, characteristics and transmission status of the PDU set, and current UE / network conditions. The WTRU may send indications about the RLC entity switch (e.g., the last SN (of RLC or PDCP) transmitted using the previous RLC entity, the first SN (of RLC or PDCP) transmitted via the current RLC entity, etc.) to the network (e.g., gNB / DU). The WTRU may transmit PDCP PDUs via the determined RLC entity (and associated logical channel).

[0131] Some implementations include strategies for 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 operation (e.g., enables and / or disables retransmission) depending on the characteristics of the PDU set (e.g., importance level) and the current transmission status of the PDU set (e.g., thresholds that consider TTL, PSER, UL buffer level, percentage of remaining PDU sets to be transmitted, and / or other factors), as well as the current WTRU and / or network conditions (e.g., radio conditions, buffer level).

[0132] In an exemplary implementation of adaptive RLC entities, the WTRU may behave as follows: The WTRU may receive configurations for the DRB and associated RLC AM entities with a default maximum retransmission count value. The WTRU may receive configurations for conditions to determine whether to disable RLC retransmissions (maximum retransmissions = 0) or enable them (e.g., maximum retransmissions > 1). In some implementations, the conditions may include one or more of the following thresholds: TTL of the PDU set to which the PDU belongs, the percentage of PDUs in the remaining PDU sets to be transmitted (or, for example, the percentage of the amount of data in the remaining PDU sets to be transmitted, if it is possible that the PDUs in the PDU set can be of different sizes), PSER (for example, either for the PDU set in question or averaged over several PDU sets), importance of the PDU set or PDUs, UL buffer level (for example, the UL buffer level of the DRB in question or the overall UL buffer level), radio conditions (for example, RSRP threshold, number of RLC retransmissions, HARQ NACK / ACK level, ...), and / or explicit indications from the network (for example, MAC CE).

[0133] A WTRU may initiate sending PDCP PDUs via / through the default RLC AM configuration. A WTRU may monitor conditions for enabling / disabling RLC retransmissions. A WTRU may select an RLC AM retransmission count based on monitoring conditions / thresholds and current UE / network conditions (e.g., setting it to 0 disables retransmissions). In some implementations, a WTRU may flush buffered RLC AM packets waiting for an ACK if retransmissions are disabled. A WTRU may send an indication of retransmission enabled / disabled (e.g., RLC control PDU, RLC header, (MAC CE), etc.) to the gNB / DU. A WTRU may be configured to disable RLF triggering (and subsequent re-establishment) based on the number of retransmissions for this RLC entity (however, RLF triggering based on maximum retransmissions on other RLC entities can still behave like legacy).

[0134] Some implementations include strategies for conditional PDCP replication. For example, in some implementations, the PDCP and / or bearer is associated with one or more RLC entities associated with different carriers (e.g., CAs) or links (e.g., DCs). In some implementations, the WTRU may be configured with conditions for when to replicate the PDUs in the PDU set, based on the characteristics of the PDU set (e.g., importance level), the current transmit status of the PDU set (e.g., thresholds considering TTL, PSER, UL buffer level, percentage of remaining PDU sets to be transmitted, etc.), and the conditions of the current WTRU and / or network (e.g., radio conditions, buffer level).

[0135] In an exemplary implementation of conditional PDCP replication, the WTRU may operate as follows: The WTRU may be configured with a CA or DC. The WTRU may receive a configuration of a DRB (divided) with one or more RLC entities, each RLC associated with a specific carrier (e.g., in the case of a CA) or a specific link / cell group (e.g., in the case of a DC). The WTRU may receive a configuration of conditions for determining whether to replicate at least a subset of the PDCP PDUs in the DRB's PDU set, the default replication mode (on or off), the default path (e.g., RLC entity), and 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 PDUs in the remaining PDU set to be transmitted (or, if the PDUs in the PDU set can be of different sizes, the percentage of the amount of data in the remaining PDU set to be transmitted), PSER (e.g., the minimum percentage of PDUs in the PDU set that are expected to be successfully received at the receiving entity), the importance of the PDU set or PDU, the UL buffer level (on the primary path, on the alternate path, overall UL buffer level, considering only the bearer in question, etc.), and / or radio conditions (e.g., RSRP threshold, number of RLC retransmissions, HARQ NACK / ACK level, etc.).

[0136] In some implementations, the WTRU may initiate PDCP replication if the default replication mode is on. The WTRU may monitor the conditions for enabling and / or disabling PDCP replication. The WTRU may determine the replication state and, if the determined replication state is on, process the PDCP PDU (e.g., after applying security, adding headers, etc.) before sending the PDCP PDU through both RLC entities. The WTRU may inform the network when PDCP replication is turned on and / or off.

[0137] Some implementations include strategies for conditional transmission on a second path. For example, in some implementations, the PDCP and / or bearer are associated with one or more RLC entities, each associated with a different carrier (e.g., CA) or link (e.g., DC). In some implementations, the WTRU is configured to transmit PDCP PDUs on one RLC entity (e.g., the default path, the path with currently available grants, etc.), and if certain conditions are not met (e.g., within a given time), the WTRU may transmit duplicates of the PDUs on other RLC entities (e.g., a threshold considering RLC status reception indicating ACK / NACK reception associated with the initial transmission within a given time, a buffer level on the first path, radio conditions on the first path / carrier, etc.). In some implementations, different conditions may be configured for different PDU sets characteristics (e.g., importance level) and transmit status (e.g., TTL, percentage of PDUs already transmitted, etc.). In some implementations, the WTRU may also be configured to switch the default path until a second set of conditions is met or until a certain amount of time has elapsed.

[0138] In an exemplary implementation of conditional RLC entity switching, the WTRU may operate as follows: The WTRU may be configured with a CA or DC. The WTRU may receive a configuration of a DRB (e.g., a split DRB) with one or more RLC entities, each RLC associated with a specific carrier (e.g., in the case of a CA) or a specific link and / or path (e.g., in the case of a DC), with one of the RLC entities set as the default. The WTRU may receive a configuration of conditions for deciding to retransmit a PDCP PDU, which is on a second path, after a given configured time length has elapsed since the transmission of data on a first path and the packet has not been acknowledged, the conditions may include one or more thresholds, namely, the reception of one or more NACKs (e.g., an RLC status indicating a NACK for the PDU, an RLC status indicating a NACK for another PDU, etc.), the number of HARQ retransmissions, the buffer level on the first or second path, and / or the radio link quality on the first and / or second path. In some implementations, the conditions may further depend on the characteristics of the PDU set (e.g., importance level) and the transmission status of the current PDU set (e.g., TTL, percentage of PDUs in the remaining PDU set to be transmitted). In some implementations, after processing the PDCP PDU (e.g., after applying security, after adding headers, etc.), the WTRU may first send the packet on the first / default path.

[0139] In some implementations, if a configured time has elapsed and the packet has not been acknowledged, the WTRU may check for conditions to retransmit the packet. If one or more of the conditions for retransmission are met on one or more other paths, the WTRU may send a copy of the PDCP PDU over one or more other paths. The WTRU may be configured, for example, to stop attempting to retransmit the packet in question on the first path after it has sent a copy of the PDCP PDU over one or more other paths.

[0140] For example, as discussed above, various embodiments are considered to address various problems and / or implement various measures. For example, as discussed herein, in some implementations, the network may include, for example, base stations (e.g., gNB, TRP, RAN nodes, access nodes), core network functions (e.g., AMF, SMF, PCF, NEF), and application functions (e.g., edge server functions, remote server functions).

[0141] As discussed herein, in some implementations, a flow may correspond to either a QoS flow or a data flow (e.g., a data flow, PDU set, or data burst containing one or more PDUs, which may be interdependent of each other and / or associated with one or more QoS requirements, such as latency, data rate, reliability, or RTT latency). Different flows that, in some cases, originate from a common application / experience source and / or are destined for a common destination device / UE / WTRU or a group of associated devices / UE / WTRUs may be called associated flows or correlated flows.

[0142] As discussed herein, in some implementations, a data unit may refer to one or more frames (e.g., media, video and / or audio frames, slices, and / or segments), PDUs, PDU sets, data bursts, groups of frames, PDUs, PDU sets, data bursts, and / or bitstreams. In some implementations, such data units, which may be transmitted or received sequentially (e.g., one after the other) or in parallel (e.g., over different channels / links / resources) by a WTRU, may or may not be interdependent of each other.

[0143] As discussed herein, in some implementations, a transport configuration may 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 individual layers within the AS protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, and / or other protocol layers (e.g., new protocol layer)), parameters associated with logical channel prioritization (LCP) (e.g., priority, PBR, BSD), BWP, carriers, radio links and / or interfaces (e.g., Uu links, SL), and / or radio resources (e.g., a set of one or more frequency resources, time resources, and / or spatial resources, such as symbols, slots, subcarriers, resource elements, and / or beams). For example, in some implementations, radio resources may be associated with configured grants (CG), dynamic grants (DG), and / or any other resource grants or grant-free resources.

[0144] As discussed herein, in some implementations, a PDU set and / or their associated characteristics and / or characteristics 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 media units, or video frames and / or slices. In some implementations, such data units within a PDU set or data burst may be interdependent 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 one another in terms of, for example, the number of PDUs in the PDU set, payload size, correlation between PDU sets, importance and / or priority of data units, transmission status (e.g., the percentage of PDUs of one or more data units that were successfully transmitted / received), and / or the effective data rate and / or effective reliability associated with the transmission.

[0145] In the example, such attributes associated with a set of PDUs may be visible in one or more lower layers (e.g., PDCP, RLC, MAC, PHY sublayers / multiple PHY sublayers) to support additional activities (e.g., prioritization, mapping to LCH, multiplexing to one or more TBs, scheduling) based on any of the following: (1) Marking in the data unit. For example, such marking may include a sequence number, ID, index, timestamp, and / or a time offset value (e.g., relative to a reference time) in the header of the data unit. In some implementations, such marking may be performed by higher layers, any preceding sublayers / layers, and / or another device and / or WTRU. (2) Reception of a display such as a control PDU (e.g., display of an application, higher layer, and / or NAS layer, PDCP control PDU, RLC control PDU, MAC CE, and / or DCI / UCI). In some implementations, such representations may be received by the WTRU from, for example, higher layers and / or preceding layers, from another device and / or WTRU (e.g., on the SL), and / or from the network. (3) Mapping of data units from higher layers to configurations associated with lower layers. For example, when a WTRU maps a PDU to one or more radio bearers, logical channels (LCHs), TBs, and / or HARQ processes that may be configured to provide similar forwarding services, it may be possible to see one or more attributes of the higher layer in the lower layer. (4) Tracking of PDU attributes in any buffer associated with a sublayer, radio bearer logical channel, or HARQ process.For example, a WTRU may track attributes associated with a PDU set based on any of the following: the time elapsed since the reception of the first PDU in the PDU set, the remaining time for the PDUs in the PDU set to satisfy the PDSB, the jitter between the arrival of one or more PDUs within and / or across the PDU set, the percentage of remaining PDUs in the PDU set that are expected to be received, and / or the payload size. (5) Constraints associated with the sublayers, radio bearers, logical channels, and / or HARQ processes to which the data units of the PDU set may be mapped. For example, a WTRU may be able to see the data units and, based on configured constraints associated with one or more sublayers, radio bearers, and / or LCHs to which the data units may be mapped, determine the corresponding activity (e.g., performing prioritization per LCP, performing mapping to constrained CG configurations, TB, HPI).

[0146] As discussed herein, in some implementations, a data burst may refer to data generated by an application within a period (e.g., a short period) containing PDUs from one or more PDU sets. Such attributes, associations, and / or interdependencies (e.g., within and between PDU sets) may include the start and / or end indicators of the PDU set / data burst (e.g., via sequence number, start / end indicator, timestamp), start and / or end times, duration, payload size, periodicity, importance and / or priority, and / or QoS (e.g., PSDB), and may be visible to the AS layer (e.g., using associated IDs) and / or handled at the AS layer while recognizing the association between data transmission in UL and reception in DL.

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

[0148] As discussed herein, in some implementations, QoS and / or data flows may refer to situations in which an application's PDUs and / or sets of PDUs can be encoded and / or delivered by the application to a WTRU (in UL) or network (in DL) via one or more QoS and / or data flows. In some implementations, different QoF flows carrying PDUs and / or sets of PDUs associated with an XR application and / or experience may be visible to the AS layer and / or handled at the AS layer while recognizing such associations between data transmission and reception.

[0149] As discussed herein, in some implementations, traffic characteristics and PDU set-level QoS requirements may apply. (1) The PDU set delay budget (PSDB) may refer to the time between the reception of the first PDU (e.g., at the UPF in DL, at the WTRU in UL) and the successful delivery of the last PDU arriving in the PDU set (e.g., at the WTRU in DL, at the UPF in UL). In some implementations, the PSDB is an optional parameter and, if provided, may supersede the PDB. (2) The PDU set batch processing indication (PSIHI) may indicate whether all PDUs in the PDU set are required for use of the PDU set by the application layer. (3) The PDU set error rate (PSER) may refer to the upper limit of the PDU set loss rate unrelated to congestion between the RAN and WTRU. (4) Jitter may refer to the variation in the expected time during which one or more data units may be received or transmitted. For example, for a set of data units that are expected to be received periodically at different periodic times, jitter may refer to the variation with respect to the periodic time (for example, for a data unit that is expected to be received T1ms before or T2ms after the expected time T, the jitter range is T2-T1). Jitter may refer to an instantaneous value or a statistical value (e.g., mean, variance, standard deviation, maximum / minimum value). (5) Remaining delay may refer to the length of time remaining to receive or transmit one or more PDUs of the PDU set before the PSDB. Remaining delay may also be called the time to live (TTL) associated with the PDU set.

[0150] As discussed herein, in some implementations, a multi-PUSCH CG may correspond to one or more configured resource or configured grant (CG) configurations, where each CG configuration may include a set of slots and / or continuous or discontinuous PUSCH opportunities for each CG period. For example, a multi-PUSCH CG may include one or more CG periods (e.g., where each CG period may repeat periodically using a periodic value), where a CG period in a multi-PUSCH CG may include one or more continuous or discontinuous slots, where a slot during a CG period of a multi-PUSCH CG may include one or more continuous or discontinuous PUSCH opportunities, and / or where a slot and / or PUSCH opportunity during a CG period of a multi-PUSCH CG may include one or more continuous or discontinuous symbols having a symbol length (e.g., a time-domain resource). In some implementations, a PUSCH opportunity may include one or more resource blocks or groups of resource blocks in the frequency domain.

[0151] As discussed herein, in some modes (e.g., three RLC entities, one RLC AM, one RLC UM, one RLC TM), the configuration may be as follows: WTRU is configured using implementation-specific conditions, and the use of PUSCH may refer to one or more slots or the number, location, arrangement, or timing of one or more PUSCH opportunities during a period, which may be associated with one or more multi-PUSCH CG configurations. As discussed herein, in some implementations, the terms path and carrier may be used interchangeably. As discussed herein, in some implementations, the terms packet and PDU may be used interchangeably.

[0152] Some implementations include strategies for conditional RLC entity switching. For example, in some implementations, a PDCP entity is associated with multiple RLC entities that have different types of conditions for pushing PDCP PDUs in a PDU set, depending on the characteristics of the PDU set (e.g., importance level) and the current transmission status of the PDU set (e.g., thresholds considering TTL, PSER, UL buffer level, percentage of remaining PDU sets to be transmitted, etc.), as well as the current WTRU / network conditions (e.g., radio conditions, buffer level).

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

[0154] The WTRU may receive a configuration of conditions for determining which RLC entity to transmit the PDUs of a set of PDUs in a DRB to, where the conditions may include one or more of the following thresholds: the TTL of the PDU set to which the PDUs belong; the percentage of PDUs in the remaining PDU sets to be transmitted (or, for example, the percentage of the amount of data in the remaining PDU sets to be transmitted, if it is possible that the PDUs in a set of PDUs can be of different sizes); PSER (for example, either for the PDU set in question or averaged over several PDU sets); the importance of the PDU set or the importance of the PDUs; the UL buffer level (for example, the UL buffer level of the DRB in question or the overall UL buffer level); radio conditions (for example, the RSRP threshold, the number of RLC retransmissions, the HARQ NACK / ACK level, and / or others); and / or explicit indications from the network.

[0155] The WTRU may be configured to determine a default / initial RLC entity (for example, based on the characteristics of a PDU set). The WTRU may initiate transmission of PDCP PDUs via and / or through the default RLC entity. The WTRU may monitor the conditions for which an RLC entity should be used. For example, this may be done continuously (for example, for each PDCP PDU to be transmitted) or periodically (for example, the period can be defined by time, the number / percentage of PDUs / bytes in the PDU set to be transmitted, the number / percentage of elapsed PSDBs, etc.). The WTRU may also receive explicit indications from the network (e.g., MAC CE, RLC control, and / or status PDUs) indicating which RLC entity should be used thereafter.

[0156] A WTRU may select an RLC entity based on monitoring conditions / thresholds and the current WTRU and / or network conditions. For example, a WTRU may send gNB and / or DU indications about a switch (e.g., if switching alternately while a set of PDUs is in progress is supported). A WTRU may send PDCP PDUs through the determined RLC entity (e.g., and associated logical channel).

[0157] Some implementations involve strategies for configuring the WTRU with PDCP entities and one or more RLC entities per PDCP. In some implementations, one or more RLC entities may be associated with each PDCP entity, but this is only done in the case of a CA or DC, in which case different RLC entities are associated with and / or constrained to only one carrier (e.g., in the case of a CA) or one link, path, and / or destination node (e.g., in the case of a DC), and the reason for configuring multiple RLC entities is to use link and / or carrier diversity for higher reliability (e.g., for CA or DC in the case of replication) and / or higher throughput (e.g., for DC in the case of split-bearer path switching techniques, because in the case of a CA, it may not be necessary for multiple RLC entities to utilize throughput from multiple carriers). In some such cases, the RLC modes of the two legs may be assumed to be the same (e.g., the QoS demands of the bearers may not change whether split-bearer and / or replication are used).

[0158] In some implementations, the WTRU may be configured with PDCP entities associated with one or more RLC entities, for example, in which case the RLC entities are configured to operate in different modes. For example, in some implementations, the first RLC entity associated with the PDCP entity may be configured using RLC AM mode, and the second RLC entity may be configured using RLC TM mode. In some implementations, the WTRU is configured to operate in CA or DC even if it is not operating in CA or DC. In some implementations, different RLC entities may use separate logical channels. In some implementations, different RLC entities may use a common logical channel.

[0159] Some implementations include a policy regarding the configuration of the WTRU using 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 be in initial / default mode (e.g., RLC AM entity, RLC UM entity, or RLC TM entity).

[0160] In some implementations, the WTRU may determine the initial and / or default mode based on, for example, one or more characteristics of the PDU set associated with the PDCP entity in question. For example, in some implementations, if the WTRU receives the first PDU of the PDU set and has PDU set information such as the PSDB or importance level (for example, received from the application layer along with or prior to the first PDU of the PDU set), the WTRU uses that information to decide whether to initiate transmission via 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 decide to initiate transmission using an RLC AM entity, and for a second subset of PDUs in the PDU set, the WTRU may decide to continue using the same RLC AM entity or change / switch to an RLC TM entity. In some implementations, such a decision to initiate transmission using an RLC entity configured in a particular mode may be based on the PDU set information and / or characteristics. For example, if the PSDB is greater than a configured threshold, start with an AM entity; if the PSDB is less than a configured threshold, start with a TM entity; if the importance level is above a configured threshold, start with an AM entity; if the importance level is below a configured threshold, start with a TM entity; if the PDU set is a PSIHI PDU set, start with an AM entity; and if the PDU set is expected to have PDUs greater than a configured threshold, start with a UM and / or AM entity (for example, to enable segmentation), and so on.

[0161] In some implementations, the WTRU may determine its initial and / or default mode based on one current WTRU condition. For example, if the UL buffer level is above a certain threshold, it may start in the TM and / or UM entity; if the UL buffer level is below a certain threshold, it may start in the AM entity; if the WTRU overheat level is above a certain threshold, it may start in the TM / UM entity; if the WTRU overheat level is below a certain threshold, it may start in the AM entity; if the WTRU battery level is above a certain threshold, it may start in the AM entity; if the WTRU battery level is below a certain threshold, it may start in the TM / UM entity; if the experienced / past / recent UL throughput is greater than a certain threshold, it may start in the AM entity; and if the experienced / past / recent UL throughput is less than a certain threshold, it may start in the TM and / or UM entity, and so on.

[0162] 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, and if the radio quality (e.g., RSRP / RSRQ) is above a configured threshold, the TM / UM entity is used. In some implementations, the WTRU may determine the initial and / or default RLC entity based on the WTRU implementation.

[0163] Some implementations involve strategies for configuring the WTRU using conditions to determine the current RLC entity, which depends on the characteristics of the PDU set.

[0164] In some implementations, the WTRU is configured to determine which RLC entity to use based on one or more characteristics of the PDU set associated with the PDCP entity in question. For example, if the PSDB is greater than a threshold (e.g., a configured threshold), use the AM entity; if the PSDB is less than a threshold (e.g., a configured threshold), use the TM entity; if the importance level is above a threshold (e.g., a configured threshold), use the AM entity; if the importance level is below a threshold (e.g., a configured threshold), use the TM entity; if the PDU set is a PSIHI PDU set, use the AM entity; and if the PDU set is expected to have PDUs greater than a threshold (e.g., a configured threshold), use the UM and / or AM entities (i.e., to enable segmentation), and so on.

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

[0166] In some implementations, the WTRU is configured to determine which 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), use the TM / UM entity; if the UL buffer level is below a threshold (e.g., a configured threshold), use the AM entity; if the WTRU overheat level is above a threshold (e.g., a configured threshold), use the TM / UM entity; if the WTRU overheat level is below a threshold (e.g., a configured threshold), use the AM entity; if the WTRU battery level is above a threshold (e.g., a configured threshold), use the AM entity; if the WTRU battery level is below a threshold (e.g., a configured threshold), use the TM / UM entity; if the experienced / past / recent UL throughput is greater than a threshold (e.g., a configured threshold), use the AM entity; if the experienced / past / recent UL throughput is less than a threshold (e.g., a configured threshold), use the TM / UM entity, and so on.

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

[0168] In some implementations, the WTRU continuously checks for conditions to switch RLC entities (for example, for each PDCP PDU or subset of one or more PDUs in a set of PDUs to be transmitted, the WTRU checks for conditions to determine which RLC entity should be used for that RLC entity). In some implementations, the WTRU periodically checks for conditions to switch RLC entities, for example using a configured period (for example, period0 starts when the first PDU in the PDU set is transmitted, period1 starts after period0+ periods have elapsed, and the WTRU uses the same RLC entity within a single period, etc.). In some implementations, the period can be a time length or the number of PDUs and / or bytes transmitted, etc. In some implementations, the WTRU may receive an explicit indication from the network of which RLC entity should be used.

[0169] Some implementations include measures to prevent frequent switching. For example, in the above, WTRU may be configured using a trigger time (TTT) for switching to occur. For example, in some implementations, the trigger condition must be satisfied for at least the TTT before the condition is considered satisfied. In some implementations, a common TTT value may be configured for all conditions, or each condition may have a separate TTT value.

[0170] In some implementations, the WTRU may be further configured with a delay timer that indicates how long it will wait before it can perform an RLC switchover again. In some implementations, the delay timer may be a value of time length, or it may be based on data size (e.g., the number of bytes that must be sent in one RLC entity before a switchover can be performed, the number of RLC / PDCP packets to be sent, etc.).

[0171] In some implementations, the WTRU may be configured to disable the prohibit timer under certain conditions. For example, in some implementations using an RLC AM entity, if the TTL falls below a certain value and / or percentage while more than a certain percentage of the PDU set of PDUs remain to be transmitted, while the prohibit timer for not switching the RLC entity is still running, the WTRU may disable and / or stop the prohibit timer and switch to RLC TM mode.

[0172] Some implementations include strategies for the WTRU to send indications to the network. For example, in some implementations, the WTRU may send an indication to the network once it has determined the initial and / or default RLC entity based on, for example, one of the strategies described above (or, for example, per implementation of the WTRU). In some implementations, this indication may be implicit with respect to the selected RLC entity (for example, the network may determine the selected RLC entity based on the RLC entity that the first PDU in a PDU set received) or explicit (for example, the WTRU may send an indication in, for example, a MAC CE, an RLC control PDU, or an indication in the RLC header). In some implementations, the latter helps the network determine the selected RLC entity even if the RLC entities shared the same logical channel and / or if a switch of RLC entities occurs before the first packet reaches the network (for example, the first packet is delayed during an RLC AM retransmission and the second packet is sent via TM mode and received before the first packet).

[0173] In some implementations, the WTRU sends an indication to the network after deciding to switch RLC entities based on one of the above strategies (or based on the WTRU's implementation). In some implementations, this indication may be implicit with respect to the selected RLC entity (for example, the network determines the selected RLC entity based on the network determining that data has begun arriving through a different RLC entity than the one the previous packet was received through) or explicit (for example, the WTRU sends an indication, such as in a MAC CE, RLC control PDU, or indication in the RLC header). In some implementations, the latter helps the network determine which RLC entity to choose, even if the RLC entities shared the same logical channel and / or if a switch of RLC entities occurred before the last packet sent using the previous RLC entity reached the network (for example, if a packet of SN x was delayed in an RLC entity during an RLC AM retransmission, and SN x+1 was sent via TM mode and received correctly, and the network receives SN x after SN x+1, it could incorrectly determine that a second switch to AM mode occurred, only if implicit representation was used).

[0174] Some implementations include strategies regarding the DL (Digital Readiness) aspects. Some of the exemplary implementations described above are explained with respect to UL (e.g., how the WTRU dynamically determines RLC entities and how that informs the network), and in some implementations, network behavior is undefined and / or left to the network implementation. Some implementations include RLC receiver behavior in the WTRU to support similar dynamic switching of RLC entities in the DL.

[0175] In some implementations, the WTRU may be configured to receive an indication from the network for switching the receiving RLC entity associated with a PDCP entity. In some implementations, this indication may be implicit (e.g., an RLC entity and a different associated logical channel and a decision to receive data over the logical channel used for the previous one or more packets), or it may be explicit (e.g., MAC CE, RLC control PDU, flags in the RLC header, etc.).

[0176] In some implementations, after determining that an RLC receiving entity has been switched from an AM RLC entity to an UM / TM, the WTRU may be configured to reset some of the state variables and counters of the RLC receiving window that is being switched to (for example, the leftmost of the receiving window is initialized to the first SN, e.g., 0, the retransmission count is set to 0, all timers such as the ban / pole timer are reset, etc.).

[0177] In some implementations, the WTRU may decide to retain the SN of the PDU associated with the previous RLC entity after switching to a new RLC entity. In some implementations, the WTRU may reset a timer when switching to a new RLC entity, for example. In some implementations, such retention of the SN of the previous RLC entity may be done to facilitate avoiding interruptions to procedures in the receiving entity (e.g., sorting of PDUs in the receiving PDCP entity).

[0178] Some implementations include strategies for other aspects. In some of the exemplary implementations described above, the buffer level may be, for example, the overall buffer level or the buffer level of several bearers (for example, bearers with a certain QoS profile, e.g., those with stricter latency and / or bitrate requirements compared to a certain level or the bearer configuration of the PDCP entity in question).

[0179] For example, in some of the implementations described above, the WTRU may be constructed using any combination of the above conditions. For instance, in some implementations, the TTL is below threshold 1, the radio quality is above threshold 2, the PDU has a significance level above x, and uses an RLC AM entity.

[0180] For example, in some of the implementations described above, the WTRU may be configured to consider not only the current value but also the mean and / or filtered value within a configured time frame, or the rate of change of the value, or the threshold may be based on other statistical measures (e.g., mean, standard deviation, minimum / maximum value within the evaluation period).

[0181] For example, in some of the implementations described above, it is assumed that the importance levels of the PDUs in a set of PDUs are the same (i.e., one importance level per PDU set). However, in some implementations, such a policy is applicable when different PDUs in a set of PDUs may have different importance levels. In some implementations, the determination of RLC entities is performed on a per-PDU level basis in such cases.

[0182] In some implementations, RLC entity switching can take effect immediately. For example, packets that were pending retransmissions (e.g., if the switch was from AM to UM / TM) may be flushed from the RLC AM buffer, or they may be retransmitted once via TM / UM (e.g., the AM entity notifies the PDCP, and the PDCP pushes the PDCP packet in question to the TM entity).

[0183] In some implementations, RLC entity switching takes effect only on newly received PDCP packets after the RLC entity has been switched (for example, including the current PDCP packet if the switching is determined on a packet-by-packet basis). In such cases, some implementations may have switching periods in which more than one RLC entity is being used simultaneously (for example, an RLC AM is being used to finish sending a packet that was a pending retransmission, while new packets are being sent via an RLC TM).

[0184] In some implementations, more than one RLC entity may be active simultaneously. For example, in some implementations, a WTRU may, during a switching period, wait for a packet that was already being transmitted by one of the RLC entities to be properly transmitted while simultaneously transmitting a new packet through another RLC entity. In some implementations, RLC entities are selected based on the importance of the PDU (for example, if PDUs in a set of PDUs can have different importance levels), with PDUs of higher importance than a certain level being transmitted through the RLC AM entity, while less important PDUs are transmitted through the RLC TM entity, and so on.

[0185] Figure 5 is a flowchart illustrating an exemplary procedure performed by a WTRU for wireless communication involving conditional RLC entity switching, as discussed further above, for example. In 502, the WTRU receives a PDCP configuration associated with multiple RLC entities. In 504, the WTRU receives a configuration of conditions for determining which RLC entity will transmit data. In 506, the WTRU monitors the conditions. In 508, data is transmitted on the RLC entities based on the conditions. Other implementations may include additional steps, fewer steps, and / or different steps, as discussed above, for example.

[0186] Some implementations include strategies for adaptive RLC entities. For example, in some implementations, the DRB and / or PDCP are associated with RLC AM entities that dynamically adapt their behavior and / or operation (e.g., enable / disable retransmission) depending on the characteristics of the PDU set (e.g., importance level) and the current transmission status of the PDU set (e.g., thresholds considering TTL, PSER, UL buffer level, percentage of remaining PDU sets to be transmitted, etc.), as well as the current WTRU and / or network conditions (e.g., radio conditions, buffer level).

[0187] In an exemplary implementation of adaptive RLC entities, the WTRU may behave as follows: The WTRU may receive the configuration of the DRB and associated RLC AM entities with a default maximum retransmission count value.

[0188] The WTRU may receive a configuration of conditions for determining whether to disable (maximum retransmissions = 0) and / or enable (e.g., maximum retransmissions > 1) RLC retransmissions. In some implementations, the conditions may include one or more of the following thresholds: TTL of the PDU set to which the PDU belongs, the percentage of PDUs in the remaining PDU sets to be transmitted (or, if the PDUs in the PDU sets can be of different sizes, the percentage of the amount of data in the remaining PDU sets to be transmitted), PSER (either for the PDU set in question or averaged over several PDU sets), importance of the PDU set or PDUs, UL buffer level (of the DRB in question or the overall UL buffer level), radio conditions (e.g., RSRP threshold, number of RLC retransmissions, HARQ NACK / ACK level, etc.), and / or explicit indications from the network (e.g., MAC CE).

[0189] The WTRU may initiate sending PDCP PDUs via / through the default RLC AM configuration. The WTRU may receive and monitor conditions for enabling / disabling RLC retransmissions. The WTRU may select an RLC AM retransmission count based on monitoring conditions / thresholds and current UE / network conditions (e.g., setting it to 0 disables retransmissions). In some implementations, the WTRU may flush buffered RLC AM packets waiting for an ACK if retransmissions are disabled. The WTRU may send an indication of retransmission being enabled / disabled, e.g., an RLC control PDU, RLC header, (MAC CE), etc., to the gNB / DU. The WTRU may be configured to disable RLF triggering (and subsequent re-establishment) based, for example, the number of retransmissions for this RLC entity (e.g., RLF triggering based on maximum retransmissions on other RLC entities can still behave like legacy).

[0190] Some implementations involve strategies for RLC entities that are aware of PDU set information. In some implementations, the PDCP informs the RLC entity about 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 can be facilitated by the PDCP informing the RRC of the WTRU, which then constitutes the RLC entity.

[0191] In some implementations, the network uses PDU set information to construct RLC entities (for example, the WTRU may have previously communicated the PDU set information to the gNB and / or DU, or the network may have received this information in other ways, such as through packet inspection or communication with an application server).

[0192] Some implementations include policies for RLC AM entities with adaptive retransmission behavior. In some implementations (e.g., in legacy NR / LTE), an 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 properly received (e.g., as determined by the RLC status PDU received from a peer RLC entity), in some implementations the packet may be retransmitted. If the packet is still not received after the maximum number of retransmissions, in some implementations the WTRU may conclude that the radio link is not good enough and declare a Radio Link Failure (RLF), which may result in the re-establishment of the connection. 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., set to 1, at least one retransmission is allowed before declaring an RLF; set to 32, 32 retransmissions are allowed, etc.).

[0193] In some implementations, the WTRU may be configured with an RLC AM entity that can be configured with a maximum retransmission count value of 0, indicating that it will not perform retransmission despite being an RLC entity operating in AM mode. In some implementations, when an RLC AM entity is configured with a maximum retransmission count value of 0, it advances the RLC transmit window as if the packet had been successfully received at the receiver (for example, as if an RLC status PDU acknowledging receipt of the packet had been received). That is, the packet is flushed from the RLC immediately after being pushed to the MAC.

[0194] In some implementations, the WTRU may be configured with an RLC AM entity that can be configured with a maximum retransmission count value greater than 1, and after retransmitting the packet a permitted number of times, it may flush the packet in question and advance the RLC transmit window as if the packet had been properly received at the receiver (i.e., as if an RLC status PDU acknowledging receipt of the packet had been received). In some implementations, the WTRU may be configured with an RLC AM entity if the maximum retransmission count value is variable for each RLC packet (for example, the first packet may have a maximum retransmission count value of 1, the second packet may have a maximum retransmission count value of 3, etc.). In some implementations, the maximum retransmission count value is common to all RLC packets in the transmit buffer. For example, if the maximum retransmission count value is 3 and there is already a packet in the second retransmission, when the maximum retransmission count is changed to 2, the WTRU may remove the packet from the retransmission packets as if a status PDU indicating proper reception had just been received.

[0195] Some implementations include a policy for what to do 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 RLF triggering for that RLC entity based on the retransmission count.

[0196] In some implementations, even if the retransmission count is greater than zero, the WTRU may be configured to disable RLF triggering for an RLC entity when the maximum retransmission count for a given packet is reached. That is, as described in the above strategy, the WTRU may behave as if the packet was received correctly and flush it from the retransmission buffer. In some implementations, the WTRU may be configured to record information about the number of RLC packets that have reached the maximum retransmission count. For example, this could be a log stored in the WTRU containing information such as the SN of the packet in question, a timestamp, and the radio conditions at the time. Alternatively, the WTRU may take statistical information about such events (e.g., the number of occurrences, the frequency of occurrences, the percentage of packets that experience it, etc.). In some implementations, the WTRU may be configured to transmit the recorded information when the network requests it. In some implementations, the WTRU may be configured to transmit recorded information when certain conditions are met (for example, periodically when the number of occurrences since the last such report exceeds a certain level, when the number of occurrences within a given time period exceeds a certain level, when the size of the report is greater than a certain value, and / or other conditions).

[0197] In some implementations, the WTRU may be configured to send an indication that it has recorded information (for example, based on similar conditions as above to send a report). In some implementations, the WTRU may be configured with conditions that can trigger an RLF and subsequent re-establishment, for example, if it was not possible to send more than a certain number of packets before reaching the retransmission count. In some implementations, this may be constrained by time length (e.g., failure to correctly send a certain number of packets within the retransmission count within a given time length). In some implementations, if the maximum retransmission is reached and the packet is flushed, this may not be counted as an occurrence of failure if a status PDU indicating the last retransmission was successful is later received. In some implementations, the invalidation of RLF triggering may be packet-specific. For example, for some packets (e.g., containing a very important PDCP PDU), in some implementations, an RLF may be triggered even if the WTRU was unable to send the packet after attempting the maximum allowable retransmission of the packet.

[0198] Some implementations include strategies for the WTRU to be configured with conditions for deciding whether to enable and / or disable retransmission, as well as the number of retransmissions. In some implementations, the WTRU is configured to determine, for example, whether to apply retransmission to packets of an RLC entity (for example, and up to how many times) based on one or more characteristics of the set of PDUs associated with the RLC entity in question. For example, if the PSDB is less than threshold 1, RLC retransmission is disabled; if the PSDB is between threshold 1 and threshold 2, the maximum retransmission count is set to 1; if the PSDB is between threshold 2 and threshold 3, the maximum retransmission count is set to 2; if the importance level is below threshold 1, RLC retransmission is disabled; if the importance level is between threshold 1 and threshold 2, the maximum retransmission count is set to 1; if the importance level is between threshold 2 and threshold 3, the maximum retransmission count is set to 2; if the importance level is above threshold 3, the maximum retransmission count is set to 3; if the PDU set is a PSIHI PDU set, RLC retransmission is always enabled; and if the RLC PDU size exceeds threshold 1, RLC retransmission is disabled.

[0199] In some implementations, the WTRU is configured to determine whether to apply retransmissions to packets of an RLC entity (for example, if applicable and how many times at most) based on the transmission status of the PDU set. For example, (1) if the TTL is below a configured threshold, retransmissions are 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 configured threshold, retransmissions are 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.

[0200] In some implementations, the WTRU is configured to determine whether (and up to how many times) to apply retransmission to packets of an RLC entity 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 the experienced, past, and / or recent UL throughput is below a certain threshold, retransmission is disabled; if the experienced, past, and / or recent UL throughput is between threshold 1 and threshold 2, the maximum retransmission count is set to 1; if the experienced, past, and / or recent UL throughput is between threshold 2 and threshold 3, the maximum retransmission count is set to 2; and so on.

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

[0202] In some implementations, the WTRU periodically checks the conditions for determining the maximum RLC retransmission count, for example, using a configured period (e.g., period0 starts when the first RLC PDU in a PDU set is sent, period1 starts when period0+ periods have elapsed, and the WTRU uses the same maximum RLC retransmission count value within a single period). In some implementations, the period can be a time length or the number of PDUs / bytes being sent. In some implementations, the WTRU may receive an explicit indication from the network (e.g., in the MAC CE, RLC control PDU, or information in the RLC packet header) of which maximum retransmission count should apply.

[0203] Some implementations include a policy for the WTRU to send an indication to the network based on a change 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, indication in the RLC header, etc.) after changing the maximum retransmission count (e.g., after disabling retransmission or RLF trigger based on reaching the maximum retransmission) based on one of the above policies (or the WTRU implementation, etc.). In some implementations, this can help the network to advance the received RLC window size (e.g., if it was waiting for the retransmission of some packets). In some implementations, this indication may be a single flag (e.g., retransmission is disabled or enabled), or it may contain more detailed information (e.g., the SN of the RLC PDU where / when retransmission was disabled / enabled, the new maximum retransmission count, etc.).

[0204] Some implementations include strategies regarding the DL (Digital Download) aspect. For example, some of the above strategies focus on UL (e.g., how the WTRU dynamically determines RLC entities and how that informs the network), and the network behavior is not defined (as that is usually left to the network implementation). In some implementations, if similar dynamic switching of RLC entities is supported in the DL, the behavior of the RLC receiver is provided in the WTRU.

[0205] In some implementations, a WTRU may be configured to receive an indication from the network that retransmission is disabled and / or enabled for an RLC entity (e.g., MAC CE, RLC control PDU, information in the RLC packet header, RRC message, etc.), and based on that indication, the WTRU may advance its receive window accordingly (for example, if there was a missing packet that the WTRU was waiting for the network to retransmit, it may advance its receive window as if the packet had been received upon receiving an indication that retransmission is now disabled).

[0206] In some implementations, a WTRU may receive an indication to enable out-of-order delivery (for example, if not already configured) for a PDCP entity associated with the RLC entity in question, for example, when a peer RLC transmitting entity in the network disables retransmission. In some implementations, this indication may be the same network indication used to indicate the disabling of RLC retransmission discussed above, or it may be a separate indication (for example, a PDCP control PDU sent from the network).

[0207] In some implementations, a WTRU may receive an indication to disable sequential delivery (e.g., if not already configured) for a PDCP entity associated with the RLC entity in question, for example, when a peer RLC transmitting entity in the network enables retransmission. In some implementations, this indication may be the same network indication used to indicate the enabling of RLC retransmission discussed above, or it may be a separate indication (e.g., a PDCP control PDU sent from the network).

[0208] Some implementations include strategies for other aspects. For example, in some of the above, the buffer level may be the overall buffer level or the buffer level of several bearers (e.g., bearers with certain QoS profiles, such as those with stricter latency / bitrate requirements compared to a certain level or the bearer configuration of the PDCP entity in question).

[0209] In some implementations, the WTRU may be configured using any combination of the above conditions. For example, retransmission may be enabled if the TTL is above threshold 1, the radio quality is below threshold 2, and the PDU set has an importance level above x. In some implementations, the WTRU may be configured to consider not only the current value but also the mean and / or filtered value within a configured time frame, or the rate of change of the value, or the threshold may be based on any other statistical measure (e.g., mean, standard deviation, minimum / maximum within the evaluation period).

[0210] In some of the above, certain implementations assume that the importance levels of the PDUs in a set of PDUs are the same (i.e., one importance level per PDU set). However, some implementations may be applicable when different PDUs in a set of PDUs may have different importance levels. In some implementations, the maximum RLC retransmission count value may need to be determined per PDU level in such cases.

[0211] Some implementations include alternative approaches. For example, in some of the above, some implementations may assume that the RLC entity always operates in RLC AM and that the maximum retransmission count is determined dynamically (e.g., at the packet level, for all packets in the current transmit or retransmit buffer, for all packets of a given time length, etc.).

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

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

[0214] In some implementations, a change in RLC mode may only affect the new RLC PDU, or in some implementations, it may affect all packets currently in an RLC transmit or retransmit window (for example, if the mode is switched from AM to TM, the WTRU may flush all packets that were pending ACKs in the receive buffer, etc.).

[0215] In some implementations, a change in RLC mode may result in the WTRU starting or stopping processing and / or applying the SN to the packet (for example, stopping applying the SN to the packet when switching from AM to TM). If multiple switching is possible (for example, starting in AM due to poor radio conditions, switching to TM when radio conditions improve, and returning to AM when radio conditions deteriorate again), the WTRU may be configured to restart the sequence number and / or continue counting from the last sequence number used when the RLC entity was previously in AM mode.

[0216] Figure 6 is a flowchart illustrating an exemplary procedure for wireless communication involving an adaptive RLC entity (e.g., performed by a WTRU), as discussed further above, for example. In 602, the WTRU receives the configuration of the RLC entity. In 604, the WTRU receives the configuration of a condition for determining whether to enable or disable RLC retransmission. In 606, the WTRU receives data and monitors the condition. In 608, the WTRU retransmits the data over the RLC entity based on the condition. Other implementations may include additional steps, fewer steps, and / or different steps, as discussed above, for example.

[0217] Figure 7 is a flowchart of another exemplary procedure 700 for wireless communication involving an adaptive RLC entity (performed, for example, by a WTRU), as discussed further above. In 702, the WTRU transmits a set of PDUs through the RLC entity. Under condition 704, which is met, the RLC entity is configured to enable retransmission. Under condition 706, which is not met, the RLC entity is configured to disable retransmission. Other implementations include additional steps, fewer steps, and / or different steps, as discussed above, for example.

[0218] Figure 8 is a flowchart of another exemplary procedure 800 for wireless communication including an adaptive RLC entity, as discussed further above, for example (performed by a WTRU). In 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. In 1004, the WTRU transmits a PDU set via the RLC entity. In 804, the PDU set is transmitted via the RLC entity configured for retransmission.

[0219] Some implementations include strategies for conditional PDCP replication. For example, in some implementations, the PDCP and / or bearer are associated with one or more RLC entities associated with different carriers (CA) or links (DC). For example, in some implementations, the WTRU is configured with conditions for deciding whether to replicate the PDUs of a PDU set, based on the characteristics of the PDU set (e.g., based on importance level) and / or the current transmit status of the PDU set (e.g., based on thresholds that consider TTL, PSER, UL buffer level, percentage of remaining PDU sets to be transmitted, etc.), as well as the conditions of the current WTRU and / or network (e.g., radio conditions, and / or buffer level).

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

[0221] The WTRU may receive a configuration of conditions for determining whether to replicate at least a subset of the PDCP PDUs in the DRB's PDU set, the default replication mode (e.g., on or off), the default path (e.g., RLC entity), and one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs, the percentage of PDUs in the remaining PDU set to be transmitted (e.g., or, if it is possible for the PDUs in the PDU set to be of different sizes, the percentage of the amount of data in the remaining PDU set to be transmitted), the PSER (e.g., the lowest percentage of PDUs in the PDU set that are expected to be successfully received at the receiving entity), the importance of the PDU set or PDU, the UL buffer level (e.g., on the primary path, on the alternate path, the overall UL buffer level, considering only the bearer in question, and / or others), and / or radio conditions (e.g., the RSRP threshold, the number of RLC retransmissions, the HARQ NACK / ACK level, and / or others).

[0222] The WTRU may initiate PDCP replication if the default replication mode is on. The WTRU may monitor the conditions for enabling / disabling PDCP replication. The WTRU may determine the replication state. If the determined replication state is on, it will send the PDCP PDU through both RLC entities after processing it (e.g., applying security, adding headers, etc.). The WTRU may inform the network when PDCP replication is turned on and / or off.

[0223] In some implementations, the WTRU is configured to determine whether replication should be applied at the PDCP level based on one or more characteristics of the set of PDUs associated with the PDCP entity in question. For example, in some implementations, the WTRU may behave as follows: The WTRU may apply replication if the PSDB is greater than a configured threshold, and not apply replication otherwise. The WTRU may always apply replication if the severity level is above a configured threshold, never apply replication if the severity level is below a configured threshold, and if the severity level is between the two thresholds, it may decide on replication at the packet level based on other conditions (e.g., discussed herein). The WTRU may apply replication if the set of PDUs is a PSIHI PDU set. WTRU may not apply replication if the PDU set size exceeds a certain threshold size, or it may apply replication up to a certain size and / or percentage of the PDUs in the PDU set (for example, the first x%, the last x%, and so on, with WTRU determining which packets to replicate based on other conditions discussed here up to a specified x%).

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

[0225] 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 may be associated with a buffer in the PDCP, RLC, or LCH. For example, in some implementations, the WTRU may behave as follows: The WTRU may apply replication if the UL buffer level on the default path / carrier is above a certain threshold, and not apply replication otherwise. The WTRU may apply replication if the UL buffer level on the non-default path / carrier is below a certain threshold, and not apply replication otherwise. The WTRU may 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 the non-default path and / or carrier is below another threshold, and so on.

[0226] In some implementations, the WTRU is configured to determine whether replication should be applied at the PDCP level based on one or more conditions. For example, in some implementations, the WTRU may behave as follows: The WTRU may apply replication if the radio quality of the default path and / or carrier (e.g., RSRP / RSRQ) is below a configured threshold. The WTRU may not apply replication if the radio quality of the default path and / or carrier (e.g., RSRP / RSRQ) is above a configured threshold. The WTRU may apply replication if the number, percentage, and / or frequency of RLC and / or HARQ retransmissions in the first path (e.g., on all bearers, but only those relating to the bearer / PDCP in question) are above a level within a given time. A WTRU may not apply replication if the number, percentage, and / or frequency of RLC and / or HARQ retransmissions in the first path (e.g., on all bearers, but only those relating to the bearer / PDCP in question) are below a given level within a given time. A WTRU may apply replication if a UL grant is available on the non-default path that may not be used / needed by other bearers / packets already associated / buffered on that non-default path (e.g., there is no buffered data, the bearer in question has a high enough priority to ensure the packet is scheduled before other pending data, there is a large configured grant, etc.).

[0227] In some implementations, the WTRU continuously checks whether to replicate a PDCP PDU (for example, the WTRU checks the condition for each PDCP PDU that is to be sent). In some implementations, the WTRU periodically checks the condition for replication, for example, using a configured period (for example, period0 starts when the first PDU in a PDU set is sent, period1 starts and period0+ periods have elapsed, and depending on the determination / checking of the condition, the replication state for that PDCP entity is set to on or off for a given period). In some implementations, the period can be a time length or the number of PDUs and / or bytes being sent.

[0228] Some implementations involve measures such as the WTRU sending indications to the network. For example, in some implementations, the WTRU may enable or disable replication without explicitly informing the network.

[0229] In some implementations, the WTRU may inform the network whether replication is enabled or disabled. In some implementations, this indication may include other information regarding the reasons for enabling and / or disabling replication (e.g., which of the conditions for triggering replication activation and / or disabling has been met). Alternatively, this indication may show the desired conditions for enabling and / or disabling replication (e.g., including the start time and / or duration for enabling and / or disabling replication).

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

[0231] In some implementations, instead of enabling or disabling replication itself, the WTRU may send an indication to the network that the conditions for enabling or disabling replication have been met, and the network may enable and / or disable replication based on that indication (for example, using the legacy mechanism of activating / deactivating replication via MAC CE). In some implementations, if the WTRU enables replication, it may send a Buffer Status Report (BSR) to the network (for example, to the secondary node if the default path was the master node, or vice versa). In some implementations, the BSR may indicate the expected data arriving on the new path (for example, the newly replicated data).

[0232] Some implementations include strategies for other aspects. For example, in some of the above, the buffer level may be the overall buffer level or the buffer level of some bearers (e.g., bearers with a certain QoS profile, e.g., those with stricter latency and / or bitrate requirements compared to a certain level or the bearer configuration of the PDCP entity in question).

[0233] In some implementations, the WTRU may be configured using any combination of the above conditions. For example, in some implementations, the WTRU may apply a replica if the TTL is below threshold 1 and the radio quality on the default path / carrier is below threshold 2. In some implementations, the WTRU may be configured to consider not only the current value but also the mean and / or filtered value within a configured time frame, or the rate of change of the value, or the threshold may be based on any other statistical measure (e.g., mean, standard deviation, minimum / maximum within the evaluation period).

[0234] In some of the above, certain implementations assume that the importance levels of the PDUs in a set of PDUs are the same (i.e., one importance level per PDU set). However, some implementations may be applicable when different PDUs in a set of PDUs may have different importance levels. In some implementations, the PDCP replication decision may need to be made per PDU level in such cases.

[0235] In some of the above, in some implementations, the WTRU may be configured with a replication state change prohibition timer that indicates how long the WTRU will wait before changing the replication state. In some implementations, in the case of periodic replication checks, the period may be considered the same as the prohibition timer (for example, the WTRU checks the conditions for the replication state periodically, so it cannot change the replication state in less than that period). However, in some implementations, if the replication state can be changed ad hoc, the prohibition timer may be started each time the replication state is changed, and the replication may not change until the prohibition time has elapsed.

[0236] In some implementations, the replication state may only be changed once, and the prohibition may be "sticky" to the PDU set in that the replication state is not changed for the rest of the PDU set. In some implementations, the WTRU determines the replication state of the PDU set at the beginning, and it continues to use the determined replication state (i.e., replicate or not replicate) for the rest of the PDU set transmission. In some implementations, the WTRU may be configured to be able to change the replication state a maximum number of times within the lifetime of the PDU set.

[0237] Figure 9 is a flowchart illustrating an exemplary procedure performed by a WTRU for wireless communication, including conditional PDCP replication, as discussed further above, for example. In 902, the WTRU receives a configuration of multiple RLC entities. In 904, the WTRU receives a configuration of conditions for determining whether to transmit data on more than one of the RLC entities. In 906, the WTRU monitors the conditions. In 908, the WTRU transmits data on more than one of the RLC entities based on the conditions. Other implementations may include additional steps, fewer steps, and / or different steps, as discussed above, for example.

[0238] Some implementations include measures for conditional retransmission on a second path. For example, in some implementations, a PDCP / bearer is associated with one or more RLC entities, each associated with a different carrier (in the case of a CA) or link (in the case of a DC). In some implementations, a WTRU is configured to first transmit a PDCP PDU on one RLC entity (e.g., a default path, a path with currently available grants, etc.), and if certain conditions are not met (e.g., within a given time), the WTRU transmits a copy of the PDU on another RLC entity (e.g., a threshold considering RLC status reception indicating ACK / NACK reception associated with the initial transmission within a given time, a buffer level on the first path, radio conditions on the first path / carrier, etc.). In some implementations, different conditions may be configured for different PDU sets of characteristics (e.g., importance level) and transmit status (e.g., TTL, percentage of PDUs already transmitted, etc.). In some implementations, the WTRU may be configured to then switch the default path until a second set of conditions is met or until a certain amount of time has elapsed.

[0239] In an exemplary implementation of conditional retransmission on a second path, the WTRU may behave as follows: The WTRU may be configured with a CA or DC. The WTRU may receive a configuration of a DRB (split) with one or more RLC entities, each RLC associated with a specific carrier (e.g., in the case of a CA) or a specific link / path (e.g., in the case of a DC), with one of the RLC entities set as the default.

[0240] The WTRU may receive a configuration of conditions for deciding to retransmit a PDCP PDU on a second path after a given configured time length has elapsed since the transmission of data on the first path and the packet has not been acknowledged, the conditions may include one or more of the following thresholds: reception of one or more NACKs (e.g., RLC status indicating a NACK for a PDU, RLC status indicating a NACK for another PDU), the number of HARQ retransmissions, the buffer level on the first or second path, and / or the radio link quality on the first and / or second path. The conditions may further depend on the characteristics of the PDU set (e.g., importance level) and the current transmit status of the PDU set (e.g., TTL, percentage of PDUs in the remaining PDU set to be transmitted).

[0241] After processing the PDCP PDU (e.g., after applying security, adding headers, etc.), the WTRU may transmit the packet on the first and / or default path. If a configured time has elapsed and the packet has not been acknowledged, the WTRU may check for conditions to retransmit the packet. The WTRU may transmit a copy of the PDCP PDU over one or more other paths if the conditions for retransmission over one or more other paths are met. After transmitting the copy, the WTRU may be configured to stop attempting to retransmit the packet in question on the first path. In some implementations, the WTRU is configured with conditions to determine whether it will retransmit the PDCP PDU on a second path (e.g., transmit a copy of it) after transmitting the PDU on the first path.

[0242] In some implementations, the conditions for retransmission may include the elapsed of a configured time length after the packet was transmitted on the first path, as well as the satisfaction of one or more of the following during a configured time length: no acknowledgment for the packet in question has been received; one or more RLC status PDUs indicating that the RLC PDU containing the PDCP PDU in question is missing; one or more RLC status PDUs indicating a certain number (or percentage) of missing RLC PDUs; detection of a certain number (or percentage) of HARQ retransmissions after the packet was transmitted on the first path; detection of an increase in the UL buffer level on the first path; detection of a decrease in the UL buffer level on the second path; detection that the radio link quality is below a threshold on the first path (which may be an averaged / filtered value over that time length); and / or detection that the radio link quality is above a threshold on the second path (which may be an averaged / filtered value over that time length).

[0243] In some implementations, the conditions for retransmission on other paths (e.g., configured latency length, number of RLC status PDUs indicating a missing RLC PDU, number / percentage of HARQ retransmissions, UL buffer level increase / decrease level, radio quality levels on the first and second paths, and / or others) depend on the characteristics of the PDUs (e.g., PDU set importance, PSDB, PSHI, etc.). That is, the WTRU may be constructed using multiple sets of values ​​for different characteristics of the PDU set (e.g., different latency lengths for different PSDBs or PDU set importance).

[0244] In some implementations, the conditions for retransmission on other paths (e.g., configured wait time length, number of RLC status PDUs indicating a missing RLC PDU, number / percentage of HARQ retransmissions, UL buffer level increase / decrease level, radio quality levels on the first and second paths, and / or others) depend on the status of the PDU set transmission (e.g., TTL, PSER, percentage of PDUs in the PDU set still remaining to be transmitted, etc.). That is, the WTRU may be configured with multiple sets of values ​​for different transmission states of the PDU set (e.g., different wait times for different TTLs). For example, in some implementations, the WTRU may be configured to apply a longer wait time when the TTL is higher compared to when the TTL is lower.

[0245] In some implementations, the satisfaction of the retransmission conditions affects only one specific packet. In some implementations, the WTRU may be configured to periodically check for the retransmission conditions (e.g., every xm, every n PDUs, etc.) rather than checking for the conditions for every packet after each packet has been sent on the first pass. In some implementations, if the retransmission conditions are met for this packet, the WTRU may be configured to retransmit on the second pass all packets that were sent before this packet on the first pass but are still awaiting their acknowledgment. In some implementations, instead of all of these packets being retransmitted, only a certain number and / or percentage of these packets are retransmitted.

[0246] In some implementations, a WTRU may, after deciding to retransmit a packet on a second path, refrain from retransmitting / sending that packet on the first path (for example, all RLC PDUs containing PDCP PDUs are flushed from the RLC's transmit buffer on the first path). In such cases, some implementations may need to send information about this occurrence to the network (for example, so that receiving RLC entities on the network do not have to wait for packets that are not retransmitted). In some implementations, this may be done via MAC CE, RLC header information, RLC control PDUs, etc.

[0247] In some implementations, after deciding to retransmit a packet over the second path, the WTRU may suspend using the first path to transmit any new data for the PDCP in question for a given configured time length or until some other condition is met (e.g., retransmission to the first path is decided while the second path is being used, the buffer level on the first path drops to a certain level, the radio quality on the first link now exceeds a certain threshold, the number / percentage of HARQ retransmissions or RLC status PDUs indicating missing PDUs on the first path falls below a certain threshold, and / or other).

[0248] In some implementations, the buffer level can be the overall buffer level or the buffer level of several bearers (for example, bearers with certain QoS profiles, such as those with stricter latency / bitrate requirements compared to a certain level or the bearer configuration of the PDCP entity in question).

[0249] In some implementations, it may be assumed that the importance levels of the PDUs in a set of PDUs are the same (i.e., one importance level per PDU set). However, some implementations are equally applicable when different PDUs in a set of PDUs may have different importance levels. For example, in some implementations, the wait time for important PDUs may be set lower than that for less important PDUs.

[0250] Figure 10 is a flowchart illustrating an exemplary procedure performed by a WTRU for wireless communication, including conditional retransmission, as discussed further above. In 1002, the WTRU receives a configuration of multiple RLC entities. In 1004, the WTRU receives a configuration of conditions for determining whether to transmit duplicate data on a second RLC entity. In 1006, the WTRU transmits data on the first RLC entity. In 1008, the WTRU transmits a duplicate of the data on the second RLC entity based on the conditions. Other implementations may include additional steps, fewer steps, and / or different steps, as discussed above.

[0251] While 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 may be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as built-in hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital multipurpose disks (DVDs). A software-related processor may be used to implement a radio frequency transceiver for use in a WTRU, WTRU terminal, base station, RNC, or any host computer.

Claims

1. A method for wireless communication implemented in a wireless transmitter / receiver unit (WTRU), Receiving configuration information indicating the configuration for an Acknowledgment Mode (AM) Radio Link Control (RLC) entity, Receiving a set of packet data units (PDUs) 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 the characteristics of the PDU set and / or the transmission status of the PDU set. Transmitting the PDU set via the AM RLC entity, Receiving an RLC status PDU indicating the RLC status, In response to the RLC status, retransmit one or more PDUs of the PDU set via the RLC entity, Methods that include...

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

3. The method according to claim 1, wherein the transmission status of the PDU set 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 according to claim 1, wherein the at least one of the conditions includes a network condition.

5. The method according to claim 1, wherein the at least one of the conditions includes a wireless condition.

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

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

8. The method according to claim 1, wherein the RLC status indicates that at least one PDU of the PDU set was not received.

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

10. The method according to 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 at least one condition.

11. A wireless transmitter / receiver unit (WTRU), A circuit configured to receive configuration information indicating the configuration for an Acknowledgment 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 constitute the AM RLC entity for retransmission based on at least one condition, wherein the at least one condition includes the characteristics of a PDU set and / or the transmission status of a PDU set, 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, A circuit configured to retransmit one or more PDUs of the PDU set via the RLC entity in response to the RLC status, WTRU, equipped with...

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

13. The WTRU according to claim 11, wherein the transmission status of the PDU set 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 according to claim 11, wherein the at least one of the conditions includes a network condition.

15. The WTRU according to claim 11, wherein the at least one of the conditions includes a wireless condition.

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

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

18. The WTRU according to claim 11, wherein the RLC status indicates that at least one PDU of the PDU set was not received.

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

20. The WTRU according to 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 at least one condition.

Images