WO2025034902A1

WO2025034902A1 - Higher layer reliability for xr traffic

Info

Publication number: WO2025034902A1
Application number: PCT/US2024/041338
Authority: WO
Inventors: Oumer Teyeb; Jaya Rao; Tejaswinee LUTCHOOMUN; Senay NEGUSSE
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2023-08-07
Filing date: 2024-08-07
Publication date: 2025-02-13
Anticipated expiration: 2026-02-07

Abstract

Systems, methods, and devices for wireless communications. Configuration information is received, which indicates a configuration for an acknowledged mode (AM) radio link control (RLC) entity. A packet data unit (PDU) set is received, via a packet data convergence protocol (PDCP) entity. The AM RLC entity is configured for retransmission based on at least one condition, wherein the at least one condition includes a PDU set characteristic and/or a PDU set transmission status. The PDU set is transmitted via the AM RLC entity. An RLC status PDU indicating an RLC status is received. One or more PDUs of the PDU set is retransmitted, via the RLC entity, responsive to the RLC status. In some implementations, the PDU set characteristic includes a priority level of the PDU set and/or a type of the PDU set. In some implementations, the PDU set transmission status includes a time-to-live (TTL) threshold.

Description

HIGHER LAYER RELIABILITY FOR XR TRAFFIC

BACKGROUND

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Application Serial No. 63/531 , 193 filed August 7, 2023, U.S. Provisional Application Serial No. 63/531 ,197 filed August 7, 2023, U.S. Provisional Application Serial No. 63/531 ,201 filed August 7, 2023, and U.S. Provisional Application Serial No. 63/531,204 filed August 7, 2023, the contents of which are hereby incorporated by reference herein.

BACKGROUND

[0002] The term extended Reality (XR) may refer to different types of immersive experiences including Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR) and/or realities interpolated among them. Some XR services and/or application traffic may include data and/or packet data units (PDUs), which may be associated with an application data unit (ADU), PDU set or data burst. PDUs belonging to a PDU set may be associated with different segments and/or components of a video frame or a video slice. In some implementations, a data burst may include one or more PDU sets, which may be transmitted and/or received over a time window. For example, in some implementations, the number of PDUs in a PDU set or data burst transmitted in UL and/or received in DL may depend on the type of the media frame (e.g., 3D video frame or audio frame).

SUMMARY

[0003] Some implementations provide a method for wireless communications that is implemented in a wireless transmit/receive unit (WTRU). Configuration information is received, which indicates a configuration for an acknowledged mode (AM) radio link control (RLC) entity. A packet data unit (PDU) set is received, via a packet data convergence protocol (PDCP) entity. The AM RLC entity is configured for retransmission based on at least one condition, wherein the at least one condition includes a PDU set characteristic and/or a PDU set transmission status. The PDU set is transmitted via the AM RLC entity. An RLC status PDU indicating an RLC status is received. One or more PDUs of the PDU set is retransmitted, via the RLC entity, responsive to the RLC status.

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

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

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

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

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

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

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

[0011] Some implementations provide a method for wireless communications. Data is transmitted over one of a plurality of radio link control (RLC) entities. Each of the plurality of RLC entities is operating in a different mode. The data is transmitted over the one of the plurality of RLC entities based on at least one condition. In some implementations, the data includes a packet data unit (PDU) set. In some implementations, the at least one condition includes a PDU set characteristic, a PDU set transmission status, WTRU conditions, and/or network conditions. In some implementations, a PDU set characteristic includes an importance level; wherein a PDU set transmission status includes a TTL threshold, PSER threshold, UL buffer level, and/or percentage of the PDU set remaining to be transmitted; wherein WTRU conditions include radio conditions and/or buffer levels; and wherein network conditions include radio conditions and/or buffer levels. In some implementations, each of the plurality of RLC entities operates in either an Acknowledged Mode (AM), Unacknowledged Mode (UM), or Transparent Mode (TM). Some implementations provide a wireless transmit/receive unit (WTRU), system, processor, network element, base station, access point, station, integrated circuit, and/or memory configured to perform the method for wireless communications.

[0012] Some implementations provide a method for wireless communications. Data is transmitted over a radio link control (RLC) entity. The RLC entity is configured for retransmissions based on at least one condition. In some implementations, the data includes a PDU set. In some implementations, the at least one condition includes a PDU set characteristic, a PDU set transmission status, WTRU conditions, and/or network conditions. In some implementations, a PDU set characteristic includes an importance level; wherein a PDU set transmission status includes a TTL threshold, PSER threshold, UL buffer level, and/or percentage of the PDU set remaining to be transmitted; wherein WTRU conditions include radio conditions and/or buffer levels; and wherein network conditions include radio conditions and/or buffer levels. In some implementations, the RLC is configured to enable retransmissions responsive to a value associated with the data meeting a threshold value associated with the at least one condition. Some implementations provide a WTRU, system, processor, network element, base station, access point, station, integrated circuit, and/or memory configured to perform the method for wireless communications.

[0013] Some implementations provide a method for wireless communications. Data is transmitted over a packet data convergence protocol (PDCP) that is associated with a plurality of RLC entities. The data is transmitted over more than one of the plurality of RLC entities, based on at least one condition. In some implementations, the data includes a PDU set. In some implementations, the at least one condition includes a PDU set characteristic, a PDU set transmission status, WTRU conditions, and/or network conditions. In some implementations, a PDU set characteristic includes an importance level; wherein a PDU set transmission status includes a TTL threshold, PSER threshold, UL buffer level, and/or percentage of the PDU set remaining to be transmitted; wherein WTRU conditions include radio conditions and/or buffer levels; and wherein network conditions include radio conditions and/or buffer levels. In some implementations, the PDCP is configured to transmit the data over more than one of the plurality of RLC entities responsive to a value associated with the data meeting a threshold value associated with the at least one condition. Some implementations provide a WTRU, system, processor, network element, base station, access point, station, integrated circuit, and/or memory configured to perform the method for wireless communications.

[0014] Some implementations provide a method for wireless communications. Data is transmitted over a first one of a plurality of RLC entities. A duplicate of the data is transmitted over a second one of the plurality of RLC entities, based on a condition associated with the transmission of the data over the first one of the plurality of RLC entities. In some implementations, the data includes a PDU set. In some implementations, the at least one condition includes a time duration since the transmission of the data over the first RLC entity, a data reception status from the network, radio conditions over links associated with the one or more of the RLC entities and/or uplink (UL) buffer levels over the links associated with the one or more of the RLC entities. In some implementations, the at least one condition depends on a PDU set characteristic and/or a PDU set transmission status. In some implementations, the PDCP is configured to transmit the duplicate of the data over the second one of the RLC entities responsive to a value associated with the transmission of the data over the first one of the plurality of RLC entities meeting a threshold value associated with the at least one condition. Some implementations provide a wireless transmit/receive unit (WTRU), system, processor, network element, base station, access point, station, integrated circuit, and/or memory configured to perform the method for wireless communications.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

[0016] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0017] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0018] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0019] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0020] FIG. 2 is a line graph illustrating example PDU sets received over time;

[0021] FIG. 3 is a block diagram illustrating an example protocol view of a split bearer;

[0022] FIG. 4 is a block diagram illustrating an overview model of the RLC sub-layer;

[0023] FIG. 5 is a flowchart illustrating an example procedure performed for wireless communications including conditional RLC entity switching;

[0024] FIG. 6 is a flowchart illustrating another example procedure performed for wireless communications including an adaptive RLC entity;

[0025] FIG. 7 is a flowchart illustrating another example procedure performed for wireless communications;

[0026] FIG. 8 is a flowchart illustrating another example procedure performed for wireless communications.

[0027] FIG. 9 is a flowchart illustrating another example procedure performed for wireless communications including an adaptive RLC entity; and [0028] FIG. 10 is a flowchart illustrating another example procedure performed for wireless communications including an adaptive RLC entity.

DETAILED DESCRIPTION

[0029] The following acronyms and abbreviations are used herein:

6DOF 6 Degrees of Freedom

ACK Acknowledgement

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 Conventional OFDM (relying on cyclic prefix)

CQI Channel Quality Indicator

CRC Cyclic Redundancy Check

CSI Channel State Information

CW Contention Window

CWS Contention Window Size

CO Channel Occupancy

DAI Downlink Assignment Index

DCI Downlink Control Information

DFI Downlink feedback information

DG Dynamic grant

DL Downlink

DM-RS Demodulation Reference Signal

DRB Data Radio Bearer eLAA enhanced Licensed Assisted Access

FDRA Frequency domain resource allocation

FeLAA Further enhanced Licensed 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 control prioritization

LCH Logical Channel

LTE Long Term Evolution e.g., from 3GPP LTE R8 and up

NACK Negative ACK

MAC Medium access control

MCS Modulation and Coding Scheme

MIMO Multiple Input Multiple Output

MT Mobile Termination

MTP Motion-to-photon

NAS Non-access stratum

NR New Radio

NW Network

OFDM Orthogonal Frequency-Division Multiplexing

PBR Prioritized bit rate

PDB Packet Delay Budget

PDCP Packet Data Convergence Protocol

PDU Packet Data Unit

PHY Physical Layer

PUCCH Physical Uplink Control Channel

PUSCH Physical Uplink Shared Channel

PDSCH Physical Downlink Shared Channel

PID Process ID

PO Paging Occasion

PRACH Physical Random Access Channel

PSS Primary Synchronization Signal

PSDB PDU set delay bound

PSER PDU set error rate

PSIHI PDU set integrated handling indicator QFI QoS flow identifier

RA Random Access (or procedure)

RACH Random Access Channel

RAR Random Access Response

RCU Radio access network Central Unit

RF Radio Front end

RLF Radio Link Failure

RLM Radio Link Monitoring

RNTI Radio Network Identifier

RO RACH occasion

RRC Radio Resource Control

RRM Radio Resource Management

RS Reference Signal

RSRP Reference Signal Received Power

RSSI Received Signal Strength Indicator

RLC Radio link control

RTT Round trip time

SDAP Service data adaptation protocol

SR Scheduling Request

SDU Service Data Unit

SLIV Start and Length Indicator value

SRS Sounding Reference Signal

SS Synchronization Signal

SSS Secondary Synchronization Signal

SWG Switching Gap (in a self-contained subframe)

SPS Semi-persistent scheduling

SUL Supplemental Uplink

TB Transport Block

TBS Transport Block Size

TDRA Time domain resource allocation

TRP Transmission / Reception Point

TSC Time-sensitive communications

TSN Time-sensitive networking

UCI Uplink control indication

UL Uplink

UTO Unused transmission occasion URLLC Ultra-Reliable and Low Latency Communications

WBWP Wide Bandwidth Part

WLAN Wireless Local Area Networks and related technologies (IEEE 8O2.xx domain)

VR Virtual Reality

XR Extended Reality

[0030] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0031] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU.

[0032] The com munications systems 100 may also incl ude a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0033] The base station 114a may be part of the 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), relay nodes, and the like. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the 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 desired spatial directions.

[0034] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which 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).

[0035] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed Uplink (UL) Packet Access (HSUPA).

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

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

[0039] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 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), GSM EDGE (GERAN), and the like. [0040] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 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 FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0041] The RAN 104 may be in communication with the CN 106, 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 the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0042] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0043] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0044] FIG. 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include 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 source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0045] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables 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. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0046] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over 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 yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0047] Although the transmit/receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116. [0048] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

[0049] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The 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. The removable memory 132 may include a subscriber identity 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, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0051] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0052] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

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

[0054] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0055] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0056] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 10, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0057] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0058] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

[0059] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0060] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0061] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. [0062] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network. In representative embodiments, the other network 112 may be a WLAN.

[0063] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication. [0064] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in 802.11 systems. For CSMA/CA, the STAs (e.g., every 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, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0065] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0066] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0067] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support Meter Type Control/Machine- Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0068] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11ac, 802.11af, and 802.11ah, include a channel which may 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 a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 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, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

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

[0070] FIG. 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0071] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

[0072] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and/or lasting varying lengths of absolute time).

[0073] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0074] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0075] The CN 106 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0076] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

[0077] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0078] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 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, providing mobility anchoring, and the like.

[0079] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0080] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0081] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or performing testing using over-the-air wireless communications.

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

[0083] Some implementations relate to extended reality. The term extended Reality (XR) may refer to different types of immersive experiences including Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR) and/or realities interpolated among them. In some implementations, VR may refer to a rendered version of a delivered visual and audio scene. The rendering may mimic the visual (e.g., stereoscopic 3D) and/or audio sensory stimuli of the real world, e.g., as naturally as possible, to an observer or user as they move within limits defined by the application. In some implementations, AR may refer to additional information, artificially generated objects and/or items, and/or content overlaid upon the current environment of a user. In some implementations, MR may refer to a form of AR where some virtual elements are inserted into the physical scene, e.g., to provide an illusion that these elements are part of the real scene. In some implementations, XR may refer to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables.

[0084] In some implementations, immersion, in the context of XR applications and/or services may refer to a sense of a user being surrounded by the virtual environment and/or a feeling of the user being physically and spatially located in the virtual environment. In some implementations, levels of virtuality may range from partial sensory inputs to fully immersive multi-sensory inputs leading to a virtual reality practically indiscernible from actual reality.

[0085] In some implementations, a WTRU may correspond to any XR device and/or node, which may come in variety of form factors. In some implementations, a WTRU (e.g., an XR WTRU) may include, but is not limited to the following: Head Mounted Displays (HMD), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with positional tracking and camera, wearables, haptic gloves, haptic body suits, haptic shoes, etc. In some implementations, several different types of XR WTRU may provide or be based on XR device functions, e.g., as display, camera, sensors, sensor processing, wireless connectivity, XR and/or media processing and/or power supply, e.g., to be provided by 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, e.g., for supporting XR applications, experiences, and/or services.

[0086] Some XR services and/or applications may involve traffic, which may include data and/or PDUs, which may be associated with an application data unit (ADU), PDU set or data burst. In an example, PDUs belonging to a PDU set may be associated with different segments and/or components of a video frame or a video slice. In some implementations, a data burst may include one or more PDU sets, which may be transmitted and/or received over a time window. For example, in some implementations, the number of PDUs in a PDU set or data burst transmitted in UL and/or received in DL may depend on the type of the media frame (e.g., 3D video frame, audio frame). [0087] In some XR applications, a WTRU transmits XR traffic including one or more PDUs and/or PDU sets, in UL (e.g., including pose, gesture, and/or video information) and/or receives XR traffic in DL (e.g., including video, audio, and/or haptics information). In some implementations, such traffic may be transmitted and/or received periodically or a periodically in one or more data flows (e.g., QoS flows). In some implementations, e.g., during UL transmissions, XR traffic may arrive from an application layer at WTRU the WTRU and/or from different devices, terminals, and/or WTRUs (e.g., via sidelink) at different time instances. In some implementations, such XR traffic may be characterized by different attributes, such as variable payload sizes per PDU set, variable number of PDUs per PDU set, variable per-PDU and/or per-/PDU set level importance and/or different levels of inter-dependencies between PDUs and/or PDU sets. In some implementations, such XR traffic (e.g., PDUs and/or PDU sets) received by the WTRU may also experience different delays, jitter, data rate and/or loss rate. In some implementations, performing data transmission and/or reception and/or other associated functions (e.g., prioritization, multiplexing, and/or scheduling) on timely basis with XR awareness (e.g., awareness of PDU set attributes) can have the advantage of facilitating QoS and/or user experience (QoE).

[0088] Some implementations relate to PDU sets and data bursts. In some 5G system (5GS) implementations, the QoS Flow is the finest granularity of QoS differentiation in the PDU Session. 5G QoS characteristics may be determined by the 5QI. Accordingly, in some implementations, each packet in a QoS flow may be treated according to the same QoS requirements.

[0089] For XR and/or XR media services, a group of packets are used to carry payloads of a PDU Set (e.g., a frame, video slice, and/or tile). A PDU Set may include one or more PDUs carrying the payload of one unit of information generated at the application level (e.g., a frame, video slice, and/or tile).

[0090] In a media layer, packets in such a PDU Set may be decoded and/or otherwise handled as a whole. For example, in some implementations, the frame, video slice, and/or tile may only be decoded if some or all of the packets carrying the frame, video slice, and/or tile are successfully delivered. For example, in some implementations, a frame within a Group of Pictures (GOP) can only be decoded by the client if all frames upon which that frame depends are successfully received. Accordingly, in some implementations, the groups of packets within the PDU Set can be referred to has having inherent dependency on each other in the media layer. Without considering such dependencies between the packets within the PDU set, in some implementations, 5GS may perform a scheduling with low efficiency. For example, the 5GS may randomly drop one or more packets, but may try to deliver other packets of the same PDU set which are useless to the client and thus waste radio resources.

[0091] In some implementations, audio samples, haptics applications, and/or remote control operations may benefit if the 5GS considers the PDU Set characteristics. Some implementations which leverage such dependency between packets of a PDU Set (e.g., a frame, video slice, and/or tile) may have the advantage of increasing efficiency and/or promoting user experience. [0092] Some implementations provide enhancements to the current 5GS QoS framework to support different QoS handling for PDU Set. PDU Sets may carry different content, e.g., I/B/P frames, slices/tiles within an l/B/P frame, etc. Some implementations provide differentiated QoS handling where different importance of PDU Sets is considered, e.g., by treating packets (i.e., PDUs) belonging to a less important PDU Set (or Sets) differently, e.g., to reduce resource waste.

[0093] A set of data PDUs generated and sent by the application in a period of time (e.g., a relatively short period of time) may be referred to as a Data Burst. In some implementations, a Data Burst may include multiple PDUs belonging to one or multiple PDU Sets.

[0094] FIG. 2 is a line graph showing data 200, received over time, which illustrates an example way in which a WTRU receives information in PDU sets and data bursts. Data 200 includes a first data burst 202 and a second data burst 252. First data burst 202 includes a first PDU set 210, a second PDU set 220, and a third PDU set 250. In this example, first PDU set 210 is an l-frame that includes 7 PDUs. Each PDU includes a serial number for identification (numbered 1-7, respectively, in this example). Second PDU set 220 is an I- frame that includes 8 PDUs. Each PDU includes a serial number for identification (numbered 1-8, respectively, in this example). Third PDU set 230 is a P-frame that includes 5 PDUs. Each PDU includes a serial number for identification (numbered 1-5, respectively, in this example).

[0095] Second data burst 252 includes a first PDU set 260 and a second PDU set 270. In this example, first PDU set 260 is an l-frame that includes 9 PDUs. Each PDU includes a serial number for identification (numbered 1-9, respectively, in this example). Second PDU set 270 is a B-frame that includes 6 PDUs. Each PDU includes a serial number for identification (numbered 1-6, respectively, in this example).

[0096] In some implementations, a PDU-Set Delay Budget (PSDB) refers to an upper bound for the time that a PDU-Set may be delayed between the WTRU and the N6 termination point at the UPF. In some implementations, PSDB refers to the PDU set delay budget (e.g., time from the reception of the first PDU of the PDU set at the WTRU to the time the last PDU of the PDU set is received (e.g., properly received) at the application layer at the receiver).

[0097] In some implementations, Time To Live (TTL) of a PDU set refers to how much of the PSDB of the PDU is remaining. For example, if the PSDB is x milliseconds (ms), and it has been y ms since the first PDU of the PDU set becomes available for transmission at the remote WTRU, the TTL is x-y ms.

[0098] In some implementations, PDU-Set Error Rate (PSER) refers to an upper bound for the rate of PDU- Sets that have been processed by the sender of a link layer protocol (e.g., RLC layer) but where all of the PDUs in the PDU-Set are not successfully delivered by the corresponding receiver to the upper layer (e.g., PDCP layer).

[0099] In some implementations, if a PDU set is associated with and/or marked with a PDU Set Integral Handling Indication (PSIHI), all the PDUs of the PDU set must be received successfully at the receiving entity/application for the information contained within the PDU set to be useful (e.g., an application may not be able to combine and/or render the information in the PDUs of the PDU set even if all but one of the PDUs of the PDU set are received successfully).

[0100] In some implementations, some PDU sets may be usable even if a certain portion of the PDUs are not received.

[0101] Some implementations relate to how a WTRU receives information regarding a PDU set. In some implementations, the WTRU may obtain information about the size of PDU sets and/or data bursts (e.g., size of frame and/or PDU and/or PDU-set and/or group of PDU-sets) and/or other information such as PSDB, PDU set type, and/or importance, etc., in any one or more of several ways.

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

[0103] In some implementations, the WTRU may receive one or more indications from an application and/or higher layers, based upon which the WTRU may infer the size of the PDU-set. For example, in some implementations, the WTRU may receive indications about the first and the last packet in the PDU-set, which may be indicated in the headers of the first and the last packet, for example.

[0104] In some implementations, the WTRU may receive size information, e.g., on a granular level (e.g., a more granular level). For example, in some implementations, the WTRU may receive indications from the application and/or higher layers about a typical size of different frames (e.g., l-frame, P-frame, and/or B-frame). In some implementations, the first, last, and/or another positioned packet in the PDU-set may include information indicating its type (e.g., corresponding to an l-frame or P-frame) and/or that the packet is the first, last, and/or another positioned packet of the PDU-set. In some implementations, based on this information, the WTRU may estimate the size of the PDU-set.

[0105] In some implementations, e.g., in an encoding scheme where different types offrames are encoded into different traffic streams (e.g., GOP-based, whereby a single video frame is either an l-frame or P-frame), the WTRU may receive an indication linking the data flow to the frame type, e.g., only once at the start of the session.

[0106] For example, in some implementations, an indication from the application and/or higher layers to the WTRU may be or include a bit, where “0” may correspond to a data flow with l-frames while “1” may corresponding to a data flow with P-frames. It is noted that any other suitable indication is usable in other implementations (e.g., where the bits are reversed, or other encoding is used to indicate frame types.

[0107] In some implementations, the WTRU may receive information about the size of the PDU set on a PDU-set basis and/or on a per-flow basis (e.g., in a GOP-based encoding scheme). In some implementations, this exchange may occur at the start of the XR session. In some implementations, the WTRU may receive updates (e.g., regular updates) throughout the XR session, (e.g., periodically, or e.g., only if there is a change in the information (e.g., change in size of PDU-set). [0108] In some implementations, the WTRU may receive information from an application and/or higher layers regarding multiple PDU-sets (e.g., granularity of 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.).

[0109] In some implementations, an importance of data may be indicated to the WTRU from the application and/or higher layers on different data-unit granularities (e.g., importance on a per-frame basis and/or per-PDU basis and/or per-PDU-set basis and/or per-group of PDU-sets basis, etc.) In some implementations, an indication of importance may be indicated for every data unit, or may be indicated for a first data unit with no indication being sent for the following data units, until and/or unless there is a change in the importance. In some implementations, an indication of importance may include a bit-wise binary indication and/or a flag indicating whether the data is important enough (e.g., has an importance above a threshold level of importance) to necessitate a special treatment, for example. In some implementations, an indication of importance may be indicated based on a table which maps different QoS levels in a legacy QoS framework to different importance levels.

[0110] For example, in some implementations, the four most important QoS levels from the QoS framework may be flagged as important such that the WTRU may determine that any data mapped to radio bearers with the corresponding QoS flows from the four most important QoS levels may need to be sent before transitioning to another cell and/or gNB or other node b, base station, or infrastructure equipment. In some implementations, any data mapped to radio bearers with QoS flows from the remaining QoS levels may wait until after HO is completed to be transmitted. In some implementations, an indication of importance may override QoS levels from the traditional QoS framework in some cases (e.g., if the data in the buffer is about to expire).

[0111] Some implementations relate to split bearers in dual connectivity (DC). In DC, in some implementations, a WTRU is served by two nodes, each including a set of cells, which may be referred to as a Master Cell Group (MCG) and a Secondary Cell Group (SCG). In some implementations, a bearer may be associated only with the MCG or only with the SCG, or the bearer may be configured as a split bearer.

[0112] FIG. 3 is a block diagram illustrating an example protocol view 300 of a split bearer. Protocol view 300 illustrates a bearer split between a WTRU 302, gNB1 304, and gNB2 306. In some implementations, WTRU 302 is associated with one PDCP entity 304, and the peer PDCP entity on the network side may be terminated at either one of the gNBs (or other node b, base station, or infrastructure equipment), either the master or the secondary. In this example, termination on the network side is at PDCP entity 310, at g N B 1 304. gNB 1 304, and gNB2 306 each include RLC entities 312, 314, MAC entities 316, 318, and PHY entities 320, 322, respectively. WTRU 302 includes corresponding RLC entities 324, 326, MAC entities 328, 330, and PHY entities 332, 334, in communication with gNB1 304 and gNB2 306 as shown.

[0113] In some implementations, in the DL, the CN may send the data to the gNB (or other node b, base station, or infrastructure equipment) where the PDCP is terminated, and it is the responsibility of the network to directly send the data (e.g., PDCP PDUs) to the WTRU via the link between that gNB (or other node b, base station, or infrastructure equipment) and the WTRU, or forward the PDCP PDUs to gNB2 (or other node b, base station, or infrastructure equipment) (e.g., via Xn interface), and gNB2 (or other node b, base station, or infrastructure equipment) will send the data to the WTRU via the link between itself and the WTRU. For example, in some implementations the CN may send the data to gN B 1 304 for transmission directly to WTRU 302, or gNB 1 304 may forward the data to gNB2 306 and gNB2 306 may transmit the data to WTRU 302 from itself.

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

[0115] Some implementations relate to packet duplication. In some implementations, packet duplication is a mechanism performed at the PDCP layer (e.g., after the PDCP PDU is generated from the PDCP SDU, encryption and/or integrity protection applied, header compression performed, and/or SN generated, etc.,), where the same PDCP PDU is forwarded via multiple paths and/or links to the receiver. In some implementations, this may be accomplished in DC or carrier aggregation (CA) scenarios. In some implementations, since the two packets (i.e., the same packet forwarded via different links and/or paths) are identical, the receiving PDCP entity is able to determine if and/or when a duplicate PDU is received and/or is able to discard it (e.g., by detecting the reception of a PDU with a SN the same as an already received PDU).

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

[0117] In some implementations, in the downlink, duplication is network controlled (e.g., completely network controlled). In some implementations, duplicates that are received are be discarded by the WTRU at the PDCP level. In some implementations, in the uplink, duplication may be enabled and/or disabled (also referred to as activated and/or deactivated) using a downlink MAC CE received from the network. In some implementations, in the case of CA, an additional restriction (in some cases, known as logical channel restriction) is configured to facilitate the packet and the duplicated version or versions not being transmitted via the same carrier (e.g., a certain logical channel will be configured to use only UL resources granted at the same carrier.) In some implementations, packet duplication provides the advantage of enhanced reliability. However, in some implementations, packet duplication reduces the throughput of the system, e.g., due to the same packet being transmitted multiple times via different links (e.g., in the case of DC) or carriers (e.g., in the case of CA) which may result in increased resource consumption.

[0118] Some implementations relate to Radio Link Control (RLC) protocol. The RLC protocol is a layer 2 protocol that lies between the PDCP and the MAC protocols. In some implementations, tasks (e.g., main tasks) of the NR RLC protocol include one or more of: Transfer of upper layer Protocol Data Units (PDUs) in one of three modes (Acknowledged Mode (AM), Unacknowledged Mode (UM) and/or Transparent Mode (TM)); Error correction through Automatic Repeat reQuest (ARQ) (e.g., only for AM data transfer); Segmentation and reassembly of RLC SDUs (e.g., UM and AM); Re-segmentation of RLC data PDUs (e.g., AM); Duplicate detection (e.g., AM); RLC SDU discard (e.g., UM and AM); RLC re-establishment; and/or Protocol error detection (e.g., AM).

[0119] In some implementations, in LTE, multiplexing of data is implemented two times by concatenating RLC SDUs from one logical channel into one RLC PDU in the RLC layer and by multiplexing RLC PDUs from different logical channels into one MAC PDU in the MAC layer. In some implementations, in this way, a MAC PDU carries the information about the same data field in both RLC and MAC headers and/or sub-headers. In some implementations, the RLC concatenation takes input from the MAC layer scheduling, i.e., it interacts with the MAC layer to construct the RLC PDUs that have the proper size for each UL grant. In some implementations, after receiving a scheduling decision (e.g., uplink grant size) and a LCP (Logical Channel Prioritization) procedure takes place in the MAC layer, the RLC concatenation may be performed, e.g., within one scheduling cycle. In some implementations, this means that neither the RLC nor MAC layer is able to perform any pre-processing before the grant information is received. In some implementations, this may limit the very high data rate and latency requirements of NR as compared to LTE. Accordingly, in some implementations, the concatenation procedure may be removed from the NR RLC layer and the RLC may immediately send PDCP packets 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.

[0120] In some implementations, LTE RLC also includes a re-ordering functionality. In some implementations, in NR, this functionality has been removed from RLC, and left for PDCP to do so, as PDCP already has re-ordering functionality. In some implementations this has the advantage of improving latency, e.g., because delivering out-of-order RLC packets to the PDCP may allow for earlier deciphering of out of order packets. In some implementations, in each RLC mode, transmission or reception of data may be performed. In some implementations, in TM and UM, separate entities are used for transmission and reception, but in AM a single RLC entity performs both transmission and reception. [0121] FIG. 4 is a block diagram of communications interfacing 400 between a WTRU 402 and WTRU (or gNB) 452, illustrating an overview model of an example RLC sub-layer, which illustrates this. In this example, WTRU 402 includes a receiving TM RLC entity 404, transmitting TM RLC entity 406, receiving UM RLC entity 408, transmitting UM RLC entity 410, and a transmitting and receiving AM RLC entity 412. WTRU 402 includes upper layers 440 and lower layers 445.,, WTRU 452 includes a transmitting TM RLC entity 454, receiving TM RLC entity 456, transmitting UM RLC entity 458, receiving UM RLC entity 460, and a transmitting and receiving AM RLC entity 462. WTRU 452 includes upper layers 490 and lower layers 495.

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

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

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

[0125] In WTRU 402, a transmitting UM RLC entity 410 receives PDUs transferred from upper layer 440 over an 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 via logical channel interfaces as shown. Receiving UM RLC entity 460 transfers the PDUs to upper layers 490 via an RLC channel interface as shown. [0126] In WTRU (or gNB) 452, a transmitting and receiving AM RLC entity 462 receives PDUs from upper layer 490 over an RLC channel interface as shown, and transmits these PDUs to transmitting and receiving AM RLC entity 412 of WTRU 402 over radio interface 499 via lower layers 495 and 445 via logical channel interfaces as shown. Transmitting and receiving AM RLC entity 412 transfers the PDUs to upper layers 440 via an RLC channel interface as shown.

[0127] In WTRU 402, transmitting and receiving AM RLC entity 412 receives PDUs from upper layer 440 over an RLC channel interface as shown, and transmits these PDUs to transmitting and receiving AM RLC entity 462 of WTRU 402 over radio interface 499 via lower layers 495 and 445 via logical channel interfaces as shown. Transmitting and receiving AM RLC entity 462 transfers the PDUs to upper layers 490 via an RLC channel interface as shown.

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

[0129] In some implementations, a TMD PDU has no headers, contains the PDCP PDU that the RLC received, and is forwarded to the MAC as is. In some implementations, a UMD PDU includes a Data field and an UMD PDU header. In some implementations, the UMD PDU header is byte aligned. In some implementations, for UM and AM, segmentation may be applied. In some implementations, MAC layers inform the RLC layer about available transport block size than can be scheduled and transmitted. In some implementations, if the RLC PDU size is higher than available TB size, then the RLC layer segments the RLC SDU into multiple PDUs. In some implementations, if an UMD PDU includes a complete RLC SDU (i.e., there is no segmentation of the PDCP PDU), then the UMD PDU header only includes the SI (Segmentation Info) and Reserved (R) fields. In some implementations, the SI field is a 2 bit field that indicates whether an RLC PDU contains a complete RLC SDU or the first, middle, last segment of an RLC SDU (e.g., 00: complete SDU, 01 : first segment of an RLC SDU, 10: last segment of an RLC SDU, 11 : intermediate segment of an RLC SDU). In some implementations, in the case of segmentation, the first and the last segments will include only the SN and the SI fields, while for the intermediate segments, an additional field which may be referred to as SO (Segment Offset) is included, indicating the position of the RLC SDU segment in bytes within the original RLC SDU. In some implementations, a UMD PDU SN may be configured to be 6 or 12 bits. In some implementations, apart from the segmentation aspect and the header, UM is similar to TM. AM, on the other hand, offers reliability via retransmissions (via Automatic Repeat reQuest, ARQ) in some implementations,. As such, in some implementations, every AM PDU has a SN (e.g., even if it was not segmented). In some implementations, the SN for AM may be configured to be 12 or 18 bits. In some implementations, the RLC transmit window is a sliding window that includes the transmitted packets that have not yet been ACKed by the receiver RLC entity (e.g., when the low numbered SN packets are received, the window can be progressed to the right, so that even more packets can be sent). In some implementations, the bigger the SN, the more RLC packets may be outstanding in the transmit entity, however, in some implementations, the SN will have more overhead.

[0130] In some implementations, the AM RLC header includes (e.g., additionally) a flag (D/C) that indicates whether this is a data PDU or a control PDU. In some implementations, a polling bit is also available in the AM RLC header that can be used by the sending RLC entity to trigger the receive RLC entity to send a status report. In some implementations, the RLC entity may be configured to set the polling bit, e.g., depending on the number of bytes/PDUs being transmitted (e.g., every X PDU, every Y bytes, etc.) In some implementations, a poll prohibit timer may be configured to prevent the triggering of a subsequent STATUS report, e.g., within a threshold time (e.g., a short time) after another one. In some implementations, similar to the UMD header, AMD may also include the SI field, and may include SO fields for segmented packets.

[0131] In some implementations, a Status PDU is an RLC AM control PDU that is sent from the receive RLC entity (e.g., from the gNB in the case of UL and from the WTRU in the case of DL) that indicates the receiver RLC status (e.g., which packets are received, and which packets are pending to be received and/or missing). In some implementations, the sending RLC entity may determine on how to progress the RLC transmit window and also determine which packets needs to be retransmitted, based on this information. In some implementations, the RLC AM entity may be configured with a maximum retransmission counter (e.g., which may take a value from 1 to 32, or any other suitable range of values in other implementations). In some implementations, whenever a packet is retransmitted, the retransmission count for that packet may be incremented and if the maximum retransmission count is reached for any of the RLC packets (e.g., if the retransmission count is set to 2, and packet was not received after the 2^nd retransmission, i.e., the 3^rd transmission including the first transmission), the RLC entity may indicate this to the RRC entity, which may consider this to be a radio link failure (RLF), and may trigger re-establishment or failure recovery via an alternative link if the WTRU was operating in DC (e.g., using the SCG if the failed RLC entity was in the MCG, and using the MCG if the failed RLC entity was in the SCG).

[0132] 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 different devices, such as AR glasses and haptics gloves (e.g., via SL). In some implementations, such data units, which may have variable payload sizes, different periodicity, jitter and different inter-dependencies may be further processed and transmitted by the WTRU in the UL.

[0133] In some implementations, enhancements related to capacity may include any one or more of i) multiple Configured Grant (CG) PUSCH transmission occasions in a period of a single CG PUSCH configuration, ii) dynamic indication of unused CG PUSCH occasion(s) based on Uplink Control Information (UCI) by the WTRU, iii) buffer status report (BSR) enhancements including at least new BSR Table(s), iv) delay reporting of buffered data in uplink and/or v) discard operation of PDU Sets for DL and UL. In some implementations, enhancements related to power savings may include DRX support of XR frame rates corresponding to non-integer periodicities (through at least semi-static mechanisms e.g., RRC signaling). In some implementations, enhancements for XR awareness may include any one or more of i) signaling by CN of semi-static information per QoS flow (e.g., PDU set QoS parameters), dynamic information per PDU set (PDU Set information and Identification) and End of Data Burst indication, and/or ii) provisioning by WTRU of XR traffic assistance information e.g., periodicity, UL traffic arrival information.

[0134] In some implementations, the QoS needs of a service semi-statically determines the QoS related settings of the bearer or bearers associated with the service and the logical channel or channels associated with the bearer or bearers. In some implementations, this may be done by the network setting proper configuration of the PDCP, RLC, logical channel, etc. associated with the bearer that is aligned with the needs of the service. For example, in some implementations, if latency is of higher importance than reliability, the bearer may be associated with a transparent RLC entity. In some implementations, if the required reliability is above a threshold amount of reliability (e.g., very high), then the RLC may be set to an AM mode and duplication via another carrier (in the case of CA) or another link (in the case of DC) may be enabled on top for carrier and/or link diversity. [0135] In some implementations, in the context of XR traffic, the QoS needs of the PDUs of a PDU set may be elastic. For example, in some implementations, the PDUs at the start of the PDU set transmission may be treated in a relaxed manner as compared to the PDUs of the PDU set that are being sent near the PSDB expiry. As used herein, relaxed manner refers to low priority, low urgency (e.g., we may prioritize other more urgent data beforehand). In some cases, if a certain percentage of the PDUs of the PDU set are received, the receiver (e.g., an application of the receiver) may be able to decode the message, and thus the rest of the PDUs of the PDU set may be delivered in a best effort fashion after that.

[0136] Accordingly, in some implementations, for the whole PDU set, applying a higher maximum RLC retransmission count or always using duplication, for the sake of reliability may be sub-optimal.

[0137] Some issues relate to latency versus reliability in the context of single and/or non-CA connectivity. In some implementations, e.g., in cases of non-CA/non-DC operation, reliability of a given bearer may be increased by associating the bearer with an RLC AM entity (e.g., with a larger number of RLC retransmissions allowed). However, in some implementations, this may increase latency, reduce throughput, and/or increase overhead and/or processing (e.g., SN in the headers, RLC window management leading to more buffering requirements while waiting for RLC ACKs and limiting the maximum achievable throughput, etc.,).

[0138] Some issues relate to latency versus reliability in the context of CA/DC. In some implementations, e.g., in cases of CA/DC operation, reliability of a given bearer may be increased by performing duplication via multiple carriers and/or links. However, in some implementations, this may increase the total resources used for sending a given data. In some implementations, for non XR traffic, the duplication is decided by the network (e.g., activated and/or deactivated) and is semi-statically configured (e.g., via a MAC CE). In some implementations, in the XR context, as discussed above, the QoS needs of the PDUs of the PDU set change during the lifetime of a PDU set, and the MN/SN may not always be aware of the needs/characteristics of the PDU set (e.g., UL heavy traffic). Thus, in some implementations, always activating duplication may be resource inefficient, whereas not deactivating it all the time may compromise and/or decrease reliability.

[0139] Some implementations relate to how the WTRU can dynamically adapt the reliability related operations and/or configurations for a bearer (e.g., PDCP duplication, RLC modes/retransmission mechanisms, etc.,) in accordance with the elastic QoS needs of the different PDUs of a PDU set that the bearer is transporting. Some implementations include solutions relating to conditional RLC entity switching. For example, in some implementations, at the start of a PDU set, since the TTL (Time to Live) of the PDU set is the highest, higher latency for a PDU of the PDU set may be acceptable, however, as the TTL nears zero, higher latency may not be desirable.

[0140] In some implementations, a PDCP entity may be associated with more than one RLC entity 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 for when to push the PDCP PDUs of the PDU set to which RLC entity depending on PDU set characteristics (e.g., importance level) and current PDU set transmission status (e.g., thresholds that consider TTL, PSER, UL buffer level, %of the PDU set remaining to be transmitted, etc.) and current WTRU and/or network conditions (e.g., radio conditions, buffer levels).

[0141] In an example implementation relating to conditional RLC entity switching, a WTRU may operate as follows. The WTRU may receive a configuration of a DRB/PDCP 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), where one of the RLC entities is configured as the primary/default RLC entity. In some implementations, the different RLC entities may share the same logical channel or have separate logical channels. In some implementations, the WTRU may receive a configuration of conditions to dynamically determine the RLC entity for transmitting the PDUs of a PDU set of the DRB. In some implementations, the conditions may include one or more of the following thresholds: the TTL of the PDU set that the PDU belongs to; the percentage of PDUs of the PDU set remaining to be transmitted (or the % of the amount of data of the PDU set remaining to be transmitted, if the PDUs of the PDU set can have different sizes); the PSER (either for the concerned PDU set or averaged over several PDU sets); PDU set importance or PDU importance; UL buffer level (of the concerned DRB, or the total UL buffer level); radio conditions (e.g., RSRP thresholds, number of RLC retransmissions, HARQ NACK/ACK levels, and/or etc.); and/or an explicit indication from the network.

[0142] In some implementations, he WTRU may be further configured to determine the default/initial RLC entity (e.g., based PDU set characteristics). The WTRU may begin transmitting the PDCP PDUs via/through the default RLC entity. The WTRU may monitor the conditions for the determination of the RLC entity to use for the PDCP. The WTRU may choose the RLC entity based on the monitoring conditions/thresholds, the PDU set characteristics and transmission status, and current UE/network conditions. The WTRU may send an indication to the network (e.g., gNB/DU) about the switching of the RLC entity (e.g., the last SN (of the RLC or PDCP) transmitted with the previous RLC entity, the first SN (of the RLC or PDCP) that is transmitted via the current RLC entity, etc.) The WTRU may transmit the PDCP PDUs via the determined RLC entity (and associated logical channel).

[0143] Some implementations include solutions relating to an adaptive RLC entity. For example, in some implementations, a DRB/PDCP is associated with an RLC AM entity that dynamically adapts its behavior and/or operation (e.g., enable and/or disable retransmissions) depending on the PDU set characteristics (e.g., importance level) and current PDU set transmission status (e.g., thresholds that consider TTL, PSER, UL buffer level, percentage of the PDU set remaining to be transmitted, and/or etc.) and current WTRU and/or network conditions (e.g., radio conditions, buffer levels).

[0144] In an example implementation relating to an adaptive RLC entity, a WTRU may operate as follows. The WTRU may receive a configuration of a DRB and an associated RLC AM entity with a default max retransmission count value. The WTRU may receive a configuration of conditions to determine whether to disable (max retrains=0)/enable RLC retransmissions (e.g., max retransmission >1). In some implementations, the conditions may include one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs; the percentage of PDUs of the PDU set remaining to be transmitted (or the percentage of the amount of data of the PDU set remaining to be transmitted, e.g., if the PDUs of the PDU set can have different sizes); the PSER (e.g., either for the concerned PDU set or averaged over several PDU sets); a PDU set or PDU importance; a UL buffer level (e.g., of the concerned DRB, or the total UL buffer level); radio conditions (e.g., RSRP thresholds, number of RLC retransmissions, HARQ NACK/ACK levels, ...); and/or an explicit indication from the network (e.g., MAC CE).

[0145] The WTRU may start transmitting the PDCP PDUs via/through the default RLC AM setting. The WTRU may monitor the conditions to enable/disable RLC retransmissions. The WTRU may choose the RLC AM retransmission count (e.g., setting it to zero disables retransmissions) based on the monitoring conditions/thresholds and current UE/network conditions. In some implementations, the WTRU may flush buffered RLC AM packets waiting an ACK if retransmission is being disabled. The WTRU may send an indication to the gNB/DU about the disabling/enabling of retransmissions (e.g., RLC control PDU, RLC header, (MAC CE), etc.) The WTRU may be configured to disable RLF triggering (and subsequent re-establishment) based on number of retransmissions for this RLC entity (but RLF triggering based on max retransmissions on other RLC entities can still operate as in legacy).

[0146] Some implementations include solutions relating to conditional PDCP duplication. For example, in some implementations, a PDCP and/or bearer is associated with more than one RLC entity associated with different carriers (e.g., CA case) or links (e.g., DC case). In some implementations, the WTRU is configured with conditions for when to duplicate a PDUs of a PDU set based on PDU set characteristics (e.g., importance level), current PDU set transmission status (e.g., thresholds that consider TTL, PSER, UL buffer level, percentage of the PDU set remaining to be transmitted, etc.) and current WTRU and/or network conditions (e.g., radio conditions, buffer levels).

[0147] In an example implementation relating to conditional PDCP duplication, a WTRU may operate as follows. The WTRU may be configured with CA or DC. The WTRU may receive a configuration of a DRB (split) with one or more RLC entities, where each RLC is associated with a particular carrier (e.g., in CA case) or a particular link/cell group (e.g., in the case of DC). The WTRU may receive a configuration of conditions to determine whether to duplicate at least a subset of PDCP PDUs of a PDU set of the DRB, default duplication mode (on or off), default path (e.g., RLC entity), where the conditions could contain one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs; the percentage of PDUs of the PDU set remaining to be transmitted (or the percentage of the amount of data of the PDU set remaining to be transmitted, if the PDUs of the PDU set can have different sizes); the PSER (e.g., minimum percentage of PDUs of the PDU set expected to be received successfully at receiving entity); the PDU set or PDU importance; the UL buffer level (on the primary path, on the alternate path, total UL buffer level, considering only the concerned bearer, etc.); and/or the radio conditions (e.g., RSRP thresholds, number of RLC retransmissions, HARQ NACK/ACK levels, etc.). [0148] In some implementations, the WTRU may begin applying PDCP duplication if the default duplication mode is ON. The WTRU may monitor the conditions to enable and/or disable PDCP duplication. The WTRU may determine the duplication state, wherein the WTRU sends the PDCP PDU via both RLC entities, after processing a PDCP PDU (e.g., applying security, adding headers, etc.) if the determined duplication state is ON. The WTRU may inform the network when the PDCP duplication is turned on and/or off.

[0149] Some implementations include solutions relating to conditional transmission over a second path. For example, in some implementations, a PDCP and/or bearer is associated with more than one RLC entity, each associated with different carriers (e.g., CA case) or links (e.g., DC case). In some implementations, the WTRU is configured to send a PDCP PDU over one RLC entity (e.g., default path, the path with a grant currently available, etc.,), and, e.g., if certain conditions are not fulfilled (e.g., within a given time), the WTRU may send a duplicate of the PDU over the other RLC entity (e.g., thresholds that consider RLC status reception indicating ACK/NACK reception associated with the first transmission within a given time, buffer level on the first path, radio conditions over the first path/carrier, etc.,). In some implementations, different conditions may be configured for different PDU set characteristics (e.g., importance level) and transmission status (e.g., TTL, percentage of PDUs already sent, etc.,). In some implementations, the WTRU may also be configured to switch the default path after that until second set of conditions are fulfilled or a certain time has elapsed.

[0150] In an example implementation relating to conditional RLC entity switching, a WTRU may operate as follows. The WTRU may be configured with CA or DC. The WTRU may receive a configuration of a DRB (e.g., split) with one or more RLC entities, where each RLC is associated with a particular carrier (e.g., in CA case) or a particular link and/or path (e.g., in the case of DC), and one of the RLC entities set as the default. The WTRU may receive a configuration of conditions to determine to retransmit a certain PDCP PDU over a second path, e.g., after a given configured time duration has elapsed after the transmission of the data on a first path and the reception of the packet has not been acknowledged, where the conditions may include one or more of the following thresholds: one or more NACKs (e.g., RLC status indicating a NACK for the PDU, RLC status indicating a NACK for other PDUs, etc.) is received; a number of HARQ retransmissions; a buffer level on the first path or the second path; and/or a radio link quality over the first path and/or the second path.

In some implementations, the conditions may be further dependent on PDU set characteristics (e.g., importance level) and current PDU set transmission status (e.g., TTL, percentage of PDUs of the PDU set remaining to be sent, etc.) In some implementations, after processing a PDCP PDU (e.g., applying security, adding headers, etc.), the WTRU may initially send the packet over the first/default path.

[0151] In some implementations, if the configured time has elapsed and the reception of the packet has not been acknowledged, the WTRU may check the conditions to retransmit the packet. If one or more of the conditions to retransmit over the other path or paths are fulfilled, the WTRU may send a copy of the PDCP PDU via the other path or paths. The WTRU may be configured to stop attempting to retransmit the concerned packet over the first path, e.g., after the WTRU sends the copy of the PDCP PDU via the other path or paths. [0152] In order to address various issues and/or implement various solutions, e.g., as discussed above, various aspects are contemplated. For example, as discussed herein, in some implementations, the network may include any of a base station (e.g., gNB, TRP, RAN node, access node), core network function (e.g., AMF, SMF, PCF, NEF) and application function (e.g., edge server function, remote server function), for example.

[0153] As discussed herein, in some implementations, flows may correspond to any of: QoS flows or data flows (e.g., flow of data including of one or more PDUs, PDU sets or data bursts, which may be inter-dependent with one and another and/or associated with one or more QoS requirements, e.g., latency, data rate, reliability, RTT latency). Different flows, possibly originating from a common application/experience source and/or intended to a common destination device/UE/WTRU or group of associated devices/UEs/WTRUs may be referred to associated flows or correlated flows.

[0154] As discussed herein, in some implementations, a data unit may refer to any of: one or more frames (e.g., media, video, and/or audio frame, slice, and/or segment), 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 by the WTRU sequentially (e.g., one after the other) or in parallel (e.g., over different channels/links/resources), may or may not be inter-dependent with each other.

[0155] As discussed herein, in some implementations, a forwarding configuration may correspond to any of the following: radio bearers (e.g., data radio bearer (DRB), signaling radio bearers (SRB), transport radio bearer, PDU set bearer); logical channels (LCHs), logical channel groups (LCGs); configuration parameters in the individual layers within the AS protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, and/or other protocol layers (e.g., new protocol layers)); parameters associated with logical channel prioritization (LCP) (e.g., priority, PBR, BSD), BWPs, carriers, radio links and/or interfaces (e.g., Uu links, SLs); and/or radio resources (e.g., set of one or more frequency, time, 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 configurated grants (CG), dynamic grants (DG) and/or any other resource grants or grant free resources.

[0156] As discussed herein, in some implementations, PDU sets and/or their associated characteristics and/or properties, may refer to any one or more of the following: A PDU set may include one or more data units (e.g., PDUs) associated with a media unit, or a video frame and/or slice. In some implementations, such data units within a PDU set or data burst may be inter-dependent with each other at the application layer and/or lower layers (e.g., AS-layers). In some implementations, the attributes and/or properties of a PDU set may be different from each other in terms of, e.g., the number of PDUs in a PDU set, payload sizes, intra-PDU set correlation, importance and/or priority of the data units, status of transmission (e.g., percentage of PDUs of one or more data units transmitted/received successfully), and/or effective data rate and/or effective reliability associated with transmission.

[0157] In an example, such attributes associated with PDU sets may be visible at one or more lower layers (e.g., at PDCP, RLC, MAC, PHY sub-layers/layers), possibly for supporting additional actions (e.g., prioritizing, mapping to an LCH, multiplexing into one or more TBs, scheduling) based on any of the following: (1) Markings in the data units. For example, such markings may include sequence numbers, IDs, indexes, timestamps, and/or time offset values (e.g., with respect to a reference time) e.g., in the header of data units. In some implementations, such markings may be made by higher layers, any preceding sub-layer/layer and/or another device and/or WTRU. (2) Reception of an indication such as a control PDU (e.g., application, higher, layer, and/or NAS layer indication, PDCP control PDU, RLC control PDU, MAC CE, and/or DCI/UCI). In some implementations, such indication may be received by the WTRU from a higher and/or preceding layer, from another device and/or WTRU (e.g., over SL) and/or from the network, for example. (3) Mapping of the data units from a higher layer to a configuration associated with a lower layer. For example, the WTRU may have visibility into a higher layer attribute or attributes at a lower layer when mapping the PDUs to one or more radio bearers, logical channels (LCHs), TBs, and/or or HARQ processes that may be configured to provide similar forwarding treatment. (4) Tracking of the attributes of the PDUs at any buffer associated with sublayer, radio bearer logical channel or HARQ processes. For example, the WTRU may track the attributes associated with a PDU set based on any of the time elapsed since the reception of a first PDU of a PDU set, the remaining time for the PDUs of a PDU set for meeting PSDB, jitter between the arrival one or more PDUs within and/or across PDU sets, percentage and/or payload size of remaining PDUs of a PDU set expected to be received. (5) Restrictions associated with the sublayer, radio bearer, logical channel and/or HARQ process to which the data units of PDU sets may be mapped. For example, the WTRU may have visibility into the data units and may determine corresponding actions (e.g., to perform prioritization per LCP, perform mapping to restricted CG configurations, TBs, HPIs) based on the configured restrictions associated with the one or more sublayers, radio bearers and/or LCHs to which the data units may be mapped.

[0158] As discussed herein, in some implementations, a data burst may refer to data produced by the application in a period of time (e.g., a short period of time), including PDUs from one or more PDU Sets. Such attributes, associations and inter-dependencies (e.g., intra-PDU set and/or inter-PDU set) may include the start and/or end indication of a PDU set/data burst (e.g., via sequence number, start/end indication, timestamp), start and/or end time, duration, payload sizes, periodicity, importance and/or priority, and/or QoS (e.g., PSDB) may be visible to the AS-layers (e.g., with associated IDs) and/or may be handled at the AS layers with the awareness of the association during data transmission in UL and reception in DL.

[0159] As discussed herein, in some implementations, application and/or higher layer importance and/or priority may refer to where the different PDUs in a PDU set or all PDUs in a PDU set may be associated with different importance and/or priority values. In some implementations, such importance value may correspond to, e.g., spatial importance (e.g., spatial position of the video frame whose data is carried by the PDU and/or PDU set, where PDUs and/or PDU set carrying FoV spatial positions may be associated with higher spatial importance than non-FoV spatial positions) and/or temporal importance (e.g., time sequence of the video and/or application frame whose data is carried by the PDU and/or PDU set, where PDUs and/or PDU sets carrying base video frames, such as l-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 layers during data transmission and reception.

[0160] As discussed herein, in some implementations QoS and/or data flow may refer to where the PDUs and/or PDU sets of an application may be encoded and/or delivered by the application to the WTRU (in UL) or to the network (in DL) via one or more QoS and/or data flows. In some implementations, the different QoS flows carrying the PDUs and/or PDU sets associated with an XR application and/or experience may be visible to the AS-layers and/or may be handled at the AS layers with the awareness of such association during data transmission and reception.

[0161] As discussed herein, in some implementations, traffic characteristics and PDU set-level QoS requirements may apply: (1) PDU Set Delay Budget (PSDB) may refer to a time between reception of the first PDU (e.g., at the UPF in DL, at the WTRU in UL) and the successful delivery of the last arrived PDU of a PDU Set (e.g., at the WTRU in DL, at the UPF in UL). In some implementations, PSDB is an optional parameter and if provided, the PSDB may supersede the PDB. (2) PDU Set Integrated Handling Indication (PSIHI) may indicate whether all PDUs of the PDU Set are needed for the usage of the PDU Set by the application layer. (3) PDU Set Error Rate (PSER) may refer to an upper bound for a rate of non-congestion related PDU Set losses between the RAN and the WTRU. (4) Jitter may refer to variation with respect to an expected time instance during which one or more data units may be received or transmitted. For example, for a set of data units that may be expected to be received periodically at different periodic time instances, jitter may refer to the variation with respect to the periodic time instances (e.g., for a data unit that may be received T1 ms in advance or T2 ms later than an expected time instance at T, the jitter range is T2 - T1). Jitter may refer to an instantaneous value or a statistical value (e.g., average, variance, standard deviation, max/min). (5) Remaining delay may refer to the time duration remaining for receiving or transmitting one or more PDUs of a PDU set before the PSDB. Remaining delay may also be referred to as the time to live (TTL) associated with a PDU set. [0162] As discussed herein, in some implementations, multi-PUSCH CG, may correspond to one or more configured resources or configured grant (CG) configurations, where each CG configuration may include of a set of consecutive or non-consecutive PUSCH occasions per slot and/or per CG period. In an example, a multi- PUSCH CG may include of one or more CG periods (e.g., where each CG period may repeat periodically with a certain periodicity value); a CG period in a multi-PUSCH CG may include of one or more consecutive or non- consecutive slots; a slot in a CG period of a multi-PUSCH CG may include of one or more consecutive or non- consecutive PUSCH occasions; and/or a PUSCH occasion in a slot and/or CG period of a multi-PUSCH CG may include of one or more consecutive or non-consecutive symbols with a certain symbol length (e.g., time domain resources). In some implementations, a PUSCH occasion may include of one or more resource blocks or resource block groups in the frequency domain.

[0163] As discussed herein, in some modes (e.g., three RLC entities, one RLC AM, one RLC UM, one RLC TM). The WTRU is configured with conditions when implementations, PUSCH usage may refer to any of the number, location, position or timing of one or more PUSCH occasions in one or more slots or periods, 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.

[0164] Some implementations include solutions relating to conditional RLC entity switching. For example, in some implementations, a PDCP entity is associated with more than one RLC entity with different to push the PDCP PDUs of the PDU set to which RLC entity depending on PDU set characteristics (e.g., importance level) and current PDU set transmission status (e.g., thresholds that consider TTL, PSER, UL buffer level, percentage of the PDU set remaining to be transmitted, etc.) and current WTRU/network conditions (e.g., radio conditions, buffer levels).

[0165] In an example implementation relating to conditional RLC entity switching, a WTRU may operate as follows. The WTRU may receive a configuration of a DRB/PDCP 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), where one of the RLC entities is configured as the primary/default RLC entity. In some implementations, the different RLC entities may share the same logical channel or have separate logical channels.

[0166] The WTRU may receive a configuration of conditions to determine which RLC entity for transmitting the PDUs of a PDU set of the DRB, where 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 of the PDU set remaining to be transmitted (or the percentage of the amount of data of the PDU set remaining to be transmitted, e.g., if the PDUs of the PDU set can have different sizes); the PSER (e.g., either for the concerned PDU set or averaged over several PDU sets); a PDU set importance or PDU importance; a UL buffer level (e.g., of the concerned DRB, or the total UL buffer level); radio conditions (e.g., RSRP thresholds, number of RLC retransmissions, HARQ NACK/ACK levels, and/or etc.); and/or an explicit indication from the network.

[0167] The WTRU may be configured to determine the default/initial RLC entity (e.g., based PDU set characteristics). The WTRU may start transmitting the PDCP PDUs via and/or through the default RLC entity. The WTRU may monitor the conditions for the RLC entity to use. For example, this may be performed all the time (e.g., for each PDCP PDU to be transmitted), or in a periodic manner (e.g., where periodicity can be defined in terms of time, number/percentage of PDUs/bytes of the PDU set that are transmitted, number/percentage of the PSDB that has elapsed etc.) The WTRU may also receive an explicit indication from the network (e.g., a MAC CE, RLC control and/or status PDU, etc.,) indicating the RLC entity to be used from then on.

[0168] The WTRU may choose the RLC entity based on the monitoring conditions/thresholds and current WTRU and/or network conditions. For example, the WTRU may send an indication of the gNB and/or DU about the switching (e.g., in cases where switching back and forth while the PDU set is ongoing is supported). The WTRU may transmit the PDCP PDUs via the determined RLC entity (e.g., and an associated logical channel).

[0169] Some implementations include solutions relating to a WTRU configured with a PDCP entity and more than one RLC entity per PDCP. In some implementations, more than one RLC entity may be associated per PDCP entity, but it is performed only in the case of CA or DC, where the different RLC entities are associated and/or restricted to only one carrier (e.g., in the case of CA) or one link, path, and/or destination node (e.g., in the case of DC), as the reason for configuring the multiple RLC entities is to use the link and/or carrier diversity for more reliability (e.g., in the case of duplication, for the CA or DC case) and/or higher throughput (e.g., in the case of split bearer path switching approach, DC case, as in the CA case, multiple RLC entities may not be required to take advantage of the throughput from multiple carriers). In some such cases, the RLC mode of the two legs may be assumed to be the same (e.g., as the QoS needs of the bearer may not change whether a split bearer and/or duplication is used or not).

[0170] In some implementations, a WTRU may be configured with a PDCP entity that is associated with more than one RLC entity, e.g., where each RLC entity is configured to operate in different modes. For example, in some implementations, a first RLC entity associated with a PDCP entity may be configured with RLC AM mode and a second RLC entity may be configured with RLC TM mode. In some implementations, the WTRU is configured in such a way, even if it is not operating in CA or DC. In some implementations, the different RLC entities may use separate logical channels. In some implementations, the different RLC entities may use a common logical channel.

[0171] Some implementations include solutions relating to a WTRU configured with conditions to determine the initial and/or default RLC entity. In some implementations, one of the RLC entities is explicitly configured by the network to be the initial/default mode (e.g., the RLC AM entity, the RLC UM entity, or the RLC TM entity). [0172] In some implementations, the WTRU may determine an initial and/or default mode, e.g., based on one or more characteristics of the PDU set that is associated with the concerned PDCP entity. For example, in some implementations, if the WTRU receives the first PDU of the PDU set and has the PDU set information (e.g., received along with the first PDU of the PDU set or beforehand from the application layer), such as PSDB or importance level, the WTRU will use that information to determine to start the transmission via the RLC AM, RLC UM or RLC TM entity. For example, in some implementations, for a first subset of PDUs of a PDU set, the WTRU may determine to start the transmission with an RLC AM entity and for the second subset of PDUs of the PDU set, the WTRU may determine to continue using the same RLC AM entity or change/switch to an RLC TM entity. In some implementations, such determination for starting the transmission with an RLC entity configured with a particular mode may be done based on the PDU set information and/or characteristics. For example, if the PSDB is larger than a certain configured threshold, start with the AM entity; if the PDSB is lower than a certain configured threshold, start with the TM entity; if the importance level is above a certain configured threshold, start with the AM entity; if the importance level is below a certain configured threshold, start with the TM entity; if the PDU set is a PSIHI PDU set, start with the AM entity; if the PDU set is expected to have PDUs bigger than a certain configured threshold, start with the UM and/or AM entity (e.g., to allow for segmentation); and so forth.

[0173] In some implementations, the WTRU may determine the initial and/or default mode based on one current WTRU conditions. For example: if the UL buffer level is above a certain threshold, start with the TM and/or UM entity; if the UL buffer level is below a certain threshold, start with the AM entity; if the WTRU overheating level is above a certain threshold, start with the TM/UM entity; if the WTRU overheating level is below a certain threshold, start with the AM entity; if the WTRU battery level is above a certain threshold, start with the AM entity; if the WTRU battery level is below a certain threshold, start with the TM/UM entity; if the experienced/historical/recent UL throughput is greater than a certain threshold, start with the AM entity; if the experienced/historical/recent UL throughput is lower than a certain threshold, start with the TM and/or UM entity; and so forth.

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

[0175] Some implementations include solutions relating to a WTRU configured with conditions to determine the current RLC entity that depends on the characteristics of the PDU set.

[0176] In some implementations, the WTRU is configured to determine the RLC entity to use based on one or more characteristics of the PDU set that is associated with the concerned PDCP entity. For example: if the PSDB is larger than a threshold (e.g., a configured threshold), use the AM entity; if the PDSB is lower 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; if the PDU set is expected to have PDUs bigger than a threshold (e.g., a configured threshold), use the UM/AM entity (i.e., to allow for segmentation); and so forth.

[0177] In some implementations, the WTRU is configured to determine the RLC entity to use based on the current PDU set transmission status. For example: if the TTL is larger than a threshold (e.g., a configured threshold), use the AM entity; if the TTL is lower than a threshold (e.g., a configured threshold), use the TM entity; if the remaining number/percentage of the PDUs of the PDU set (or the actual/percentage of total data of the PDU set remaining to be sent) is below a threshold (e.g., a configured threshold), use the AM entity; and so forth.

[0178] In some implementations, the WTRU is configured to determine the RLC entity to use based on one or more WTRU conditions. For example: if the UL buffer level is above a threshold (e.g., a configured threshold), 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 overheating level is above a threshold (e.g., a configured threshold), use the TM/UM entity; If the WTRU overheating 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/historical/recent UL throughput is greater than a threshold (e.g., a configured threshold), use the AM entity; If the experienced/historical/recent UL throughput is lower than a threshold (e.g., a configured threshold), use the TM/UM entity; and so forth.

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

[0180] In some implementations, the WTRU checks the conditions for switching the RLC entity continuously (e.g., for each PDCP PDU or subsets of one or more PDUs of a PDU set to be transmitted, the WTRU checks the conditions to determine the RLC entity to use for that RLC entity). In some implementations, the WTRU checks the conditions for switching the RLC entity periodically, e.g., with a configured periodicity (e.g., periodO started when the first PDU of the PDU set is sent, period 1 starts periodO+periodicity has elapsed, and so on, and the WTRU using the same RLC entity within one period, etc., ). In some implementations, the periodicity may be of time duration or of 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 to use.

[0181] Some implementations include solutions relating to preventing frequent switching. For example, e.g., in the above, the WTRU may be configured with a Time To Trigger (TTT) to perform the switching. For example, in some implementations, the triggering condition must be fulfilled for at least the TTT before the conditions are considered to be fulfilled. In some implementations, a common TTT value may be configured for all conditions, or each condition may have a separate TT value.

[0182] In some implementations, the WTRU may be further configured with a prohibit timer, which may indicate for how long the WTRU waits before it may perform RLC switching again. In some implementations, the prohibit timer may be of a time duration value or may be based on data size (e.g., number of bytes, number RLC/PDCP packet to be sent, etc., that has to be sent in one RLC entity before switching can be performed, etc.), and so forth.

[0183] In some implementations, the WTRU may be configured to override the prohibit timer under certain conditions. For example, in some implementations, while using the RLC AM entity and prohibit timer to not switch the RLC entity is still running, if the TTL drops below a certain value and/or percentage while there are more than a certain percentage of the PDUs of the PDU set remaining to be transmitted, the WTRU may override and/or stop the prohibit timer and may switch to RLC TM mode.

[0184] Some implementations include solutions relating to a WTRU sending an indication to the network. For example, in some implementations, the WTRU, upon determining an initial and/or default RLC entity, e.g., based on any of the solutions above (or e.g., per WTRU implementation) may send an indication to the network. In some implementations, this indication may be implicit (e.g., the network may determine the chosen RLC entity based on by which RLC entity the first PDU of the PDU set was received) or explicit (e.g., the WTRU may send an indication, e.g., in a MAC CE, RLC control PDU, indication in the RLC header, etc.,) regarding the chosen RLC entity. In some implementations, the latter facilitates the network in being able to determine the chosen RLC entity, even if the RLC entities were sharing the same logical channel and/or switching of the RLC entity happens before the first packet reaches the network (e.g., first packet was being delayed during RLC AM retransmission, and second packet was sent via TM mode and was received before the first packet). [0185] In some implementations, the WTRU, after determining to switch the RLC entity based on any of the solutions above (or based on WTRU implementation), sends an indication to the network. In some implementations, this indication may be implicit (e.g., the network will determine the chosen RLC entity based on determining that data has started arriving via a different RLC entity than the RLC entity the previous packets were being received) or explicit (e.g., the WTRU sends an indication, e.g., in a MAC CE, RLC control PDU, indication in the RLC header, etc.,) regarding the chosen RLC entity. In some implementations, later facilitates the network in being able to determine the chosen RLC entity even if the RLC entities were sharing the same logical channel and/or switching of the RLC entity happens before the last packet that was transmitted using the previous RLC entity reaches the network (e.g., packet with SN x was being delayed during RLC AM retransmission in the RLC entity, and SN x+1 was sent and properly received via TM mode. If network receives SN x later than SN x+1, it may incorrectly determine a second switching back to AM mode was made if only implicit indication was used).

[0186] Some implementations include solutions relating to DL aspects. Some of the above example implementations are described regarding UL (e.g., how the WTRU dynamically determines the RLC entity and how it informs the network) and in some implementations, the network behavior is not defined and/or left to network implementation. Some implementations include RLC receiver behavior at the WTRU to support similar dynamic switching of RLC entities in the DL. [0187] In some implementations, the WTRU may be configured to receive an indication from the network to switch the receive RLC entity associated with a PDCP entity. In some implementations, the indication may be an implicit indication (e.g., determination of the reception of data via an RLC entity and associated logical that is different from the RLC entity and logical channel that was used for previous packet or packets) or it may be an explicit indication (e.g., a MAC CE, RLC control PDU, flag in an RLC header, etc.,).

[0188] In some implementations, the WTRU, after determining that the RLC receive entity has been switched from an AM RLC entity to a UM/TM, the WTRU may be configured to reset some of the state variables and counters of the RLC receive window that is being switched from/to (e.g., left edge of the receive window initialized to a first SN, e.g., 0, retransmission count set to 0, all timers such as prohibit/poll timers reset, etc.).

[0189] In some implementations, the WTRU, after switching to a new RLC entity, may determine to retain the SNs of the PDUs associated with a previous RLC entity. In some implementations, the WTRU may reset the timers when switching to the new RLC entity, for example. In some implementations, such retaining of the SNs of previous RLC entity may be made to facilitate avoiding interruption to the procedures at the receiving entities (e.g., reordering of PDUs at receiving PDCP entity).

[0190] Some implementations include solutions relating to other aspects. In some of the above example implementations, the buffer level may be, e.g., the total buffer level or buffer level of certain bearers (e.g., bearers with certain QoS profile, e.g., those that have a stricter latency and/or bit rate requirements than a certain level or as compared to the bearer configuration of the concerned PDCP entity, etc.)

[0191] In some implementations, e.g., in the above, the WTRU may be configured with a combination of any of the above conditions. For example, in some implementations, the TTL is below thresholdl and the radio quality is above threshold2, and the PDU set has an importance level above x, use the RLC AM entity, etc.

[0192] In some implementations, e.g., in the above, the WTRU may be configured to consider not only current values but also average and/or filtered values within a certain configured time window, or the rate of change of the values, or thresholds may be based on other statistical metrics (e.g., averages, standard deviation, minimum/maximum values within the evaluation period, etc.)

[0193] In some implementations, e.g., in the above, it is assumed that the importance level of the PDUs of the PDU set are the same (i.e., one importance level per PDU set). However, in some implementations, such solutions are applicable to cases where different PDUs of the PDU set may have different importance levels. In some implementations, RLC entity determination is performed on a per PDU level in such cases.

[0194] In some implementations, the RLC entity switching may 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 will be retransmitted once via the TM/UM (e.g., AM entity informing the PDCP, and PDCP pushing the concerned PDCP packet to the TM entity).

[0195] In some implementations, the RLC entity switching takes effect only for newly received PDCP packets after the RLC entity is switched (e.g., including the current PDCP packet, if the switching was determ i ned per packet). In such cases, in some implementations, there may be a switching period where more than one RLC entity is being used at the same time (e.g., RLC AM being used to finish the transmission of the packets that were pending retransmissions, while new packets being sent via RLC TM).

[0196] In some implementations, more than one of the RLC entities may be active at the same time. For example, in some implementations, during the switching period, while waiting for the packets that were already being transmitted in one of the RLC entities to be correctly transmitted, while at the same time transmitting the new packets via another RLC entity. In some implementations, the RLC entity is chosen based on PDU importance (e.g., if PDUs within a PDU set can have different importance levels), and PDUs of an importance greater than a certain importance level are sent via RLC AM entity, whereas PDUs of lower importance are sent via the RLC TM entity, etc.

[0197] FIG. 5 is a flowchart illustrating an example procedure (e.g., performed by a WTRU) performed by a WTRU for wireless communications including conditional RLC entity switching, e.g., as further discussed above. In 502, the WTRU receives a PDCP configuration associated with a plurality of RLC entities. In 504, the WTRU receives a configuration of conditions to determine which RLC entity to transmit data. In 506, the WTRU monitors the conditions. In 508 Transmit the data over an RLC entity based on the conditions. Other implementations include additional steps, fewer steps, and/or different steps, e.g., as discussed above.

[0198] Some implementations include solutions relating to an adaptive RLC entity. For example, in some implementations, a DRB and/or PDCP is associated with an RLC AM entity that dynamically adapts its behavior and/or operation (e.g., enable/disable retransmissions) depending on the PDU set characteristics (e.g., importance level) and current PDU set transmission status (e.g., thresholds that consider TTL, PSER, UL buffer level, percentage of the PDU set remaining to be transmitted, etc.) and current WTRU and/or network conditions (e.g., radio conditions, buffer levels).

[0199] In an example implementation relating to an adaptive RLC entity, a WTRU may operate as follows. The WTRU may receive a configuration of a DRB and an associated RLC AM entity with a default max retransmission count value.

[0200] The WTRU may receive a configuration of conditions for determining whether to disable (e.g., max retransmission = 0) and/or enable RLC retransmissions (e.g., max retransmission > 1). In some implementations, the conditions may include one or more of the following thresholds: the TTL of the PDU set to which the PDU belongs; the percentage of PDUs of the PDU set remaining to be transmitted (or the % of the amount of data of the PDU set remaining to be transmitted, if the PDUs of the PDU set can have different sizes); the PSER (either for the concerned PDU set or averaged over several PDU sets); a PDU set or PDU importance; a UL buffer level (of the concerned DRB, or the total UL buffer level); radio conditions (e.g., RSRP thresholds, number of RLC retransmissions, HARQ NACK/ACK levels, etc.); and/or an explicit indication from the network (e.g., MAC CE). [0201] The WTRU may start transmitting the PDCP PDUs via/through the default RLC AM setting. The WTRU may receive monitor the conditions to enable/disable RLC retransmissions. The WTRU may choose the RLC AM retransmission count (e.g., setting it to zero disables retransmissions) based on the monitoring conditions/thresholds and current UE/network conditions. In some implementations, WTRU may flush buffered RLC AM packets waiting an ACK if retransmission is being disabled. The WTRU may send an indication to the gNB/DU about the disabling/enabling of retransmissions: e.g., RLC control PDU, RLC header, (MAC CE), etc. The WTRU may be configured to disable RLF triggering )and subsequent re-establishment) e.g., based on number of retransmissions for this RLC entity (e.g., RLF triggering based on max retransmissions on other RLC entities can still operate as in legacy).

[0202] Some implementations include solutions relating to an RLC entity that is aware of PDU set information. In some implementations, the PDCP informs the RLC entity about the PDU set information (e.g., either explicitly or as part of PDCP header information). The information may include the static PDU set characteristics (e.g., PSDB, number of PDUs, size, PSI HI , and/or importance level, etc.) or dynamic PDU set characteristics (e.g., TTL). In some implementations, this may be facilitated by the PDCP informing the RRC of the WTRU, and RRC configuring the RLC entity.

[0203] In some implementations, the network configures the RLC entity with the PDU set information (e.g., the WTRU may have earlier communicated the PDU set information to the gNB and/or DU, or the network has received the information in another way; e.g., via packet inspection, communication with an application server, etc.)

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

[0205] In some implementations, a WTRU may be configured with an RLC AM entity that may be configured with a maximum retransmission count value of 0, indicating that though the RLC entity, though operating in AM mode, it will not perform a retransmission. In some implementations, if the RLC AM entity is configured with a maximum retransmission count value of 0, it will progress the RLC transmit window as if the packet was correctly received at the receiver (e.g., as if an RLC status PDU ACKing the reception of the packet was received). That is, the packet is immediately after from RLC after being pushed to MAC. [0206] In some implementations, a WTRU may be configured with an RLC AM entity that may be configured with a maximum retransmission count value that is greater than 1, and after retransmitting the packet the allowed number of times, it may flush the concerned packet and progress the RLC transmit window as if the packet was correctly received at the receiver (i.e., as if an RLC Status PDU ACKing the reception of the packet was received). In some implementations, a WTRU may be configured with an RLC AM entity where the maximum retransmission count value is variable from one RLC packet to another (e.g., a first packet may have a max retransmission count value of 1 , a second packet may have a max retransmission count value of 3, etc.) In some implementations, the maximum retransmission count value is common for all RLC packets that are at the transmission buffer. For example, if the maximum retransmission count value was 3, and there was a packet already in its 2^nd retransmission, if the maximum retransmission count is changed to 2, the WTRU may remove that packet from the retransmission packet as if a status PDU was just received indicating its proper reception. [0207] Some implementations include solutions relating to actions when max retransmission count is reached for a given RLC packet. In some implementations, if the retransmission count is set to 0, the WTRU disables the triggering of RLF for that RLC entity based on retransmission counts.

[0208] In some implementations, even if the retransmission count is above 0, the WTRU may be configured to disable the triggering of RLF for that RLC entity when the max retransmission count is reached for a certain packet. That is, as described in the solutions above, the WTRU may behave as if the packet was correctly received and flush it from the retransmission buffer. In some implementations, the WTRU may be configured to log information regarding the number of RLC packets that have reached the maximum retransmission count. For example, this may be a log that is stored at the WTRU containing information such as the SN of the concerned packet, the timestamp, radio conditions at that time, etc. Alternatively, the WTRU may keep statistical information about such events (e.g., number of occurrences, frequency of occurrences, percentage of packets that experience that, etc.) In some implementations, the WTRU may be configured to send the logged information when the network requests it. In some implementations, the WTRU may be configured to send the logged information if certain conditions are fulfilled (e.g., periodically, when the number of occurrences since the last such reporting is above a certain level, when the number of occurrences within a given time duration is above a certain level, when the size of the report is bigger than a certain value, and/or etc.)

[0209] In some implementations, the WTRU may be configured to send an indication that it has logged information (e.g., based on similar conditions as above for sending the report). In some implementations, the WTRU may be configured with conditions that may trigger an RLF and subsequent re-establishment, e.g., if it was not able to send more than a certain number of packets before reaching the retransmission count. In some implementations, this may be constrained by a time duration (e.g., having failed to correctly transmit a certain number of packets within the retransmission count within a given duration). In some implementations, if the maximum retransmission was reached and a packet was flushed, this may not be counted as a failure occurrence if a status PDU was received later that indicates the last retransmission was successful. In some implementations, the disabling of the triggering of RLF may be packet specific. For example, for certain packets (e.g., containing very important PDCP PDUs), In some implementations, the RLF may still be triggered if the WTRU was not able to transmit the packets after trying for the allowed maximum retransmission for that packet. [0210] Some implementations include solutions relating to a WTRU configured with conditions to determine to enable and/or disable retransmissions, and the number of retransmissions. In some implementations, the WTRU is configured to determine whether to apply retransmissions (e.g., and up to how many times) for the packets of an RLC entity, e.g., based on one or more characteristics of the PDU set that is associated with the concerned RLC entity. For example: if the PSDB is smaller than threshold 1, disable RLC retransmissions; if PSDB is between threshold 1 and threshold2, set max retransmission count to 1 ; if PSDB is between threshol d2 and thresholds, set max retransmission count to 2, etc.; if the importance level is below thresholdl , disable RLC retransmissions; if importance level is between thresholdl and threshold2, set max retransmission count to 1; if importance level is between threshold2 and thresholds, set max retransmission count to 2; if importance level is above threshold 3, set max retransmission count to 3, etc.; if the PDU set is a PSIHI PDU set, always enable RLC retransmissions; if the RLC PDU size is above thresholdl , disable RLC retransmissions, etc.); etc. [0211] In some implementations, the WTRU is configured to determine whether to apply retransmissions (e.g., and up to how many times) for the packets of an RLC entity based on the PDU set transmission status. For example: (1) If the TTL is lower than a certain configured threshold, disable retransmissions, if the TTL is between threshold 1 and threshold 2, set the max retransmission count to 1 , if the TTL is between threshold 2 and threshold 3, set the max retransmission count to 2, etc. (2) If the remaining number and/or percentage of the packets of the PDU set is higher than a certain configured threshold, disable retransmissions, if the remaining number and/or percentage of the packets of the PDU set is between threshold 1 and threshold 2, set the max retransmission count to 1, if the remaining number and/or percentage of the packets of the PDU set is between threshold 2 and threshold 3, set the max retransmission count to 2, if the remaining number and/or percentage of the packets of the PDU set is less than thresholds, set it to 3, etc.

[0212] In some implementations, the WTRU is configured to determine whether to apply retransmissions (and up to how many times) for the 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, disable retransmissions, if the UL buffer level is between threshold 1 and threshold 2, set the max retransmission count to 1, if the UL buffer level is between threshold 2 and threshold 3, set the max retransmission count to 2, etc. (2) If the experienced, historical, and/or recent UL throughput is lower than a certain threshold, disable retransmissions, if the experienced, historical, and/or recent UL throughput is between threshold 1 and threshold 2, set the max retransmission count to 1 , if the experienced, historical, and/or recent UL throughput is between threshold 2 and threshold 3, set the max retransmission count to 2, etc.

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

[0214] In some implementations, the WTRU checks the conditions for determining the maximum RLC retransmission count periodically, e.g., with a configured periodicity (e.g., periodO started when the first RLC PDU of the PDU set is sent, periodl starts periodO+periodicity has elapsed, and so on, and the WTRU using the same maximum retransmission count value within one period, etc.) In some implementations, the periodicity may be of time duration or the number of PDUs/bytes transmitted, etc. In some implementations, the WTRU may receive an explicit indication from the network of what maximum retransmission count to apply (e.g., in a MAC CE, RLC control PDU, info in an RLC packet header, etc.)

[0215] Some implementations include solutions relating to a WTRU sending indication to the network based on a max retransmission count change. In some implementations, the WTRU, after changing the maximum retransmission count (e.g., and/or disabling of retransmissions or RLF triggering based on reaching max retransmissions) e.g., based on any of the solutions above (or WTRU implementation, etc.) sends an indication to the network (e.g., in a MAC CE, RLC control PDU, indication in the RLC header, etc.,). In some implementations, this may facilitate the network in being able to progress the receive RLC window size (e.g., in case it was waiting for the retransmission of some packets). In some implementations, the indication may be a simple flag (e.g., retransmission disabled or enabled) or it may contain detailed information (e.g., the SN of the RLC PDU where/when retransmission was disabled/enabled, new max retransmission count, etc.)

[0216] Some implementations include solutions relating to DL aspects. For example, some of the above solutions regard UL (e.g., how the WTRU dynamically determines the RLC entity and how it informs the network) and the network behavior was not defined (as that is usually left to network implementation.). In some implementations, if similar dynamic switching of RLC entities is supported in the DL, RLC receiver behavior is provided at the WTRU.

[0217] In some implementations, the WTRU may be configured to receive an indication from the network that retransmissions are disabled and/or enabled for the RLC entity (e.g., MAC CE, RLC Control PDU, info in an RLC packet header, RRC message, etc.,), and based on the indication, the WTRU may progress the receive window accordingly (e.g., as if there were missing packets that the WTRU was waiting for the network to retransmit, it may progress the receive window as if the packets were received, upon receiving an indication that retransmission is now disabled).

[0218] In some implementations, the WTRU may receive an indication to enable out of order delivery (e.g., if already not configured) for the PDCP entity associated with the concerned RLC entity, e.g., when the peer RLC transmit entity at the network disables retransmissions. In some implementations, this indication may be the same indication from the network as to indicate the RLC retransmission disabling discussed above, or it may be a separate indication (e.g., a PDCP control PDU sent from the network).

[0219] In some implementations, the WTRU may receive an indication to disable in-order delivery (e.g., if already not configured) for the PDCP entity associated with the concerned RLC entity, e.g., when the peer RLC transmit entity at the network enables retransmissions. In some implementations, this indication may be the same indication from the network as to indicate the RLC retransmission enabling discussed above, or it may be a separate indication (e.g., a PDCP control PDU sent from the network).

[0220] Some implementations include solutions relating to other aspects. For example, in some of the above, the buffer level may be the total buffer level or buffer level of certain bearers (e.g., bearers with certain QoS profile, e.g., those that have a stricter latency/bit rate requirements than a certain level or as compared to the bearer configuration of the concerned PDCP entity, etc.)

[0221] In some implementations, the WTRU may be configured with combination of any of the above conditions. For example, if the TTL is above threshold 1 and the radio quality is below threshold2, and the PDU set has an importance level above x, enable retransmissions, etc. In some implementations, the WTRU may be configured to consider not only current values but also average and/or filtered values within a certain configured time window, or the rate of change of the values, or thresholds may be based on any other statistical metrics (e.g., averages, standard deviation, minimum/maximum values within the evaluation period, etc.)

[0222] In some of the above, in some implementations, it is assumed that the importance level of the PDUs of the PDU set are the same (i.e., one importance level per PDU set). However, some implementations, may be applicable to the case where the different PDUs of the PDU set may have different importance levels. In some implementations, maximum RLC retransmission count value may need to be determined on per PDU level in such cases.

[0223] Some implementations include alternative solutions. For example, in some of the above, in some implementations, it may be assumed that the RLC entity is always operating in RLC AM and the maximum retransmission count is determined dynamically (e.g., at a packet level, for all the packets in the current transmission or re-transmission buffer, for all packets within a given time duration, etc.)

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

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

[0226] In some implementations, the change of the RLC mode may impact only new RLC PDUs, or in some implementations, it may impact all packets that are currently in the RLC transmission or re-transmission window (e.g., if the mode is switched from AM to TM, WTRU may flush all the packets that were pending ACK in the receive buffer, etc.)

[0227] In some implementations, the change of the RLC mode may result in the WTRU starting or stopping processing and/or applying SN to packets (e.g., when switching from AM to TM, stop applying SN to packets). In cases where multiple switching is possible (e.g., start with AM due to radio conditions being bad, switch to TM when radio conditions improve, switch back to AM if radio conditions get bad again, etc.,), the WTRU may be configured to restart the sequence number and/or continue the numbering from the last sequence number that was used when the RLC entity was in AM mode earlier.

[0228] FIG. 6 is a flowchart illustrating an example procedure (e.g., performed by a WTRU) for wireless communications including an adaptive RLC entity, e.g., as further discussed above. In 602, the WTRU receives a configuration of an RLC entity. In 604, the WTRU receives a configuration of conditions to determine whether to enable or disable RLC retransmissions. In 606, the WTRU receives the data and monitors the conditions. In 608, the WTRU retransmits the data over the RLC entity based on the conditions. Other implementations include additional steps, fewer steps, and/or different steps, e.g., as discussed above.

[0229] FIG. 7 is a flowchart illustrating another example procedure 700 (e.g., performed by a WTRU) for wireless communications including an adaptive RLC entity, e.g., as further discussed above. In 702, the WTRU transmits a PDU set via an RLC entity. On condition 704 that a condition is met, the RLC entity is configured to enable retransmissions. On condition 706 that the condition is not met, the RLC entity is configured to disable retransmissions. Other implementations include additional steps, fewer steps, and/or different steps, e.g., as discussed above.

[0230] FIG. 8 is a flowchart illustrating another example procedure 800 (e.g., performed by a WTRU) for wireless communications including an adaptive RLC entity, e.g., as further discussed above. In 802, an RLC entity of the WTRU is configured for retransmission. In some embodiments, the RLC entity of the WTRU is configured for retransmission based on a PDU set condition, PDU set transmission condition, network condition, and/or WTRU condition. In 1004, the WTRU transmits the PDU set via the RLC entity. In 804, the PDU set is transmitted via the RLC entity that is configured for retransmission.

[0231] Some implementations include solutions relating to conditional PDCP duplication. For example, in some implementations, a PDCP and/or bearer is associated with more than one RLC entities associated with different carriers (CA case) or links (DC case). For example, in some implementations, the WTRU is configured with conditions for determining to duplicate a PDU of a PDU set based on PDU set characteristics (e.g., based on importance level) and/or current PDU set transmission status (e.g., based on thresholds that consider TTL, PSER, UL buffer level, percentage of the PDU set remaining to be transmitted, etc.) and current WTRU and/or network conditions (e.g., radio conditions, and/or buffer levels).

[0232] In an example implementation relating to conditional PDCP duplication, a WTRU may operate as follows. The WTRU may be configured with CA or DC. The WTRU may receive a configuration of a DRB (split) with one or more RLC entities, where each RLC is associated with a particular carrier (e.g., in CA case) or a particular link/cell group (e.g., in the case of DC).

[0233] The WTRU may receive a configuration of conditions to determine whether to duplicate at least a subset of PDCP PDUs of a PDU set of the DRB, default duplication mode (e.g., on or off), default path (e.g., RLC entity), where the conditions could contain one or more of the following thresholds: the TTL of the PDU set the PDU belongs to; the percentage of PDUs of the PDU set remaining to be transmitted (e.g., or the percentage of the amount of data of the PDU set remaining to be transmitted, if the PDUs of the PDU set can have different sizes); the PSER (e.g., minimum percentage of PDUs of the PDU set expected to be received successfully at receiving entity); PDU set or PDU importance; UL buffer level (e.g., on the primary path, on the alternate path, total UL buffer level, considering only the concerned bearer, and/or etc.); and/or radio conditions (e.g., RSRP thresholds, number of RLC retransmissions, HARQ NACK/ACK levels, and/or etc.)

[0234] The WTRU may start applying PDCP duplication if the default duplication mode was ON. The WTRU may monitor the conditions to enable/disable PDCP duplication. The WTRU may determine the duplication state. If the determined duplication state is ON, after processing a PDCP PDU (e.g., applying security, adding headers, etc.), send the PDCP PDU via both RLC entities. The WTRU may inform network when the PDCP duplication is turned on and/or off.

[0235] In some implementations, the WTRU is configured to determine whether duplication should be applied at PDCP level based on one or more characteristics of the PDU set that is associated with the concerned PDCP entity. For example, in some implementations, the WTRU may operate as follows. The WTRU may apply duplication if the PSDB is larger than a certain configured threshold, and otherwise not apply duplication. The WTRU may, if the importance level is above a certain configured threshold, always apply duplication, if the importance level is below a certain configured threshold, never apply duplication, and if the importance level is between the two thresholds, determine duplication on a packet level based on other conditions (e.g., discussed herein). The WTRU may, if the PDU set is a PSIHI PDU set, apply duplication. The WTRU may, if the PDU set size is above a certain threshold size, not apply duplication, or may apply duplication to up to a certain size and/or percentage of the PDUs of the PDU set (e.g., the first x%, the last x%, the WTRU determines which packets to duplicate based on other conditions discussed here up to the specified x%, etc.,), etc. [0236] In some implementations, the WTRU is configured to determine whether duplication should be applied at the PDCP level based on the current PDU set transmission status. For example, in some implementations, the WTRU may operate as follows. The WTRU may apply duplication if the TTL is larger than a threshold (e.g., a configured threshold). The WTRU may not apply duplication if the TTL is lower than a threshold (e.g., a configured threshold). The WTRU may apply duplication if the remaining number and/or percentage of the PDUs of the PDU set (or the actual and/or percentage of total data of the PDU set remaining to be sent) is below a threshold (e.g., a configured threshold); etc.

[0237] In some implementations, the WTRU is configured to determine whether duplication should be applied at PDCP level based on one or more WTRU conditions associated with UL buffer level. In some implementations, such UL buffer may be associated with any of the buffer at PDCP, RLC or LCH. For example, in some implementations, the WTRU may operate as follows. The WTRU may apply duplication if the UL buffer level on the default path/carrier is above a certain threshold, and otherwise not apply duplication. The WTRU may apply duplication if the UL buffer level on the non-default path/carrier is below a certain threshold, and otherwise not apply duplication. The WTRU may apply duplication 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; etc.

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

[0239] In some implementations, the WTRU checks whether or not to duplicate a PDCP PDU continuously (e.g., for each PDCP PDU to be transmitted, WTRU checks the conditions). In some implementations, the WTRU checks the conditions for duplication periodically; e.g., with a configured periodicity (e.g., periodO started when the first PDU of the PDU set is sent, period 1 starts periodO+periodicity has elapsed, and so on, and the duplication state for that PDCP entity set to ON or OFF for a given period, depending on the determ i nation/checking of the conditions). In some implementations, the periodicity may be of time duration or of the number of PDUs and/or bytes transmitted.

[0240] Some implementations include solutions where a WTRU sends an indication to the network. For example, in some implementations, the WTRU may enable or disable duplication without explicitly informing the network.

[0241] In some implementations, the WTRU may inform the network whenever duplication is enabled or disabled. In some implementations, this indication may include other information regarding the reason for enabling and/or disabling the duplication (e.g., which of the conditions for triggering duplication enabling and/or disabling were fulfilled, etc.,). Alternatively, this indication may indicate the preference for enabling and/or disabling duplication (e.g., including the start time and/or duration for enabling and/or disabling duplication).

[0242] In some implementations, such an information may be useful for the network to allocate resources to the WTRU and other UEs properly. For example, in some implementations, if the WTRU informs the network that duplication is being enabled, the network may attempt to allocate more resources to the WTRU (e.g., on the non-default path/carrier) in anticipation of duplicated data. On the other hand, in some implementations, if the WTRU informs the network that duplication is being disabled, the network may free resources (e.g., any resources) that may have been provided by the WTRU in anticipation of duplicated data, and these resources (e.g., configured grants, etc.,) may be provided for other WTRUs.

[0243] In some implementations, the WTRU, instead enabling or disabling the duplication by itself, may send an indication to the network that the conditions for enabling or disabling the duplication are fulfilled, and the network may enable and/or disable the duplication (e.g., using the legacy mechanism of activating/deactivating duplication via a MAC CE) based on the indication. In some implementations, the WTRU, if enabling duplication, may send a buffer status report (BSR) to the network (e.g., to the secondary node, if the default path was the master node, or vice versa, etc.. In some implementations, the BSR may indicate the expected data (e.g., new duplicated data) that will arrive on the new path.

[0244] Some implementations include solutions relating to other aspects. For example, in some of the above, the buffer level may be the total buffer level or buffer level of certain bearers (e.g., bearers with certain QoS profile, e.g., those that have a stricter latency and/or bit rate requirements than a certain level or as compared to the bearer configuration of the concerned PDCP entity, etc.)

[0245] In some implementations, the WTRU may be configured with a combination of any of the above conditions. For example, in some implementations, if the TTL is below threshold 1 and the radio quality on the default path/carrier is below threshold2, the WTRU may apply duplication, etc. In some implementations, the WTRU may be configured to consider not only current values but also average and/or filtered values within a certain configured time window, or the rate of change of the values, or thresholds may be based on any other statistical metrics (e.g., averages, standard deviation, minimum/maximum values within the evaluation period, etc.) [0246] In some of the above, in some implementations, it is assumed that the importance level of the PDUs of the PDU set are the same (i.e., one importance level per PDU set). However, some implementations may be applicable to the case where the different PDUs of the PDU set may have different importance levels. In some implementations, PDCP duplication determination may need to be performed on per PDU level in such cases.

[0247] In some of the above, in some implementations, the WTRU may be configured with a duplication state change prohibit timer, which indicates for how long the WTRU waits before it may change the duplication state. In some implementations, in the case of periodic duplication checking, the periodicity may be considered to be the same as the prohibit timer (e.g., as the WTRU checks the conditions for duplication state every periodicity, it will not be able to change the duplication state in less than the periodicity). However, in some implementations, in cases where duplication state may be changed in an ad-hoc fashion, the prohibit timer may be started each time the duplication state is changed, and duplication may not change until the prohibit time duration has elapsed.

[0248] In some implementations, the prohibition may be “sticky” for the PDU set, in that the duplication state may be changed only once and for the rest of the PDU set, the duplication state will not be changed. In some implementations, the WTRU will determine the duplication state at the start of the PDU set, and it will keep using the determined duplication state (i.e., to duplicate or not duplicate) for the rest of the PDU set transmission. In some implementations, the WTRU may be configured to be able to change the duplication sate a maximum of a certain number of times within the lifetime of a PDU set.

[0249] FIG. 9 is a flowchart illustrating an example procedure (e.g., performed by a WTRU) performed by a WTRU for wireless communications including conditional PDCP duplication, e.g., as further discussed above. In 902, the WTRU receives a configuration of a plurality of RLC entities. In 904, the WTRU receives a configuration of conditions to determine whether to transmit the data over more than one of the RLC entities. In 906, the WTRU monitors the conditions. In 908, the WTRU transmits the data over more than one of the RLC entities based on the conditions. Other implementations include additional steps, fewer steps, and/or different steps, e.g., as discussed above.

[0250] Some implementations include solutions relating to conditional retransmission over a second path. For example, in some implementations, a PDCP/bearer is associated with more than one RLC entity, each associated with different carriers (CA case) or links (DC case). In some implementations, the WTRU is configured to first send a PDCP PDU over one RLC entity (e.g., default path, the path with a grant currently available, etc.,), and if certain conditions are not fulfilled (e.g., within a given time), the WTRU sends a copy of the PDU over the other RLC entity (e.g., thresholds that consider RLC status reception indicating ACK/NACK reception associated with the first transmission within a given time, buffer level on the first path, radio conditions over the first path/carrier, etc.,). In some implementations different conditions may be configured for different PDU set characteristics (e.g., importance level) and transmission status (e.g., TTL, percentage of PDUs already sent, etc.,). In some implementations, the WTRU may be configured to switch the default path after that until second set of conditions are fulfilled or a certain time has elapsed.

[0251] In an example implementation relating to conditional retransmission over a second path, a WTRU may operate as follows. The WTRU may be configured with CA or DC. The WTRU may receive a configuration of a DRB (split) with one or more RLC entities, where each RLC is associated with a particular carrier (e.g., in CA case) or a particular link/path (e.g., in the case of DC), and one of the RLC entities set as the default.

[0252] The WTRU may receive a configuration of conditions to determine to retransmit a certain PDCP PDU over a second path, after a given configured time duration has elapsed after the transmission of the data on a first path and the reception of the packet has not been acknowledged, where the conditions could contain one or more of the following thresholds: one or more NACKs (e.g., RLC status indicating a NACK for the PDU, RLC status indicating a NACK for other PDUs, etc.,) is received; number of HARQ retransmissions; buffer level on the first path or the second path; and/or radio link quality over the first path and/or the second path. The conditions may be further dependent on PDU set characteristics (e.g., importance level) and current PDU set transmission status (e.g., TTL, percentage of PDUs of the PDU set remaining to be sent, etc.)

[0253] The WTRU may send the packet over the first and/or default path after processing a PDCP PDU (e.g., applying security, adding headers, etc.). If the configured time has elapsed and the reception of the packet has not been acknowledged, the WTRU may check the conditions to retransmit the packet. The WTRU may send a copy of the PDCP PDU via the other path or paths if the conditions to retransmit over the other path or paths is fulfilled. The WTRU may be configured to stop attempting to retransmit the concerned packet over the first path after sending the copy. In some implementations, the WTRU is configured with conditions to determine whether to retransmit (e.g., send a copy of) a PDCP PDU over a second path after it has sent the PDU over a first path.

[0254] In some implementations, the conditions for the retransmission may include the elapsing of a configured time duration after the sending of the packet over the first path and the fulfillment of one or more of the following during the configured time duration: acknowledgement for the concerned packet has not been received; reception of one or more RLC status PDUs indicating an RLC PDU containing the concerned PDCP PDU is missing; reception of one or more RLC status PDUs indicating a certain number of (or percentage of) missing RLC PDUs; detection of a certain number (or percentage) of HARQ retransmissions after the sending of the packet over 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 of the radio link quality being below a certain threshold over the first path (this may be averaged/filtered value during the time duration); and/or detection of the radio link quality being above a certain threshold over the second path (this may be averaged/filtered value during the time duration).

[0255] In some implementations, the conditions for the retransmission over the other path (e.g., the configured waiting time duration, the number of RLC status PDUs indicating an RLC PDU is missing, the number/percentage of HARQ retransmissions, the level of UL buffer level increase/decrease, radio quality level on the first and second path, and/or etc.) are dependent on the characteristics of the PDU (e.g., PDU set importance, PSDB, PSHI, etc.,). That is, the WTRU may be configured with multiple sets of values for different characteristics of the PDU set (e.g., different waiting time durations for different PSDB or PDU set importance, etc.,).

[0256] In some implementations, the conditions for the retransmission over the other path (e.g., the configured waiting time duration, the number of RLC status PDUs indicating an RLC PDU is missing, the number/percentage of HARQ retransmissions, the level of UL buffer level increase/decrease, radio quality level on the first and second path, and/or etc.) are dependent on the status of the PDU set transmission (e.g., TTL, PSER, percentage of the PDUs of the PDU set that still remain to be transmitted, etc.,). That is, the WTRU may be configured with multiple sets of values for different transmission state of the PDU set (e.g., different waiting time durations for different TTL, etc.,). For example, in some implementations, the WTRU may be configured to apply a longer waiting time duration when the TTL is high as compared to when the TTL is low.

[0257] In some implementations, the fulfillment of the conditions for retransmission affects only one particular packet. In some implementations, the WTRU does not check the conditions for retransmission for all packets every time after sending them over the first path, but may be configured to check the conditions periodically (e.g., every x ms, every n PDUs, etc.,). In some implementations, the WTRU may be configured to retransmit over the second path all the packets that were sent before this packet over the first path but still waiting their acknowledgement if the conditions for retransmission are fulfilled for this packet,. In some implementations, only a certain number and/or percentage of these packets are retransmitted, instead of all of these packets being retransmitted.

[0258] In some implementations, the WTRU, after determining to retransmit a packet over the second path, may stop retransmitting/transmitting that packet over the first path (e.g., all RLC PDUs containing the PDCP PDU are flushed from the transmission buffer of the RLC of the first path). In such cases, in some implementations, the WTRU may need to send information to the network regarding this occurrence (e.g., so that the receive RLC entity at the network does not have to wait for a packet that will not be sent again). In some implementations, this may be done via a MAC CE, RLC header info, RLC control PDU, etc.,

[0259] In some implementations, the WTRU, after determining to retransmit a packet over a second path, may pause using the first path for transmitting any new data of the concerned PDCP for a given configured time duration or until some other conditions are fulfilled (e.g., retransmission to the first path is determined while using the second path, the buffer level on the first path has dropped to a certain level, the radio quality over the first link is now above a certain threshold, the number/percentage of HARQ retransmissions or RLC status PDUs indicating missing PDUs on the first path has fallen below a certain threshold, and/or etc.) [0260] In some implementations, the buffer level could be the total buffer level or buffer level of certain bearers (e.g., bearers with certain QoS profile, e.g., those that have a stricter latency/bit rate requirements than a certain level or as compared to the bearer configuration of the concerned PDCP entity, etc.,)

[0261] In some implementations, it may be assumed that the importance level of the PDUs of the PDU set are the same (i.e., one importance level per PDU set). However, some implementations are equally applicable to the case where the different PDUs of the PDU set may have different importance levels. For example, in some implementations, waiting time duration for important PDUs may be set to be smaller than non-important PDUs, etc.

[0262] FIG. 10 is a flowchart illustrating an example procedure (e.g., performed by a WTRU) performed by a WTRU for wireless communications including conditional retransmission, e.g., as further discussed above. In 1002, the WTRU receives a configuration of a plurality of RLC entities. In 1004, the WTRU receives a configuration of conditions to determine whether to transmit duplicate data over a second RLC entity. In 1006, the WTRU transmits data over a first RLC entity. In 1008, the WTRU transmits a duplicate of the data over a second RLC entity based on the conditions. Other implementations include additional steps, fewer steps, and/or different steps, e.g., as discussed above.

[0263] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, WTRU, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is Claimed:

1. A method for wireless communications implemented in a wireless transmit/receive unit (WTRU), the method comprising: receiving configuration information indicating a configuration for an acknowledged mode (AM) radio link control (RLC) entity; receiving a packet data unit (PDU) set via a packet data convergence protocol (PDCP) entity; configuring the AM RLC entity for retransmission based on at least one condition, wherein the at least one condition comprises a PDU set characteristic and/or a PDU set transmission status; transmitting the PDU set via the AM RLC entity; receiving an RLC status PDU indicating an RLC status; and retransmitting one or more PDUs of the PDU set, via the RLC entity, responsive to the RLC status.

2. The method of claim 1 , wherein the PDU set characteristic comprises a priority level of the PDU set and/or a type of the PDU set.

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

4. The method of claim 1 , wherein the at least one condition comprises a network condition.

5. The method of claim 1 , wherein the at least one condition comprises a radio condition.

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

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

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

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

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

11. A wireless transmit/receive unit (WTRU) comprising: circuitry configured to receive configuration information indicating a configuration for an acknowledged mode (AM) radio link control (RLC) entity; circuitry configured to receive a first packet data unit (PDU) set via a packet data convergence protocol (PDCP) entity; circuitry configured to configure the AM RLC entity for retransmission based on at least one condition, wherein the at least one condition comprises a PDU set characteristic and/or a PDU set transmission status; circuitry configured to transmit the PDU set via the AM RLC entity; circuitry configured to receive an RLC status PDU indicating an RLC status; and circuitry configured to retransmit one or more PDUs of the PDU set, via the RLC entity, responsive to the RLC status.

12. The WTRU of claim 11 , wherein the PDU set characteristic comprises a priority level of the PDU set and/or a type of the PDU set.

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

14. The WTRU of claim 11, wherein the at least one condition comprises a network condition.

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

16. The WTRU of claim 11, wherein the at least one condition comprises a WTRU condition.

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

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

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

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