Handling encrypted XRM traffic using QUIC aware proxying

Abstract

A network function (NF) of a core network (CN) receives a set of rules for processing a downlink Internet Protocol (IP) traffic that carries end-to-end (e2e) encrypted traffic; receives an IP packet associated with the IP traffic and metadata related to the IP packet and including one or more of (i) a Quick User Data Protocol (UDP) Internet Connections (QUIC) priority information or (ii) a QUIC correlated identifier (ID) of a QUIC session; and based on the set of rules and the metadata, performs a differentiated services code point (DSCP) transport level marking of a packet data unit (PDU) including the IP packet, the PDU associated with a PDU Set.

Description

PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00HANDLING ENCRYPTED XRM TRAEFIC USING QUIC AWARE PROXYINGCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 572, 176 entitled “Handling Encrypted XRM Traffics using QUIC Aware Proxying,” filed on March 29, 2024. The entire content of the provisional application is hereby expressly incorporated herein by referenceFIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communications and, more particularly, to differentiated handling of transport level packets carrying packet data unit (PDU) sets within a quality of service (QoS) flow in a wireless communication network.BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] Base stations that operate according to fifth-generation (5G) New Radio (NR) requirements support significantly larger bandwidth than fourth-generation (4G) base stations. In some cases, a base station can transmit to a user device, or a user equipment (UE), data associated with extended Reality (XR), which refers to such technologies as Augmented Reality (AR), Virtual Reality (VR), Mixed Reality (MR), cloud gaming. The technologies generally involve quasi-periodic streaming and are associated with high data rates and low-latency requirements.

[0005] The 3rd Generation Partnership Project (3GPP) recently proposed that a 5G system (5GS) start providing support of advanced media services such as High Data Rate Low Latency (HDRLL) services, augmented reality (AR)Zvirtual reality (VR) / extended reality (XR) services, and tactile / multi-modality communication services. XR and media services also can be referred to as “XRM services.” Generally speaking, 3GPP proposed to study enhancements of networkPATENT APPLICATION Attorney Docket No.: 31730 / 307610-00 exposure to support interaction between 5GS and XRM applications as well as enhancements of Quality of Service (QoS) and policy for XR service and media service transmission.

[0006] In a current 5GS, a QoS flow represents the finest granularity of QoS differentiation in a PDU Session. The 5G QoS characteristics correspond to a 5G QoS Identifier (5QI). A 5GS treats each packet in a QoS flow according to the same QoS requirements. However, it has been proposed that a Session Management Function (SMF) control a QoS flow and preconFig. or establish the QoS flow via a Protocol Data Unit (PDU) Session Establishment procedure or the PDU Session Modification procedure.

[0007] The characteristics of a QoS flow include a QoS profile, which the SMF can provide to the AN (Access Network) via the Access & Mobility Management Function (AMF) over a N2 reference point, or which the AN can preconFig.. The characteristics of a QoS flow further include one or more QoS rule(s) and, optionally, QoS Flow level QoS parameters associated with these QoS rule(s), which the SMF can provide to a user equipment ( UE) via the AMF and over the N1 reference point, or which the UE can derive by applying Reflective QoS control. Further, the characteristics of a QoS flow include one or more uplink (UL) and downlink (DL) packet detection rules (PDRs), which the SMF can provide to the User Plane Function (UPF).

[0008] However, XRM services can rely on PDU sets, which are groups of packets carrying payload such as a frame, a slice, or a tile for example. More specifically, a PDU set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e g. a frame or video slice for XRM Services), which have the same importance requirement at the application layer. The application layer generally requires all PDUs in a PDU set are needed to process the corresponding unit of information. In some cases, however, the application layer can recover parts of the information unit when some of the PDUs are missing.

[0009] The media layer decodes and handles packets in such a PDU set as one whole because the packets within the PDU set have inherent dependency on each other at the media layer. For example, the media layer can decode the frame / video slice only when all, or a certain minimum number, of the packets carrying the frame / video slice are successfully delivered. As another example, a client application can decode a frame within a GOP (Group of Pictures) only after successfully receiving all frames on which the particular frame depends.PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0010] Because XRM services generally require a high data rate and low latency, the 5GS QoS framework requires enhancements to support different QoS handling for a PDU set. Without considering such dependencies between the packets within the PDU set, a 5GS may perform a scheduling only with low efficiency. For example, the 5GS may drop some packets but try to deliver other packets of the same PDU set which the client application cannot use, and in thus unnecessarily expend radio resources. Similarly, audio samples, haptics applications, and remote control operations can benefit from the 5GS considering PDU set characteristics. As another example, PDU sets can carry different content, e.g. I / B / P frames, slices / tiles within an I / B / P frame, etc., and thus allows the 5GS to process packets (e.g., PDUs) that belong to less important PDU set(s) differently to more efficiently utilize resources.

[0011] Most XRM services stream using Real-time Transport Protocol (RTP) or secure RTP (SRTP ) based or HTTP based streaming protocols. For end-to-end encryption, DTLS or TLS further apply to RTP / SRTP or HTTP-based protocols, respectively.

[0012] According to one possible approach, network devices map a media service data flow (associated with a set of IP 5 tuples) to one QoS flow, and map all transporting packets associated with the same QoS flow using the same transport-level marking, i.e., differentiated services code point (DSCP) marking. Because these packets have the same DSCP value in the outer IP header, transport-level packets carrying PDU Sets in a QoS flow receive the same treatment in the transport network. Thus, there is no differentiated handling of transport-level packets carrying PDU sets within a QoS Flow in a 5G network.

[0013] Although it is possible to perform DSCP marking in an IP packet header based on PDU Set Importance (PSI) information included in a media packet header, e.g., the RTP extension header defined in 3GPP TS26.522 vO.1.1 (2023-08), this approach requires the assumption that the media packet header information necessary for PDU Set identification is unencrypted, and that the PSA UPF can identify a PDU Set and perform GTP-U header marking with the PDU Set information.

[0014] Although several further approaches have been considered, it remains unclear how network devices can enable differentiated handling of transport layer packets carrying PDU sets within a QoS Flow with DSCP marking for end-to-end encrypted traffic in downlink direction.PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00SUMMARY

[0015] Generally speaking, network devices can implement the techniques of this disclosure to support differentiated handling of transport packets carrying PDU sets within a QoS Flow, using for example certain PDU set QoS information to mark DSCP bits in an outer header of downlink packets of PDU sets.

[0016] An example embodiment of the techniques of this disclosure is a method implemented in a network function (NF) of a core network (CN). The method comprises receiving a set of rules for processing a downlink Internet Protocol (IP) traffic that carries end-to-end (e2e) encrypted traffic; receiving an IP packet associated with the IP traffic and metadata related to the IP packet and including one or more of (i) a Quick User Data Protocol (UDP) Internet Connections (QUIC) priority information or (ii) a QUIC correlated identifier (ID) of a QUIC session; and based on the set of rules and the metadata, performing a differentiated services code point (DSCP) transport level marking of a packet data unit (PDU) including the IP packet, the PDU associated with a PDU Set.

[0017] Another example embodiment of these techniques is one or more devices comprising processing hardware and configured to implement the method above.BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Fig. l is a block diagram of an example wireless communication system, such as 5GS, that supports PDU set handling in the direction using the techniques of this disclosure;

[0019] Fig. 2 is a block diagram of an example protocol stack according to which the UE of Fig. 1 can communicate with the RAN of Fig. 1;

[0020] Fig. 3 is a service-based representation of the 5GS architecture, including the overall non-roaming reference architecture of the policy and charging control framework for the 5GS;

[0021] Fig. 4 is a reference-point based representation of the 5GS architecture, including overall non-roaming reference architecture of the policy and charging control framework for the 5GS;PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0022] Fig. 6 is a high-level messaging diagram of an example scenario in which a UE uses XRM services using PDU set handling;

[0023] Fig. 7 is a diagram of transport layer packet with RTP packets from application server to 5G network;

[0024] Fig. 8 illustrates example of e2e encrypted XRM traffic using QUIC transport layer protocol such that one QUIC payload contains one RTP packet;

[0025] Fig. 9 is an example method in a Policy Control Function (PCF) for generating a policy and charging control (PCC) rule for handling e2e encrypted traffic;

[0026] Fig. 10 is an example method in a Session Management Function (SMF) for configuring differentiated transport level handling of the traffic of Fig. 9;

[0027] Fig. 11 is an example method in User Plane Function (UPF) for differentiated transport level handling of the traffic of Fig. 9;

[0028] Fig. 12 is a messaging diagram of example scenario in which a core network (CN) of a cellular communication system provides QoS provisioning for downlink e2e encrypted XRM traffic using the Quick User Data Protocol (UDP) Internet Connections (QUIC) transport layer protocol;

[0029] Fig. 13 is a messaging diagram of an example scenario in which the PCF receives, from the application function (AF), a correlated QUIC session ID (CQS-ID) and a priority of a QUIC session, and the SMF generates a mapping list of priority and DSCP values;

[0030] Fig. 14 is a messaging diagram of an example scenario in which the PCF receives, from the AF, a CQS-ID and a priority of a QUIC session, and the SMF generates a mapping list of CQS-ID and DSCP values;

[0031] Fig. 15 is a messaging diagram of an example scenario in which the PCF receives, from the AF, a CQS-ID and an indication of transport level marking, and the SMF generates DSCP assistance information with an indication of transport level marking;

[0032] Fig. 16 is a messaging diagram of an example scenario in which the PCF receives, from the AF, a CQS-ID and an indication of transport level marking, and the SMF generatesPATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00DSCP assistance information with an indication of transport level marking set to the inactive value, along with a DSCP value of the mapped CQS-ID;

[0033] Fig. 17 is a messaging diagram of an example scenario in which the PCF receives, from the AF, a CQS-ID and a priority of a QUIC session, and the SMF generates DSCP assistance information with an indication of transport level marking set to the inactive value, along with a DSCP value of the mapped CQS-ID or mapped priority of the QUIC session;

[0034] Fig. 18 is a messaging diagram of an example scenario in which the PCF receives, from the AF, a CQS-ID and a priority of a QUIC session, the SMF generates a mapping of priority and DSCP values, and the UPF generates a UDP datagram with an HTTP datagram containing metadata with a CQS-ID and a QUIC packet;

[0035] Figs. 19A-C are block diagrams of example UDP datagrams encapsulating an HTTP diagrams in different respective formats; and

[0036] Fig. 20 is a flow diagram of an example method in a network function (NF) of the core network.DETAILED DESCRIPTION OF THE DRAWINGS

[0037] As discussed below, to support PDU set identification for e2e encrypted traffic, one or more network functions (NF) of a core network establish an N6 UDP tunnel between a UPF operating as an HTTP client and Application Server (AS), with a collocated UDP proxy for HTTP. The UDP proxy can convert received HTTP datagram into UDP packets, and vice versa, until the network closes the UDP tunnel. In this manner, the HTTP datagram effectively supports in-band communication for providing metadata with PDU set Information and the corresponding QUIC packet between the 5GS and the AS.

[0038] As used herein, the term “fully encrypted media flow” refers to a media flow in which both the media header and media payload are encrypted from end-to-end. Fully encrypted headers and payload are not visible in the network. Examples include RTP over QUIC (RoQ) and Media over QUIC (MoQ) (draft-ietf-moq-transport). Partially Encrypted Media Flow: A media flow where some media headers (e.g., base header) are not encrypted. Other media headers (e.g., extension header) and media payload are encrypted from end-to-end. The payloadPATENT APPLICATION Attorney Docket No.: 31730 / 307610-00 and headers that are encrypted from end-to-end are not visible in the network. Examples include SRTP (RFC 3711) with partially encrypted header extensions (RFC 6904, RTP cryptex (RFC 9335)).

[0039] It is possible to perform DSCP marking in IP packet header based on PDU Set Importance (PSI) information included in the media packet header, e.g. RTP extension header defined in TS26.522. This solution assumes that the media packet header information necessary for PDU Set identification are not encrypted and the PSA UPF can identify PDU Set and perform GTP-U header marking with PDU Set information.

[0040] Considering end-to-end encrypted traffics which media packet header information, e.g. RTP extension header, necessary for PDU Set identification are partially or fully encrypted, it is possible to implement a mechanism that enables the application to provide DSCP assistance information to the 5GC for assigning DSCP value for an media stream based on metadata indicated in UDP-Option for the corresponding QUIC packet of the XRM traffic, in which both metadata and QUIC packet are encapsulated in the UDP datagram.

[0041] For PDU Set identification for end-to-end encrypted traffic, it is possible to establish a N6 UDP tunnel between PSA UPF as HTTP client and Application Server (AS) with collocated UDP proxy for HTTP. The UDP proxy can convert received HTTP datagram into UDP packets, and vice versa, until the UDP tunnel is closed. Therefore, the HTTP Datagram is used as in-band communication for providing metadata with PDU Set Information and the corresponding QUIC packet between 5GS and the AS.Example system and protocol stack

[0042] Referring first to Fig. 1, an example wireless communication system 100 can implement one or more of the techniques of this disclosure for supporting user handling of traffic, particularly the uplink traffic from a UE. The example wireless communication system 100 includes UEs 102A and 102B, a base station (BS) 104, a base station 106, and a core network (CN) 110, such as a fifth generation (5G) core (5GC). The base stations 104 and 106 can operate in a RAN 105 connected to the CN 110. The CN 110 can also be implemented as a sixth generation (6G) core or another suitable core network.PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0043] The base station 104 covers a cell 124, and the base station 106 covers a cell 126. If the base station 104 is a gNB, the cell 124 is an NR cell. If the base station 124 is an ng-eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the base station 106 is a gNB, the cell 126 is an NR cell, and if the base station 126 is an ng-eNB, the cell 126 is an E-UTRA cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. The cells 124 and 126 can partially overlap, so that the UE 102A or 102B can select, reselect or hands over from one of the cells 124 and 126 to the other. In general, the RAN 105 can include any number of base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells. The UE 102 can support at least a 5G NR (or simply, “NR”) air interface to communicate with the base stations 104 and 106. Each of the base stations 104, 106 can connect to the CN 110 via an interface (e.g., SI or NG interface). The base stations 104 and 106 also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0044] Several NFs that make up the CN 110 are discussed below with reference to Figs. 3 and 4. One or more of the NFs of the CN 110 implement the user consent checking techniques discussed below, for the UE 102A and / or the UE 102B.

[0045] While not shown in Fig. 1 to avoid clutter, the CN 110 may include processing hardware, which may include one or more general -purpose processors (e.g., CPUs) and a non- transitory computer-readable memory storing instructions that the one or more general -purpose processors execute. Additionally or alternatively, the processing hardware can include specialpurpose processing units. The processing hardware may be conFig.d to implement the techniques of this disclosure for enabling 5GS support of advanced media services.

[0046] The base station 104 is equipped with processing hardware that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute (not shown). Additionally or alternatively, the processing hardware can include special-purpose processing units.

[0047] The UE 102A is equipped with processing hardware 130A that can include one or more general -purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors,PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00 and / or special-purpose processing units. The UE 102A also includes a transceiver 132A to communicate with the RAN 105 over a radio interface. Further, the UE 102A includes a memory 134A storing a PDU controller 140A. The UE 102B can have a similar implementation. Further, the UE 102A also can execute various applications (not shown) to which the PDU controller 140A provides downlink data, and from which the PDU set controller 140A efficiently receives, and forwards to the CN 110 via the RAN 105, uplink data.

[0048] The CN 110 can connect to various services, including data servers (now shown) that transmit PDUs to the UEs 102A and 102B, and receive PDUs from the UEs 102A and 102B, as well as a 3rd party application 150 that can request information related specifically to the UE 102A and 102B, or a group of UEs including the UE 102A and 102B, which is subject to privacy control. The CN 110 implements one or more user privacy protection techniques discussed in more detail below to determine whether to provide the requested information to the 3rd party application 150. Further, requests for information related to UE privacy in some cases originate within the CN 110, i.e., from an AF operating in the CN 110.

[0049] Fig. 2 illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102A or 102B can communicate with an eNB / ng-eNB 230 or a gNB 232 (e.g., one or more of the base stations 104, 106). In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204 A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to a EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR REC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2). The UE 102A or 102B, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2, to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2, the UE 102A or 102B can support layering of NR PDCP 210 over EUTRA RLC 206 A, and SDAP sublayer 212 over the NR PDCP sublayer 210.PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0050] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”

[0051] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide data radio bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.Example network architecture

[0052] The techniques discussed below can be implemented in the system of Fig. 1 and / or the core network of Figs. 3 and 4.

[0053] Fig. 3 is a service-based representation 300 of an example CN architecture, which the system of Fig. 1 can implement. In the representation 300, the overall non-roaming reference architecture of the policy and charging control (PCC) framework for the 5GS includes components illustrated using solid lines, and the other components are illustrated using dashed lines. According to this representation, network functions enable other authorized network functions to access their services. The components that are outside the PCC framework include a Network Slicing Selection Function (NSSF) 302, a Network Repository Function (NRF) 306, a Unified Data Management (UDM) 308, an Edge Application Server Discovery Function (EASDF) 310, a Network Slice Specific Authentication and Authorization Function (NSAAF) 312, an Authentication Server Function (AUSF) 314, a Service Communication Proxy (SCP) 316, and a Network Slice Admission Control Function (NSACF) 318. The non-PCC architecture further includes the UE 102, the RAN 105, and a data network (DN) 330.

[0054] The PCC framework in the architecture 300 includes a Unified Data Repository (UDR) 352, a Network Exposure Function (NEF) 354, a network data analytics function (NWDAF) 356, an Application Function (AF) 358, a Policy Control Function (PCF) 360, a Charging FunctionPATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00(CHF) 362, an Access & Mobility Management Function (AMF) 364, a Session Management Function (SMF) 366, and a User Plane Function (UPF) 370.

[0055] In the discussion below, a PDU Session Anchor User Plane Function (PSA UPF) can be referred to simply as the UPF. It will be understood, however, that the UPF 370 need not be the only instance of a UPF or be limited to PSA UPF functionality.

[0056] The AF 358 in some deployment operates in a trusted domain 311 or outside the trusted domain 311, i.e., in a non-trusted domain. The trusted domain 311 is generally internal to the CN 110 and includes such components as the UDM 308, the UDR 352, the PCF 360, the AMF 364, the SMF 366, and the UPF 370. Generally speaking, an AF operating outside the trusted domain 311 can access the network functions of the CN 110 only via the NEF 354, whereas an AF operating within the trusted domain 311 can access at least some of the network functions of the CN 110 directly, or may access these functions via the NEF 354 in some deployments.

[0057] Fig. A-4 is a reference-point based representation 400 of the 5GS architecture. In Fig. A-4, the non-roaming reference architecture of the PCC framework for the 5GS is illustrated as blocks and connections with solid lines, and components and connections outside the PCC framework are illustrated using dashed lines.

[0058] For clarity, Fig. 5 illustrates a high-level scenario in which the UE 102A or 102B obtains data services. During the registration procedure, the AMF determines 510 whether the UE 102 is authorized to use the data services based on the service capability of the UE and the service authorization included in the subscription data received from the UDM 308 (e.g., as specified in TS 23.501 clause 5.7). After successful registration, the UE 102A or 102B performs 520 a PDU Session Establishment procedure (e.g., as described in TS23.502 clause 4.3.2.2). The UE 102A or 102B or the network can initiate 530 a PDU Session Modification Procedure for the existing PDU Session (e.g., as described in TS23.502 clauses 4.3.3.2 and 4.3.3.3). The UE 102A or 102B may repeat procedure 530 for multiple PDU Sessions that are associated with the same or different DNN and S-NSSAI.Example structure of a PDU enclosing a UDP payloadPATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0059] As illustrated in Fig. 6, a UPF such as the UPF 370 can generate a transport layer packet 650, which can be a PDU within a certain QoS flow, based on the IP packet 601 receives from the AS 331. The IP packet 601 includes an IP header 610 and a UDP diagram including UDP header 612 and a UDP payload 615, but does not include a UDP-option field. The UDP payload 614 includes an RTP packet 640 associated with an RTP session 605. The RTP packet 640 includes an RPT header 641 and an RTP payload 642, such an I / P / B frame 610. The UPF according to the approach of Fig. 6 can generate an IP packet 601A based on the RTP packet 640 and generate an outer IP header 652 and a GTP-U header 653 of the transport layer packet 650, to enclose an inner IP packet 60 IB corresponding to the IP packet 601 A. The UDP payload 614 can be unencrypted in the scenario of Fig. 6, and the UPF can generate the outer IP header 652 and a GTP-U header 653 based on the UDP payload 614 (e.g., using the RTP header 641).

[0060] Fig. 7 illustrates example layering of the QUIC protocol over UDP, which an application server and a CN can support for PDU Set based handling of end-to-end encrypted traffic. An IP packet 701 includes an IP header 710 and a UDP diagram that in turn includes a UDP header 712, a UDP payload 714, and UDP-option 716. The UDP payload 714 can encapsulate a QUIC packet. In an example implementation, the UDP-option 714 includes metadata with the necessary RTP session information for mapping to the QUIC stream. The UPF 370 can use the UDP-option 716 for PDU Set based identification.

[0061] The UDP payload 714 can include a QUIC packet 722 of a QUIC stream 720 with a certain QUIC connection. An RTP session 702 in this example includes the single QUIC stream 720. The QUIC packet 722 includes a QUIC header 730 and a QUIC payload 732, which encapsulates one or more RTP packets that share the same RTP properties, e.g., I / P / B media frame type. In the example of Fig. 7, the QUIC payload 732 includes a single RPT packet including an RTP header and an RTP payload.

[0062] According to the approach 800 illustrated in Fig. 8, the UPF 370 can use the metadata included in an IP packet 801 for differentiated handling of PDUs when transporting downlink encrypted XRM traffic from the AS 331. The UPF 370 for example can detect an IP flow with encrypted XRM traffic and identify a PDU in a PDU Set based on (i) the unencrypted metadata in the UDP-Option field of the IP packet 1001 for the corresponding QUIC packet, on the user plane, and (ii) downlink XRM traffic information, on the control plane. The UPF 370 canPATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00 receive the downlink XRM traffic information from the SMF 366, as a part of an N4 session configuration that can include a Packet Detection Rule (PDR), a Forwarding Action Rule (FAR), and a QoS Enforcement Rule (QER).

[0063] The UPF 370 then can set the DSCP bits in an outer IP header 852 of a PDU 1051 in the identified PDU Set, for transport-level marking. The PDU 1051 thus is a transport-layer packet. The UPF 370 can determine the DSCP bits using the DSCP assistance information, which can be included in the N4 session configuration. The IP payload of the IP packet 1001 can encapsulate a QUIC packet with downlink XRM traffic.

[0064] Further, the UPF 370 can perform PDU Set based handling by (i) identifying a PDU of a PDU Set based on the RTP extension header, when the IP payload of the IP packet 801 is unencrypted, or on the unencrypted metadata included in UDP-Option (regardless of whether the IP payload of the IP packet 801 is encrypted), and (ii) marking in GTP-U header with one or both of (1) PDU Set Information for the identified PDU associated with a certain PDU Set, or (2) the priority of the QUIC session or other information which the metadata within the UDP-Option indicates for partially or fully encrypted XRM traffic. When the XRM traffic is unencrypted, the UPF 370 can obtain the PDU Set Information from the RTP extension header. When the XRM traffic is encrypted, the UPF 370 can obtain the PDU Set Information from the UDP-Option field.Example techniques for supporting differentiated handling of e2e encrypted traffic

[0065] Figs. 9-11 illustrate several example methods in a core network to enable PDU set based handling for PDU set identification and marking and differentiated handling for transporting downlink e2 encrypted XRM traffic. Generally speaking, similar events in Figs. 9- 18 and 20 are labeled with similar reference numbers that share two least significant digits, with differences discussed where appropriate. For example, event 1339 is similar to event 1439 and 1539, event 1339 is similar to event 1439 as well as block 2039, etc.

[0066] Fig. 9 is an example method 900 which a PCF, such as the PCF 360, can implement to generate rule for handling e2e encrypted traffic. At block 910, the PCF receives, from an AF such as the AF 358, an AF request message that requests QoS provisioning for e2e encrypted XRM traffic. The AF request message can include assistance information for handling downlink e2e encrypted XRM traffic to support (i) PDU set based handling for downlink e2e encryptedPATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00XRM traffic and (ii) differentiated handling when transporting downlink e2e encrypted XRM traffic.

[0067] At block 921, the PCF generates PCC rules that contain assistance information for handling downlink e2e encrypted XRM traffic. To this end, the PCF enables PDU set based handling for downlink e2e encrypted XRM traffic based on the assistance information for handling downlink e2e encrypted XRM traffic. For example, the assistance information can include a QoS requirement that includes PDU Set based parameters. The PCF further enables differentiated handling for transporting downlink e2e encrypted XRM traffic based on the assistance information for handling downlink e2e encrypted XRM traffic, such as an indication of differentiated handling for transport or priority of the QUIC session. At block 926, the PCF provides the PCC rule(s) to an SMF, such as the SMF 366.

[0068] Fig. 10 is an example method 100, which an SMF (such as the SMF 366) can implement to configure differentiated transport level handling of the downlink e2e encrypted XRM traffic. At block 1026, the SMF receives a PCC rule which the PCF configured based on the assistance information of the downlink XRM traffic received from the AF, as discussed above with reference to Fig. 9. Next, at block 1031, the SMF performs QoS binding for the PCC rule. At block 1032, the SMF determines to enable differentiated transport level handling across one or more QoS flow(s) for downlink XRM traffic in the 5GC. To this end, the SMF determines DSCP assistance information. At block 1039, the SMF provides N4 rules (PDR, FAR, QER) to the UPF and intermediate UPF(s), via the N4 interface.

[0069] Next, Fig. 11 illustrates an example method 100, which a PSA UPF, or simply UPF (such as the UPF 370) can implement to support differentiated transport level handling of the downlink e2e encrypted XRM traffic.

[0070] At block 1139, the UPF receives N4 rules from the SMF. As discussed above, the N4 rules can include a PDR, a FAR, and QER for the downlink XRM traffic. At block 1131, the UPF enables PDU set based handling for PDU set identification and marking for an e2e encrypted XRM traffic. In particular, at block 1132, the UPF can operate as an HTTP client to establish a UDP tunnel with an AS (e.g., the AS 331), as a collocated UDP proxy for HTTP, which can convert received HTTP datagram into UDP packets, and vice versa. At block 1160, the UPF can receive, from the AS, an HTTP Datagram containing metadata and thePATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00 corresponding e2e QUIC packet. Next, at block 1 180, based on the N4 rules and the HTTP datagram that includes the metadata and the QUIC packet associated with the e2e encrypted XRM traffic, the UPF can (i) perform PDU set identification, by detecting an IP flow with encrypted XRM traffic and identifying a PDU set based PDU, and (ii) perform GTP-U marking for the identified PDU that belongs to a PDU Set.

[0071] At blocks 1190 and 1163, the UPF can enable differentiated handling for transporting downlink e2e encrypted XRM traffics. In particular, at block 1190, the UPF can perform DSCP bits marking in the outer IP header of the identified PDU belonging to a PDU set, for transport level DSCP marking based on the N4 rules for the DSCP assistance information, where for example the IP payload received from AS encapsulates a UDP datagram with an HTTP datagram containing metadata and a QUIC packet with downlink XRM traffic. At block 1163, the UPF forwards the IP packet encapsulating the QUIC packet to a RAN (e.g., the RAN 105) for PDU set based QoS handling.

[0072] The metadata discussed with reference to Fig. 11 can include, for example, a downlink CQS-ID (alternatively acronymized as QUIC session correlation (QSC-ID)), which an XRM application can generate as a variable-length or fixed-length hash value per IP flow, QUIC connection (based on the QUIC connection ID), and a QUIC stream (based on QUIC Stream ID), for privacy and security protection. The QSC-ID is unique for an XRM application, and a QUIC session can be associated to with IP flow with one QUIC connection, or one IP flow with one QUIC stream within one QUIC connection.

[0073] The metadata further can include the priority of the QUIC session identified by the QSC-ID or an indication of differentiated handling for transport, as discussed below with reference to example scenarios. Still further, the metadata can include one or more of the following units of downlink PDU set information contained in the RTP Extension header of RTP packets (encapsulated in an encrypted QUIC packet: (i) a PDU set sequence number, (ii) an indication of the end PDU in the PDU set, (iii) a PDU sequence number within a PDU set, (iv) a PDU set Size in bytes, or (v) a PDU set importance, which identifies the relative importance of the PDU set compared to other PDU sets within a QoS flow.

[0074] A QUIC session can be associated with one IP flow with one QUIC connection or one IP flow with one QUIC stream within one QUIC connection. For example, an XRM applicationPATENT APPLICATION Attorney Docket No.: 31730 / 307610-00 can use different IP flows (represented by different IP 5 tuples) for different QUIC connections, if each QUIC connection contains only one QUIC stream, each QUIC session correlated ID is generated per IP flow. As another example, an XRM application uses the same IP flow (represented by certain IP 5 tuples) for all QUIC connections, if each QUIC connection contains only one QUIC stream, and each QUIC session correlated ID is generated per QUIC connection. As another example, an XRM application uses the same IP flow for all QUIC connections, if each QUIC connection contains only one QUIC stream, and each QUIC session correlated ID is generated per QUIC connection. As yet another example, an XRM application uses different IP flows for different sets of QUIC connections, if each QUIC connection contains only one QUIC stream, and each QUIC session correlated ID is generated per IP flow and QUIC connection. As still another example, an XRM application can use different IP flows for different set of QUIC connections, if each QUIC connection contains more than one QUIC stream, and each QUIC session correlated ID is generated per IP flow, QUIC connection, and QUIC stream.

[0075] The N4 rules discussed above with reference to Figs. 10 and 11 can include a PDR, an FAR, and a QER.

[0076] The PDR contains packet detection information with at least one of the following: (i) a QoS flow ID (QFID) allocated by the SMF 366, (ii) a Packet Filter Set and a Protocol Description based on the IP header of the IP packets, as indicated in TS 23.501 for example, and additionally one or more DL QSC-IDs, which can be associated with one or more components of the traffic descriptions such as IP flows, QUIC connections, and QUIC streams, and (iii) a Protocol Description that indicates the use of the transport layer protocol, e.g., RTP over QUIC (RoQ) or Media over QUIC, for the downlink e2e encrypted XRM traffic, and N6 UDP tunnel using UDP proxy for HTTP datagram with metadata and QUIC packet of the XRM traffic.

[0077] The FAR can include an indication of an N6 UDP tunnel using UDP proxy for HTTP Datagram and a fully qualified domain name (FQDN) for the AS and DSCP assistance information, which can include (i) a mapping list of priority values of a QUIC session and DSCP values, as option 1, (ii) a mapping list of QSC-ID and DSCP values, as option 2, or (iii) a specific DSCP value for a QUIC session identified by a specific QSC-ID, as option 3.

[0078] The QER can include PDU Set Information marking indicator that instructs the UPF 370 to mark the GTP-U header for the identified PDU in a PDU Set, and / or a DSCP markingPATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00 indicator that instructs the UPF to mark the outer IP header with DSCP bits according to the FAR, for the identified PDU in a PDU Set. Th FAR can be based on the PSI for the unencrypted XRM traffic and / or metadata for the e2e encrypted XRM traffic.

[0079] For example, the SMF 366 can configure the N4 rules as follows. For the PDU set based handling of downlink e2e encrypted XRM traffic, the SMF can generate the PDR including (i) a packet filter with information for a QSC-ID, using which the UPF can identify a PDU set based PDU for encrypted XRM traffic in which metadata contains this QSC-ID, (ii) a protocol description with information indicating the use of the transport layer protocol, e.g., RTP over QUIC (RoQ) or Media over QUIC, for the downlink e2e encrypted XRM traffic, and an N6 UDP tunnel using UDP proxy for an HTTP datagram with metadata and QUIC packet of the XRM traffic.

[0080] The SMF can determine the FAR including an indication of an N6 UDP tunnel using a UDP proxy for an HTTP Datagram and FQDN for the AS. Further, the SMF can determine the QER including a PDU set information marking indicator that instructs the UPF to mark the GTP- U header for the identified PDU in a PDU set.

[0081] For differentiated handling of transporting downlink e2e encrypted XRM traffic, theSMF can (i) determine the QER and the FAR including a DSCP marking indicator to enable or disable differentiated handling of transporting XRM traffic, based on marking of the outer IP header with DSCP bits according to FAR, and (ii) determine the FAR including the DSCP assistance information for encrypted XRM traffic.

[0082] For example, for differentiated handling of transporting downlink e2e encrypted XRM traffics, when the UPF receives N4 rules including DSCP assistance information from the SMF (in an N4 ) message, the UPF can identify, based on the matched QSC-ID included in the extended packet filter set in PDR with the metadata of the XRM traffic, the corresponding QUIC session. Based on the FAR with DSCP assistance information and the QER / FAR with DSCP marking indicator, for the matched QSC-ID QUIC session based on the PDR, the UPF can mark the DSCP bit in the outer IP header of the identified PDU according to the DSCP value. This value corresponds to the priority value indicated in metadata, based on the DSCP assistance information with the mapping list for priority values of QUIC sessions and DSCP values.Example scenariosPATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0083] Fig. 12 is a messaging diagram of example scenario 1200 in which the CN 110 provides QoS provisioning for downlink e2e encrypted XRM traffic. The UE 102 performs 1202 a PDU Session Establishment procedure, which can be similar to the procedure described in TS 23.502, clause 4.3.2.2.1. The AF 358 receives, from the AS 331, assistance information for requesting QoS provisioning for e2e encrypted XRM traffic.

[0084] The AF 358 sends PDU session establishment with PDU set with certain parameters. To this end, the AF 358 sends, to the PCG 360 / NEF 354, an Nnef_AFsessionWithQoS_Create request or an Nnef AFsessionWithQoS Update request message and provide the following information: (i) a QoS requirement, which can include PDU Set based QoS parameters for the downlink XRM traffic, (ii) a traffic description to indicate IP flow information for the downlink XRM traffic, e.g. IP 5 tuples, and additional traffic description to indicate a downlink QSC-ID, (iii) a protocol description with an indication of the transport layer protocol, e.g., QoQ or Media over QUIC, for the downlink e2e encrypted XRM traffic, and N6 UDP tunnel using UDP proxy for HTTP datagram with metadata and QUIC packet of the XRM traffic, where one or more context ID(s) may be provided for the HTTP datagram that carries specific content, and (iv) the priority value of the QUIC session identified by the QSC-ID.

[0085] The downlink QSC-ID can be based on one or more components of the traffic descriptions, such as IP flows (each is represented by an IP 5 tuples), QUIC connections, and QUIC streams, e.g., for association with a specific QoS requirement of a QoS flow. The QSC-ID is unique within the XRM application. Different QUIC sessions may be associated with QUIC connections in different IP flows, different QUIC connections in one IP flow, or different QUIC streams within one QUIC connection in one IP flow.

[0086] The PCF 360 determines 1220 to enable PDU set based handling for e2e encrypted XRM traffic, and generates 1221 PCC Rules based on the information provided by the AF and / or local policies, e.g., as described in TS 23.503 clause 6.1.3.27.4. The PCF 360 forwards 1226, to the SMF 366, the PCC rule for the e2e encrypted XRM traffic using an SM Policy Association Establishment / Modification message.

[0087] The SMF 366 binds 1231 the PCC rules to a QoS flow, determines the applicable QoS Profile, and determines N4 rules as follows for PDU set based handling and differentiated handling of transporting downlink e2e encrypted XRM traffic as discussed above with referencePATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00 to Fig. 11 . The SMF 266 instructs 1232 the UPF 370 and performs 1233 PDU set based handling also as discussed with reference to Fig. 11. The SMF 366 then provisions 1240 the RAN 105 with the QoS profile, via the AMF 364. The SMF 366 also sends 1241, to the UE 102, the QoS rules in a NAS message, via AMF 364 and the RAN 105.

[0088] The UE 102 sends 1250, to the UPF 370, an uplink packet when initiating an e2e QUIC connection towards the AS 331, to enable the end-to-end encryption of the XRM traffic. Based on the FAR with an indication of an N6 tunnel using UDP proxy for the HTTP Datagram and the FQDN for the AS 331, the UPF 370 detects 1251 the uplink packet addressed to the AS 331, with the address and the port number that matches the FAR for the e2e encrypted XRM, requests 1251 UDP tunnel establishment to the target AS 331 as a UDP proxy for an HTTP / 3 session, and forwards 1251, to the AS 331, an e2e QUIC connection establishment request.

[0089] The AS 331 determines 1252 to use an HTTP datagram with a capsule protocol for sending metadata and the corresponding QUIC packet of the XRM traffic. The AS 331 then sends 1260 an IP packet encapsulating a UDP datagram including HTTP datagrams with metadata and a QUIC packet of the XRM traffic. In some implementations, the AS 331 encloses the metadata and the QUIC packet within the same UDP datagram, e.g. using one of the options considered in the discussion of metadata above.

[0090] Based on the metadata and the QUIC packet information obtained from the encapsulated UDP datagram, the UPF 370 can perform 1280 PDU set identification and marking with PDU set information of the GTP-U header based on PDR and PDU Set information in the metadata. The UPF 370 further can perform 1290 DSCP bit marking of the outer IP header based on the PDR and FAR, the and perform 1290 the QoS enforcement based on the QER.

[0091] The UPF 370 forwards 1263 the (XRM) IP packet over the transport network, and the routers transport the IP packet with traffic differentiation that is based on the DSCP bits. The RAN 105 then sends 1270, to the UE 102, the XRM packet according to downlink PDU set based QoS handling and based on GTP-U header and the PDU set based QoS parameters in the QoS profile.

[0092] Next, Figs. 13-18 illustrate several example implementations of differentiated handling of transporting downlink encrypted XRM traffic.PATENT APPLICATION Attorney Docket No.: 31730 / 307610-00

[0093] First, Fig. 13 illustrates an example scenario 300. The AF 358 sends 1311, to the PCF 360 / NEF 354, an AF request message including a CQS-ID and priority of the QUIC session. The PCF 360 generates and sends 1326 the PCC rule to the SMF 366, based on the information included in received 1311 AF request message. The SMF 366 enables 1331 differentiated handling for transporting downlink encrypted XRM traffics. The SMF 366 further generates 1332 a mapping list of priority and DSCP values based on operator policies, SMF configuration of the DSCP values, and the priority values of all the QUIC sessions for the XRM application. The SMF 366 also generates 1337 N4 rules with DSCP assistance information that includes a mapping list of priority and DSCP values.

[0094] The SMF 366 provides 1339, to the UPF 370, N4 rules. The AS 331 sends 1361 an IP packet that encapsulates a UDP datagram with an HTTP datagram containing metadata (including the CQS-ID and the priority of QUIC session) we well as a QUIC packet for the downlink XRM traffic. Based on the DSCP assistance information, including the mapping list of the priority and DSCP values, the UPF 370 identifies 1381 a PDU based on CQS-ID in the metadata and obtains 1381 DSCP values for the mapped priority value of the QUIC session indicated in the metadata. The UPF 370 marks 1391 DSCP bits in the outer IP header based on the obtained DSCP value.

[0095] Fig. 14 is a messaging diagram of an example scenario 1400. This scenario is generally similar to that of Fig. 13, with the differences discussed below. Events 1411 , 1426, 1431, 1439 are similar to the events 1311, 1326, 1331, and 1339, respectively, discussed above. Here, however, the SMF generates 1433 a mapping list of CQS-ID and DSCP values based on operator policies, SMF configuration of the DSCP values, and the priority values of all the QUIC sessions for the XRM application. The SMF 366 then generates 1437 N4 rules with DSCP assistance info that include a mapping list of CQS-ID and DSCP values.

[0096] The AS 331 sends 1462 an IP packet that encapsulates a UDP datagram with an HTTP datagram containing metadata (CQS-ID) and a QUIC packet for the downlink XRM traffic.Based on the DSCP assistance info (mapping list of the CQS-ID and DSCP values), the UPF 370 identifies 1482 a PDU based on the CQS-ID in the metadata and obtains 1482 DSCP values for the mapped CQS-ID of the QUIC session indicated in the metadata. The UPF 370 marks 1491 the DSCP bits in the outer IP header based on the obtained DSCP value.PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0097] Fig. 15 illustrates an example scenario 1500 which also is generally similar to that of Fig. 13 or Fig. 14, with the differences considered next. Events 1526, 1531, 1539, and 1563 are similar to the events 1326 / 1426, 1331 / 1431, 1339 / 1439, and 1463, respectively, discussed above.

[0098] The AF 358 sends 1512, to the PCF 360 / NEF 354, an AF request message including a CQS-ID and an indication of transport level marking. The PCF 360 generates and sends 1526, to the SMF 366, the PCC rule, based on the information received 1512 in the AF request message. The SMF 366 generates 1538 N4 rules with DSCP assistance info, including an indication of transport level marking. The SMF 366 and the UPF 370 identify 1583, based on the metadata and the N4 rules, a PDU based on the CQS-ID in the metadata. Based on DSCP assistance info (indication of transport level marking), and the received 1563 priority of the QUIC session in the metadata, the UPF 370 reports 1583 the priority of the QUIC session in the metadata to the SMF 366, for generating a mapping list of priority and DSCP values based on operator policies, the SMF configuration of the DSCP values, and the priority values of all the QUIC sessions for the XRM application. The SMF 366 and the UPF 370 further obtain 1583 DSCP assistance information, which includes an indication of transport level marking set to “inactive” and the DSCP value of the mapped priority of the QUIC session.

[0099] The UPF 370 marks 1592 the DSCP bits in the outer IP header based on the obtained DSCP value, using the DSCP value obtained 1583 from the SMF 366. With the indication of transport level marking set to “inactive,” the UPF 370 uses the same DSCP value for the outer IP header of the IP packet for the QUIC session.

[0100] Fig. 16 is a messaging diagram of an example scenario 1600, which is generally similar to that of Fig. 15, with the differences considered next. Events 1612, 1626, 1631, 1639, 1661, andl692 are similar to the events 1512, 1526, 1531, 1539, 1561, and 1592, respectively, discussed above.

[0101] Here, based on the metadata and the N4 rules, the UPF 370 and the SMF 366 perform 1684 the following: (i) identify a PDU in a PDU Set based on the CQS-ID in the metadata, (ii) based on the DSCP assistance information, including an indication of transport level marking, and the priority of QUIC session received 1563 in the metadata, report the priority of QUIC session in metadata to the SMF 366 for generating a mapping list of CQS-ID and DSCP values based on operator policies, the SMF configuration of the DSCP values, and the priority values ofPATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00 all the QUIC sessions for the XRM application, and (iii) obtain DSCP assistance information including an indication of transport level marking set to “inactive” and the DSCP value of the mapped CQS-ID.

[0102] Fig. 17 is a messaging diagram of an example scenario 1700, which is generally similar to that of Figs. 13-16, with the differences considered next. Events 1711, 1726, 1731, 1739, 1762 are similar to the events 1311, 1526, 1531, 1539, 1462 respectively, discussed above. Here, the UPF 370 and the SMF 366 perform 1785 the following, based on the metadata and the N4 rules: (i) identify a PDU based on the CQS-ID in the metadata, (ii) based on the DSCP assistance information including an indication of transport level marking, and priority of the QUIC session received in the metadata, report the CQS-ID and the priority of the QUIC session in the metadata to the SMF 366 for generating a mapping list of CQS-ID and DSCP values or a mapping list of priority and DSCP values based on operator policies, the SMF configuration of the DSCP values, and the priority values of all the QUIC sessions for the XRM application, (iii) and obtain DSCP assistance information including an indication of transport level marking set to “inactive,” the DSCP value of the mapped CQS-ID or the mapped priority of the QUIC session.

[0103] The UPF 370, based on the obtained DSCP value, marks 1794 the DSCP bits in the outer IP header based on the obtained DSCP value. With the indication of transport level marking set to “inactive,” the UPF 370 uses the same DSCP value for the outer IP header of the IP packet for the QUIC session.

[0104] Fig. 18 is a messaging diagram of an example scenario 1800, which is generally similar to that of Figs. 13-16, with the differences considered next. The SMF 366 generates 1835 a mapping list of priority and DSCP values based on the operator policies, the SMF configuration of the DSCP values, and the priority values of all the QUIC sessions for the XRM application. The SMF 366 generates 1839 N4 rules with the DSCP assistance information including the DSCP values, in the FAR. The AS 331 sends 1862 an IP packet that encapsulates a UDP datagram with an HTTP datagram containing metadata (CQS-ID) and a QUIC packet for the downlink XRM traffic. Based on the DSCP assistance information including the DSCP values, the UPF 370 identifies 1895 a PDU based on the CQS-ID in the metadata and marks 1895 DSCP bits in the outer IP header of the identified PDU based on the DSCP value obtained from the FAR.PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0105] Now referring to Figs. 19A-C, techniques for delivering metadata with the corresponding QUIC packet of the e2e encrypted XRM traffic, e.g. using RTP or other media transport protocol, can be based on QUIC aware UDP proxying for an HTTP datagram, where the AS 331 can encapsulate an HTTP datagram in a UDP datagram 1914A, 1914B, or 1914C, for carrying different payloads identified by a specific context ID, and can be designed with a dedicated capsule protocol for metadata delivery with the corresponding e2e encrypted QUIC packet in the following options.

[0106] In the examples of Figs. 19A-C, the metadata can include the information discussed above (the QSC-ID, the priority of the QUIC session, PDU set information, etc.).

[0107] According to a first approach discussed with reference to Figs. 19A-C, the AS 331 generates an HTTP datagram with a capsule protocol. This approach can be combined with the technique of Fig. 13, 15, or 16, for example. In particular, based on the QUIC aware UDP proxy for a HTTP datagram, the AS 331 can encapsulate an HTTP datagram in a UDP datagram and can support a capsule protocol for metadata delivery with the corresponding e2e encrypted QUIC packet in the following options.

[0108] According to option (a) illustrated in Fig. 19A, the UDP datagram encapsulates one HTTP Datagram 1923 and one QUIC packet 1922. According to option a.1, the AS 331 reuses the existing capsule type of QUIC datagram, and the PDU Set Information is included in an encrypted QUIC datagram. The CQS-ID and the priority of the QUIC Session within the application can be included as part of the PDU set Information contained in the RTP Extension header of RTP packets encapsulated in an encrypted QUIC packet. The HTTP header of the HTTP Datagram can include the following information: context ID: 0x00, which has been defined in IETF RFC 9297 and registered at IANA.

[0109] According to option a.2, the AS 331 uses a new (dedicated, special-purpose) context ID for capsule type of the QUIC datagram in the HTTP Datagram, in which the PDU Set Information is included in an encrypted QUIC datagram and the HTTP header of the HTTP Datagram can include the following information: (i) context ID: new (dedicated, specialpurpose) ID for the HTTP datagram containing information for PDU Set Identification and PDU Set information for the e2e encrypted XRM traffic; (ii) the CQS-ID, which is used for the PDU Set identification, and (iii) priority of the QUIC Session within the application.PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0110] According to option B illustrated in Fig. 19B, the UDP datagram 1914B encapsulates two HTTP Datagrams including one HTTP datagram 1925 with a new (dedicated, specialpurpose) capsule type for the QUIC datagram containing PDU Set Information, and one HTTP datagram 1926 is with the capsule type set as 0x00 for the QUIC datagram containing XRM payload.

[0111] The HTTP header of the first HTTP datagram 1925 can include the following information: a context ID, which can be a new (dedicated, special-purpose) ID for the HTTP datagram containing information for PDU Set Identification for the e2e encrypted XRM traffic, a CQS-ID, and priority of the QUIC Session within the application. The HTTP header of the second QUIC datagram 1926 can include the following information: a context ID: 0x00, which has been defined in IETF RFC 9297 and registered at IANA.

[0112] According to option C illustrated in Fig. 19C: the UDP datagram 1914C encapsulates a single HTTP datagram 1927 with a new capsule protocol for encapsulating two QUIC datagrams, including: a first QUIC datagram that contains PDU Set Information, and a second QUIC datagram contains an XRM payload. The HTTP header of the HTTP Datagram can include the following information: a context ID: new ID for the HTTP datagram containing information for PDU Set Identification and QUIC packet for the e2e encrypted XRM traffic; a CQS-ID; and priority of the QUIC Session within the application

[0113] Another approach can be combined with the technique of Fig. 14 and 17, for example. This approach is based on a QUIC aware UDP proxy for HTTP datagram. The AS 331 can encapsulate HTTP datagram in UDP datagram and can be designed with new capsule protocol for metadata delivery with corresponding e2e encrypted QUIC packet in the following options.

[0114] According to option A (see Fig. 19AC), the UDP datagram encapsulates one HTTP Datagram and one QUIC packet. In particular, according to option a.l, the AS 331 reuses the existing capsule type of QUIC datagram, and the PDU Set Information is included in an encrypted QUIC datagram. The Correlated QUIC Session ID (CQS-ID) can be included as part of PDU Set Information contained in the RTP Extension header of RTP packets encapsulated in an encrypted QUIC packet. The HTTP header of the HTTP Datagram can include the following information: Context ID: 0x00, which has been defined in IETF RFC 9297 and registered at IANA.PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0115] According to option a.2, the AS 331 uses a new Context ID for capsule type of QUIC datagram in the HTTP Datagram, in which the PDU Set Information is included in an encrypted QUIC datagram and the HTTP header of the HTTP Datagram can include the following information: a context ID: new (special-purpose, dedicated) ID for the HTTP datagram containing information for PDU Set Identification and PDU Set information for the e2e encrypted XRM traffic; and CQS-ID, which is used for the PDU Set identification.

[0116] According to option B (see Fig. 19B), the UDP datagram encapsulates two HTTP datagrams including: one HTTP datagram is with new capsule type for the QUIC datagram containing PDU set Information, and one HTTP datagram is with capsule type set as 0x00 for the QUIC datagram containing XRM payload. The HTTP header of the first HTTP datagram can include the following information: a context ID, which can be a new (special-purpose, dedicated) ID for the HTTP datagram containing information for PDU Set Identification for the e2e encrypted XRM traffic, and a CQS-ID.

[0117] The HTTP header of the second QUIC datagram can include the following information: a context ID: 0x00, which has been defined in IETF RFC 9297 and registered at IAN A.

[0118] According to option C (see Fig. 19C), the UDP datagram encapsulates one HTTP datagram with a new (dedicated, special-purpose) capsule protocol for encapsulating two QUIC datagrams, including: a first QUIC Datagram contains PDU Set Information, and a second QUIC Datagram contains XRM payload. The HTTP header of the HTTP Datagram can include the following information: a context ID: new ID for the HTTP datagram containing information for PDU Set Identification and QUIC packet for the e2e encrypted XRM traffic; and a CQS-ID.

[0119] Fig. 20 is a flow diagram of an example method 2000 in an NF (e.g., the UPF 370) of a core network such as the CN 110. At block 2039, the NF receives a set of rules for processing a downlink IP traffic that carries e2e encrypted traffic. At block 2060, the NF receives an IP packet associated with the IP traffic and metadata related to the IP packet and including one or more of (i) a QUIC priority information or (ii) a QSC-ID (or CQS-ID) of a QUIC session. At block 2090, based on the set of rules and the metadata, the NF performs a differentiated services code point (DSCP) transport level marking of a packet data unit (PDU) including the IP packet, the PDU associated with a PDU Set.PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00

[0120] The following description may be applied to the description above.

[0121] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an intemet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general -purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0122] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code stored on non- transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be conFig.d or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently conFig.d (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application -specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily conFig.d by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently conFig.d circuitry, or in temporarily conFig.d circuitry (e.g., conFig.d by software) may be driven by cost and time considerations.

[0123] The term “or” as used herein is to be interpreted as an inclusive or meaning any one or any combination, unless expressly indicated otherwise, mutually exclusive, or indicated otherwise by context. Therefore, herein, the expression “A or B” means “A, B, or both A and B.”

[0124] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. ThePATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00 software can be executed by one or more general -purpose processors or one or more specialpurpose processors.

Claims

PATENT APPLICATIONAttorney Docket No.: 31730 / 307610-00What is claimed is:

1. A method in a network function (NF) of a core network (CN), the method comprising: receiving a set of rules for processing a downlink Internet Protocol (IP) traffic that carries end-to-end (e2e) encrypted traffic; receiving an IP packet associated with the IP traffic and metadata related to the IP packet and including one or more of (i) a Quick User Data Protocol (UDP) Internet Connections (QUIC) priority information or (ii) a QUIC correlated identifier (ID) of a QUIC session; and based on the set of rules and the metadata, performing a differentiated services code point (DSCP) transport level marking of a packet data unit (PDU) including the IP packet, the PDU associated with a PDU Set.

2. The method of claim 1, further comprising: determining a priority of the QUIC session based on the correlated ID.

3. The method of claim 1 or 2, wherein: the correlated ID corresponds to a single Internet Protocol (IP) flow.

4. The method of claim 1 or 3, wherein: the correlated ID is unique for an extended reality and media services (XRM) application.

5. The method of any of the preceding claims, wherein: the set of rules includes a Packet Detection Rule (PDR) with a QUIC correlated ID.

6. The method of any of the preceding claims, wherein: the set of rules includes a Forwarding Action Rule (FAR) with DSCP assistance information comprising a mapping of priorities and DSCP values.

7. The method of claim 6, wherein the DSCP assistance information includes one of:(i) a mapping of priority values of the QUIC session to respective DSCP values,(ii) a mapping of QUIC correlated IDs to respective DSCP values, orPATENT APPLICATION Attorney Docket No.: 31730 / 307610-00(iii) a DSCP value of the QUIC session.

8. The method of claim 6 or 7, wherein: the set of rules includes a Quality of Service (QoS) Enforcement Rule (QER) with a DSCP marking indicator that instructs the NF to make an outer header of the IP packet according to the DSCP assistance information.

9. The method of any of the preceding claims, wherein: the metadata further includes a PDU Set Importance (PSI) indication of the PDU Set.

10. The method of any of the preceding claims, wherein: the IP packet is a UDP datagram encapsulating an Hypertext Transfer Protocol (HTTP) datagram and a QUIC packet.

11. The method of claim 10, wherein: the UDP datagram includes a Real-Time Transport Protocol (RTP) extension field, and the QUIC priority information and the QUIC correlated ID are included in the RPT extension field.

12. The method of claim 10, wherein: a header of the HTTP datagram includes (i) a context ID for PDU Set identification, (ii) the QUIC priority information, and (iii) the QUIC correlated ID.

13. The method of any of claims 1-9, wherein: the IP packet is a UDP datagram encapsulating (i) a first HTTP datagram including a first QUIC datagram that contains PDU Set information and (ii) a second HTTP datagram including a second QUIC datagram including an XRM payload.

14. The method of any of claims 1-9, wherein:PATENT APPLICATION Attorney Docket No.: 31730 / 307610-00 the IP packet is a UDP datagram encapsulating a single HTTP datagram including (i) a first QUIC datagram that contains PDU Set information and (ii) a second QUIC datagram including an XRM payload.

15. One or more devices comprising processing hardware and configured to implement a method of any of the preceding claims.

Images