Distinguishing and optimizing QoS handling in demultiplexing multi-mode IP streams

Abstract

Aspects of the present disclosure relate to a server for multi-mode network traffic differentiation of application data, the server comprising: at least one memory; and at least one processor coupled to the at least one memory and configured to cause the server to: receive a multi-mode protocol stream from a client, where the multi-mode protocol stream includes multiplexing of a plurality of data streams of application data; receiving a protocol description defining a plurality of data streams in the multiplexing of the application data; receiving a request for an application session with traffic differentiation, the application session request including at least: a representation of a protocol description and a corresponding QoS profile of a multi-mode protocol flow; demultiplexing the one or more data streams based at least on the protocol description and a corresponding QoS profile of the multi-mode protocol stream; and mapping each of the one or more data streams corresponding to the multi-mode protocol stream to one or more QoS streams for differentiated traffic processing based at least on the corresponding QoS profile of the multi-mode protocol stream.

Description

Technical Field

[0001] The topics disclosed in this document generally relate to the area of ​​achieving differentiation and optimizing QoS processing when demultiplexing multimode IP flows. This document defines a server for multimode network service differentiation of application data, a processor for multimode network service differentiation of application data, a method for multimode network service differentiation of application data, a client for multimode network service differentiation of application data, a processor for multimode network service differentiation of application data, and a method for multimode network service differentiation of application data. Background Technology

[0002] A wireless communication system may include one or more network communication devices (such as base stations) that can support wireless communication with one or more user communication devices, which may also be referred to as user equipment (UE) or other suitable terms. The wireless communication system can support wireless communication with one or more user communication devices by utilizing the resources of the wireless communication system (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers, etc.)). Furthermore, the wireless communication system can support wireless communication across a variety of radio access technologies, including third-generation (3G) radio access technology, fourth-generation (4G) radio access technology, fifth-generation (5G) radio access technology, and other suitable radio access technologies other than 5G (e.g., sixth-generation (6G)). Summary of the Invention

[0003] The article “a (a)” preceding an element is unrestricted and should be understood to mean “at least one” or “one or more” of these elements. The terms “a (a),” “at least one,” “one or more,” and “at least one of one or more” are interchangeable. As used herein, including in claims, the word “or” used in a list of items (e.g., a list of items beginning with phrases such as “at least one of…” or “one or more of…” or “one or two 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 or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, as used herein, the phrase “based on” should not be construed as a reference to a closed set of conditions. For example, an example step described as “based on condition A” may be based on both condition A and condition B without departing from the scope of this disclosure. In other words, as used herein, the phrase “based on” should be interpreted in the same manner as the phrase “at least partially based on.” Furthermore, as used herein, including in claims, “set” can include one or more elements.

[0004] Therefore, a server for multi-mode network service differentiation of application data is provided, the server comprising: at least one memory; and at least one processor coupled to at least one memory and configured such that the server: receives a multi-mode protocol stream from a client, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of application data; receives a protocol description defining multiple data streams in the multiplexing of application data; receives a request for an application session with service differentiation, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream; demultiplexes one or more data streams at least based on the protocol description and the corresponding QoS profile of the multi-mode protocol stream; and maps each of the one or more data streams corresponding to the multi-mode protocol stream to one or more QoS streams for differentiated service processing, at least based on the corresponding QoS profile of the multi-mode protocol stream.

[0005] A processor for multi-mode network service differentiation of application data is also provided, the processor comprising: at least one controller coupled to at least one memory and configured such that the processor: receives a multi-mode protocol stream from a client, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of application data; receives a protocol description defining multiple data streams in the multiplexing of application data; receives a request for an application session with service differentiation, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream; demultiplexes one or more data streams at least based on the protocol description and the corresponding QoS profile of the multi-mode protocol stream; and maps each of the one or more data streams corresponding to the multi-mode protocol stream to one or more QoS streams for differentiated service processing, at least based on the corresponding QoS profile of the multi-mode protocol stream.

[0006] A method for multi-mode network service differentiation of application data is also provided. The method is executed by a server and includes: receiving a multi-mode protocol stream from a client, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of application data; receiving a protocol description that defines multiple data streams in the multiplexing of application data; receiving a request for an application session with service differentiation, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream; demultiplexing one or more data streams based at least on the protocol description and the corresponding QoS profile of the multi-mode protocol stream; and mapping each of the one or more data streams corresponding to the multi-mode protocol stream to one or more QoS streams for differentiated service processing based at least on the corresponding QoS profile of the multi-mode protocol stream.

[0007] A client for multi-mode network service differentiation of application data is also provided, the client comprising: at least one memory; and at least one processor coupled to at least one memory and configured such that the client: sends a multi-mode protocol stream to a server, wherein the multi-mode protocol stream comprises: multiplexing of multiple data streams of application data; sends a protocol description defining the multiple data streams in the multiplexing of application data; and sends a request for an application session with service differentiation, the application session comprising at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream.

[0008] A processor for multi-mode network service differentiation of application data is also provided, the processor comprising: at least one controller coupled to at least one memory and configured to cause the processor to: send a multi-mode protocol stream to a server, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of application data; send a protocol description defining the multiple data streams in the multiplexing of application data; and send a request for an application session with service differentiation, the application session including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream.

[0009] A method for multi-mode network service differentiation of application data is also provided. The method is executed by a client and includes: sending a multi-mode protocol stream to a server, wherein the multi-mode protocol stream includes multiplexing of multiple data streams of application data; sending a protocol description that defines multiple data streams in the multiplexing of application data; and sending a request for an application session with service differentiation, the application session including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream. Attached Figure Description

[0010] Figure 1 Examples of wireless communication systems according to various aspects of this disclosure are illustrated.

[0011] Figure 2 The diagram illustrates an overview of the core network XRM architecture for processing PDU sets.

[0012] Figure 3 The illustration shows an example of a single-byte RTP header extension used to mark PDU set information.

[0013] Figure 4 The illustration shows an example of a two-byte RTP header extension used to mark PDU set information.

[0014] Figure 5 illustrates the mapping of two PDU sets with different importance and characteristics to QoS flows and DRBs, respectively.

[0015] Figure 6An overview of the RTP and RTCP stacks is provided.

[0016] Figure 7a The diagram illustrates the packet format and header information for RTP packets.

[0017] Similarly, Figure 7b The diagram illustrates the packet format and header information for SRTP packets.

[0018] Figure 8 The diagram illustrates an overview of the WebRTC stack.

[0019] Figure 9 The diagram illustrates the extended format and related syntax of the RTP / SRTP header.

[0020] Figure 10 This demonstrates the TLS 1.3-based encryption and authentication of the QUIC PDU.

[0021] Figure 11 An HTTP / 3 datagram is shown as the payload used for a QUIC datagram.

[0022] Figure 12 The diagram illustrates a general demultiplexing solution and a mapping of multi-mode media content to one or more individual QoS streams for differentiated services in the downlink via tunneling over N6.

[0023] Figure 13 A general demultiplexing solution is shown, along with a mapping of multi-mode media content to one or more individual QoS streams for differentiated services in the uplink via tunnel transmission between the UE and the PSA UPF (QUIC as an example).

[0024] Figure 14 The diagram illustrates a UDP proxy for a multi-mode QUIC tunnel for an XR video application with three data streams: an RTP video stream tagged with PDU set information, an RTP audio stream, and an RTCP control message.

[0025] Figure 15 Examples of user equipment (UE) according to various aspects of this disclosure are illustrated.

[0026] Figure 16 Examples of processors according to various aspects of this disclosure are illustrated.

[0027] Figure 17 Examples of network devices (NEs) according to various aspects of this disclosure are illustrated.

[0028] Figure 18 The diagram illustrates a flowchart of a method according to various aspects of this disclosure.

[0029] Figure 19 A flowchart illustrating another method according to various aspects of this disclosure is shown. Detailed Implementation

[0030] Multiplexing heterogeneous application data streams within a single network application session (i.e., a 5-tuple) presents several challenges, particularly where the communication path crosses the transport layer of the wireless communication network. Without demultiplexing and understanding the potential heterogeneous QoS requirements of the multiplexed data streams, multiplexed streams of multimedia application data are not easily transmitted in an optimized manner on such networks.

[0031] Traditionally, heterogeneous application data is served across multiple network application sessions in managed wireless networks (such as 4G and 5G) with differentiated QoS processing. The managed QoS processing collectively aims to meet the heterogeneous transmission requirements of different data streams (i.e., latency budget, packet error rate) and optimize resource allocation across the core network and radio access network, while simultaneously satisfying overall application QoS requirements. Therefore, there is a need to improve the QoS processing of multiplexed multimedia application data in managed wireless communication networks.

[0032] The solution proposed in this paper involves including at least one identifier in the flow. The identifier can be a flow identifier, or alternatively, a range of flow identifiers. UPF can then distinguish and demultiplex the flow based on the identifier(s), thereby providing a mapping of the flow to the appropriate QoS flow. This solution can be applied even if the content of the flow includes encrypted or partially encrypted services.

[0033] For each QoS stream of each media within the same IP stream, the PCF can trigger QoS monitoring to detect packet latency for each QoS stream. This is necessary when packets from a particular QoS stream are delayed beyond a configurable value (which can lead to a poor user experience). If the packet latency of a QoS stream exceeds a threshold, the PCF can adjust the QoS requirements of the QoS stream to ensure that packet latency meets packet latency standards.

[0034] Various aspects of this disclosure are described in the context of wireless communication systems.

[0035] Figure 1An example of a wireless communication system 100 according to various aspects of this disclosure is illustrated. The wireless communication system 100 may include one or more NEs 102, one or more UEs 104, and a core network (CN) 106. The wireless communication system 100 may support various radio access technologies. In some implementations, the wireless communication system 100 may be a 4G network, such as an LTE network or an LTE-A network. In some other implementations, the wireless communication system 100 may be an NR network, such as a 5G network, a 5G-A network, or a 5G Ultra Wideband (5G-UWB) network. In other implementations, the wireless communication system 100 may be a combination of 4G and 5G networks, or other suitable radio access technologies, including IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), and IEEE 802.20. The wireless communication system 100 may support radio access technologies other than 5G, such as 6G. In addition, the wireless communication system 100 can support technologies such as time division multiplexing (TDMA), frequency division multiplexing (FDMA), or code division multiplexing (CDMA).

[0036] One or more NEs 102 may be distributed throughout a geographic area to form a wireless communication system 100. One or more NEs 102 described herein may be, include, or may be referred to as a network node, base station, network element, network function, network entity, radio access network (RAN), NodeB, eNodeB (eNB), next-generation NodeB (gNB), or other suitable terms. NEs 102 and UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, NEs 102 and UE 104 may perform wireless communication (e.g., receive signaling, send signaling) via a Uu interface.

[0037] NE 102 can provide a geographic coverage area for which NE 102 can support services of one or more UE 104s within that geographic coverage area. For example, NE 102 and UE 104 can support wireless communication of signals associated with services (e.g., voice, video, packet data, messaging, broadcasting, etc.) based on one or more radio access technologies. In some implementations, NE 102 can be mobile, 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 can overlap, but different geographic coverage areas can be associated with different NE 102s.

[0038] One or more UEs 104 may be distributed throughout the geographic area of ​​the wireless communication system 100. UE 104 may include or be referred to as a remote unit, mobile device, wireless device, remote device, subscriber device, transmitter device, receiver device, or some other suitable term. In some implementations, UE 104 may be referred to as a unit, station, terminal, or client, etc. Additionally or alternatively, UE 104 may be referred to as an Internet of Things (IoT) device, Internet of Everything (IoE) device, or Machine Type Communication (MTC) device, etc.

[0039] UE 104 may be able to support direct wireless communication with other UE 104s via a communication link. For example, UE 104 may support direct wireless communication with another UE 104 via 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, UE 104 may support direct wireless communication with another UE 104 via a PC5 interface.

[0040] NE 102 can support communication with CN 106 or with another NE 102, or both. For example, NE 102 can interface with other NE 102 or CN 106 via one or more backhaul links (e.g., S1, N2, N3, or network interfaces). In some implementations, NE 102 can communicate directly with each other. In some other implementations, NE 102 can communicate indirectly with each other (e.g., via CN 106). In some implementations, one or more NE 102 may include sub-components (such as access network entities), which may be examples of access node controllers (ANCs). The ANC can communicate with one or more UE 104s via one or more other access network transport entities (which may be referred to as radio headends, smart radio headends, or transmit / receive points (TRPs)).

[0041] CN 106 can support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. CN 106 can be an evolved packet core (EPC) or a 5G core (5GC), which may include control plane entities that manage access and mobility (e.g., Mobility Management Entity (MME), Access and Mobility Management Functions (AMF)) and user plane entities that route packets or interconnects to external networks (e.g., Serving Gateway (S-GW), Packet Data Network (PDN) Gateway (P-GW), or User Plane Functions (UPF)). In some implementations, the control plane entities may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signaling bearers, etc.) for one or more UEs 104 served by one or more NEs 102 associated with CN106.

[0042] CN 106 can communicate with the packet data network via one or more backhaul links (e.g., via S1, N2, N3, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 can communicate with the application server. UE 104 can establish a session with CN 106 via NE 102 (e.g., a Protocol Data Unit (PDU) session, etc.). CN 106 can use the established session (e.g., an established PDU session) to route services (e.g., control information, data, etc.) between UE 104 and the application server. The PDU session may be an example of a logical connection between UE 104 and CN 106 (e.g., one or more network functions of CN 106).

[0043] In the wireless communication system 100, NE 102 and UE 104 can use the resources of the wireless communication system 100 (e.g., time resources (e.g., symbols, time slots, subframes, frames, etc.) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communication). In some implementations, NE 102 and UE 104 can support different resource structures. For example, NE 102 and UE 104 can support different frame structures. In some implementations, such as in 4G, NE 102 and UE 104 can support a single frame structure. In some other implementations, such as in 5G and other suitable radio access technologies, NE 102 and UE 104 can support various frame structures (i.e., multiple frame structures). NE 102 and UE 104 can support various frame structures based on one or more digital schemes.

[0044] The wireless communication system 100 may support one or more digital schemes, and the digital schemes may include subcarrier spacing and cyclic prefixes. A first digital scheme (e.g., μ =0) can be associated with the first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first digital scheme (e.g., ...) associated with the first subcarrier spacing (e.g., 15 kHz) is... μ =0) can utilize one time slot per subframe. The second digital scheme (e.g., μ =1) can be associated with the second subcarrier spacing (e.g., 30 kHz) and the normal cyclic prefix. The third digital scheme (e.g., μ =2) can be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth digital scheme (e.g., μ =3) can be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth digital scheme (e.g., μ=4) can be associated with the fifth subcarrier spacing (e.g., 240 kHz) and the normal cyclic prefix.

[0045] The time intervals of resources (e.g., communication resources) can be organized according to frames (also known as radio frames). Each frame can have a duration, for example, 10 milliseconds (ms). In some implementations, each frame can include multiple subframes. For example, each frame can include 10 subframes, and each subframe can have a duration, for example, 1 ms. In some implementations, each frame can have the same duration. In some implementations, each subframe of a frame can have the same duration.

[0046] Alternatively or concurrently, the time intervals of resources (e.g., communication resources) can be organized according to time slots. For example, a subframe may include a certain number (e.g., quantity) of time slots. The number of time slots in each subframe may also depend on one or more digital schemes supported in the wireless communication system 100. For example, a first digital scheme, a second digital scheme, a third digital scheme, a fourth digital scheme, and a fifth digital scheme (i.e., ...) associated with corresponding subcarrier intervals of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz. μ =0、 μ =1、 μ =2、 μ =3、 μ =4) One time slot per subframe, two time slots per subframe, four time slots per subframe, eight time slots per subframe, and 16 time slots per subframe can be used, respectively. Each time slot can include a certain number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of time slots in a subframe can depend on the digital scheme. For a normal cyclic prefix, a time slot can include 14 symbols. For an extended cyclic prefix (e.g., for a 60kHz subcarrier spacing), a time slot can include 12 symbols. The relationship between the number of symbols per time slot, the number of time slots per subframe, and the number of time slots per frame for both normal and extended cyclic prefixes can depend on the digital scheme. It should be understood that for a first digital scheme (e.g., quantity) associated with a first subcarrier spacing (e.g., 15kHz), μ The reference of =0 can be used interchangeably between subframes and time slots.

[0047] In the wireless communication system 100, the electromagnetic (EM) spectrum can be divided into various categories, frequency bands, frequency channels, etc., based on frequency or wavelength. For example, the wireless communication system 100 can support one or more operating frequency bands, such as frequency range names FR1 (410MHz-7.125GHz), FR2 (24.25GHz-52.6GHz), FR3 (7.125GHz-24.25GHz), FR4 (52.6GHz-114.25GHz), FR4a or FR4-1 (52.6GHz-71GHz), and FR5 (114.25GHz-300GHz). In some implementations, NE 102 and UE 104 can perform wireless communication on one or more operating frequency bands. In some implementations, FR1 can be used by NE 102 and UE 104, as well as other devices or apparatuses, for cellular communication services (e.g., control information, data). In some implementations, FR2 can be used by NE 102 and UE 104, as well as other devices or apparatuses, for short-range, high data rate capabilities.

[0048] FR1 can be associated with one or more number schemes (e.g., at least three number schemes). For example, FR1 can be associated with the following: a first number scheme (e.g., μ =0), which includes a 15kHz subcarrier spacing; the second digital scheme (e.g., μ =1), which includes a 30kHz subcarrier spacing; a third digital scheme (e.g., μ =2), which includes a subcarrier spacing of 60 kHz. FR2 can be associated with one or more digital schemes (e.g., at least two digital schemes). For example, FR2 can be associated with a third digital scheme (e.g., μ =2), which includes a 60kHz subcarrier spacing; the fourth digital scheme (e.g., μ =3), which includes a subcarrier spacing of 120kHz.

[0049] The transmission of multimedia application data (e.g., AR / VR / XR, interactive and streaming services, web applications) typically involves multiplexed data streams (such as video, audio, control and feedback metadata, application metadata, etc.). Multiplexing multiple data streams for an application offers deployment advantages. These advantages can include: reduced network port usage, reduced overhead for implementers managing different sessions of the application, and / or providing a generic, network-friendly API with the desired functionality (e.g., WebRTC, WebRTransport).

[0050] However, multiplexing heterogeneous application data streams within a single network application session (i.e., a 5-tuple) presents several challenges, particularly at the transport layer where communication paths traverse wireless communication networks. Without demultiplexing and understanding the potential heterogeneous QoS requirements of the multiplexed data streams, multiplexed streams of multimedia application data are not easily transmitted in an optimized manner over such networks.

[0051] Traditionally, heterogeneous application data is served across multiple network application sessions in managed wireless networks (e.g., 4G, 5G) with differentiated QoS processing. The managed QoS processing collectively aims to meet the heterogeneous transmission requirements of different data streams (i.e., latency budget, packet error rate) and optimize resource allocation across the core network and radio access network, while simultaneously satisfying overall application QoS requirements. Therefore, there is a need to improve the QoS processing of multiplexed multimedia application data in managed wireless communication networks.

[0052] The solutions described in this paper involve using a new multiplexing or protocol description and then demultiplexing the multiplexed data streams of the application session for differentiated and optimized QoS processing based on the multiplexing or protocol description.

[0053] Another solution described in this paper includes providing a protocol description that includes: a list of multiplexed data streams and their respective potentially different QoS requirements, which are part of a general application QoS requirement, while taking into account 5GS support for tunneling protocols via N6 between the UPF and the application server, or between the UE and the UPF. The tunneling protocol helps identify the media multiplexed over the same IP session.

[0054] It should be noted that the solutions and embodiments described herein can be interchangeably applied to both applications serving one or more users and web services (e.g., AR / VR immersive telephone calling services).

[0055] The Extended Reality (XR) field encompasses a wide range of applications and services where multimedia streams are multiplexed within a single network application session. Such a network application session can be defined by a 5-tuple containing the source IP address, destination IP address, source network port, destination network port, and a protocol number as an identifier. For example, an XR application based on WebRTC or an RTP / SRTP protocol stack can contain one or more video and audio streams, multiplexed with control and feedback metadata and application metadata (e.g., user gesture information, user input actions, etc.) over a single application data network session.

[0056] It should be noted that while some of the examples presented in this paper use XR as a reference use case or series of applications for the solutions defined herein, those skilled in the art will recognize that the proposed solutions are generally applicable to other multimedia applications and can be embodied through different types of transport and network protocol stacks (e.g., QUIC, WebRTC, WebRTransport, etc.).

[0057] Subsequently, Extended Reality (XR) was used as a general term for different types of reality, such as Virtual Reality, Augmented Reality, and Mixed Reality.

[0058] Virtual reality (VR) is a rendered version of a delivered visual and audio scene. In this case, the rendering is designed to mimic real-world visual and auditory stimuli as naturally as possible as an observer or user moves within an area defined by the application. Virtual reality typically (but not necessarily) requires the user to wear a head-mounted display (HMD) to completely replace the user's field of vision with simulated visual components, and headphones to provide accompanying audio. In VR, some form of head and motion tracking is usually also required to allow updates to the simulated visual and audio components to ensure that objects and sound sources appear consistent with the user's movements from their perspective. In some implementations, additional components may be provided for interacting with the virtual reality simulation, but this is not strictly necessary.

[0059] Augmented reality (AR) refers to providing users with additional information or artificially generated items, or content overlaid on their current environment. Such additional information or content is typically visual and / or auditory, and its observation of the current environment can be direct without intermediate sensing, processing, and rendering, or it can be indirect, in which its perception of its environment is relayed via sensors and can be augmented or processed.

[0060] Mixed Reality (MR) is a higher form of AR in which some virtual elements are inserted into the physical scene to provide the illusion that these elements are part of the real scene.

[0061] XR refers to all combinations of real and virtual environments and human-computer interactions generated by computer technology and wearable devices. It includes representative forms (such as AR, MR, and VR) and the interpolation zone between them. The level of virtuality ranges from partial sensory input to fully immersive VR. In some cases, key aspects of XR are considered extensions of the human experience, particularly those related to a sense of presence (represented by VR) and cognitive acquisition (represented by AR).

[0062] In 3GPP Release 18, the XR Media (XRM) feature at the core network (CN) level introduced the concept of PDU sets to handle the QoS requirements of XRM applications and flows, offering granularity superior to 5G Rel-17 QoS flow possibilities. Therefore, according to 3GPP Technical Report TR 23.700-60 (v0.0.3), a PDU set consists of one or more PDUs carrying the payload (e.g., a frame or video slice for XRM services) of an information element generated at the application level. In some implementations, the application layer requires all PDUs in the PDU set to use the corresponding information element. In other implementations, the application layer can still recover some or all of the information elements even if some PDUs are lost.

[0063] Furthermore, PDU sets are associated with QoS requirements in terms of latency budget and error rate, which can be defined as PDU set latency budget (PSDB) and / or PDU set error rate (PSER), as defined in 3GPP technical report TR 23.700-60 (v0.0.3, May 2022) entitled "Study on XR (Extended Reality) and media services" and 3GPP technical specification TS 23.501 (v18.1.0, April 2023) entitled "System architecture for the 5G System (5GS)". The PDU set latency budget (PSDB) defines the upper limit of the time that a PDU set can be delayed between the UE and the N6 endpoint at the UPF. The PSDB applies to DL PDU sets received by the UPF via the N6 interface and UL PDU sets transmitted by the UE, respectively. The PDU set error rate (PSER) defines the upper limit on the rate at which a set of PDUs (e.g., the set of IP packets that make up the PDU set) has been processed by a transmitter of a link-layer protocol (e.g., an RLC in a 3GPP-accessible RAN). The PSER can be used to determine the upper limit of the non-congestion-related packet loss rate.

[0064] Figure 2 The diagram illustrates an overview of the core network (CN) XRM architecture for processing PDU sets. Figure 2System 200 is illustrated, comprising: Extended Reality Media Application Function (XRM AF) 210, Policy and Control Function (PCF) 215, Session Management Function (SMF) 220, Access and Mobility Function (AMF) 225, Radio Access Network (RAN) 230, User Equipment (UE) 235, User Plane Function (UPF) 240, and Extended Reality Application 245. UE 235 may include UE 104, 235, 1235, 1335, 1435, or 1500 as described herein. UPF 240 may include UPF 1240, 1340, or 1440 as described herein. The operation of system 200 will now be described in an example of downlink service; similar procedures can be used for uplink service.

[0065] At position 280, XRM AF 210 determines the PDU set requirements.

[0066] At position 281, XRM application function 210 provides PCF 215 with QoS requirements for packets belonging to the PDU set, as well as information identifying the application (i.e., a 5-tuple or application ID). QoS requirements may include PSDB and PSER. XRM AF 210 may also include importance parameters for the PDU set and information for the core network to identify packets belonging to the PDU set.

[0067] At position 282, PCF 215 derives QoS rules for XR applications and specific QoS requirements for PDU sets, and configures SMF 220. QoS rules can use 5G QoS identifiers (5QI) for XR media services. PCF 215 sends the QoS rules to SMF 220. PCF 215 can include PCC rules in communications to SMF 220 according to the importance of the PDU set. PCC rules can be derived based on information received from XRM AF 210 or based on operator configuration.

[0068] At position 283, SMF 220 establishes a QoS flow based on the QoS rules of PCF 215 and configures UPF to route packets for XR applications to the QoS flow. It also enables PDU set processing. SMF 220 also provides a QoS profile containing PDU set QoS requirements to RAN 230 via AMF 225. AMF 225 can provide the QoS profile containing PDU set QoS requirements to RAN 230 in the N2 SM container. Furthermore, AMF 225 can provide QoS rules to UE 235 in the N1 SM container.

[0069] At position 284, UPF 240 examines packets and determines which packets belong to the PDU set. This determination can be based on a given UPF, for example, by examining the RTP packet header, as described in 3GPP Technical Specification 23.501 v18.2.2 (June 2023) entitled "System architecture for the 5G System (5GS)", or based on PDU set information with AS markings sent via RTP PDU set header extensions, as described in 3GPP TS 23.501 v182.2 and 3GPP Technical Specification 26.522 v0.1.1 (September 2023) entitled "5G Real-time Media Transport Protocol Configurations", which uses, for example, the PDU set information RTP header extension urn:3gpp:pdu-set-marking:rel-18. Packet inspection may include examining RTP packets. When the UPF 240 detects packets belonging to a PDU set, it marks the packets as belonging to the PDU set within the GTP-U header. The GTP-U header information includes the PDU set sequence number and the size of the PDU set. The UPF 240 can also determine the importance of the PDU set based on information from the UPF 240 implementation components, information provided by the XRMAF 210, or information provided as metadata from the XRM application server. Based on the importance of the PDU set, the UPF 240 can route traffic to the corresponding QoS flow 1 (according to rules received from the SMF 220) or include the importance of the PDU set within the GTP-U header. QoS flow 1 can include GTP-U headers, and these headers can include PDU set information.

[0070] At 285, RAN 230 identifies packets belonging to the PDU set (based on GTP-U labeling) and processes these packets according to the QoS requirements of the PDU set provided by SMF 220. In one implementation, the RAN 230 node can guarantee the delivery of PDU set packets using different radio bearers with higher QoS requirements (based on PDU set PSDB / PSER), while using different radio bearers based on the 5QI of the QoS flow for non-PDU set packets.

[0071] The above example pertains to downlink (DL) traffic. Reciprocal processing applies to uplink (UL) traffic, where the role of packet inspection by UPF240 is assumed by UE 235. UE 235 is expected to inspect uplink packets, determine packets belonging to the PDU set, and accordingly send the PDU set signal to RAN 230 for scheduling and resource allocation corresponding to the associated DRBs (i.e., PSDB and PSER) that can meet the QoS requirements of the PDU set. The low-level signaling mechanisms associated with UL UE-to-RAN information transfer depend on the specifications and implementation of the RAN signaling procedures.

[0072] However, in XRM version 18, for example, the 3GPP technical specification TS 23.501 v18.2.2 (June 2023) entitled "System architecture for the 5G System (5GS)", after PDU set QoS integration processing is enabled, the PSA UPF identifies the PDUs belonging to the PDU set, and determines the following PDU set information sent to the NG-RAN in the GTP-U header for each PDU set.

[0073] PDU set information includes: • PDU set serial number. • The end of the PDU set is indicated by the PDU. • PDU sequence number within the PDU set. • PDU set size (in bytes). • PDU set importance, which identifies the relative importance of a PDU set compared to the importance of other PDU sets within a QoS flow.

[0074] Then, the PDU set information is used by NG-RAN for QoS processing based on the PDU set, as described above.

[0075] NG-RAN can use cross-QoS flow priorities and PDU set importance within a QoS flow for PDU set-level packet dropping in the presence of congestion. Such priorities are described in Clause 5.7.3.3 of 3GPP TS 23.501 v18.2.2.

[0076] 3GPP TS 23.501 v18.2.2 also specifies that the PSA UPF identifies PDUs belonging to a PDU set, and if the UPF receives a PDU that does not belong to a PDU set (e.g., not marked by the AS via PDU set information) based on the protocol description for the PDU set identification, the UPF still maps the PDU to the PDU set and determines the PDU set information as described above. This ensures that for QoS flows with an enabled PDU set, all PDUs belong to the 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 on a pre-configured default importance in some examples and based on the default importance notified by the AS / AF signal in other examples.

[0077] The AS PDU set information listed above can be provided via a one-byte RTP header extension to mark the PDU set and burst end, as defined in 3GPP TS 26.522 v0.1.1 (September 2023) entitled “5G Real-time Media Transport Protocol Configurations”.

[0078] In some implementations, 5GS includes the PDU set tag and its related information by AS in the RTP header extension, as described above, in accordance with IETF RFC 8285. This can be as follows: Figure 3 and Figure 4 The format shown is either single-byte or double-byte.

[0079] Figure 3 The illustration shows an example of a single-byte RTP header extension 300 used to mark PDU set information. Figure 4 The illustration shows an example of a two-byte RTP header extension 400 used to mark PDU set information.

[0080] and Figure 3 and Figure 4 The semantics associated with the PDU set information fields of the RTP header extension syntax outlined in the document are as follows.

[0081] “E” 332, 432 is a 1-bit representation of the Boolean flag. It should be set to 1 for the last PDU in the PDU set, and to 0 for all other PDUs in the PDU set.

[0082] “EDB” 334 and 434 are 3-bit representations of the data burst end indication. These 3 bits can be encoded, for example, as a data burst end indication, according to the encoding and guidelines provided in Clause 4.4.2.6.1 of the 3GPP technical specification TS 26.522 v0.1.1 (September 2023) entitled “5G Real-time Media Transport Protocol Configurations”.

[0083] "PSI" 336 and 436 are 4-bit representations indicating the importance of a PDU set compared to other PDU sets within the same RTP stream or session. Lower values ​​should indicate higher importance, with 0 indicating the most important PDU set and 15 indicating the least important PDU set. This field applies to various audio / video codecs supported by 5GS (e.g., H.264, H.265, HE-AAC, etc.).

[0084] The PSSN 340 and 440 include a 10-bit representation that encodes the sequence number of the PDU set to which the current PDU belongs, serving as a 10-bit numeric identifier for the PDU set. The PSSN can take values ​​between 0 and 1023, and even in some examples, the value can wrap back to 1023. Receivers (e.g., UPFs) can also use a combination of the RTP packet sequence number and the PSSN to uniquely distinguish any PDU set.

[0085] The PSN 342, 442 is a 6-bit representation of the sequence number of the current PDU within the PDU set. For the first PDU in the PDU set, the PSN should be set to 0 and monotonically incremented for each PDU in the set, following the order of transmission from the transmitter. The receiver (e.g., a UPF, or in some examples, a gNB) can use the RTP packet sequence number in conjunction with the PSN to distinguish PDUs within a PDU set containing more than 64 PDUs.

[0086] The "PSSize" field (344, 444) is a 24-bit representation indicating the total size of all PDUs in the PDU set to which this PDU belongs. This field is optional and subject to SDP signaling provide / response negotiation, where the AS can indicate whether it will be able to provide the size of the PDU set for an RTP stream or RTP session. In some embodiments, if the field is not enabled, it will not exist. However, in some embodiments, if the field is enabled, but the AS cannot determine the PDU size for a particular PDU set, the AS will set the value to 0 for all PDUs in that set. In some implementations, PSSize indicates the size of the PDU set, including the RTP / UDP / IP header encapsulation overhead of its corresponding PDUs. Alternatively, PSSize indicates the sum of the RTP payload sizes of all PDUs present in the PDU set. PSSize is represented in bytes. Because this field is optionally appended to the RTP header extension, its presence is negotiated and signaled via the "pdu-set-size" extension attribute through the SDP provide / response process, as shown in the example: ``` a=extmap:1 sendonly urn:3gpp:pdu-set-marking:rel-18 pdu-set-size ```

[0087] Reciprocal processing applies to the UL, while the role of UPF packet inspection is undertaken by the UE, which is expected to inspect packets, determine packets belonging to the PDU set, and accordingly send the PDU set signal to the RAN for scheduling and resource allocation corresponding to the associated DRB (i.e., PSDB and PSER) that can meet the QoS requirements of the PDU set. The low-level signaling mechanisms associated with UL UE-RAN information transfer depend on the specifications and implementation of the RAN signaling procedures.

[0088] Based on QoS flow mapping and RAN procedures, given two different PDU sets with different PDU set attributes (such as PDU set importance), several alternative PDU set to QoS flow to DRB mappings are possible. Figure 5 illustrates two PDU sets with different importance and characteristics mapped to QoS flows and DRBs, respectively. In this example, PDU set 1 is considered to have high importance and strict QoS requirements (i.e., PSDB, PSER, etc.), while PDU set 2 has lower importance and potentially lower QoS requirements than PDU set 1 (i.e., PSDB, PSER, etc.). As shown in Figure 5, the PDU set to QoS flow to DRB instantiation can be performed as follows, based on the QoS flow policy and Layer 2 RAN procedures.

[0089] Figures 5a to 5dThe diagram illustrates a 5GS PDU set-aware QoS processing framework for PDU set-to-QoS flow-to-DRB mapping. Depending on the QoS flow mapping and RAN procedures, several alternative PDU set-to-QoS flow-to-DRB mappings are possible given two different PDU sets with different PDU set attributes (such as PDU set importance). Figures 5a to 5d The diagram illustrates several options where two PDU sets 510 with different importance and characteristics are mapped to a QoS flow 520 and a data radio bearer (DRB) 530, respectively. In this example, PDU set 1 is considered to have high importance and strict QoS requirements (i.e., PSDB, PSER, etc.), while PDU set 2 has low importance and potentially lower QoS requirements than PDU set 1 (i.e., PSDB, PSER, etc.). Figures 5a to 5d As shown, based on the QoS flow policy and Layer 2 RAN procedures, PDU set 510 to QoS flow 520 to DRB 530 can be instantiated as follows:

[0090] Figure 5a The diagram illustrates a one-to-one mapping: where QoS flows 520 and DRBs 530 are separated between high-importance and low-importance PDU sets 510, thereby finely optimizing radio and network resources on a per-PDU-set basis.

[0091] Figure 5b The diagram illustrates an M-to-M-to-1 mapping: where the separation between high-importance and low-importance PDU sets 510 is performed only at the QoS flow level, and the same DRB 530 is used for over-the-air transmission of both PDU sets 510. This may result in over-supplying radio resources to the low-importance PDU set 510, but it requires lower RAN complexity and management overhead.

[0092] Figure 5c The diagram illustrates an M-to-1 mapping: there is no separation between the QoS flow 520 and DRB 530 for PDU sets 510 of different importance, and when handling QoS management across both CN and RAN, the QoS requirements of higher importance PDU sets are prioritized; this may result in over-suppliing resources for the lower importance PDU set 510 in both CN and RAN implementations, but it requires lower overhead and control within the 5GSQoS framework.

[0093] Figure 5dThe diagram illustrates an M-to-1-to-M mapping: QoS flows 520 between PDU set importance levels are not separated, but different DRBs 530 are used to meet individual requirements at different importance levels; this reduces the complexity of QoS flow management, and uses PDU set information to filter PDU sets 510 on different DRBs 530 to better match QoS requirements at the RAN level and optimize resource allocation based on individual PDU set needs.

[0094] The transmission of multiplexed multimedia streams is mainly handled by WebRTC, or by RTP / SRTP and QUIC.

[0095] In 3GPP Release 17, SA4 analyzes XR service models, as described in 3GPP Technical Report TR 26.926 (v1.3.0 – January 2023), entitled "Traffic Models and Quality Evaluation Methods for Media and XR Services in 5G Systems," and summarizes the QoS requirements at the application level in terms of latency budget, data rate, and error rate for a satisfactory experience. These result in four additional 5QIs for 5GS XR QoS streams, as the latency-critical GBR 5QI value is 87-90. These are described in 3GPP Technical Specification TS 23.501 (v18.1.0 – April 2023), entitled "System architecture for the 5G System (5GS)," specifically in Table 5.7.4-1. The latter applies to XR video streams and controls the metadata required to provide immersive and interactive XR experiences.

[0096] XR video services primarily consist of multiple DL / UL video streams with high resolution (e.g., typically at least 1080p dual-eye buffers), frames per second (e.g., 60+ fps), and high bandwidth (e.g., typically at least 20-30 Mbps). These multiple DL / UL video streams need to be transmitted across the network with minimal latency (typically up to 15-20 ms) to maintain reduced end-to-end application round-trip latency. Given the reliance of XR applications on cloud / edge processing (e.g., content downloading, viewport generation and configuration, viewport updates, viewport rendering, media encoding / transcoding, etc.), this latter requirement is crucial. Furthermore, XR services also include one or more audio streams, as well as user interaction metadata (e.g., user actions, user input, user gestures), or alternatively, feedback and control metadata (e.g., actions, XR spatial metadata, and transport control and feedback messages on RTCP).

[0097] The aforementioned immersive and interactive XR applications typically require real-time applicable transport architectures and protocols. As part of the latter, existing technologies are represented by the following: Real-time Transport Protocols (RTPs, as defined in IETF standard RFC 3550-RTP: "A Transport Protocol for Real-Time Applications"), Secure Real-time Transport Protocols with Secure Configurations (SRTPs, as defined in IETF standard RFC 3711: "The Secure Real-time Transport Protocol"), and WebRTC, a network-oriented stack for real-time communication (defined by w3.org in WebRTC 1.0: "Real-Time Communication Between Browsers").

[0098] RTP is a media codec-independent network protocol with application-layer frames. RTP is used to deliver multimedia (e.g., audio, video, etc.) data in real time over IP networks. It is used in conjunction with its sister protocol (i.e., Real-time Transmission Control Protocol (RTCP)) for control to provide end-to-end features such as jitter compensation, packet loss and out-of-order delivery detection, synchronization, and source-stream multiplexing.

[0099] Figure 6 An overview of the RTP and RTCP stacks is provided. IP layer 605 carries signaling from data plane 610 and forms control plane 650. The data plane 610 stack includes functions for User Datagram Protocol (UDP) 612, RTP 616, RTCP 614, media codec 620, and quality control 622. The control plane 650 stack includes functions for UDP 652, Transmission Control Protocol (TCP) 654, Session Initiation Protocol (SIP) 662, and Session Description Protocol (SDP) 664.

[0100] SRTP is a secure version of RTP and is defined by the IETF in RFC 3711, "The Secure Real-time Transport Protocol (SRTP)". SRTP provides encryption (primarily through payload confidentiality), message authentication and integrity protection (through PDUs, i.e., headers and payloads, and signatures), as well as protection against replay attacks. Similar to RTP, SRTP's sister protocol is SRTCP. This provides the same functionality to RTCP counterparts. Therefore, in a standard SRTP version, the RTP header information remains accessible but cannot be modified, while the payload is encrypted. These security provisions are as follows: Figure 7b As shown in the section. Furthermore, the key exchange and additional security parameters required for SRTP are based on the Datagram Transport Layer Security (DTLS) key exchange process. For these reasons, SRTP is used as the transport protocol for media within the WebRTC stack, ensuring secure RTC multimedia communication on the web browser interface.

[0101] Figure 7a The diagram illustrates the packet format and header information of RTP packet 730, and... Figure 7b The diagram illustrates the packet format and header information of SRTP packet 760. The following discussion will further examine individual fixed header information and complete header information (including header extensions) for RTP / SRTP packets. It can be noted that the fixed header information includes “V” 732, 762, “P” 733, 763, “X” 734, 764, “CC” 736, 766, “M” 738, 768, “PT” 740, 770, “Sequence Number” 742, 772, “Timestamp” 744, 774, “Synchronization Source (SSRC) Identifier” 746, 776, and “Contribution Source (CSRC) Identifier” 748, 778.

[0102] Figure 8The diagram illustrates an overview of the WebRTC stack. As shown, IP layer 805 carries signaling from data plane 810 and control plane 850. Data plane stack 810 includes functions for User Datagram Protocol (UDP) 812, Interactive Connection Establishment (ICE) 824, Datagram Transport Layer Security (DTLS) 826, SRTP 817, SRTCP 815, media codecs 820, Quality of Service (QoS) 822, and SCTP 828. ICE 824 can use the Session Traversal Utility (STUN) protocol for NAT and NAT Bypass (TURN) using relays to address real-time media content delivery across heterogeneous networks and NAT rules and firewalls. SCTP data plane 728 is primarily dedicated as an application data channel and can be non-time-critical. SRTP-based stack 817 and control elements (i.e., SRTCP 815), encoding (i.e., media codecs), and Quality of Service (QoS) (i.e., quality of service) are dedicated to time-critical transmissions. The control plane 850 stack includes functions for Transmission Control Protocol (TCP) 854, Transport Layer Security (TLS) 856, Hypertext Transfer Protocol (HTTP) 858, WebSocket 866, Session Initiation Protocol (SIP) 862, Session Description Protocol (SDP) 864, Server Send Events (SSE) 868, and Extensible Message and Presence Protocol (XMPP) 870.

[0103] The data plane is typically established on a single application session (i.e., a 5-tuple) that uses SCTP / DTLS to multiplex media (i.e., video, audio, and haptic media codec payloads), user plane quality control and feedback based on RTCP messages, and WebRTC data channels (i.e., application data such as user chat messages, notifications, user input, user actions, and user gestures).

[0104] The fixed header information and the complete header information (including header extensions) of RTP / SRTP are defined as follows in both RFC 3550 - RTP: A Transport Protocol for Real-Time Applications (ietf.org) and RFC 3711 - The Secure Real-time Transport Protocol (SRTP) (ietf.org).

[0105] The fixed header information includes “V” 732, 762, “P” 733, 763, “X” 734, 764, “CC” 736, 766, “M” 738, 768, “PT” 740, 770, “Serial Number” 742, 772, “Timestamp” 744, 774, “Synchronization Source (SSRC) Identifier” 746, 776, and “Contribution Source (CSRC) Identifier” 748, 778.

[0106] “V” 732, 762 are 2 bits that indicate the protocol version used.

[0107] “P” 733, 763 is a 1-bit field that indicates that there are one or more zero-padding octets at the end of the payload. Padding may be necessary for fixed-size cryptographic blocks or for carrying multiple RTP / SRTP packets through lower-level protocols.

[0108] The “X” 734, 764 is 1 bit, indicating that the standard fixed RTP / SRTP header will be followed by an RTP header extension that is usually associated with specific data / profiles. This extension will carry more information about the data (e.g., frames that mark RTP header extensions for video data (as defined in IETF RFC 3711 - The Secure Real-time Transport Protocol (SRTP)) or general RTP header extensions (such as the RTP / SRTP Extension Protocol (defined by w3.org in WebRTC 1.0: "Real-Time Communication Between Browsers").

[0109] "CC" 736 and 766 are 4-bit fields that indicate the number of Contributing Media Sources (CSRCs) following the fixed header.

[0110] “M” 738, 678 is a 1-bit symbol used to mark the boundaries of information frames in a packet stream. Its behavior is precisely specified by the RTP profile (e.g., H.264, H.265, H.266, AV1, etc.).

[0111] “PT” 740 and 770 are 7 bits, which indicate the payload type. In the case of video profiles, the payload type is dynamic and negotiated via SDP (e.g., 96 for H.264, 97 for H.265, 98 for AV1, etc.).

[0112] The "sequence number" 742, 772 is a 16-bit number that indicates a sequence number that increments for each RTP data packet sent on the session.

[0113] The "timestamp" 744, 774 is 32 bits, which indicates a timestamp in units of the tick of a payload-type clock, reflecting the sampling time of the first octet of the RTP data packet (associated with the video stream of a video frame), and the first timestamp of the first RTP packet is randomly selected.

[0114] The “Synchronization Source (SSRC) Identifier” 746, 776 is a 32-bit field that indicates a random identifier of the source of a stream of RTP packets that forms a portion of the same timing and sequence number space, so that the receiver can group packets based on the synchronization source for playback.

[0115] The “Contribution Source (CSRC) Identifier” 748, 778 is a list of up to 16 CSRC items (32 bits each) based on the number of CSRCs mixed by the RTP mixer within the current payload (as shown in CC bits); the list identifies the contribution source of the payload contained in the packet based on the CSRC identifier of the contribution source.

[0116] The complete header information (including header extensions) includes "RTP header extensions" 748 and 778.

[0117] If X bits are marked, then "RTP Header Extension" 748, 778 is a variable-length field; if present, the header extension is appended to the RTP fixed header information after the CSRC list; the RTP header extension is 32-bit aligned and consists of the following fields: • A 16-bit extended identifier, defined by the profile and typically negotiated and determined via the Session Description Protocol (SDP) signaling mechanism; • A 16-bit length field, describing the extension header length in multiples of 32 bits, excluding the first 32 bits corresponding to the 16-bit extension identifier and the 16-bit length field itself; and • The 32-bit aligned header extends the raw data field, formatted according to the format specified by the RTP header extension identifier.

[0118] Figure 9 The diagram illustrates the RTP / SRTP header extension format and syntax 900. The RTP header extension format and syntax are similar to the SRTP header extension format and syntax. Therefore, as... Figure 9As shown, sketches of these header extension formats and syntaxes are typically provided. Furthermore, for both RTP and SRTP, only one RTP extension header can be appended to the fixed header information, as defined in IETF RFC3550 - RTP: A Transport Protocol for Real-Time Applications. However, according to RFC 8285: A General Mechanism for RTP Header Extensions (rfc-editor.org), both the base protocol's RTP and SRTP extensions allow multiple predefined types of RTP header extensions to be appended to the protocol's fixed header information.

[0119] In some embodiments, RTP header extensions generated at the source can be ignored by the destination endpoint, which has no knowledge of interpreting and processing RTP header extensions sent by the source endpoint.

[0120] QUIC is defined in RFC 9000-QUIC: A UDP-Based Multiplexed and Secure Transport (ietf.org) and is a new transport protocol designed to replace TCP. Initially, QUIC was designed to improve the performance of HTTP / 2 over TCP by avoiding head-of-line blocking at the application and transport layers, thus benefiting HTTP / 3 applications. QUIC is a multiplexing and framing protocol implemented in the user space of an operating system running on top of the UDP transport layer. QUIC is designed for connection-based, stream-oriented transport with reliable delivery based on stream-aware acknowledgments. The list of basic QUIC frame types registered with IANA is provided in section 12.4 of RFC 9000 and is reproduced in Table 1 below for convenience. Table 1: QUIC frame types according to RFC 9000 and RFC 9221.

[0121] Furthermore, QUIC features connection-aware and flow-aware flow control, as well as congestion control transmission procedures for rhythmic internet transmissions that establish and utilize available bandwidth on connections. QUIC also relies on TLS 1.3, as described in RFC 9001 – Using TLS to Secure QUIC (ietf.org) – to encrypt all non-essential protocol elements, including most QUIC headers and QUIC frames (including the QUIC frame header), and authenticates key QUIC headers (i.e., header format, fixed bits, spin bits, and the QUIC destination connection ID header field) alongside the encrypted content via QUIC authentication messages (QUIC mac). A perspective view of the encrypted and authenticated content of a QUIC packet is shown below. Figure 10 As shown, the QUIC payload is represented by ACK frames, flow control frames, and stream frames corresponding to HTTP data.

[0122] Figure 10 This illustrates TLS 1.3-based encryption and authentication using a QUIC PDU 1000. The PDU 1000 includes a UDP packet header containing source port 1002, destination port 1004, checksum, and length 1006. The PDU 1000 also includes a UDP payload 1008. The UDP payload 1008 includes a QUIC packet header containing flags 1010, connection ID 1012, and packet number 1014. The UDP payload 1008 also includes a QUIC payload 1016 and a QUIC mac 1018. The QUIC payload 1016 includes an ACK frame 1020, a flow control frame 1022, a stream frame header 1024, and a stream frame payload 1026 that may include HTTP data 1028.

[0123] In addition to the reliable transmission mode based on stream frames, QUIC also provides datagram frame extensions, namely the 0x30-0x31 frame types defined in RFC 9221. QUIC datagrams can be identified and mapped to different logical streams, but this depends on the application layer, not the QUIC protocol. Essentially, a datagram is an unreliable data container with minimal overhead; it only indicates the frame type (0x30, 0x31) and optionally the frame length (i.e., for a 0x31 type datagram) to allow the datagram to be multiplexed with other QUIC frames in the header. Furthermore, datagram frames are subject to flow control, but if the receiver cannot keep up with the transmitter's rate, the receiver can discard the datagram frame because it is inherently unreliable. Nevertheless, datagrams are acknowledged, but in the event of a lost or discarded QUIC packet, their ACK does not need to be retransmitted by the transmitter. Therefore, multiplexing datagrams and stream frames on the same QUIC packet is generally not a good transmitter strategy. However, datagrams are the object of transmitter congestion control, and therefore they can be affected by the transmitter's response to congestion events, which can delay datagram transmission until the congestion controller makes a decision, or until an optional maximum transmission time window, within which datagrams may expire, as configured by applications performing rhythmic transmission.

[0124] Although QUIC was initially developed to benefit from the HTTP application layer protocol, it has evolved over the past five years into a fully functional, general-purpose transport protocol that can serve various applications and associated protocols beyond networking. For example, QUIC has been recognized as an efficient multiplexing mechanism for multimedia applications and proxies. To this end, the IETF has further researched and developed QUIC in its Media on QUIC (MoQ) and Multiplexing on QUIC Encryption (MASQUE) working groups. According to draft-ietf-avtcore-rtp-over-quic-05, QUIC-based HTTP / 3 is considered an alternative to HTTP / 2 for DASH and Adaptive Low-Latency Streaming, and also an end-to-end secure transport mechanism for RTP in RTP on QUIC (RoQ).

[0125] QUIC's multiplexing-aware transport and its datagram frame extensions make it suitable for deployment in proxy scenarios, where QUIC is used to cryptographically multiplex heterogeneous streams end-to-end over a single connection (i.e., corresponding to a single 5-tuple). This allows endpoints to meet service multiplexing and potential prioritization, including QoS flow control, based on the out-of-the-box end-to-end integrity and confidentiality protections provided by QUIC, without any intermediate box intervention.

[0126] QUIC-based proxies rely on the CONNECT HTTP procedure already established in the TCP socket. Recently, the MASQUE IETF proposed an HTTP / 3 extension to CONNECT over QUIC and UDP to allow UDP proxying according to RFC 9298: Proxying UDP in HTTP (rfc-editor.org) and IP proxying according to draft-ietf-masque-connect-ip-13: Proxying IP in HTTP. To this end, HTTP / 3 capsule frames are defined according to RFC 9297: HTTP Datagrams and the Capsule Protocol (rfc-editor.org) to match the datagram concept in QUIC. Defining HTTP / 3 datagram capsule frames allows HTTP / 3 datagrams to be natively encapsulated in QUIC datagrams for high-performance unreliable proxying, as well as reliable proxying via QUIC streams (when QUIC datagrams are unavailable or the proxy implementation does not require them). Combined with the CONNECT HTTP extension, this enables end-to-end encrypted and multiplexed HTTP / 3 CONNECT proxying between any proxy server and client via QUIC and TCP, UDP, and IP-based UDP protocols.

[0127] Figure 11 This document outlines the HTTP / 3 datagram used as the payload of a QUIC datagram. HTTP / 3 datagrams have low overhead and consist of a quarter-stream ID. The concept of a stream ID from a QUIC stream is reused to differentiate and multiplex different types of QUIC datagrams and to open up multiplexing control to applications at QUIC endpoints. Therefore, the quarter-stream ID is a variable-length integer that contains the value of the bidirectional stream initiated by the client associated with the datagram divided by 4. This division by four stems from the fact that HTTP requests are sent on a bidirectional stream initiated by the client, and in this embodiment, the stream ID is divisible by four. In this embodiment, the largest valid QUIC stream ID value is 2^62-1, therefore, according to RFC 9297: HTTP Datagrams and the Capsule Protocol (rfc-editor.org), the largest valid value for the quarter-stream ID field is 2^60-1.

[0128] Figure 11The diagram illustrates the representation of an HTTP / 3 datagram as the payload of a QUIC datagram frame in a UDP proxy configuration, running an HTTP / 3 extended CONNECT proxy via QUIC and UDP. Specifically, Figure 11 The diagram shows a UDP datagram 1100 containing a QUIC packet 1102. The QUIC packet 1102 further contains a QUIC datagram frame 1104. The QUIC datagram frame 1104 further contains an HTTP datagram 1106. The HTTP datagram 1106 further includes a quarterstream ID 1112 and a UDP datagram payload 1114.

[0129] In some embodiments, since QUIC datagrams may not be usable as a transport protocol, RFC 9297: HTTP Datagrams and the Capsule Protocol (rfc-editor.org) defines the capsule protocol that can be used. A capsule protocol is a series of type-length-value tuples that HTTP upgrade tokens can optionally use. Even in the presence of HTTP intermediaries, the capsule protocol allows endpoints to reliably pass request-related information end-to-end over an HTTP request stream. Therefore, in some embodiments, the capsule protocol can be used to exchange HTTP / 3 datagrams (i.e., Figure 11 The payload carried in the datagram is necessary when HTTP runs on a transmission that does not support QUIC datagram frames. In some embodiments, this can be run on top of QUIC stream frames to provide a reliable proxy, as the HTTP / 3 extension performs CONNECT proxying over QUIC streams according to RFC 9297: HTTP Datagrams and the Capsule Protocol (rfc-editor.org).

[0130] Multi-mode support and AF / AS interface support in 5GS. Prior to the completion of Phase 2 specification work on version 18 for XRM in 3GPP TS 23.501 v18.2.2 (June 2023) entitled "System architecture for the 5G System (5GS)", 5GS specified minimum support for multi-mode flows, namely, providing a generic multi-mode service ID for the PCF according to Clause 5.37.2 of 3GPP TS 23.551 to associate QoS policies and rules for multiple flows on a public PDU session. However, there are no architectural features in the CN (e.g., at the UPF) or RAN for dedicated support of multi-mode flows and differentiated service support.

[0131] Furthermore, from the perspective of 5G multimedia, interactive, and immersive architecture, the interface between AS and AF (i.e., the M3 interface in the 5G media streaming TS 26.501 context and the RTC-3 interface in the 5G real-time communication TS 26.506 context) is implementation-dependent and does not belong to the 5GS implementation within the current version 18 timeline, and is outside the scope of 5GS. However, this will change considering the expansion of AS-driven 5GS service support, including dynamic policies, service adaptation, and optimized QoS processing requests for multimedia-related applications.

[0132] Multi-mode streaming support within 5GS also falls into the latter category, thus requiring additional AS-related information regarding 5GS, such as protocol descriptions for multi-mode services and / or applications. Currently, via... Npcf_PolicyAuthorization The service (see 3GPP TS 29.514 v18.3.0 (September 2023) entitled "5G System; Policy Authorization Service; Stage 3") provides minimal specification support on the PCF's N5 interface, or via... Nnef_AFSessionWithQoS The service (refer to 3GPP TS 29.122 v18.3.0 entitled "T8 reference point for Northbound APIs") provides minimal specification support on the N33 interface of NEF to provide a multimode service ID, a protocol description limited to PDU set-tagged flows, and a list of QoS requirements for multiple IP data flows associated with the same multimode service ID.

[0133] Therefore, there is a gap in supporting multi-mode streams served on the same stream, where at least the multi-mode protocol data stream is encrypted by AS and / or not tagged with PDU set information.

[0134] Current capabilities: such as Figure 2 As shown, the current behavior of 5GS in version 18 does not allow service differentiation, i.e., identifying media sent through the same IP stream, where the IP stream corresponds to a 5-tuple containing source and destination IP addresses and port numbers. In fact, in all embodiments, QoS streams enabled by PDU set features require all PDUs of the session (IP stream) mapped to that QoS stream to be mapped to a PDU set and tagged with PDU set information. Therefore, according to application requirements, all PDUs and PDU sets are processed uniformly based on QoS stream PSER, PSDB, and PSIHI QoS rule configurations.

[0135] The problem with the current process: While this behavior is simple, it handles the same heterogeneous streams with different QoS requirements in many multimodal service scenarios (e.g., XR, cloud gaming, or general interactive media applications). For example, in some implementations, audio, video, and metadata of a media session are multiplexed on the same IP stream. Currently, the granularity of QoS streams in 3GPP systems is per IP stream, where an IP stream corresponds to a 5-tuple containing source and destination IP addresses and port numbers. According to Table 5.7.4-1 of 3GPP TS23.501 v18.2.2, this results in such media sessions being routed on 5GS systems using the same QoS stream enabled by PDU sets, and in some examples, latency-critical guaranteed bit rates satisfying 10^-4 PSER and 20ms PSDB, with a default maximum data burst of 63kBytes. While this may be suitable for video media content, it is an over-provisioning of audio and metadata content resources that could be better mapped to specific QoS streams. Furthermore, in some embodiments, each of the different media sources can have its own sampling frequency (e.g., 60fps for video, 20ms for audio, 10ms for haptic / gesture) and jitter associated with sampling and encoding. Additionally, media acquisition devices (e.g., microphones, cameras, haptic gloves, HMD accelerometers / SLAM) can be asynchronous, so the generated packets to be transmitted can overlap aperiodically at the multiplexed stream level, while individual data streams (e.g., video, audio) can exhibit quasi-periodic behavior. To enable the network to utilize these multimodal service characteristics, differentiated service processing of multiplexed services within the 5GS CN is necessary and desirable. In many embodiments, an additional challenge of differentiated service processing is the end-to-end additional security, confidentiality, and integrity protection of modern multiplexing protocols and media transport stacks (e.g., SCTP / DTLS and SRTP, SRTCP in WebRTC, QUIC encryption based on TLS 1.3).

[0136] Figure 12 The illustration presents a general demultiplexing solution and a mapping of multi-mode media content to one or more individual QoS streams for differentiated service transmission in the DL over tunneling on N6. This can include multiplexed media on the same IP stream identified via N6, i.e., in the DL direction. Figure 12System 1200 is illustrated, which includes Application Function (AF) 1210, Network Open Function (NEF) 1212, Policy Control Function (PCF) 1215, Session Management Function (SMF) 1220, Access and Mobility Function (AMF) 1225, Radio Access Network (RAN) 1230, User Equipment (UE) 1235, User Plane Function (UPF) 1240, and Application Server (AS) 1245. AS 1245 may include an Extended Reality Application Server.

[0137] At 1281, AS 1245 provides a protocol description to AF 1210 and requests a specific QoS profile based on the protocol description. The protocol description is a representation of the protocol used to transmit AS application data over the line. The protocol description includes at least a mapping of each individual media content (e.g., video, audio, haptic, application metadata) to a “stream identifier” (or a range of stream identifiers) corresponding to a specific type of media in the IP stream. In one embodiment, the identifier may correspond to an individual stream encapsulating media content data over the line. The specific QoS profile corresponding to the protocol description contains associated QoS requirements for at least one of the following QoS parameters: application-level (i.e., stream public PDB) and stream-level (i.e., for each media content / media type, such as PDU set tagged video @ 60 fps with a PSER of 10^-4, a PSDB of 20 ms, and PDU set integration processing enabled).

[0138] At 1282, AS 1245 establishes a tunnel session via N6 to allow AS to provide information about each multiplexed medium within the IP flow. AS ensures that media of a specific media type (based on the protocol description) corresponds to the mapping from the protocol description to the flow identifier (or flow identifier range) provided in step 1281.

[0139] AF 1210 may optionally verify the AS protocol description and further request it from PCF 5GS via NEF, or directly from AF in the requested trusted domain to PCF for an AS session with an AS request QoS profile.

[0140] At 1284, AF 1210 establishes an AF session to 5GS (via NEF 1212). The AF includes in its request information providing a mapping of identifiers (stream identifiers) (or identifier ranges) to specific media types, where the identifiers are associated with specific media information provided through the N6 tunnel.

[0141] PCF 1215 validates AF requests based on available SLAs and capabilities for creating AS sessions with QoS requirements. During validation, PCF responds to AF requests with appropriate status and / or error codes (e.g., HTTP code 200, indicating success of the request and appropriate AS session configuration by CN and 5GS). PCF also derives one or more QoS rules based on information provided by the AF, each QoS rule corresponding to one or more multiplexed media within an IP flow. Each QoS rule includes a packet detection rule that includes one or more of the following: 5-tuple information of the media flow, a protocol description of the media flow, a 5-tuple message of the tunnel session between the UPF and AS, and a tunnel session flow identifier on N6 (e.g., one or more 5QIs for multi-mode media services) and flow-specific or application-specific QoS requirements. In some cases, PCF may include default QoS rules for packets that do not contain a specific media type. Default QoS rules may also include a flow identifier range where it is known (based on AF information) that such media / services do not require specific QoS processing (e.g., PDU set QoS processing). In some embodiments, associated QoS flows are linked at the CN level via a single multimode service ID, application ID, or 5-tuple descriptor. In some embodiments, the PCF can determine QoS requirements for one or more QoS flows that depend on a PDU set characteristic with QoS parameters PSER, PSDB, and PSIHI; in other embodiments, the PCF can determine QoS requirements for one or more QoS flows based on conventional (i.e., non-PDU set) PER and PDB rules. The remaining PCF processing follows the standard 5GS QoS flow establishment operation, i.e., the SMF configuration process with defined QoS and PCC rules.

[0142] The SMF 1220 establishes QoS flows according to the PCF's QoS rules. In some embodiments, the SMF establishes a set of one or more associated QoS flows according to the PCF QoS rules and provides N4 rules to the UPF, where the N4 rules include information on routing packets to QoS flows based on packet detection rules in the QoS flows. Furthermore, in some arrangements, the SMF enables PDU set processing for one or more associated QoS flows according to QoS rules derived from the protocol description. The SMF also provides the RAN with QoS profiles of one or more associated QoS flows and their individual QoS requirements via the AMF.

[0143] The UPF 1240 applies the N4 rule to demultiplex AS sessions corresponding to multimodal media content. It identifies the target receiver of the media stream by examining information within the tunnel session (e.g., by examining the destination address included in the QUIC control plane information) and further maps the stream to QoS streams according to SMF instructions to satisfy the AS's original request for an AS session with specific QoS and differentiated service processing. In one implementation, the UPF can assign a PDU set media stream (e.g., corresponding to video content tagged with PDU set information by the AS) to a QoS stream with PDU set integration processing, and assign one or more streams (with similar PER and / or PDB requirements) to another QoS stream with traditional processing (i.e., non-PDU set processing). In this implementation, the two QoS streams for the associated QoS stream set serve the same QoS profile for the application with multimodal media content on a single AS session.

[0144] RAN 1230 processes QoS flows mapped to the DRB similarly to traditional processing. Specifically, for QoS flows tagged with PDU sets in one or more associated QoS flows, the RAN identifies packets belonging to the PDU set (based on GTP-U tagging) and processes the packets of the PDU set according to the QoS requirements of the PDU set provided by the SMF. In one implementation, such as Figure 12 As shown, a RAN node can use different radio bearers with higher QoS requirements (based on PDU set PSDB / PSER requirements) to guarantee the delivery of packets marked with PDU set information corresponding to one of the associated QoS flows, while using different radio bearers based on the 5QI of packets marked with non-PDU set information corresponding to another associated QoS flow in a set of one or more associated QoS flows.

[0145] The solution described in this paper assumes that, even in the context of encrypted or partially encrypted services, UPF can distinguish and demultiplexed flows based on identifiers (e.g., flow identifiers, or flow identifier ranges) and a provided mapping to QoS flows. Detailed implementations and examples of this behavior are described below.

[0146] For each QoS stream of each media for the same IP stream, PCF can trigger QoS monitoring to monitor packet latency for each QoS stream. This is necessary if packets from a particular QoS stream are delayed beyond a configurable value (which can lead to a poor user experience). If the packet latency of a QoS stream exceeds a threshold, PCF can adjust the QoS requirements of the QoS stream to ensure that packet latency meets packet latency standards.

[0147] Therefore, it is necessary to identify the multiplexed media on the same IP stream via the user plane protocol between the UE and the PSA UPF, i.e., in the UL direction. The solution proposed in this paper is as follows: Figure 13 As shown. Figure 13 A general demultiplexing solution is shown, along with a mapping of multi-mode media content to one or more individual QoS streams for differentiated services in UL via tunnel transmission between the UE and PSA UPF (QUIC as an example).

[0148] Figure 13 System 1300 is illustrated, which includes Extended Reality Media Application Functions (XRM AF) 1310, Policy and Control Functions (PCF) 1315, Session Management Functions (SMF) 1320, Access and Mobility Functions (AMF) 1325, Radio Access Network (RAN) 1330, User Equipment (UE) 1335, User Plane Functions (UPF) 1340, and Extended Reality Video Application 1345. UE 1335 includes a QUIC proxy client, which is an example of a tunneling client. UPF 1340 includes a QUIC proxy server, which is an example of a tunneling server. UE 1335 runs a local XR video application 1337.

[0149] exist Figure 13 In the diagram, video data is represented by crosshairs; audio data is represented by diagonal lines from the top left to the bottom right; and metadata is represented by dots or spots. The first QoS flow between UPF 1340 and RAN 1330 has PSDB / PSER requirements. The second QoS flow between UPF 1340 and RAN 1330 has traditional QoS requirements, which may include PDB / PER requirements.

[0150] At 1381, AF 1310 provides configuration information to UE 1335, which includes "QUIC MASQUE rules" containing: application identifiers, and rules for mapping the media of the applied IP streams to specific streams via a tunneling protocol between the UE and the PSA UPF (e.g., using protocols defined in the IETFMASQUE group). Rules may include information mapping media corresponding to specific protocols on a separate stream. For example, video streaming media requiring PDU set processing should be sent via a separate stream compared to other media. Rules may also include a range of stream identifiers that should be assigned to the stream corresponding to the protocol description. Rules may also include a default stream identifier for any packets that cannot identify a protocol (default stream). Configuration information may include: protocol descriptions (a list of multiplexed data streams and corresponding protocols); mapping of quarter-stream IDs (to data streams such as payload type, sub-protocol); and / or mapping of quarter-stream IDs (or quarter-stream ID ranges) to data stream QoS requirements.

[0151] At 1382, AF 1310 simultaneously provides 5GS (via NEF and PCF 1315) with information for each medium in the IP flow, including one or more of the following: protocol description, QoS requirements, and flow identifier range. These may include PDU set requirements and can be defined by a flow ID range with corresponding QoS requirements.

[0152] At 1383, PCF 1315 derives one or more QoS rules based on SLA and subscription information. Each QoS rule is based on information provided by the AF corresponding to one or more multiplexed media within a multiplexed media stream in the IP stream. For example, a QoS rule may include QoS requirements related to a 5-tuple PDU set for a protocol session between the UE and the UPF. Each QoS rule includes a packet detection rule having one or more of the following: 5-tuple information of the media stream within the tunnel session, a protocol description of the media stream, 5-tuple information of the tunnel session between the UE and the UPF, and a stream identifier (i.e., one or more 5QIs used for multi-mode media services), and stream-specific or application-specific QoS requirements. For example, associated QoS streams are associated at the CN level via a single service ID, application ID, or 5-tuple descriptor. The PCF may determine the QoS requirements for one or more QoS streams that depend on PDU set characteristics with QoS parameters PSER, PSDB, and PSIHI. The PCF may determine the QoS requirements for one or more QoS streams based on conventional (i.e., non-PDU set) PER and PDB rules. The remaining PCF processing follows the standard 5GSQoS flow establishment operation, which is an SMF configuration process with defined QoS and PCC rules.

[0153] At 1383, SMF 1320 establishes QoS flows based on QoS rules provided by PCF 1315. SMF 1320 can provide QoS rules to the UE, where the QoS rules can include packet detection information about how to route uplink packets to QoS flows based on the protocol description of the media and / or flow identifier. For the downlink, SMF establishes a set of one or more associated QoS flows based on the PCF QoS rules and provides N4 rules to UPF, where N4 rules include information on how to route packets to QoS flows based on 5-tuples and protocol descriptions. UPF 1340 can also receive QUIC rules provided separately or within N4 rules, which indicate how to route packets in the downlink (i.e., by which flow identifier) ​​to the UE based on the protocol description and flow identifier. If UPF cannot identify the protocol, then if the UE has already established a default flow, UPF routes packets through the default flow. For example, SMF 1320 can provide a QoS profile to AMF 1325. A QoS profile can define QoS requirements associated with QoS flow 1 and QoS flow 2, and can be associated QoS flows with the same application identifier or service identifier.

[0154] When UE 1335 registers with the 5GS, it establishes a QUIC session with UPF 1340, which supports QUIC proxying. When the local XR video application 1337 requests a network connection, UE 1335 identifies the media of the local XR video application 1337 according to the "QUIC MASQUE rule" and sends the media to UPF 1340 via a separate stream. UE 1335 encapsulates the media within a QUIC connection and assigns a stream identifier based on the QUIC MASQUE rule. The UE uses uplink QoS rules to send the QUIC stream to the UPF corresponding to the QoS rule via a QoS stream. The UPF decapsulates the QUIC packets and routes the content to the end server based on the destination address included in the QUIC control plane information.

[0155] At 1385, UPF 1340 checks the N4 rule upon receiving a downlink packet. If the N4 rule includes a protocol description and a MASQUE processing rule (or an associated MASQUE processing rule exists), the UPF routes the downlink packet to the flow based on the protocol description and / or flow identifier configuration. Processing at UPF 1340 can be based on a quarter-flow ID in QUIC tunnel ID data flow #1 as a video service, and is transmitted via QoS flow #1 with PDU set QoS requirements.

[0156] The RAN 1330 processes QoS flows mapped to the DRB in a manner similar to traditional processing. Specifically, for QoS flows tagged with PDU sets in one or more associated QoS flows, the RAN identifies packets belonging to the PDU set (based on GTP-U tagging) and processes the packets of the PDU set according to the QoS requirements of the PDU set provided by the SMF. In one implementation, such as Figure 12 As shown, the RAN node can use different radio bearers with higher QoS requirements (according to PDU set PSDB / PSER requirements) to ensure the delivery of packets marked with PDU set information corresponding to one of the associated QoS flows, while using different radio bearers for packets marked with non-PDU set information corresponding to another associated QoS flow in a set of one or more associated QoS flows, according to 5QI.

[0157] The identifiers of multiplexed media on a single IP stream can be combined to include Figure 12 and Figure 13 The two proposed solutions are shown, one in the UL direction and the other in the DL direction.

[0158] QUIC tunneling can be enabled between the AS and the UPF. In this setup, the UPF acts as the QUIC proxy tunnel server, and the AS acts as the QUIC proxy tunnel client.

[0159] QUIC tunneling can be enabled between the UE and the UPF. In this setup, the UPF acts as the QUIC proxy tunnel server, and the UE acts as the QUIC proxy tunnel client.

[0160] The solutions described in this paper are applicable to both AS-to-UPF QUIC tunnels and UE-to-UPF QUIC tunnels. They can rely on the HTTP extension CONNECT and UDP proxy on QUIC. Therefore, in one implementation, the QUIC tunnel can be established to proxy UDP connections according to RFC 9298 based on the “connect-udp” protocol exchange; in another implementation, the QUIC tunnel can be established to proxy TCP connections, for example, according to RFC 2817; and in some other implementations, the QUIC tunnel can be established to proxy IP connections according to the IETF draft specification draft-ietf-masque-connect-ip-13 entitled “Proxying IP in HTTP” based on the “connect-ip” protocol exchange. In some embodiments, tunnel establishment via the CONNECT HTTP method can rely on the traditional CONNECT method of HTTP / 1.1 (see Section 9.3.6 of RFC 9110), optionally enhanced with an upgrade header (see Section 7.8 of RFC 9110), and supports both UDP and IP tunneling. Tunnel establishment can rely on the HTTP / 2 extension CONNECT (see RFC 8441), or it can rely on the HTTP / 3 extension CONNECT (see RFC 9220).

[0161] For example, HTTP extension CONNECT is implemented for HTTP / 2 or HTTP / 3, via QUIC and UDP proxy requests from the AS (i.e., the client) to the 3GPP UPF proxy server, as shown below, and establishes a UDP tunnel to a remote UE endpoint with a target hostname of 100.188.67.134 and a target port of 443 via the connect-udp protocol according to RFC 9298. ``` HEADERS :method = CONNECT :protocol = connect-udp :scheme = https :path = / .well-known / masque / udp / 100.188.67.134 / 443 / :authority = 3gpp-upf-proxy.example.org capsule-protocol = ?1 ```

[0162] Hostnames can be referenced by name instead of IPv4 or IPv6 addresses, and this will require the UPF proxy server to perform DNS resolution. In some embodiments, the AS or the UE in other embodiments may employ a reverse DNS lookup provided by application-level control logic to obtain the IPv4 or IPv6 address of the target host UE or AS. After an optional DNS lookup is performed and the path to the target host is resolved, the UPF proxy server may respond with success in some embodiments or with an error message in others, depending on the requested configuration and available UPF proxy capabilities. The response status is determined by the server based on the client request and the server's capabilities. For example, a client (AS or UE) may request network configuration for a client-server tunnel (e.g., a QUIC tunnel) from the server (PSA UPF) (e.g., via an HTTP extended CONNECT header). The network configuration may include flow control configuration (e.g., enforcing flow-level / datagram-level QUIC flow control), which may be based on a QoS profile or QoS requirements corresponding to the client's multi-mode application data (a multiplexed single data stream that includes multi-mode IP streams such as audio, video, haptic feedback, application metadata, etc.). In some configurations, such client requests may include "QUIC MASQUE rules".

[0163] For example, in one implementation, the UPF proxy server responds with an HTTP success status of 200 to indicate the AS proxy client's request, as shown below. ``` HEADERS :status = 200 capsule-protocol = ?1 ```

[0164] In situations where tunneling via QUIC datagram frames is not possible (e.g., HTTP / 1 / 1, HTTP / 2, or HTTP / 3, which do not support QUIC datagram frames), the capsule protocol of RFC 9297 is used to transmit tunneled UDP payloads within HTTP datagram capsules. Alternatively, the capsule protocol of RFC 9297 can be used to further transmit other types of capsules, such as IP tunnel capsule types ADDRESS_REQUEST, ADDRESS_ASSIGN, and ROUTE_ADVERTISEMENT. For this purpose, the capsule protocol provides a lightweight capsule serialization stream format, where each capsule has a type identifier, length, and value (i.e., payload), the semantics of which depend on the capsule type. For example, according to RFC 9297, the following lists the HTTP / 3 datagram capsule format (i.e., the semantics of the capsule value field for HTTP / 3 datagram types), and... Figure 11 It is represented graphically. ``` HTTP / 3 datagram { Quarter stream ID(i) HTTP datagram payload (...) } ```

[0165] When implementing an HTTP / 3 proxy over QUIC datagrams, HTTP / 3 datagram capsule padding is used as a result of the QUIC datagram frame type. Furthermore, because QUIC packet syntax and semantics are reused, explicit encapsulation of the capsule type and length is no longer necessary. Figure 11 As shown.

[0166] For the reasons mentioned above, it is possible to multiplex heterogeneous data streams over the same tunnel by using capsule protocols or QUIC datagram frames for tunnel transport proxy services, thereby identifying individual data streams by protocol-negotiated identifiers (e.g., quarter-stream IDs based on QUIC datagram payloads, quarter-stream IDs based on QUIC streams, or quarter-stream IDs based on HTTP datagram capsules according to RFC 9297).

[0167] As described above, QUIC tunneling can be used based on the HTTP extension CONNECT to proxy UDP traffic between the AS and the UE, with the QUIC tunnel running between the AS proxy client and the UPF proxy server. Therefore, the QUIC protocol can be used to multiplex multi-mode data streams (i.e., 5-tuples, or IP streams) of the AS over a single application session. Furthermore, the UPF proxy terminating the QUIC tunnel can identify each data stream based on a mapping from each data stream to a quarter-stream ID. This mapping can be provided by the AS to the AF as a protocol description along with the QoS requirements of one or more data streams multiplexed by the AS. The AF then requests an application session with differentiated QoS service management from the 5GS via control plane signaling on behalf of the AS. Communication between the AF and the 5GS occurs on the control plane; in some arrangements, this occurs between the AF and the NEF, while in other arrangements, when the AF is deployed in the trusted domain of the MNO, it occurs between the AF and the PCF.

[0168] In some implementations, the QoS requirements for multiplexed AS sessions transmitted via QUIC proxy tunnels are specific to each data stream, and the QoS PER and PDB requirements for individual data streams are listed. For example, one or more data streams may each be marked with an AS-enabled PDU set, which is provided, for example, through an RTP header extension of the PDU set according to 3GPP TS 26.522 v0.1.1. Therefore, PDU set integrated QoS processing is enabled, and the QoS requirements are represented relative to the PSER, PSDB, and PSIHI requirements of the individual data streams marked with the enabled PDU set. In some arrangements, in addition to the individual data stream-specific QoS requirements, the application stream of the multiplexed multimode data streams may also include a set of QoS requirements for the data streams, specifically related to the maximum tolerable PER and PDB across all multiplexed data streams. The application can use the maximum tolerable PER and PDB as a processing window for resynchronizing the multimode streams at the receiver to maintain the desired QoE. The specific details of application-level synchronization processing are application domain-specific (e.g., XR streaming / session, cloud gaming) and are beyond the scope of this article.

[0169] The PCF processes QoS requests based on available PCC and OAM configurations and determines a set of QoS rules associated with the QoS profile requested by the AF. QoS rules can be sent to the SMF, which determines the corresponding QoS flow and notifies the UPF of the QoS rules and available QoS flows, including a mapping from tunneled data flows to specific QoS flows. This mapping can be based on available QoS rules derived from the protocol description and data flow identifiers, such as quarter-stream IDs of QUIC datagrams.

[0170] UPF can terminate the QUIC tunnel and, based on the QoS rules provided via the N4 interface SM container and their mapping to the data flow identifier, further proxies the data flow to the UE remote endpoint.

[0171] The AS QUIC tunnel client connects to the UPF QUIC tunnel proxy via the HTTP / 3 extension CONNECT over QUIC and UDP. AS is a multimedia XR application that multiplexes different data streams using QUIC. Figure 14In the example shown, the QUIC tunnel carries at least three distinct data streams corresponding to three RTP / RTCP streams. One RTP stream, tagged with PDU set information, carries the video payload type (e.g., H.264, H.265, H.266, etc.), one RTP stream carries audio (e.g., OPUS, HE-AAC, 3GPP EVS / IVAS, etc.), and the RTCP stream carries RTCP control messages associated with the other two multiplexed RTP streams. These streams are identified by quarter-stream IDs; for example, QSI=0 for video, QSI=1 for audio, and QSI=2 for RTCP control messages. Therefore, the UPF maps RTP video streams to QoS-enabled streams with PDU sets that meet specific video requirements (PSDB and PSER), such as PER=10^-4, PDB=20ms, and a maximum data burst of 120kBytes. RTP audio and RTCP streams are mapped together to QoS streams with common PER and PDB rules covering the requirements of both audio and RTCP control messages, such as PER=10^-3, PDB=10ms, and a maximum small data burst of up to 500 bytes. The UPF then proxies the RTP and RTCP data streams to the remote UE at the UDP layer, performing service differentiation based on the demultiplexing of the data streams and the corresponding QoS rules matching the requirements of each data stream.

[0172] Figure 14 The diagram illustrates a UDP proxy for multi-mode QUIC tunneling in an XR video application with three data streams: an RTP (or SRTP) video stream tagged with PDU set information, an RTP audio stream, and an RTCP (or SRTCP) control message.

[0173] Figure 14 System 1400 is illustrated, which includes Extended Reality Application Functions (XR AF) 1410, Policy and Control Functions (PCF) 1415, Session Management Functions (SMF) 1420, Access and Mobility Functions (AMF) 1425, Radio Access Network (RAN) 1430, User Equipment (UE) 1435, User Plane Functions (UPF) 1440, and Extended Reality Video Application 1445. XR Video Application 1445 includes a QUIC client, which is an example of a tunneling client. UPF 1440 includes a QUIC server, which is an example of a tunneling server.

[0174] exist Figure 14In the diagram, video data is represented by crosshairs; audio data is represented by diagonal lines from the top left to the bottom right; and metadata is represented by dots or spots. The first QoS flow between UPF 1440 and RAN 1430 has PSDB / PSER requirements. The second QoS flow between UPF 1440 and RAN 1430 has traditional QoS requirements, which may include PDB / PER requirements.

[0175] XR video application 1445 sends a protocol description to XR AF 1410, which includes a list of multiplexed data streams and their corresponding protocols. This may include a mapping from quarter-stream IDs to data streams (e.g., payload type, sub-protocol), and / or a mapping from quarter-stream IDs or quarter-stream ID ranges to data service QoS requirements. Similarly, SMF 1420 can send N4 QoS configuration rules to AMF 1425. The QoS configuration rules can define QoS mappings associated with QoS stream 1 and QoS stream 2 based on the QoS profile requested by the XR video application. QoS stream 1 and QoS stream 2 can be associated QoS streams with the same application identifier or service identifier. SMF 1420 sends stream ID to QoS stream indicator mapping information to UPF 1440.

[0176] Similar to the examples above in the DL direction, in the UL direction, QUIC tunneling can be used to proxy UDP traffic between UE 1435 and AS (in this case, XR video application 1445), where the QUIC tunnel is between the UE proxy client and the UPF proxy server. Therefore, the QUIC protocol can be used to multiplex the UE's multi-mode data streams (i.e., 5-tuples or IP streams) on a single application session. In these examples, the UE is configured by AF 1410 with a "QUIC MASQUE rule" that contains an application identifier and rules that map the media of the application's IP streams to specific streams via a tunneling protocol between UE 1435 and the PSA UPF (e.g., using protocols defined in the IETF MASQUE group). The configuration rules can include information on mapping media corresponding to a specific protocol to a separate stream (e.g., media with PDU set processing should be sent via a separate stream compared to other media), the range of stream identifiers to be assigned to the stream corresponding to the application's protocol description, and a default stream identifier (i.e., default stream) for any packets that cannot identify the protocol.

[0177] Furthermore, UEs configured with "MASQUE rules" for applications can establish QUIC tunnel sessions with UPFs that support QUIC proxies when registering to the 5GS. When an application requests a network connection, the UE identifies the application's media according to the "QUIC MASQUE rule" and sends the media to the UPF via a separate flow. The UE encapsulates the media within a QUIC connection and assigns a flow identifier (or quarter-flow ID) based on the QUIC MASQUE rule. For the SMF configuration, the UE uses uplink QoS rules to send each QUIC flow to the UPF corresponding to the QoS rule associated with each flow via a specific QoS flow. The UPF decapsulates QUIC packets based on the destination address included in the QUIC control plane information, such as an HTTP-extended CONNECT QUIC established via a UDP proxy, and routes the content to the end AS or peer UE.

[0178] The UE can request application-specific "MASQUE rule" configuration from the AF (e.g., via a RESTful API over HTTP / S). The AF processes the request and validates the UE request based on application logic, SLA, and / or ASP policies. Upon successful validation (e.g., via HTTP 2xx status), the UE applies the requested "MASQUE rule".

[0179] like Figure 14 The tunneled data stream shown can use SRTP instead of RTP, SRTCP instead of RTCP to implement WebRTC, and provides an additional data channel on DTLS based on SCTP DTLS as part of a single multiplexed application session. In this arrangement, although the WebRTC stack is used, individual streams can still be mapped to quarterstream IDs or capsule protocol context IDs.

[0180] In one example, the following mapping can be applied: • The SRTP video stream is mapped to a quarter stream ID=0. According to the QoS rules, this SRTP video stream will be further assigned to QoS stream #1 by UPF. • The SRTP audio stream is mapped to a quarter stream ID=1, and according to the QoS rules, this SRTP audio stream will be further assigned to QoS stream #2 by UPF; • The SRTCP control message is mapped to quarter-flow ID=2, and according to the QoS rules, this SRTCP control message will be further assigned by UPF to QoS flow #2; and • The SCTP / DTLS WebRTC data channel is mapped to quarter stream ID=3. According to the QoS rules, this SCTP / DTLS WebRTC data channel will be further allocated to QoS stream #2 by UPF.

[0181] In other arrangements, WebRTC application sessions can be transmitted over the line without additional encapsulation, instead of tunneling through QUIC. In this arrangement, the UPF performs deep packet inspection based on the protocol description representation and available associated QoS rules. To this end, in some implementations, the UPF may apply a combination of at least one underlying WebRTC protocol, or referred to as a “sub-protocol” (e.g., SRTP for media, SRTCP for media session control, SCTP / DTLS for data channels), and the type of the transmitted media payload to identify and demultiplex WebRTC data streams, and subsequently map them to associated QoS streams with different QoS requirements. In some arrangements, these associated QoS streams will share at least one of the same service ID, application ID, or 5-tuple descriptor across the 5GS QoS stream session management process.

[0182] In one example, considering that a WebRTC session includes: • Two SRTP video streams, one corresponding to an HD H.264 media source with profile level id=64001f and RTP payload type 96, and the other corresponding to a 720p H.264 media source with profile level id=42001f and RTP payload type 97. • SRTP audio stream with payload type 113, • One or more SRTCP streams, and •SCTP / DTLS data channel.

[0183] The payload type of an RTP / SRTP stream can be disclosed to the UPF by the AS via control plane signaling. For example, the AS sends a protocol description to the AF, the AF requests an AS session with QoS requirements, and shares the protocol description with the PCF / NEF to derive QoS rules, which include the associated RTP payload type and sub-protocol type. In the above embodiment, the UPF can first perform deep packet inspection to detect the type of sub-protocol encapsulation (e.g., SRTP), and then use payload type information (e.g., 96 for the first source of HDH.264, 97 for the second source of 720p H.264, and 113 for audio) to identify and potentially separate up to three streams on separate QoS streams according to the derived QoS rules. Similarly, through deep packet inspection, the UPF can identify other WebRTC sub-protocols, namely SRTCP and DTLS, to separate and differentiate SRTCP and WebRTC data channels at the QoS stream level based on the application's QoS requirements and the QoS rules derived by the PCF.

[0184] For other multiplexed data streams on a single application session, similar processing is possible, regardless of whether the payload is encrypted or whether the payload and some header elements are encrypted, such as: • RTP and RTCP multiplexed streams (e.g., based on AVP or AVPF RTP profiles) • SRTP and SRTCP multiplexed streams (e.g., based on the SAVP or SAVPF RTP profile). • SRTP and SRTCP multiplexed streams, which have additional encrypted RTP header extensions defined by CRYPTEX (i.e., RFC 9335) or RFC 6904.

[0185] As another example, it should be noted that IP flows can be encapsulated within GTP-U. In this arrangement, the AS establishes a GTP-U tunnel with the UPF via N6. The AS includes an identifier corresponding to the media information contained in the packet within the GTP-U header on a per-packet basis. For example... Figure 12 As shown, if the packet corresponds to a video stream, the AS includes ID#0 in the GTP-U header, while if the packet corresponds to an audio stream, the GTP-U header is marked with ID#1.

[0186] Based on the N4 rule received from the SMF, the UPF routes each received packet to the QoS flow according to the 5-tuple and flow identifier information received from the GTP-U packet via N6.

[0187] In another example, in order to enable 5GS and UPF identification and demultiplexing of different data streams transmitted over a common application session for differentiated services and QoS management, the AS or application service provider configuring network functions may need to expose components of the underlying transport protocol for multi-mode application data.

[0188] In some configurations, the minimum necessary information for enabling AF requests to establish AF sessions with QoS support for differentiating multi-mode protocol flow traffic on a single AS session can be based in 5GS at least on: • The first part of the information corresponding to the public multimode service identifier, or in other embodiments, the public application / session identifier corresponding to the source IP address, destination IP address, source network port, destination network port and protocol flow identifier (e.g., the "WebRTC" string identifier), or the multimode protocol (e.g., WebRTC) 5-tuple descriptor. • The second part of the information corresponds to the protocol description, which includes a list of indexes of mappings corresponding to the single-mode data streams of the multi-mode protocol stream, and • The third part of the information is a list of associated indexes corresponding to one or more QoS requirements for a single-mode data stream associated with a multi-mode protocol stream. The third part of the information may include a stream identifier (or a range of stream identifiers) corresponding to each medium multiplexed on the same IP stream.

[0189] In some embodiments, the protocol description includes an index list of mappings between single-mode data streams and identifiable protocol elements, wherein the identifiable protocol elements may be, for example: • Stream ID, or a quarter-stream ID corresponding to the set of QUIC stream frames and QUIC datagram frames in a QUIC-based protocol (e.g., in a connect-udp tunneling protocol between an AS and a UPF), or ••••(S) RTP payload type, such as AVC / HEVC / audio codec profile, and sub-protocol PDU, such as (S) RTCP encapsulated control messages or DTLS encapsulated and encrypted SCTP messages, as in the case of the WebRTC protocol stack.

[0190] AS or ASP can communicate via the N33 interface to Nnef_AFSessionWithQoS The request establishes a multi-mode session with service differentiation and QoS optimization. In some embodiments, this is based on AS / ASP providing the above information as part of an HTTP request, where JSON... AsSessionWithQoSSubscription Data types include public multimodal service identifiers, and alternatively, AsSessionMediaComponent A list (or hash map) of indices for JSON objects. Each mapping... AsSessionMediaComponent JSON objects also include integer indices (e.g., medCompN (or hash key) and a protocol description that includes at least one of the following: MediaType (e.g., a media identifier encoded as video, audio, haptic, application, text, control, or other strings). MediaProtocol (e.g., (S)RTP, (S)RTPC, RTCP, DTLS, connect-udp / QUIC, etc.) PayloadType (e.g., AVC / 96, HEVC / 97, OPUS / 98, AV1 / 100, etc.), and one or more arrays of stream IDs (e.g., QUIC stream IDs, quarter stream IDs, etc.). Each AsSessionMediaComponent It may also include QoS requirements associated with the corresponding indexed data streaming media component. In some implementations, QoS requirements may be formed from at least one of the following: PER, PDB, 5G QoS stream identifier, and alternatively, a QoS identifier. Alternatively, QoS requirements may also be based on PDU set characteristics and include PSER, PSDB, and PSIHI requirements.

[0191] AF deployed in the trusted domain directly communicates with PCT via the N5 interface. Npcf_PolicyAuthorization The service request establishes the same setup for multi-mode sessions with service differentiation and QoS optimization. In this arrangement, the policy authorization request will include... MediaComponent A list (or hash map) of indexes for JSON objects, which are collectively referenced internally by a common multimode service identifier within 5GS. Furthermore, in the embodiment, each MediaComponent JSON objects include integer indices, i.e. medCompN (or hash key) and a protocol description that includes at least one of the following: MediaType (e.g., a media identifier encoded as video, audio, haptic, application, text, control, or other strings). MediaProtocol (e.g., (S)RTP, (S)RTPC, RTCP, DTLS, connect-udp / QUIC, etc.) PayloadType (e.g., AVC / 96, HEVC / 97, OPUS / 98, AV1 / 100, etc.), and one or more arrays of stream IDs (e.g., QUIC stream IDs, quarter stream IDs, etc.). In other arrangements, each MediaComponent It may also include QoS requirements associated with the data streaming component of the corresponding index. In some implementations, QoS requirements may be formed from at least one of the following: PER, PDB, 5G QoS stream identifier, and alternative QoS identifier. In other implementations, QoS requirements may also be based on PDU set characteristics and include PSER, PSDB, and PSIHI requirements.

[0192] The JSON object, node, or array referenced above (i.e., AsSessionWithQoSSubscription , MediaComponent / AsSessionMediaComponent MediaType, MediaProtocol, PayloadType, StreamID, etc. can be replaced with different alternative encodings (such as XML).

[0193] In another example, UE configuration can be provided to handle traffic on the MASQUE connection between the UE and the UPF. Configuration rules (or QUIC MASQUE rules) can include one or more of the following information: • The application ID or business category of the business type initiated by the application; • Masque processing indicators instruct the UE to route packets to the PSA UPF via the QUIC connection; • Protocol descriptions corresponding to media types (e.g., H.264, audio, metadata); and / or • Stream identifier range, which is used to route the media for QUIC connections.

[0194] The UL QoS rules provided by the PCF to the UE (via the SMF) may include one or more of the following information:

[0195] Packet detection rules that associate uplink traffic containing QUIC connections with QoS flows. Packet detection rules may include flow identifiers (or ranges of flow identifiers).

[0196] Therefore, a server for multi-mode network service differentiation of application data is provided, the server comprising: at least one memory; and at least one processor coupled to at least one memory and configured such that the server: receives a multi-mode protocol stream from a client, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of application data; receives a protocol description defining multiple data streams in the multiplexing of application data; receives a request for an application session with service differentiation, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream; demultiplexes one or more data streams at least based on the protocol description and the corresponding QoS profile of the multi-mode protocol stream; and maps each of the one or more data streams corresponding to the multi-mode protocol stream to one or more QoS streams for differentiated service processing, at least based on the corresponding QoS profile of the multi-mode protocol stream.

[0197] Such a server allows demultiplexing of multiplexed data streams for application sessions corresponding to multi-mode services and / or applications for communication over 5GS, thereby allowing differentiation and potential optimization of QoS processing for multiple data streams of application data.

[0198] The protocol description may additionally define corresponding QoS profiles for multiple data streams in the multiplexing of application data. The QoS profiles for multiple data streams may include a set of QoS requirements. The QoS profiles for multiple data streams may optionally exist in the protocol description as an enumeration of media stream types. For example, media stream types may be categorized as "video," "audio," or "haptic." Media stream types may be used as service identifiers and / or coarse QoS attributes.

[0199] Application session requests include QoS profiles for multimode protocol streams. These QoS profiles are supplemented by a set of QoS configuration rules. For example, the QoS configuration rule set may include configuration rules provided by the SMF. These rules can be provided by the SMF via the N4 interface. The configuration rules can instruct the server how to map each individual data stream to one or more QoS streams established for the session. The QoS profiles for multimode protocol streams are more specific to the mapping to QoS streams and can therefore be viewed as an extension of, or at least an extension of, the QoS profiles for multiple data streams in the multiplexing of application data.

[0200] At least one of the multiple data streams of application data can be encrypted. The multimode protocol stream can be at least partially encrypted. A portion of the multimode protocol stream can be encrypted. The encryptable portion of the multimode protocol stream may include at least one of the multiple data streams of application data.

[0201] The multi-mode protocol stream received from the client may include at least one of the following: the QUIC tunneling protocol; and the WebRTC protocol. The multi-mode protocol stream received from the client may also include a combination of the following: at least one Secure Real-Time Protocol (SRTP) media stream, at least one of the following: a Real-Time Protocol (RTP) media stream, a Real-Time Control Protocol (RTCP) stream, and a Secure Real-Time Control Protocol (SRTCP) stream. The multi-mode protocol stream received from the client may also include a combination of the following: at least one SRTP media stream with additional encrypted RTP header extensions, at least one of the following: a Real-Time Protocol (RTP) media stream, an RTCP stream, and an SRTCP stream.

[0202] The QUIC tunneling protocol can include the HTTP extension CONNECT over QUIC and UDP that proxies one of the following: UDP connection; TCP connection; and IP connection to a remote endpoint.

[0203] The server may include User Plane Functions (UPF). The client may include an Application Server (AS).

[0204] The mapping of each data stream in one or more data streams corresponding to a multi-mode protocol stream to one or more QoS streams for differentiated service processing can also be based on configuration rules provided by the Session Management Function (SMF).

[0205] Configuration rules can be provided by SMF through the N4 interface. Configuration rules can be N4 rules.

[0206] Demultiplexing of one or more data streams can also be based on network QoS policies; and the mapping of each data stream in one or more data streams corresponding to a multi-mode protocol stream to one or more QoS streams for differentiated service processing can also be based on network QoS policies.

[0207] Network QoS policies can be based on at least one of the following: policy control functions (PCF) within the network; service level agreements (SLAs); and mobile network operator (MNO) operation, management and maintenance (OAM) network configurations.

[0208] Mapping each data stream in one or more data streams to one or more QoS streams can include mapping each data stream in one or more data streams to a QoS stream.

[0209] One or more QoS flows may be associated with an application session used for application data. Network service differentiation may be based on at least one of the following: a multi-mode application identifier; a multi-mode session identifier; a multi-mode service identifier; and a multi-mode protocol 5-tuple descriptor corresponding to the source IP address, destination IP address, source network port, destination network port, and protocol flow identifier.

[0210] Multimode protocols can include WebRTC.

[0211] A processor for multi-mode network service differentiation of application data is also provided. The processor includes: at least one controller coupled to at least one memory and configured such that the processor: receives a multi-mode protocol stream from a client, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of application data; receives a protocol description defining multiple data streams in the multiplexing of the application data; receives a request for an application session with service differentiation, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream; demultiplexes one or more data streams at least based on the protocol description and the corresponding QoS profile of the multi-mode protocol stream; and maps each of the one or more data streams corresponding to the multi-mode protocol stream to one or more QoS streams for differentiated service processing, at least based on the corresponding QoS profile of the multi-mode protocol stream.

[0212] A method for multi-mode network service differentiation of application data is also provided. This method is executed by a server and includes: receiving a multi-mode protocol stream from a client, wherein the multi-mode protocol stream includes multiplexing of multiple data streams of application data; receiving a protocol description defining multiple data streams in the multiplexing of application data; receiving a request for an application session with service differentiation, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream; demultiplexing one or more data streams based at least on the protocol description and the corresponding QoS profile of the multi-mode protocol stream; and mapping each of the one or more data streams corresponding to the multi-mode protocol stream to one or more QoS streams for differentiated service processing, based at least on the corresponding QoS profile of the multi-mode protocol stream.

[0213] This multi-mode network service differentiation of application data allows for the demultiplexing of multiplexed data streams of application sessions corresponding to multi-mode services and / or applications for communication over 5GS, and thus allows for differentiation and potential optimization of QoS processing of multiple data streams of application data.

[0214] The protocol description can additionally define the corresponding QoS profiles for multiple data streams in the multiplexing of application data. The QoS profiles for multiple data streams can include a set of QoS requirements. The QoS profiles for multiple data streams can optionally exist in the protocol description as an enumeration of media stream types. For example, media stream types can be categorized as "video," "audio," or "haptic." Media stream types can be used as service identifiers and / or coarse QoS attributes.

[0215] Application session requests include QoS profiles for multimode protocol streams. These QoS profiles are supplemented by a set of QoS configuration rules. For example, the QoS configuration rule set may include configuration rules provided by the SMF. These rules can be provided by the SMF via the N4 interface. The configuration rules can instruct the server how to map each individual data stream to one or more QoS streams established for the session. The QoS profiles for multimode protocol streams are more specific to the mapping to QoS streams and can therefore be viewed as an extension of, or at least an extension of, the QoS profiles for multiple data streams in the multiplexing of application data.

[0216] At least one of the multiple data streams of application data can be encrypted. The multimode protocol stream can be at least partially encrypted. A portion of the multimode protocol stream can be encrypted. The encryptable portion of the multimode protocol stream may include at least one of the multiple data streams of application data.

[0217] The multi-mode protocol stream received from the client may include at least one of the following: the QUIC tunneling protocol; and the WebRTC protocol. The multi-mode protocol stream received from the client may also include a combination of the following: at least one Secure Real-Time Protocol (SRTP) media stream, at least one of the following: a Real-Time Protocol (RTP) media stream, a Real-Time Control Protocol (RTCP) stream, and a Secure Real-Time Control Protocol (SRTCP) stream. The multi-mode protocol stream received from the client may also include a combination of the following: at least one SRTP media stream with additionally encrypted RTP header extensions, at least one of the following: a Real-Time Protocol (RTP) media stream, an RTCP stream, and an SRTCP stream.

[0218] The QUIC tunneling protocol may include the HTTP extension CONNECT over QUIC and UDP that proxies one of the following: UDP connection; TCP connection; and IP connection to a remote endpoint. The server may include User Plane Functions (UPF). The client may include an Application Server (AS).

[0219] The mapping of each data stream in one or more data streams corresponding to a multi-mode protocol stream to one or more QoS streams for differentiated service processing can also be based on configuration rules provided by the Session Management Function (SMF). Configuration rules can be provided by the SMF through the N4 interface. Configuration rules can be N4 rules.

[0220] Demultiplexing of one or more data streams can also be based on network QoS policies; and the mapping of each data stream in one or more data streams corresponding to a multi-mode protocol stream to one or more QoS streams for differentiated service processing can also be based on network QoS policies.

[0221] Network QoS policies can be based on at least one of the following: policy control functions (PCF) within the network; service level agreements (SLAs); and mobile network operator (MNO) operation, management, and maintenance (OAM) network configurations. Mapping each data flow in one or more data flows to one or more QoS flows can include mapping each data flow in one or more data flows to a single QoS flow.

[0222] One or more QoS flows can be associated with an application session, which is used for application data. Network service differentiation can be based on at least one of the following: a multi-mode application identifier; a multi-mode session identifier; a multi-mode service identifier; and a multi-mode protocol 5-tuple descriptor corresponding to the source IP address, destination IP address, source network port, destination network port, and protocol flow identifier. The multi-mode protocol may include WebRTC.

[0223] A client for multi-mode network service differentiation of application data is also provided, the client comprising: at least one memory; and at least one processor coupled to at least one memory and configured such that the client: sends a multi-mode protocol stream to a server, wherein the multi-mode protocol stream comprises: multiplexing of multiple data streams of application data; sends a protocol description defining the multiple data streams in the multiplexing of application data; and sends a request for an application session with service differentiation, the application session comprising at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream.

[0224] Such a client allows demultiplexing of multiplexed data streams for application sessions corresponding to multimodal services and / or applications for communication over 5GS, thereby allowing differentiation and potential optimization of QoS processing for multiple data streams of application data.

[0225] As an example, the server may include a User Plane Function (UPF). The client may include a client device. The client may include an Application Server (AS) or a User Equipment (UE). The AS / UE cannot interact directly with the UPF via control plane media. The AS therefore communicates with the UPF for control purposes or to set specific user plane configurations according to the following control plane signaling path: AS->AF->NEF / PCF->SMF->UPF. Alternatively, the UE communicates with the UPF for control purposes or to set specific user plane configurations according to the following control plane signaling path: UE<->AF->NEF / PCF->SMF->UPF.

[0226] Therefore, a request for a service-differentiated application session can be sent to a second server (e.g., an application function (AF)). In other words, a request for a service-differentiated application session can be sent to the second server via a wireless communication network. A request for a service-differentiated application session can be sent to the second server via at least one node of the wireless communication network.

[0227] The interface between AS->AF or UE<->AF is usually an implementation detail, but in the case of multimedia applications (such as XR and streaming described in this article), at least one media service enabler can be used, which will define its own service interface in 5G / 6G.

[0228] At least one of the multiple data streams of application data can be encrypted. The multimode protocol stream can be at least partially encrypted. A portion of the multimode protocol stream can be encrypted. The encryptable portion of the multimode protocol stream may include at least one of the multiple data streams of application data.

[0229] The multi-mode protocol stream sent to the server may include at least one of the following: the QUIC tunneling protocol; and the WebRTC protocol. The multi-mode protocol stream sent to the server may include a combination of the following: at least one Secure Real-Time Protocol (SRTP) media stream, at least one of the following: a Real-Time Protocol (RTP) media stream, a Real-Time Control Protocol (RTCP) stream, and a Secure Real-Time Control Protocol (SRTCP) stream. The multi-mode protocol stream sent to the server may include a combination of the following: at least one SRTP media stream with additionally encrypted RTP header extensions, at least one of the following: a Real-Time Protocol (RTP) media stream, an RTCP stream, and an SRTCP stream.

[0230] The QUIC tunneling protocol can include the HTTP extension CONNECT over QUIC and UDP that proxies one of the following: UDP connection; TCP connection; and IP connection to a remote endpoint.

[0231] The server may include a User Plane Function (UPF). The client may include an Application Server (AS). The representation of the protocol description and the corresponding QoS profile for the multi-mode protocol stream may include QoS configuration rules provided by the Session Management Function (SMF).

[0232] One or more QoS flows can be associated with an application session. The application session can be used for application data. Network service differentiation can be based on at least one of the following: a multi-mode application identifier; a multi-mode session identifier; a multi-mode service identifier; and a multi-mode protocol 5-tuple descriptor corresponding to the source IP address, destination IP address, source network port, destination network port, and protocol flow identifier. The multi-mode protocol can include WebRTC.

[0233] A processor for multi-mode network service differentiation of application data is also provided, the processor comprising: at least one controller coupled to at least one memory and configured to cause the processor to: send a multi-mode protocol stream to a server, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of application data; send a protocol description defining the multiple data streams in the multiplexing of application data; and send a request for an application session with service differentiation, the application session including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream.

[0234] A method for multi-mode network service differentiation of application data is also provided. The method is executed by a client and includes: sending a multi-mode protocol stream to a server, wherein the multi-mode protocol stream includes multiplexing of multiple data streams of application data; sending a protocol description that defines multiple data streams in the multiplexing of application data; and sending a request for an application session with service differentiation, the application session including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream.

[0235] This multi-mode network service differentiation of application data allows for the demultiplexing of multiplexed data streams of application sessions corresponding to multi-mode services and / or applications for communication over 5GS, and thus allows for differentiation and potential optimization of QoS processing of multiple data streams of application data.

[0236] As an example, the server may include a User Plane Function (UPF). The client may include a client device. The client may include an Application Server (AS) or a User Equipment (UE). The AS / UE cannot interact directly with the UPF via control plane media. The AS therefore communicates with the UPF for control purposes or to set specific user plane configurations according to the following control plane signaling path: AS->AF->NEF / PCF->SMF->UPF. Alternatively, the UE communicates with the UPF for control purposes or to set specific user plane configurations according to the following control plane signaling path: UE<->AF->NEF / PCF->SMF->UPF.

[0237] Therefore, a request for a service-differentiated application session can be sent to a second server (e.g., an application function (AF)). In other words, a request for a service-differentiated application session can be sent to the second server via a wireless communication network. A request for a service-differentiated application session can be sent to the second server via at least one node of the wireless communication network.

[0238] The interface between AS->AF or UE<->AF is usually an implementation detail, but in the case of multimedia applications (such as XR and streaming described in this article), at least one media service enabler can be used, which will define its own service interface in 5G / 6G.

[0239] At least one of the multiple data streams of application data can be encrypted. The multimode protocol stream can be at least partially encrypted. A portion of the multimode protocol stream can be encrypted. The encryptable portion of the multimode protocol stream may include at least one of the multiple data streams of application data.

[0240] The multi-mode protocol stream sent to the server may include at least one of the following: the QUIC tunneling protocol; and the WebRTC protocol. The multi-mode protocol stream sent to the server may include a combination of the following: at least one Secure Real-Time Protocol (SRTP) media stream, at least one of the following: a Real-Time Protocol (RTP) media stream, a Real-Time Control Protocol (RTCP) stream, and a Secure Real-Time Control Protocol (SRTCP) stream. The multi-mode protocol stream sent to the server may include a combination of the following: at least one SRTP media stream with additionally encrypted RTP header extensions, at least one of the following: a Real-Time Protocol (RTP) media stream, an RTCP stream, and an SRTCP stream.

[0241] The QUIC tunneling protocol may include the HTTP extension CONNECT over QUIC and UDP that proxies one of the following: UDP connection; TCP connection; and IP connection to a remote endpoint. The server may include User Plane Functions (UPF). The client may include an Application Server (AS).

[0242] The protocol description and the corresponding QoS profile for the multi-mode protocol stream may include QoS configuration rules provided by the Session Management Function (SMF).

[0243] One or more QoS flows can be associated with an application session. The application session can be used for application data. Network service differentiation can be based on at least one of the following: a multi-mode application identifier; a multi-mode session identifier; a multi-mode service identifier; and a multi-mode protocol 5-tuple descriptor corresponding to the source IP address, destination IP address, source network port, destination network port, and protocol flow identifier. The multi-mode protocol can include WebRTC.

[0244] Figure 15 An example of a UE 1500 according to various aspects of this disclosure is illustrated. UE 1500 may include a processor 1502, a memory 1504, a controller 1506, and a transceiver 1508. The processor 1502, memory 1504, controller 1506, or transceiver 1508, or various components thereof, may be examples of parts for performing various aspects of this disclosure described herein. These components may be coupled via one or more interfaces (e.g., operational ground, communication ground, functional ground, electronic ground, electrical ground).

[0245] Processor 1502, memory 1504, controller 1506, or transceiver 1508, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may include a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof, configured or otherwise supporting components for performing the functions described in this disclosure.

[0246] Processor 1502 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some implementations, processor 1502 may be configured to operate memory 1504. In some other implementations, memory 1504 may be integrated into processor 1502. Processor 1502 may be configured to execute computer-readable instructions stored in memory 1504 to cause UE 1500 to perform various functions of this disclosure.

[0247] Memory 1504 may include volatile or non-volatile memory. Memory 1504 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1502, cause UE 1500 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 1504 or another type of memory. Computer-readable media include both non-transitory computer storage media and communication media, which include any medium that facilitates the transfer of computer programs from one place to another. Non-transitory storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0248] In some implementations, processor 1502 and memory 1504 coupled to processor 1502 can be configured such that UE 1500 performs one or more of the functions described herein (e.g., instructions stored in memory 1504 are executed by processor 1502). For example, according to the examples disclosed herein, processor 1502 can support wireless communication at UE 1500. UE 1500 can be configured to support components for operation with the nodes described herein.

[0249] Controller 1506 can manage input and output signals for UE 1500. Controller 1506 can also manage peripheral devices not integrated into UE 1500. In some implementations, controller 1506 can utilize operating systems such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, controller 1506 can be implemented as part of processor 1502.

[0250] In some implementations, UE 1500 may include at least one transceiver 1508. In other implementations, UE 1500 may have more than one transceiver 1508. Transceiver 1508 may represent a wireless transceiver. Transceiver 1508 may include one or more receiver chains 1510, one or more transmitter chains 1512, or a combination thereof.

[0251] Receiver chain 1510 can be configured to receive signals (e.g., control information, data, packets) via a wireless medium. For example, receiver chain 1510 may include one or more antennas for receiving signals over the air or via a wireless medium. Receiver chain 1510 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 1510 may include at least one demodulator configured to demodulate the received signal and acquire transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 1510 may include at least one decoder for decoding the demodulated signal to receive the transmitted data.

[0252] Transmitter chain 1512 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 1512 may include at least one modulator for modulating data onto a carrier signal to prepare 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 such as phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 1512 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 1512 may also include one or more antennas for transmitting the amplified signal over the air or wireless medium.

[0253] Figure 16 An example of a processor 1600 according to various aspects of this disclosure is illustrated. Processor 1600 may be an example of a processor configured to perform various operations according to the examples described herein. Processor 1600 may include a controller 1602 configured to perform various operations according to the examples described herein. Processor 1600 may optionally include at least one memory 1604, which may be, for example, an L1 / L2 / L3 cache. Additionally or alternatively, processor 1600 may optionally include one or more arithmetic logic units (ALUs) 1606. One or more of these components may be electronically communicated or otherwise coupled (e.g., operative ground, communicative ground, functional ground, electronic ground, electrical ground) via one or more interfaces (e.g., buses).

[0254] Processor 1600 may be a processor chipset and includes a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receive, acquire, retrieve, send, output, forward, store, determine, identify, access, write, read) according to the examples described herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to the processor chipset or included in the processor chipset (e.g., processor 1600)) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase-change memory (PCM), etc.).

[0255] Controller 1602 can be configured to manage and coordinate various operations of processor 1600 (e.g., signaling, receiving, acquiring, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, and reading) to enable processor 1600 to support various operations according to the examples described herein. For example, controller 1602 can operate as a control unit of processor 1600, generating control signals that manage the operation of various components of processor 1600. These control signals include enabling or disabling functional units, selecting data paths, initiating memory accesses, and coordinating operation timing.

[0256] Controller 1602 can be configured to fetch (e.g., fetch, retrieve, receive) instructions from memory 1604 and determine subsequent instructions(s) to be executed, enabling processor 1600 to support various operations according to the examples described herein. Controller 1602 can be configured to track the memory addresses of instructions associated with memory 1604. Controller 1602 can be configured to decode instructions to determine the operations to be performed and the operands involved. For example, controller 1602 can be configured to interpret instructions and determine control signals that will be output to other components of processor 1600, enabling processor 1600 to support various operations according to the examples described herein. Additionally or alternatively, controller 1602 can be configured to manage data flow within processor 1600. Controller 1602 can be configured to control data transfers between registers, arithmetic logic unit (ALU), and other functional units of processor 1600.

[0257] Memory 1604 may include one or more caches (e.g., memory native to or included in processor 1600) or other memories such as RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, memory 1604 may reside within or on the processor chipset (e.g., native to processor 1600). In some other implementations, memory 1604 may reside external to the processor chipset (e.g., remote from processor 1600).

[0258] Memory 1604 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1600, cause processor 1600 to perform the 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. Controller 1602 and / or processor 1600 may be configured to execute computer-readable instructions stored in memory 1604 to cause processor 1600 to perform various functions. For example, processor 1600 and / or controller 1602 may be coupled to or coupled to memory 1604, and processor 1600, controller 1602, and memory 1604 may be configured to perform the various functions described herein. In some examples, processor 1600 may include multiple processors, and memory 1604 may include multiple memories. One or more of the multiple processors may be coupled to one or more of the multiple memories, which may be configured individually or collectively to perform the various functions described herein.

[0259] One or more ALU 1606s can be configured to support a variety of operations as described in the examples herein. In some implementations, one or more ALU 1606s may reside within or on a processor chipset (e.g., processor 1600). In some other implementations, one or more ALU 1606s may reside outside the processor chipset (e.g., processor 1600). One or more ALU 1606s can perform one or more computations (such as addition, subtraction, multiplication, and division) on data. For example, one or more ALU 1606s can receive input operands and an opcode that determines the operation to be performed. One or more ALU 1606s are configured with a variety of logic and arithmetic circuitry, including adders, subtractors, shifters, and logic gates, to process and manipulate data according to the operations. Alternatively or concurrently, one or more ALU 1606 may support logical operations (such as AND, OR, XOR, NOR, and NAND), enabling one or more ALU 1606 to handle conditional operations, comparisons, and bitwise operations.

[0260] Based on the examples disclosed herein, processor 1600 can support wireless communication. Processor 1600 can be configured or operable to support components for: receiving a multimode protocol stream from a client, wherein the multimode protocol stream includes: multiplexing of multiple data streams of application data; receiving a protocol description defining multiple data streams in the multiplexing of application data; receiving a request for a service-differentiated application session, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multimode protocol stream; demultiplexing one or more data streams at least based on the protocol description and the corresponding QoS profile of the multimode protocol stream; and mapping each of the one or more data streams corresponding to the multimode protocol stream to one or more QoS streams for differentiated service processing, at least based on the corresponding QoS profile of the multimode protocol stream.

[0261] Figure 17 An example of an NE 1700 according to various aspects of this disclosure is illustrated. The NE 1700 may include a processor 1702, a memory 1704, a controller 1706, and a transceiver 1708. The processor 1702, memory 1704, controller 1706, or transceiver 1708, or various combinations thereof, or various components thereof, may be examples of parts for performing various aspects of this disclosure described herein. These components may be coupled via one or more interfaces (e.g., operational ground, communication ground, functional ground, electronic ground, electrical ground).

[0262] Processor 1702, memory 1704, controller 1706, or transceiver 1708, or various combinations or components thereof, may be implemented in hardware (e.g., a circuit system). The hardware may include a processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof, configured or otherwise supporting components for performing the functions described in this disclosure.

[0263] Processor 1702 may include intelligent hardware devices (e.g., a general-purpose processor, DSP, CPU, ASIC, FPGA, or any combination thereof). In some implementations, processor 1702 may be configured to operate memory 1704. In some other implementations, memory 1704 may be integrated into processor 1702. Processor 1702 may be configured to execute computer-readable instructions stored in memory 1704 to cause NE 1700 to perform various functions of this disclosure.

[0264] Memory 1704 may include volatile or non-volatile memory. Memory 1704 may store computer-readable, computer-executable code, including instructions that, when executed by processor 1702, cause NE 1700 to perform the various functions described herein. The code may be stored in a non-transitory computer-readable medium, such as memory 1704 or another type of memory. Computer-readable media include both non-transitory computer storage media and communication media, including any medium that facilitates the transfer of computer programs from one place to another. Non-transitory storage media may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0265] In some implementations, processor 1702 and memory 1704 coupled to processor 1702 can be configured such that NE 1700 performs one or more of the functions described herein (e.g., instructions stored in memory 1704 are executed by processor 1702). For example, according to the examples disclosed herein, processor 1702 can support wireless communication at NE 1700. NE 1700 can be configured to support components for: receiving a multimode protocol stream from a client, wherein the multimode protocol stream includes: multiplexing of multiple data streams of application data; receiving a protocol description defining multiple data streams in the multiplexing of application data; receiving a request for an application session with service differentiation, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multimode protocol stream; demultiplexing one or more data streams at least based on the protocol description and the corresponding QoS profile of the multimode protocol stream; and mapping each of the one or more data streams corresponding to the multimode protocol stream to one or more QoS streams for differentiated service processing, at least based on the corresponding QoS profile of the multimode protocol stream.

[0266] Controller 1706 can manage input and output signals used by NE 1700. Controller 1706 can also manage peripheral devices not integrated into NE 1700. In some implementations, controller 1706 can utilize operating systems such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, controller 1706 can be implemented as part of processor 1702.

[0267] In some implementations, the NE 1700 may include at least one transceiver 1708. In other implementations, the NE 1700 may have more than one transceiver 1708. The transceiver 1708 may represent a wireless transceiver. The transceiver 1708 may include one or more receiver chains 1710, one or more transmitter chains 1712, or a combination thereof.

[0268] Receiver chain 1710 can be configured to receive signals (e.g., control information, data, packets) via a wireless medium. For example, receiver chain 1710 may include one or more antennas for receiving signals over the air or via a wireless medium. Receiver chain 1710 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. Receiver chain 1710 may include at least one demodulator configured to demodulate the received signal and acquire transmitted data by reversing the modulation technique applied during signal transmission. Receiver chain 1710 may include at least one decoder for decoding the demodulated signal to receive the transmitted data.

[0269] Transmitter chain 1712 can be configured to generate and transmit signals (e.g., control information, data, packets). Transmitter chain 1712 may include at least one modulator for modulating data onto a carrier signal to prepare 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 such as phase shift keying (PSK) or quadrature amplitude modulation (QAM). Transmitter chain 1712 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over a wireless medium. Transmitter chain 1712 may also include one or more antennas for transmitting the amplified signal over the air or wireless medium.

[0270] Figure 18 A flowchart of method 1800 according to various aspects of this disclosure is illustrated. The operation of this method can be implemented by an NE as described herein. In some implementations, the NE can execute an instruction set to control the functional elements of the NE to perform the described functions.

[0271] At 1802, the method may include: receiving a multimode protocol stream from a client, wherein the multimode protocol stream includes: multiplexing of multiple data streams of application data. The operation of 1802 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1802 can be found in the references. Figure 17 The NE described is used to execute.

[0272] At 1804, the method may include: receiving a protocol description that defines multiple data streams in the multiplexing of application data. The operation of 1804 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1804 can be found in the references... Figure 17 The NE described is used to execute.

[0273] At 1806, the method may include: receiving a request for an application session with service differentiation, wherein the application session request includes at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream. The operation of 1806 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1806 can be found in the references... Figure 17 The NE described is used to execute.

[0274] At point 1808, the method may include: demultiplexing one or more data streams, based at least on the protocol description and the corresponding QoS profile of the multimode protocol stream. The operation of point 1808 can be performed according to the examples described herein. In some implementations, aspects of the operation of point 1808 can be found in the references... Figure 17 The NE described is used to execute.

[0275] At point 1810, the method may include: mapping each of one or more data streams corresponding to the multimode protocol stream to one or more QoS streams for differentiated service processing, based at least on the corresponding QoS profile of the multimode protocol stream. The operation of 1810 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1810 may be derived from references... Figure 17 The NE described is used to execute.

[0276] It should be noted that the method described in this paper describes one possible implementation, and the operations and steps can be rearranged or otherwise modified, and other implementations are also possible.

[0277] Figure 19 A flowchart of method 1900 according to various aspects of this disclosure is illustrated. The operation of this method can be implemented by an NE as described herein. In some implementations, the NE can execute an instruction set to control the functional elements of the NE to perform the described functions.

[0278] At 1902, the method may include: sending a multimode protocol stream to a server, wherein the multimode protocol stream includes: multiplexing of multiple data streams of application data. The operation of 1902 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1902 can be found in the references... Figure 17 The NE described is used to execute.

[0279] At 1904, the method may include: sending a protocol description that defines multiple data streams in the multiplexing of application data. The operation of 1904 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1904 can be found in the references. Figure 17 The NE described is used to execute.

[0280] At 1906, the method may include: sending a request for an application session with service differentiation, the application session including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream. The operation of 1906 can be performed according to the examples described herein. In some implementations, aspects of the operation of 1906 can be found in the references... Figure 17 The NE described is used to execute.

[0281] It should be noted that the method described in this paper describes one possible implementation, and the operations and steps can be rearranged or otherwise modified, and other implementations are also possible.

[0282] The description provided herein is intended to enable those skilled in the art to make or use this disclosure. Various modifications to this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0283] This paper presents an arrangement that, based on inherent multimode and its corresponding protocol descriptions, demultiplexes multiplexed data streams of application sessions corresponding to multimode services / applications on 5GS for differentiated QoS optimization. The focus is on protocols with encrypted multiplexing capabilities (QUIC, WebRTC, SRTP / SRTCP+Cryptex for RTP header encryption).

[0284] It also provides a protocol description, which includes a list of potentially different QoS requirements for multiplexed data streams and their individual components. These QoS requirements are part of a set of application-wide QoS requirements corresponding to differentiated service processing on 5GS multimode services. Differentiated service processing is performed when a tunnel session is established between the UE and the PSA UPF or between the AS and the PSA UFF. System and policy control configurations and corresponding signaling procedures are further provided.

[0285] Some aspects described in this article involve differentiated business processing for multi-mode tunneling and encrypted services.

[0286] Therefore, a method for multi-mode network service differentiation of application data between a client and a server is provided. The method includes: a client multiplexing one or more data streams of an application over a multi-mode protocol stream; the client providing a protocol description that determines one or more multiplexed data streams of the multi-mode protocol stream and a corresponding QoS profile of the QoS requirement set of the one or more multiplexed data streams; a server receiving the multi-mode protocol stream and a request for an application session with service differentiation, the request including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream; the server demultiplexing one or more data streams based at least on the protocol description, the corresponding QoS profile, and a network QoS policy; and the server mapping each data stream in the one or more data streams corresponding to the multi-mode protocol stream to one or more QoS streams for differentiated service processing within the network, based at least on the corresponding QoS profile and the network QoS policy.

[0287] Multimode protocol streams may be at least partially encrypted. A multimode protocol stream may include at least one of the following: the QUIC tunneling protocol; the WebRTC protocol; a combination of the following: at least one Secure Real-Time Protocol (SRTP) media stream; at least one of the following: a Real-Time Protocol (RTP) media stream, a Real-Time Control Protocol (RTCP) stream, and a Secure Real-Time Control Protocol (SRTCP) stream; a combination of the following: at least one SRTP media stream with additionally encrypted RTP header extensions; at least one of the following: a Real-Time Protocol (RTP) media stream, an RTCP stream, and an SRTCP stream.

[0288] The QUIC tunneling protocol can include the HTTP extension CONNECT over QUIC and UDP that proxies one of the following: UDP connection; TCP connection; and IP connection to a remote endpoint.

[0289] The client can be an application server (AS). The server can be a user plane function (UPF).

[0290] The protocol description and the corresponding QoS profile for the multi-mode protocol stream may include QoS rules provided by the Session Management Function (SMF).

[0291] Network QoS policies can be based on at least one of the following: policy control functions (PCF) within the network; service level agreements (SLAs); and mobile network operator (MNO) operation, management and maintenance (OAM) network configurations.

[0292] A server can map one or more data streams to one or more QoS streams, which may correspond to each of the one or more data streams being mapped to exactly one QoS stream.

[0293] One or more QoS flows may be associated with an application session, wherein network service differentiation is based on at least one of the following: a multi-mode application identifier; a multi-mode session identifier; a multi-mode service identifier; and a multi-mode protocol (e.g., WebRTC) 5-tuple descriptor corresponding to the source IP address, destination IP address, source network port, destination network port, and protocol flow identifier.

[0294] Another aspect of this document relates to the protocol description of client-side multimedia service flows. This aspect can be reflected in the transmitter logic included in the AS / UE.

[0295] Therefore, a method for multi-mode network service differentiation for client application data is provided at the client end. The method includes: the client generating a protocol description, wherein the protocol description contains a mapping of one or more data streams to identifiable protocol elements as an index list; the client multiplexing one or more data streams into an application multi-mode protocol stream based on the protocol description; and the client sharing a request with the server for an application session with network service differentiation, the request including at least: a first part corresponding to a common multi-mode session identifier, a second part corresponding to a representation of the protocol description, and a third part corresponding to a QoS profile including a set of QoS requirements for one or more multiplexed data streams.

[0296] An identifiable protocol element may correspond to at least one of the following: a stream protocol frame identifiable by at least one stream ID (e.g., a QUIC stream frame identifiable by a stream ID or a stream ID range / stream ID array); a datagram protocol frame identifiable by at least one stream ID (e.g., a QUIC datagram frame identifiable by a quarter stream ID or a stream ID range / stream ID array); a sub-protocol identifiable by at least one of protocol type and protocol number (e.g., a protocol identifiable based on the IANA protocol ID and protocol syntax applied to different sub-protocols that make up the application protocol stream, e.g., for WebRTC RTP / SRTP, RTCP / SRTCP and DTLS are multiplexed together on the application WebRTC stream); and a sub-protocol carrying an identifiable media payload type (e.g., in RTP / SRTP, the media payload type is visible to the UPF and can be inspected, identified, and mapped to a specific video / audio / haptic codec profile configuration and payload, such as a video H.264 baseline profile, an H.264 extended profile, or an H.265 master profile RTP payload type).

[0297] The client can be included in either the application server (AS) or the user equipment (UE). The server can be included within the application function (AF). The AF transmits requests for the application session through at least one of the network traffic differentiation and network exposure function (NEF) and policy control function (PCF).

[0298] A client may dynamically update at least a portion of its request for an application session with network service differentiation based on at least one of the following: changes to the protocol description; and changes to the QoS profile and QoS requirement set of one or more multiplexed multimode data streams.

[0299] Changes to the protocol description are based on the dynamic termination and reassignment of at least one of the stream identifier, protocol identifier, and RTP media type identifier.

[0300] Another aspect of this document relates to system and policy configurations for differentiating media on the same business flow.

[0301] A method for policy-controlled network functions is provided, the method comprising: receiving from a first network function a request for establishing an IP flow session to a UE, the request including: 5-tuple information, and QoS requirements for each medium within the IP flow information, a protocol description of the medium, and an identifier range; determining QoS rules for each medium within the IP flow information, and associating the QoS rules with the identifier range; and sending the QoS rules to a second network function (SMF), each QoS rule being associated with the UE in the first request.

[0302] A method for an SMF is also provided, the method comprising: receiving one or more QoS rules for a UE from a first network function, each QoS rule being associated with an identifier range; determining configuration rules for a second network function (UPF), wherein the rules assist the second network function in routing received packets (via N6) to a QoS flow to the RAN based on the identifier; and determining UL QoS rules for the UE, wherein the UL QoS rules assist the UE in routing uplink packets to a QoS flow to the RAN based on the identifier.

[0303] A method for UPF (utilizing tunnels at N6) is also provided, the method comprising: (via N6) receiving downlink packets, wherein the downlink packets are received from a first server function via a tunnel connection; decapsulating the downlink packets from the tunnel connection and processing an identifier (flow identifier) ​​associated with the received packets in the tunnel connection; determining a QoS flow for routing the packets based on configuration rules received from the SMF; and routing the packets on the corresponding QoS flow based on the configuration rules.

[0304] Configuration rules can include protocol descriptions of flow identifiers. Configuration rules can include protocol descriptions of QoS flows. Configuration rules can include flow identifiers mapped to QoS flows.

[0305] A method for a UPF is also provided, the method comprising: (via N6) receiving downlink packets; determining, based on a received first configuration rule, to route packets to a first UE via a flow connection; determining, based on the first configuration rule, a flow identifier for the flow connection; encapsulating the received packets within the flow connection corresponding to the flow identifier; and routing the flow packets on the corresponding QoS flow based on a second configuration rule received from the SMF.

[0306] The first configuration rule may include a protocol description and flow identifier for the flow connection. The second configuration rule may include a flow identifier mapped to a QoS flow.

[0307] Another aspect of this document relates to configuration information for the UE.

[0308] A method for a UE is provided, the method comprising: determining a service category and / or application identifier for a service received from an application layer in the UE; and encapsulating and routing packets on a QUIC flow connection associated with a flow identifier to a second network function according to a first configuration rule, wherein the QUIC flow packets are transmitted on a QoS flow according to the second configuration rule.

[0309] The first configuration rule may include one or more of the following: application ID or service category of the service type initiated by the application; Masque processing indicator that instructs the UE to route packets to the PSA UPF via the QUIC connection; protocol description corresponding to the media type (e.g., h264, audio, metadata); and stream identifier range that routes media via the QUIC connection.

[0310] The second configuration rule may include packet detection rules associated with uplink services on QUIC connections containing QoS flows. Packet detection rules may include flow identifiers (or ranges of flow identifiers).

[0311] The following abbreviations are relevant to the areas covered in this document: 3GPP, 3rd Generation Partnership Project; 5G, 5th Generation; 5GS, 5G System; 5QI, 5G QoS Identifier; 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 Evaluation Function; VPS, Video Parameter Set; VR, Virtual Reality; XR, Extended Reality; XR AS, XR Application Server; and XRM, XR Media.

Claims

1. A server for differentiating multi-mode network services for application data, the server comprising: At least one memory; and at least one processor, said at least one processor being coupled to said at least one memory, and configured such that the server: Receive a multi-mode protocol stream from the client, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of the application data; A protocol description is received, the protocol description defining the plurality of data streams in the multiplexing of the application data; Receive a request for an application session with service differentiation, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream; At least based on the protocol description and the corresponding QoS profile of the multi-mode protocol stream, demultiplex the one or more data streams; and Based at least on the corresponding QoS profile of the multimode protocol stream, each of the one or more data streams corresponding to the multimode protocol stream is mapped to one or more QoS streams for differentiated service processing.

2. The server according to claim 1, wherein at least one of the plurality of data streams of the application data is encrypted.

3. The server of claim 1, wherein the multi-mode protocol stream received from the client comprises at least one of the following: QUIC tunneling protocol; WebRTC protocol; A combination of the following: at least one Secure Real-Time Protocol (SRTP) media stream; at least one of the following: Real-Time Protocol (RTP) media stream; Real-Time Control Protocol (RTCP) stream; and Secure Real-Time Control Protocol (SRTCP) stream; and The following combinations: at least one SRTP media stream with additional encrypted RTP header extensions, at least one of the following: Real-time Protocol (RTP) media stream, RTCP stream, and SRTCP stream.

4. The server of claim 3, wherein the QUIC tunneling protocol includes the HTTP extension CONNECT over QUIC and UDP that proxies one of the following: UDP connection; TCP connection; and IP connection to a remote endpoint.

5. The server according to any one of the preceding claims, wherein the server includes a user plane function (UPF).

6. The server according to any one of the preceding claims, wherein the client includes an application server (AS).

7. The server according to any one of the preceding claims, wherein the mapping of each of the one or more data streams corresponding to the multi-mode protocol stream to one or more QoS streams for differentiated service processing is further based on configuration rules provided by the Session Management Function (SMF).

8. The server according to any one of the preceding claims, wherein the demultiplexing of the one or more data streams is further based on a network QoS policy; and wherein the mapping of each of the one or more data streams corresponding to the multimode protocol stream to one or more QoS streams for differentiated service processing is further based on the network QoS policy.

9. The server of claim 8, wherein the network QoS policy is based on at least one of the following: The policy control function (PCF) within the network; Service Level Agreement (SLA); and Mobile network operator (MNO) operation, management and maintenance (OAM) network configuration.

10. The server according to any one of the preceding claims, wherein the mapping of each of the one or more data streams to the one or more QoS streams comprises: Map each of the one or more data streams to a QoS stream.

11. The server according to any one of the preceding claims, wherein the one or more QoS flows are associated with an application session for the application data, and wherein network service differentiation is based on at least one of the following: Multi-mode application identifier; Multi-mode session identifier; Multimode service identifier; A multi-mode protocol 5-tuple descriptor corresponding to the source IP address, destination IP address, source network port, destination network port, and protocol flow identifier.

12. A method for differentiating multi-mode network services for application data, the method being executed by a server, and the method comprising: Receive a multi-mode protocol stream from the client, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of the application data; A protocol description is received, the protocol description defining the plurality of data streams in the multiplexing of the application data; Receive a request for an application session with service differentiation, the application session request including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream; At least based on the protocol description and the corresponding QoS profile of the multi-mode protocol stream, demultiplex the one or more data streams; and Based at least on the corresponding QoS profile of the multimode protocol stream, each of the one or more data streams corresponding to the multimode protocol stream is mapped to one or more QoS streams for differentiated service processing.

13. A client for differentiating multi-mode network services for application data, the client comprising: At least one memory; and at least one processor, said at least one processor being coupled to said at least one memory, and configured such that the client: Sending a multi-mode protocol stream to the server, wherein the multi-mode protocol stream includes: multiplexing of multiple data streams of the application data; Sending a protocol description, the protocol description defining the multiple data streams in the multiplexing of the application data; Send a request for an application session with service differentiation, the application session including at least: a representation of the protocol description and a corresponding QoS profile of the multi-mode protocol stream.

14. The client of claim 13, wherein at least one of the plurality of data streams of the application data is encrypted.

15. The client of claim 13, wherein the multimode protocol stream sent to the server comprises at least one of the following: QUIC tunneling protocol; WebRTC protocol; A combination of the following: at least one Secure Real-Time Protocol (SRTP) media stream; at least one of the following: Real-Time Protocol (RTP) media stream; Real-Time Control Protocol (RTCP) stream; and Secure Real-Time Control Protocol (SRTCP) stream; and The following combinations: at least one SRTP media stream with additional encrypted RTP header extensions, at least one of the following: Real-time Protocol (RTP) media stream, RTCP stream, and SRTCP stream.

16. The client of claim 15, wherein the QUIC tunneling protocol includes the HTTP extension CONNECT over QUIC and UDP that proxies one of the following: UDP connection; TCP connection; and IP connection to a remote endpoint.

17. The client according to any one of claims 13 to 16, wherein the server includes a user plane function (UPF).

18. The client according to any one of claims 13 to 17, wherein the client includes an application server (AS).

19. The client according to any one of claims 13 to 18, wherein the representation described by the protocol and the corresponding QoS profile of the multimode protocol stream comprise: QoS configuration rules provided by the Session Management Function (SMF).

20. The client according to any one of claims 13 to 19, wherein the one or more QoS flows are associated with an application session for the application data, and wherein network service differentiation is based on at least one of the following: Multi-mode application identifier; Multi-mode session identifier; Multimode service identifier; A multi-mode protocol 5-tuple descriptor corresponding to the source IP address, destination IP address, source network port, destination network port, and protocol flow identifier.

Images