Adapting a discard mechanism to extended traffic.

Abstract

A wireless transceiver unit (WTRU) may receive configuration information indicating the priority value of a set of protocol data units (PDUs). The WTRU may determine that a set of PDUs is associated with a priority higher than its priority value. Based on the determination that a set of PDUs is associated with a priority higher than its priority value and that no status report associated with the PDU set has been received by the WTRU, the WTRU may determine that a polling indicator should be sent. The WTRU may send a polling indicator. The polling indicator may indicate a request for the transmission of a status report associated with the PDU set.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 456,958, filed on April 4, 2023, the content of which is incorporated herein by reference.

Background Art

[0002] Mobile communications using wireless communication have been continuously evolving. The fifth generation is sometimes called 5G. The previous (legacy) generations of mobile communications can be, for example, the fourth generation (4G) Long Term Evolution (LTE).

Summary of the Invention

[0003] [[ID=二十一]]Systems, methods, and means related to a wireless transmit - receive unit (WTRU) configured to send a polling indicator are described herein.

[0004] In the example, the WTRU may receive configuration information indicating the priority value of a set of protocol data units (PDUs). The WTRU may determine that the set of PDUs is associated with a priority higher than its priority value. Based on the determination that the set of PDUs is associated with a priority higher than its priority value and that no status report associated with the PDU set has been received by the WTRU, the WTRU may decide that a polling indicator should be sent. The WTRU may send a polling indicator. The polling indicator may indicate a request for the transmission of a status report associated with the PDU set. In some examples, the WTRU may receive an indication of a time period, determine that no status report has been received by the WTRU within that time period, and send a polling indicator. For example, the WTRU may send a polling indicator to the network in a Packet Data Convergence Protocol (PDCP) packet. The WTRU may send a polling indicator to the network in a Radio Link Control (RLC) packet. A status report associated with a set of PDUs is used to indicate the reception of the PDU set. The priority of a PDU set indicates the level of importance of that PDU set for Extended Reality (XR) applications.

[0005] In the example, WTRU may determine a PDU set delay budget (PSDB) threshold and determine that the PSDB associated with a PDU set is less than the PSDB threshold. Based further on this determination that the PSDB associated with a PDU set is less than the PSDB threshold, WTRU may decide to send a polling indicator.

[0006] In the example, WTRU may determine the PDU reception rate associated with a set of PDUs. The PDU reception rate may represent the number or percentage of PDUs in the PDU set that are being received. WTRU may determine that the PDU reception rate associated with a set of PDUs is below a PDU reception threshold. WTRU may then decide to send a polling indicator based on the determination that the PDU reception rate associated with a set of PDUs is below a PDU reception threshold.

[0007] In the example, the WTRU may receive a status report related to a PDU set after a polling indicator has been sent. The status report may indicate that the PDU set has been received. Based on the status report, the WTRU may determine that the PDU set has been received and discard the PDU set based on that determination. [Brief explanation of the drawing]

[0008] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transceiver unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram showing a further exemplary RAN and a further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2] This is an example illustrating the decision to send a polling indicator and the transmission of the polling indicator. [Modes for carrying out the invention]

[0009] Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple radio users. The communication system 100 may enable multiple radio users to access such content through the sharing of system resources, including radio bandwidth. For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, and filter bank multicarrier (FBMC).

[0010] As shown in Figure 1A, the communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend 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 radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be called “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, IoT devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating on commercial and / or industrial radio networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be called WTRU.

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

[0012] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown) such as base station controllers (BSCs), radio network controllers (RNCs), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be called cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells may provide coverage for radio services to a particular geographic area that may be relatively fixed or change over time. Cells may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers per sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0013] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via an air interface 116 which may be any suitable radio 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).

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

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

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

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

[0018] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), GSM®, GSM Advanced Data Rate (EDGE), and GSM EDGE (GERAN).

[0019] In Figure 1A, base station 114b could be, for example, a wireless router, home node B, home enode B, or access point, and could utilize any suitable RAT to facilitate wireless connectivity in localized areas such as workplaces, homes, vehicles, premises, industrial facilities, aerial corridors (for use by drones, for example), and roads. In one embodiment, base station 114b and WTRU 102c, 102d could implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRU 102c, 102d could implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRU 102c, 102d could utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0020] RAN 104 / 113 may communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data may have varying Quality of Service (QoS) requirements such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video delivery, etc., and / or implement high-level security functions such as user authentication. Although not shown in FIG. 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 may communicate directly or indirectly with other RANs that employ the same or different radio access technologies (RATs) as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113 that may utilize New Radio (NR) wireless technology, CN 106 / 115 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi wireless technology.

[0021] CN106 / 115 may also act as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides 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), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) within the TCP / IP Internet protocol suite. The network 112 may include wired and / or wireless communication networks that are owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs that may employ the same RAT or a different RAT than the RAN 104 / 113.

[0022] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include multimode capabilities (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in FIG. 1A may be configured to communicate with a base station 114a that may employ cellular-based wireless technology and may be configured to communicate with a base station 114b that may employ IEEE802 wireless technology.

[0023] FIG. 1B is a system diagram showing an exemplary WTRU 102. As shown in FIG. 1B, the WTRU 102 may specifically include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a GPS chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 may include any sub-combination of the above elements while remaining in accordance with the embodiments.

[0024] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other 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. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

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

[0032] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of the signal (e.g., related to a particular subframe for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference through signal processing either through hardware (e.g., chokes) or a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WRTU102 may include a half-duplex radio for the transmission and reception of some or all of the signal (e.g., related to a particular subframe for either UL (e.g., for transmission) or downlink (e.g., for reception)).

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

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

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

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

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

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

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

[0040] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional fixed-line telephone communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0041] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in some typical embodiments where such a terminal may be used (for example, temporarily or permanently), wired communication is considered to interface with the communication network.

[0042] In a typical embodiment, the other network 112 may be a WLAN.

[0043] 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 to or interfaces with a distribution system (DS) or another type of wired / wireless network that carries traffic entering and leaving the BSS. Traffic originating from outside the BSS to an STA may arrive through the AP and be sent to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to the AP for distribution to its respective destination. Traffic between STAs within the BSS may be sent through the AP, for example, here, a source STA may send traffic to the AP, and the AP may send traffic to the destination STA. Traffic between STAs within the BSS is considered and / or sometimes referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (e.g., directly between them) using a Direct Link Setup (DLS). In some typical embodiments, the DLS may be an 802.11e DLS or an 802.11z Tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have access points (APs), and STAs within or using IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the “ad-hoc” communication mode in this specification.

[0044] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In some typical embodiments, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented in the 802.11 system, for example. In CSMA / CA, an STA, including the AP (e.g., any STA), may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA may back off. One STA (e.g., just one station) may transmit in a given BSS at a given time.

[0045] A high-throughput (HT) STA may use a 40MHz wide channel for communication via a combination of primary 20MHz channels, for example, with adjacent or non-adjacent 20MHz channels, in order to form a 40MHz wide channel.

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

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

[0048] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the primary channel may be 1MHz wide for an STA (e.g., an MTC-type device) that supports (e.g., only) the 1MHz mode. Carrier detection and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to the AP, a large portion of the frequency band remains idle, and the entire available frequency band may be considered busy, even if it could be available elsewhere.

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

[0050] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 may employ NR radio technology to communicate with WTRU102a, 102b, and 102c via air interface 116. RAN113 may also communicate with CN115.

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

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

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

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

[0055] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the above elements is shown as part of CN115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] AMF182a and 182b may be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and may function as control nodes. For example, AMF182a and 182b may be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize the support for WTRU102a, 102b, and 102c CNs based on the type of service that is being utilized. For example, different network slices may be established for different use cases, such as services relying on high-reliability, low-latency (URLLC) access, services relying on extended large-scale mobile broadband (eMBB) access, and services using machine-type communications (MTC) access. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0057] SMF183a and 183b may be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b may also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b may select and control UPF184a and 184b and configure traffic routing through UPF184a and 184b. SMF183a and 183b may perform other functions such as managing and allocating IP addresses for WTRUs, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. The type of PDU session may be IP-based, non-IP-based, Ethernet-based, etc.

[0058] UPF184a, 184b may be connected to one or more of the gNB180a, 180b, 180c in RAN113 via an N3 interface that can give WTRU102a, 102b, 102c access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, 102c and IP-enabled devices. UPF184, 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 downlink packets, and providing mobility anchoring.

[0059] CN115 can facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. Furthermore, CN115 may grant WTRU102a,102b,102c access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a,102b,102c may be connected to the local data network (DN) 185a,185b through UPF184a,184b via an N3 interface to UPF184a,184b and an N6 interface between UPF184a,184b and DN185a,185b.

[0060] In view of Figures 1A to 1D and the corresponding descriptions of Figures 1A to 1D, one or more or all of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a to b, e-nodes B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0061] Emulation devices may be designed to perform one or more tests on other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one, more, or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one, more, or all functions while being temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device to be tested and / or to perform tests using over-the-air radio communication.

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

[0063] This specification describes systems, methods, and means related to a wireless transceiver unit (WTRU) configured to send polling indicators.

[0064] In the example, the WTRU may receive configuration information indicating the priority value of a set of protocol data units (PDUs). The WTRU may determine that the set of PDUs is associated with a priority higher than the PDU set's priority value. Based on the determination that the set of PDUs is associated with a priority higher than the PDU set's priority value and that no status report associated with the PDU set has been received by the WTRU, the WTRU may decide to send a polling indicator. The WTRU may send a polling indicator. The polling indicator may indicate a request for the transmission of a status report associated with the PDU set. In some examples, the WTRU may receive an indication of a time period, determine that no status report has been received by the WTRU within that time period, and send a polling indicator. For example, the WTRU may send a polling indicator to the network in a Packet Data Convergence Protocol (PDCP) packet. The WTRU may send a polling indicator to the network in a Radio Link Control (RLC) packet. A status report associated with a PDU set is used to indicate the reception of the PDU set. The priority of a PDU set indicates the level of importance of that PDU set for Extended Reality (XR) applications.

[0065] In the example, WTRU may determine a PDU set delay budget (PSDB) threshold and determine that the PSDB associated with a PDU set is less than the PSDB threshold. Based further on this determination that the PSDB associated with a PDU set is less than the PSDB threshold, WTRU may decide to send a polling indicator.

[0066] In the example, WTRU may determine the PDU reception rate associated with a set of PDUs. The PDU reception rate may represent the number or percentage of PDUs in the PDU set that are being received. WTRU may determine that the PDU reception rate associated with a set of PDUs is below a PDU reception threshold. WTRU may then decide to send a polling indicator based on the determination that the PDU reception rate associated with a set of PDUs is below a PDU reception threshold.

[0067] In the example, the WTRU may receive a status report related to a PDU set after a polling indicator has been sent. The status report may indicate that the PDU set has been received. Based on the status report, the WTRU may determine that the PDU set has been received and discard the PDU set based on that determination.

[0068] This specification describes systems, methods, and means relating to a radio transceiver unit (WTRU) configured to send polling indicators at the Packet Data Convergence Protocol (PDCP) level or at least at the Radio Link Control (RLC) level based on importance related to a set of protocol data units (PDUs).

[0069] For example, a WTRU may receive configuration information indicating the importance threshold of a PDU set. A WTRU may receive a PDU set and determine the importance of the PDU sets associated with it. Based on the importance threshold of the PDU set and the importance of the PDU sets associated with it, a WTRU may decide to send a polling indicator (for example, to the network). A WTRU may send a polling indicator as a transmitting PDCP entity, for example.

[0070] A WTRU may determine that no status report has been received. If received, a status report may indicate the successful delivery of a PDU from the PDU set. A polling indicator may be sent to the network based on the determination that no status report has been received (for example, within a time window if the configuration information indicates a time window). A WTRU may determine the size of the PDU set and send an indication of the PDU set size to the network, for example, if the WTRU is a transmitting RLC entity. The configuration information may indicate a PDU set delay budget (PSDB) threshold, and a polling indicator may be determined to be sent based on the PSDB threshold.

[0071] If the WTRU receives a status report indicating successful delivery of the PDU set, the PDU set may be discarded, for example, at the PDCP level or the RLC level.

[0072] In one or more examples herein, a discard mechanism (in PDCP and / or RLC) may be implemented. Polling may be introduced in PDCP. Polling (e.g., extended polling) may be used in RLC.

[0073] In PDCP and RLC, PDUs within a PDU set are held before being sent (for example, to lower layers such as MACs) to facilitate discarding (for example, to ensure that discarding occurs).

[0074] For critical PDU sets, features or elements in one or more examples herein may be used to facilitate (e.g., ensure) that discarding occurs (e.g., only occurs) after the WTRU has received a status report confirming the successful delivery of the critical PDU set. Polling (e.g., a polling mechanism) may be introduced into the PDCP. The criticality of the PDU set may be considered with respect to RLC polling (e.g., as an extension of legacy RLC polling).

[0075] Features or elements in one or more examples herein may be used to facilitate (e.g., ensure) that discarding can actually occur for a PDU set, where the loss / delay of one PDU in the PDU set renders the remaining PDUs in the PDU set useless. A holding mechanism may be introduced in the PDCP. A holding mechanism may be introduced in the RLC. Discarding may occur in the receiving PDCP.

[0076] Extended reality (XR) may include augmented reality (AR), virtual reality (VR), mixed reality (MR), and areas interpolated between them. An XR application provider may use system functions (e.g., the system functions described in Figures 1A to 1D) for XR services. A WTRU may include an XR client and an XR-aware application for using network functions using a network interface and an application programming interface (API).

[0077] In XR traffic, dependencies can occur in one or more ways: between PDUs (e.g., within a PDU set or data burst), between PDU sets, between data bursts, or across multiple flows. A PDU set can be used for processing and delivering a group of PDUs belonging to that set. In the example, there may be multiple (e.g., two) types of PDU sets, including a first type of PDU set (e.g., Type I) and a second type of PDU set (Type II). A first type of PDU set may not tolerate any loss / delay of any PDU in the set (e.g., it cannot) (e.g., when one of the PDUs is lost or delayed, the remaining PDUs in the PDU set may be dropped). A second type of PDU set may tolerate some loss / delay (e.g., an XR application can reconstruct a PDU set with some PDUs delayed / lost). Table 1 gives an example of a PDU set integrated display (PSII or PSIHI).

[0078] [Table 1]

[0079] A first type of PDU set (e.g., a Type I PDU set) can be marked with a PSIHI indicator. PDU set importance can be introduced for XR traffic. PDU set importance can be applicable to DL and uplink (UL) traffic. In addition to QoS parameters (e.g., PDU set delay budget (PSDB), PDU set error rate (PSER)), PDU set importance can provide additional granularity to how packets may be handled (e.g., how packets may be handled at the AS layer). PDU set importance can be relative from one PDU set to another. PDU set importance can be marked (e.g., for applications used in NG-RAN).

[0080] In some examples, the importance of a PDU set may be an indicator (e.g., a flag / indicator) showing whether the PDU set is important or not. For example, the absence of a flag / indicator indicates that the PDU set is not important. In some examples, the importance of a PDU set may be more granular. For example, there may be different levels corresponding to importance values ​​for different PDU sets (e.g., different scores corresponding to importance values ​​for different PDU sets). A higher importance value may indicate a higher level of importance. Importance values ​​may be marked by applications / higher layers in the WTRU. In one or more examples herein, lower layers in the WTRU (e.g., the AS layer) may be able to read the importance values. Importance values ​​may affect one or more functions in the WTRU (e.g., the importance value indicates the degree of such an effect). For example, for important PDU sets, discarding at the PDCP layer may be delayed. For important PDU sets, discarding the PDU set may occur only after a status report confirming successful delivery of the PDU set at the receiving end has been received (e.g., only then).

[0081] A PDU set can contain a group of PDUs (e.g., corresponding to a single video frame). In some applications, PDUs in a PDU set (e.g., all PDUs) are required for decoding the PDU set. If one or more PDUs in a PDU set are determined to be lost / delayed (e.g., known to be lost / delayed), the remaining PDUs in the PDU set may become unavailable (e.g., useless to the application). PDU discarding can be frequent for XR services (and more frequent for non-XR services). Some discarding mechanisms may be designed to treat discarding as an error case (e.g., legacy discarding mechanisms may be designed to treat discarding as an error case and be inadequate for handling XR traffic). This may not be an example of XR traffic where discarding is frequent. Some discarding mechanisms (e.g., discarding mechanisms designed to treat discarding as an error case) may not take into account the characteristics of XR traffic.

[0082] Some discard mechanisms (e.g., legacy discard mechanisms) may include the following: PDCP discard can occur, for example, when the discard timer expires for a PDCP service data unit (SDU), or when the successful delivery of a PDCP SDU is confirmed by a PDCP status report, as shown in Table 2. Table 2 shows an example of PDCP discard for an exemplary discard mechanism (e.g., legacy discard mechanism). RLC discard can occur when a PDU is not submitted to the lower layer (MAC). Table 3 shows an example of RLC discard for an exemplary discard mechanism (e.g., legacy discard mechanism).

[0083] [Table 2]

[0084] [Table 3]

[0085] XR traffic may have lower latency requirements (e.g., lower latency requirements than non-XR traffic). Discarding may be done for XR traffic (e.g., often) (e.g., discarding may be done more frequently for XR traffic than for non-XR traffic). Discarding procedures that do not increase / introduce additional latency may be used. For critical PDU sets, features or elements may be used to facilitate (e.g., guarantee) that discarding occurs (e.g., only occurs) after the WTRU has received a status report confirming the successful delivery of the critical PDU set.

[0086] In one or more examples herein, polling may be used to facilitate (e.g., assure) a sending entity that a receiving entity will send a polling bit / indicator for any important PDU set. The importance of a PDU set may be indicated by the priority associated with the PDU set. In response to the polling bit / indicator, the receiving entity may send a status report associated with the PDU set to the sending entity. A status report associated with a PDU set, when received by the sending entity, may indicate the delivery status of the PDU set (e.g., confirming the delivery status of the PDU set). The delivery status of a PDU set may mean that the PDU set has been received. The sending entity may not discard a PDU set until it receives a status report (e.g., a status report confirming the successful delivery of the PDU set). For example, the sending entity may discard a PDU set only upon receiving a status report confirming the successful delivery of the PDU set.

[0087] Sending a bit / indicator to poll for (any) critical PDU sets can facilitate (e.g., guarantee) that critical PDU sets are not discarded unless / until a status report confirming the successful delivery of the PDU set is received on the receiving (Rx) side, and can facilitate that critical PDU sets may be discarded without introducing an additional delay (e.g., critical PDU sets may be discarded as soon as a status report is received).

[0088] In one or more examples described herein, polling may be introduced into PDCP (in contrast to some examples where, for example, the polling mechanism is not used in PDCP). For example, a polling indicator may be sent in a PDCP packet or PDCP header. In one or more examples described herein, polling may be used in RLC based on the importance and / or association or dependency of PDU sets (in contrast to examples where, for example, the importance of a set of PDUs or the dependency of PDUs is not considered for polling in RLC, or where polling in RLC is defined without regard to the importance of a set of PDUs or the dependency of PDUs (for example, blindly defined so that a polling indicator is added every n PDUs or every n bytes)). For example, a polling indicator may be sent in an RLC packet or RLC header.

[0089] Some PDU sets may be associated with (e.g., marked by) a PDU set integrated handling indication (PSIHI). The PSIHI indicator may be used to indicate, for the type of PDU set associated with the PSIHI, that the loss / delay of one PDU in the PDU set renders the remaining PDUs in the PDU set unusable for certain purposes (e.g., the remaining PDUs may become useless). Discarding may be necessary for the remaining PDUs in the same PDU set as the lost / delayed PDU (e.g., discarding may often need to occur for XR traffic). In some examples, discarding may not occur when the PDU is submitted to a lower layer (e.g., MAC). In one or more examples herein, features or elements may be used to facilitate (e.g., guarantee) the discarding of a PDU set when the loss / delay of one PDU in the PDU set renders the remaining PDUs in the PDU set useless.

[0090] In one or more examples herein, for a PDU set associated with a PSIHI indicator, a feature or element may be used to facilitate (e.g., ensure) that the PDUs in the PDU set associated with the PSIHI indicator are collectively discarded (e.g., because PDUs may become ineligible to discard once submitted to the MAC). In one or more examples herein, a feature or element may be used to facilitate (e.g., ensure) that when discard is triggered, new data (e.g., PDUs from the PDU set) is not submitted to the lower layer and data already submitted to the lower layer is discarded. These features or elements in one or more examples herein may prevent unwanted (re)transmissions. In one or more examples described herein, a retention scheme may be used to "retain" PDUs in a PDU set (e.g., one or more of the remaining PDUs in a PDU set associated with a PSIHI indicator) at the PDCP layer until more PDUs from the PDU set are received at the PDCP (e.g., at the PDCP layer). In one or more examples described herein, the RLC may "hold" PDUs from the PDU set associated with the PSIHI indicator until it receives an indication (e.g., from a lower layer such as a MAC) that the RLC has sufficient permission / resources to adapt to the entire PDU set. Some examples herein may relate to discarding at the transmitting side (e.g., transmitting PDCP or RLC). In Example 2(C), if some PDUs from the PDU set associated with the PSIHI indicator have been transmitted despite the loss / delay of PDUs in the PDU set, the receiving entity may perform discarding.

[0091] In one or more examples described herein, polling may be introduced in a PDCP (e.g., a polling indicator may be sent via the PDCP layer). A WTRU may send polling bits / flags related to a PDU set having several characteristics (e.g., the importance of a PDU set) and be configured to trigger a status report on the successful reception of the PDU set (e.g., in contrast to some examples where status polling at the PDCP level is not performed). For example, a WTRU (e.g., Transmit (Tx)PDCP) may receive configuration information from the network indicating one or more of the following: configurations related to polling, an importance threshold for a PDU set (e.g., P1), or a time window threshold (e.g., T1) that can be used to trigger polling. In the example, T1 may be a timer created as a standalone timer or in accordance with a PDU set delay budget (e.g., PSDB). The WTRU may receive data related to a PDU set from a higher layer (e.g., the application layer). The WTRU may receive or derive the importance of a PDU set (e.g., based on the priority of the PDU set). A WTRU may send a polling indicator to the network based on the importance and / or other information of a set of PDUs. For example, if, in T1, the importance of a set of PDUs is greater than the importance threshold P1 of the set, and the WTRU has not received a status report confirming the successful delivery of any PDUs in the set, the WTRU may send a polling indicator to the network. In the example, one status report may be sent for the set of PDUs. In some examples, multiple status reports may be sent for any PDUs in the set. If the WTRU receives a status report from the network confirming the successful delivery of a set of PDUs / PDUs in the set, the WTRU (e.g., Tx PDCP) may discard the set of PDUs.

[0092] In Example 1(B), polling may be used in RLC (e.g., a polling indicator may be sent via the RLC layer). The WTRU may be configured to trigger a status report regarding the successful reception of a PDU set by introducing RLC polling specific to the PDU set (e.g., based on information related to the PDU set or PDU dependencies, e.g., dependencies between PDUs in a PDU set or between different PDU sets), in contrast to some examples where RLC polling is based only on the number of PDUs and / or bytes sent (e.g., without information about the PDU set or PDU dependencies). The WTRU (e.g., Tx RLC) may receive configuration information from the network indicating configurations related to polling. For example, the configuration information may indicate one or more of the following: polling on a PDU set basis, a PDU set severity threshold (e.g., T1), or a PSDB threshold (D1) that can be used to trigger polling. The WTRU may receive data in the PDU set from a higher layer (e.g., the application layer). A WTRU may receive or derive the size of a PDU set (e.g., the # of the PDUs in the PDU set, the start / end of the PDU set, etc.). A WTRU may receive or derive the importance of a PDU set (e.g., based on the priority associated with the PDU set). A WTRU may send an indication to the network showing the size of the PDU set. A WTRU may send a polling indicator (e.g., a polling bit / flag) to the network based on the importance of the PDU set and / or other information. For example, if the importance of a PDU set is greater than the importance threshold T1 and the PSDB is less than the PSDB threshold D1, a WTRU (e.g., a transmitting RLC) may send a polling bit / flag to the network. If a WTRU receives a status report confirming the successful delivery of a PDU set, a WTRU (e.g., a Tx RLC) may discard the PDU set.

[0093] One or more examples described herein may facilitate (e.g., ensure) that discarding occurs in the PDCP (e.g., at the PDCP layer). The PDCP (e.g., the PDCP entity and / or the WTRU through the PDCP layer) may be configured to, for example, delay sending one or more PDUs from a PDU set (e.g., to lower layers) for a given amount of time or until a certain number or percentage of PDUs in the PDU set have been received, and / or delay sending an indication of the buffer status (e.g., transmit buffer status) for the PDU set (contrary to some examples where it is not specified whether the PDCP performs retention / preprocessing). For example, the WTRU (e.g., Tx PDCP) may receive data in the PDU set from, for example, a higher layer (e.g., the application layer). The WTRU may receive configuration information from the network indicating configurations related to retention mechanisms. For example, configuration information may indicate a threshold T1 (for example, for a holding mechanism) corresponding to the percentage of PDUs in a PDU set that should be received before the WTRU can send the PDU set (e.g., the percentage of PDUs that need to be received at the PDCP before the WTRU can send the PDU set to a lower layer). The WTRU may detect the presence or absence of PSIHI indicators associated with the PDU set (e.g., in the header of the PDU set). The WTRU may receive or derive information about the size S1 of the PDU set (e.g., start / end indicators, number of PDUs in the PDU set, size in bits / bytes, etc.). The WTRU (e.g., Tx PDCP) may determine the percentage (X1) of PDUs in the PDU set that is currently being received. If the WTRU detects the presence of a PSIHI indicator associated with a PDU set, and the proportion of PDUs in the PDU set being received at that time (X1) is less than or equal to the threshold T1, the WTRU (e.g., Tx PDCP) may hold the PDUs until more PDUs in the PDU set are received (e.g., the proportion of PDUs in the PDU set being received is greater than the threshold T1).A WTRU (e.g., Tx PDCP) may generate a control PDU (e.g., a PDU containing control information) which may include information about the retention scheme, such as the number of PDUs in the retained PDU set, the duration of the retention, the number of remaining PDUs in the PDU set, or the number of remaining PDUs in the PDU set before the WTRU can release the retention (e.g., the retention mechanism). The WTRU (e.g., Tx PDCP) may send the control PDU to the network (e.g., Rx PDCP in gNodeB (gNB)).

[0094] One or more examples described herein may facilitate (e.g., ensure that discards occur in the RLC). The RLC (e.g., an RLC entity and / or a WTRU through the RLC layer) may be configured to send a set of PDUs associated with a PSIHI indicator when the RLC receives an indication of sufficient authorization availability (e.g., the RLC sends a set of PDUs associated with a PSIHI indicator to a lower layer only when the RLC receives that indication from the lower layer), in contrast to some examples where a status PDU may only be generated by the receiver of the RLC entity, which has information about successfully received PDUs and PDUs detected as lost by the receiver, as described in the examples shown in Table 4. For example, a WTRU (e.g., Tx RLC) may receive data associated with a set of PDUs from a higher layer (e.g., an application layer). A WTRU (e.g., Tx RLC) may detect the presence / absence of a PSIHI indicator associated with a set of PDUs. The WTRU may receive or derive information about the size S1 of the PDU set (e.g., start / end indicators, number of PDUs in the PDU set, size in bits / bytes, etc.). The WTRU may receive indicators (e.g., from lower layers such as MAC) about the availability of one or more authorizations and their respective sizes (e.g., the size of two or more authorizations for a configured authorization (CG), the size of a dynamic authorization (DG), the size of a (CG+DG) authorization). If the sum (of available authorizations) is greater than or equal to the size S1 of the PDU set, the WTRU (e.g., Tx RLC) may transmit data (e.g., to lower layers such as MAC). If the sum (of available authorizations) is less than S1 and the WTRU detects a PSIHI indicator associated with the PDU set (e.g., a PSIHI indicator in the PDU set), the WTRU may hold the data in the WTRU buffer (e.g., RLC buffer).If a WTRU holds data in a WTRU buffer (e.g., a new WTRU buffer such as a new RLC buffer distinct from the legacy WTRU buffer, which may be an additional buffer to the legacy RLC buffer used to hold data such as PDUs in a PDU set), and the WTRU has not received sufficient resources from one or more authorizations, and the PSDB is within a pre-configured window for expiration, the WTRU may trigger the sending of a Scheduling Request (SR) / Buffer Status Report (BSR). If a WTRU holds data in a WTRU buffer (e.g., a legacy WTRU buffer such as the legacy RLC buffer), and the WTRU has not received sufficient resources from one or more authorizations, and the WTRU has received new data in the meantime, the WTRU may send the data (e.g., to a lower layer) when the WTRU buffer (e.g., the RLC buffer) is filled. In some examples, if a WTRU holds data in a WTRU buffer (e.g., a legacy WTRU buffer such as a legacy RLC buffer), and the WTRU has not received sufficient resources from one or more authorizations, and the WTRU receives new data in the meantime, the WTRU may decide what to do based on the priority of the new data (e.g., the priority of the new data relative to the priority of the PSIHI data). For example, if the priority of the new data is higher than the priority of the PDU set associated with the PSIHI indicator, the WTRU may send the new data (e.g., to a lower layer such as a MAC). If the priority of the new data is less than or equal to the priority of the PDU set associated with the PSIHI indicator, the WTRU may send the PDU set associated with the PSIHI indicator (e.g., to the first available authorization regardless of authorization size). The WTRU (e.g., Tx RLC) may generate a status PDU to inform the network (e.g., Rx RLC) about the retention scheme in the WTRU, including information about the amount of additional authorizations required to release the retention mechanism.In some examples, a WTRU (e.g., Tx RLC) may send an indication (e.g., to a lower layer such as a MAC), and a WTRU (e.g., MAC) may send an indication (e.g., MAC control element (CE)) to the network to inform the network about the retention scheme in the WTRU, including information about the amount of additional authorization required to release the retention. In one or more examples described herein, the sender may perform a status report, which may consist of a PDU set basis and / or include information about how much additional authorization is required to release the retention (contrary to some examples where a status PDU containing information about successfully received PDUs and PDUs detected as lost by the receiver may be generated only by the receiver of the RLC entity).

[0095] [Table 4]

[0096] One or more examples described herein may facilitate discarding at the Rx-side PDCP (e.g., ensuring that discarding occurs at the Rx-side PDCP on the downlink). The receiving PDCP may be configured to drop PDUs from a set of PDUs related to the PSIHI indicator if some PDUs in the set of PDUs are lost / delayed (contrary to some examples where the receiving PDCP forwards all PDUs to the application layer, for example). The WTRU (e.g., Rx PDCP) may receive data related to a set of PDUs (e.g., from lower layers). The WTRU may receive indications (e.g., from higher layers (e.g., application layer)) of data in the QoS flow that should be treated as PSIHI data (e.g., data that needs to be treated as PSIHI data based on the encoding scheme in the application in the WTRU). For example, some data may not be marked as PSIHI type data by the network. The WTRU may receive data in the DL. Data (e.g., data not initially marked as PSIHI) should be treated as PSIHI data based on the encoding scheme in the WTRU, for example. A WTRU (e.g., Rx PDCP) may detect the loss / delay of some PDUs in a PDU set (e.g., a PDU set currently marked as PSIHI) based on the SNs of the PDUs in the PDU set. The WTRU may send an indication to the network regarding changes in the status of the PDU set. In the example, if the PSDB is reached, the WTRU may discard the other PDUs in the PDU set.

[0097] In one or more examples herein, the network may include, for example, base stations (e.g., gNBs, transmit / receive points (TRPs), RAN nodes, access nodes), core network functions (e.g., AMFs, SMFs, PCFs, NEFs), and application functions (e.g., edge server functions, remote server functions).

[0098] In one or more examples herein, a flow may correspond to either a QoS flow or a data flow (e.g., a data flow consisting of one or more PDUs, PDU sets, or data bursts that may be associated with one or more QoS requirements, e.g., latency, data rate, reliability, or RTT latency). Different flows that in some cases originate from a common application / experience source and / or target a common destination device / WTRU or group of associated devices / WTRUs may be called related flows or correlated flows.

[0099] In one or more examples herein, a data unit may refer to one or more frames (e.g., media / video / audio frames or slices / segments), PDUs, PDU sets, data bursts, or groups of frames / PDUs / PDU sets / data bursts.

[0100] In one or more examples herein, QoE may correspond to any of the application and / or higher-layer metrics and measurements that may be directly or indirectly detectable / visible in the WTRU and / or application functionality. Such QoE metrics and measurements may or may not be directly visible / detectable at, for example, the base station. Such QoE metrics and measurements may be determined / implemented depending on the QoS metrics / parameters (e.g., latency, data rate, reliability, RTT / MTP latency).

[0101] In one or more examples herein, a forwarding configuration may correspond to any of the following: radio bearers (e.g., data radio bearers (DRBs) and / or signaling radio bearers (SRBs), logical channels (LCHs), logical channel groups (LCGs), configuration parameters in individual layers within the AS protocol stack (e.g., SDAP, PDCP, RLC, MAC, physical layer (PHY), other newer protocol layers), parameters related to logical channel prioritization (LCP) (e.g., priority, priority bitrate (PBR), BSD), bandwidth portions (BWPs), carriers, radio links / interfaces (Uu links, SLs), and radio resources (e.g., a set of one or more frequency / time / spatial resources such as symbols, slots, subcarriers, resource elements, or beams). Radio resources may be associated with configured grants (CGs), dynamic grants (DGs), and / or any other resource grants or grant-free resources.

[0102] In one or more examples herein, the mapping configuration may correspond to any of the parameters and / or configurations related to the mapping from one or more of the following: data units, PDUs, SDUs, PDU sets, data bursts, application data (e.g., ADU) flows, (e.g., related or unrelated) QoS flows, or data units, PDUs, SDUs, PDU sets, data bursts, application data (e.g., ADU) flows, or (e.g., related or unrelated) QoS flows, which can originate from one or more of the following: application layers, upper layers, and networks, which can be used to deliver data / PDUs in the UL direction or DL ​​direction: wireless bearers (e.g., DRB, SRB), layers, sublayers or entities (e.g., SDAP, new layer, PDCP, RLC, MAC, PHY), LCHs, carriers or component carriers (e.g., CC in a CA configuration), BWPs, and wireless links / interfaces (e.g., Uu links or side links).

[0103] In one or more examples herein, a data unit may correspond to one or more frames (e.g., media / video / audio frames or slices / segments), PDUs, PDU sets, data bursts, or groups of frames / PDUs / PDU sets / data bursts.

[0104] In one or more examples herein, XR / application-aware data transmission or XR / application-aware QoS processing may correspond to any of the following: PDU sets, attributes associated with ADUs or data bursts, application / higher layer importance / priority, or QoS / data flow.

[0105] XR / application-aware data transmission or XR / application-aware QoS processing may include attributes related to PDU sets, ADUs, or data bursts. A PDU set (e.g., media unit, video frame) may comprise one or more PDUs. A PDU set may be associated with PDU set-level QoS requirements (e.g., data rate, latency, error rate, reliability) that may be applicable to one, more, or all PDUs associated with the PDU set. Different PDUs within a PDU set may be associated with individual PDU-level QoS requirements. A data burst may refer to data generated by an application during a short time period comprising PDUs from one or more PDU sets. Such attributes, associations, and interdependencies (e.g., intraPDU sets and / or interPDU sets) including the start / end indicators of PDU sets / data bursts (via sequence numbers, start / end indicators), start / end times, duration, payload size, period, severity / priority, and QoS (e.g., PSDB) are visible to the AS layer (e.g., with associated IDs) and / or can be handled by the AS layer with recognition of the associations during data transmission in UL and reception in DL.

[0106] XR / application-aware data transmission and reception or XR / application-aware QoS processing may include application / higher-layer importance / priority. Different PDUs in a PDU set or all PDUs in a PDU set may be associated with different application / higher-layer importance / priority values. Such importance values ​​may correspond to spatial importance (e.g., the spatial location of the video frame carrying data by the PDU / PDU set, where a PDU / PDU set carrying FoV spatial location may be associated with a higher spatial importance than a non-FoV spatial location) or temporal importance (e.g., the temporal sequence of video frames carrying data by the PDU / PDU set, where a PDU / PDU set carrying base video frames such as I-frames may be associated with a higher temporal importance than differential video frames such as P-frames / B-frames). Such importance values ​​may be visible to the AS layer (e.g., with associated IDs / markers / indications) during data transmission and reception, depending on the application awareness.

[0107] XR / application-aware data transmission or XR / application-aware QoS processing may include QoS / data flows. An application's PDU / PDU set may be encoded by the application and delivered to a WTRU (in UL) or network (in DL) via one or more QoS / data flows. In this regard, different QoS flows carrying PDU / PDU sets associated with an XR application / experience may be visible to the AS layer (e.g., with associated IDs) and / or handled at the AS layer with association awareness during data transmission and reception.

[0108] In one or more examples herein, WTRU actions relating to application actions and / or AS layer actions to guarantee / support differentiated QoS may, in some cases, correspond to any of the following: determining metadata for an application (e.g., an XR application), determining / generating application content, measuring and reporting; processing / transferring data / PDU / PDU sets and handling QoS associated with PDU / PDU sets; or processing / transferring information relating to connectivity with networks and / or other WTRUs.

[0109] In some cases, WTRU actions related to application actions and / or AS layer actions to guarantee / support differentiated QoS may include determining metadata for an application (e.g., an XR application). For example, determining metadata may involve determining any of the FoV / visual / spatial perimeter, 2D / 3D size, boundary, spatial attributes, and borders of the FoV based on measurements in any spatial dimension including longitude, latitude, altitude, depth, roll, pitch, and yaw in one or more coordinate systems (e.g., orthogonal, spherical), but is not limited to this. For example, determining metadata may involve determining the quality of the FoV content, e.g., whether the FoV content is of high quality (which, in the case of an image, can be quantified and assessed by the image resolution (e.g., the number of megapixel densities)). For example, determining metadata may involve determining the importance and / or priority of the FoV content. Importance may be related to, for example, the spatial importance and / or temporal importance of the content / data. For example, spatial / temporal importance values ​​may indicate the absolute or relative importance of FoV content. Spatial importance may, for example, be associated with one or more segments / tiles / slices / locations of the FoV in the spatial dimension. Temporal importance may, for example, be associated with one or more frames / subframes of the FoV in the temporal dimension.

[0110] In some cases, WTRU actions related to application actions and / or AS layer actions to guarantee / support differentiated QoS may include determining / generating application content. For example, determining application content may involve determining / capturing one or more 2D / 3D image / video frames related to the FoV boundary / perimeter / boundary defined by FoV metadata by the WTRU / node, for itself and / or on behalf of another WTRU / node. For FoV content mapping, the WTRU may determine the image / video frames using visual sensors (e.g., 2D / 3D cameras, LIDAR), RF sensors (e.g., RF transceivers, RADAR), audio sensors (e.g., sonar), etc. In this specification, FoV mapping may also be referred to as FoV content detection or FoV content capture. For example, determining application content may also include recording / capturing audio frames as part of a soundtrack / audio file, or as part of an overlaid soundtrack / audio file, originating from an audio file originating from a source other than the current real environment being mapped.

[0111] In some cases, WTRU actions related to application actions and / or AS layer actions to ensure / support differentiated QoS may include performing measurements and reporting. For example, a WTRU may perform measurements such as the location / space / orientation (e.g., 6DoD / 3DoD orientation, location / position), and rate of movement / movement of the user / WTRU and / or other objects (e.g., virtual or real) with which the user may interact. A WTRU may send / report orientation measurements to the network periodically or when it detects an event trigger (e.g., a change in orientation measurement above / below a threshold). For example, a WTRU may perform measurements of one or more of the following: reference signals or channels (e.g., Synchronization Signal Block (SSB), Channel Status Information-Reference Signal (CSI-RS), Positioning Reference Signal (PRS), Sidelink Reference Signal (Sidelink RS), Global Navigation Satellite System (GNSS) signals, Unauthorized Carrier, Ultra-Wideband signals, Lider signals, Visual signals, etc.). In another example, a WTRU may perform measurements of the radio link interface associated with the WTRU (e.g., Uu-link, SL). A WTRU may trigger the transmission and / or measurement of reference signals in, for example, one or more other WTRUs (e.g., via Uu-link and / or sidelinks). A WTRU may send measurement reports to the network and / or other WTRUs.

[0112] In some cases, WTRU actions related to application actions and / or AS layer actions to guarantee / support differentiated QoS may include processing / transferring data / PDUs / PDU sets and handling QoS associated with PDUs / PDU sets. For example, data may include media / image / video frames, sensor data, and measurement data (e.g., attitude measurements, link / channel measurements) determined by the WTRU to support application / service / network requests associated with the WTRU. For example, a WTRU may send and receive data to and from one or more destinations, including RAN nodes (e.g., gNBs), CN functions / entities, and application functions (e.g., hosted in the WTRU or in the network). For example, a WTRU may perform splitting / merging of data / PDUs in one or more QoS flows into one or more transport configurations during transmission and reception.

[0113] In some cases, WTRU actions related to application actions and / or AS layer actions to guarantee / support differentiated QoS may include processing / transferring information related to connectivity with the network and / or other WTRUs. A WTRU may send capability information to the network, including, for example, the ability to support one or more traffic flows with different XR traffic patterns (e.g., periodic / aperiodic, PDU sets with variable payload sizes), the ability to perform application layer measurements (e.g., QoE measurements, application buffer measurements, RTT measurements), and the ability to detect changes to traffic patterns. A WTRU may send interWTRU cooperation capability information to the network, including, for example, the ability to support one or more interfaces that may or may not be co-located with the WTRU, and the ability to cooperate and / or interact with other WTRUs / devices (e.g., via SL interfaces). A WTRU may receive configurations, including receiving radio resource control (RRC) configurations from gNBs and / or NAS layer configurations from CNs. A WTRU may send and receive support data related to traffic, QoS, scheduling, etc., to and from the network to support UL / DL transmissions. WTRUs can send requests for radio resources and / or resource authorization (e.g., dynamic authorization, semi-static / configured authorization).

[0114] One or more of the features or components of the information relating to XR traffic, information relating to traffic characteristics, WTRUs that receive configuration information from the network, congestion, WTRUs that detect flags for PDU set processing (e.g., PSIHI) or identify data types, one or more PDCP discard timers or multiple PDCP discard timers, WTRU discard behavior based on discardTimer, and WTRU discard behavior based on factors other than the expiration of data unit discard timers (e.g., discard timers for dependent data units, data types, etc.) described herein may be applicable to one or more examples.

[0115] Information regarding XR traffic may include one or more of the following: Information regarding XR traffic may include association information (e.g., information about dependencies). Dependencies may refer to either intra-PDU set dependencies (e.g., dependencies between different PDUs in a PDU set) or inter-PDU set dependencies (e.g., dependencies between multiple PDU sets). Dependencies may refer to dependencies between different PDU sets during a data burst (e.g., different PDU sets received within a short time window).

[0116] Dependencies may be determined by the WTRU based on one or more of the following: severity markings (e.g., severity markings added to the Application or Service Data Adaptive Protocol (SDAP) or new layers above / below the SDAP), SN markings (e.g., SN markings added to the Application or SDAP or new layers above / below the SDAP), arrival time, data type, QoS flow, or explicit indications from higher / application layers, or may be known / communicated to the WTRU.

[0117] Dependencies may be determined by the WTRU based on importance markings, or may be known / communicated to the WTRU. Importance markings may be added, for example, to an application or an SDAP or a new layer above / below the SDAP. For example, importance markings may be added to data units (e.g., in the header of each PDU set) or sent as metadata (e.g., via separate signaling). Lower layers may be able to read the importance markings and infer (e.g., any) dependencies from them.

[0118] Dependencies may be determined by the WTRU based on SN markings, or may be known / communicated to the WTRU. Sequence number (SN) markings may be added, for example, to an application or an SDAP or a new layer above / below the SDAP. SN markings may be added to data units (e.g., in the header of each PDU set) or sent as metadata (e.g., via separate signaling). Lower layers may be able to read the SN markings and infer dependencies (e.g., any) from the importance markings. For example, PDUs 1, 2, and 3 in PDU set 1 may be marked as [1,1], [1,2], and [1,3], and PDUs 1 and 2 in PDU set 2 may be marked as [2,1] and [2,2].

[0119] Dependencies can be determined by the WTRU based on arrival time, or they can be known / communicated to the WTRU. Arrival time can be used based on time retention (e.g., time retention based on a time criterion (e.g., SFN) in SDAP / PDCP) or time window (e.g., start / end time). For example, a lower layer might assume a dependency between two data units (e.g., two sets of PDUs) arriving within each other's time window.

[0120] Dependencies can be determined by the WTRU based on the data type, or they can be known / communicated to the WTRU. For example, if the data type associated with a subsequent frame is the same as the data type associated with one or more frames in the first frame, then the subsequent frame may depend on one or more frames in the first frame (e.g., the second frame depends on the first frame). For example, if the data type associated with a first frame type is the same as the data type associated with a second frame type, then the first frame type may depend on the second frame type. For example, a dependent / differential frame (e.g., a P / B frame) may depend on an I frame. In the example, one PDU set type I has a higher dependency among the constituent PDUs in the PDU set (for example, because, by definition, a PDU set type I cannot tolerate the loss / delay of any PDU in the PDU set, compared to a PDU set type II which can tolerate the loss / delay of one or more PDUs in the PDU set).

[0121] Dependencies can be determined by the WTRU based on the QoS flow, or they can be known / communicated to the WTRU. For example, a WTRU may determine that multiple (e.g., two) sets of PDUs arriving in the same QoS flow are dependent on each other.

[0122] Dependencies can be determined by the WTRU based on explicit indications from higher / application layers, or they can be known / communicated to the WTRU. For example, a higher / application layer may explicitly mark two data units that depend on each other, since an application may require both data units at the other end. For example, an application may mark PDU Set 1 and PDU Set 3 as dependent on each other (e.g., via in-band marking of PDU Set 1 and PDU Set 3 or via separate signaling indicating a dependency between PDU Set 1 and PDU Set 3), and so a lower layer in the WTRU (e.g., the AS layer) can handle PDU Set 1 and PDU Set 3 in a way that preserves the dependency. In the example, a higher / application layer may give an application layer packet. The packet may be considered a PDU. An application layer packet may be an RTP packet. The packet may contain a header describing the PDU. There may be a field in the header indicating the packet's priority (e.g., importance) relative to other packets in the same stream. The WTRU may determine that packets with the same priority value in the header depend on each other. There may be a field in the header indicating a sequence number. The WTRU may determine that PDU sets associated with consecutive sequence numbers are related to each other (for example, the PDU set associated with sequence number 4 is related to the PDU set associated with sequence number 5). There may be a field in the header indicating dependency. For example, dependency indications may be called correlation IDs, and PDU sets that have correlation IDs in their headers may be considered dependent on each other. In some examples, the WTRU may receive PDU set processing rules in a NAS message. PDU set processing rules may be received as part of a QoS rule. PDU set processing rules may indicate correlation ID values ​​that should be considered related to each other. For example, a PDU set processing rule may indicate that correlation ID values ​​5 and 3 are related. The WTRU may then determine that any packets with correlation IDs of 3 or 5 in their headers are related to each other.

[0123] Dependencies may be determined by or known / communicated to the WTRU based on one or more of the examples herein. For example, the WTRU may determine that multiple (e.g., two) sets of PDUs of the same importance, sent consecutively (or within a short specified time window between them), depend on each other. The WTRU may determine that multiple (e.g., two) sets of PDUs of the same type, with arrival times within short time windows between them, depend on each other.

[0124] A WTRU may send information (e.g., to the network) or receive information (e.g., from a higher layer (e.g., the application layer) or from the network), or determine information about traffic characteristics. Information about traffic characteristics may include one or more of the following: the size of the PDU set, the number of PDUs per PDU set, and the number of PDUs in a data burst in one or more traffic flows. Information about traffic characteristics may include instantaneous measurement / determination and / or statistical / distribution information such as mean, minimum, maximum, and standard deviation. Information about traffic characteristics may include information about PDU sets. Information about PDU sets may include the size of the PDU set (e.g., total payload, number of PDUs in the PDU set), the representation of the first / first and / or last / end PDU in the PDU set, and the representation of the association / dependencies of the PDUs in the PDU set (e.g., PDU set ID, importance / priority value).

[0125] Information regarding traffic characteristics can be obtained. For example, a WTRU may receive or derive information from an upper layer (e.g., the application layer) regarding the importance of the data it receives from the upper / application layer. A WTRU may receive PDU sets with an indication (e.g., marking / flag) that they are "important" PDU sets. For example, "1" indicates importance, and "0" indicates unimportant. There may be different levels / granularity for defining importance. A WTRU may receive information from an upper / application layer regarding how important a PDU set is. For example, "11" indicates very important, "10" indicates average importance, "01" indicates low importance, and "00" indicates unimportant. There may be further granularity for definition. A WTRU may, for example, read importance values ​​in the header of a PDU set. A WTRU may receive a separate PDU (e.g., a control PDU) that gives information about the importance of several PDU sets. For WTRU traffic, a WTRU may send information about the importance of PDU sets to the network. In the example, the WTRU might receive information (e.g., from an XR application) about the number of PDUs in a PDU set and the appearance of the first PDU in the PDU set. Based on some of this information, the WTRU might determine the size of the PDU set and the last PDU in the PDU set. In the example, the WTRU might have received PDUs 1, 2, and 3 from the PDU set. Based on the information about the size of the PDU set (e.g., by the total number of PDUs in the PDU set), the WTRU might determine that PDUs 4, 5, and 6 of the PDU set are still pending and should be received soon (e.g., ideally within a time window that would allow the WTRU to send all PDUs in the PDU set into the PSDB).In the example, a WTRU may send to or receive from the NW / application / upper layer information about PDU sets and / or data bursts in one or more data / QoS flows, including the number of PDUs or PDU sets (e.g., instantaneous, average, maximum, minimum), the payload size of PDU sets and / or data bursts in bits / bytes (e.g., instantaneous, average, maximum, minimum), the period, importance / priority, start and end indications of PDU sets and / or data bursts (e.g., ID of the first PDU / PDU set, ID of the last PDU / PDU set), and one or more dependency information across multiple PDU sets and / or data bursts within a PDU set (e.g., whether multiple PDU sets depend on each other and / or whether PDU sets in one or more data bursts depend on each other and / or whether PDUs within a PDU set depend on each other). In the example, a WTRU may send jitter information in the UL and / or DL. Such jitter information, which may be sent per flow, per PDU set, or per PDU, may include, for example, one or more of the range, average, maximum, and minimum values. In the example, the WTRU may send information about the importance / priority of any of the data units (e.g., PDUs, PDU sets, data bursts) to be sent and received in the UL / DL. In the example, the WTRU may receive indications (e.g., from the NW or higher / application layer) about changes in traffic pattern characteristics and / or send indications when it detects changes in the UL / DL traffic pattern (e.g., changes in payload size, PDU set size, data burst size, jitter range, period, etc.).In the example, a WTRU may send configuration to the network via one or more of the following: RRC signaling and / or NAS messages (e.g., SRB0, SRB1, SRB2, SRB3, SRB4), control PDUs related to any of the AS layers (e.g., SDAP control PDU, PDCP control PDU), UL MAC CEs (e.g., Existing MAC CE, New MAC CE, Normal BSR, Periodic BSR, Extended BSR, Padding BSR, Preemptive BSR, etc.), UCIs (e.g., Single-bit SR, Multi-bit SR, Feedback, Acknowledgment (ACK) / Negative ACK (NACK), CSI Report), PUCCH, PUSCH, Non-AS (NAS) layer signaling (e.g., PDU session-related messages), or application layer signaling / messages.

[0126] A WTRU may receive configuration information from the network. A WTRU may receive a set of DRBs configured by the base station (e.g., DRB1, priority of DRB1, DRB2, priority of DRB2) from the base station (e.g., from the gNB and in the RRC). A WTRU may receive rules / restrictions from the base station (e.g., the gNB) for mapping DRBs to LCHs and / or mapping DRBs and / or LCHs to resource permissions (e.g., CG). A WTRU may receive a set of LCHs from the base station (e.g., the gNB in ​​the RRC) that can be configured so that some LCHs handle dependencies. LCH parameters (e.g., BSD, PBR, priority) may be applied to all or some of the data units mapped to the LCH (e.g., PDUs and / or PDU sets and / or data bursts). The WTRU may receive from the base station (e.g., gNB) the LCP configuration and / or changes to the LCP configuration (e.g., LCP restrictions / rules / configurations for handling PDUs / PDU sets / data bursts) for a certain duration, indefinitely, or until further notice (e.g., changes in LCP configuration). The WTRU may receive indications from the base station (e.g., gNB) whether these LCP rules may be temporarily relaxed / modified during the duration or whether they may be applicable (e.g., always applicable). The WTRU may receive configurations from the gNB for multiplexing PDUs / PDU sets / data bursts into transport blocks. A WTRU may receive configuration from the network via one or more of the following: RRC signaling and / or messages (e.g., dedicated / unicast signaling via SRB, broadcast / SIB), control PDUs associated with one or more AS layers (e.g., SDAP control PDU, PDCP control PDU), DL MAC CE, downlink control information (DCI), PDCCH, PUSCH, non-AS (NAS) layer signaling (e.g., PDU Session Establishment Response or PDU Session Modification Command), or application layer signaling / messages.

[0127] Congestion can be detected. In some cases, one or more of the examples (e.g., extensions to discarding mechanisms) may apply to (e.g., only apply to) the cases in which congestion is detected. Congestion may be detected at a WTRU and / or base station (e.g., gNB) based on one or more of the following: throughput, block error rate (BLER), hybrid automatic retransmission request (HARQ) ACK / NACK, ARQ ACK / NACK, status reports / feedback / acknowledgments or lack thereof at any layer in the protocol stack indicating successful and / or failed deliveries, acknowledgments of reception or lack thereof at any layer in the protocol stack, the time of traffic reception, etc. For example, the time of traffic arrival at a WTRU later than the expected arrival time may indicate congestion. A large number of HARQ NACKs within a pre-configured window (e.g., the number of HARQ NACKs is greater than a threshold) may constitute a trigger for congestion detection at a WTRU. A small number of status reports confirming successful deliveries at the receiver (e.g., the number of status reports is less than a threshold) may constitute a trigger for congestion detection at a WTRU. WTRUs may receive indications from networks and / or applications that the presence of congestion is present.

[0128] In one or more examples herein, PDU set 1 may refer to one or more PDU sets having similar PDU set level QoS requirements (e.g., the same or similar PSDB1, PSER1, PSII representations, etc.). PDU set 2 may refer to one or more PDU sets having similar PDU set level QoS requirements (e.g., the same or similar PSDB2, PSER2, PSII representations, etc.). In one or more examples herein, PDCP may refer to a packet data convergence protocol entity / layer in a WTRU (or any new entity / layer in a WTRU that performs the task of sending / discarding data units). It can be assumed that a base station (e.g., gNB) may have a similar / corresponding entity / layer.

[0129] A WTRU may detect an indication (e.g., a flag) (e.g., PSIHI) for PDU set processing and / or identify a data type. Based on the SA2 definition of a PDU set, a PDU set may be used for processing and delivering groups of PDUs belonging to the PDU set. Some PDU sets may tolerate some degree of loss and / or delay of one or more PDUs in the PDU set (e.g., an XR application can still reconstruct a PDU set with delay / loss of one or more PDUs in the PDU set). Such PDU sets are referred to as Type II PDU sets in one or more examples herein. Some PDU sets (e.g., referred to as Type I PDU sets in one or more examples herein) may not tolerate any loss / delay of PDUs in the PDU set (e.g., they cannot), for example, an XR application cannot tolerate any delay / loss of any PDU in the PDU set, and therefore, if there is some delay / loss of any PDU in the PDU set, the remaining PDUs in the PDU set may be dropped. Such PDU sets are referred to as PSIHI PDU sets or PDU sets with PSIHI indicators in one or more examples herein.

[0130] In the example, it is determined by the XR application whether a reconfiguration of a PDU set with some loss / delay can occur. This could be an XR application marking the PDU set as Type I or Type II. The marking can be done at the NAS layer or at the AS layer (e.g., SDAP). This information can be communicated / relayed down to lower layers, so that lower layers (e.g., PDCP) can adapt the processing of the PDU set (e.g., discard) accordingly. One or more of the following can occur: In the example, the information (e.g., marking) can be added to (e.g., each) PDU set (e.g., as a marking in the header of each PDU set), and lower layers (e.g., PDCP) in the WTRU may be able to read it. In the example, information may be added to a PDU set, and the lower layer may assume that similar information is applied to subsequent PDU sets (e.g., all) until a PDU set with a different marking arrives at the lower layer (e.g., all subsequent PDU sets without markings are of the same type as the one PDU set with a marking). In the example, the type of the PDU set and the number of subsequent PDU sets of the same type (e.g., N) may be marked in the header of the first PDU set. When the lower layer receives / reads the header of this first PDU set, it may perform similar processing on the N subsequent PDU sets without taking the time to read the headers of the N subsequent PDU sets, for example. In the example, this information may be sent separately to the lower layer as metadata in the WTRU. In the example, one type of PDU set may carry a flag (e.g., a 1-bit flag) to identify its type. For example, only a set of Type I PDUs may carry a flag indicating that the XR application cannot tolerate any loss / delay of any PDU in the set. In the example, the first set of Type I PDUs may carry a flag indicating its type. A lower layer may assume that subsequent sets of PDUs are also Type I. In the example, a set of PDUs of a certain severity may be assumed to be of a certain type by the WTRU.For example, a WTRU might assume that any PDU set with an importance value greater than a certain preset value (e.g., greater than 8 on an importance scale of 1 to 10 where 10 is the most important) is a Type I PDU set (and therefore, no loss / delay of any PDU in the PDU set is to be tolerated). The importance of a PDU set can be determined by the XR application and communicated to the WTRU in-band (e.g., in the PDU set header) or through separate signaling (e.g., metadata signaling). In the example, the application might define new parameters for the use of PDU sets in the application. These new parameters could be, for example, PDU set QoS parameters that indicate preferred handling of the PDU set at lower layers, or PSII (PDU set unified display) indicating whether all PDUs are needed for use of the PDU set in the application. Parameters can be binary (e.g., whether all PDUs are needed without any loss / delay) or finer granular (e.g., a certain number / percentage of PDUs in the PDU set are needed for PDU set reconfiguration in the application). Parameters may be signaled to lower layers via markings on the PDU set (e.g., inband markings in the header) or via separate signaling (e.g., dedicated signaling for metadata on the PDU set).

[0131] One or more PDCP discard timers may be used. In some PDCP frameworks (e.g., legacy PDCP frameworks), there may be one discard timer associated with each PDCP SDU. When the discardTimer for a PDCP SDU expires or successful delivery of the PDCP SDU is confirmed by a PDCP status report, the sending PDCP entity discards the PDCP SDU along with the corresponding PDCP data PDU. In a state where XR traffic includes one or more PDUs in a PDU set and one or more PDU sets in a data burst, with dependencies between configuration PDUs in a PDU set or configuration PDU sets in a data burst, one or more of the following examples may be considered when configuring PDCP discard timers. In the example, there may be one PDCP discardTimer operating per PDCP SDU, as in some PDCP frameworks, where timer expiration takes into account the PDU delay budget (PDB) of the individual PDUs. This configuration may imply multiple PDCP discardTimers per PDU set. In the example, there might be one PDCP discardTimer operating per PDCP SDU, as in some PDCP framework, but in this configuration, the expiration of the configuration timers for a set of PDUs takes into account the PSDB of the PDU set (e.g., each configuration timer for each PDU set takes into account the PSDB of the PDU set, not the PDB of the individual PDUs). This configuration could imply multiple PDCP discardTimers per PDU set (e.g., all having expiration times corresponding to the PSDB of the PDU set). In the example, there might be one PDCP discardTimer operating per PDCP SDU, as in some PDCP framework, but in this configuration, if the PDUs in a set do not all arrive at the WTRU at the same time, PDCP discard timers of different lengths (e.g., taking PSDBs into account) are applied to the SDUs of the same PDU set to expire simultaneously (e.g., all expiring at the same time).For example, the first batch of PDUs in a PDU set (e.g., arriving at time t1) may have a larger discardTimer expiration time value compared to the second batch of PDUs in the PDU set (e.g., arriving at t2, where t2 is greater than t1). In the example, there may be one PDCP discardTimer that operates per PDU set, taking into account the PSDB of the PDU set. In the example, more than one configuration may be possible. For example, a base station (e.g., gNB) may configure whether the PDCP discardTimer operates per PDCP SDU or per PDCP PDU set. WTRU may determine, for example, which option to use based on whether all PDCP SDUs belonging to a PDU set arrive simultaneously or staggered (e.g., a PDCP discardTimer that operates per PDCP SDU or per PDCP PDU set) and / or how to configure the expiration timer value (e.g., based on the PDB of individual PDUs, or based on the PSDB of the PDU set, or based on the PSDB of the PDU set with increments / decrements based on arrival times in the WTRU). In one or more examples herein, the PDCP discardTimer of an XR data unit may be used to describe a discard timer per PDCP SDU or per PDU set according to one or more of the options described above.

[0132] WTRU discard behavior can be based on discardTimers. Discard behavior in a WTRU (e.g., in the PDCP layer within a WTRU) can be PDU-based or PDU-set-based. For example, if there is one discardTimer for each PDCP SDU in a PDU set, each PDCP SDU will be discarded when its respective discardTimer expires (regardless of whether its discardTimer is based on the individual PDB of the PDU / PDCP SDU or on the PSDB of the PDU set it is a part of). If there is one discardTimer per PDU set, when the discardTimer expires, the transmitting PDCP entity (e.g., a WTRU for UL traffic) discards any PDUs in that PDU set that were not successfully transmitted. If there is a discardTimer associated with each PDCP SDU as well as a discardTimer associated with a PDU set, the WTRU may decide to prioritize the stricter of the two conditions (e.g., prioritizing the smaller of the PDB or PSDB).

[0133] WTRU discard behavior may be based on factors other than the expiration of data unit discard timers (e.g., discard timers for dependent data units, data types, etc.). Discard behavior in a WTRU (e.g., in the PDCP layer within a WTRU) may be based on, for example, the discardTimer value in addition to the data type or (e.g., some) indication from the higher / application layer regarding the appropriate handling of the XR data unit. Discard behavior may be configured in an entity (e.g., a PDCP entity) in any AS layer within a WTRU (e.g., in the PDCP layer within a WTRU) or in an entity (e.g., a new entity) in a new layer within a WTRU. An example of a new layer may be a new layer between the SDAP and PDCP layers within a WTRU, which may be common to multiple PDCP entities within a WTRU.

[0134] The WTRU discard behavior of a data unit (e.g., PDU set 1) may correlate with one or more of the following: the data unit's discard timer, the discard timers of one or more components of the data unit, the discard timers of dependent data units, the importance of PDU set 1, status reports indicating successful delivery of the XR data unit, status reports indicating successful delivery of dependent XR data units, status reports indicating successful delivery of another XR data unit on which the XR data unit depends, status reports indicating failed delivery of the XR data unit, status reports indicating failed delivery of a dependent XR data unit, and status reports indicating failed delivery of another XR data unit on which the XR data unit depends. The WTRU discard behavior of a data unit may correlate with the data unit's discard timer, which has expired or is within a pre-configured time window with a small remaining expiration time. For example, the discard timer associated with PDU set 1 has expired or is within a pre-configured time window with a small remaining expiration time. The WTRU discard behavior of a data unit may correlate with the discard timer of one or more components of the data unit, which has expired or is within a pre-configured time window with a small remaining expiration time. For example, the discard timers of one or more PDUs in PDU set 1 may be expired or within a pre-configured time window with a small remaining time. The WTRU discard behavior of a data unit may correlate with the discard timers of dependent data units that are expired or within a pre-configured time window with a small remaining time. For example, the discard timers of PDU set 2, which depends on and / or on PDU set 1, may be expired or within a pre-configured time window with a small remaining time.

[0135] The WTRU discard behavior of a data unit may correlate with the importance of PDU set 1. For example, if the importance of a PDU set exceeds a threshold, the WTRU may decide not to discard the PDU set even if the PSDB has expired (for example, because the PDU set may still be needed for decoding dependent PDU sets). For example, if the importance of a PDU set exceeds a threshold, or if the PDU set has a flag indicating it is important, the WTRU (e.g., PDCP) may be configured not to discard the PDU set even if the discardTimer corresponding to the PDU set has expired, if the WTRU has not received a status report from the network confirming the successful reception of that PDU set. For example, if the importance of a PDU set exceeds a threshold, or if the PDU set has a flag indicating it is important, the WTRU (e.g., PDCP) may be configured to scale up the length of the discardTimer for that PDU set. For example, if the importance of a PDU set = A1, a scaling factor X2 may be applied to the length of the discardTimer applied to the PDU set. If the severity of a PDU set is A2, the scaling factor X3 may be applied to the length of the discardTimer applied to the PDU set, and so on. The WTRU may receive an association from the network between the scaling factor to be applied and the severity of the PDU set. For example, if the severity of a PDU set exceeds a threshold or the PDU set has a flag indicating that it is important, the WTRU (e.g., PDCP) may be configured to extend the corresponding PDCP discardTimer and apply it to that PDU set. The WTRU has a maximum number of times it can extend the discardTimer value (e.g., for a critical PDU set of severity A1, the WTRU may only be able to extend the discardTimer value a maximum of 2 times), and a maximum buffer fill rate at which the discardTimer value can no longer be extended (e.g., for a critical PDU set of severity A1, the WTRU may only be able to extend the discardTimer value until the PDCP buffer is filled to 80%).If it is filled to more than 80%, WTRU can consist of one or more of the following (the discardTimer value can no longer be extended).

[0136] The WTRU discard behavior of a data unit may correlate with status reports indicating failed delivery of other XR data units on which the XR data unit depends. For example, if the PDCP discard timer for an XR data unit has expired or is within a small pre-configured time window of expiration, and / or the data type is PDU set type I (e.g., the application cannot rebuild a PDU set with delays / losses of any PDUs in the PDU set), the WTRU may discard the XR data unit or a copy of the XR data unit. An XR data unit can be the entire PDU set or some PDUs within a PDU set. In the example, if the PDCP discard timer for an XR data unit has expired, and / or the XR data unit is of type PDU set type I, and / or the WTRU (e.g., the sending PDCP entity in the WTRU) has received a status report from the gNB (e.g., the receiving PDCP entity in the gNB) indicating a failed delivery of the XR data unit, and / or there is a dependency between this XR data unit and another XR data unit (e.g., another PDU set mapped to a different DRB / PDCP entity), the WTRU may send an indication to one or more PDCP entities that have dependent data units to drop copies (e.g., all) of the dependent data unit. For example, the WTRU may determine a dependency between PDU set 1 and PDU set 2, and therefore PDU set 2 may be useless without PDU set 1. For example, PDU set 1 could be an I frame and PDU set 2 could be a differential P / B frame.If the PDCP discard timer for PDU set 1 has expired, and the WTRU (e.g., PDCP) has received a status report from the gNB indicating failed delivery of one or more PDUs in PDU set 1, and the data type of PDU set 1 is PDU set type I, which cannot tolerate any loss / delay of any PDU in the PDU set for the successful reconstruction of the PDU set, then the WTRU (e.g., transmitting PDCP entity 1 carrying a copy of PDU set 1) may send an indication to PDCP entity 2 (carrying a copy of PDU set 2) to drop copies of PDU set 2 and / or any PDUs in PDU set 2 (e.g., all of them).

[0137] In the example, if a dependent PDU set has already been submitted to a lower layer (e.g., a WTRU RLC entity), the WTRU (e.g., a PDCP entity) may send a discard indication to the lower layer (e.g., an RLC entity) to avoid gaps in the sequence number (e.g., any gaps in any sequence number). In these examples, if dependent PDU set 2 has already been submitted from PDCP entity 2 to RLC entity 2, PDCP entity 2 may send an indication to RLC entity 2 to avoid gaps in the sequence number (e.g., any gaps in the sequence number) upon receiving an indication from PDCP entity 1 that the discard timer for PDU set 1 has expired and one, more, or all of the PDUs in PDU set 1 were not successfully delivered to the gNB. Following the receipt of this indication from PDCP entity 2 to RLC entity 2, RLC entity 2 may send an indication to the base station (e.g., a gNB) or to a lower layer indicating that PDU set 2 is no longer useful. The notice may include the reason (e.g., due to the failed delivery of some or all of PDU Set 1, or due to the expected failed reconfiguration of PDU Set 1 as a result of some or more or all of the PDUs in PDU Set 1 being delayed / lost).

[0138] Some layers or entities may be common to multiple PDCP entities in a WTRU. An example of a new layer is a new layer between the SDAP and PDCP layers in a WTRU that may be common to multiple PDCP entities in a WTRU. For example, in a model where (e.g., each) type of PDU sets may be mapped to different DRBs (and thus different PDCP entities), and there are dependencies between two or more such different PDU sets (e.g., mapped to different PDCP entities), a common layer on top of the PDCP entities (e.g., existing PDCP entities) may be used for one or more of the following: The common layer may have visibility to dependent PDU sets and the PDCP entities to which they are mapped (e.g., all dependent PDU sets and the PDCP entities to which they are mapped). The common layer may send indications to PDCP entities that have dependent PDU sets (e.g., all PDCP entities that have dependent PDU sets) to inform them about the dependencies. The common layer may receive indications from base stations (e.g., gNBs), such as status reports indicating successful or failed delivery of data units and / or indications to drop (e.g., any) data units or dependent data units. The common layer may send indications to PDCP entities (e.g., all PDCP entities with dependent PDU sets) that have dependent PDU sets to notify them of successful / failed delivery indications from base stations (e.g., gNBs). The common layer may handle one or more discard timers and / or have visibility of discard timers in one or more PDCP entities. The common layer may determine dependencies between data units (e.g., between PDU set 1 and PDU set 2). The common layer may send discard indications to PDCP entities to drop dependent data units (e.g., dropping PDU set 2 to PDCP entity 2 following a status report from base station (e.g., gNB) indicating a failed delivery of PDU set 1).

[0139] In one or more examples herein, following the discarding of a dependent PDU set, the WTRU may notify the base station of the discard by sending an indication to a base station such as a gNB (e.g., the corresponding PDCP entity in the gNB). The indication may include a method for identifying the discarded PDU set and / or any context (e.g., serial number, sequence number, etc.) associated with the discarded PDU set. In an example, the WTRU may determine that PDU set 1 and PDU set 2 are dependent. If the discard timer for PDU set 1 has expired and PDU set 1 was not successfully transmitted to the base station (e.g., the WTRU may receive a status report from the gNB indicating a failed delivery of PDU set 1 or a request from the gNB to retransmit PDU set 1), the WTRU may discard PDU set 2.

[0140] One or more of the following features, such as polling in PDCP or polling in RLC, may be used in connection with one or more examples described herein (e.g., the example relating to polling in PDCP and / or the example relating to polling in RLC).

[0141] Polling may occur at the PDCP level associated with the WTRU (for example, as described in one or more examples relating to polling herein). In the examples, the WTRU (e.g., the transmitting PDCP entity in the WTRU) may receive configuration information (e.g., from the network) indicating configuration for polling. Such configuration may include, for example, one or more timers and / or conditions, rules, or thresholds relating to whether and / or when polling should be triggered in the PDCP. The WTRU may trigger polling (e.g., at the PDCP level associated with the WTRU) by sending a polling indicator. For example, the polling indicator may be sent in a PDCP packet or in the PDCP header. The WTRU may receive and / or determine a time period (e.g., a timer / time window) that, upon expiration, can trigger a polling indicator (e.g., can trigger a decision that a polling indicator should be sent). In the examples, the polling indicator may be sent upon expiration of the time period. For example, the time period (e.g., a timer value) may be standalone. The time period (e.g., timer value) may correlate with various parameters (e.g., PSDB and / or PDCP discardTimer). WTRU may receive and / or determine one or more conditions, rules, or thresholds regarding whether and / or when polling should be triggered. In the example, WTRU may, for example, be a threshold corresponding to the importance value and / or importance level of a PDU set (e.g., priority value T of a PDU set). I ) may receive, and therefore WTRU is T I Polling may be triggered in PDCP for PDU sets with importance values ​​greater than (e.g., threshold T). IPolling may only be triggered at PDCP levels related to WTRU for PDU sets with a higher importance level than T. For example, the priority of a PDU set may be used to indicate the importance level of a PDU set for an Extended Reality (XR) application (for example, a lower priority value for a PDU set may indicate a higher priority or importance level for a PDU set). WTRU is a threshold T. I Polling may not be triggered for PDU sets with the following severity levels. In some cases, WTRU may receive thresholds corresponding to one or more PDU set parameters (e.g., one or more PDU set parameters other than the PDU set severity level). For example, WTRU may receive thresholds corresponding to the PDU set delay budget (PSDB), thresholds corresponding to the PDU set error rate (PSER), etc. In some cases, WTRU may receive configurations and / or rules that trigger polling for certain types of PDU sets (e.g., only polling for certain types of PDU sets). For example, a certain type of PDU set may be a Type I PDU set (e.g., a PDU set that does not tolerate any loss or delay of any PDUs in the PDU set).

[0142] A WTRU (e.g., a transmitted PDCP in the WTRU) may be configured to trigger polling based on one or more of the following examples (e.g., sending a polling indicator). A WTRU may be configured to send a polling indicator related to a set of PDUs of a certain characteristic. In the example, a WTRU may be configured to trigger polling if the importance of a set of PDUs (e.g., indicated by the priority of the set of PDUs) is greater than a threshold (e.g., a threshold received from the NW).

[0143] Figure 2 is an example illustrating the decision to send a polling indicator and the sending of the polling indicator. As shown in Figure 2, the WTRU may receive configuration information indicating the priority value of a PDU set at 202. The WTRU may determine at 204 that the PDU set is associated with a priority higher than the PDU set's priority value. If the WTRU has not received a status report related to the PDU set (e.g., indicating the receipt of the PDU set), the WTRU may determine at 206 that a polling indicator should be sent based on the determination that the PDU set is associated with a priority higher than the PDU set's priority value. The WTRU may send a polling indicator at 208, which may indicate a request for the sending of a status report related to the PDU set. In some examples, the WTRU may be configured to trigger polling if the PDU set is marked with a severity indicator (e.g., a severity flag). In some examples, the WTRU may be configured to trigger polling if the PDU set is a PSIHI PDU set (e.g., marked with a PSIHI indicator).

[0144] If a PDU set has not been received, the WTRU may be configured to trigger polling. For example, if the WTRU (e.g., Tx PDCP) has not received a status report related to a PDU set (e.g., a status report indicating successful delivery of the PDU set), the WTRU may be configured to trigger polling. For example, if the WTRU (e.g., Tx PDCP) receives a status report indicating a failed delivery of a PDU set or a portion thereof, the WTRU may be configured to trigger polling.

[0145] A WTRU can be configured to trigger polling based on the buffer status associated with the WTRU. For example, a WTRU (e.g., a Tx PDCP buffer) can be configured to trigger polling when its buffer status is filled (e.g., a buffer status indicating a filled status). For example, a WTRU (e.g., a Tx PDCP buffer) can be configured to trigger polling when its buffer status is filled to a certain extent.

[0146] The WTRU can be configured to trigger polling based on the size of the PDU set. For example, if the size of the PDU set is greater than a threshold, the WTRU can be configured to trigger polling. For example, if the size of the PDU set is less than or equal to a threshold, the WTRU can be configured to trigger polling.

[0147] A WTRU can be configured to trigger polling based on the PSDB and / or PSER of a PDU set. For example, if the PSDB of a PDU set is less than a threshold (e.g., a threshold received from the network), the WTRU can be configured to trigger polling. For example, if the PSDB of a PDU set is greater than or equal to a threshold, the WTRU can be configured not to trigger polling. For example, if the PSER of a PDU set is less than or equal to a threshold (e.g., a threshold received from the network), the WTRU can be configured to trigger polling. For example, if the number of PDUs in a PDU set that were not received or received erroneously (e.g., corrupted, delayed) is greater than or equal to a threshold (e.g., a threshold received from the network), the WTRU can be configured to trigger polling.

[0148] A WTRU may be configured to trigger polling based on requests (e.g., from the network and / or application layer). For example, a WTRU may be configured to trigger polling if it receives a request to trigger polling for its set of PDUs, or if it receives a request to trigger polling for that type of set of PDUs.

[0149] A WTRU can be configured to trigger polling based on the PDU reception rate associated with a PDU set. The PDU reception rate may represent the number of PDUs in a PDU set that are being received or the percentage of PDUs in a PDU set that are being received. For example, a WTRU can be configured to trigger polling based on the number of PDUs in a PDU set received at time T in the WTRU (e.g., Tx PDCP). For example, if the number of PDUs in a PDU set received at time T is greater than a threshold (e.g., a PDU reception threshold), the WTRU can be configured to trigger polling. If the number of PDUs in a PDU set received at time T is less than or equal to a threshold (e.g., a PDU reception threshold), the WTRU can be configured to trigger polling. A WTRU can also be configured to trigger polling based on the percentage of PDUs in a PDU set received at time T. For example, if the percentage of PDUs in a PDU set received at time T is greater than a threshold (e.g., a PDU reception threshold received from the network), the WTRU can be configured to trigger polling. A WTRU may be configured to trigger polling if the proportion of PDUs in a set of PDUs received at time T is less than or equal to a threshold (e.g., a PDU reception threshold from the network). In some examples, a WTRU may be configured to trigger polling based on, for example, the total number of PDUs in a set of PDUs (e.g., triggering polling if the total number of PDUs in a set of PDUs is greater than a threshold, and not triggering polling if the total number of PDUs in a set of PDUs is less than or equal to the threshold). A WTRU may be configured to trigger polling based on, for example, the size of a buffer in the WTRU (e.g., a PDCP buffer). For example, a WTRU may be configured to trigger polling if the buffer size is greater than a threshold (e.g., not triggering polling if the buffer size is less than a threshold).

[0150] WTRU (e.g., transmitted PDCP in WTRU) can be polled per PDU (e.g., one polling indicator per PDU), per PDU set (e.g., one polling indicator per PDU set), per PDU set (e.g., the remaining PDUs in a PDU set (e.g., all remaining PDUs)), per data burst (e.g., the remaining PDUs / PDU sets in a data burst), per data burst (e.g., one polling indicator per data burst), per group of PDUs (e.g., one polling indicator per group of PDUs), per group of PDU sets (e.g., one polling indicator per group of PDU sets), Polling indicators (e.g., polling indicators, polling bits, polling flags, or polling messages) may be sent to a network (e.g., a receiving PDCP in the NW) at one or more data unit granularities, such as per group of data bursts (e.g., one polling indicator per group of data bursts), per bit / byte / kilobit / megabit / megabyte, or per group thereof, or per n bits / byte / kilobit / megabit / megabyte (e.g., one polling indicator per n bits / byte / kilobit / megabit / megabyte).

[0151] A WTRU may send polling indicators (e.g., polling indicators, polling bits, polling flags, or polling messages) in-band (e.g., in the headers of the PDU and / or PDU set) or separately. In the example, a separate PDU may be sent indicating polling for a particular data unit or group thereof, which may have a data unit ID (e.g., a PDU set ID).

[0152] A WTRU may receive one or more status reports after it has sent a polling indicator. For example, after sending a polling indicator, a WTRU (e.g., Tx PDCP) may wait for a certain period of time (e.g., a pre-configured time window) for one or more status reports from the NW.

[0153] A WTRU may discard a data unit after it has received an indication (e.g., on the Rx side) that the data unit has been received. For example, a WTRU may receive a status report indicating the receipt of a PDU set after a polling indicator has been sent, determine that the PDU set has been received based on the status report, and discard the PDU set based on the determination that the PDU set has been received. In some examples, a WTRU (e.g., a Tx PDCP) may discard a data unit (e.g., a PDU set) as soon as it receives a status report from the Rx side (e.g., a Rx PDCP) confirming the successful delivery of the data unit.

[0154] A WTRU may refrain from discarding a data unit until it receives an indication that the data unit has been received. For example, a WTRU (e.g., Tx PDCP) may not discard a data unit until it receives a status report from the Rx side (e.g., Rx PDCP) confirming the successful delivery of the data unit. The status report may be, for example, a response to a polling indicator sent by the WTRU (e.g., generated and / or sent in response to it).

[0155] A WTRU may receive status reports for each PDU or for each set of PDUs. In some examples, a WTRU (e.g., Tx PDCP) may receive one status report indicating whether the reception of each PDU in a set was successful or unsuccessful. In some examples, a WTRU (e.g., Tx PDCP) may receive one status report indicating whether the reception of a set of PDUs was successful or unsuccessful. For example, the status report may indicate the status of each PDU in a set, or it may show "1" if all PDUs in a set were successfully received, and "0" if none of the PDUs in the set were received.

[0156] Polling may occur at the RLC level associated with a WTRU (as described, for example, in one or more examples relating to polling herein). In the examples, the WTRU (e.g., the transmitting RLC entity in the WTRU) may receive configuration information (e.g., from the network) indicating configuration for polling. Such configuration may include, for example, one or more timers and / or conditions, rules, or thresholds regarding whether and / or when polling in the RLC should be triggered. The WTRU may trigger polling (e.g., at the RLC level associated with the WTRU) by sending a polling indicator. For example, the polling indicator may be sent in an RLC packet or in an RLC header. The WTRU may receive and / or determine a time period (e.g., a timer / time window) that, upon expiration, can trigger a polling indicator (e.g., can trigger a decision that a polling indicator should be sent). In the examples, the polling indicator may be sent upon expiration of the time period. For example, the time period (e.g., a timer value) may be standalone. The time period (e.g., timer value) may correlate with various parameters (e.g., PSDB). WTRU may receive and / or determine one or more conditions, rules, or thresholds regarding whether and / or when polling should be triggered. In the example, WTRU may, for example, be a threshold corresponding to the importance value and / or importance level of a PDU set (e.g., priority value T of a PDU set). I ) may receive, and therefore WTRU is T I Polling in RLC may be triggered for PDU sets with importance values ​​greater than (e.g., threshold T). I (Polling may only be triggered at RLC levels related to WTRU for PDU sets with a higher importance level than WTRU.) IPolling may not be triggered for PDU sets with the following severity levels. In some cases, WTRU may receive thresholds corresponding to one or more PDU set parameters (e.g., one or more PDU set parameters other than the PDU set severity level). For example, WTRU may receive thresholds corresponding to the PDU set delay budget (PSDB), thresholds corresponding to the PDU set error rate (PSER), etc. In some cases, WTRU may receive configurations and / or rules that trigger polling for certain types of PDU sets (e.g., only polling for certain types of PDU sets). For example, a certain type of PDU set may be a Type I PDU set (e.g., a PDU set that does not tolerate any loss or delay of any PDUs in the PDU set).

[0157] A WTRU (e.g., a transmitted RLC in the WTRU) may be configured to trigger polling based on one or more of the following examples (e.g., the examples shown in Figure 2). A WTRU may be configured to send a polling indicator related to a set of PDUs of a certain characteristic. In the example, a WTRU may be configured to trigger polling if the importance of a PDU set (e.g., indicated by the priority of the PDU set) is greater than a threshold (e.g., a threshold received from the NW). In some examples, a WTRU may be configured to trigger polling if a PDU set is marked with an importance indicator (e.g., an importance flag). In some examples, a WTRU may be configured to trigger polling if a PDU set is a PSIHI PDU set (e.g., marked with a PSIHI indicator).

[0158] For example, if a WTRU (e.g., a Transmit RLC within the WTRU) receives an indication from a higher layer within the WTRU (e.g., PDCP, SDAP, application / higher layer) to trigger polling, the WTRU may be configured to trigger polling.

[0159] If no PDU set is received, the WTRU may be configured to trigger polling.

[0160] For example, a WTRU (e.g., Tx RLC) may be configured to trigger polling if it has not received a status report related to a PDU set (e.g., a status report indicating successful delivery of the PDU set). In some examples, a WTRU (e.g., Tx RLC) may be configured to trigger polling if it receives a status report indicating a failed delivery of a PDU set or a portion thereof.

[0161] A WTRU can be configured to trigger polling based on the buffer status associated with the WTRU. For example, a WTRU (e.g., a Tx RLC buffer) can be configured to trigger polling when its buffer status is filled (e.g., a buffer status indicating a filled status). For example, a WTRU (e.g., a Tx RLC buffer) can be configured to trigger polling when its buffer status is filled to a certain extent.

[0162] The WTRU can be configured to trigger polling based on the size of the PDU set. For example, if the size of the PDU set is greater than a threshold, the WTRU can be configured to trigger polling. For example, if the size of the PDU set is less than or equal to a threshold, the WTRU can be configured to trigger polling.

[0163] The WTRU can be configured to trigger polling based on the PSDB and / or PSER of the PDU set. For example, if the PSDB of the PDU set is less than a threshold (e.g., a threshold received from the network), the WTRU can be configured to trigger polling. For example, if the PSDB of the PDU set is greater than or equal to a threshold, the WTRU can be configured not to trigger polling. For example, if the PSER of the PDU set is less than a threshold (e.g., a threshold received from the network), the WTRU can be configured to trigger polling.

[0164] A WTRU may be configured to trigger polling based on requests (e.g., from the network and / or application layer). For example, a WTRU may be configured to trigger polling if it receives a request to trigger polling for its set of PDUs, or if it receives a request to trigger polling for that type of set of PDUs.

[0165] A WTRU can be configured to trigger polling based on the PDU reception rate associated with a set of PDUs. The PDU reception rate may represent the number of PDUs in a set of PDUs being received or the percentage of PDUs in a set of PDUs being received. For example, a WTRU can be configured to trigger polling based on the number of PDUs in a set of PDUs received at time T in the WTRU (e.g., Tx RLC). For example, if the number of PDUs in a set of PDUs received at time T is greater than a threshold (e.g., a PDU reception threshold), the WTRU can be configured to trigger polling. If the number of PDUs in a set of PDUs received at time T is less than or equal to a threshold (e.g., a PDU reception threshold), the WTRU can be configured to trigger polling. A WTRU can also be configured to trigger polling based on the percentage of PDUs in a set of PDUs received at time T. For example, if the percentage of PDUs in a set of PDUs received at time T is greater than a threshold (e.g., a PDU reception threshold received from the network), the WTRU can be configured to trigger polling. A WTRU may be configured to trigger polling if the proportion of PDUs in a set of PDUs received at time T is less than or equal to a threshold (e.g., a PDU reception threshold from the network). In some examples, a WTRU may be configured to trigger polling based on, for example, the total number of PDUs in a set of PDUs (e.g., triggering polling if the total number of PDUs in a set of PDUs is greater than a threshold, and not triggering polling if the total number of PDUs in a set of PDUs is less than or equal to the threshold). A WTRU may be configured to trigger polling based on, for example, the size of a buffer in the WTRU (e.g., an RLC buffer). For example, a WTRU may be configured to trigger polling if the buffer size is greater than a threshold (e.g., not triggering polling if the buffer size is less than a threshold).

[0166] WTRU (e.g., transmitted RLC within a WTRU) can be polled per PDU (e.g., one polling indicator per PDU), per PDU set (e.g., one polling indicator per PDU set), per PDU set (e.g., the remaining PDUs in a PDU set (e.g., all remaining PDUs)), per data burst (e.g., the remaining PDUs / PDU sets in a data burst), per data burst (e.g., one polling indicator per data burst), per group of PDUs (e.g., one polling indicator per group of PDUs), per group of PDU sets (e.g., one polling indicator per group of PDU sets), Polling indicators (e.g., polling indicators, polling bits, polling flags, or polling messages) may be sent to a network (e.g., a receiving RLC in a NW) at one or more data unit granularities, such as per group of data bursts (e.g., one polling indicator per group of data bursts), per bit / byte / kilobit / megabit / megabyte, or per group thereof, or per n bits / byte / kilobit / megabit / megabyte (e.g., one polling indicator per n bits / byte / kilobit / megabit / megabyte).

[0167] A WTRU (e.g., a transmitted RLC within a WTRU) may send polling indicators (e.g., polling indicators, polling bits, polling flags, or polling messages) in-band (e.g., in the headers of the PDU and / or PDU set) or separately. In the example, a separate PDU may be sent indicating polling for a particular data unit or group thereof, which may have a data unit ID (e.g., a PDU set ID).

[0168] A WTRU may receive one or more status reports after it has sent a polling indicator. For example, after sending a polling indicator, a WTRU (e.g., Tx RLC) may wait for a certain period of time (e.g., a pre-configured time window) to receive one or more status reports from the NW.

[0169] A WTRU may discard a data unit after it has received an indication (e.g., on the Rx side) that the data unit has been received. For example, after a polling indicator is sent, the WTRU may receive a status report indicating the receipt of a PDU set, determine based on the status report that the PDU set has been received, and discard the PDU set based on that determination. In some examples, as soon as the WTRU (e.g., Tx RLC) receives a status report from the Rx side (e.g., Rx RLC) confirming the successful delivery of the data unit, the WTRU (e.g., Tx RLC) may discard the data unit (e.g., a PDU set) or a portion thereof.

[0170] A WTRU may refrain from discarding a data unit until it receives an indication that the data unit has been received. For example, a WTRU (e.g., a Tx RLC) may not discard a data unit until it receives a status report from the Rx side confirming the successful delivery of the data unit. The status report may, for example, be in response to a polling indicator sent by the WTRU (e.g., it may be generated and / or sent in response to it).

[0171] In the example, a WTRU (e.g., Tx RLC) may not perform a discard even if it receives an indication from a higher layer (e.g., Tx PDCP in the WTRU) that it is discarding a data unit or a portion of it, until it receives a status report from the Rx side confirming the successful delivery of the data unit.

[0172] A WTRU may receive status reports for each PDU or for each set of PDUs. In some examples, a WTRU (e.g., Tx RLC) may receive one status report indicating whether the reception of each PDU in a set was successful or unsuccessful. In some examples, a WTRU (e.g., Tx RLC) may receive one status report indicating whether the reception of a set of PDUs was successful or unsuccessful. For example, the status report may indicate the status of each PDU in a set, or the status report may show "1" if all PDUs in a set were successfully received, and "0" if none of the PDUs in the set were received.

[0173] One or more of the following features, such as retaining data units in a PDCP, retaining data units in an RLC, or discarding on the receiving end, may be used in connection with one or more examples described herein (e.g., one or more examples relating to facilitating or guaranteeing discarding in a PDCP, one or more examples relating to facilitating or guaranteeing discarding in an RLC, or one or more examples relating to facilitating or guaranteeing discarding in a PDCP on the Rx side).

[0174] Data units may be retained in the PDCP. A WTRU (e.g., Tx PDCP entity in the WTRU) may receive configurations from the network (e.g., conditions / rules / thresholds) that can trigger the retention mechanism, which may include one or more of the following: thresholds corresponding to parameters of a PDU set (e.g., thresholds may correspond to parameters of a PDU set), timer / time window configurations T, which, upon expiration, can trigger the WTRU to determine whether retention should be performed (e.g., whether the retention mechanism should be activated), or one or more of the following other thresholds.

[0175] A WTRU (e.g., a Tx PDCP entity within a WTRU) may receive configurations (e.g., conditions / rules / thresholds) from the network that can trigger a retention mechanism, which may include thresholds corresponding to parameters of a PDU set. Parameters of a PDU set may include one or more of the following: the size of the PDU set, the number of PDUs in the PDU set, the number and / or percentage of PDUs in the PDU set received at a given time, the number and / or percentage of PDUs in the PDU set received due to PSDB expiration, the number and / or percentage of PDUs in the PDU set received by a time window within PSDB expiration, the number and / or percentage of PDUs in the PDU set received before the WTRU (e.g., Tx PDCP) can forward or transmit the PDU (and / or PDU set) to a lower layer (e.g., Tx RLC).

[0176] A WTRU (e.g., a Tx PDCP entity within the WTRU) may receive configurations from the network (e.g., conditions / rules / thresholds) that can trigger a retention mechanism, which may include a timer / time window configuration T. The timer / time window configuration T may trigger the WTRU to determine whether retention should be performed upon expiration. For example, the timer value T may be standalone. The timer value T may correlate with the PSDB of the PDU set and / or a PDCP discardTimer associated with the PDU set. In the example, at time t before the expiration of the discardTimer associated with the PDU set, the WTRU may be configured to determine the number and / or percentage of PDUs in the PDU set it has received.

[0177] A WTRU (e.g., a Tx PDCP entity within the WTRU) may receive configurations from the network (e.g., conditions / rules / thresholds) that can trigger a retention mechanism, which may include other thresholds. For example, one or more of these other thresholds may correspond to the WTRU's buffer size (e.g., the WTRU may trigger a retention mechanism as long as the PDCP buffer is filled to X% or less; otherwise, the WTRU may not trigger a retention mechanism).

[0178] In the example, WTRU (e.g., Tx PDCP) may be configured to identify the type of PDU set, for example, whether the type of PDU set allows for the loss / delay of any PDU in the PDU set.

[0179] For example, a WTRU (e.g., Tx PDCP) may be configured to detect the presence of an indicator in a PDU set (e.g., a PSIHI indicator) that can provide information about how the PDU set should be handled in the lower layers.

[0180] A WTRU (e.g., Tx PDCP) may be configured to determine the size of a PDU set and / or the start and / or end indicators of the PDU set (e.g., based on the sequence number). A WTRU (e.g., Tx PDCP) may receive information about the size of a PDU set from a higher layer (e.g., the application layer).

[0181] A WTRU (e.g., Tx PDCP) may be configured to determine the number and / or percentage of PDUs in a PDU set received at time T (e.g., time T configured by the network). For example, a WTRU may be able to read the sequence numbers of PDUs / PDU sets. As an example, the sequence numbers for PDUs 1, 2, and 3 in PDU set 1 may be represented as (1,1), (1,2), and (1,3). Based on information (e.g., via the sequence numbers) regarding the total number of PDUs in the PDU set and the number of PDUs received at time T, a WTRU may determine the percentage of PDUs in a PDU set received at time T. A WTRU may determine the number or percentage of PDUs in a PDU set via a display from a higher layer (e.g., the application layer).

[0182] A WTRU (e.g., Tx PDCP) may be configured to "retain" PDUs from a PDU set (and not send them to lower layers, e.g., Tx RLC) based on one or more of the following conditions: The WTRU may be configured to "retain" PDUs from a PDU set based on the number of PDUs in a PDU set received at time T (e.g., if the number of PDUs in a PDU set received at time T is greater than a threshold received from the NW). The WTRU may be configured to "retain" PDUs from a PDU set based on the proportion of PDUs in a PDU set received at time T (e.g., if the proportion of PDUs in a PDU set received at time T is greater than a threshold received from the NW). The WTRU may be configured to "retain" PDUs from a PDU set based on the total number of PDUs in the PDU set. The WTRU may be configured to "retain" PDUs from a PDU set based on the size of a buffer (e.g., a PDCP buffer) in the WTRU. For example, if the buffer size is greater than a threshold, the WTRU may be configured to "hold" the PDUs in the PDU set. For example, if the buffer status in the WTRU (e.g., Tx PDCP buffer) is filled, the WTRU may be configured to "hold" the PDUs in the PDU set. For example, if the buffer status in the WTRU (e.g., Tx PDCP buffer) is filled to a certain extent, the WTRU may be configured to "hold" the PDUs in the PDU set. For example, if the importance of a PDU set is greater than a threshold received from the NW, the WTRU may be configured to "hold" the PDUs in the PDU set. For example, if a PDU set is marked with an importance flag / indicator, the WTRU may be configured to "hold" the PDUs in the PDU set. For example, if a PDU set is a PSIHI PDU set (e.g., marked with a PSIHI indicator), the WTRU may be configured to "hold" the PDUs in the PDU set.For example, if a WTRU (e.g., Tx PDCP) has not received a status report indicating successful delivery of a set of PDUs, the WTRU may be configured to "retain" the PDUs in the set. For example, if a WTRU (e.g., Tx PDCP) has received a status report indicating failed delivery of a set of PDUs or a portion thereof, the WTRU may be configured to "retain" the PDUs in the set. For example, if the size of a set of PDUs is greater than a threshold, the WTRU may be configured to "retain" the PDUs in the set. For example, if the size of a set of PDUs is less than a threshold, the WTRU may be configured to "retain" the PDUs in the set. For example, if the PSDB of a set of PDUs is less than a threshold received from the NW, the WTRU may be configured to "retain" the PDUs in the set. For example, if a PDCP has a set of PSIHI PDUs that can guarantee the activation of a retention mechanism, the PDCP may not activate the retention mechanism if the PSDB of the PDU set is less than a threshold (for example, the PDCP may not want the risk that the retention mechanism poses if the PSDB is not met). For example, if the PSDB of the PDU set is greater than a threshold received from the NW, the WTRU may be configured to "retain" the PDUs in the PDU set. For example, if a PDCP has a set of PSIHI PDUs, the PDCP may activate the retention mechanism if the PSDB of the PDU set is greater than a threshold (for example, if the PSDB of the PDU set is greater than a threshold, the PDCP may only activate the retention mechanism). For example, if a WTRU receives a request (for example, from the network and / or application layer) to trigger retention for a PDU set or that type of PDU set, the WTRU may be configured to "retain" the PDUs in the PDU set.

[0183] A WTRU (e.g., Tx PDCP) may be configured to "hold" PDUs from a PDU set until one or more of the following are fulfilled: The WTRU may be configured to "hold" PDUs from a PDU set for a short period of time (e.g., during a fixed time window configured by the NW, during a time window according to the PSDB, or during a time window according to the PDU set's discardTimer). The WTRU may be configured to "hold" PDUs from a PDU set until (e.g., all) PDUs from the PDU set are received in the WTRU (e.g., Tx PDCP). The WTRU may be configured to "hold" PDUs from a PDU set until a certain number of PDUs from the PDU set are received in the WTRU (e.g., Tx PDCP). The WTRU may be configured to "hold" PDUs from a PDU set until a certain percentage of PDUs from the PDU set are received in the WTRU (e.g., Tx PDCP). A WTRU may be configured to "hold" PDUs from a set of PDUs until a buffer in the WTRU (e.g., a PDCP buffer) is filled (e.g., completely filled). A WTRU may be configured to "hold" PDUs from a set of PDUs until a buffer in the WTRU (e.g., a PDCP buffer) is filled to a certain amount / percentage. A WTRU may be configured to "hold" PDUs from a set of PDUs until the WTRU (e.g., Tx PDCP) receives new data, and so on.

[0184] A WTRU may send information about a retention mechanism to the network. This can take the form of a control PDU generated by the WTRU (e.g., Tx PDCP). The control PDU may include one or more of the following information about the retention mechanism: the number of PDUs in the retained PDU set, the duration for which the PDUs in the PDU set have been retained, the total amount of time the WTRU is expected to retain / hold the PDUs in the PDU set, the number and / or percentage of remaining PDUs in the PDU set, the number and / or percentage of remaining PDUs in the PDU set that the WTRU should receive before it can release the retention mechanism, the size of the PDU set, the PDU set ID / sequence number (SN) of the retained PDU set, and the PDU ID / SN of the retained PDUs.

[0185] Data units may be held in the RLC. A WTRU (e.g., Tx RLC entity in the WTRU) may receive configurations from the network (e.g., conditions / rules / thresholds) that can trigger the retention mechanism, which may include one or more of the following: thresholds corresponding to parameters of a PDU set (e.g., thresholds may correspond to parameters of a PDU set), timer / time window configurations T, which, upon expiration, can trigger the WTRU to determine whether retention should be performed (e.g., whether the retention mechanism should be activated), or one or more of the following other thresholds.

[0186] A WTRU (e.g., a Tx RLC entity within a WTRU) may receive configurations (e.g., conditions / rules / thresholds) from the network that can trigger a retention mechanism, which may include thresholds corresponding to parameters of a PDU set, e.g., thresholds corresponding to the size of a PDU set, thresholds corresponding to the number of PDUs in a PDU set, thresholds corresponding to the number and / or percentage of PDUs in a PDU set received at a given time, thresholds corresponding to the number and / or percentage of PDUs in a PDU set received upon PSDB expiration, thresholds corresponding to the number and / or percentage of PDUs in a PDU set received within a time window within PSDB expiration, and thresholds corresponding to the number and / or percentage of PDUs in a PDU set received before the WTRU (e.g., Tx RLC) can forward or transmit the PDU and / or PDU set (e.g., to a lower layer such as a MAC).

[0187] A WTRU (e.g., a Tx RLC entity within the WTRU) may receive configurations (e.g., conditions / rules / thresholds) from the network that can trigger a retention mechanism, which may include other thresholds corresponding to the size of authorizations that the WTRU must have received (e.g., at the MAC) before it can transfer data (e.g., from the RLC to the MAC). These other thresholds may include thresholds corresponding to the WTRU's buffer size (e.g., if the RLC buffer is filled to less than 60%, the WTRU may consider triggering a retention mechanism; otherwise, it may not).

[0188] A WTRU (e.g., a Tx RLC entity within the WTRU) may receive configurations from the network (e.g., conditions / rules / thresholds) that can trigger a retention mechanism, which may include a timer / time window configuration T. The timer / time window configuration T may trigger the WTRU to determine whether retention should be performed upon expiration. For example, the timer value T may be standalone. The timer value T may correlate with a PSDB of a PDU set. In the example, at time t before the expiration of the PSDB associated with the PDU set, the WTRU may be configured to determine the number and / or percentage of PDUs in the PDU set it has received.

[0189] In the example, WTRU (e.g., RLC) may be configured to identify the type of PDU set (e.g., whether the PDU set type allows for loss / delay of any PDUs in the PDU set).

[0190] For example, a WTRU (e.g., RLC) may be configured to detect the presence of an indicator (e.g., a PSIHI indicator) in a PDU set that can provide information about how the PDU set should be handled (e.g., in lower layers).

[0191] A WTRU (e.g., RLC) may be configured to determine the size of a PDU set (e.g., based on a sequence number) and / or to determine the start and / or end indicators of the PDU set. The WTRU (e.g., RLC) may receive information about the size of a PDU set from a higher layer (e.g., an application layer).

[0192] A WTRU (e.g., RLC) may be configured to determine the number and / or percentage of PDUs in a PDU set received at time T (e.g., time T configured by the network). For example, a WTRU may be able to read the sequence number of a PDU / PDU set. As an example, the sequence numbers for PDUs 1, 2, and 3 in PDU set 1 may be represented as (1,1), (1,2), and (1,3). Based on information (e.g., via the sequence number) regarding the total number of PDUs in the PDU set and the number of PDUs received at time T, a WTRU may determine the percentage of PDUs in a PDU set received at time T. A WTRU may determine the number or percentage of PDUs in a PDU set via a display from a higher layer (e.g., the application layer).

[0193] A WTRU (e.g., an RLC) may be configured to “hold” PDUs from a set of PDUs (and not send them to a lower layer, e.g., a MAC) based on one or more of the following conditions: A WTRU may be configured to “hold” PDUs from a set of PDUs based on an indication, e.g., an indication from a lower layer (e.g., a MAC). An indication may include one or more of the following: An indication may indicate the size of one or more available authorizations (e.g., authorizations available at a MAC). For example, if the size of available authorizations (e.g., at a MAC) is not sufficient to cover the entire set of PDUs or at least a certain amount / percentage of the set of PDUs, the WTRU may be configured to hold (e.g., at an RLC) PDUs from a set that may have already been received (e.g., at an RLC). In some examples, for a PDU set associated with a PSIHI indicator, for example, if even one PDU in the PDU set is delayed or lost, the remaining PDUs in the PDU set may be unavailable (e.g., useless), so the WTRU (e.g., MAC) may wait until it receives an indication that it has one or more authorizations large enough to accommodate the entire PDU set before sending the PDUs in that PDU set (e.g., to a lower layer such as MAC). The indication may include the number of authorizations available (e.g., available in MAC). The indication may include the size of the total number of authorizations available (e.g., the sum of all authorizations available in MAC). Authorizations may correspond to one or more of CG authorizations, DG authorizations, or combinations thereof. The indication may include the number of authorizations expected to be available (e.g., the number of authorizations expected to be available in MAC within a pre-configured time window). The indication may include the size of authorizations expected to be available (e.g., the size of authorizations expected to be available in MAC within a pre-configured time window).

[0194] For example, if the number of PDUs in a PDU set received at time T is greater than a threshold (e.g., a threshold received from the network), the WTRU may be configured to "retain" the PDUs in the PDU set based on the number of PDUs in the PDU set received at time T. For example, if the proportion of PDUs in a PDU set received at time T is greater than a threshold (e.g., a threshold received from the network), the WTRU may be configured to "retain" the PDUs in the PDU set based on the proportion of PDUs in the PDU set received at time T. The WTRU may be configured to "retain" the PDUs in a PDU set based on the total number of PDUs in the PDU set. For example, if the size of the buffer is greater than a threshold, the WTRU may be configured to "retain" the PDUs in the PDU set based on the size of the buffer (e.g., an RLC buffer) in the WTRU. For example, if the buffer status in the WTRU (e.g., Tx RLC buffer) is filled, the WTRU may be configured to "retain" the PDUs in the PDU set. For example, if the buffer status in a WTRU (e.g., a Tx RLC buffer) is filled to a certain percentage, the WTRU may be configured to "hold" PDUs from a PDU set. For example, if the importance of a PDU set is greater than a threshold (e.g., a threshold received from the NW), the WTRU may be configured to "hold" PDUs from a PDU set. For example, if a PDU set is marked with an importance flag / indicator, the WTRU may be configured to "hold" PDUs from a PDU set. For example, if a PDU set is a PSIHI PDU set (e.g., marked with a PSIHI indicator), the WTRU may be configured to "hold" PDUs from a PDU set. For example, if a WTRU (e.g., an RLC) has not received a status report indicating successful delivery of a PDU set, the WTRU may be configured to "hold" PDUs from a PDU set. For example, if a WTRU (e.g., RLC) receives a status report indicating a failed delivery of a set of PDUs or a portion thereof, the WTRU may be configured to "hold" the PDUs from the set.For example, if the size of a PDU set is greater than a threshold, the WTRU may be configured to "hold" the PDUs in the PDU set. For example, if the size of a PDU set is less than a threshold, the WTRU may be configured to "hold" the PDUs in the PDU set.

[0195] For example, if the PSDB of a PDU set is smaller than a threshold (e.g., a threshold received from the network), the WTRU may be configured to "hold" the PDUs in the PDU set. In the example, if the RLC has a PSIHI PDU set and has not received an indication of sufficient authorization available to adapt to the entire PDU set (e.g., an indication of sufficient authorization available in the MAC), and the PSDB of the PDU set is smaller than a threshold, the RLC may not activate the holding mechanism (e.g., the RLC may not want the risk that the holding mechanism poses if the PSDB is not met). For example, if the PSDB of a PDU set is larger than a threshold (e.g., a threshold received from the network), the WTRU may be configured to "hold" the PDUs in the PDU set. In the example, if the RLC has a PSIHI PDU set and has not received an indication of sufficient authorization available to adapt to the entire PDU set (e.g., an indication of sufficient authorization available in the MAC), and the PSDB of the PDU set is larger than a threshold, the RLC may activate the holding mechanism (e.g., it may only activate it).

[0196] For example, if a WTRU receives a request (e.g., from the network and / or application layer) to trigger a hold for a set of PDUs or a set of PDUs of that type, the WTRU may be configured to "hold" the PDUs from the set of PDUs.

[0197] A WTRU (e.g., Tx RLC) may be configured to "hold" a PDU from a PDU set until one or more of the following are fulfilled: The WTRU may be configured to "hold" a PDU from a PDU set until it receives an indication (e.g., from a lower layer such as a MAC) that sufficient authorization (e.g., from one or more authorizations) is available to conform the entire PDU set. The WTRU may be configured to "hold" a PDU from a PDU set until it receives an indication (e.g., from a lower layer such as a MAC) that sufficient authorization (e.g., from one or more authorizations) is available to conform at least a certain amount / percentage of the PDU set (e.g., at least 80% of the PDU set). The WTRU may be configured to "hold" a PDU from a PDU set for a short period of time (e.g., during a fixed time window configured by the NW, during a time window according to the PSDB, or during a time window according to the PDU set's discardTimer). A WTRU may be configured to "hold" PDUs from a PDU set until (e.g., all) of the PDUs in the PDU set are received at the WTRU (e.g., Tx RLC). A WTRU may be configured to "hold" PDUs from a PDU set until (e.g., all) of the PDUs in the PDU set are received at the WTRU (e.g., Tx RLC). A WTRU may be configured to "hold" PDUs from a PDU set until (e.g., a certain percentage of) the PDUs in the PDU set are received at the WTRU (e.g., Tx RLC). A WTRU may be configured to "hold" PDUs from a PDU set until (e.g., a buffer in the WTRU, e.g., RLC buffer) is filled (e.g., completely filled). A WTRU may be configured to "hold" PDUs from a PDU set until (e.g., a buffer in the WTRU, e.g., RLC buffer) is filled to a certain amount / percentage. A WTRU may be configured to "hold" PDUs from a set of PDUs until the WTRU (e.g., Tx RLC) receives new data.

[0198] A WTRU (e.g., Tx RLC) may send information about a retention mechanism to the network (e.g., Rx RLC). This can take the form of a status PDU generated by the WTRU (e.g., Tx RLC). The status PDU may include one or more pieces of information about the retention mechanism, such as: the number of PDUs in the retained PDU set; the amount of (additional) permission required to release the retention mechanism; the duration for which the PDUs in the PDU set have been retained; the total amount of time the WTRU is expected to retain / hold the PDUs in the PDU set; the number and / or percentage of remaining PDUs in the PDU set; the number and / or percentage of remaining PDUs in the PDU set that the WTRU should receive before it can release the retention mechanism; the size of the PDU set; the PDU set ID / sequence number (SN) of the retained PDU set; and the PDU ID / SN of the retained PDUs.

[0199] A WTRU (e.g., Tx RLC) may send an indication about the retention mechanism (to lower layers, e.g., MAC). The WTRU (e.g., MAC) may then send an indication to the network (e.g., in MAC CE, SR, BSR) that may inform the network about the retention mechanism, including one or more of the following: the number of PDUs in the retained PDU set, the amount of (additional) authorization required to release the retention mechanism, the duration for which the PDUs in the PDU set have been retained, the total amount of time the WTRU is expected to retain / hold the PDUs in the PDU set, the number and / or percentage of remaining PDUs in the PDU set, the number and / or percentage of remaining PDUs in the PDU set that the WTRU should receive before it can release the retention mechanism, the size of the PDU set, the PDU set ID / sequence number (SN) of the retained PDU set, and the PDU ID / SN of the retained PDUs.

[0200] For example, a WTRU (e.g., Tx RLC) may have a dedicated buffer (e.g., an RLC buffer) for its holding mechanism. For example, a PSIHI PDU set (e.g., PSIHI PDU set only) may be eligible for a dedicated buffer (e.g., an RLC buffer) for its holding mechanism.

[0201] In some cases, a WTRU (e.g., Tx RLC) may use a buffer (e.g., legacy RLC buffer) for all types of data, in which case the reception of new data may trigger one or more of the following actions: termination of the retention mechanism; termination of the retention mechanism when the RLC buffer is filled (e.g., completely filled) (e.g., only in that case); or termination of the retention mechanism when the RLC buffer is filled to a certain amount / percentage (e.g., only in that case). In some cases, a WTRU (e.g., Tx RLC) may use a buffer (e.g., legacy RLC buffer) for all types of data, in which case the reception of new data may trigger one or more of the following WTRU actions based on the priority of the new data relative to the priority of the PSIHI data. For example, if the priority of the new data is higher than the priority of the PSIHI PDU set, the WTRU may send the new data (e.g., to lower layers such as MAC whenever the resource / permission becomes available). If the priority of the new data is less than or equal to the priority of the PSIHI PDU set, the WTRU may send the PSIHI PDU set (for example, to the first available authorization regardless of authorization size).

[0202] The receiving end (e.g., PDCP) may perform discarding (e.g., on the downlink). In the example, the WTRU (e.g., Rx PDCP) may be configured to perform discarding. The WTRU (e.g., Rx PDCP) may receive indications from the network (and / or higher layers (e.g., application layer)) about data (e.g., in a QoS flow) that may be treated as a PSIHI PDU set. For example, the network may not be managed to perform timely collective discarding, and it may send an indication to the Rx PDCP. In the example, data that is not considered a PSIHI PDU set by the network may be considered a PSIHI PDU set and by the WTRU (e.g., by the encoding scheme in the WTRU).

[0203] A WTRU (e.g., Rx PDCP) may detect the loss or delay of some PDUs in a PDU set that is treated as a PSIHI PDU set (e.g., needs to be treated as such) (e.g., based on the SN of the PDUs in the PDU set). A WTRU (e.g., Rx PDCP) may send an indication to the network regarding a change in the status of a PDU set (e.g., a change in status from a normal PDU set to a PSIHI PDU set). If the PDU set's PSDB arrives, a WTRU (e.g., Rx PDCP) may discard the remaining PDUs in the PDU set (e.g., any remaining / other PDUs).

[0204] Although the features and elements described above are described in specific combinations, each feature or element can be used alone or in various combinations with or without other features and elements in a preferred embodiment.

[0205] While the implementations described herein may take into account 3GPP-specific protocols, it should be understood that the embodiments described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and may be applicable to other wireless systems.

[0206] The processes described above may be implemented in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, ROM, RAM, registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM discs and / or digital multipurpose discs (DVDs). Processors related to software may be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transceiver unit (WTRU) equipped with a processor, The aforementioned processor, Receiving configuration information, wherein the configuration information indicates the priority value of a set of protocol data units (PDUs). It is determined that the PDU set is associated with a priority higher than the priority value of the PDU set, Based on the determination that the PDU set is associated with a priority higher than the priority value of the PDU set, and the determination that the status report associated with the PDU set has not been received by the WTRU, it is determined that a polling indicator is sent. The polling indicator is transmitted, the polling indicator indicating a request for the transmission of the status report associated with the PDU set, A WTRU configured to execute [this].

2. The processor is further configured to receive an indication of a time period, and the determination that the status report has not been received by the WTRU includes the determination that the status report has not been received by the WTRU within the time period, according to claim 1.

3. The WTRU of claim 1, wherein the status report associated with the PDU set is used to indicate the receipt of the PDU set.

4. The polling indicator is transmitted to the network in a Packet Data Convergence Protocol (PDCP) packet, according to claim 1.

5. The polling indicator is transmitted to the network in a radio link control (RLC) packet, according to claim 1.

6. The priority of the PDU set indicates the importance level of the PDU set for an Extended Reality (XR) application, according to claim 1.

7. The aforementioned processor, Determining the PDU Set Delay Budget (PSDB) threshold, The determination that the PSDB associated with the PDU set is smaller than the PSDB threshold, and the polling indicator is to be transmitted based on the determination that the PSDB associated with the PDU set is smaller than the PSDB threshold, The WTRU of claim 1, further configured to perform the following:

8. The aforementioned processor, Determining the PDU reception rate associated with the PDU set, wherein the PDU reception rate indicates the number or percentage of PDUs in the PDU set that are being received. It is determined that the PDU reception rate associated with the PDU set is less than or equal to the PDU reception threshold, and that the polling indicator is transmitted based on the determination that the PDU reception rate associated with the PDU set is less than or equal to the PDU reception threshold. The WTRU of claim 1, further configured to perform the following:

9. The aforementioned processor, After the polling indicator is transmitted, the status report indicating the receipt of the PDU set is received, Based on the status report, it is determined that the PDU set has been received, Discard the PDU set based on the determination that the PDU set has been received, The WTRU of claim 1, further configured to perform the following:

10. A method performed by a wireless transceiver unit (WTRU), Receiving configuration information, wherein the configuration information indicates the priority value of a set of protocol data units (PDUs). It is determined that the PDU set is associated with a priority higher than the priority value of the PDU set, Based on the determination that the PDU set is associated with a priority higher than the priority value of the PDU set, and the determination that a status report indicating the receipt of the PDU set has not been received by the WTRU, it is determined that a polling indicator is sent. The polling indicator is transmitted, the polling indicator indicating a request for the transmission of the status report indicating the receipt of the PDU set, A method that includes this.

11. The method of claim 10, further comprising receiving an indication of a time period, wherein the determination that the status report has not been received by the WTRU includes the determination that the status report has not been received by the WTRU within the time period, and the polling indicator is transmitted to the network in a Packet Data Convergence Protocol (PDCP) packet or in a Radio Link Control (RLC) packet.

12. The method of claim 10, wherein the priority of the PDU set indicates the importance level of the PDU set for an Extended Reality (XR) application.

13. Determining the PDU Set Delay Budget (PSDB) threshold, The determination that the PSDB associated with the PDU set is smaller than the PSDB threshold, and the polling indicator is to be transmitted based on the determination that the PSDB associated with the PDU set is smaller than the PSDB threshold, The method of claim 10, further comprising:

14. Determining the PDU reception rate associated with the PDU set, wherein the PDU reception rate indicates the number or percentage of PDUs in the PDU set that are being received. It is determined that the PDU reception rate associated with the PDU set is less than or equal to the PDU reception threshold, and that the polling indicator is transmitted based on the determination that the PDU reception rate associated with the PDU set is less than or equal to the PDU reception threshold. The method of claim 10, further comprising:

15. After the polling indicator is transmitted, the status report indicating the receipt of the PDU set is received, Based on the status report, it is determined that the PDU set has been received, Discard the PDU set based on the determination that the PDU set has been received, The method of claim 10, further comprising:

Images