Determining a quality of service requirement of a quality of service flow in a wireless communication network

Abstract

Various aspects of the present disclosure relate to a user equipment, UE, for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: receive, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS requirement of a data flow for the data packet; determine the particular QoS requirement for the data packet based at least in part on the additional data; and route the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

Description

DETERMINING A QUALITY OF SERVICE REQUIREMENT OF A QUALITY OF SERVICE FLOW IN A WIRELESS COMMUNICATION NETWORKTECHNICAL FIELD

[0001] The subject matter disclosed herein relates generally to the field of implementing a Quality-of-Service (QoS) flow. In particular, this document defines a user equipment (UE) and a radio access network (RAN), a processor and methods thereof.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C orAB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on”. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] There is provided a user equipment (UE) for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: receive, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular Quality of Service (QoS) requirement of a data flow for the data packet; determine the particular QoS requirement for the data packet based at least in part on the additional data; and route the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

[0005] There is further provided a processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: receive, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS requirement of a data flow for the data packet; determine the particular QoS requirement for the data packet based at least in part on the additional data; and route the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

[0006] There is further provided a method performed by a UE, wherein the UE is configured with a data flow, wherein a QoS of the data flow is adaptable, the method comprising: receiving, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS requirement of the data flow for the data packet; determining the particular QoS requirement for the data packet based at least in part on the additional data; and routing thedata packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

[0007] There is further provided a radio access network (RAN) for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the RAN to: establish a plurality of radio bearers for a data flow, wherein a quality of service, QoS, of the data flow is adaptable; and receive, from a UE via a first radio bearer of a plurality of radio bearers, a data packet, the data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of a data flow for the data packet.

[0008] There is further provided a method performed by a RAN, the method comprising: establishing a plurality of radio bearers for a data flow, wherein a quality of service, QoS, of the data flow is adaptable; and receiving, from a UE via a first radio bearer of the plurality of radio bearers, a data packet, the data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of the data flow for the data packet.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0010] Figure 2 illustrates a Core Network (CN) extended Reality Media (XRM) architecture and handling of Packet Data Unit (PDU) sets in accordance with aspects of the present disclosure.

[0011] Figure 3 illustrates a 1-byte Real Time Protocol (RTP) header extension for PDU Set marking by the Application Server (AS) in accordance with aspects of the present disclosure.

[0012] Figure 4 illustrates a 2-byte RTP header extension for PDU Set marking by the AS in accordance with aspects of the present disclosure.

[0013] Figures 5a to 5d illustrate 5GS PDU Set-aware Quality of Service (QoS) handling framework description of PDU Set to QoS flow to Data Radio Bearer (DRB) mappings in accordance with aspects of the present disclosure.

[0014] Figure 6 illustrates an architecture for using QUIC to add PDU set info within Hypertext Transfer Protocol (HTTP) datagrams in accordance with aspects of the present disclosure.

[0015] Figure 7 illustrates a flow diagram for a procedure for network assistance and exposure of bit rate recommendations applicable to Real Time Control (RTC) in accordance with aspects of the present disclosure.

[0016] Figure 8 illustrates an architecture for support of UL dynamic QoS for applications with dynamic traffic characteristics in accordance with aspects of the present disclosure.

[0017] Figure 9 illustrates a procedure for enabling support of UL dynamic QoS for applications with dynamic traffic characteristics in accordance with aspects of the present disclosure.

[0018] Figure 10 illustrates an example of a user equipment (UE) 1000 in accordance with aspects of the present disclosure.

[0019] Figure 11 illustrates an example of a processor 1100 in accordance with aspects of the present disclosure.

[0020] Figure 12 illustrates an example of a network equipment (NE) 1200 in accordance with aspects of the present disclosure.

[0021] Figure 13 illustrates a flowchart of a method 1300 performed by a UE in accordance with aspects of the present disclosure.

[0022] Figure 14 illustrates a flowchart of a method 1400 performed by a NE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0023] Some wireless communication networks, such as 5G networks supporting a QoS framework may experience shortcomings, resulting from applying (e.g., enforcing, implementing) Guaranteed Bit Rate (GBR) QoS flows with static QoS requirements. Once a QoS flow is established with static QoS requirements, the networks (e.g., a RAN) may manage delivery of a packet according to the static requirements of the QoS flow.However, these QoS flows might be unsuitable (e.g., inadequate) for applications with traffic characteristics that change dynamically. Applications, such as video streaming applications, real-time media applications, and the like, may require the networks to handle bursty traffic. For example, bursty traffic may occur due to a sudden increase in the bandwidth required to support a video stream. Bursty traffic scenarios are inconsistent and cannot be predicted. As such, to accommodate such type of traffic, the networks may establish a GBR QoS flow with QoS requirements to satisfy highest bandwidth requirements of these applications. However, the problem is that the networks (e.g., the RAN) have to reserve resources to accommodate the highest bandwidth requirements. These resources may be wasted (i.e., unused) given that the applications might not need to transmit (e.g., deliver) large traffic bursts continuously (e.g., all the time).

[0024] Examples described herein generally relate to solutions for Uplink (UL) dynamic QoS handling for applications with dynamic QoS requirements and traffic characteristics changes.

[0025] Aspects of the present disclosure are described in the context of a wireless communications system.

[0026] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE-Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G-Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combinationof a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0027] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signalling, transmit signalling) over a Uu interface.

[0028] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0029] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as anInternet-of-Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0030] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0031] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0032] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0033] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0034] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0035] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., / t=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., / t=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., / / =1) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., g=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., / t=3) may be associated with a fourth subcarrier spacing(e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., / t=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0036] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0037] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., / t=0, / t=l, =2, jtz=3, =4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., / t=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0038] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designationsFR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0039] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., / t=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., / / =1), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / / =2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., / z=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / t=3), which includes 120 kHz subcarrier spacing.

[0040] A plethora of application and services where multimedia flows are multiplexed under a single network application session (e.g., a 5-tuple containing a source IP address, a destination IP address, a source network port, a destination network port, and a protocol number as identifier) relates to the domain of extended Reality (XR). As an example, an XR application based on WebRTC, or alternatively, on RTP / SRTP protocol stack, may contain one or more multiple video streams and audio streams multiplexed with control and feedback metadata and application metadata (e.g., such as user pose information, user input actions etc) over a single application data network session.

[0041] Examples described herein may relate to XR as a reference use case or family of applications for the solutions proposed. However, examples described herein are generally applicable and may be embodied by different types of transport and network protocols stacks (e.g., QUIC, WebRTC, WebTransport or alike).

[0042] Furthermore, XR is referred to hereafter as an umbrella term for different types of realities, for example:

[0043] Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is in this case designed to mimic the visual and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Virtual reality usually, but not necessarily, requires a user to wear a head mounted display (HMD), to completely replace the user's field of view with a simulated visual component, and to wear headphones, to provide the user with the accompanying audio. Some form of head and motion tracking of the user in VR is usually also necessary to allow the simulated visual and audio components to be updated to ensure that, from the user's perspective, items and sound sources remain consistent with the user's movements. In some implementations additional means to interact with the virtual reality simulation may be provided but are not strictly necessary.

[0044] Augmented reality (AR) is when a user is provided with additional information or artificially generated items, or content overlaid upon their current environment. Such additional information or content will usually be visual and / or audible and their observation of their current environment may be direct, with no intermediate sensing, processing, and rendering, or indirect, where their perception of their environment is relayed via sensors and may be enhanced or processed.

[0045] Mixed reality (MR) is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene.

[0046] XR refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. It includes representative forms such as AR, MR and VR and the areas interpolated among them. The levels of virtuality range from partially sensory inputs to fully immersive VR. A key aspect of XR is the extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of cognition (represented by AR).

[0047] The XR Media (XRM) feature in 3 GPP Release 18 at the core network (CN) level introduced the concept of a PDU Set to handle QoS requirements of XRM applications and streams with a better granularity beyond 5G Rel-17 QoS flow possibilities. As such, a PDU set is composed of one or more PDUs carrying the payload of one unit ofinformation generated at the application level (e.g. a frame or video slice for XRM Services). In some implementations, all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover parts or all of the information unit, when some PDUs are missing.

[0048] In addition, the PDU set is associated with QoS requirements in terms of delay budget and error rate as:

[0049] a PDU Set Delay Budget (PSDB) which defines an upper bound for the time that a PDU-Set may be delayed between the UE and the N6 termination point at the UPF. PSDB applies to the DL PDU-Set received by the UPF over the N6 interface, and to the UL PDU-Set sent by the UE, and respectively,

[0050] a PDU Set Error Rate (PSER) which defines an upper bound for the rate of PDU-Sets (e.g. set of IP packets constituting a PDU-Set) that have been processed by the sender of a link layer protocol (e.g. RLC in RAN of a 3GPP access) but where all of the PDUs in the PDU-Set are not successfully delivered by the corresponding receiver to the upper layer (e.g. PDCP in RAN of a 3GPP access), whereas the PSER is used to determine an upper bound for a rate of non-congestion-related packet losses.

[0051] Figure 2 illustrates a Core Network (CN) extended Reality Media (XRM) architecture and handling of Packet Data Unit (PDU) sets in accordance with aspects of the present disclosure. Figure 2 may illustrate an overview of the CN XRM architecture handling of PDU sets. Figure 2 shows a system 200 comprising an Extended Reality Media Application Function (XRM AF) 210, a Policy and Control Function (PCF) 215, a Session Management Function (SMF) 220, an Access and Mobility Function (AMF) 225, a Radio Access Network (RAN) 230, a User Equipment (UE) 235, a User Plane Function (UPF) 240, and an Extended Reality Application 245. The operation of system 200 will now be described in the example of downlink traffic, a similar process may operate for uplink traffic.

[0052] At 280, the XRM AF 210 determines PDU-set requirements.

[0053] At 281, the XRM AF 210 provides QoS requirements for packets of a PDU set to the PCF 215 and information to identify the application (e.g., 5-tuple or application id). The QoS requirements may comprise PSDB and PSER. The QoS requirements may comprise additional parameters. The XRM AF 210 may also include an importance parameter for a PDU set and information for the core network to identify packets belonging to a PDU set.

[0054] At 282, the PCF 215 derives QoS rules for the XR application and specific QoS requirements for the PDU Set and configures the SMF 220. The QoS rules may use a 5G QoS identifier (5QI) for XR media traffic. The PCF 215 sends the QoS rules to the SMF 220. The QoS rules may comprise PDU set related QoS requirements for 5-tuple. The PCF 215 may include in the communication to the SMF 220 PCC rules per importance of a PDU Set. The PCC rules may be derived according to information received from the XRM AF 210 or based on an operator configuration.

[0055] At 283, the SMF 220 establishes a QoS flow according to the QoS rules by the PCF 215 and configures the UPF to route packets of the XR application to a QoS flow, and, in addition, to enable PDU Set handling. The SMF 220 also provides the QoS profile containing PDU Set QoS requirements to the RAN 230 via the AMF 225. The QoS profile may be of the QoS flow. The QoS profile may be of the QoS flow may include the PSDB and PSER information and any other parameters. The AMF 225 may provide the QoS profile containing PDU Set QoS requirements to the RAN 230 in an N2 SM container. Further, the AMF 225 may provide the QoS rules to the UE 235 in an N1 SM container.

[0056] At 284, the UPF 240 inspects the packets and determines packets belonging to a PDU Set. Such a determination may be based on UPF implementation given, for instance by inspecting the RTP packet headers , as described in 3 GPP Technical Specification 23.501 V18.2.2 (Jun 2023) titled "System architecture for the 5G System (5GS)", or based on AS-marked PDU Set information transmitted over RTP PDU Set header extensions as described in 3GPP TS 23.501 vl8.2.2 and 3GPP Technical Specification 26.522 vl8.1.0 (Sep 2024) titled "5G Real-time Media Transport Protocol Configurations" i.e., urn:3gpp:pdu-set-marking:rel-18. The UPF 240 may determine a PDU set from XR packets and route the packets toa corresponding QoS flow according to N4 rules. Thepacket inspection may comprise inspecting the RTP packets. When the UPF 240 detects packets of a PDU Set the UPF 240 marks the packets belonging to a PDU Set within a GTP-U header. The GTP-U header information includes a PDU Set sequence number and the size of the PDU Set. The UPF 240 may also determine the importance of the PDU Set either based on UPF 240 implementation means, information provided by the XRM AF 210 or information provided as metadata from an XRM application server. Based on the importance of the PDU Set the UPF 240 may route the traffic to a corresponding QoS flow 1 (according to the rules received from the SMF 220) or include the importance of the PDU Set within a GTP-U header. QoS flow 1 may comprise GTP-U headers, and these may include PDU Set information.

[0057] At 285, the RAN 230 identifies packets belonging to a PDU Set (based on the GTP-U marking) and handles the packets of the PDU-set according to the QoS requirements of the PDU Set provided by the SMF 220. The RAN 230 may receive QFIs, QoS profile of the QoS flow from the SMF 220 (via the AMF 225) during PDU session establishment or modification which may include PDSB and PSER. The RAN 230 may inspect GTP-U headers and may ensure all packets of the same PDU set are handled according to the QoS profile.

[0058] The RAN 230 may send packets of the PDU set over a radio bearer (RB) allocated to QoS flow 1 to the UE 235. The RAN 230 may send packets not belonging to the PDU set over a RB allocated to QoS flow 2 to the UE 235. The AMF 225 may send the QoS Rules to the UE 235 using an N1 SM container. The AMF 225 may send the QoS profile to the RAN 230 using an N2 SM container. The XR application 245 may send an XR packet to the UPF 240.

[0059] However, in XRM Release 18, i.e. 3GPP Technical Specification TS 23.501 V18.2.2 (Jun 2023) titled "System architecture for the 5G System (5GS)", once the PDU Set QoS integrated handling is enabled, the PSA UPF identifies PDUs that belong to PDU Sets and determines for each PDU Set the PDU Set information below sent over to the NG-RAN in the GTP-U header.

[0060] The PDU Set Information comprises:• PDU Set Sequence Number.• Indication of End PDU of the PDU Set.• PDU Sequence Number within a PDU Set.• PDU Set Size in bytes.• PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.

[0061] The PDU Set information is then used by the NG-RAN for PDU Set based QoS handling as described above.

[0062] The NG-RAN may use Priority Levels as of across QoS Flows and PDU Set Importance within a QoS Flow for PDU Set level packet discarding in presence of congestion. Such Priority Levels are described in 3GPP TS 23.501 vl8.2.2 clause 5.7.3.3.

[0063] It is also specified in 3GPP TS 23.501 vl8.2.2 that the PSA UPF identifies PDUs that belong to PDU Sets and if the UPF receives a PDU that does not belong to a PDU Set based on Protocol Description for PDU Set identification (e.g., has not been marked with PDU Set information by the AS), then the UPF still maps the PDU to a PDU Set and determines the PDU Set Information as described above. This ensures that for a QoS flow with PDU Set enabled all the PDUs belong to a PDU Set. To this end, if the PSA UPF receives a PDU that does not belong to a PDU Set, it is assumed that the UPF determines the PDU Set Importance value based in some examples on pre-configuration and in other examples on an AS / AF signalled default importance.

[0064] The AS PDU Set information listed above may be provided via a RTP Header Extension for the marking of PDU Sets, e.g., US provisional application 63 / 478,932 titled “MULTIMEDIA SUBPROTOCOLS OVER REAL TIME PROTOCOL” by Stoica et al., Applicant’s reference SMM920220218-US-PSP. In addition, the PDU Set information may further include in an End of Data Burst indication, as defined by 3 GPP Technical Specification TS 26.522 vl8.1.0 (Sep 2024), titled “5G Real-time Media Transport Protocol Configurations”.

[0065] Figure 3 illustrates a 1-byte RTP header extension for PDU Set marking by the AS as per 3GPP TS 26.522 vl8.1.0.

[0066] Similarly, figure 4 illustrates a 2-byte RTP header extension for PDU Set marking by the AS as per 3GPP TS 26.522 vl8.1.0.

[0067] The semantics of the fields denoted in Figure 3 and Figure 4 of the RTP Header Extension for the marking of PDU Set and End of Bursts are as follows.

[0068] End PDU of the PDU Set [E] (1 bit field) 332, 432 is a flag set to 1 for the last PDU of the PDU Set and set to 0 for all other PDUs of the PDU Set.

[0069] Reserved [R] (2 bits field) 333, 433 is reserved for future use.

[0070] End of Data Burst [D] (1 bit field) 334, 434 indicates the end of a Data Burst being set to a non-zero value when the end of data burst is present and 0 otherwise.

[0071] PDU Set Importance [PSI] (4 bits field) 335, 435 indicates the importance of a PDU Set compared to other PDU Sets within the same QoS flow. Lower values indicate a higher importance PDU Set with the highest importance PDU Set of 1 and the lowest importance PDU Set of 15. A PSI value of 0 provides no information about the PDU Set importance and may be used when the importance of a PDU Set cannot be determined, or is unknown.

[0072] PDU Set Sequence Number [PSSN] (10 bits field) 336, 436 encodes the sequence number of the PDU Set to which the current PDU belongs acting as a 10-bit numerical identifier for the PDU Set and wraps around at 1023.

[0073] PDU Sequence Number within a PDU Set [PSN] (6 bits field) 337, 437 indicates the sequence number of the current PDU within the PDU Set. The PSN is set to 0 for the first PDU in the PDU Set and incremented monotonically for every PDU in the PDU Set in order of transmission from the sender. PSN wraps around 63.

[0074] PDU Set Size [PSSize] (24 bits field) 338, 438 indicates the total size of all PDUs of the PDU Set to which this PDU belongs. This field is optional and subject to an SDP signalling offer / answer negotiation, where the AS may indicate whether it will be able to provide the size of the PDU Set for that RTP stream. If not enabled, the field is notpresent. If enabled, but the AS is not able to determine the PDU Set Size for a particular PDU Set, it should set the value to 0 in all PDUs of that PDU Set. The PSSize indicates the size of a PDU Set including RTP / UDP / IP header encapsulation overhead of its corresponding PDUs. The PSSize is expressed in bytes.

[0075] Number of PDUs in the PDU Set [NPDS] (16 bits) 339, 439 is the number of PDUs within the PDU Set indicates the total number of PDUs belonging to the same PDU Set. This field is optional and subject to an SDP signalling offer / answer negotiation, where the Application Server may indicate whether it will be able to provide the number of PDUs within the PDU Set for that RTP stream. It is recommended to add the Number of PDUs in the PDU Set field when the PDU Set Size field is present.

[0076] The above examples relate to downlink (DL) traffic. Reciprocal processing is applicable to UL whereas the role of UPF packet inspection is taken by the user equipment (UE) which is expected to inspect packets, determine packets belonging to a PDU Set, and signal accordingly the PDU Set to the RAN for scheduling and resource allocation corresponding to an associated DRB capable of fulfilling the PDU Set QoS requirements (e.g., PSDB and PSER). The low-level signalling mechanism associated with the UL UE- to-RAN information passing are up to the specification and implementations of RAN signalling procedures and rely on buffer status reporting (BSR) and delay status reporting (DSR) procedures.

[0077] Figures 5a to 5d illustrate 5GS PDU Set-aware QoS handling framework description of PDU Set to QoS flow to DRB mappings. Depending on the QoS flow mappings and RAN procedures, several alternative PDU Set to QoS flow to DRB mappings are possible given two distinct PDU Sets with different PDU Set attributes, such as PDU Set importance. Figure 5 illustrates some options where two PDU Sets 510 of different importance and characteristics are mapped to QoS flows 520 and respectively to Data Radio Bearers (DRBs) 530. Consider in this example PDU Set 1 to be of high importance with strict QoS requirements (e.g., PSDB, PSER etc.) and PDU Set 2 to be of low importance with potentially lower QoS requirements (e.g., PSDB, PSER etc.) than PDU Set 1. As illustrated in Figure 5, the PDU Set 510 to QoS flow 520 to DRB 530 can take the following instantiations depending on QoS flow policies and Layer 2 RAN procedures.

[0078] Figure 5a illustrates 1-to-l-to-l mapping: whereby the separation of QoS flows 520 and DRBs 530 is complete between high and low importance PDU Sets 510 optimizing finely the radio and network resources on a per PDU Set basis.

[0079] Figure 5b illustrates M-to-M-to-1 mapping: whereby the separation between high and low importance PDU Sets 510 is performed only at QoS flow level, whereas the same DRB 530 is used for the over-the-air transmission of both PDU Sets 510, which may lead to overprovisioning of radio resources for low importance PDU Sets 510 yet require a lower overhead of RAN complexity and management.

[0080] Figure 5c illustrates M-to-l-to-1 mapping: whereby there is no separation between the QoS flows 520 and DRBs 530 of different importance PDU Sets 510 and the higher importance PDU Set QoS requirements are prioritized in handling the QoS management across both CN and RAN; this may lead to overprovisioning of resources for low importance PDU Sets 510 in both CN and RAN implementations but requires lower overhead and control within the 5GS QoS framework.

[0081] Figure 5d illustrates M-to-l-to-M mapping: whereby there is no separation across the QoS flows 520 between PDU Set importance levels, yet distinct DRBs 530 are used to cater for the individual requirements of the distinct importance levels; this compromises the QoS flow management complexity and uses PDU Set information to filter the PDU Sets 510 on different DRBs 530 in order to better match the QoS requirements at RAN level and optimize resource allocation according to individual PDU Set needs.

[0082] Figure 6 illustrates an architecture 600 for using QUIC to add PDU set info within Hypertext Transfer Protocol (HTTP) datagrams in accordance with aspects of the present disclosure.

[0083] The architecture 600 comprises an end-to-end encrypted connection between a UE 635 and a content server associated with an XR video application server 645 via a UPF 640. An XR AF 610 sends a PDU set requirement for an IP flow (5-tuple) to a PCF 615. The PCF 615 sends PCC rules with PSDB requirements to an SMF 620. The SMF 620 sends a QoS profile to an AMF 625. The SMF 620 also sends N4 rules to the UPF 640. The UPF 640 further comprises a HTTP / 3 client 644a. An XR video application server 645receives PDU set information within an encapsulation protocol header. The XR video application server 645 comprises a HTTP / 3 proxy 644b. A first QUIC connection 646 and a second QUIC connection 648, are established between the UPF 640 and the XR video application server 645.

[0084] The UPF 640 further comprises Packet Detection Rules (PDR) rules. A first QoS flow 632 is established between the UPF 640 and RAN 630. The first QoS flow 632 comprises PDSB and PSER requirements. The RAN 630 receives a QoS profile with PSDB requirements from the AMF 625 using an N2 SM container. The RAN 630 allocates an RB for the first QoS flow for the UE 635.

[0085] The architecture 600 may be used for identification of encrypted traffic. In Release 19, the core network may be aware of the PDU set information when the end-to- end XRM application is fully encrypted. This may use a "QUIC tunnel" between the UPF 640 and the XR video application Server 645 including within the headers of the HTTP datagram, metadata that includes PDU set information. The UPF 640 extracts the PDU set metadata and includes the PDU set within GTP-U headers towards the RAN 630.

[0086] Some examples described herein may relate to the support of dynamic traffic characteristics.

[0087] The mechanism adopted in 5G networks for QoS support is that an Application Function provides QoS requirements that the 5G network translates into 3GPP specific QoS characteristics (5G QoS parameter). The 5G network may comprise a PCF. 5G QoS characteristics associated with a 5G QoS Identifier (5QI) where each 5QI has specific traffic characteristics. Each 5QI may comprise a specific packet delay requirement, a packet error rate, and / or a maximum data burst volume. A 5QI may be defined to support services such as conversational voice, video, real time gaming etc. When a RAN receives a packet (in the downlink) identified by a specific 5QI then the RAN may handle the packet according to the traffic characteristics of the 5QI.

[0088] In the past, QoS frameworks may not be quick enough to adapt to applications that dynamically change their traffic characteristics. For example, in video media there may be a sudden need for sending a burst of traffic. For example, the burst of traffic may be dueto a change in a scene in the video. The RAN (or RAN node) may use the same QoS characteristics irrespective of the size of the burst.

[0089] In some examples described herein, the traffic characteristics of XR services can change dynamically. In some examples, the size of a media segment may vary dynamically; for example, if a user moves a progress bar of a streaming video, more bandwidth is needed to buffer an initial set of video frames to allow the streaming application to buffer enough data to support smooth video playback. In some examples, the size of a data burst in XR service may vary dynamically during video scene changes. An encoder may create a new video I-frame where the packet size is considerably higher against a packet size of a previous.

[0090] In the past, a 5QI is associated with specific traffic characteristics such as a specific maximum data burst volume. In such an arrangement, the RAN has no flexibility to handle the packet differently if traffic characteristics change dynamically. The solution adopted in 3GPP in Release 19 is that the Application Server providing an indication of a traffic burst that is received at the UPF and forwarded to the RAN via GTP-U signalling. The RAN node adjusts its scheduling resources according to the traffic burst size. The solution adopted is sub-optimal and not flexible enough since the method the RAN node takes to adapt its scheduling resources is implementation specific and may not be consistent across similar traffic flows with the same traffic characteristics.

[0091] A different solution has also been provided where the AF indicates requirements to boost the data rate for an application session providing additional QoS requirements and the 3 GPP network configuring two QoS flows one with default QoS requirements and one with higher QoS requirements. The Application Server indicates with packet needs higher QoS (within metadata over N6) and the UPF routes the packet over the higher QoS flows. Such approach has the disadvantage of wasting resources as the RAN may need to maintain resources for the higher QoS flow even when no packets are routed over such flow.

[0092] Some examples described herein may relate to Application Awareness in a 3 GPP network (RAN and CN).

[0093] In the past, the RAN may be aware of the packet delay requirements or packet error rate of a received packet (if in the downlink). The RAN is not aware of the type of application that sent this packet or the traffic characteristics of the application.

[0094] In some examples, the 3 GPP network may be configured to be aware of the traffic characteristics whereby the UE uses Multipath QUIC (MPQUIC - draft-ietf-quic- multipath-10) to split application traffic with different traffic characteristics into multiple QUIC connections where each connection is associated with a specific QoS rule. Such approach brings complexity to the UE as the UE may identify application traffic with specific traffic characteristics and route this traffic via a specific QUIC connection. In addition, the UPF may require enhanced capability to ensure that corresponding traffic in the downlink traffic is routed via the same QUIC connection

[0095] In some examples, the 3 GPP network may be configured to be aware of the traffic characteristics by leveraging Internet Engineering Task Force (IETF) Multiplexed Application Substrate over QUIC Encryption (MASQUE) which uses QUIC protocol as an enhanced method for traffic management. MASQUE can be used to exchange information between the UE and mobile network providing information such as a traffic category.

[0096] Examples described herein may relate to the exposure of network events to external Application Functions. The exposure of network events to external Application Functions may be at the RAN. The exposure of network events to external Application Functions may be at the Core Network (CN).

[0097] In the past, an Application Function may request:• A QoS monitoring for packet delay. o the UPF may use the Nupf EventExposure Notify to report QoS monitoring information.• The UL and / or DL congestion information monitoring. o The UPF reports congestion information directly to AF using a UPF based service API or via SMF / PCF / NEF.The UL and / or DL Data rate information.o PSA UPF measures and reports the information. They may be exposed to the AF directly by PSA UPF via Nupf_EventExposure service or via SMF / PCF / NEF,• The round-trip delay for two service data flows considering the UL direction of a service data flow and the DL direction of another service data flow in the same PDU Session. o PSA UPF reports the delay information per QoS Flow to the SMF. The SMF reports to PCF. The PCF derives round trip delay information based on the two direction's packet delay result for the service data flows and exposes the information to the AF directly or via NEF.• The round-trip delay for one service data flow.

[0098] The UPF and / or PCF may trigger an Application Programming Interface (API) request to report to the Application Function. For applications which traffic changes dynamically, the use of the existing methods for the notification of network events is not sufficient since by the time an API request is triggered to notify of congestion or other QoS events useful to the application it may be too late for an application to adapt. Furthermore, the AF is not the endpoint and merely a relay of such exposure information, and in effect may need to additionally trigger another API request, or alternatively publish (e.g., over Message Queuing Telemetry Transport (MQTT)) a message to expose an event to the application media server endpoint (e.g. performing the media encoding and decoding). As such, the current QoS monitoring framework (e.g. network congestion and QoS-related events exposure) may be significantly delayed in reaching the media source / encoder making it difficult in practice for applications to adapt.

[0099] Therefore, in the past, network event exposure and implicit network assistance to applications is inefficient; particularly as delay requirements of the applications decrease. For example, in 3GPP, the real-time communications subsystem for media may comprise two modes for network exposure and assistance:• AF-centric QoS monitoring based on the prior detailed network procedures:o the procedures may be limited to trusted domain deployed AF; o the UE may comprise a Media Session Handler (MSH) that subscribes to network events exposed (e.g., MQTT-based event brokerage) by the AF as the publisher; o the AF network events may include recommended QoS notifications the application may consider and apply by triggering typical control plane procedures; for example, AF requests.• Access Network Bit Rate (ANBR)-centric network assistance including: o Modify Session Header (MSH) triggering (e.g., by appropriate AT- commands such as +CGBRRREQ and +CGBRRREP) queries via the UE modem against the RAN (e.g., via Medium Access Control Control Element (MAC-CE) bit rate recommendation query and response procedures); o The RAN providing, given the network operation conditions and response, prohibit timer responses to the UE modem for the bit rate recommendation requests; o MSH fetching, from the UE modem, (e.g., by +CGBRRREP) the network bit rate recommendations and exposing them via Operating System (OS) interfaces or Software (SW) libraries to the application.

[0100] Figure 7 illustrates a flow diagram 700 for a procedure for network assistance and exposure of bit rate recommendations applicable to Real Time Control (RTC) in accordance with aspects of the present disclosure. The flow diagram 700 may be associated with the existing interactions across system actors for the RTC subsystem network exposure and assistance mechanisms.

[0101] The flow diagram illustrates signalling between an RTC endpoint (UE1) 750a, an RTC AF 751, a PCF / SMF 715, a Remote RTC endpoint 752 and a RAN 730. The RTC endpoint (UE1) 750a comprises an RTC Client 750b, which includes an RTC Access Function 750d and an RTC Media Session Handler 750e. The RTC endpoint (UE1) 750a further comprises an RTC Application 750c and a UE Modem 750f.

[0102] In step 778, the RTC AF 751 subscribes over N5 to the PCF / SMF 715 for QoS events relating to a session.

[0103] In step 779, the PCF / SMF 715 sends changes to session QoS over N5.

[0104] In step 780, the RTC AF 751 sends a bit rate recommendation (RTC-5) to theRTC Media Session Handler 750e.

[0105] The RTC Media Session Handler 750e, UE modem 750f and RAN 730 perform Application-Network Bit Rate (ANBR)-based Network Assistance in steps 781 to 783.

[0106] In step 781, the RTC Media Session Handler 750e sends an Application- Network Bit Rate Operation (ANBRO) to the UE Modem 750f.

[0107] In step 782, the UE Modem 750f and RAN 730 exchange ANBR / ANBRO (Uu).

[0108] In step 783, the UE Modem 750f sends an Application-Network Bit Rate(ANBR) to the RTC Media Session Handler 750e.

[0109] In step 784, the RTC Media Session Handler 750e sends a bit rate recommation (RTC-6) to the RTC Application 750c.

[0110] In step 785, the RTC Media Session Handler 750e adjusts a bit rate of the session.[OHl] There are shortcomings of the existing QoS framework; in particular, for adaptive application data flows.

[0112] For next-generation networks, for example 6G or 5G- Advanced, service provisioning for high bandwidth, interactive, and adaptive applications (e.g., XR or immersive experiences) may be required to ensure and application runs at high QoE levels and / or the network knows more about the application requirements, including their adaptation capabilities.

[0113] Fixed QoS metric guarantees in cellular networks for applications which are capable to adapt may create challenges in effectively distributing network resources across users and accommodating capacity needs. A fixed QoS metric guarantee may also be referred to as a hard QoS metric guarantee. These challenges may be due to given dynamicnetwork conditions; for example, for a congested network or a non-congested network. In the past, QoS flow types in 5G QoS framework may rely only on fixed QoS metrics. The QoS may be reconfigured over control plane interactions (as previously described). These control plane interactions are not fast enough to leverage application adaptation potential and / or requirements.

[0114] Furthermore, a fixed allocation of resources may overprovision network resources and, in some scenarios (e.g., loaded cells) may prohibitively use the network thereby affecting network performance and multiple users simultaneously. Table 1 summarizes current 5G QoS flow resource types and their relation to QoS metrics and parameters such as bit rate, delay / latency (PDB), and reliability (PER).

[0115] Table 1 : QoS flow resource types in 5G QoS flow framework and their relations to QoS flow metrics and parameters.

[0116] Examples described herein may relate to the improvement of QoS flow resource types and management beyond a fixed QoS flow concept and evolve towards a moredynamic (or alternatively, adaptive) QoS flow management that can cope with changing network conditions and cater for adaptive applications needs. The adaptive application needs may include a minimum bit rate vs. a target bit rate, a maximum PDB / PER vs. a target PDB / PER.

[0117] Figure 8 illustrates an architecture 800 for support of UL dynamic QoS for applications with dynamic traffic characteristics in accordance with aspects of the present disclosure.

[0118] The architecture 800 comprises an Application Function (AF) 810, a Policy Control Function (PCF) 815, a Session Management Function (SMF) 820 an Access and Mobility Management Function (AMF) 825, a Radio Access Network (RAN) 830, a User Equipment (UE) 835, a User Plane Function (UPF) 840, and an Application Service Provider (ASP) 845a. The UE 835a comprises an App 835b, a 5G modem 835d, a 6G modem 835c and a HTTP / 3 client 844b. The UPF 840 comprises a HTTP / 3 proxy 844a. An IP tunnel 850 is established between the HTTP / 3 proxy 844a and HTTP / 3 client 844b. The ASP 845a comprises an AS 845b and an App 845c.

[0119] The architecture 800 illustrates the interactions of the above network actors. The IP tunnel 850 is established between the UE 835a and the UPF 840. For example, the UE 835a implements a tunnelled encapsulation protocol client, e.g., a HTTP / 3 Connect-UDP, Connect-IP, QUIC-Aware proxy client, or similar, that connects to the UPF integrating a HTTP / 3 Connect-UDP, Connect-IP, QUIC-Aware proxy server.

[0120] Some examples described herein relate to an UL dynamic QoS flow established based on a tunneled connection of UL application data flows. The tunneled connection may be achieved by means of an encapsulated communication protocol such as Connect-UDP (according to RFC 9298), Connect-IP (according to RFC 9484), or QUIC-aware proxying.

[0121] The main system actors establishing and operating the UL dynamic QoS flow involve:

[0122] The ASP 845a may provision the AF 810 with QoS requirements and application data flow indication which may include at least one of: a 5-tuple, an application ID, a list of available Application Servers (ASes), and / or multimedia modalities descriptors.The multimedia modalities descriptors may comprise at least one of: video, audio, haptics, closed captions, and other metadata descriptors. The ASP 845a may provision the AF 810 with UL-specific QoS requirements and application data flow indication describing service requirements for UL traffic from the UE 835a to one or more ASes of the ASP 845a.

[0123] The AF 810 may request (e.g., in an AF request) a core network for a QoS session at least in part for UL traffic from the UE 835a to the core network with QoS requirements based on the ASP 845a provisioned QoS requirements and application data flow indication. The core network may comprise at least one of a 5GC, an evolved 5GC, or a 6G core network. The AF 810 may include in its request, further indications regarding application data flow, media modalities and traffic characteristics based on the ASP 845a provisioned information.

[0124] The AF 810 may further include in its request at least one of:• Transport-related indications comprising at least one of: o transport protocol and format description applicable to one or more media components (e.g., application media data flow) of the application data flow, including mapping of a media component to a transport protocol subelement (e.g., a payload type, a format type, a data frame type, a context ID, a subprotocol ID, or alike); o description of the transport protocol encapsulation of metadata including dynamic QoS adaptation requests to the network (e.g., traffic characteristics changes, QoS flow adaptation / prioritization / boost) in-band user plane signaling (as for instance based on an encapsulation protocol such as Connect-UDP, Connect-IP, QUIC-Aware proxy or any other QUIC method where metadata may be added as part of the headers of the QUIC protocol or embedded in control payloads as correspondingly defined header metadata, control frames, and / or control PDUs; and / or based on RTP extension headers where corresponding RTP packets are encapsulated by an encapsulation protocol, or alternatively, carried over vanilla UDP transport); and / oro codec information associated with each of the media components.• QoS range indication related to the necessary QoS requirements to support various Quality of Experience (QoE) for the service. The QoS range indication may comprise at least one of: o Minimum / Maximum QoS rate requirement, or alternatively a QoS requirements range for the application data flow, or alternatively adaptive QoS requirements including “soft” bit rate requirements (e.g., minimum required bit rate and desired bit rate, maximum required PDB / PER, or alternatively, PSDB / PSER, and desired Packet Delay Budget (PDB) / Packet Error Rate (PER), or alternatively, PSDB / PSER); o Default, or equivalently, expected QoS requirement; o Alternative QoS requirements as in an elevated, or equivalently, prioritized QoS requirement, or alternatively, a demoted, or equivalently, deprioritize QoS requirement complementing the default QoS requirement; and / or o Available temporary QoS requirements for data rate boost, including a minimum duration for which the QoS boost may be applicable by the network if resources allow the instantiation of the QoS boost.

[0125] The QoS requirements described above may comprise at least one of: a data rate, a latency / delay budget, a maximum error rate, maximum data burst size, and / or a minimum QoE threshold. The QoS requirements may be configured and applicable on a per packet (e.g., PDU) basis or on a per packet group (e.g., PDU Set / Application Data Unit (ADU)) basis.

[0126] The QoS requirements indications above may further be common to an application data flow (e.g., a bundled QoS applicable to all media components of the application data flow, a bundled QoS applicable to two or more modalities, e.g., audio and haptics, two video streams, or alike), or alternatively may be specific for each media component of the application data flow (e.g., QoS requirements of video media component #1, of video media component #2, of audio media component, etc.).

[0127] The AF 810 may further include in its request at least one of:• Enabled set of indications of dynamic traffic characteristics and features in handling the dynamic QoS flow operation, comprising at least one of: o Data burst size, or alternatively maximum data burst size as either bundled over all media component or per media component; o Codec information per media component, and may additionally include, alternative available codec configurations for the service (e.g., video media component may be streamed in either 720p, 1080p, 2160p as one of HD, Full HD or 4K); o Latency requirements (e.g., as packet delay requirement) for all media components; o Latency requirements (e.g., as packet delay requirement) for each media component (e.g., delay requirements for video component packets, delay requirements for audio component packets etc.); o Packet importance and / or size thresholds to determine dynamic prioritization of media component packets within the scope of the dynamic QoS flow (e.g., packets of importance higher than set threshold are moved onto a higher priority, e.g., lower delay, guaranteed delay or alike, data radio bearer associated with the dynamic QoS flow, whereas packets of importance lower or equal than set threshold are moved onto default data radio bearer associated with the dynamic QoS flow); o Selection of an available UL QoS boost configuration, the selected QoS boost being dynamically requested by a UE 835a from the core network without explicit AF interaction (e.g., for UL multimedia streaming the UE 835a may be allowed to access a data boost from 20 Mbps to 50 Mbps for at least 30 seconds if network resources are available); o Inter-media component synchronization thresholds for media delivery of the radio access network (e.g., maximum absolute Audio / Video synchronizationdelay, maximum Video / Haptic synchronization delay, maximum absolute caption / Video synchronization delay, or more generally maximum absolute media component #l / media component #2 synchronization delay etc.); and / or o Application-layer forward error correction (AL-FEC) information, e.g., codebook type such as Maximum Distance Separable (MDS) codes (e.g., Reed-Solomon), near MDS codes (Raptor / RaptorQ as per RFC 5053 / RFC 6330), FlexFEC (RFC 8627), systematic / non-systematic code, content ratio, or alternatively, redundancy ratio, number of source packets, or alternatively, number of redundant packets, discarding behavior of AL-FEC obsolete redundant packets (e.g., keep or discard in case of congestion or non-congestion) as well as QoS requirements (bit rate, delay budget, tolerable error rates) taking into account the AL-FEC configuration.

[0128] The above traffic characteristics and dynamic QoS configurations and information elements may be applicable on a per packet basis, e.g., PDU, or on a per packet group, ADU, or PDU Set basis of the application data flow, or alternatively individual media component data flows.

[0129] Information elements of the AF 810 request to the mobile network may comprise at least one of:• Including within an Nnef AFSessionwithQoS request the following information: o Flow Description (5-tuple or application ID of the packet); o Protocol Description indicating the traffic characteristics and / or QoS requirements that will be included as metadata within the user plane packet provided by the Application Server to the UPF; o Encapsulation protocol used (e.g. Connect-UDP, QUIC-Aware Proxy); o An indication to adapt QoS based on traffic characteristics; and / or o QoS requirements in priority order or default QoS requirements and elevated QoS requirements, or alternatively downgraded QoS requirements. EachQoS requirement including a pre-agreed QoS reference or one or more of the following: Requested Priority, Maximum Burst Size, Requested 5GS Delay, Requested Maximum Bitrate, Requested Guaranteed Bitrate and / or Requested Packet Error Rate.

[0130] The PCF 815 may determine a PCC rule that comprises policy parameters enforcing QoS requirements necessary to establish the dynamic QoS flow as per the AF session request. The PCC rule may comprise a new list of standardised 5QIs, or alternatively, tabulated standardized QoS configurations identifiers, wherein the new 5QIs, or equivalent, list elements may comprise ranges of traffic characteristics (e.g., maximum data burst volume, traffic type, periodicity etc.) and / or QoS parameters (e.g., delay, error rate, PDU vs. PDU Set treatment). The PCC rule may be associated with and applicable to specific applications or services based on application ID and / or 5-tuple (for example, including source, destination IP addresses, source, destination ports, and / or protocol. The protocol may be an encapsulation protocol such as Connect-UDP, Connect-IP or QUIC- Aware proxy used by the application to exchange with network in-band user plane dynamic QoS control messages for the dynamic QoS flow) The PCF may indicate a request to establish a QoS flow supporting multiple legacy 5QIs. The multiple legacy 5QIs may be sub-QoS flows. The PCF 815 communicates the PCC rule to the SMF 820.

[0131] The PCC rule may comprise at least one of:• An indication of a 5QI for dynamic QoS. The 5QI may support a range of QoS requirements;• A mapping of traffic characteristics to specific QoS requirements within the range of QoS requirements supported by the new 5QI;• An indication to establish sub-QoS flows. Each sub-QoS flow may support a legacy 5 QI; and / or• A mapping of traffic characteristics to a legacy 5QI (e.g. a mapping of burst size to a 5QI).

[0132] The SMF 820 configures the UPF 840 with the QoS rules of the dynamic QoS flow, e.g., over the N4 interface. The QoS rules may be N4 rules. The UPF 840 terminates the UL dynamic QoS flow at the N6 reference point. The UPF 840 may be further configured by the SMF 820 to detect in-band over N3 metadata originating at the RAN 830 regarding the dynamic QoS flow handling and traffic characteristics. The metadata may involve RAN network exposure events including but not limited to bit rate recommendations, source rate adaptation changes (e.g., change of source codec encoding configuration based on network available bandwidth and resources), latency statistics, etc. The UPF 840 may feedback such events to the UE 835a over the established IP tunnel under a common scope of a 5-tuple, or alternatively, an application ID. The UPF 840 may further feedback to the UE dynamic QoS flow changes as well as notify the PCF 815 of any QoS flow changes associated with the UE 5-tuple and / or application ID mapped to the dynamic QoS flow.

[0133] UPF 840 configuration rules may comprise at least one of• An indication to accept an IP tunnel connection from the UE 835a using an encapsulation protocol (e.g. Connect-UDP, QUIC Aware proxy) corresponding to the dynamic QoS flow;• An indication to inspect traffic received over N3 for application metadata (metadata may be sent over the encapsulation protocol); and / or• Routing rules to route the extracted application (e.g., UDP packet, QUIC packet etc.) towards the AS 845b.

[0134] The SMF 820 configures the RAN 830 with QoS rules associated with the dynamic QoS flow, e.g., via the AMF 825. The QoS rules may further be complemented by descriptors of the encapsulation protocol and traffic characteristics enabled indications based on the IP tunnel originating at the UE 835a.

[0135] QoS rules may comprise at least one of• A range of QoS requirements supported for a 5QI;• A mapping of traffic characteristics to specific QoS requirements within the range of QoS requirements supported by the new 5QI (e.g. mapping of burst size to specific QoS requirement); and / or• An indication of sub-flows within a QoS flow and QoS requirements per sub-QoS flow.

[0136] The SMF 820 configures the UE 835a to inspect encapsulated metadata received in user-plane at L2 ingest reference point on the UL based on the encapsulation protocol, QoS rules and media components description associated with the AF session. The UE 835a may use the SMF configuration to process the encapsulated metadata. The UE 835a may route the UL packets accordingly to the QoS rules. The UE 835a may fulfil the QoS requirements of the application given the established data radio bearers with the RAN 830 and their subsequent mapping to the dynamic QoS flow terminating at the UPF 840.

[0137] The UE 835a may receive an indication of the UPF 840 address for the encapsulation protocol tunnel session establishment. The AS 845b may signal the UE 835a out of band, e.g., based on application specific protocol / metadata and / or the address of the UPF 840. The UE 835a may be signalled by the network the address of the UPF 840. The UE 835a may further expose the latter to application layer by means of OS APIs or service interfaces.

[0138] The UE 835a may expose programmatic interfaces , e.g., APIs via OS libraries or alternatively service-based interfaces (e.g., through a media session handler or alternative session handler entity) to applications or other entities under the control of ASPs. The applications configure the UE 835a with QoS requirements for the session and a UE modem (e.g., 5G Modem 835d or 6G Modem 835c) determines the QoS rules associated with the required QoS for the session. The QoS requirements may comprise adaptive QoS parameters and characteristics, or alternatively, “soff’ / dynamic QoS requirements as detailed above. Additionally, the configuration may further comprise packet detection rules and / or protocol description information elements detailing the content delivery protocols employed by the application in UL and applicable packet detection filters. The UE 835a may apply for appropriate filtering of content and its mapping to network QoS flows and lower layers radio bearers.

[0139] The service-based interfaces may be comprised within the UE 835a (e.g., the ones exposed by a Media Session Handler, or alternatively, a tunnel Session Handler). The service-based interfaces may be used by other network functions, e.g., the AF 810, under the control of an ASP 845a to provision the UE 835a with the dynamic QoS requirements / rules and / or the associated packet detection rules and protocol description for UL traffic.

[0140] The UE 835a may access service-based interfaces exposed by other network functions under the control of an ASP 845a, e.g., such as an AF 810, to fetch a session configuration for the content delivery in UL. The configuration may comprise dynamic QoS requirements / rules and / or the associated packet detection rules and protocol description set by an ASP 845a for UL traffic.

[0141] The UE 835a and RAN 830 nodes, on reception of the QoS rules for the UL dynamic QoS, may establish the mapping of the application data flow to the enhanced 5QI corresponding to the dynamic QoS flow, further establishing the corresponding one or more data radio bearers. The RAN 830 may create separate data radio bearers corresponding to the UL dynamic QoS flow, wherein one radio bearer is associated with the default QoS of the dynamic QoS flow and the second data radio bearer mapped to the elevated QoS flow. The UE 835a may use the different radio bearers to route different packets (e.g., PDUs), or alternatively, PDU Sets over the first data radio bearer or the second data radio bearer based on the encapsulated metadata information available in the encapsulation protocol at the UE 835a. The application may use the metadata information to control the routing, e.g., prioritize among the different packets in-transit over the application data flow. The marking of metadata information may be in headers of the encapsulated payloads by the encapsulation protocol. The marking may be applied to all packets. The marking may be applied for some packets where the traffic characteristics / QoS handling requirements may change (e.g., large video data burst that may need to be handled with priority).

[0142] An application data flow may be configured by an ASP 845a with multiple dynamic QoS requirements, e.g., one dynamic QoS requirement per each media component of the application data flow, the same system actors perform the same actions described herein. Multiple dynamic QoS flows may be established in parallel for each of the mediacomponents for the application data flow as configured by the ASP 845a, or equivalently, the AF session with dynamic QoS.

[0143] Figure 9 illustrates a signalling diagram 900 procedure for enabling support of UL dynamic QoS for applications with dynamic traffic characteristics in accordance with aspects of the present disclosure.

[0144] The signalling diagram 900 illustrates the messages sent / received between a UE (QUIC client) 935, a RAN 930, an AMF 925, a UPF (QUIC server) 940, an SMF 920, a PCF 915, an AF 910 and UE Service Data Adaptation Protocol (SDAP) entity 937. The AMF 925, UPF (QUIC server) 940, SMF 920, PCF 915, and AF 910 may be part of a Core Network (CN). The CN may be a 5G CN. The CN may be a 6G CN. The terms AF, NEF, PCF, AMF, SMF and / or UPF are typically used in relation to a 5G CN but may be replaced with relevant terms in 6G CN.

[0145] In step 970a, the ASP 947 provisions the AF 910 with Service Access Information, Dynamic Policies Templates, Network Assistance and Monitoring Provisioning for an application. The Service Access Information may comprise information regarding the endpoint of the service (e.g., server address, service URL or equivalent), server / edge resources available to the service as well as encapsulation protocols and network UPFs available for the dynamic QoS establishment corresponding to the Dynamic Policies Templates. The Dynamic Policies Templates may include indications of the QoS requirements of the service data fl ow / appli cation data flow, including dynamic QoS requirements, protocol, media, format and codec descriptions, traffic characteristics and traffic characteristics changes description.

[0146] In step 970b, the UE 935 acquires the Service Access Information including indication on use of Dynamic Policies and instantiation of dynamic QoS by means of out- of-band signalling. This may imply communication (e.g., over a best effort QoS flow, or alike) to fetch updated Service Access Information, from the ASP, e.g., directly over M8 5G media delivery interface, or from the provisioned AF 910 via at least the M5 media delivery control interface.

[0147] In step 971, the UE client 935 may activate a Dynamic Policy Template for dynamic QoS flow from the AF 910 based on the available Service Access Information and Dynamic Policy information.

[0148] In step 972, the AF 910 requests on behalf of the UE 935 by means of an AF session with QoS requirements API an AF session with dynamic QoS requirements as per the Dynamic Policy Template activated. The request may comprise application descriptors (e.g. 5-tuple, application ID), address of the content server as per the Service Access Information, an indication that the application traffic characteristics are changing dynamically and / or dynamic QoS requirements. As such, the dynamic QoS requirements may include a range of QoS requirements, or alternative QoS requirements. The AF 910 may submit the request to a PCF 915, or alternatively to a NEF.

[0149] In step 973, the PCF 915 receives the request (the PCF 915 may receive the request via the NEF) and determines PCC rules that are sent to an SMF 920. The PCC rules may include an indication to establish a QoS flow with dynamic QoS, or alternatively, a dynamic QoS flow.

[0150] In step 974, the SMF 920 determines configuration rules for the UPF 940, RAN 930 and UE 935 based on the PCC rules received as one of:• The configuration rules to the UPF 940 (e.g., shared over the N4 interface or alike) include at least one of: o An indication to start listening to an IP tunnelled connection request from the UE 935 using an encapsulation protocol (e.g. Connect-UDP, Connect-IP, QUIC-Aware proxy) associated with the dynamic QoS flow; o An indication containing packet detection rules to inspect traffic received over N3 for application metadata generated by the client UE 935 and encapsulated in the encapsulation protocol; and / or o An indication containing packet detection rules to inspect traffic received over N3 for access network metadata generated by a RAN 930, the metadataencapsulated as part of the GTP-U header tunnelling the RAN 930 to UPF 940 user plane traffic associated with the dynamic QoS flow over N3;• The configuration rules to the RAN 930 may include at least one of: o An indication to establish at least an UL dynamic QoS flow and the associated range of QoS requirements. The RAN 930 may establish one or more data radio bearers to serve the dynamic QoS flow based on the associated QoS requirements (e.g., a default data radio bearer and an elevated data radio bearer for dynamic QoS flow boost); and / or o An indication to publish network events in-band UL over N3, the network events related to RAN 930 behaviour / QoS changes and available RAN 930 resources for the dynamic QoS flow (e.g., available bit rate, bandwidth drop, bandwidth increase, predicted expected bit rate for a next time duration, predicted QoS drop, or alternatively predicted QoS increase, predicted congestion event etc.), the network events encapsulated as metadata comprised in the GTP-U tunnel headers from RAN 930 to UPF 940 over N3 interface.• The configuration rules to the UE 935 may include at least one of: o An indication to request an IP tunnelled connection from the UPF 940 using an encapsulation protocol (e.g., Connect-UDP, Connect-IP, QUIC-Aware proxy) establish at least an UL dynamic QoS flow and the associated range of QoS requirements; and / or o An indication comprising packet detection rules to inspect traffic egress from the application, a mapping of the packets to one or more data radio bearers as per the dynamic QoS configuration rules and marking rules for dynamic QoS flow and / or dynamic traffic characteristic changes. The metadata may be encapsulated in the IP encapsulation protocol, and the marking may be used by the client UE in requesting the network dynamic QoS changes either directly, or indirectly by means of dynamic traffic characteristics triggers.

[0151] In step 975, the SMF 920 sends the UPF configuration rules to the UPF 940 (e.g. via N4 reference point).

[0152] In step 976, the SMF 920 sends the RAN configuration rules to the RAN 930 (e.g. via the AMF 925).

[0153] In step 977, the SMF 920 sends the UE configuration rules to the UE 935 (e.g., by means of NAS signalling over the N1 reference point via the AMF 925).

[0154] In step 978, the UE tunnel client (e.g., HTTP / 3 client) establishes the IP tunnel connection with the UPF tunnel proxy corresponding to the dynamic QoS flow by means of an encapsulation protocol such as Connect-UDP, Connect-IP, QUIC-Aware proxy.

[0155] In step 979, the UE tunnel client applies the packet detection rules and QoS rules configured to encapsulate the incoming packets in the encapsulation protocol and filter them accordingly to the dynamic QoS and dynamic traffic characteristics rules for mapping to one or more data radio bearers, associated with the dynamic QoS flow.

[0156] For example, the UE tunnel client may detect based on the packet detection rules packets, or alternatively, PDU Sets of different priority and / or different sizes and filter them accordingly to different mappable to two data radio bearers, e.g., large, or alternatively, high importance, video PDU Set to elevated data radio bearer, and all other PDU Sets and packets to the default data radio bearer.

[0157] In step 980, the UE SDAP entity 937 applies the mapping of the packets to the respective data radio bearers as per dynamic QoS configuration rules and UE tunnel client filtering and encapsulates the IP packet into the according radio protocols (including the appropriate QFI marking). The packets are sent to the RAN SDAP entity.

[0158] For example, the UE HTTP / 3 client may utilize the Connect-UDP Context ID to encapsulate extended UDP -based traffic in UL within the HTTP / 3 encapsulation protocol over QUIC transport. The HTTP datagram proxying a UDP datagram may use the Context ID to indicate to lower layers (e.g. SDAP, or any alternative layer pre-SDAP) that the HTTP datagram payload may contain a certain payload type (e.g., high / low priority video, high / low priority audio, high / low priority haptics, and control metadata or combinationsthereof). In an example a Context ID 0x02 may indicate default video content with QoS flow control metadata header pre-pended to a UDP datagram, and ID 0x04 may indicate elevated priority video content with QoS flow control metadata header pre-pended to a UDP datagram. The SDAP layer or similar may use the context ID for mapping the proxied content accordingly to a DRB in UL associated with a dynamic QoS flow. The QoS flow control metadata may be further used by SDAP in the mapping to finely control the mapping of each PDU / PDU Set to a specific DRB in UL while considering data burst / PDU Set traffic characteristics such as burst / PDU Set size, delay requirements, dynamic boost requirements etc.

[0159] In another example, QUIC traffic may be similarly proxied and filtered with the help of QUIC-aware proxy encapsulation protocols over HTTP, e.g., HTTP / 3, such as (IETF MASQUE). The QUIC Connection IDs, or alternatively, Stream IDs dynamic registration and retirement may be used as a mechanism to separate different packets of the application data flows, e.g., default video stream and elevated video stream packets and signal to SDAP which packets may be routed between default and elevated DRBs in UL, or alternatively, which packets may comprise of additional packet headers accessible within the encapsulated payloads. The packet headers may include control metadata information elements that can further aid SDAP or alike layers make a decision regarding dynamic routing of packets based on dynamic QoS requirements and traffic characteristics described previously. In other examples the UE HTTP / 3 QUIC-aware proxy client may further apply a packet transform instead of simple forwarded encapsulation of packets. The packet transform may include a specific proxied payload (e.g., a UDP payload conforming with QUIC invariants format as per RFC 8999 not modifying the Connection ID), wherein the proxied payload may comprise at least the original QUIC packet payload, and additional dynamic QoS control hints and traffic characteristics metadata. The metadata may be authenticated and / or encrypted, yet the SDAP or similar layers are expected to be configured (e.g., by the HTTP / 3 client within the UE 935, for instance in a secure environment within the domain of the UE modem functionality) with the metadata security keys outside of the encryption context of QUIC packet payload. When authenticati on / encry ption of metadata is enabled, the UE 935 may similarly share security keys with UPF 940. The derivation of security keys for authenticati on / encry ption ofmetadata information as part of QUIC-aware proxying with packet transforms is not covered herein and is subject to additional security procedures.

[0160] In step 981, the RAN 930 notifies the QoS enforced to the PCF 915 (e.g., via AMF 925 / SMF 920, or directly via an alternative service-based interface).

[0161] In step 982, the RAN 930 notifies the UPF 940 of the dynamic QoS changes (e.g., by means of GTP-U headers metadata). The dynamic QoS changes may include predictive QoS changes based on RAN-based prediction of QoS events, e.g., QoS degradation, QoS elevation, given the available RAN communication resources.

[0162] The flow described above and the encapsulation protocol may be used to request in-band a temporary dynamic boost of a dynamic QoS flow. The boost of the dynamic QoS flow may apply to at least one of the default QoS characteristics or alternate QoS characteristics (e.g., elevated, or downgraded) of a dynamic QoS flow according to the Dynamic Policy Templates available. The UE may use in-band metadata control frames encapsulated in the encapsulation protocol (Connect-UDP, Connect-IP, QUIC-Aware Proxy). The UPF 940 configured with the packet detection rules and descriptors for the encapsulated metadata within the dynamic QoS flow may filter and process the client UE 935 request for a boost for some of the UL dynamic QoS flow characteristics (e.g., latency requirement for default QoS requirements, latency and bandwidth requirements for elevated QoS requirements etc.). The UPF 940 based on available information from the RAN 930 regarding the current QoS (e.g., signalled either by GTP-U headers encapsulated metadata direct in-band in user plane, or by means of SBI, e.g., via AMF 925 / SMF 920 or other new NF) may temporarily elevate the dynamic QoS flow characteristics and inform the PCF 915, SMF 920 and RAN 930 about the dynamic QoS change and its applicable duration (e.g., lower latency of default QoS requirements by 5ms for the next 30 seconds, or alike). The communication with the other network actors (e.g., PCF 915, SMF 920, AMF 925 / RAN 930) may happen over SBI (e.g., PCF 915, SMF 920, AMF 925, or other new NF handling dynamic network changes) or in-band where possible via IP tunnelled interfaces (e.g., GTP-U header metadata instructing RAN 930 about the temporary changes).

[0163] Figure 10 illustrates an example of a UE 1000 in accordance with aspects of the present disclosure. The UE 1000 may include a processor 1002, a memory 1004, acontroller 1006, and a transceiver 1008. The processor 1002, the memory 1004, the controller 1006, or the transceiver 1008, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0164] The processor 1002, the memory 1004, the controller 1006, or the transceiver 1008, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0165] The processor 1002 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 1002 may be configured to operate the memory 1004. In some other implementations, the memory 1004 may be integrated into the processor 1002. The processor 1002 may be configured to execute computer-readable instructions stored in the memory 1004 to cause the UE 1000 to perform various functions of the present disclosure.

[0166] The memory 1004 may include volatile or non-volatile memory. The memory 1004 may store computer-readable, computer-executable code including instructions when executed by the processor 1002 cause the UE 1000 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1004 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0167] In some implementations, the processor 1002 and the memory 1004 coupled with the processor 1002 may be configured to cause the UE 1000 to perform one or more ofthe functions described herein (e.g., executing, by the processor 1002, instructions stored in the memory 1004). For example, the processor 1002 may support wireless communication at the UE 1000 in accordance with examples as disclosed herein. The UE 1000 may be configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable. The UE 1000 may be configured to support a means for receiving, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of the data flow for the data packet; determining the particular QoS requirement for the data packet based at least in part on the additional data and routing the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

[0168] The controller 1006 may manage input and output signals for the UE 1000. The controller 1006 may also manage peripherals not integrated into the UE 1000. In some implementations, the controller 1006 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1006 may be implemented as part of the processor 1002.

[0169] In some implementations, the UE 1000 may include at least one transceiver 1008. In some other implementations, the UE 1000 may have more than one transceiver 1008. The transceiver 1008 may represent a wireless transceiver. The transceiver 1008 may include one or more receiver chains 1010, one or more transmitter chains 1012, or a combination thereof.

[0170] A receiver chain 1010 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1010 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1010 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal. The receiver chain 1010 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1010 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0171] A transmitter chain 1012 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1012 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 1012 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1012 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0172] Figure 11 illustrates an example of a processor 1100 in accordance with aspects of the present disclosure. The processor 1100 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1100 may include a controller 1102 configured to perform various operations in accordance with examples as described herein. The processor 1100 may optionally include at least one memory 1104, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 1100 may optionally include one or more arithmetic-logic units (ALUs) 1106. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0173] The processor 1100 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 1100) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).

[0174] The controller 1102 may be configured to manage and coordinate various operations (e.g., signalling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 1100 to cause the processor 1100 to support various operations in accordance with examples as described herein. For example, the controller 1102 may operate as a control unit of the processor 1100, generating control signals that manage the operation of various components of the processor 1100. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0175] The controller 1102 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1104 and determine subsequent instruction(s) to be executed to cause the processor 1100 to support various operations in accordance with examples as described herein. The controller 1102 may be configured to track memory address of instructions associated with the memory 1104. The controller 1102 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1102 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1100 to cause the processor 1100 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1102 may be configured to manage flow of data within the processor 1100. The controller 1102 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 1100.

[0176] The memory 1104 may include one or more caches (e.g., memory local to or included in the processor 1100 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 1104 may reside within or on a processor chipset (e.g., local to the processor 1100). In some other implementations, the memory 1104 may reside external to the processor chipset (e.g., remote to the processor 1100).

[0177] The memory 1104 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1100, cause the processor 1100to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 1102 and / or the processor 1100 may be configured to execute computer-readable instructions stored in the memory 1104 to cause the processor 1100 to perform various functions. For example, the processor 1100 and / or the controller 1102 may be coupled with or to the memory 1104, the processor 1100, the controller 1102, and the memory 1104 may be configured to perform various functions described herein. In some examples, the processor 1100 may include multiple processors and the memory 1104 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0178] The one or more ALUs 1106 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1106 may reside within or on a processor chipset (e.g., the processor 1100). In some other implementations, the one or more ALUs 1106 may reside external to the processor chipset (e.g., the processor 1100). One or more ALUs 1106 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1106 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1106 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1106 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not-AND (NAND), enabling the one or more ALUs 1106 to handle conditional operations, comparisons, and bitwise operations.

[0179] The processor 1100 may support wireless communication in accordance with examples as disclosed herein. The processor 1100 may be configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable. The processor 1100 may be configured to support a means for receiving, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of the data flow for the data packet; determining the particularQoS requirement for the data packet based at least in part on the additional data and routing the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow. Alternatively, the processor 1100 may be configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable, and wherein a plurality of radio bearers is established for the data flow. The processor 1100 may be configured to or operable to support a means for receiving, from a user equipment, UE, via a first radio bearer of the plurality of radio bearers, a data packet, the data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of the data flow for the data packet.

[0180] Figure 12 illustrates an example of a NE 1200 in accordance with aspects of the present disclosure. The NE 1200 may include a processor 1202, a memory 1204, a controller 1206, and a transceiver 1208. The processor 1202, the memory 1204, the controller 1206, or the transceiver 1208, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0181] The processor 1202, the memory 1204, the controller 1206, or the transceiver 1208, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0182] The processor 1202 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 1202 may be configured to operate the memory 1204. In some other implementations, the memory 1204 may be integrated into the processor 1202. The processor 1202 may be configured to execute computer-readable instructions stored in the memory 1204 to cause the NE 1200 to perform various functions of the present disclosure.

[0183] The memory 1204 may include volatile or non-volatile memory. The memory 1204 may store computer-readable, computer-executable code including instructions when executed by the processor 1202 cause the NE 1200 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1204 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0184] In some implementations, the processor 1202 and the memory 1204 coupled with the processor 1202 may be configured to cause the NE 1200 to perform one or more of the functions described herein (e.g., executing, by the processor 1202, instructions stored in the memory 1204). For example, the processor 1202 may support wireless communication at the NE 1200 in accordance with examples as disclosed herein. The NE 1200 may be configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable, and wherein a plurality of radio bearers is established for the data flow. The NE 1200 may be configured to support a means for receiving, from a user equipment, UE, via a first radio bearer of the plurality of radio bearers, a data packet, the data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of the data flow for the data packet.

[0185] The controller 1206 may manage input and output signals for the NE 1200. The controller 1206 may also manage peripherals not integrated into the NE 1200. In some implementations, the controller 1206 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1206 may be implemented as part of the processor 1202.

[0186] In some implementations, the NE 1200 may include at least one transceiver 1208. In some other implementations, the NE 1200 may have more than one transceiver 1208. The transceiver 1208 may represent a wireless transceiver. The transceiver 1208 may include one or more receiver chains 1210, one or more transmitter chains 1212, or a combination thereof.

[0187] A receiver chain 1210 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1210 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1210 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal. The receiver chain 1210 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1210 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0188] A transmitter chain 1212 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1212 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 1212 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1212 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0189] Figure 13 illustrates a flowchart of a method 1300 in accordance with aspects of the present disclosure. The operations of the method may be implemented by a UE as described herein. In some implementations, the UE may execute a set of instructions to control the function elements of the UE to perform the described functions. The UE may be configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable.

[0190] At 1302, the method 1300 may include receiving, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of the data flow for the data packet. The operations of 1302 may be performed in accordance with examples as described herein. In someimplementations, aspects of the operations of 1302 may be performed by a UE as described with reference to Figure 10.

[0191] At 1304, the method 1300 may include determining the particular QoS requirement for the data packet based at least in part on the additional data. The operations of 1304 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1304 may be performed by a UE as described with reference to Figure 10.

[0192] At 1306, the method 1300 may include routing the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow. The operations of 1306 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1306 may be performed a UE as described with reference to Figure 10.

[0193] It should be noted that the method 1300 described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0194] Figure 14 illustrates a flowchart of a method 1400 in accordance with aspects of the present disclosure. The operations of the method 1400 may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions. The NE may be configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable, and wherein a plurality of radio bearers is established for the data flow

[0195] At 1402, the method 1400 may include establishing a plurality of radio bearers for a data flow, wherein a quality of service, QoS, of the data flow is adaptable. The operations of 1402 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1402 may be performed by a NE as described with reference to Figure 12.

[0196] At 1404, the method 1400 may include receiving, from a user equipment, UE, via a first radio bearer of the plurality of radio bearers, a data packet, the data packet comprising additional data, wherein the additional data comprises information fordetermining a particular QoS of the data flow for the data packet. The operations of 1404 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1404 may be performed by a NE as described with reference to Figure 12.

[0197] There is provided a user equipment, UE, for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: receive, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS requirement of a data flow for the data packet; determine the particular QoS requirement for the data packet based at least in part on the additional data; and route the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

[0198] Such a UE tends to reduce the delay in changing the QoS handling of the data flow for the data packet. The UE may be configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable.

[0199] The UE may be a remote unit. The first radio bearer may be a data radio bearer, DRB. Each of the plurality of radio bearers may be a DRB. The data packet may be a packet data unit, PDU. The PDU may belong to a PDU set. The information for determining the particular QoS of the data flow for the data packet may comprise a traffic characteristic of the data packet. The information for determining the particular QoS of the data flow for the data packet may comprise a traffic characteristic of the data packet set. The information for determining the particular QoS of the data flow for the data packet may comprise a traffic characteristic of the PDU set. The information for determining the particular QoS of the data flow for the data packet may comprise the QoS requirement for the data packet. The data flow may be part of a QoS flow. The QoS flow may be adaptable. The QoS flow may be an adaptive QoS flow. The QoS flow may serve one or more data flow(s). The data flow may comprise an adaptive QoS requirement. The data flow may be an uplink data flow. The data flow may comprise an application data flow with application data packets. The additional data may be control metadata. The control metadata may comprise a QoS control information element. The QoS control information element maycomprise at least one of: a QoS Flow Indicator, a QoS preferred parameter, and / or a QoS minimum required parameter. The QoS preferred parameter may comprise at least one of: a delay budget, a bit rate, and / or an error rate.

[0200] The additional data may be metadata. The additional data may describe an attribute of the data packet. The additional data may describe an attribute of traffic over the application data flow. The additional data may describe an attribute of traffic mapped over the data flow. The additional data may describe an attribute of traffic mapped over the adaptive QoS flow. The additional data may complement source encoded information. The data packet may comprise source encoded information. The source encoded information may relate to at least of video data, audio data, haptic data, and / or generally application data. The data packet may relate to at least of video data, audio data, haptic data, and / or generally application data. The additional data may complement source encoded application data. The source encoded application data may relate to at least one of a video frame, a video slice, an audio frame, an audio channel, and / or haptic data. The additional data may provide in-band additional information related to QoS treatment of the data flow. The in-band additional information related to QoS treatment of the data flow may comprise QoS requirements for the data packet of the data flow. The additional data may provide in- band additional information related to encapsulated application data packets of the data flow.

[0201] The at least one processor coupled with the at least one memory may be further configured to cause the UE to: receive configuration information for the data flow, wherein the configuration information comprises at least one of: a range of QoS requirements for the QoS of the data flow comprising a set of QoS parameters as QoS rules; an access information tuple corresponding to an encapsulation protocol of the data flow; a packet transform configuration applicable to one or more data packets encapsulated within the encapsulation protocol; a protocol description comprising a packet filter applicable to the data packet of the application data flow; and / or an additional data configuration and a packet filter configuration for the encapsulation protocol.

[0202] The access information tuple corresponding to the encapsulation protocol may comprise a 5-tuple associated with a proxy connection of the data flow. The accessinformation tuple corresponding to the encapsulation protocol may comprise at least one of a source IP, a destination IP, a source port and / or a protocol identifier.

[0203] The range of QoS requirements for the QoS of the data flow may comprise one or more QoS rule(s). Each of the one or more QoS rule(s) may comprise the set of QoS parameters. The set of QoS parameters may be aggregated under one QoS rule of the one or more QoS rule(s). Each of the QoS parameters in the set of QoS parameters may be allocated one QoS rule of the one or more QoS rule(s). The one or more QoS rule(s) may be aggregated at a top level. The top level aggregation may be performed per QoS flow.

[0204] The configuration information for the data flow may include one or more packet filters. The packet filters may be used by the UE to appropriately detect application data packets, map application data packets to QoS rules, and encapsulate, mark and / or transform their corresponding data flow data packets with additional data within the encapsulation protocol.

[0205] The at least one processor coupled with the at least one memory may be further configured to cause the UE to: encapsulate the data packet according to the encapsulation protocol to generate an encapsulated data packet. The encapsulation protocol may comprise encapsulating application data packets within the data packets of the data flow. The encapsulation may include applying a packet transform to the application data flow data packets. The resulted encapsulated packets of the data flow may include the application data packets, or alternatively their transformed payloads, and additional data.

[0206] The at least one processor coupled with the at least one memory may be further configured to cause the UE to: mark the encapsulated data packet with the additional data.

[0207] The at least one processor coupled with the at least one memory being configured to cause the UE to mark the encapsulated data packet with the additional data may comprise the at least one processor coupled with the at least one memory being further configured to cause the UE to: mark the additional data within headers of a payload proxied in the encapsulation protocol.

[0208] The encapsulation protocol may be based on at least one of a Connect-UDP, QUIC-aware proxy, and / or Connect-IP tunnel. The additional data may comprise anadditional data format. The additional data format may be determined based on the encapsulation protocol. The encapsulation protocol may comprise an encapsulated protocol format. The additional data format may be determined based on the encapsulated protocol format. The encapsulation protocol may comprise an encapsulated protocol format. The additional data format may be determined based on a proxied protocol format. The additional data format may be based on a proxied protocol metadata format. The proxied protocol metadata format may comprise a real time transport protocol, RTP, / secure real time transport protocol, SRTP, with RTP header extensions for metadata marking. The RTP / SRTP with RTP header extensions for metadata marking may comprise a PDU Set marking. The proxied protocol metadata format may comprise UDP packets with UDP- Options enabled for UDP datagrams marking. The proxied protocol metadata format may comprise a HTTP datagram Context ID of the encapsulation protocol tunnel. The HTTP datagram Context ID of the encapsulation protocol tunnel may comprise a HTTP / 3 transport for encapsulation. The proxied protocol metadata format may comprise a Capsule Type. The Capsule Type may comprise a non-HTTP / 3 transport for encapsulation. The non-HTTP / 3 transport may comprise a HTTP 1.1 transport. The non-HTTP / 3 transport may comprise a HTTP2 transport. The encapsulation protocol may define its own additional data format.

[0209] The at least one processor coupled with the at least one memory being configured to cause the UE to mark the encapsulated data packet with the additional data may comprise the at least one processor coupled with the at least one memory being further configured to cause the UE to: mark the encapsulated data packet with the additional data based at least in part on a mapping of at least one of: a data packet type, a data packet format, and a data packet priority to the range of QoS requirements.

[0210] The data packet type may be a media type. The data packet format may be a media format. The data packet priority may be at least one of a media priority, a stream priority and datagram priority. The media priority may be proxied based on a transportlevel priority. The transport-level priority may be mapped to stream priority. The transportlevel priority may be mapped to datagram priority. The media priority may be an audio priority high, or a video priority medium. The range of QoS requirements may relate to atleast one of the media type, media format and / or the media priority as mapped by the one or more QoS rule(s) and one or more QoS Flow Identifiers, QFI.

[0211] The encapsulation protocol may be based on a tunneled connection to a proxying server by means of a hypertext transfer protocol, HTTP, proxy client. The HTTP proxy client may be a HTTP / 2 client. The HTTP proxy client may be a HTTP / 3 client. The HTTP proxy client may utilize extended CONNECT HTTP semantics to establish a tunneled connection. The tunneled connection may comprise as an encapsulation protocol at least one of: a QUIC-aware proxying connection; a Connect-UDP connection; and / or a Connect-IP connection. The tunneled connection may comprise at a network transport level at least one of a QUIC connection, a QUIC stream, a QUIC datagram and / or a user datagram protocol, UDP, connection.

[0212] The set of QoS parameters may comprise a set of default QoS parameters. The set of QoS parameters may further comprise a set of modified QoS parameters. The set of modified QoS parameters may be a set of elevated QoS parameters relative to the set of default QoS parameters. The QoS parameters in the set of elevated QoS parameters may be higher than the QoS parameters in the set of default QoS parameters. The set of modified QoS parameters may be a set of downgraded QoS parameters relative to the set of default QoS parameters. The QoS parameters in the set of downgraded QoS parameters may be lower than the QoS parameters in the set of default QoS parameters

[0213] The set of QoS parameters may comprise at least one of: a desired bit rate; a minimum bit rate; a desired packet delay budget; a maximum packet delay budget; a desired packet error rate; a maximum packet error rate; a desired data packet set delay budget; a maximum data packet set delay budget; a desired data packet set error rate; and / or a maximum data packet set error rate.

[0214] The first radio bearer may be configured according to the set of QoS parameters. The first radio bearer may be configured according to the default set of QoS parameters. The first radio bearer may be configured according to the modified set of QoS parameters. The method may further comprise selecting the first radio bearer of the plurality of radio bearers based at least in part on the additional data. The at least one processor coupled withthe at least one memory may be further configured to cause the UE to configure the first radio bearer according to the set of QoS parameters.

[0215] The additional data may comprise at least one of: an identifier of at least one of: a payload format, type and representation; a traffic burst size indication; a media type and codec information; an application-layer forward error correction (FEC) configuration; an indication of modified QoS requirements; QoS requirements for one or more data packets of the application data flow; a temporary boost indication of QoS and a combination thereof.

[0216] The application-layer FEC configuration may comprise at least one of: a FEC type, a content ratio, a number of source data packets, and / or a number of redundant data packets.

[0217] The indication of modified QoS requirements may comprise a per packet indication of modified QoS requirements. The QoS requirements for one or more data packets of the application data flow may comprise a dynamic QoS requirement for one or more data packets of the application data flow.

[0218] The dynamic QoS requirements may comprise at least one of a bit rate, a data packet delay budget, and / or a data packet error rate. The dynamic QoS requirements may be for one or more data packets of the application data flow. The dynamic QoS requirements additional data signaling may utilize the set of QoS requirements configured.

[0219] The temporary boost indication may indicate a request for an elevated QoS handling comprised by the adaptive QoS flow.

[0220] There is further provided a processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: receive, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS requirement of a data flow for the data packet; determine the particular QoS requirement for the data packet based at least in part on the additional data; and route the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

[0221] Such a processor tends to reduce the delay in changing the QoS handling of the data flow for the data packet. The processor may be configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable.

[0222] There is further provided a method performed by a user equipment, UE, wherein the UE is configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable, the method comprising: receiving, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS requirement of the data flow for the data packet; determining the particular QoS requirement for the data packet based at least in part on the additional data; and routing the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

[0223] Such a method tends to reduce the delay in changing the QoS handling of the data flow for the data packet.

[0224] The UE may be a remote unit. The first radio bearer may be a data radio bearer, DRB. Each of the plurality of radio bearers may be a DRB. The data packet may be a packet data unit, PDU. The PDU may belong to a PDU set. The information for determining the particular QoS of the data flow for the data packet may comprise a traffic characteristic of the data packet. The information for determining the particular QoS of the data flow for the data packet may comprise a traffic characteristic of the data packet set. The information for determining the particular QoS of the data flow for the data packet may comprise a traffic characteristic of the PDU set. The information for determining the particular QoS of the data flow for the data packet may comprise the QoS requirement for the data packet. The data flow may be part of a QoS flow. The QoS flow may be adaptable. The QoS flow may be an adaptive QoS flow. The QoS flow may serve one or more data flow(s). The data flow may comprise an adaptive QoS requirement. The data flow may be an uplink data flow. The data flow may comprise an application data flow with application data packets. The additional data may be control metadata. The control metadata may comprise a QoS control information element. The QoS control information element may comprise at least one of: a QoS Flow Indicator, a QoS preferred parameter, and / or a QoSminimum required parameter. The QoS preferred parameter may comprise at least one of: a delay budget, a bit rate, and / or an error rate.

[0225] The additional data may be metadata. The additional data may describe an attribute of the data packet. The additional data may describe an attribute of traffic over the application data flow. The additional data may describe an attribute of traffic mapped over the data flow. The additional data may describe an attribute of traffic mapped over the adaptive QoS flow. The additional data may complement source encoded information. The data packet may comprise source encoded information. The source encoded information may relate to at least of video data, audio data, haptic data, and / or generally application data. The data packet may relate to at least of video data, audio data, haptic data, and / or generally application data. The additional data may complement source encoded application data. The source encoded application data may relate to at least one of a video frame, a video slice, an audio frame, an audio channel, and / or haptic data. The additional data may provide in-band additional information related to QoS treatment of the data flow. The in-band additional information related to QoS treatment of the data flow may comprise QoS requirements for the data packet of the data flow. The additional data may provide in- band additional information related to encapsulated application data packets of the data flow.

[0226] The method may further comprise receiving configuration information for the data flow, wherein the configuration information comprises at least one of: a range of QoS requirements for the QoS of the data flow comprising a set of QoS parameters as QoS rules; an access information tuple corresponding to an encapsulation protocol of the data flow; a packet transform configuration applicable to one or more data packets encapsulated according to the encapsulation protocol; a protocol description comprising a packet filter applicable to the data packet of the application data flow; an additional data configuration and a packet filter configuration for the encapsulation protocol and a combination thereof.

[0227] The access information tuple corresponding to the encapsulation protocol may comprise a 5-tuple associated with a proxy connection of the data flow. The access information tuple corresponding to the encapsulation protocol may comprise at least one of a source IP, a destination IP, a source port and / or a protocol identifier.

[0228] The range of QoS requirements for the QoS of the data flow may comprise one or more QoS rule(s). Each of the one or more QoS rule(s) may comprise the set of QoS parameters. The set of QoS parameters may be aggregated under one QoS rule of the one or more QoS rule(s). Each of the QoS parameters in the set of QoS parameters may be allocated one QoS rule of the one or more QoS rule(s). The one or more QoS rule(s) may be aggregated at a top level. The top level aggregation may be performed per QoS flow.

[0229] The configuration information for the data flow may include one or more packet filters. The packet filters may be used by the UE to appropriately detect application data packets, map application data packets to QoS rules, and encapsulate, mark and / or transform their corresponding data flow data packets with additional data within the encapsulation protocol.

[0230] The method may further comprise encapsulating the data packet according to the encapsulation protocol to generate an encapsulated data packet. The encapsulation protocol may comprise encapsulating application data packets within the data packets of the data flow. The encapsulation may include applying a packet transform to the application data flow data packets. The resulted encapsulated packets of the data flow may include the application data packets, or alternatively their transformed payloads, and additional data.

[0231] The method may further comprise: marking the encapsulated data packet with the additional data. Marking the encapsulated data packet with the additional data may comprise marking the additional data within headers of a payload proxied in the encapsulation protocol.

[0232] The encapsulation protocol may be based on at least one of a Connect-UDP, QUIC-aware proxy, and / or Connect-IP tunnel. The additional data may comprise an additional data format. The additional data format may be determined based on the encapsulation protocol. The encapsulation protocol may comprise an encapsulated protocol format. The additional data format may be determined based on the encapsulated protocol format. The encapsulation protocol may comprise an encapsulated protocol format. The additional data format may be determined based on a proxied protocol format. The additional data format may be based on a proxied protocol metadata format. The proxied protocol metadata format may comprise a real time transport protocol, RTP, / secure realtime transport protocol, SRTP, with RTP header extensions for metadata marking. The RTP / SRTP with RTP header extensions for metadata marking may comprise a PDU Set marking. The proxied protocol metadata format may comprise UDP packets with UDP- Options enabled for UDP datagrams marking. The proxied protocol metadata format may comprise a HTTP datagram Context ID of the encapsulation protocol tunnel. The HTTP datagram Context ID of the encapsulation protocol tunnel may comprise a HTTP / 3 transport for encapsulation. The proxied protocol metadata format may comprise a Capsule Type. The Capsule Type may comprise a non-HTTP / 3 transport for encapsulation. The non-HTTP / 3 transport may comprise a HTTP 1.1 transport. The non-HTTP / 3 transport may comprise a HTTP2 transport. The encapsulation protocol may define its own additional data format.

[0233] Marking the encapsulated data packet with the additional data may comprise marking the encapsulated data packet with the additional data based on a mapping of at least one of: a data packet type, a data packet format, and / or a data packet priority to the range of QoS requirements

[0234] The data packet type may be a media type. The data packet format may be a media format. The data packet priority may be at least one of a media priority, a stream priority and datagram priority. The media priority may be proxied based on a transportlevel priority. The transport-level priority may be mapped to stream priority. The transportlevel priority may be mapped to datagram priority. The media priority may be an audio priority high, or a video priority medium. The range of QoS requirements may relate to at least one of the media type, media format and / or the media priority as mapped by the one or more QoS rule(s) and one or more QoS Flow Identifiers, QFI.

[0235] The encapsulation protocol may be based on a tunneled connection to a proxying server by means of a hypertext transfer protocol, HTTP, proxy client. The HTTP proxy client may be a HTTP / 2 client. The HTTP proxy client may be a HTTP / 3 client. The HTTP proxy client may utilize extended CONNECT HTTP semantics to establish a tunneled connection. The tunneled connection may comprise as an encapsulation protocol at least one of: a QUIC-aware proxying connection; a Connect-UDP connection; and / or a Connect-IP connection. The tunneled connection may comprise at a network transport levelat least one of a QUIC connection, a QUIC stream, a QUIC datagram and / or a user datagram protocol, UDP, connection.

[0236] The set of QoS parameters may comprise a set of default QoS parameters. The set of QoS parameters may further comprise a set of modified QoS parameters. The set of modified QoS parameters may be a set of elevated QoS parameters relative to the set of default QoS parameters. The QoS parameters in the set of elevated QoS parameters may be higher than the QoS parameters in the set of default QoS parameters. The set of modified QoS parameters may be a set of downgraded QoS parameters relative to the set of default QoS parameters. The QoS parameters in the set of downgraded QoS parameters may be lower than the QoS parameters in the set of default QoS parameters

[0237] The set of QoS parameters may comprise at least one of: a desired bit rate; a minimum bit rate; a desired packet delay budget; a maximum packet delay budget; a desired packet error rate; a maximum packet error rate; a desired data packet set delay budget; a maximum data packet set delay budget; a desired data packet set error rate; and / or a maximum data packet set error rate.

[0238] The first radio bearer may be configured according to the set of QoS parameters. The first radio bearer may be configured according to the default set of QoS parameters. The first radio bearer may be configured according to the modified set of QoS parameters. The method may further comprise selecting the first radio bearer of the plurality of radio bearers based at least in part on the additional data.

[0239] The additional data may comprise at least one of: an identifier of at least one of: a payload format, type and representation; a traffic burst size indication; a media type and codec information; an application-layer forward error correction (FEC) configuration; an indication of modified QoS requirements; QoS requirements for one or more data packets of the application data flow; a temporary boost indication of QoS and a combination thereof.

[0240] The application-layer FEC configuration may comprise at least one of: a FEC type, a content ratio, a number of source data packets, and / or a number of redundant data packets.

[0241] The indication of modified QoS requirements may comprise a per packet indication of modified QoS requirements. The QoS requirements for one or more data packets of the application data flow may comprise a dynamic QoS requirement for one or more data packets of the application data flow.

[0242] The dynamic QoS requirements may comprise at least one of a bit rate, a data packet delay budget, and / or a data packet error rate. The dynamic QoS requirements may be for one or more data packets of the application data flow. The dynamic QoS requirements additional data signaling may utilize the set of QoS requirements configured.

[0243] The temporary boost indication may indicate a request for an elevated QoS handling comprised by the adaptive QoS flow.

[0244] There is further provided a radio access network, RAN, for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the RAN to: establish a plurality of radio bearers for a data flow, wherein a quality of service, QoS, of the data flow is adaptable; and receive, from a user equipment, UE, via a first radio bearer of the plurality of radio bearers, a data packet, the data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of the data flow for the data packet.

[0245] Such a RAN tends to reduce the delay in changing the QoS handling of the data flow for the data packet. The RAN may be configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable. A plurality of radio bearers may be established for the data flow.

[0246] There is further provided a method performed by a radio access network, RAN, the method comprising: establishing a plurality of radio bearers for a data flow, wherein a quality of service, QoS, of the data flow is adaptable; and receiving, from a user equipment, UE, via a first radio bearer of the plurality of radio bearers, a data packet, the data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of the data flow for the data packet.

[0247] Such a method tends to reduce the delay in changing the QoS handling of the data flow for the data packet.

[0248] The method may further comprise receiving configuration information for the data flow. Establishing the plurality of radio bearers for the data flow may be based on the configuration information. The method may further comprise routing the data packet to a network entity by applying the particular QoS of the data flow. The network entity may be a user plane function, UPF.

[0249] The data flow may comprise an application data flow with application data packets. The data flow may comprise an adaptive QoS requirement. The data flow may be a QoS flow. The QoS flow may be adaptable. The QoS flow may be an adaptive QoS flow. The QoS flow may be an uplink QoS flow. The QoS flow may be established between the RAN and a second network entity. The network entity may be a connectivity gateway to a data network. The connectivity gateway may be a user plane function, UPF.

[0250] The data packet may be a user plane packet. The data packet may be encapsulated within an encapsulation protocol to generate an encapsulated data packet. The encapsulated data packet may be marked with the additional data. The additional data may be marked within headers of a payload proxied in the encapsulation protocol.

[0251] The encapsulated data packet may be marked with the additional data based on at least one of: a data packet type; a data packet format and / or a data packet priority to a range of QoS requirements. The encapsulation protocol may be based on a tunneled connection to a proxying server by means of a hypertext transfer protocol, HTTP, proxy client.

[0252] The first radio bearer may be configured according to a set of QoS parameters. The set of QoS parameters may be part of the configuration information. The set of QoS parameters may comprise a set of default QoS parameters. The set of QoS parameters may further comprise a set of modified QoS parameters. The set of QoS parameters may comprise at least one of: a desired bit rate; a minimum bit rate; a desired packet delay budget; a maximum packet delay budget; a desired packet error rate; a maximum packet error rate; a desired data packet set delay budget; a maximum data packet set delay budget; a desired data packet set error rate; and / or a maximum data packet set error rate.

[0253] The first radio bearer may be configured according to the default set of QoS parameters. The first radio bearer may be configured according to the modified set of QoS parameters. The method may further comprise selecting the first radio bearer of the plurality of radio bearers based at least in part on the additional data.

[0254] The additional data may comprise at least one of an identifier of at least one of a payload format, type and representation; a traffic burst size indication; a media type and codec information; an application-layer FEC configuration; a per packet indication of modified QoS requirements; dynamic QoS requirements for one or more data packets of the application data flow; a temporary boost indication of QoS and a combination thereof.

[0255] The QoS framework in 5G is limited by the nature of enforcing GBR / delay- critical GBR QoS flows with static QoS requirements in both UL and DL. An established QoS flow with QoS requirements inflicts on the RAN node to ensure a packet delivery based on static QoS requirements of the QoS flow both in UL and DL. This is not suitable for modern apps (often multi-modal, such as XR, AR, LLM Q&A and interactions etc.) which have dynamically varying traffic characteristics. For example, video stream applications often require for low-latency and high QoE bursty traffic potentially exceeding instantaneously the bit rates allocated to GBR / delay-critical GBR QoS flows. To this end, more dynamic QoS flow handling may need to be established End-to-End (E2E). This would avoid resource overprovisioning issues at the RAN where the apps dynamic traffic characteristics are in the lower rate regimes and can be handled with far less resources than for traffic bursts / peaks. Such dynamic QoS flow handling is even more relevant in UL where the capacity is more limited relative to DL by the lower UE transmit power, yet novel dynamic applications continuously emerge (immersive and interactive AR, LLM Q&A, reels uploading, social live steaming etc.).

[0256] Examples described herein generally relate to UL dynamic QoS handling solutions for applications with dynamic QoS requirements and traffic characteristics changes. A new type of dynamic (or adaptive) QoS flow is introduced in UL wherein the QoS flow may be dynamically associated with one or more DRBs to cater for the dynamic QoS requirements of the application. The solution may comprise proxying / encapsulating application traffic between UE and network within an encapsulation protocol (e.g., basedon QUIC). The encapsulation protocol is used to add flow control metadata dynamically to the packets of the application, the metadata based on the dynamic QoS requirements and traffic characteristics of the app traffic. The metadata and encapsulation is used by SDAP or similar upper layers in L2 design to adaptively route traffic in UL to appropriate DRBs without waste of resources, based on dynamic application needs. The one or more UL DRBs may be aggregated over the CN by a single dynamic QoS capable of satisfying for an application / service a range of QoS requirements with optimized resource allocation E2E over the mobile network.

[0257] Rel-18 and Rel-19 work on XR rely still on static QoS allocations (e.g., of GBR type), where at best an application may indicate to the network either via control plane changes in the QoS requirements for a QoS flow / an alternate QoS flow or alternatively an indication within N6 metadata of dynamic traffic characteristics that may require increased QoS flow handling. These solutions currently require CN establish two QoS flows and switch the traffic correspondingly to a QoS flow, e.g., based on whether the N6 indication is provided by the AS. Such solution is not resource efficient as the RAN may need to have resources reserved for QoS flows. Furthermore, the current solutions focus exclusively on DL QoS flow handling, whilst UL behaviour is currently not enhanced by similar dynamic QoS flow handling mechanisms.

[0258] Some examples described herein may relate to a Dynamic UL QoS flow configured to support a set of QoS requirements, e.g., a default QoS and an elevated QoS, for an application data flow. This tends to translate into a number of network actors playing some additional roles than currently available in 5GS.

[0259] Some examples described herein may relate to a UE that implements an HTTP / 3 client to establish an IP encapsulation tunnel with the UPF for the application flow. A UE modem SDAP entity applies new packet filtering (taking into account potential application marking of traffic at IP encapsulation level) new dynamic QoS rules (e.g., comprising at least default QoS and elevated QoS ranges) and maps the UL traffic accordingly to one or more DRBs. The DRBs are associated with the UL dynamic QoS flow. This enables intraapplication flow packets / bursts prioritization in UL as per application needs / marking.

[0260] Some examples described herein may relate to a RAN SDAP entity that establishes and associates the one or more DRBs with the dynamic QoS flow. The RAN groups and routes the L2 egress traffic from the one or more DRBs to the dynamic QoS flow QFI to the UPF within GTP-U. The application traffic is still encapsulated within the IP tunnel encapsulation protocol established between UE and UPF.

[0261] Some examples described herein may relate to an AF that includes requirements for establishing an UL QoS flow whose QoS requirements change dynamically. Some examples described herein may relate to a PCF that determines a PCC rule that establishes an UL QoS flow with dynamic QoS requirements. Some examples described herein may relate to an SMF that configures a UE with an encapsulation tunnel configuration for the dynamic UL QoS flow handling, QoS rules and / or packet detection rules.

[0262] Some examples described herein may relate to a UE that implements a novel HTTP / 3 client, filter UL application data flow and encapsulates UL packets into encapsulation protocol (including metadata for flow control). Some examples described herein may relate to a UE that enhances SDAP functionality enabling routing of a flow to one or more DRBs in UL, the one or more DRBs associated with a dynamic QoS flow. Some examples described herein may relate to a UE that enhances SDAP functionality to parse 3 GPP-specific control metadata for dynamic QoS control and dynamic traffic characteristics for routing of UL packets to appropriate DRBs for the dynamic QoS flow handling in UL.

[0263] Some examples described herein may relate to a UPF that receives at N6 an application data flow with metadata over the dynamic QoS control. Some examples described herein may relate to a RAN node. An SDAP entity on the RAN node may implement some additional features to facilitate UL mapping of two DRBs to a single QoS flow.

[0264] There is further provided a user equipment (UE) apparatus configured to receive configuration information for establishing a QoS session with adaptive QoS requirements; receive a packet from an application data flow; encapsulate the packet according to the configuration within an encapsulation protocol associated with an adaptive QoS flow; determine QoS requirements for the packet based on the configuration information andcontrol metadata; and route the packet to a data radio bearer out of a set of data radio bearers, the data radio bearers associated with the adaptive QoS flow.

[0265] The UE apparatus may be further configured to mark the encapsulated packet with the control metadata based on the configuration information and dynamic traffic characteristics of the application data flow.

[0266] The configuration information may comprise a range of QoS requirements, the range of QoS requirements including at least a first set of QoS parameters as default QoS parameters.

[0267] The range of QoS requirements may further include at least a second set of QoS parameters, the second set of QoS parameters as one of elevated QoS parameters or downgraded QoS parameters, relative to the default QoS parameters.

[0268] A set of QoS parameters may comprise of at least one of: a desired bit rate, a minimum bit rate, a desired packet delay budget, a maximum packet delay budget, a desired packet error rate, a maximum packet error rate, a desired PDU Set delay budget, a maximum PDU Set delay budget, a desired PDU Set error rate, and / or a maximum PDU Set error rate.

[0269] The configuration information may comprise at least one of: an access information tuple corresponding to the encapsulation protocol, e.g., a 5-tuple associated with the proxy connection of the application data flow (e.g., src IP, dst IP, src port, dst port, proto); a packet transform configuration applicable to the packets encapsulated according to the encapsulation protocol; a protocol description corresponding to packets of the application data flow; a control metadata and packet detection rule configuration for the encapsulation protocol and a combination thereof.

[0270] The control metadata information may be marked within the headers of the payload proxied in the encapsulation protocol. The control metadata information may comprise at least one of: an identifier of one of payload format, a type and representation; traffic burst size indication; media type and codec information; application-layer FEC configuration (e.g., FEC type, content ratio, number of source packet, number of redundant packets etc.); per packet indication of elevation or downgrade of QoS requirements;dynamic QoS requirements (e.g., bit rate, packet delay budget, packet error rate) for one or more packets of the application data flow; and / or temporary boost indication of QoS; the boost indication requesting elevated QoS handling comprised by the adaptive QoS flow.

[0271] Marking of the packet with control metadata may be further based upon an intermediate mapping of a media type, format or priority to an identifier, the identifier further determined based on the QoS requirements associated with the media type, format or priority.

[0272] The encapsulation protocol may be based upon requesting at least one of: a QUIC-aware proxying connection over HTTP / 3; Connect-UDP connection over HTTP / 3; Connect-IP connection over HTTP / 3; to a proxying server by means of an HTTP / 3 proxy client.

[0273] Routing of the packet for the adaptive QoS flow may comprise selecting a data radio bearer at least matching the QoS requirements of at least one of the set of QoS parameters, the selection determined in part based on the metadata control information associated with the packet.

[0274] There is further provided a network entity configured to: receive configuration information related to session establishment with adaptive QoS requirements; establish a set of one or more data radio bearers supporting the adaptive QoS requirements, the one or more data radio bearers associated with a dynamic QoS flow as per the configuration information; receive a user plane packet from a user equipment on one of the data radio bearer, the user plane packet encapsulated within an IP encapsulation protocol mapped to the dynamic QoS flow; route the user plane packet to another network entity (e.g., UPF) by applying the dynamic QoS flow. The network entity may be a RAN.

[0275] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0276] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may beapplied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

[0277] The following abbreviations are relevant in the field addressed by this document: 3GPP - 3rd generation partnership project; 5G - fifth generation; 5GS - 5G System; 5QI - 5G QoS Identifier; 6G - sixth generation; AF - application function; AMF - access and mobility function; AR - augmented reality; AS - application server; DL - downlink; NAL - network abstraction layer; PCF - policy control function; PDU - packet data unit; PPS - picture parameter set; QoE - quality of experience; QoS - quality of service; RAN - radio access network; RTCP - real-time control protocol; RTP - real-time protocol; SDAP - service data adaptation protocol; SMF - session management function; SRTCP - secure real-time control protocol; SRTP - secure real-time protocol; UE - user equipment; UL - uplink; UPF - user plane function; VCL - video coding layer; VMAF - video multi-method assessment function; VPS - video parameter set; VR - virtual reality; XR extended reality; XR AS - XR application server; XRM - XR media.

Claims

CLAIMSWhat is claimed is:

1. A user equipment, UE, for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: receive, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS requirement of a data flow for the data packet; determine the particular QoS requirement for the data packet based at least in part on the additional data; and route the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

2. The UE of claim 1, wherein the at least one processor coupled with the at least one memory is further configured to cause the UE to: receive configuration information for the data flow, wherein the configuration information comprises at least one of: a range of QoS requirements for the QoS of the data flow comprising a set of QoS parameters as QoS rules; an access information tuple corresponding to an encapsulation protocol of the data flow; a packet transform configuration applicable to one or more data packets encapsulated according to the encapsulation protocol; a protocol description comprising a packet filter applicable to the data packet of the application data flow; an additional data configuration and a packet filter configuration for the encapsulation protocol; and a combination thereof.

3. The UE of claim 2, wherein the at least one processor coupled with the at least one memory is further configured to cause the UE to: encapsulate the data packet according to the encapsulation protocol to generate an encapsulated data packet.

4. The UE of claim 3, wherein the at least one processor coupled with the at least one memory is further configured to cause the UE to: mark the encapsulated data packet with the additional data.

5. The UE of claim 4, wherein the at least one processor coupled with the at least one memory being configured to cause the UE to mark the encapsulated data packet with the additional data comprises the at least one processor coupled with the at least one memory being further configured to cause the UE to: mark the additional data within headers of a payload proxied in the encapsulation protocol.

6. The UE of any one of claims 4 to 5, wherein the at least one processor coupled with the at least one memory being configured to cause the UE to mark the encapsulated data packet with the additional data comprises the at least one processor coupled with the at least one memory being further configured to cause the UE to: mark the encapsulated data packet with the additional data based at least in part on a mapping of at least one of: a data packet type, a data packet format, and a data packet priority to the range of QoS requirements.

7. The UE of any one of claims 2 to 6, wherein the encapsulation protocol is based on a tunneled connection to a proxying server by means of a Hypertext Transfer Protocol, HTTP, proxy client.

8. The UE of any one of claims 2 to 7, wherein the set of QoS parameters comprises a set of default QoS parameters.

9. The UE of claim 8, wherein the set of QoS parameters further comprises a set of modified QoS parameters.

10. The UE of any one of claims 2 to 9, wherein the set of QoS parameters comprises at least one of: a desired bit rate; a minimum bit rate; a desired packet delay budget; a maximum packet delay budget; a desired packet error rate; a maximum packet error rate;; a desired data packet set delay budget; a maximum data packet set delay budget; a desired data packet set error rate; and a maximum data packet set error rate.

11. The UE of any one of claims 2 to 10, wherein the first radio bearer is configured according to the set of QoS parameters.

12. The UE of any one of claims 1 to 11, wherein the additional data comprises at least one of: an identifier of at least one of: a payload format, type and representation; a traffic burst size indication; a media type and codec information; an application-layer Forward Error Correction, FEC, configuration; an indication of modified QoS requirements;QoS requirements for one or more data packets of the application data flow; a temporary boost indication of QoS; and a combination thereof.

13. A processor for wireless communication, comprising:at least one controller coupled with at least one memory and configured to cause the processor to: receive, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS requirement of a data flow for the data packet; determine the particular QoS requirement for the data packet based at least in part on the additional data; and route the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

14. A method performed by a user equipment, UE, wherein the UE is configured with a data flow, wherein a quality of service, QoS, of the data flow is adaptable, the method comprising: receiving, from an application data flow, a data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS requirement of the data flow for the data packet; determining the particular QoS requirement for the data packet based at least in part on the additional data; and routing the data packet to a first radio bearer of a plurality of radio bearers, wherein the plurality of radio bearers is established for the data flow.

15. A radio access network, RAN, for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the RAN to: establish a plurality of radio bearers for a data flow, wherein a quality of service, QoS, of the data flow is adaptable; and receive, from a user equipment, UE, via a first radio bearer of the plurality of radio bearers, a data packet, the data packet comprising additional data, wherein the additional data comprises information for determining a particular QoS of the data flow for the data packet.

Images