Data treatment in the protocol stack

Abstract

Systems, methods, and instrumentalities are described herein related to data treatment in the protocol stack. An example device may include a processor configured to perform one or more actions. For example, a device (e.g., a wireless transmit / receive unit (WTRU)) may (e.g., be configured to) receive first transmission configuration information indicating a first transmission configuration. The first transmission configuration may indicate a first mapping condition and / or a first mapping between a quality-of-service (QoS) flow and a first data radio bearer (DRB). The device may receive second transmission configuration information indicating a second transmission configuration. The second transmission configuration may indicate a second mapping condition and / or a second mapping between the QoS flow and a second DRB. The device may determine that a condition is satisfied. The device may select a transmission configuration from the first and / or second transmission configuration based on the determination that the condition.

Description

DATA TREATMENT IN THE PROTOCOL STACKCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 679,473, filed August 5, 2024, the contents of which is incorporated by reference herein.BACKGROUND

[0002] Mobile communications using wireless communication continue to evolve. A fifth generation may be referred to as 5G. A previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).SUMMARY

[0003] Systems, methods, and instrumentalities are described herein related to data treatment in the protocol stack. An example device may include a processor configured to perform one or more of the following actions. For example, a device (e.g., a wireless transmit / receive unit (WTRU)) may (e.g., may be configured to) perform one or more of the following.

[0004] A device (e.g., WTRU) may receive first transmission configuration information from a network. The first transmission configuration information may indicate a first transmission configuration. The first transmission configuration may indicate a first mapping condition and / or a first mapping between a quality-of-service (QoS) flow and a first data radio bearer (DRB). The device may receive second transmission configuration information from the network. The second transmission configuration information may indicate a second transmission configuration. The second transmission configuration may indicate a second mapping condition and / or a second mapping between the QoS flow and a second DRB. The device may determine that a condition is satisfied. The condition may be the first mapping condition or the second mapping condition. The device may select a transmission configuration from the first transmission configuration and / or the second transmission configuration based on the determination that the condition is satisfied. The device may transmit data based on the selected transmission configuration.

[0005] The satisfied condition may be the first mapping condition. The first mapping condition may be based on at least one of a QoS profile of the transmitted data, an application layer property, a data type, or a data attribute. The satisfied condition may be the first mapping condition, and / or selection of the transmission configuration may be based on the second mapping condition not being satisfied. The first transmission configuration may further indicate a mapping between the first DRB and a first logical channel (LCH). The second transmission configuration may further indicate a mapping between the second DRB and a second LCH. The device may send, to the network, an indication of the selected transmission configuration. The satisfied condition may be the first mapping condition, and / or the first mapping condition may be based on a congestion status. The congestion status may be indicated in the first transmission configuration information or determined by the WTRU. The satisfied condition may be the first mapping condition, and / or the first mapping condition may be based on an energy savings state of the WTRU or an energy savings state of the network. The satisfied condition may be the first mapping condition, and / or the first mapping condition may be based on a dependency between a first Protocol Data Unit (PDU) and second PDU.

[0006] A flexible, dynamic mapping in the layer-two stack may be disclosed herein. For example, a device may be configured to receive information, from a network, indicative of a plurality of transmission configurations. Each configuration may have respective mapping rules that define conditions with corresponding mappings between quality-of-service flows and data radio bearers. In an example, transmission configurations may represent a greater than a one-to- one mapping between quality-of-service flows and data radio bearers. The mapping rules may further include a corresponding mapping between data radio bearers and logical channels.

[0007] The device may be configured to determine a transmission configuration from the plurality of transmission configurations applicable for a data transmission based on information indicative of network-device congestion. The information indicative of network-device congestion may include information determined from device buffer status monitoring. The information indicative of network-device congestion may include information received from the network.

[0008] The device may be configured to map a quality-of-service flows and a data radio bearer according to the mapping rules of the determined transmission configuration and transmit the data transmission according to the mapped quality of service flows and a data radio bearer.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0012] FIG. ID is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.EXAMPLE NETWORKS FOR IMPLEMENTATION OF THE EMBODIMENTS

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

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

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

[0016] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

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

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

[0020] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).

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

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

[0023] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellularbased RAT (e g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

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

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

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

[0027] FIG. IB is a system diagram illustrating an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0028] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0031] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

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

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

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

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

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

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

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

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

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

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

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

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

[0044] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or maycommunicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0045] Although the WTRU is described in FIGS. 1 A-1D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0046] In representative embodiments, the other network 112 may be a WLAN.

[0047] 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 an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802. l ie DLS or an 802.1 Iz tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0048] When using the 802.1 lac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

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

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

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

[0052] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.1 In, 802.1 lac, 802.1 laf, and 802.1 lah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.1 lah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network AllocationVector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

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

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

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

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

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

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

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

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

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

[0062] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

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

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

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

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

[0067] Systems, methods, and instrumentalities are described herein related to data treatment in the protocol stack. An example device may include a processor configured to perform one or more of the following actions. For example, a device (e.g., a wireless transmit / receive unit (WTRU)) may (e.g., may be configured to) perform on or more of the following.

[0068] A device (e.g., a WTRU) may receive first transmission configuration information from a network. The first transmission configuration information may indicate a first transmission configuration. The first transmission configuration may indicate a first mapping condition and / or a first mapping between a quality-of-service (QoS) flow and a first data radio bearer (DRB). The device may receive second transmission configuration information from the network. The second transmission configuration information may indicate a second transmission configuration. The second transmission configuration may indicate a second mapping condition and / or a secondmapping between the QoS flow and a second DRB. The device may determine that a condition is satisfied. The condition may be the first mapping condition or the second mapping condition. The device may select a transmission configuration from the first transmission configuration and / or the second transmission configuration based on the determination that the condition is satisfied. The device may transmit data based on the selected transmission configuration.

[0069] The satisfied condition may be the first mapping condition. The first mapping condition may be based on at least one of a QoS profile of the transmitted data, an application layer property, a data type, or a data attribute. The satisfied condition may be the first mapping condition, and / or the selection of the transmission configuration may be based on the second mapping condition not being satisfied. The first transmission configuration may further indicate a mapping between the first DRB and a first logical channel (LCH). The second transmission configuration may further indicate a mapping between the second DRB and a second LCH. The device may send, to the network, an indication of the selected transmission configuration. The satisfied condition may be the first mapping condition, and / or the first mapping condition may be based on a congestion status. The congestion status may be indicated in the first transmission configuration information or determined by the WTRU. The satisfied condition may be the first mapping condition, and / or the first mapping condition may be based on an energy savings state of the WTRU or an energy savings state of the network. The satisfied condition may be the first mapping condition, and / or the first mapping condition may be based on a dependency between a first PDU and a second PDU.

[0070] Systems, methods, and instrumentalities are described herein related to data treatment in the protocol stack (e.g., radio bearer based). A wireless transmit / receive unit (WTRU) may perform flexible and dynamic data routing / (re)mapping at service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), radio link control (RLC), and / or medium access control (MAC), e.g., utilizing a radio bearer concept associated with quality of service (QoS). A WTRU may perform flexible and dynamic mapping, remapping, and routing in the L2 stack, for example, based on a QoS profile of uplink (UL) traffic, different data types, and / or the attributes of the data. A WTRU may implement rules covering mapping from data unit to QoS flow, from QoS flow to data radio bearer (DRB), and from DRB to one or more logical channels (LCHs). A WTRU may be configured with soft QoS guarantees, for example, if / when one or more conditions are fulfilled.

[0071] Wireless system transport data streams may be associated with different services and / or applications. Data may be transported as different flows. A (e.g., each) service and / orapplication may transmit data associated with a plurality of flows. A (e.g., each) flow may be associated with a (e.g., specific) Quality of Service (QoS). Data units for different applications may be assigned to different flows or grouped together, e.g., according to different strategies. For example, video may be coded as base layer and enhancement layer. Different data units may represent different type of information for the decoding process (e.g., I-frame, B-frame, P- frames) and / or may represent different areas of the field of view (FoV) for a given user, for example. Applications may (e.g., further) use forward error correction (application layer forward error correction (AL-FEC)), for example, such that additional repair data may be available at the receiver, e.g., if needed, such as if / when a data unit may be lost or delayed beyond an acceptable amount of time at some point in the transmission path between transmitter and sender. Different AL-FEC algorithms may implement different strategies, for example, as described herein.

[0072] Data units from a given service and / or given application may be differentiated, for example, in terms of their impact to the quality of service (QoS) and / or quality of experience (QoE) of the end user. An impact may vary over time and / or may be dependent on the reception status of other, e.g., related, data units.

[0073] Data streams may be related to immersive services and / or extended Reality (XR). The term XR may be an umbrella term for different types of immersive experiences, including, for example, Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and the realities interpolated among the various types of immersive experiences. VR may be a rendered version of a delivered visual and / or audio scene. A rendering may be designed to mimic the visual (e.g., stereoscopic 3D) and / or audio sensory stimuli of the real world (e.g., as naturally as possible) to an observer or user as the observer or user moves within the limits defined by the application. AR may be when a user is provided with additional information, artificially generated objects / items, and / or content overlaid upon their current environment. MR may be an advanced form of AR where, for example, one or more virtual elements may be inserted into the physical scene, e.g., with the intent to provide the illusion that the elements are part of the real scene. XR may include (e.g., all) real-and-virtual combined environments and / or human-machine interactions generated by computer technology and wearables. The notion of immersion in the context of XR applications / services may refer to the sense of being surrounded by a virtual environment and / or providing the feeling of being physically and / or spatially located in the virtual environment. The levels of virtuality may range from partial sensory inputs to fullyimmersive multi-sensory inputs, which may lead to a virtual reality practically indiscernible from actual reality.

[0074] Traffic (e.g., in XR services and applications) may include data / protocol data units (PDUs), which may be associated with an application data unit (ADU), PDU set, or data burst. In an example, the PDUs belonging to a PDU set may be associated with different segments or components of a video frame or a video slice. A data burst may include one or more PDU sets that may be transmitted / received over a time window. For example, a number of PDUs in an PDU set or data burst transmitted in uplink (UL) and / or received in downlink (DL) may be dependent on the type of the media frame (e.g., 3D video frame, audio frame).

[0075] A WTRU (e.g., executing an XR application) may transmit XR traffic, which may include one or more PDUs / PDU sets in UL (e.g., pose, gesture, video data), and / or may receive XR traffic in DL (e.g., video, audio, haptics). Traffic may be transmitted and / or received periodically or aperiodically in one or more data flows (e.g., QoS flows). During UL transmissions, XR traffic may arrive from the application layer at a WTRU and / or from different devices / terminals / WTRUs (e.g., via sidelink, WiFi, or wired connection) at different time instances. XR traffic may be characterized by different attributes, such as variable payload sizes per PDU set, variable number of PDUs per PDU set, variable per-PDU / PDU set level importance, and / or different levels of inter-dependencies between PDUs / PDUs sets. XR traffic (e.g., PDU / PDU sets) received by a WTRU may (e.g., also) experience different delays, jitter, data rate, and / or loss rate. A QoS and / or high user experience (e.g., QoE) may be provided, for example, by performing data transmission / reception and / or other associated functions (e.g., prioritization, multiplexing, scheduling) on timely basis with XR awareness (e.g., awareness of PDU set attributes).

[0076] Application layer Forward Error Correction (AL-FEC) may be implemented. There may be different types of data output from an AL-FEC process, for example, depending on the encoding scheme at the codec.

[0077] For example, an FEC encoder may encode one or more data units and / or may output N coded data units, e.g., where any K coded data units out of N may be sufficient to successfully decode the initial data unit(s). N, and / or K may represent an equal or larger number than the number of data units used as input to the encoding process. N-K data units may (e.g., thus) be available to compensate, for example, if / when fewer than K coded data units are received at the receiver.

[0078] For example, K coded data units may be source PDUs. For example, N-K coded data units may be repair PDUs.

[0079] An application may generate data units that may be used as enhancement and / or mitigation of error propagation at the receiver.

[0080] There may be multiple application data types. Multiple AL-FEC data types may be described herein, which may be referred to as a data packet or PDU of the AL-FEC process. A packet / PDU type may refer, for example, to any one or more of the following: a source PDU, a repair PDU, and / or an enhancement PDU.

[0081] A source PDU may include a data unit. An application may successfully recover the initial application data, for example, if / when all source PDUs are received. For example, source PDUs may be used for successful decoding of application level data.

[0082] A repair PDU may be generated from a source PDU. A repair PDU may be used to reconstruct a source PDU. One or more repair PDU(s) may be considered redundant information, for example, if the corresponding source PDU(s) are received by the receiving application and / or if the repairs PDU(s) included application data that has been successfully decoded from the transmission of other PDUs (e.g., source PDUs).

[0083] An enhancement PDU may provide (e.g., additional) application-level information. A higher QoS and / or QoE may be achieved, for example, if / when enhancement PDU data is received by the application. An enhancement PDU may provide (e.g., to an application) error propagation mitigation, error concealment, and / or error recovery capabilities. An enhancement PDU may be generated (e.g., directly), for example, from an application encoding (e.g., video coded enhancement layer), from the one or more application level data units used as input to the AL-FEC encoding, or from source and / or repair PDUs. For example, an enhancement PDU may not be considered as critical (e.g., or mandatory) because the receiver may (e.g., be able to) determine / predict a missing enhancement PDU from another PDU (e.g., a source PDU). For example, a video frame delivered without any enhancement PDUs may still be considered as successfully delivered.

[0084] There may be dependencies between data units. For example, there may be dependencies between source and repair data units.

[0085] A repair data unit may be generated from a source data unit. The source:repair dependencies between the repair data unit and the source data unit may be characterized, for example, in any one or more of the following ways: 1 :1; 1 : 1 but not every source packet may generate a repair packet; 1 :M; and / or M: 1.

[0086] A source:repair dependency between the repair data unit and the source data unit may be characterized as 1 : 1. For example (e.g., in a 1 : 1 dependency), every source packet may generate a repair packet. For example (e.g., in a 1 : 1 dependency), there may exist a (e.g., direct) dependency between the source packet and the repair packet generated from the source packet.

[0087] A source:repair dependency between the repair data unit and the source data unit may be characterized as 1 : 1, but not every source packet may generate a repair packet. For example, a source packet may generate a repair packet. For example, a repair packet may be used to reconstruct the source packet it was generated from. For example, a repair packet may be used to reconstruct another source packet that it was not generated from, e.g., a source packet that is adjacent to the source packet it was generated from.

[0088] A source:repair dependency between the repair data unit and the source data unit may be characterized as 1 :M. For example (e.g., in a 1 :M dependency), a source packet may generate multiple repair packets. For example, one or more repair packets may be used to reconstruct the source packet. For example, multiple repair packets may be used to reconstruct the source packet.

[0089] A source:repair dependency between the repair data unit and the source data unit may be characterized as M: 1. For example, several source packets may be used to generate a repair packet. For example, the repair packet may be used to reconstruct any one or more of the source packets used to generate the repair packet.

[0090] Dependencies may be visible at the application in the WTRU. Dependency information may be available to the data transmission process in a transmitting device (e.g., a WTRU). For example, the WTRU (e.g., lower layers) may receive an indication of dependencies from the application layer.

[0091] There may be dependencies between source and enhancement data units. An enhancement data unit may be generated from a source and / or a repair data unit. Enhancement dependencies between the source and / or repair data unit and the enhancement data unit may be characterized, for example, in any one or more of the following ways: 1 : 1; 1 : 1 but not every source and / or repair packet may generate an enhancement packet; 1 :M; and / or M: 1.

[0092] Enhancement dependencies between the source and / or repair data unit and the enhancement data unit may be characterized as 1 : 1. For example (e.g., in a 1 : 1 dependency), every source and / or repair packet may generate an enhancement packet. For example, there may exist a (e.g., direct) dependency between the source and / or repair packet and the enhancement packet generated from the source and / or repair packet.

[0093] Enhancement dependencies between the source and / or repair data unit and the enhancement data unit may be characterized as 1 :1, but not every source and / or repair packet may generate an enhancement packet. For example, a source and / or repair packet may generate an enhancement packet. For example, an enhancement packet may be used to reconstruct the source and / or repair packet the enhancement packet was generated from. For example, an enhancement packet may be used to reconstruct another source and / or repair packet that the enhancement packet was not generated from, e.g., a source and / or repair packet that is adjacent to the source and / or repair packet it was generated from.

[0094] Enhancement dependencies between the source and / or repair data unit and the enhancement data unit may be characterized as 1 :M. For example, a source and / or repair packet may generate multiple enhancement packets. For example, one or more enhancement packet(s) may be used to reconstruct the source and / or repair packet. For example, multiple enhancement packets may be used to reconstruct the source and / or repair packet.

[0095] Enhancement dependencies between the source and / or repair data unit and the enhancement data unit may be characterized as M: 1. For example, several source and / or repair packets may be used to generate an enhancement packet. For example, the enhancement packet may be used to reconstruct any one or more of the source and / or repair packet(s) used to generate the enhancement packet.

[0096] Dependencies may be visible at the application in the WTRU. Dependency information may be available to the data transmission process in a transmitting device (e.g., a WTRU). For example, the WTRU (e.g., lower layers) may receive an indication of dependencies from the application layer.

[0097] Repair PDUs may be generated from the source PDUs, e.g., according to the FEC algorithm. The repair PDUs may help in the detection and / or correction of errors in the traffic stream. Repair PDUs may not be needed by the receiver, for example, if the receiver successfully receives all the source PDUs and they are all uncorrupted. However, if the receiver does not successfully receive any / some / all source PDUs, then the receiver may use the repair PDUs to recover the information that was included in the source PDUs that were not successfully received.

[0098] Packetization may be implemented. Applying any FEC algorithm may result in, for example, one or more of the following packetization options: data of different types ending up in different data units (e.g., one data unit including only source packets, another data unit includingonly repair packets) and / or data of different types ending up in the same data unit (e.g., one data unit including a ratio of two of more data units or type thereof).

[0099] A WTRU supporting an XR experience may be receiving data units (e.g., PDUs, PDU sets, data bursts, bitstreams) from higher layers or different devices, such as AR glasses and haptics gloves (e.g., via SL). The data units, which may have variable payload sizes, different periodicity, jitter, and / or different inter-dependencies, may be (e.g., further) processed and transmitted by the WTRU in the UL.

[0100] Operations related to capacity may include, for example, one or more of the following: multiple Configured Grant (CG) physical uplink shared channel (PUSCH) transmission occasions in a period of a single CG PUSCH configuration; dynamic indication of unused CG PUSCH occasion(s) based on Uplink Control Information (UCI) by the WTRU; buffer status report (BSR) including buffer status report (BSR) Table(s); delay reporting of buffered data in uplink; and / or discard operation of PDU Sets for UL.

[0101] Operations related to power savings may include, for example, one or more of the following: discontinuous reception (DRX) support of XR frame rates corresponding to noninteger periodicities (e.g., through at least semi-static mechanisms, such as Radio Resource Control (RRC) signaling).

[0102] Operations related to XR awareness may include, for example, one or more of the following: in the downlink, signaling by CN of semi-static information per QoS flow (e.g., PDU set QoS parameters), dynamic information per PDU set (PDU Set information and Identification), and / or End of Data Burst indication, and / or in the uplink, provisioning by WTRU of XR traffic assistance information, e.g., periodicity, UL traffic arrival information.

[0103] A Data Volume Calculation may be performed. In example wireless systems, a WTRU may determine the amount of data available for transmission, e.g., for the purpose of MAC buffer status reporting (BSR) and / or for the purpose of MAC delay status reporting (DSR). The WTRU may calculate the RLC data volume and / or the packet data convergence protocol (PDCP) data volume.

[0104] The RLC data volume for BSR may include, for example, one or more of the following: RLC SDUs and RLC SDU segments that may not have been included in an RLC data PDU;RLC data PDUs that may be pending for initial transmission; and / or RLC data PDUs that may be pending for retransmission (RLC AM).

[0105] The PDCP data volume for BSR may include, for example, one or more of the following: the PDCP service data units (SDUs) for which PDCP Data PDUs may not have beenconstructed; the PDCP Data PDUs that may not have been submitted to lower layers; the PDCP Control PDUs; for AM DRBs, the PDCP SDUs to be retransmitted; and / or for AM DRBs, the PDCP Data PDUs to be retransmitted.

[0106] The combined logic may ensure that a control plane or user plane data unit (e.g., IP packet) is reported once (e.g., not reported twice) for each layer, e.g., as a function of the unit’s processing state. The combined logic may (e.g., also) consider that any data that is considered under processing (e.g., by PDCP or RLC) may be reported in the BSR.

[0107] The PDCP data volume for DSR may include one or more of the following in a delay- critical PDCP data volume. The transmitting PDCP entity may, for example (e.g., for the purpose of MAC delay status reporting), consider one or more of the following as a delay-critical PDCP data volume: the delay-critical PDCP SDUs for which PDCP Data PDUs may not have been constructed; the PDCP Data PDUs that may include the delay-critical PDCP SDUs that may not have been submitted to lower layers; the PDCP Control PDUs; for AM DRBs, the PDCP SDUs to be retransmitted (e.g., as may be described herein); for AM DRBs, the PDCP Data PDUs to be retransmitted (e.g., as may be described herein).

[0108] A PDCP may indicate to a lower layer (e.g., if / when a PDCP SDU becomes delay critical) whether / if a corresponding PDCP Data PDU has been submitted to lower layers.

[0109] The RLC data volume for DSR may include, for example, one or more of the following in a delay-critical RLC data volume: delay-critical RLC SDUs and delay-critical RLC SDU segments that may not have been included in an RLC data PDU; RLC data PDUs pending for initial transmission, which may include a delay-critical RLC SDU or a delay-critical RLC SDU segment; RLC data PDUs that may be pending for retransmission (RLC AM).

[0110] The combined logic may ensure that the a control plane or user plane data unit (e.g., IP packet) is reported once (e.g., not reported twice) for each layer, e.g., as a function of the unit’s processing state and / or contents. The combined logic may (e.g., also) consider that any data that may be considered under processing (e.g., by PDCP or RLC) that may be delay critical may be reported in the DSR. The combined logic may (e.g., also) consider as delay critical data units that may be retransmitted or pending retransmission.

[0111] Logical Channel Prioritization may be applied. In examples of current wireless systems, a logical channel prioritization (LCP) procedure may be applied if / when a new transmission is performed.

[0112] A WTRU may determine what data units to multiplex in a transport block for uplink transmission, for example, by (e.g., first) selecting the logical channels applicable to the newtransmission according to one or more conditions (e.g., also referred to as “mapping restrictions”), which may include, for example, if data associated with a logical channel can be transmitted with respect to a configured restriction, such as the allowed subcarrier spacing, the PUSCH transmission duration, the type of configured grant, the allowed serving cell, the allowed cell group, the priority index associated with the dynamic UL grant and the allowed hybrid automatic repeat request (HARQ) mode, etc. A WTRU may select the logical channel (LCH) for the next step of the LCP procedure, for example, if a logical channel’s configuration allows associated data be included in the transport block associated with the transmission resources. RRC may control the conditions, for example, by configuration of the MAC parameters, LCH configuration, and / or logical channel group (LCG) configuration.

[0113] A WTRU may multiplex data from a selected LCH(s), for example, in decreasing priority order, e.g., where data amount from each LCH may be multiplexed up to their Bj value, which value may be based on the LCH’s configured Prioritized Bit Rate (PBR) and / or Bucket Size Duration (BSD). For example, Bj may be equal to PBR multiplied by BSD (e.g., Bj = PBR x BSD). Bj may be decremented by the total size of data multiplexed.

[0114] The WTRU may (e.g., if any resource remains) multiplex data from a selected LCH(s) (e.g., in decreasing priority order), regardless of the value Bj, for example, until (e.g., all) the data for the LCH is exhausted or until the resources of the grant are exhausted. LCHs of equal priority may be served equally.

[0115] A PDU set may be composed of one or more PDUs carrying the payload of a (e.g., one) unit of information generated at the application level (e.g., a frame or video slice for XRM Services). In some examples, (e.g., all) the PDUs in a PDU Set may be utilized by the application layer to use the corresponding unit of information. In some examples, the application layer may recover one or more parts or all or of the information unit if / when one or more PDUs are missing. For the uplink, the identification of PDU sets, data bursts, and / or PDU Set Importance (PSI) may be left to WTRU implementation.

[0116] For a PDU Set in a QoS flow for which the PDU set Integral handling indication (PSIHI) is set, one or more (e.g., all) remaining PDUs of the PDU Set may be discarded at the transmitter (e.g., to free up radio resources), for example, if / when a (e.g., one) PDU of the PDU set is known to be lost or associated with a discarded SDU.

[0117] PDU Set Delay Budget (PSDB) may be the time between reception of the first PDU (e.g., at the UPF in DL, at the WTRU in UL) and the successful delivery of the last arrived PDUof a PDU Set (e.g., at the WTRU in DL, at the UPF in UL). PSDB may be an optional parameter. The PSDB (e.g., if / when provided) may supersede the packet delay budget (PDB).

[0118] The semantics of the fields of the real-time transport protocol (RTP) Header Extension for the marking of PDU Set and End of Bursts in the downlink may be defined, for example, based on one or more of the following: the end PDU of a PDU set [E] may be one bit; an End of Data Burst (EDB) may be three (3) bits; PDU Set Importance (PSI) may be four (4) bits; PDU Set Sequence Number (PSSN) may be ten (10) bits; PDU Sequence Number within a PDU Set (PSN) may be six (6) bits; and / or PDU set size (PSSize) may be 24 bits.

[0119] An End PDU of the PDU Set [E] field may be a flag that may be set, for example, to one (1) for the last PDU of the PDU Set and / or set to zero (0) for (e.g., all) other PDUs of the PDU Set.

[0120] An End of Data Burst (EDB) field may indicate the end of a Data Burst. The (e.g., 3) bits may encode the End of Data Burst indication, e.g., according to encoding and guidelines as may be described herein.

[0121] A PSI field may indicate the importance of the PDU Set compared to other PDU Sets within the same QoS flow. Lower values may indicate a higher importance PDU Set. For example, the highest importance PDU Set may be indicated by zero (0) and the lowest importance PDU Set may be indicated by a higher number (e.g., 15).

[0122] A PSSN field may encode the sequence number of the PDU Set to which the current PDU belongs (e.g., acting as a (10-bit) numerical identifier for the PDU Set).

[0123] A PSN may represent the sequence number of the current PDU within the PDU Set. For example, the PSN may be set to zero (0) for the first PDU in the PDU Set and may be incremented (e.g., monotonically) for every PDU in the PDU set in order of transmission from the sender.

[0124] A PSSize may indicate the total size of (e.g., all) PDUs of the PDU Set to which the PDU belongs. The PSSize field may be optional. The PSSize field may be subject to an SDP signaling offer / answer negotiation, for example, where the Application Server may indicate whether it will (e.g., be able to) provide the size of the PDU Set for the RTP stream. If not enabled, the PSSize field may not be present. If enabled, but if the Application Server is not able to determine the PDU Size for a particular PDU Set, the PSSize field may set the value (e.g., to zero (0)) in (e.g., all) PDUs of the PDU Set. The PSSize may indicate the size of a PDU Set, which may include RTP / UDP / IP header encapsulation overhead of corresponding PDUs. The PSSize may be expressed in bytes.

[0125] A (e.g., current) protocol stack may have, for example, one or more of the following limitations: one QoS flow may be mapped onto only one DRB at a time in the UL; remapping of QoS flow to DRB via RRC may be slow; differentiation between signaling radio bearers (SRBs) and data radio bearers (DRBs) may be rigid and static; the number of radio bearers may be too limited for newer applications (e.g., volumetric video on demand, live streaming, artificial intelligence (AI) / machine learning (ML), etc.); all packets in a DRB may receive the same QoS treatment; mapping of DRBs to LCHs may be 1 : 1; the QoS framework may be rigid / inflexible with preconfigured mappings; and / or QoS guarantees may be limited to hard QoS guarantees and no QoS guarantees (e.g., no allowance for soft / flexible QoS guarantees).

[0126] A (e.g., current) L2 system / protocol stack may be rigid and static / semi- static. Treatment of QoS may be achieved by assigning data to a radio bearer, then collectively treating all data from the bearer similarly by configuring parameters for the radio bearer. There is a lack of flexible rules / routing with current configuration and mapping rules. Differentiated treatment within a (e.g., one) QoS flow may not be allowed, even though different data types may be mapped to one QoS flow. Different data types may require differentiated treatment in the stack (e.g., user plane data, control plane data, system data, AI / ML data, sensing data, etc.). Within user plane data, N of K (e.g., N / K) packets of a data unit may be required for successful decoding. QoS guarantees may be hard / ab solute. Adaptations to changes in radio conditions may be semi-static.

[0127] Differentiated, dynamic, and more flexible treatment of data within a QoS flow may be implemented, for example, by considering different data types.

[0128] A 1 :N mapping may be implemented between QoS flows and DRBs (data sets), for example, based on one or more of the following: QoS profile (e.g., reliability, latency bounds); data type (e.g., control plane (CP), user plane (UP), Positioning, XR, etc.); Packet importance; interdependencies (e.g., video flow and audio flow may have dependencies resulting in them being mapped to the same QoS flow, and, e.g., differentiated treatment via remapping to different radio bearers (RBs));different packets from a QoS flow may have different treatment; SDAP may add dynamic markings to packets based on the QoS profile of the data (e.g., avoid rigid mapping); and / or WTRU may receive a configuration from NW on mapping rules (e.g., determine data to radio resource mapping based on data profile).

[0129] Flexible forwarding / treatment of packets may be implemented in L2, for example, based on data set characteristics (e.g., in contrast to rigid mapping to control channels). Prioritization (e.g., UP data may be prioritized over CP data in some cases / scenarios) may beimplemented, for example, based on one or more of the following: importance; remaining time; data type; prioritization rules, conditions, and / or exceptions. Data types may include, for example, CP data, UP data, system data (e.g., sensing data), AI / ML data, etc. Signaling channels / SRBs may be different, for example, based on an end point of an AI / ML data / server (e.g., third party server versus 3 GPP based server). Data of the same type may be aggregated / concatenated, for example, depending on the data type. A subset of data may be accessible to an external server while other another subset of data may not be accessible to an external server. There may be a drawback from prioritizing UP data over CP data, for example, based on rules, conditions, and / or exceptions.

[0130] Bearers may be shared between SRBs and DRBs, which may increase the number of bearers and provide more granular treatment. A (e.g., one) PDCP entity may handle / treat data of different types / profiles. A higher number of radio bearers may be configured to accommodate a wider range of services with a larger granularity in QoS.

[0131] In some examples, splitting may be allowed. For example, a DRB may be split into M LCHs. There may be different forwarding treatment of the data (e.g., different to PDCP duplication - DC and CA).

[0132] In some examples, an LCH may be propagated to upper layers with more granularity, allowing flexibility to create as many LCHs as may be needed within a radio bearer (e.g., an LCH ID may carry the treatment of the packet). Different layers may provide different treatment, for example, based on LCH ID. For example, an LCH ID assigned at SDAP may be applied (e.g., may trickle down) to every layer. Each layer may provide the treatment accordingly.

[0133] In some examples, data set and / or data type may be mapped to LCHs and / or an LCG within a radio bearer.

[0134] Soft QoS guarantees may be used, e.g., instead of relying on only hard, absolute QoS guarantees. Soft QoS guarantees may be used to indicate a range of values for QoS attributes (e.g., a range for latency, data rate, reliability, such as packet error rate, etc.). An adaptive QoS framework with soft QoS guarantees may include, for example, one or more of the following: adaptiveness based on channel conditions; network configuration of WTRUs; dynamic mapping; flexible properties, etc.

[0135] Adaptiveness for properties, such as QoS, may be based on channel conditions, e.g., low reference signal received power (RSRP). Adaptiveness may address congestion, which maybe WTRU detected and / or NW indicated. Adaptiveness may address WTRUs in bad coverage (e.g., cell edge).

[0136] A WTRU may receive a configuration from the NW to perform mappings (e.g., as described herein) in two or more settings, where an uncongested NW / WTRU with good coverage may provide an upper bound and a congested NW / WTRU with poor coverage may provide a lower bound.

[0137] Mapping may include mapping QoS flow to DRB and / or mapping DRB to LCH, for example, to provide more flexible and dynamic operation based on current / prevailing conditions.

[0138] Properties of channels / data pipes (e.g., QoS flow, DRB, LCH) may be flexible. For example, properties may include one or more of the following: hard QoS guarantees; no QoS guarantees; and / or soft QoS guarantees (e.g., QoS met when conditions allow).

[0139] A WTRU may receive, from a network (NW), one or more (e.g., at least two) configurations (e.g., the WTRU may receive an indication of a first transmission configuration and / or a second transmission configuration). The configuration(s) (e.g., each of the configurations) may include, for example, flexible QoS flow to DRB mapping rules and / or flexible DRB to LCH routing rules (e.g., respective flexible QoS flow to DRB mapping rules and / or flexible DRB to LCH routing rules). One or more QoS bounds may be provided. In some examples, QoS bounds may be provided for one or more of the following scenarios: uncongested NW / WTRU with good coverage (e.g., upper QoS bound); and / or congested NW / WTRU with poor coverage (e.g., lower QoS bound). The WTRU may determine the configuration (e.g., among multiple configurations) to apply, for example, based on current / prevailing conditions (e.g., determined via buffer status monitoring, a QoS profile of the data transmission, an application layer property, a data type, a data attribute, an absence of a second mapping condition being satisfied, a congestion status, an energy savings state of the WTRU, an energy savings state of the NW, a dependency between a PDU and a PDU set, and / or the like as described herein). The WTRU may (e.g., alternatively) receive an indication of congestion from the NW, e.g., to determine which configuration to apply. The WTRU may send an indication to the NW on the selected configuration. The WTRU may activate the selected configuration. The WTRU may map the QoS to a DRB according to the activated configuration. The WTRU may transmit / receive data according to the activated configuration.

[0140] A data unit may include, for example, any one or more of the following: an IP packet and / or a system data unit (e.g., sensing, positioning and / or computing data); a bit and / or group thereof; bytes and / or group thereof; PDU segment and / or group thereof; a PDU; a group / set ofPDUs (e.g., PDU set); a set of PDUs that may be considered as one unit at the application, e.g., set of PDUs corresponding to a frame; a group of PDU sets; a data burst; a group of data bursts; a flow; and / or a group of flows.

[0141] As described herein, a “data unit” may refer to one data unit, a group of data units, a component of a data unit (e.g., a portion of one data unit), and / or a type of data unit (e.g., a group of one or more data units of one type).

[0142] Type of data units (e.g., as described herein) may refer to one or more (e.g., any) characteristic of the data unit, e.g., whether attributed by the application and / or the WTRU. Types of data units may include, for example, any one or more of the following: repair / source / enhancement data units; primary / secondary / tertiary data units; mandatory / non- mandatory data units; needed for QoS and / or QoE enhancement (e.g., repair data units, enhancement data units); not needed for either QoS or QoE enhancement); needed (e.g., only) for QoS enhancement; needed (e.g., only) for QoE enhancement, does not necessarily impact QoS (e.g., an enhancement data unit); low delay budget data units (e.g., PSDB and / or PDU set delay deadline (PSDD) below a certain / threshold value for PDU set); high delay budget data units (e.g., PSDB and / or PSDD below a value for PDU set); low error rate data units (e.g., PER and / or PDU set error rate (PSER) set below a value for PDU set); high error data units (e.g., PSER above a value for PDU set); data units of an importance value or above; data units of an importance value or below; control plane data units; data units for sensing; data units for positioning; system data units; data units pertaining to RF based systems; data units pertaining to non-RF based systems; data units corresponding to an artificial intelligence (AI) / machine learning (ML) system; user plane data; and / or any of the data as may be described herein (e.g., control plane data, sensing data, positioning data, system data, and so on) that may be used by (e.g., critical for) a user plane service to work.

[0143] Group of data units may refer to a group of data units of a (e.g., one) type. In some examples, a first group of data units may refer to a group of mandatory packets while a second group of data units may refer to a group of repair packets. “Data units” may refer to a group of data units.

[0144] PDU Set Delay Budget (PSDB) may refer to the time between reception of the first arrived PDU of a PDU set (e.g., at the UPF in DL, at the WTRU in UL) and the successful delivery of the last arrived PDU of the PDU Set (e.g., at the WTRU in DL, at the UPF in UL). PSDB may be an optional parameter. PSDB (e.g., when provided) may supersede the PDB. Similarly, the delay budget of a data unit may be the time between reception of the first bitand / or packet of the data unit (e.g., at the UPF in DL, at the WTRU in UL) and the successful delivery of the last arrived bit and / or packet of the data unit (e.g., at the WTRU in DL, at the UPF in UL). The delay budget of a data unit (e.g., when provided) may supersede the PDB.

[0145] PSER may refer to (e.g., define) an upper bound for a rate of non-congestion related PDU Set losses between the RAN and the WTRU. Similarly, the error rate of a data unit may refer to (e.g., define) an upper bound for a rate of non-congestion related losses of packets and / or bits within a data unit between the RAN and the WTRU.

[0146] PSIHI may indicate whether all PDUs of the PDU Set may be needed for the usage of PDU Set by the application layer. A similar concept may be applied to a data unit, whereby an indicator may be used to determine whether all bits and / or packets of the data unit may be needed for the usage of the data unit by the application layer.

[0147] Remaining delay may refer to the time duration remaining for receiving or transmitting one or more PDUs of a data unit before the expiry of the delay budget of the data unit.Remaining delay may also be referred to as the time to live (TTL) associated with a data unit.

[0148] Data units may have attributes, characteristics, and / or properties.

[0149] A data unit may comprise of one or more packets and / or bits (e.g., PDUs). In some examples, the packets and / or bits may be associated with a media unit or a video frame / slice. The bits / packets within a data unit or data burst may be inter-dependent with each other at the application layer and / or lower layers (e.g., access stratum (AS)-layers).

[0150] The attributes / properties of a data unit may be different from the attributes / properties of other data units, for example, in terms of the number of PDUs in the data unit, payload sizes of the data unit, correlation within bits / packets of the data unit, correlation with bits / packets of other data units, importance / priority of the data units, status of transmission (e.g., percentage of PDUs of one or more data units transmitted / received successfully), effective data rate, and / or effective reliability associated with transmission.

[0151] The attributes associated with data units may be visible at one or more lower layers (e.g., at PDCP, RLC, MAC, PHY sub-layers / layers), for example, to support additional actions (e.g., prioritizing, mapping to an LCH and / or LCG, multiplexing into one or more TBs, scheduling). The visibility of attributes associated with data units may be based on, for example, one or more of the following: markings in the data units; reception of an indication such as a control PDU; mapping of the data units from a higher layer to a configuration associated with a lower layer; tracking of the attributes of the bits / packets / data units at any buffer associated with sublayer, radio bearer logical channel or HARQ processes; and / or restrictions associated with thesublayer, radio bearer, logical channel and / or HARQ process to which the packets of data units may be mapped to.

[0152] The visibility of attributes associated with data units may be based on markings in the data units. Markings may include, for example, sequence numbers, IDs, indexes, timestamps, and / or time offset values (e.g., with respect to a reference time) in the header of data units. Markings may be made by higher layers, a preceding sub-layer / layer, or another device / WTRU.

[0153] The visibility of attributes associated with data units may be based on reception of an indication, such as a control PDU (e.g., application / higher / NAS layer indication, PDCP control PDU, RLC control PDU, MAC CE, DCI / UCI). An indication may be received by a WTRU, for example, from a higher / preceding layer, from another device / WTRU (e.g., over SL), and / or from a network.

[0154] The visibility of attributes associated with data units may be based on a mapping of the data units from a higher layer to a configuration associated with a lower layer. For example, the WTRU may have visibility of higher layer attribute(s) at a lower layer when mapping the bits / packets / data units to one or more radio bearers, logical channels (LCHs), LCG, TBs, or HARQ processes that may be configured to provide similar forwarding treatment.

[0155] The visibility of attributes associated with data units may be based on tracking of the attributes of the bits / packets / data units at a (e.g., any) buffer associated with sublayer, radio bearer logical channel, or HARQ processes. For example, the WTRU may track the attributes associated with a data unit based on one or more of the following: the time elapsed since the reception of a first packet of a data unit, the remaining time for the packets of a data unit for meeting corresponding delay budget, jitter between the arrival one or more PDUs / bits within / across data units, and / or the percentage / payload size of remaining packets / bits of a data unit expected to be received.

[0156] The visibility of attributes associated with data units may be based on restrictions associated with one or more of the following: the sublayer, radio bearer, logical channel, and / or HARQ process to which the packets of data units may be mapped to. For example, the WTRU may have visibility of the data units and determine the corresponding actions (e.g., perform prioritization per LCP, perform mapping to restricted CG configurations, TBs, HPIs) based on the configured restrictions that may be associated with the one or more sublayers, radio bearers, and / or LCHs to which the data units may be mapped to.

[0157] A data burst may refer to the data produced by the application in a short period of time. A data burst may comprise packets from one or more data units. The attributes, associations,and / or inter-dependencies (e.g., intra-data unit and / or inter-data unit), including, for example, the start / end indication of a data unit (e.g., via sequence number, start / end indication, timestamp), start / end time, duration, payload sizes, periodicity, importance / priority, and / or QoS (e.g., corresponding delay budget) may be visible to the AS layers (e.g., with associated IDs) and / or may be handled at the AS layers with the awareness of the association during data transmission in UL and reception in DL.

[0158] Data (e.g., packets of data) in data units may be associated with an application, high layer importance, and / or priority values. The different packets in a data unit (e.g., or all packets in a data unit) may be associated with different importance / priority values. The importance value may correspond to spatial importance (e.g., spatial position of the video frame whose data is carried by the data unit, where packets carrying FoV spatial positions may be associated with higher spatial importance than non-FoV spatial positions) or temporal importance (e.g., time sequence of the video / application frame whose data is carried by the packets, where packets carrying base video frames, such as I-frames, may be associated with higher temporal importance than differential video frames, such as P-frame / B-frame). Importance values may be visible to the AS layers during data transmission and reception.

[0159] Data units may be transmitted / received in QoS / data flows. The packets of an application may be encoded and delivered by an application to a WTRU (in UL) or network (in DL), for example, via one or more QoS / data flows. The different QoS flows carrying the data units associated with an application / experience may be visible to the AS layers and / or handled at the AS layers with the awareness of the association during data transmission and reception.

[0160] Radio bearers (RBs) may refer to data radio bearers (DRBs), signaling radio bearers (SRBs), and / or RBs that may be configured to serve any type of data unit (e.g., irrespective of whether they may be control plane signaling or user plane data).

[0161] Jitter may refer to variation with respect to an expected time instance during which one or more data units may be received or transmitted. For example, for a set of data units that may be expected to be received periodically at different periodic time instances, jitter may refer to variation with respect to the periodic time instances (e.g., for a data unit that may be received T1 ms in advance or T2 ms later than an expected time instance at T, such that the jitter range may be T2 - Tl). Jitter may refer to an instantaneous value or a statistical value (e.g., average, variance, standard deviation, max / min).

[0162] A WTRU may receive a configuration from the network (e.g., the WTRU may receive an indication of transmission configuration information from the NW). A WTRU may receive aconfiguration for flexible and dynamic mapping / routing. A WTRU may receive configuration from the NW that allows for flexible and dynamic mapping, remapping, and / or routing in the L2 stack. A configuration may include, for example, any one or more of the following: configuration for mapping of one or more QoS flow(s) to one or more RB(s); configuration for (e.g., dynamically) remapping of one or more QoS flow(s) to one or more RB(s) (e.g., due to late arrival of a data unit or part / component / group thereof, and / or, e.g., due to late arrival of a dependent data unit or part / component / group thereof); configuration for mapping of one or more RBs to one or more LCH(s) / LCG(s); configuration of one or more RLC and / or PDCP entities associated with a RB; and / or configuration of conditions for (e.g., dynamically) remapping of one or more RB(s) to LCH(s) / LCG(s) (e.g., due to late arrival of a data unit or part / component / group thereof, and / or e.g., due to late arrival of a dependent data unit or part / component / group thereof).

[0163] A WTRU may receive configuration and / or reconfiguration rules and / or conditions for mapping, (e.g., dynamically) remapping, routing, and / or rerouting from one entity to another. The (re)configuration rules and / or conditions may include, for example, mapping from data units to QoS flow, mapping from QoS flow to DRB, mapping from DRB to LCH / LCG / RLC / PDCP entity, and / or mapping data from an LCH / LCG to a MAC PDU.

[0164] The WTRU may apply a first mapping (e.g., a default mapping) of a QoS flow to a DRB and / or a protocol chain stack within the WTRU, for example, if a rule is not met. The WTRU may apply a second mapping (e.g., a non-default mapping) of a QoS flow to a DRB and / or a protocol chain stack, for example, if a rule is met (e.g., if a mapping condition is satisfied).

[0165] Configuration and / or reconfiguration rules for mapping, (dynamically) remapping, routing, and / or rerouting from one entity to another (e.g., that the WTRU may receive from the NW) may be based on, for example, any one or more of the following: QoS profile of UL traffic; data type; data attribute; interdependencies between flows and / or data units (e.g., a dependency between a PDU and a PDU set); congestion status; whether successful delivery of data unit or part / group / component thereof impacts QoS; reception of an indication from the network to apply a given mapping / configuration for one or more data flows; energy saving state of the WTRU or the network; reception of an indication from higher layers; satisfying one or more control plane event; synchronization between data flows; measuring a channel condition below or above a given threshold; measuring a change in the channel conditions below or above a given threshold; and / or reception or successful reception of a dependent data unit on the downlink.

[0166] (Re)configuration rules for (re)mapping and / or (re)routing may be based on a QoS profile of UL traffic, e.g., reliability, latency bounds (e.g., delay budgets, remaining time with respect to delay budgets), tolerable error bounds (e.g., packet error rate, PDU set error rate), e.g., when the reliability required for the data may be below and / or above a threshold. In some examples, the WTRU may apply a (e.g., one) mapping if there is a possibility of transmission / inclusion of buffered data from a subset of PDUs within a PDU set, e.g., where the remaining time until the delay budget for the PDU or the underlying application may be less than a threshold.

[0167] (Re)configuration rules for (re)mapping and / or (re)routing may be based on application layer properties, e.g., forward error correction (FEC) related parameters. For example, N out of K packets may be needed for successful decoding of a frame by the application. After N packets have been received, the WTRU may be configured to remap / reroute the remaining (K-N) packets to a lower priority DRB. For example prior to successful reception of N packets (e.g., which may be confirmed via feedback from the network), the WTRU may apply a different mapping between the QoS flow to an RB.

[0168] (Re)configuration rules for (re)mapping and / or (re)routing may be based on a data type (e.g., CP data, UP data, positioning data, XR data, haptics data, AI / ML data, sensing data, system data, etc.). For example, a WTRU may receive a configuration to map QoS flows to DRB(s) based on the type of data being carried by the QoS flow.

[0169] (Re)configuration rules for (re)mapping and / or (re)routing may be based on a data attribute (e.g., packet importance, PDU set importance, importance of PDU within the PDU set, priority of packet / data units). For example, a WTRU may receive a configuration to map QoS flows to DRB(s) based on the data attribute of the data being carried by the QoS flow.

[0170] (Re)configuration rules for (re)mapping and / or (re)routing may be based on interdependencies between flows and / or data units. For example, a video flow and audio flow may have dependencies resulting in both flows being mapped to the same QoS flow. However, the video flow and audio flow may require differentiated treatment based on the higher data rate of the video flow, for example. As a result, the WTRU may receive a configuration to map the video packets and the audio packets to different radio bearers. For example, the WTRU may apply a (e.g., one) non-default mapping / configuration when a dependent PDU is received or transmitted.

[0171] (Re)configuration rules for (re)mapping and / or (re)routing may be based on a congestion status. For example, a WTRU may receive a configuration to map QoS flows toDRB(s) and / or to map DRB(s) to LCH(s) / RLC entity(ies) based on the congestion status at the NW and / or at the WTRU. A congestion status at the NW may be indicated to the WTRU from the NW and / or may be determined (e.g., inferred) by the WTRU. A congestion status may be determined (e.g., inferred), for example, via the number / frequency / occurrences of negative acknowledge messages that may be received at the WTRU (e.g., HARQ negative acknowledgement (NACK)). For example, a congestion status may be determined (e.g., inferred) if the number of negative acknowledgement messages is above a preconfigured threshold. A congestion status may be determined (e.g., inferred), for example, via the number / frequency / occurrences of positive acknowledge messages received at the WTRU (e.g., HARQ ACK, RLC AM status reports, PDCP status reports, etc.). For example, a congestion status may be determined (e.g., inferred), if the number of positive acknowledgement messages is below a preconfigured threshold. A congestion status may be determined (e.g., inferred), for example, via the amount of grants provided by the NW to the WTRU. For example, a congestion status may be determined (e.g., inferred) if the amount and / or size of grants is lower / smaller compared to what the WTRU may have requested from the NW (e.g., in a BSR).

[0172] For example, a congestion status at the WTRU may be indicated based on buffer status / level monitoring at the WTRU. For example, if any one or more of the L2 buffers is filled at greater than a preconfigured threshold (e.g., greater than 95%, for example), there may be congestion at the WTRU, e.g., due to pre-processing / processing / post-processing at any one or more sublayers.

[0173] (Re)configuration rules for (re)mapping and / or (re)routing may be based on whether successful delivery of data unit or part / group / component thereof impacts QoS. For example, successful delivery of some packets, e.g., enhancement packets, may improve the QoE of the session, but may not impact the QoS. The WTRU may be configured to select a DRB and / or LCH / LCG accordingly.

[0174] (Re)configuration rules for (re)mapping and / or (re)routing may be based on reception of an indication from the network to apply a given mapping / configuration for one or more data flows (e.g., in a DCI or a MAC CE).

[0175] (Re)configuration rules for (re)mapping and / or (re)routing may be based on an energy saving state of the WTRU and / or the network. For example, the WTRU may apply one mapping / configuration when the WTRU is in an energy saving state (e.g., or if the WTRU is indicated to be activated with an energy saving state) and may apply another mapping / configuration when the WTRU is in a normal (e.g., non-energy efficient state). Anenergy efficient state may be any state where the WTRU and / or the network is employing at least one energy saving mechanism (e.g., discontinuous reception (DRX), multiple input multiple output (MIMO) reduction, power reduction, cell on / off, reception of a low energy saving signal / structure).

[0176] (Re)configuration rules for (re)mapping and / or (re)routing may be based on reception of an indication from higher layers (e.g., the application or the RAN-application programming interface (API)). For example, the application may indicate that, for a given QoS flow, a different QoE level may be required, and / or the WTRU may determine to apply a different mapping / configuration based on reception of the indication. The Indication may provide a given QoS class or an identifier associated with the QoS class.

[0177] (Re)configuration rules for (re)mapping and / or (re)routing may be based on satisfying one or more control plane events (e.g., satisfying one or more mobility event condition, satisfying a conditional handover condition to one or more handover candidate). For example, upon satisfying a mobility, an RLM, a beam failure, or an RLF, the WTRU may map a QoS flow to a different RB (e.g., DRB), e.g., for a period of time associated with the CP event.

[0178] (Re)configuration rules for (re)mapping and / or (re)routing may be based on synchronization between data flows. For example, synchronization between data flows may be configured or indicated from the application or the core network. The WTRU may map the data flows to the same RB (e.g., DRB) or may use an alternative QoS to DRB mapping, for example, if / when the data flow is synchronized or within a period of synchronization (e.g., if / when a remaining synchronization time is larger or lower than a (pre)configured threshold).

[0179] (Re)configuration rules for (re)mapping and / or (re)routing may be based on measuring a channel condition below or above a given threshold. (Re)configuration rules for (re)mapping and / or (re)routing may be based on measuring a change in the channel conditions below or above a given threshold.

[0180] (Re)configuration rules for (re)mapping and / or (re)routing may be based on reception or successful reception of a dependent data unit on the downlink (e.g., on a Physical Downlink Shared Channel (PDSCH)), for example (e.g., only) from an associated data flow by configuration.

[0181] If the WTRU changes the mapping of a QoS from one DRB to a second DRB, and the second DRB belongs to a different base station or a different protocol chain stack, the WTRU may apply a different configuration associated with the second DRB, e.g., including for integrityprotocol, header encoding, etc. The WTRU may (e.g., further) indicate the mapping configuration associated with the transmitted PDU.

[0182] A WTRU may receive one or more configurations for congestion and / or noncongestion. In some examples, the WTRU may receive (e.g., from the NW) two sets of configuration, e.g., one set for congestion and one set for non-congestion. In some examples, the WTRU may receive, e.g., from the NW, multiple sets of configurations pertaining to different levels of congestion that may be prevailing. Each set of configuration may include rules for mapping / remapping / routing / rerouting data from one entity and / or sublayer to another based on the congestion status at the WTRU and / or NW. Each configuration may be based on a set of rules that may be adapted to the congestion status of the WTRU and / or NW. For example, the WTRU may receive different configuration / mapping rules for mapping from data units to QoS flow, mapping from QoS flow to DRB, mapping from DRB to LCH / LCG / RLC entity, and / or mapping data from an LCH / LCG to a MAC PDU based on the congestion status at the NW. For example, in a non-congested scenario, the WTRU may be configured to map data units of priority 1 and 2 to DRB 1 while in a congested scenario, the WTRU may be configured to (e.g., only) map data units of priority 1 to DRB 1.

[0183] A WTRU may receive a configuration from the NW to apply for a time. In some examples, the WTRU may be configured with a default configuration that may be applied (e.g., at all times, unless the WTRU receives an indication from the network to apply a different configuration). In some examples, a different or non-default configuration may come with a time interval for when the configuration may be applicable. In some examples, applicability of a configuration may be an explicit time duration signaled to the WTRU by the NW, e.g., during RRC (re)configuration. In some examples, applicability of a configuration may be an implicit time duration. For example, configuration applicability may be based on a WTRU measurement of congestion versus non-congestion radio environment. The WTRU may activate the nondefault configuration, for example, (e.g., only) when the WTRU detects congestion and / or congestion levels above a certain (pre)configured metric (e.g., as may be indicated by the NW).

[0184] A WTRU may receive a configuration for a radio bearer. In some examples, a WTRU may receive a radio bearer configuration, e.g., as part of RadioBearerConfig, which may allow the network to establish, modify, and / or release radio bearers for the WTRU. In some examples, a WTRU may receive a configuration during RRC (re)configuration. In some examples, a WTRU may receive a configuration periodically, e.g., with periodicity configured by the network. In some examples, a WTRU may receive a configuration after sending a request forthe configuration to the NW. The request to the NW may include, for example, any one or more of the following: a request for additional radio bearers; a request to modify existing radio bearers; a request to release existing radio bearers; a traffic profile of UL traffic, e.g., traffic periodicity, data rates, traffic flows (e.g., video / haptics / audio flow), latency / delay requirements of traffic (e.g., PDB / PSDB / PSDD / remaining time of data unit, etc.); new parameters (e.g., higher number of radio bearers to provide finer granularity, priority of radio bearer) needed based on traffic profile.

[0185] A radio bearer configuration procedure may allow the network to control the radio bearers that may be used by the WTRU to meet the QoS and / or service requirements. In some examples, a radio bearer configuration procedure may be part of RRC connection establishment, reconfiguration, and / or mobility procedures. In some examples, a radio bearer configuration procedure may be sent to the WTRU any time (e.g., in a MAC CE, DCI).

[0186] A WTRU may be configured with radio bearers for carrying signaling information and data. In some examples, a WTRU may be configured with one type of radio bearers for signaling, e.g., signaling radio bearers (SRBs) (e.g., to send RRC messages or NAS messages) and another type of radio bearers for carrying data traffic, e.g., data radio bearers (DRBs).

[0187] In some examples, a WTRU may be configured with one or more radio bearers that may be used for carrying signaling information and / or data traffic. For example, a WTRU may (e.g., be able to) share bearers between SRBs and DRBs. The WTRU may use the total number of bearers to provide a more granular treatment to the data in the WTRU’s buffer according to the UL traffic characteristics and / or data unit properties, e.g., irrespective of whether the data is a control plane data or a user plane data. The one or more radio bearers may allow the network to control the data treatment in the WTRU (e.g., radio bearer configured according to QoS profile of the one or more QoS flows) and / or to control other parameters (e.g., PDCP configuration, security parameters, etc.).

[0188] The configuration may imply that the PDCP may need to be capable of handling / treating data of different types and / profiles. For example, the PDCP may be configured with different discard timer values to apply for different data based on the data unit type and / or data unit properties / attributes / characteristics. For example, the PDCP may be configured with rules to split data from one radio bearer to multiple logical channels based on the data unit type and / or data unit properties / attributes / characteristics.

[0189] User plane data may be prioritized over control plane data. In some examples, a WTRU may be configured to prioritize user plane data over control plane data. A WTRU mayonly be allowed to prioritize user plane data over control plane data, for example, if / when one or more conditions are met. The WTRU may be configured with conditions on when it is allowed to do such prioritization, which may include, for example, any one or more of the following: QoS profile (e.g., (only) if / when the delay budget is less than a preconfigured time threshold); data type (e.g., (only) for mandatory packets); application layer properties (e.g., FEC related parameters; and / or e.g., (only) if the N out of K criteria is not met); Data attribute (e.g., (only) if packet importance is above a preconfigured threshold); Interdependencies (e.g., (only) if the packet is needed for the successful decoding of another critical / crucial packet); Congestion status (e.g., (only) in non-congestion situations); Whether successful delivery of data unit or part / group / component thereof impacts QoS (e.g., (only) if successful delivery of the data unit results in a considerable improvement of the QoS); Time related (e.g., (only) for a preconfigured time window); Channel condition (e.g., (only) if channel conditions are good, and / or e.g., above a preconfigured RSRP); Other conditions (e.g., (only) in certain cells, locations, and / or cell types, such as, e.g., macro cells versus micro cells, etc.); and / or a control plane event is not met (e.g., outside of mobility conditions, conditional handover condition to one or more handover candidate, an RLM, a beam failure, and / or an RLF).

[0190] A WTRU may provide a response to receiving a radio bearer configuration from the NW. In some examples, a WTRU may be required to act on the radio bearer (re)configuration received from the network. A WTRU may perform, for example, one or more of the following actions (e.g., based on a radio bearer configuration): RB release; RB addition; RB modification; SRB release; SRB addition; SRB modification; DRB release; DRB addition; DRB modification; multicast MRB release; multicast MRB addition; and / or multicast MRB modification.

[0191] In some examples, the WTRU may ask for a reconfiguration of the RB in a response to the NW.

[0192] A WTRU may receive (e.g., from the NW) a mapping between data units and QoS. The WTRU may receive from the NW rules to map data units (e.g., IP packets, data units or part / component / group thereof) to QoS pipes. A WTRU may receive the mapping rules, for example, in one or more of the following ways: (pre)configuration in the WTRU; via signaling message (e.g., in NAS messages during PDU Session Establishment / Modification procedure); (implicit) derivation by the WTRU, e.g., by applying reflective QoS; following (e.g., in response to) an indication sent by the WTRU to the NW informing the NW of the UL traffic profile; and / or following (e.g., in response to) a request sent by the WTRU to the NW to request the mapping rules.

[0193] A WTRU may receive QoS to DRB mapping rules from the network. Mapping from QoS flow to DRB may be, for example, 1 :1, 1 :N, and / or N: 1. The WTRU may receive from the network QoS flow to DRB mapping rules. The WTRU may receive the (re)configurations, for example, in any one or more of the following ways: RRC (re)configurations, e.g., in RRC Reconfiguration message; using Reflective QoS flow (RQoS); and / or via one or more dynamic messages, e g., MAC CE, DCI.

[0194] In some examples, the WTRU may receive (e.g., from the gNB) a configuration to map one QoS flow to one DRB, e.g., map QF-1 to DRB-1. In some examples, the WTRU may receive (e.g., from the gNB) a configuration to map N QoS flows to one DRB, e.g., map QF-1 and QF-2 to DRB-1. In some examples, WTRU may receive (e.g., from the gNB) a configuration to map one QoS flow to N DRBs, e.g., map QF-1 to DRB-1 and DRB-2.

[0195] A WTRU may receive, as part of a mapping configuration (e.g., SDAP QoS flow to DRB mapping and / or PDCP for DRB to LCH / RLC entity mapping, etc.) one or more rules that may be applied to perform the mapping. The rules may be associated with, for example, one or more of the following properties: QoS profile; application layer properties; data type(s); data attribute(s); interdependencies between flows and / or data units; and / or congestion status at the WTRU and / or NW.

[0196] A mapping rule may be associated with a QoS profile, e.g., reliability, latency bounds (e.g., delay budgets, remaining time with respect to delay budgets), tolerable error bounds (e.g., packet error rate, PDU set error rate), etc.

[0197] A mapping rule may be associated with application layer properties, e.g., FEC related parameters. For example, N out of K packets may be needed for successful decoding of a frame by the application. After N packets have been received, the WTRU may be configured (e.g., based on one or more mapping rules associated with application layer properties) to remap / reroute the remaining K-N packets to a lower priority DRB.

[0198] A mapping rule may be associated with one or more data types (CP, UP, Positioning, XR, etc.). For example, a WTRU may receive a configuration to map QoS flows to DRB(s) based on the type of data being carried by the QoS flow.

[0199] A mapping rule may be associated with one or more data attributes (e.g., packet importance, PDU set importance, importance of PDU within the PDU set, priority of packet / data units).

[0200] A mapping rule may be associated with interdependencies between flows and / or data units. For example, a video flow and audio flow may have dependencies that may result in theaudio and video flows being mapped to the same QoS flow. The audio and video flows may be provided with differentiated treatment, for example, based on the higher data rate of the video flow. The WTRU may (e.g., therefore) receive a configuration to map the video packets and the audio packets to different radio bearers.

[0201] A mapping rule may be associated with a congestion status at the WTRU and / or NW.

[0202] A WTRU may perform reflective QoS to DRB mapping. In some examples, reflective QoS to DRB mapping may be configured at the WTRU (e.g., in SDAP header), which may allow the WTRU connected to a node (e.g., gNB) to deduce the uplink mapping rules from the downlink mapping rules (e.g., uplink rules may be copied / adapted from the downlink rules).The rules may apply to the non-access stratum (NAS) rules (e.g., data unit to QoS flow mapping) and / or to the access stratum (AS) rules (e.g., QoS flow to DRB mapping). The rules may make use of parameters in the data unit header (e.g., header added to data unit at the SDAP), e.g., Reflective QoS flow to DRB Mapping Indication (RDI), Reflective QoS Indication (RQI), etc. Any one or more rules (e.g., as described herein) may still apply, for example, if / when the WTRU (e.g., SDAP) is mapping from QoS flow to DRB, e.g., with properties based on the downlink traffic (e.g., QoS profile of downlink traffic, application layer properties based on application at core network / server, data type of downlink traffic, data attribute of downlink traffic, any interdependencies between flows and / or data units for downlink traffic, congestion status at NW and / or application server, etc.).

[0203] A WTRU (e.g., SDAP) may receive a configuration from the NW to add markings to data. For example, the WTRU (e.g., SDAP) may receive configuration from the NW to add dynamic markings to the data. The WTRU may receive information from the application to add markings to the data (e.g., in data unit / packet header / subheader), for example, instead of (e.g., simply) routing the data from the QoS flow to DRB based on the QoS profile from the application. The WTRU may (e.g., then) route the data to the radio bearer, e.g., according to the radio bearer configuration. Rules that the WTRU may receive from the network for the addition of markings to the data units and / or parts / component / group thereof may be based on, for example, any one or more of the following properties: arrival time of the data at the WTRU (e.g., SDAP); QoS profile; application layer properties; data type(s); data unit attribute(s); interdependencies between flows and / or data units; and / or congestion status at the WTRU and / or NW.

[0204] Data unit marking rules may be associated with arrival time of the data at the WTRU (e.g., SDAP). For example, a WTRU may be configured to add markings to the data based on itsarrival time (e.g., time stamps). For example, a WTRU may be configured to group data units that arrive within a short period of time of each other as one larger data unit and add markings accordingly.

[0205] Data unit marking rules may be associated with a QoS profile, e.g., reliability, latency bounds (e.g., delay budgets, remaining time with respect to delay budgets), tolerable error bounds (e.g., packet error rate, PDU set error rate).

[0206] Data unit marking rules may be associated with application layer properties, e.g., FEC related parameters. For example, N out of K packets may be needed for successful decoding of a frame by the application. After N packets have been received, the WTRU may be configured to (re)map / (re)route the remaining K-N packets to a lower priority DRB and add markings accordingly.

[0207] Data unit marking rules may be associated with one or more data types (CP, UP, Positioning, XR, etc.). For example, a WTRU may receive a configuration to map QoS flows to DRB(s) based on the type of data being carried by the QoS flow and add markings accordingly.

[0208] Data unit marking rules may be associated with one or more data unit attributes (e.g., packet importance, PDU set importance, importance of PDU within the PDU set, priority of packet / data units).

[0209] Data unit marking rules may be associated with interdependencies between flows and / or data units. For example, a video flow and audio flow may have dependencies that may result in the audio and video flows being mapped to the same QoS flow. The audio and video flows may require differentiated treatment, for example, based on the higher data rate of the video flow. The WTRU may receive a configuration to map the video packets and the audio packets to different radio bearers and add markings accordingly.

[0210] Data unit marking rules may be associated with congestion status at the WTRU and / or NW.

[0211] A WTRU may be configured to aggregate / concatenate data units of a (e.g., one) type. In some examples, the WTRU may be configured to perform aggregation / concatenation on one or more data units of a (e.g., one) type (e.g., to enable treatment of the data unit as a unit in the protocol stack and alleviate the processing times / power in the stack). For example, one subset of data units may be accessible to an external server, which the WTRU may concatenate into one data unit while another subset of data units may not be accessible to an external server, which the WTRU may concatenate as another data unit. For example, a source data unit and a corresponding enhancement data unit may be concatenated as one data unit, e.g., since they mayboth have bits / packets corresponding to the same frame at the application. In some examples, the WTRU may perform a concatenation based (e.g., only) on a condition being fulfilled, e.g., the WTRU may perform concatenation of the source and enhancement data units only in a noncongestion situation where the WTRU may be provisioned with resources according to the WTRU’s BSR requests. In a congestion situation, e.g., where only the source data unit may be transmitted, the concatenation may not be useful.

[0212] Data associated with a radio bearer may be split into more than one LCH. In some examples, a WTRU may be configured to split data to more than one logical channel from a radio bearer to provide differentiated treatment within a radio bearer, which may be useful because data of different properties / attributes may be mapped to the same QoS flow. For example, data of different PDU set importance (PSI) may be mapped to the same QoS flow, e.g., and eventually to the same DRB.

[0213] A configuration to split data from one radio bearer to more than one LCH may be based on, for example, any one or more of the following properties: QoS profile; data type(s); application layer properties; data unit attribute(s); interdependencies; congestion status; Whether successful delivery of data unit or part / group / component thereof impacts QoS; time; channel condition(s); and / or other condition(s).

[0214] A configuration to split data from one radio bearer to more than one LCH may be based on a QoS profile. For example, a split may be performed based on delay bound ranges into LCH 1 or LCH 2, where LCH 1 may serve tighter delay budget packets from the same radio bearer.

[0215] A configuration to split data from one radio bearer to more than one LCH may be based on one or more data types. For example, mandatory packets may be mapped to a higher priority LCH 1 while non-mandatory packets may be mapped to a lower priority logical channel.

[0216] A configuration to split data from one radio bearer to more than one LCH may be based on application layer properties, e.g., FEC related parameters. For example, N out of K packets may be needed for successful decoding of a frame by the application. For example, if a packet is among the N out of K packets, the packet may be mapped to a higher priority LCH. If the packet is in the remaining (K-N) packets, the packet may be mapped to a lower priority LCH from the same radio bearer.

[0217] A configuration to split data from one radio bearer to more than one LCH may be based on one or more data unit attributes. For example, if packet importance is above a preconfigured threshold, the packet may be mapped to a higher priority LCH. If the packet is below thepreconfigured threshold, the packet may be mapped to a lower priority LCH from the same radio bearer.

[0218] A configuration to split data from one radio bearer to more than one LCH may be based on Interdependencies. For example, if the packet may be needed for the successful decoding of a critical / crucial packet, the packet may be mapped to a higher priority LCH. If the packet may not be needed for the decoding of a critical packet or may not be needed for the decoding of any other packet, the packet may be mapped to a lower priority LCH from the same radio bearer. For example, if the packet has dependencies with any other packet, the packet may be is mapped to a higher priority LCH. If the packet does not have dependencies with any other packet, the packet may be mapped to a lower priority LCH from the same radio bearer.

[0219] A configuration to split data from one radio bearer to more than one LCH may be based on congestion status. In congestion scenarios, more differentiated treatment may be beneficial for a WTRU to make the right decision when doing multiplexing. For example, in congestion scenarios, a WTRU may determine to split a radio bearer to more than one LCH while in noncongestion scenarios, the WTRU may determine not to perform splitting. For example, in congestion scenarios, the WTRU may map higher importance packets to a higher priority LCH and may map lower importance packets within the same radio bearer to a lower priority LCH to optimize for the successful transmission of the packets with higher importance value, e.g., possibly at the expense of the packets of lower importance. In a non-congestion scenario, the WTRU may assume that the WTRU may be provisioned with sufficient resources to serve (e.g., all) the packets within the radio bearer and (e.g., therefore) may not need to perform splitting.

[0220] A configuration to split data from one radio bearer to more than one LCH may be based on whether successful delivery of a data unit or a part / group / component thereof impacts QoS. For example, the WTRU may perform splitting (e.g., only) if successful delivery of the data unit may result in an improvement (e.g., a considerable or threshold-based improvement) of the QoS to provide differentiated treatment for the packets. For example, if successful delivery of the data unit may result in an improvement (e.g., a considerable or threshold-based improvement) of the QoS, the WTRU may map the data unit to a higher priority LCH. If not (e.g., if the improvement does not rise to a threshold improvement), the WTRU may map the data unit to a lower priority LCH.

[0221] A configuration to split data from one radio bearer to more than one LCH may be based on time. For example, a WTRU may perform splitting (e.g., related to any one or more of theconditions described herein, such as a time period related to a length of congestion) for a (pre)configured time window.

[0222] A configuration to split data from one radio bearer to more than one LCH may be based on a channel condition. For example, a WTRU may perform splitting (e.g., only) if channel conditions are poor, e.g., below a preconfigured RSRP. A WTRU may perform the splitting while channel conditions are poor (e.g., based on any one or more of the properties described herein, such as a data unit attribute, data type, etc.) to ensure that the data (e.g., of a certain attribute and / or of a certain type) may be successfully transmitted.

[0223] A configuration to split data from one radio bearer to more than one LCH may be based on one or more other conditions. For example, a WTRU perform splitting based on the conditions, such as only in certain cells and / or locations and / or only for cells of certain types (e.g., macro cells vs micro cells), etc.

[0224] A WTRU may determine which of multiple configurations to apply.

[0225] A WTRU may determine a configuration to apply, for example, based on current conditions / measurements. A WTRU may determine the configuration to apply in a dynamic way, for example, based on information on the data and / or UL traffic. In some examples, the WTRU may perform the determination based on more static information, e.g., statistical information on the UL traffic, e.g., overall jitter statistics computed by the WTRU over a time period or delay budget associated with a more static QoS profile and / or the QoS flow identifier (QFI) value of the QoS flow. In some examples, the WTRU may perform the determination based on more instantaneous (e.g., dynamically changing) information, for example, on a per data unit or group / component / type thereof, e.g., instantaneous jitter value for a packet, importance / priority of individual data units, delay budgets of individual data units, etc.

[0226] A WTRU may determine the configuration / set of configurations to apply, for example, based on any one or more of the following: QoS profile of the UL data; QoS profile of the DL data; application layer properties; data type; data unit attribute; interdependencies; comparison with the default configuration; miscellaneous measurements; beam information; energy detection; rate of successful channel access attempts; and / or rate of NACKs.

[0227] A WTRU may determine the configuration(s) to apply based on a QoS profile of the UL data, e.g., reliability, latency bounds (e.g., delay budgets, remaining time with respect to delay budgets), tolerable error bounds (e.g., packet error rate, PDU set error rate).

[0228] A WTRU may determine the configuration(s) to apply based on a QoS profile of the DL data (e.g., for mirroring of UL behavior based on DL traffic, in a reflective QoS to DRB type configuration scenario).

[0229] A WTRU may determine the configuration(s) to apply based on application layer properties, e.g., FEC related parameters.

[0230] A WTRU may determine the configuration(s) to apply based on a data type (e.g., CP, UP, positioning, AI / ML, haptics, video, audio, etc.).

[0231] A WTRU may determine the configuration(s) to apply based on a data unit attribute (e.g., packet importance, PDU set importance, importance of PDU within the PDU set, priority of packet / data units).

[0232] A WTRU may determine the configuration(s) to apply based on a interdependencies between flows and / or data units.

[0233] A WTRU may determine the configuration(s) to apply based on a congestion status at the WTRU and / or NW.

[0234] A WTRU may determine the configuration(s) to apply based on a comparison with the default configuration (e.g., legacy). For example, a WTRU may activate a non-default configuration and compare against (e.g., past) operation in a default configuration. The assessment metric of the WTRU may be feedback received from the NW, e.g., in terms of a PDCP status report, RLC status report, number of HARQ ACKs / NACKs, etc.

[0235] A WTRU may determine the configuration(s) to apply based on one or more (e.g., miscellaneous) measurements. For example, a WTRU may be configured with resources on which to perform at least one measurement. The WTRU may compare the at least one measurement to at least one threshold. The at least one threshold may be configurable. The WTRU may determine a configuration / set of configurations to select, for example, if the at least one measurement is greater or less than the at least one threshold. A configuration / configuration set may be associated with at least one measurement threshold. A WTRU function / configuration may be associated with at least one measurement threshold. The measurement may include, for example, at least one of the following: one or more (e.g., miscellaneous) conditions associated with the WTRU and / or one or more channel conditions.

[0236] One or more (e.g., miscellaneous) conditions associated with a WTRU, may be related to, for example, one or more of the following: mobility state of WTRU; positioning info of WTRU (e.g., 3GPP or non-3GPP related); speed at which WTRU is moving; direction ofmobility; radio conditions of current cell; radio conditions of neighbor cells; battery level; and / or location of WTRU within the cell (e.g., whether at cell center or cell edge).

[0237] One or more channel conditions may include, for example, one or more of the following: throughput; block error rate (BLER); latency of transmission; whether the path is line of sight or non-line of sight; any other LI or L3 measurements (e.g., cell RSRP, Ll-RSRP, cell RSRQ, Ll-RSRQ, signal to interference and noise ratio (SINR), channel state information (CSI) parameters (e.g., channel quality indicator (CQI), precoding matrix indicator (PMI), RI, LI), Doppler spread, delay spread, number of multipaths, channel coherence time, channel coherence bandwidth, etc.); and / or interference measurement, path loss, etc.

[0238] A WTRU may determine the configuration(s) to apply based on a beam information, e.g., beam index, beam RSRP, beam direction, beamwidth, set of beams (e.g., elements in the set of the cardinality of the set).

[0239] A WTRU may determine the configuration(s) to apply based on energy detection.

[0240] A WTRU may determine the configuration(s) to apply based on a rate of successful channel access attempts. For example, the WTRU may maintain the number or percentage of successful listen-before-talk (LBT) attempts over a period of time. The period of time may be dynamically determined (e.g., sliding window).

[0241] A WTRU may determine the configuration(s) to apply based on a rate of NACKs. For example, a WTRU may maintain a measurement of the number or percentage of NACKs over a period of time. The period of time may be dynamically determined (e.g., sliding window).

[0242] A WTRU may determine a configuration to apply based on an NW indication. In some examples, the WTRU may receive an indication from the NW on the configuration (e.g., configuration set) to select. A WTRU may receive an indication, for example, statically / semi- statically, via RRC (re)configuration, and / or dynamically, e.g., via MAC CE or DCI. In some examples, the WTRU may receive from the NW an indication of congestion and / or congestion level experience by the NW. The WTRU may select the configuration (set) accordingly.

[0243] In some examples, a WTRU may be configured with one or more soft QoS guarantees, e.g., instead of relying on hard, absolute QoS guarantees. Soft guarantees may indicate a range of values for QoS attributes (e.g., a range for latency, data rate, reliability, e.g., packet error rate, etc.). An adaptive QoS framework with soft QoS guarantees may be adaptive, for example, based on channel conditions (e.g., if there is uncongested NW / WTRU radio conditions with good coverage versus congested NW / WTRU radio conditions with poor coverage). The adaptation may rely on the WTRU being configured with different constructs (e.g., includingQoS flows, DRBs, LCHs, LCGs, etc.), where each construct may have properties pertaining to (e.g., three) different statuses, e.g., hard QoS guarantees, no QoS guarantees, and soft QoS guarantees.

[0244] Soft QoS guarantees may be met, for example, (e.g., only) if / when one or more conditions pertaining to the NW and / or WTRU are fulfilled. Soft QoS guarantees may be met, for example, if one or more of the following conditions are met: if there is no congestion (e.g., at WTRU side and / or NW side); if the WTRU is being provisioned with resources according to the buffer size index indicated in the BSR report (e.g., if the WTRU is only receiving smaller grants, the WTRU may only fulfill the hard QoS guarantees); if the NW is able to serve the WTRU with sufficient resources amounting to more than the PBR of its logical channels; and / or if the NW is able to serve the WTRU with sufficient resources to serve lower priority logical channels.

[0245] A WTRU may inform the network about a selected configuration.

[0246] A WTRU may send an indication to the NW on the selected configuration. A WTRU configured with multiple configurations may (e.g., prior to activating a configuration) send an indication to the NW, for example, since the selected configuration may impact the amount of resources that the NW may need to provision for the WTRU. A configuration selection indication may be included in a protocol header or a control element. For example, if the WTRU performs splitting from one radio bearer to a higher priority LCH 1 and a lower priority LCH 2, the NW may (e.g., be able to) reconfigure the PBR of either logical channel and / or ensure that the WTRU may (e.g., always) have sufficient resources to meet the PBR of LCH 1. A WTRU may transmit a notification to the NW (e.g., prior to switching to a non-default configuration), for example, even if the WTRU receives a configuration from the NW on how to perform the splitting.

[0247] A WTRU may activate the selected configuration(s). A WTRU may activate the selected configuration(s), for example, if the related conditions are met. In some examples, the WTRU may not be able to activate the selected configuration, e.g., even if the related conditions are met unless the WTRU receives a confirmation message from the NW (e.g., a control element or feedback). In some examples, the WTRU may not receive a NACK message from the NW, in which case the WTRU may remain with a current configuration and / or may revert to a default configuration. A WTRU may receive (e.g., at any time) an indication from the NW to switch to a default configuration, in which case the WTRU may switch to a default configuration, e.g., irrespective of the conditions being fulfilled for a non-default configuration.

[0248] In accordance with the approach disclosed herein, a device may be configured to receive information, from a network, indicative of a plurality of transmission configurations. Each configuration may have respective mapping rules that define conditions with corresponding mappings between quality-of-service flows and data radio bearers. In an example, transmission configurations may represent a greater than a one-to-one mapping between quality-of-service flows and data radio bearers. The mapping rules may further include a corresponding mapping between data radio bearers and logical channels.

[0249] The device may be configured to determine a transmission configuration from the plurality of transmission configurations applicable for a data transmission based on information indicative of network-device congestion. The information indicative of network-device congestion may include information determined from device buffer status monitoring. The information indicative of network-device congestion may include information received from the network.

[0250] The device may be configured to map a quality-of-service flows and a data radio bearer according to the mapping rules of the determined transmission configuration and transmit the data transmission according to the mapped quality of service flows and a data radio bearer.

[0251] Although features and elements described above are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements.

[0252] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0253] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disksand removable disks, magneto-optical media, and / or optical media such as compact disc (CD)- ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. Claims1. A wireless transmit / receive unit (WTRU), comprising: a processor configured to: receive first transmission configuration information from a network, wherein the first transmission configuration information indicates a first transmission configuration, wherein the first transmission configuration indicates a first mapping condition and a first mapping between a quality-of-service (QoS) flow and a first data radio bearer (DRB); receive second transmission configuration information from the network, wherein the second transmission configuration information indicates a second transmission configuration, wherein the second transmission configuration indicates a second mapping condition and a second mapping between the QoS flow and a second DRB; determine that a condition is satisfied, wherein the condition is the first mapping condition or the second mapping condition; select a transmission configuration from the first transmission configuration and the second transmission configuration based on the determination that the condition is satisfied; and transmit data based on the selected transmission configuration.

2. The WTRU of claim 1, wherein the satisfied condition is the first mapping condition, and wherein the first mapping condition is based on at least one of a QoS profile of the transmitted data, an application layer property, a data type, or a data attribute.

3. The WTRU of claim 1, wherein the satisfied condition is the first mapping condition, and wherein the selection of the transmission configuration is further based on the second mapping condition not being satisfied.

4. The WTRU of claim 1, wherein the first transmission configuration further indicates a mapping between the first DRB and a first logical channel (LCH), and wherein the second transmission configuration further indicates a mapping between the second DRB and a second LCH.

5. The WTRU of claim 1, wherein the processor is further configured to send, to the network, an indication of the selected transmission configuration.

6. The WTRU of claim 1, wherein the satisfied condition is the first mapping condition, wherein the first mapping condition is based on a congestion status, and wherein the congestion status is indicated in the first transmission configuration information or determined by the WTRU.

7. The WTRU of claim 1, wherein the satisfied condition is the first mapping condition, and wherein the first mapping condition is based on an energy savings state of the WTRU or an energy savings state of the network.

8. The WTRU of claim 1, wherein the satisfied condition is the first mapping condition, and wherein the first mapping condition is based on a dependency between a first Protocol Data Unit (PDU) and a second PDU.

9. A method comprising: receiving first transmission configuration information from a network, wherein the first transmission configuration information indicates a first transmission configuration, wherein the first transmission configuration indicates a first mapping condition and a first mapping between a quality-of-service (QoS) flow and a first data radio bearer (DRB); receiving second transmission configuration information from the network, wherein the second transmission configuration information indicates a second transmission configuration, wherein the second transmission configuration indicates a second mapping condition and a second mapping between the QoS flow and a second DRB; determining that a condition is satisfied, wherein the condition is the first mapping condition or the second mapping condition; selecting a transmission configuration from the first transmission configuration and the second transmission configuration based on the determination that the condition is satisfied; and transmitting data based on the selected transmission configuration.

10. The method claim 9, wherein the satisfied condition is the first mapping condition, and wherein the first mapping condition is based on at least one of a QoS profile of the transmitted data, an application layer property, a data type, or a data attribute.

11. The method of claim 9, wherein the satisfied condition is the first mapping condition, and wherein the selection of the transmission configuration is further based on the second mapping condition not being satisfied.

12. The method of claim 9, wherein the first transmission configuration further indicates a mapping between the first DRB and a first logical channel (LCH), and wherein the second transmission configuration further indicates a mapping between the second DRB and a second LCH.

13. The method of claim 9, wherein the method further comprises sending, to the network, an indication of the selected transmission configuration.

14. The method of claim 9, wherein the satisfied condition is the first mapping condition, wherein the first mapping condition is based on a congestion status, and wherein the congestion status is indicated in the first transmission configuration information or determined by the WTRU.

15. The method of claim 9, wherein the satisfied condition is the first mapping condition, and wherein the first mapping condition is based on an energy savings state of the WTRU or an energy savings state of the network.

Images