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 first network entity 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 first network entity to: receive, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of a QoS flow for the data packet; determining the particular QoS requirement of the QoS flow for the data packet based at least in part on the additional data; and transmitting, to a user equipment, UE, the data packet over the QoS flow according to the particular QoS requirement. Such a first network entity tends to reduce the delay in changing the QoS requirement of the QoS flow for the data packet.

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 determining a quality of service (QoS) requirement of a QoS flow in a wireless communication network. In particular, this document defines a first network entity and method 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 first network entity 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 first network entity to: receive, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular Quality of Service (QoS) requirement of a QoS flow for the data packet; determining the particular QoS requirement of the QoS flow for the data packet based at least in part on the additional data; and transmitting, to a user equipment (UE) the data packet over the QoS flow according to the particular QoS requirement.

[0005] There is further provided a method performed by a first network entity, wherein the first network entity is configured with a QoS flow, wherein a QoS requirement of the QoS flow is adaptable, the method comprising: receiving, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of the QoS flow for the data packet; determining the particular QoS requirement of the QoS flow for the data packet based at least in part on the additional data; and transmitting, to a UE, the data packet over the QoS flow according to the particular QoS requirement.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0007] 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.

[0008] 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.

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

[0010] 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.

[0011] 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.

[0012] 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.

[0013] Figure 8 illustrates an architecture for Support of dynamic QoS for application with dynamic traffic characteristics in accordance with aspects of the present disclosure.

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

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

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

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

[0018] Figure 13 illustrates a flowchart of a method 1300 performed by a NE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0019] Some wireless communication networks, such as 5G networks support a Quality of Service (QoS) framework where a QoS has static QoS requirements. Once a QoS flow is established to support the QoS, these networks ensure that a packet is handled according to the static QoS requirements. However, these QoS flows are not suitable for applications with traffic characteristics that change dynamically. By way of example, a video stream application may, in some cases, require more bandwidth to provide (e.g., transmit, receive) a burst of traffic, such as video frames (e.g., P-frames) that are large in size and may need to be delivered within a certain period of time. In some other cases, additional bandwidth might not be required, such as for video frames (e.g., I-frames) that are smaller in size compared to P-frames. In these cases, bursty traffic may be inconsistent and cannot be predicted.

[0020] Examples described herein may accommodate such type of bursty traffic. In examples described herein, a wireless communication network (e.g., a 3GPP network), including one or more UEs and / or NEs may establish a Guaranteed Bit Rate (GBR) QoS flow with QoS requirements to satisfy high bandwidth requirements of applications.

[0021] In examples described herein, a network entity (e.g., a RAN node) may reserve resources to accommodate high bandwidth requirements and avoid wasting resources for applications that do not need to transmit bursty traffic.

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

[0023] 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 (LIE- 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 combination of 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.

[0024] 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.

[0025] 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.

[0026] 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 an Internet-of-Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0027] 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.

[0028] 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).

[0029] 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 orinterconnects 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.

[0030] 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).

[0031] 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 5 G 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.

[0032] 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., / r=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., / r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe.A second numerology (e.g., / r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., / r=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., / r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., / r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0033] 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.

[0034] 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., / r=0, jU=l , / r=2, jU=3, / r=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., / r=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0035] 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 designations FR1 (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.

[0036] 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., / r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., / r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / r=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., / r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / r=3), which includes 120 kHz subcarrier spacing.

[0037] 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.

[0038] 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 generallyapplicable and may be embodied by different types of transport and network protocols stacks (e.g., QUIC, WebRTC, WebTransport or alike).

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

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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 isthe extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of cognition (represented by AR).

[0044] 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 5GRel-17 QoS flow possibilities. As such, a PDU set is composed of one or more PDUs carrying the payload of one unit of information 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.

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

[0046] 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 UE PDU-Set sent by the UE, and respectively,

[0047] 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 3 GPP 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 3 GPP access), whereas the PSER is used to determine an upper bound for a rate of non-congestion-related packet losses.

[0048] 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 RadioAccess 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.

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

[0050] 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 510 may also include an importance parameter for a PDU set and information for the core network to identify packets belonging to a PDU set.

[0051] 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.

[0052] 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 PDSB 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.

[0053] 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 Specification23.501 vl 8.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 vO.1.1 (Sep 2023) 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. The packet 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.

[0054] 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.

[0055] 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 an 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.

[0056] However, in XRM Release 18, i.e. 3GPP Technical Specification TS 23.501 vl 8.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.

[0057] 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.

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

[0059] 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.

[0060] It is also specified in 3GPP TS 23.501 vl 8.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.

[0061] 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 3GPP Technical Specification TS 26.522 vO.1.1 (Sep 2023), titled “5G Real-time Media Transport Protocol Configurations”.

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

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

[0064] 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.

[0065] 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.

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

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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 not present. 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.

[0072] 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.

[0073] 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.

[0074] 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 mappingsare 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.

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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 645 receives 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.

[0081] 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.

[0082] 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.

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

[0084] 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 QoScharacteristics 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 5 QI then the RAN may handle the packet according to the traffic characteristics of the 5QI.

[0085] 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 due to 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.

[0086] 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.

[0087] 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 3 GPP 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.

[0088] 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 andthe 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.

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

[0090] 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.

[0091] 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

[0092] 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.

[0093] 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).

[0094] 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.

[0095] 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 end-point 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). Assuch, 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.

[0096] 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 3 GPP, 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.

[0097] 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.

[0098] 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.

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

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

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

[0102] 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.

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

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

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

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

[0107] In step 785, the RTC Media Session Handler 750e adjusts a bit rate of the session.

[0108] There are shortcomings of the existing QoS framework; in particular, for adaptive application data flows.

[0109] 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.

[0110] 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 dynamic network 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.

[0111] 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).

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

[0113] 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 more dynamic (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.

[0114] Figure 8 illustrates a flow diagram 800 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 800 illustrates a high level solution for QoS enhancements as described herein.

[0115] The flow diagram 800 illustrates the signals sent between an AF / NEF 810, a PCF 815, SMF 820, AMF 825, UPF 840, Application Server 845, RAN 830 and a UE 835.

[0116] The flow diagram 800 illustrates a new type of guaranteed QoS flow to be defined where the QoS requirement of the flow may be adapted according to the traffic characteristics of the application. This may be referred to as an adaptive QoS flow or a dynamic QoS flow. Such an adaptive QoS flow may be defined to have a range of QoS requirements. For example, the range of QoS requirements may include a range of Guaranteed Flow Bit Rate (GFBR) and / or a range of Maximum Data Burst Volume (MDBV) values.

[0117] The RAN 830 may decide on the QoS to apply based on the traffic characteristics of the packet (received in the downlink) based on in-band information that may be included in the header of the downlink packet. The in-band information may contain information of the traffic characteristic or the QoS requirements (e.g. packet error rate) of the packet.

[0118] The AF / NEF 810 sends a request to the PCF 815. The request requesting establishment of a session with QoS requirements to the 3GPP network. The AF includes in the request one or more of the following:• An indication that the application's traffic characteristics change dynamically and / or an indication to establish a session with adaptive / dynamic QoS requirements.• An indication that traffic character istics / dynamic QoS requirements of the application packet are provided in-band to the user plane packet. This may include an indication that at least one of the following parameters are provided. The parameters may relate to a single packet or a PDU set: o Burst size; o Data rate requirement; o Boost indication indicating which QoS requirement in the list of QoS requirements provided is the preferred QoS. The boost indication may be included within metadata information over user plane. The boost indication may be used to indicate the preferred QoS when congestion occurs. The boost indication may indicate that the QoS is applicable within a certain time period. o Codec information; o Explicit packet delay requirement; o A preferred QoS at certain period of time; o Explicit packet error rate;o QoS requirements. Each QoS requirement may include a 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. The QoS reference may be preagreed.• An indication of the range of QoS to support the application traffic.• A minimum and maximum QoS requirement; for example, a minimum and maximum of at least one of: a packet delay, a data burst volume, and / or a packet error rate.• A default QoS requirement and an elevated QoS requirement. The elevated QoS requirement may be for when traffic characteristics change.• The transport format on providing traffic characteristics in-band to the user plane packet. This may be based on an encapsulation protocol where metadata are added within headers of the protocol. The tunnel may be based on QUIC-Aware Proxy or Connect-UPD (RFC 9298) or UDP Options or any other protocol that supports encapsulation of user plane packet and establishing a tunnel between the AS and the UPF. The transport format may also be defined within RTP extension headers of the UDP payload.

[0119] The request from the AF / NEF 810 to the PCF 815 may be anNnef AFSessionwithQoS request. The request may comprise at least one of the following information:• Flow Description (5-tuple or application ID of the packet);• 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; The protocol description may include an indication that metadata is included within an encapsulation protocol or within RTP extension headers.• Encapsulation protocol used (e.g. Connect-UDP, QUIC- Aware Proxy) (may be included within the protocol description field);• Address of the Application Server to establish a tunnelled session using the provided encapsulation protocol (may be included within the protocol description field);• An indication to adapt QoS based on traffic characteristics;• QoS requirements in priority order or default QoS requirements and elevated QoS requirements. Each QoS requirement including a QoS reference (agreed based on SLA agreements) or one or more of the following: Requested Priority, Maximum Burst Size, Requested 5GS Delay, Requested Maximum Bitrate, Requested Guaranteed Bitrate and Requested Packet Error Rate.

[0120] The PCF 815 creates a Policy and Charging Control (PCC) rule that comprises requirements to establish an adaptive QoS flow. The adaptive QoS flow may be a dynamic QoS flow. The adaptive QoS flow may be adaptive to traffic characteristics. The adaptive QoS flow may be adaptive to traffic congestion.

[0121] The PCC rule may comprise a new list of one or more 5QIs. Each of the one or more 5QIs may comprise a range of traffic characteristics. Each of the one or more 5QIs may comprise a range of QoS requirements.

[0122] The PCF 815 may indicate in the PCC rule the range of traffic characteristics. The PCF 815 may ensure that the PCC rule is applicable only for applications that require dynamic QoS; for example, based on an application ID or an IP 5-tuple of the flow.

[0123] The PCC rule is sent to an SMF 820. The PCF 815 may indicate establishing a QoS flow supporting multiple legacy 5QIs. The legacy 5QIs may correspond to sub-QoS flows. Examples of a PCC rules are:• Indicate a 5QI for dynamic QoS. The new 5QI identifier supporting a range of QoS requirements;• Mapping of traffic characteristics to specific QoS requirements within the range of QoS requirements supported by the new 5QI;• Indication to establish sub-QoS flows each sub-QoS flow supporting a legacy 5QI;• Mapping of traffic characteristics to a legacy 5QI (e.g. a mapping of burst size to a 5QI).

[0124] The SMF 820 may be a 6G SMF. The SMF 820 sends configuration rules to the UPF 840. The configuration rules configure the UPF 840 to inspect metadata received on a downlink according to an encapsulation protocol or RTP extension header of a UDP payload and report the contents of the metadata over N3 (or 6G N3) to the RAN 830 over a user plane (e.g. within GTP-U headers).

[0125] The configuration rules to the UPF 840 may include one or more of the following:• An indication to establish an IP tunnel to the Application Server using an encapsulation protocol (e.g. Connect-UDP, QUIC Aware proxy, and / or UDP- Options);• An indication to inspect traffic received over N6 for application metadata (metadata may be sent over the encapsulation protocol);• Routing rules to route the extracted application (UDP packet) towards a QoS flow towards the RAN over N3.

[0126] The configuration rules may comprise an indication to add app traffic characteristics include an app ID or packet filter type traffic characteristics.

[0127] The SMF 820 also configures the RAN 830 with a QoS rule indicating that metadata is to be included in-band over N. The QoS rule may also provide an enhanced 5QI or a range of traffic characteristics. A QoS rule 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.

[0128] The RAN 830 establishes corresponding radio bearers (one or multiple) with the UE 835 according to the range of QoS requirements.

[0129] The AS 845 sends a user plane PDU to the UPF 840 and includes, within metadata of the user plane PDU, information to assist the RAN 830 when scheduling resources.

[0130] The AS 845 may add in the metadata the traffic characteristics of the PDU or a series of PDUs (e.g. PDU set). For example, the traffic characteristics of the PDU or PDU set may comprise a burst indication and / or data rate requirement.

[0131] The AS 845 may add within the metadata the QoS requirements of the PDU or a series of PDUs. For example, the QoS requirements of the PDU or series of PDUs may comprise a QFI and / or a packet error rate.

[0132] The metadata is provided via the encapsulation protocol (e.g. UDP-Options, Connect-UDP, QUIC-Aware Proxy) or via RTP extension headers.

[0133] The UPF 840 inspects the metadata of the received PDU based on the configuration rules from the SMF 820 and forwards the metadata to the RAN 830 via user plane signalling (e.g. GTP-U).

[0134] The SMF 820 and / or UPF 840 may decide on a QoS requirement to apply based on one or more of the traffic characteristics of the PDU (provided within metadata), network conditions and configuration information received from the SMF 820. The UPF 840 may forward the metadata received to the SMF 820 for a QoS requirement decision.

[0135] The UPF 840 may send the QoS requirement to the RAN 830 via in-band signalling (e.g. GTP-U). The UPF 840 may include the metadata when the UPF 840 determines the QoS requirement has changed. The UPF 840 may not add the metadata inevery data packet but may only include the metadata when a change of QoS requirement is determined. The QoS requirement may correspond to a QoS.

[0136] The UPF 840 may send the QoS requirement to the RAN 830 via Control plane signalling (e.g., via the SMF 820 and / or AMF 825. The UPF 840 may notify the SMF 820 of a change of traffic characteristics. The UPF 840 may notify the SMF 820 of a change of metadata. The SMF 820 may determine new QoS rules based on metadata sent to the RAN 830 via the AMF 825.

[0137] The UPF 840 may forward the traffic characteristics (contained in metadata) of a received PDU over in-band signalling (e.g. GTP-U) to the RAN 830.

[0138] The UPF 840 may forward the QoS requirements (contained in metadata) of the a received PDU over in-band signalling (e.g. GTP-U) to the RAN 830 or over control plane signalling. In the former case, the UPF 840 may include metadata when the UPF 840 determines the QoS requirement has changed. In the latter case the UPF 840 may notify a change of QoS requirements to the SMF 820. The SMF 820 may determine new QoS rules based on metadata sent to the RAN 830 via the AMF 825.

[0139] The RAN 830, on reception of the PDU packet, is aware of the requirement for delivery (either aware of the traffic characteristics or the QoS requirements to apply) which is included within in-band signalling (e.g. GTP-U) and takes measures to ensure delivery of the packet to the UE 835 considering the metadata information.

[0140] The RAN 830 may create separate radio bearers. A first RB may be based on a default QoS requirement. A second RB may be based on an elevated QoS requirement. The RAN 830 may decide to route the PDU packet over the first RB or the second RB based on the metadata information.

[0141] Figure 9 illustrates a signalling diagram 900 for a procedure for enabling support of dynamic QoS for applications with dynamic traffic characteristics in accordance with aspects of the present disclosure. The signalling diagram 900 may represent a high level procedure.

[0142] The signalling diagram 900 illustrates the messages sent / received between a UE 935, a RAN 930, an AMF 925, a UPF (QUIC client) 940, an SMF 920, a PCF 915, an AF 910 and an AS (QUIC proxy) 945. The AMF 925, UPF (QUIC client) 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.

[0143] In step 971, the AF 910 sends an AF session request to the PCF 915 via a Network Exposure Function (NEF). The AF session request comprises a protocol description: a 5 tuple of the packet, an address of the UE 935, an address of the content server, and an indication of a requirement for dynamic traffic characteristics. The AF session request indicates a request for a QoS for an application session. The AF session request may indicate QoS requirements in an Application Programming Interface (API) request. The API request may comprise at least one of: an application descriptor (e.g. 5 tuple of the packet), the address of the content server, an indication that the application traffic characteristics are dynamic and / or an indication to enable adaptive QoS and QoS requirements. The QoS requirements may include a range of QoS requirements or alternative QoS requirements.

[0144] In step 972, the PCF 915 receives the request (via the NEF and / or Unified Data Management (UDM) / User Data Repository (UDR)) and determines PCC rules that are sent to the SMF 920. Each of the PCC rules may include an indication to establish a QoS flow with dynamic QoS.

[0145] In step 973, The SMF 920 determines configuration rules for the UPF 940, RAN 930 and UE 935 based on the PCC rules. The configuration rules may comprise UPF configuration rules, RAN configuration rules and UE configuration rules. The configuration rules may comprise N4 rules. The N4 rules may be for the UPF 940 to add app metadata information. The UPF configuration rules sent to the UPF 940 may comprise one or more of the following:• An indication to establish an IP tunnel to the AS 945 using an encapsulation protocol (e.g. Connect-UDP, QUIC Aware proxy).• An indication to inspect traffic received over N6 for metadata. The metadata may be application metadata. The metadata may be sent over the encapsulation protocol.• Routing rules to route the extracted application (UDP packet) towards a QoS flow towards the RAN 930 over N3.

[0146] The RAN configuration rules sent to the RAN 930 may comprise one or more of the following:• An indication to establish a dynamic QoS flow and the range of QoS requirements.• An indication to inspect application metadata from traffic received over N3 by the UPF 940.

[0147] In step 974, the UPF configuration rules are sent to the UPF 940 via an N4 reference point. The UPF configuration rules may comprise a protocol description and / or a server address.

[0148] In steps 975 to 976, the RAN configuration rules are sent to the RAN 930. The RAN configuration rules may be sent to the RAN 930 via the AMF 925. The RAN 930 establishes one or more radio bearers based on the range of QoS requirements.

[0149] In step 977, the UPF 940 establishes a tunnel with the AS 945 according to the configuration rules. The tunnel may be based on a QUIC-Aware Proxy (draft-ietf-masque- quic-proxy) or Connect-UPD (RFC 9298) or UDP Options (draft-touch-tsvwg-udp-options) or any other protocol that supports encapsulation of a user plane packet and supports establishing the tunnel between the AS 945 and the UPF 940.

[0150] In step 978, the AS 945 sends an encapsulated first packet comprising a data packet and metadata to the UPF 940. The metadata may be included in a header of the encapsulation protocol of the first packet. The metadata may be app metadata. The first packet may be a UDP packet. The header may be a UDP header.

[0151] In step 979, the UPF 940 extracts the data packet and app metadata from the encapsulated first packet. The encapsulated first packet is a tunnelled packet received over N6. The UPF 940 adds the data packet to a second packet over N3 (e.g. GTP packet) andincludes the metadata within the headers of the second packet. The second packet may be a GTP packet. The headers of the second packet may be GTP-U headers of the GTP packet.

[0152] In step 980, the second packet is sent to the RAN 930.

[0153] In step 981, the RAN 930 determines an adapted QoS requirement based on the metadata. For example, if the metadata includes an indication of bandwidth required, the RAN 930 may adapt the scheduling resources for a QoS flow to send the data packet.

[0154] The RAN 930 may allocate multiple radio bearers to the same QoS flow. The multiple radio bearers may comprise different QoS characteristics to one another. The RAN 930 may route data packets with different QoS requirements (based on the metadata received) to the corresponding radio bearer.

[0155] In step 982a first radio bearer for the QoS flow (QoS flow 1) is established with the UE 935.

[0156] In step 982b second radio bearer for the QoS flow (QoS flow 1) is established with the UE 935.

[0157] In step 983, the RAN 930 notifies the QoS enforced to the PCF 915.

[0158] Some examples described herein define a new 5QI with dynamic QoS characteristics in which the AS includes traffic characteristics as metadata.

[0159] The AF provides an indication to establish a dynamic QoS flow including within an Nnef AFSessionwithQoS request the following information:• Flow Description (5-tuple or application ID of the packet).• Protocol Description indicating the traffic characteristics (e.g. burst size) that will be included as metadata within the user plane packet provided by the Application Server to the UPF.• Encapsulation protocol used (e.g. Connect-UDP, QUIC-Aware Proxy).• Address of the Application Server to establish a tunnelled session using the provided encapsulation protocol.• An indication to adapt QoS based on traffic characteristics.• QoS requirements in priority order or default QoS requirements and elevated QoS requirements. Each QoS requirement may include 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.

[0160] The PCF determines a PCC rule to establish a dynamic QoS flow. The PCC rule may comprise at least one of:• A 5QI for dynamic QoS. The 5QI may support a range of QoS requirements; and / or• A mapping of traffic characteristics to specific QoS requirements within the range of QoS requirements supported by the 5QI.

[0161] The SMF determines configuration rules for the UPF and QoS rules for the RAN. The configuration rules may comprise UPF configuration rules. The UPF configuration rules may be N4 rules. The UPF configuration rules may comprise at least one of:• An indication to establish an IP tunnel to the Application Server using an encapsulation protocol (e.g. Connect-UDP, QUIC Aware proxy);• An indication to inspect traffic received over N6 for application metadata (metadata may be sent over the encapsulation protocol); and / or• Routing rules to route the extracted application (UDP packet) towards a QoS flow towards the RAN over N3.

[0162] The configuration rules may comprise RAN configuration rules. The RAN configuration rules may be QoS rules to the RAN. The QoS rules to the RAN may comprise at least one of:• A range of QoS requirements supported for a 5QI; and / or• Mapping of traffic characteristics to specific QoS requirements within the range of QoS requirements supported by the 5QI (e.g. mapping of burst size to specific QoS requirement).

[0163] The AS encapsulates the application packet (UDP Packet) with the encapsulation protocol (e.g. connect-UDP) and adds traffic characteristics (e.g. burst size) as metadata.

[0164] The UPF extracts the UDP packet and metadata from the received encapsulated packet. The UPF inserts the UDP packet to a packet over N3 to a QoS flow based on configuration rules (e.g. GTP) and adds the metadata (e.g. burst size) in the header of the N3 packet (e.g. GTP-U).

[0165] The RAN establishes one or more radio bearers with a UE based on the range of QoS in QoS rules provided by the SMF / AMF. The RAN determines a QoS to apply based on the dynamic 5QI parameters, metadata and the QoS rules. The RAN takes into account the metadata information (e.g. burst size) to determine the QoS requirement based on QoS rules.

[0166] Examples described herein define a new 5QI with dynamic QoS characteristics in which the AS includes traffic characteristics as metadata and the UPF determines QoS requirements.

[0167] The AF provides an indication to establish a dynamic QoS flow including within an Nnef AFSessionwithQoS request. The request may comprise at least one of:• Flow Description (5-tuple or application ID of the packet);• Protocol Description indicating the traffic characteristics (e.g. burst size) that will be included as metadata within the user plane packet provided by the Application Server to the UPF;• Encapsulation protocol used (e.g. Connect-UDP, QUIC-Aware Proxy);• Address of the Application Server to establish a tunnelled session using the provided encapsulation protocol;• An indication to adapt QoS based on traffic characteristics; and / or• QoS requirements in priority order or default QoS requirements and elevated QoS requirements. Each QoS 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.

[0168] The PCF determines a PCC rule to establish a dynamic QoS flow. The PCC rule may comprise at least one of:• A 5QI for dynamic QoS. The 5QI may support a range of QoS requirements; and / or• A mapping of traffic characteristics to specific QoS requirements within the range of QoS requirements supported by the 5QI.

[0169] The SMF determines configuration rules for the UPF and QoS rules for the RAN.

[0170] The configuration rules for the UPF may comprise N4 rules. The configuration rules for the UPF may comprise at least one of:• An indication to establish an IP tunnel to the Application Server using an encapsulation protocol (e.g. Connect-UDP, QUIC Aware proxy);• An indication to inspect traffic received over N6 for application metadata (metadata may be sent over the encapsulation protocol);• Routing rules to route the extracted application (UDP packet) towards a QoS flow towards the RAN over N3; and / or• Routing rule includes a mapping of traffic characteristics to QoS requirements.

[0171] The QoS rules to the RAN may comprise at a range of QoS requirements supported for a 5 QI.

[0172] The AS encapsulates the application packet (UDP Packet) with the encapsulation protocol (e.g. connect-UDP) and adds traffic characteristics (e.g. burst size) as metadata.

[0173] The UPF extracts the UDP packet and metadata from the received encapsulated packet. The UPF inserts the UDP packet to a packet over N3 to a QoS flow based on configuration rules (e.g. GTP). The UPF determines the QoS requirements (e.g. by providing to the SMF the metadata and SMF providing QoS requirements) from the metadata (e.g. mapping of Burst size to QoS requirement) and adds the metadata (e.g., derived QoS requirement) in the header of the N3 packet (e.g. GTP-U). The UPF adds QoS requirements in the first PDU when it detects change of QoS. Alternatively, the UPF notifies the SMF of the metadata and the SMF determines QoS rules that are sent to the RAN via the AMF.

[0174] The RAN establishes one or more radio bearers with a UE based on the range of QoS in QoS rules provided by SMF / AMF. The RAN determines the QoS to apply based on the dynamic 5QI parameters, metadata (QoS requirement) and the QoS rules.

[0175] Some examples described herein define a new 5QI with dynamic QoS characteristics in which the AS includes QoS requirements as metadata.

[0176] The AF provides an indication to establish a dynamic QoS flow including within an Nnef AFSessionwithQoS request at least one of:• Flow Description (5-tuple or application ID of the packet);• Protocol Description indicating the QoS requirements (e.g. maximum burst size) that will be included as metadata within the user plane packet provided by the Application Server to the UPF;• Encapsulation protocol used (e.g. Connect-UDP, QUIC-Aware Proxy);• Address of the Application Server to establish a tunnelled session using the provided encapsulation protocol;• An indication to adapt QoS based on traffic characteristics; and / or• QoS requirements in priority order or default QoS requirements and elevated QoS requirements. Each QoS 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.

[0177] The PCF determines a PCC rule to establish a dynamic QoS flow. The PCC rule may comprise at least one of:• A 5QI for dynamic QoS. The 5QI may support a range of QoS requirements; and / or• An indication of metadata including QoS requirements (e.g. maximum burst size).

[0178] The SMF determines configuration rules for the UPF and QoS rules for the RAN.

[0179] The configuration rules for the UPF may be N4 rules. The configuration rules for the UPF may comprise at least one of:• An indication to establish an IP tunnel to the Application Server using an encapsulation protocol (e.g. Connect-UDP, QUIC Aware proxy);• An indication to inspect traffic received over N6 for application metadata (metadata may be sent over the encapsulation protocol); and / or• Routing rules to route the extracted application (UDP packet) towards a QoS flow towards the RAN over N3.

[0180] The QoS rules to the RAN may comprise a range of QoS requirements supported for a 5 QI.

[0181] The AS encapsulates the application packet (UDP Packet) with the encapsulation protocol (e.g. connect-UDP) and adds QoS requirement (e.g. maximum burst size) as metadata.

[0182] The UPF extracts the UDP packet and metadata from the received encapsulated packet. The UPF inserts the UDP packet to a packet over N3 to a QoS flow based on configuration rules (e.g. GTP). The UPF adds the metadata (e.g., derived QoS requirement)in the header of the N3 packet (e.g. GTP-U). The UPF adds QoS requirements in the first PDU when it detects change of QoS. Alternatively, the UPF notifies the SMF of the metadata and the SMF determines QoS rules that are sent to the RAN via the AMF.

[0183] The RAN establishes one or more radio bearers with a UE based on the range of QoS in QoS rules provided by SMF / AMF. The RAN determines the QoS to apply based on the dynamic 5QI parameters, metadata (QoS requirement) and the QoS rules.

[0184] Some examples described herein define sub-QoS flows within a QoS flow. Each Sub-QoS flow may support a different 5QI.

[0185] The AF provides an indication to establish a dynamic QoS flow including within an Nnef AFSessionwithQoS request the following information:• Flow Description (5-tuple or application ID of the packet);• Protocol Description indicating the traffic characteristics (e.g. burst size) that will be included as metadata within the user plane packet provided by the Application Server to the UPF;• Encapsulation protocol used (e.g. Connect-UDP, QUIC- Aware Proxy, and / or UDP- Options);• Address of the Application Server to establish a tunnelled session using the provided encapsulation protocol;• An indication to adapt QoS based on traffic characteristics; and / or• QoS requirements in priority order or default QoS requirements and elevated QoS requirements. Each QoS requirement including a QoS reference (agreed based on SLA agreements) or one or more of the following: Requested Priority, Maximum Burst Size, Requested 5GS Delay, Requested Maximum Bitrate, Requested Guaranteed Bitrate and Requested Packet Error Rate.

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

[0187] The SMF determines configuration rules for the UPF and QoS rules for the RAN.

[0188] The Configuration rules for the UPF may be N4 rules. The Configuration rules for the UPF may comprise at least one of:• An indication to establish an IP tunnel to the Application Server using an encapsulation protocol (e.g. Connect-UDP, QUIC Aware proxy, and / or UDP- Options);• An indication to inspect traffic received over N6 for application metadata (metadata may be sent over the encapsulation protocol or may be included within RTP extension headers;• Routing rules to route the extracted application (UDP packet) towards a QoS flow towards the RAN over N3; and / or• Routing rule includes a mapping of traffic characteristics to QoS requirements (subQoS flow).

[0189] The QoS rules to the RAN may comprise a range of QoS requirements supported for a 5 QI.

[0190] The AS encapsulates the application packet (UDP Packet) with the encapsulation protocol (e.g. connect-UDP) and adds traffic characteristics (e.g. burst size) as metadata.

[0191] The UPF extracts the UDP packet and metadata from the received encapsulated packet. The UPF inserts the UDP packet to a packet over N3 to a QoS flow based on configuration rules (e.g. GTP). The UPF determines the QoS requirements from the metadata (e.g. mapping of Burst size to QoS requirement) and adds the metadata (e.g.,derived QoS requirement) in the header of the N3 packet (e.g. GTP-U) over a specific subQoS flow

[0192] If configuration rules indicate that metadata is included within RTP extension headers, the UPF extracts the metadata from the RDP headers of the UDP packet

[0193] The RAN establishes one or more radio bearers with a UE based on the range of QoS in QoS rules provided by SMF / AMF Determines QoS to apply based on the 5 QI of the sub-QoS flow and the QoS rules (of the sub-QoS flow).

[0194] 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, a controller 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.

[0195] 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.

[0196] 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.

[0197] 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.

[0198] 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 of the 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 to support the arrangements described herein.

[0199] 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.

[0200] 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.

[0201] 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 (LNA)) configured to amplify the received signal. The receiver chain 1010 may include atleast 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.

[0202] 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.

[0203] 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).

[0204] 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) orother 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).

[0205] 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.

[0206] 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.

[0207] 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 otherimplementations, the memory 1104 may reside external to the processor chipset (e.g., remote to the processor 1100).

[0208] The memory 1104 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1100, cause the processor 1100 to 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.

[0209] 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.

[0210] The processor 1100 may support wireless communication in accordance with examples as disclosed herein. The processor 1100 may be configured to or operable tosupport a means for receiving, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of a QoS flow for the data packet; determining the particular QoS requirement of the QoS flow for the data packet based at least in part on the additional data; and transmitting, to a user equipment, UE, the data packet over the QoS flow according to the particular QoS requirement.

[0211] 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.

[0212] 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.

[0213] 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.

[0214] 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 describedherein. 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.

[0215] 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 QoS flow, wherein a QoS requirement of the QoS flow is adaptable. The NE 1200 may be configured to support a means for receiving, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of the QoS flow for the data packet; determining the particular QoS requirement of the QoS flow for the data packet based at least in part on the additional data; and transmitting, to a UE, the data packet over the QoS flow according to the particular QoS requirement.

[0216] 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.

[0217] 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.

[0218] 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 1210may 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.

[0219] 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.

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

[0221] At 1302, the method 1300 may include receiving, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of a QoS flow for the data packet. The operations of 1302 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1302 may be performed by a NE as described with reference to Figure 12.

[0222] At 1304, the method 1300 may include determining the particular QoS requirement of the QoS flow 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 NE as described with reference to Figure 12.

[0223] At 1306, the method 1300 may include transmitting, to a UE, the data packet over the QoS flow according to the particular QoS requirement. 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 NE as described with reference to Figure 12.

[0224] There is provided a first network entity 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 first network entity to: receive, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of a QoS flow for the data packet; determining the particular QoS requirement of the QoS flow for the data packet based at least in part on the additional data; and transmitting, to a user equipment, UE, the data packet over the QoS flow according to the particular QoS requirement. Such a first network entity tends to reduce the delay in changing the QoS requirement of the QoS flow for the data packet.

[0225] The first network entity may be configured with a quality of service, QoS, flow, wherein a QoS requirement of the QoS flow is adaptable. The first network entity may be a radio access network, RAN. The second network entity may be a user plane function, UPF. The UE may be a remote unit. The first packet may be for an application. The first packet may comprise a first packet header. The first packet may comprise a first packet payload. The first packet header may comprise the additional data. The first packet payload may comprise the data packet.

[0226] The data packet may be an application packet. The data packet may be for the application. The data packet may be an application packet. The data packet may be part of a data packet set. The data packet may comprise user data. The data packet may be a packet data unit, PDU. The PDU may belong to a PDU set.

[0227] The information for determining the particular QoS requirement of the QoS flow for the data packet may comprise a traffic characteristic of the data packet. The information for determining the particular QoS requirement of the QoS flow for the data packet may comprise the QoS requirement for the data packet. The QoS flow may comprise an adaptive QoS requirement. The QoS flow may comprise one or more data flow(s). The additional data may comprise information for the contents of the data packet. The additional data may be metadata.

[0228] The at least one processor coupled with the at least one memory may be further configured to cause the first network entity to: receive configuration information for the QoS flow. The configuration information may comprise at least one of: a range of QoS requirements for the QoS of the QoS flow; a primary QoS requirement; a secondary QoS requirement; a mapping of one or more traffic characteristics to one or more QoS requirements; an indication of one or more sub-QoS flows within the QoS flow, wherein each of the one or more sub-QoS flows corresponds to a respective QoS requirement; a command to inspect the data packet for the additional data and / or a combination thereof. The command to inspect the data packet for the additional data may comprise an indication of an instruction for the first network entity to inspect the data packet for information for determining the QoS requirement for the data packet.

[0229] The configuration information for the QoS flow may be received from a third network entity. The third network entity may be a session management function, SMF. The configuration information may be received from the third network entity via a fourth network entity. The fourth network entity may be access and mobility management function, AMF.

[0230] The configuration information may comprise one of more configuration rules. The configuration information may comprise a QoS rule. The configuration information may comprise a QoS rule info. The configuration information may comprise a RAN configuration rule.

[0231] The range of QoS requirements for the QoS of the QoS flow may comprise a range of QoS values. The range of QoS requirements for the QoS of the QoS flow may be identified by an identifier. The identifier may be a 5G-QoS Identifier, 5QI. The 5QI maycorrespond to the range of QoS requirements for the QoS of the QoS flow. The QoS of the QoS flow may be a value within the range of QoS requirements.

[0232] The at least one processor coupled with the at least one memory being configured to cause the first network entity to determine the particular QoS requirement of the QoS flow for the data packet based on the additional data may comprise the at least one processor coupled with the at least one memory being further configured to cause the first network entity to: determine the particular QoS requirement of the QoS flow for the data packet based on the configuration information. The additional data may indicate at least one of: a burst size; a data rate requirement; a codec; an error rate; and / or the QoS requirement. The additional data may comprise information of at least one of: a burst size; a data rate requirement; a codec; an error rate; and / or the QoS requirement. The QoS requirement of the QoS flow for the data packet may be determined based at least in part on the configuration information.

[0233] The at least one processor coupled with the at least one memory may be further configured to cause the first network entity to: establish at least one radio bearer for sending the data packet over the QoS flow according to the particular QoS requirement. The at least one processor coupled with the at least one memory may be further configured to cause the first network entity to: establish at least one radio bearer for transmitting the data packet over the QoS flow according to the particular QoS requirement. The at least one processor coupled with the at least one memory may be further configured to cause the first network entity to allocate one of the at least one radio bearer to the QoS flow to support the particular QoS requirement.

[0234] The first packet may be a first encapsulated packet. The first encapsulated packet may use an encapsulation protocol. The encapsulation protocol may comprise at least one of UDP-Options, Connect-UDP, and / QUIC- Aware Proxy. The first encapsulated packet may comprise a first packet header. The additional data may be provided in the first packet header. The information for determining the particular QoS requirement of the QoS flow for the data packet may be provided in the first packet header. The first packet header of the first packet may comprise the additional data. The first packet header of the firstpacket may include the additional data. The first packet header of the first packet may comprise the metadata.

[0235] The first packet may comprise an RTP extension header. The RTP extension header may comprise the additional data. The RTP extension header may comprise the metadata. The first packet may be a UDP packet. The RTP extension header may be a header of the UDP packet.

[0236] The at least one processor coupled with the at least one memory being configured to cause the first network entity to receive the first packet may comprise the at least one processor coupled with the at least one memory being further configured to cause the first network entity to: receive the first packet via a quick, user datagram protocol, UDP, internet connection, QUIC. The first packet may be received via a quick, user datagram protocol, UDP, internet connection, QUIC.

[0237] The QUIC may be a QUIC-Aware / Connect UDP transport. The QUIC may be an N3 reference point between the first network entity and the second network entity. The first packet may be a QUIC packet. The QUIC packet may comprise a QUIC packet header. The QUIC packet may comprise a QUIC packet payload. The QUIC packet header may comprise the additional data. The QUIC packet payload may comprise the data packet.

[0238] The at least one processor coupled with the at least one memory being configured to cause the first network entity to receive the first packet may comprise the at least one processor coupled with the at least one memory being further configured to cause the first network entity to: receive the first packet via a general packet radio service, GPRS, tunneling protocol.

[0239] The first packet may be an N3 packet. The first packet may be a GTP packet. The GTP packet may comprise a GTP packet header. The GTP packet may comprise a GTP packet payload. The GTP packet header may comprise the additional data. The GTP packet payload may comprise the data packet. The GTP packet may be a GTP-user plane, GTP-U, packet. The GTP-U packet may comprise a GTP-U packet header. The GTP-U packet may comprise a GTP-U packet payload. The GTP-U packet header may comprise the additional data. The GTP-U packet payload may comprise the data packet.

[0240] The first packet may be a user datagram protocol, UDP, packet. The UDP packet may comprise a UDP packet header. The UDP packet may comprise a UDP packet payload. The UDP packet header may comprise the additional data. The UDP packet payload may comprise the data packet. The UDP packet may comprise an Options field. The Options filed may comprise the additional data.

[0241] There is further provided a method performed by a first network entity, wherein the first network entity is configured with a quality of service, QoS, flow, wherein a QoS requirement of the QoS flow is adaptable, the method comprising: receiving, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of the QoS flow for the data packet; determining the particular QoS requirement of the QoS flow for the data packet based at least in part on the additional data; and transmitting, to a user equipment, UE, the data packet over the QoS flow according to the particular QoS requirement. Such a method tends to reduce the delay in changing the QoS requirement of the QoS flow for the data packet.

[0242] The method may further comprise receiving configuration information for the QoS flow. The configuration information may comprise at least one of: a range of QoS requirements for a QoS of the QoS flow; a primary QoS requirement; a secondary QoS requirement; a mapping of one or more traffic characteristics to one or more QoS requirements; an indication of one or more sub-QoS flows within the QoS flow, wherein each of the one or more sub-QoS flows corresponds to a QoS requirement; a command to inspect the data packet for the additional data; and a combination thereof.

[0243] Determining the particular QoS requirement of the QoS flow for the data packet based on the additional data may comprise determining the particular QoS requirement of the QoS flow for the data packet based on the configuration information. The particular QoS requirement of the QoS flow for the data packet may be determined based at least in part on the configuration information. The additional data may comprise information of at least one of: a burst size; a data rate requirement; a codec; an error rate; and / or the QoS requirement. The additional data may indicate at least one of: a burst size; a data rate requirement; a codec; an error rate; and / or the QoS requirement.

[0244] The method may further comprise establishing at least one radio bearer for transmitting the data packet over the QoS flow according to the particular QoS requirement. The method may further comprise allocating one of the at least one radio bearer to the QoS flow to support the particular QoS requirement.

[0245] A first packet header of the first packet may comprise the additional data. A first packet header of the first packet may include the additional data.

[0246] Receiving the first packet may comprise receiving the first packet via a quick, user datagram protocol, UDP, internet connection, QUIC. Receiving the first packet may comprise receiving the first packet via a general packet radio service, GPRS, tunneling protocol. The first packet may be received via a quick, user datagram protocol, UDP, internet connection, QUIC.

[0247] There is further provided a method performed by a second network entity, the method comprising: transmitting, to a first network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of a QoS flow for the data packet. Such a method tends to reduce the delay in changing the QoS requirement of the QoS flow for the data packet.

[0248] The method may further comprise receiving, from a fifth network entity, the information for determining the particular QoS requirement of the QoS flow for the data packet. The fifth network entity may be an application server, AS. The method may further comprise, determining, from the information for determining the particular QoS requirement of the QoS flow for the data packet, the QoS requirement of the QoS flow for the data packet.

[0249] There is further provided a method performed by a sixth network entity, the method comprising sending, to a seventh network entity, an indication of a requirement for a QoS flow, wherein a QoS requirement of the QoS flow is adaptable. Such a method tends to reduce the delay in changing the QoS requirement of the QoS flow for the data packet. The sixth network entity may be an application function, AF. The seventh network entity may be a policy control function, PCF.

[0250] There is further provided a method performed by a seventh network entity, the method comprising receiving, from a sixth network entity, an indication of a requirement for a QoS flow, wherein a QoS requirement of the QoS flow is adaptable. Such a method tends to reduce the delay in changing the QoS requirement of the QoS flow for the data packet.

[0251] The method may further comprise determining a policy and charging control, PCC, rule for the QoS flow. The method may further comprise sending the PCC rule to a second network entity via a third network entity. The method may further comprise determining configuration information for the QoS flow. The method may further comprise transmitting the configuration information for the QoS flow to a first network entity via a third network entity and a fourth network entity.

[0252] Examples described herein propose a new type of guaranteed QoS flow to be defined where the QoS requirement of the flow can be adapted according to the traffic characteristics of the application. Such adaptive (or dynamic QoS flow) can be defined to have a range of QoS requirements (e.g. a range of GFBR or a range of MDBV values). The RAN may decide on the QoS to apply based on the traffic characteristics of the packet (received in the downlink) based on in-band information that may be included in the header of the downlink packet. The in-band information may contain information of the traffic characteristic or the QoS requirements (e.g. packet error rate) of the packet. The RAN may create multiple radio bearers for the dynamic QoS flow based on the range of QoS requirements configured for the QoS flow.

[0253] As part of Release 19, XR work solutions have been disclosed where the application server provides within N6 metadata an indication to increase the QoS. This solution requires the core network to establish two QoS flows and switch the traffic to a corresponding QoS flow 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 both QoS flows.

[0254] Some examples described herein define a new 5QI with dynamic QoS characteristics in which the AS includes traffic characteristics as metadata. Some examples described herein define a new 5QI with dynamic QoS characteristics in which the ASincludes traffic characteristics as metadata and the UPF determines QoS requirements. Some examples described herein define a new 5QI with dynamic QoS characteristics in which the AS includes QoS requirements as metadata. Some examples described herein define sub-QoS flows within a QoS flow. Each Sub-QoS flow supports different 5QIs.

[0255] In some examples described herein, the AF includes requirements for establishing a QoS flow whose QoS requirements change dynamically. The PCF determines a PCC rule that establishes a QoS flow with dynamic QoS requirements. The SMF / UPF receives over N6 metadata with information on the traffic characteristics of the packet. The SMF / UPF may forward the metadata over N3. The SMF / UPF may identify appropriate QoS to send packet based on metadata information. The RAN identifies appropriate QoS to send the packet to the UE based on metadata information.

[0256] There is further provided a network entity configured to: receive configuration information of establishment of a QoS flow with adaptive QoS requirements; receive a user plane packet with metadata information; and determine first QoS requirements of user plane packet based on the configuration information and metadata information. The network entity may be a RAN.

[0257] The configuration information may include a range of QoS requirements, a primary and secondary QoS requirements, a QoS requirement based on traffic characteristics of the application. The traffic characteristics may comprise data rate and / or burst size.

[0258] The network entity may be further configured to establish a radio bearer to accommodate delivery of the packet according to the metadata of the user plane packet. The network entity may be further configured to determine QoS requirements and add the QoS requirements within metadata information over the dynamic QoS flow.

[0259] The metadata information may include one or more of the following: Burst size, data rate requirements, codec information, packet error rate, and / or QoS requirements. The metadata information may be included within the headers of the received user plane packet. The user plane packet may be received via QUIC-Aware or Connect-UDP transport. The user plane packet may be received via a GTP transport.

[0260] 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.

[0261] 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 be applied 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.

[0262] 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 first network entity 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 first network entity to: receive, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of a QoS flow for the data packet; determining the particular QoS requirement of the QoS flow for the data packet based at least in part on the additional data; and transmitting, to a user equipment, UE, the data packet over the QoS flow according to the particular QoS requirement.

2. The first network entity of claim 1 , wherein the at least one processor coupled with the at least one memory is further configured to cause the first network entity to: receive configuration information for the QoS flow, wherein the configuration information comprises at least one of: a range of QoS requirements for a QoS of the QoS flow; a primary QoS requirement; a secondary QoS requirement; a mapping of one or more traffic characteristics to one or more QoS requirements; an indication of one or more sub-QoS flows within the QoS flow, wherein each of the one or more sub-QoS flows corresponds to a respective QoS requirement; a command to inspect the data packet for the additional data; or a combination thereof.

3. The first network entity of any one of claims 1 to 2, wherein the QoS requirement of the QoS flow for the data packet is determined based at least in part on the configuration information.

4. The first network entity of any one of claims 1 to 3, wherein the additional data indicates at least one of: a burst size; a data rate requirement; a codec; an error rate; and the QoS requirement.

5. The first network entity of any one of claims 1 to 4, wherein the at least one processor coupled with the at least one memory is further configured to cause the first network entity to: establish at least one radio bearer for transmitting the data packet over the QoS flow according to the QoS requirement.

6. The first network entity of any one of claims 1 to 5, wherein a first packet header of the first packet includes the metadata.

7. The first network entity of any one of claims 1 to 6, wherein the first packet is received via a quick, user datagram protocol, UDP, internet connection, QUIC.

8. The first network entity of any one of claims 1 to 6, wherein the first packet is received via a general packet radio service, GPRS, tunneling protocol.

9. A method performed by a first network entity, wherein the first network entity is configured with a quality of service, QoS, flow, wherein a QoS requirement of the QoS flow is adaptable, the method comprising: receiving, from a second network entity, a first packet comprising a data packet and additional data, wherein the additional data comprises information for determining a particular QoS requirement of the QoS flow for the data packet;determining the particular QoS requirement of the QoS flow for the data packet based at least in part on the additional data; and transmitting, to a user equipment, UE, the data packet over the QoS flow according to the particular QoS requirement.

10. The method of claim 9, further comprising receiving configuration information for the QoS flow, wherein the configuration information comprises at least one of: a range of QoS requirements for the QoS of a QoS flow; a primary QoS requirement; a secondary QoS requirement; a mapping of one or more traffic characteristics to one or more QoS requirements; an indication of one or more sub-QoS flows within the QoS flow, wherein each of the one or more sub-QoS flows corresponds to a respective QoS requirement; a command to inspect the data packet for the additional data; and a combination thereof.

11. The method of any one of claims 9 to 10, wherein the particular QoS requirement of the QoS flow for the data packet is determined based at least in part on the configuration information.

12. The method of any one of claims 9 to 11, wherein the additional data indicates at least one of: a burst size; a data rate requirement; a codec; an error rate; and the QoS requirement.

13. The method of any one of claims 9 to 12, further comprising establishing at least one radio bearer for transmitting the data packet over the QoS flow according to the particular QoS requirement.

14. The method of any one of claims 9 to 13, wherein a first packet header of the first packet includes the additional data15. The method of any one of claims 9 to 14, wherein the first packet is received via a quick, user datagram protocol, UDP, internet connection, QUIC.

Images