Differentiated handling for downlink encrypted XRM traffic

Abstract

A core network (CN) receives (1280A), from an application server (AS), a User Data Protocol (UDP) packet including (i) a UDP payload and (ii) unencrypted metadata, generates (1281) a Packet Data Unit (PDU) including an outer Internet Protocol (IP) header and the UDP payload, and transmits the PDU to a user equipment (UE) via a radio access network (RAN). To generate the PDU, the CN marks (1281), based on the unencrypted metadata, the PDU by setting a Differentiated Services Code Point (DSCP) field in the outer IP header.

Description

PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 DIFFERENTIATED HANDLING FOR DOWNLINK ENCRYPTED XRM TRAFFIC CROSS-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 / 620,770 entitled “Differentiated Handling for Downlink Encrypted XRM Traffic,” filed on January 12, 2024. The entire content of the provisional application is hereby expressly incorporated herein by reference FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communications and, more particularly, to supporting downlink XRM traffic organized into PDU sets. 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 recently proposed to study support of XR and media (XRM) to provide 5G system (5GS) support of advanced media services, e.g. High Data Rate Low Latency (HDRLL) services, AR / VR / XR services, and tactile / multi-modality communication services. More specifically, the objectives include enhancements of network exposure to support interaction between 5GS and XRM applications, and enhancements of quality-of-service (QoS) and policy for XR services and media service transmissions.PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0006] When supporting XR communications (or, more generally, a data-intensive service), an application executing on a user equipment (UE) can receive or originate a data burst, which can be understood as multiple units, such as Packet Data Unit (PDUs), communicated within a relatively short period of time. A data burst can include or more PDU sets. A PDU set in general includes one or more PDUs carrying the payload of one unit of information generated at the application level (e.g. frame(s) or video slice(s) etc. for XR Services). All PDUs in a PDU set correspond to the same Quality-of-Service (QoS) flow.

[0007] To support XRM services for PDU-set-based handling in a 5GS, the next generation radio access network (NG-RAN) must be aware of XRM services the 5G core network (CN) provides. The NG-RAN receives, from the Session Management Function (SFM) over the N2 interface, PDU set QoS parameters in the QoS profile. The NG-RAN further receives, from a User Plane Function (UPF) via the N3 interface, PDU Set information received for the downlink XRM traffic or, from the UE over Uu interface, PDU Set information for the uplink XRM traffic.

[0008] To support PDU Set based QoS handling for XRM services, a PSA UPF identifies PDUs that belong to PDU Sets and determines the below PDU Set Information, based on the RTP extension header defined in 3GPP TS 26.522 v0.1.1 (2023-08), which the UPF sends to the NG-RAN in the GTP-U header. The NG-RAN uses the PDU Set information is for PDU Set based QoS handling as described in 3GPP TS 23.501. The PDU Set Information includes (i) a PDU Set Sequence Number, (ii) an Indication of End PDU of the PDU Set, (iii) a PDU Sequence Number within a PDU Set, (iv) PDU Set Size in bytes, (v) a PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow. The NG-RAN may use the Priority Level across QoS Flows and PDU Set Importance within a QoS Flow for PDU Set level packet discarding in presence of congestion.

[0009] Currently, networks often use end-to-end encryption to provide security and the same is expected for XR and Media (XRM) applications. However, a UPF in a 5G network cannot perform PDU Set identification as indicated in 3GPP TS 23.501, 23.502, 23.503, or 26.522 for example based on an end-to-end encrypted traffic in which media packet header information (necessary for PDU Set identification) is partially or fully encrypted.

[0010] One example of end-to-end encryption of media traffic is the use of real-time transport protocol (RTP) over Quick UDP Internet Connections (QUIC), which allows encapsulation ofPATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 RTP packets within QUIC packets and transmission via QUIC streams and datagrams to transport real-time data within a QUIC connection for a specific Internet Protocol (IP) 5 tuple.

[0011] Currently, applications map one media service data flow to one QoS Flow, and all transporting packets associated with the same QoS Flow receive the same transport level marking (i.e. have the same DSCP marking). In other words, transport-level packets carrying PDU Sets with different PSI values for example receive the same treatment in the transport network, because these packets have the same DSCP value in the outer IP header. There is no differentiated handling of transport-level packets carrying PDU Sets within a QoS Flow in 5G network. It is however desirable to use PDU Set QoS information for DSCP marking in an outer header of a downlink packet of a PDU Set over the N3 and N9 interfaces in the transport network, to enable differentiated handling of transport packets carrying PDU Sets within a QoS flow.

[0012] 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 v0.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. However, end-to-end encryption of XR and Media (XRM) applications prevents the UPF from performing PDU Set identification indicated in per TS 23.50, 23.502, 23.503, or 23.522. Thus, it is unclear how a core network can provide differentiated handling of transport layer packets carrying PDU Sets within a QoS flow for end-to-end encrypted traffic, in the downlink direction. SUMMARY

[0013] An example embodiment of the techniques of this disclosure is a method implemented in a core network (CN). The method comprises receiving, from an application server (AS), a User Data Protocol (UDP) packet including (i) a UDP payload and (ii) unencrypted metadata; generating a Packet Data Unit (PDU) including an outer Internet Protocol (IP) header and the UDP payload, the generating including: marking, based on the unencrypted metadata, the PDU by setting a Differentiated Services Code Point (DSCP) field in the outer IP header; and transmitting the PDU to a user equipment (UE) via a radio access network (RAN).PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0014] A core network (CN) node comprising processing hardware and configured to implement a method of any of the preceding claims. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0016] 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;

[0017] 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;

[0018] 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;

[0019] Fig.5 is a high-level messaging diagram of an example scenario in which a UE uses establishes and modifies a PDU session;

[0020] Fig.6 illustrates an example IP packet which an application server (AS) can send to a UPF over the N6 interface;

[0021] Fig.7 illustrates another example IP packet which an application server (AS) can send to a UPF over the N6 interface, using RTP and QUIC protocols;

[0022] Fig.8 illustrates another example IP packet enclosing a UDP packet with a UDP- option format;

[0023] Fig.9 illustrates an example transport-layer packet enclosing RTP packets from an AS, which a UPF can generate for transmission to a UE;

[0024] Fig.10 is a block diagram of an example system in which a UPF receives a IP packet enclosing a QUIC packet, generates a PDU with an outer IP header and a GTP-U header based on the metadata in the received IP packet, and transmits the PDU to the UE for use by an XRm application;PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0025] Fig.11 is a messaging diagram of an example scenario in a core network processes downlink XRM traffic in view of PDU Set parameters;

[0026] Fig.12A is a flow diagram of an example method in a UPF for receiving a UDP packet and generating a PDU a DSCP field based on the unencrypted metadata in the UDP packet;

[0027] Fig.12B is a flow diagram of an example method in a UPF for detecting and a UDP packet related to a PDU Set and applying a rule for DSCP marking;

[0028] Fig.12C is a flow diagram of an example method in a UPF for DSCP marking, when the UDP packet includes a PSI value;

[0029] Fig.12D is a flow diagram of an example method in a UPF for DSCP marking, when the UDP packet does not include a PSI value;

[0030] Fig.13 is a flow diagram of an example method in an application server (AS) for generating a UDP packet with unencrypted metadata;

[0031] Fig.14A is a flow diagram of an example method in a Session Management Function (SMF) for generating DSCP assistance information for the UE, in view of whether the metadata in the IP flow includes a PSI; and

[0032] Fig.14B is a flow diagram of an example method in an SMF for generating a packet detection rule (PDR), a QoS enforcement rule (QER), and a forwarding action rule (FER) for the UPF. DETAILED DESCRIPTION OF THE DRAWINGS

[0033] As discussed in more detail below, the core network of a wireless communication system provides differentiated handling for transporting downlink encrypted XRM traffic.

[0034] Referring first to Fig.1, an example wireless communication system 100 can implement one or more of the techniques of this disclosure for supporting PDU Set based handling of downlink traffic, particularly encrypted downlink XRM traffic. The example wireless communication system 100 includes a UE 102, 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 RAN 105 in some implementations supports XRM services capabilities for PDU Set handling. In otherPATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 implementations, however, the RAN 105 does not support XRM services capabilities for PDU Set handling. The CN 110 can also be implemented as a sixth generation (6G) core or another suitable core network.

[0035] 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., S1 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.

[0036] 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 a downlink (DL) PDU Set Controller for XRM traffic 112, which generates PDUs and transport-layer parameters related to downlink PDU Set based handling for XRM traffic. The RAN 105

[0037] 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 special- purpose processing units. The processing hardware may be configured to implement the techniques of this disclosure for enabling 5GS support of advanced media services.

[0038] The UE 102A is equipped with processing hardware 130 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, and / or special-purpose processing units. The UE 102A also includes a transceiver 132 to communicatePATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 with the RAN 105 over a radio interface. Further, the UE 102A includes a memory 134 storing a PDU set controller 140. An example XRM application 142 can use the PDU set controller 140A to operate on PDU sets. For example, the application 142 can set an RTP header to utilize PDU Set based processing. The UE 102B can have a similar implementation.

[0039] The base station 106 is equipped with processing hardware 160 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, and / or special-purpose processing units. The base station 106 also includes a transceiver 161 to communicate with the UEs over a radio interface. Further, the base station 106 includes a memory 164 storing a PDU Set controller 162. The base station 104 can have a similar implementation.

[0040] In operation, the DL PDU Set Controller for XRM traffic 112 receives UDP packets including XRM traffic from an XR data server 150 and, using the unencrypted metadata in the UDP packets, generates PDUs for the UE 102 using the techniques discussed in detail with reference to Figs.6-14B.

[0041] Fig.2 illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB / ng-eNB or a gNB (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 204A, 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 RLC 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 102, 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 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

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

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

[0044] Fig.3 is a service-based representation 300 of the 5GS architecture, which the system of Fig.1A can implement. According to 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. An application server (AS) 331 operates in the DN 330. The AS 331 can be for example the XR data server 150 illustrated in Fig.1.

[0045] 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) 357, a Policy Control Function (PCF) 360, a Charging FunctionPATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 (CHF) 362, an Access & Mobility Management Function (AMF) 364, a Session Management Function (SMF) 366, and a User Plane Function (UPF) 370.

[0046] In one example implementation, the SMF 366 implements a component 112A of the PDU Set Controller for XRM traffic 112, and the UPF 370 implements a component 112B of the PDU Set Controller for XRM traffic 112. The CN 110 in various implementations can include only the component 112A, only the component 112B, or both.

[0047] Fig.4 is a reference-point based representation 400 of the 5GS architecture. In Fig.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.

[0048] Referring to a scenario 500 of Fig.5, during the registration procedure, the AMF 364 determines 501 whether the UE 102 is authorized to use XRM services, based on the XRM Service Capability of the UE and the XRM Service Authorization included in the subscription data received from UDM as specified in TS 23.501 clause 5.7. After successful registration, the UE 102 requests 511 for PDU Session Establishment procedure and the RAN capable of XRM services can perform PDU Set handling for the QoS flows in a PDU session based on the XRM service authorization and information received from the SMF via N2 message and GTP-U header via N3 interface from the UPF. The PDU Session Establishment Procedure can be implemented as described in TS23.502 clause 4.3.2.2. The UE 102 or the network can initiate 521 PDU Session Modification Procedure for the existing PDU Session. The PDU Session Modification Procedure can be implemented as described in TS23.502 clause 4.3.3.2 and 4.3.3.3. The UE 102 may repeat procedure 511 for multiple PDU sessions which are associated with the same or different data network names (DNNs) and Single – Network Slice Selection Assistance Information (S-NSSAI).

[0049] When the PLMN provides homogeneous RAN support of PDU set based handling, the procedure 500 can be applied with the following enhancement for supporting PDU set based QoS: PCF: provides PCC rules for an application service flow as defined in clause 6.1.3.27.4 of TS 23.503 that includes PDU Set QoS parameters (PSER, PSDB and PSIHI) and Protocol Description.PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0050] The SMF determines a QoS Profile for the QoS flow, which is based on received PCC rules or pre-configuration. The PSA UPF performs the following: (i) identifies PDUs that belong to PDU Sets based on Protocol Description based on received PDR (Packet Detection Rule), (ii) marks the GTP-U header for PDU Set information as described in TS23.501 clause 5.37.5.2, (iii) and performs PDU set based parameters based on received QER (QoS Enforcement Rule).

[0051] The network instructs the UE with uplink PDU Set based handling information to perform PDU set based handling including PDU Set identification and marking on the uplink media service data flow received from upper layer to provide the RAN with in-band uplink PDU Set information.

[0052] Next, several example formats of a packet are discussed with reference to Figs.6-10.

[0053] First, Fig.6 illustrates an 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,

[0054] An IP packet 601 includes an IP header 610 and a UDP diagram that in turn includes a UDP header 612, a UDP payload 614, and UDP-option 616. The UDP payload 614 can encapsulate a QUIC packet. In an example implementation, the UDP-option 616 includes metadata with the necessary RTP session information for mapping to the QUIC stream. The UPF 370 can use the UDP-option 616 for PDU Set based identification.

[0055] The UDP payload 614 can include a QUIC packet 622 of a QUIC stream 620 with a certain QUIC connection. An RTP session 602 in this example includes the single QUIC stream 620. The QUIC packet 622 includes a QUIC header 630 and a QUIC payload 632, 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.6, the QUIC payload 632 includes a single RPT packet including an RTP header and an RTP payload.

[0056] As illustrated in Fig.7, a QUIC packet in general can encapsulate more than one RTP packet with the same QUIC connection and RTP session properties. An IP packet 701 includes an IP header 710 and a UDP diagram with a UDP header 712, a UDP payload 714, and UDP- option 716. The UDP payload 714 encapsulates a QUIC packet 722 that includes a QUIC headerPATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 730 and a QUIC payload 732, which encapsulates multiple RPT packets 740A, 740B, etc. This approach reduces overhead associated with RTP transmissions.

[0057] The QUIC packet 722 can encapsulate multiple RTP packets 740A, 740B, etc., with the shared QUIC connection and shared one or more RTP session properties such as media frame type (e.g. I / P / B type), QUIC connection and QUIC stream, PDU Set, data burst, or PDU Set importance.,

[0058] Different synchronous QUIC streams can carry RTP packets with different media frame type, e.g. I / P / B type. For example, I-media frames can travel in a QUIC stream #A, P- media frames can travel in a QUIC stream #B, and B-media frames can travel in a QUIC stream #C. The QUIC streams ##A- C can belong to a common QUIC connection that shares the same IP 5 tuples.

[0059] Fig.8 illustrates an IP packet 801 that includes an IP header 810 and a UDP diagram that in turn includes a UDP header 812, a UDP payload 814, and UDP-option 816. The UDP- option 816 includes a UDP-option header 817 and a UDP-option payload 818, so that another transport layer protocol can use the UDP payload as the encapsulation layer (e.g., QUIC over UDP, RTP over UDP, RTP over QUIC).

[0060] The UDP-Option header 817 can include for example a payload type to indicate the format of the metadata payload. For example, the payload type can indicate the encapsulation layer protocol specific to the UDP payload, e.g. QUIC, RTP, or both (QUIC over RTP). The UDP-Option header 817 also can include an extension bit to indicate the presence of an extension header between the UDP-Option header and UDP-Option payload data. The extension header can be application- or profile- specific. The UDP-Option header 817 can further include an optional header extension.

[0061] Next, several approaches to differentiated handling of downlink XRM traffic is discussed with reference to Figs.9-11.

[0062] As illustrated in Fig.9, a UPF such as the UPF 370 can generate a transport layer packet 950, which is a PDU 350 within a certain QoS flow, based on the IP packet 901 from the AS 331. The IP packet 901 includes an IP header 910 and a UDP diagram including UDP header 912 and a UDP payload 914, but does not include a UDP-option field. The UDP payloadPATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 914 includes an RTP packet 940 associated with an RTP session 905. The RTP packet 940 includes an RPT header 941 and an RTP payload 942, such an I / P / B frame 910. The UPF according to the approach of Fig.9 can generate an IP packet 901A based on the RTP packet 940 and generate an outer IP header 952 and a GTP-U header 953 of the transport layer packet 950, to enclose an inner IP packet 901B corresponding to the IP packet 901A. The UDP payload 914 can be unencrypted in the scenario of Fig.9, and the UPF can generate the outer IP header 952 and a GTP-U header 953 based on the UDP payload 914 (e.g., using the RTP header 941).

[0063] On the other hand, according to the approach 1000 illustrated in Fig.10, the UPF 370 can use the metadata included in an IP packet 1001 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 can 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).

[0064] The UPF 370 then can set the DSCP bits in an outer IP header 1052 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.

[0065] 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 1001 is unencrypted, or on the unencrypted metadata included in UDP-Option (regardless of whether the IP payload of the IP packet 1001 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 XRMPATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 traffic is encrypted, the UPF 370 can obtain the PDU Set Information from the UDP-Option field.

[0066] More particularly, as illustrated in Fig.10, the UPF 370 receives downlink XRM traffic from the AS 331 via an N6 interface, marks the DSCP bits in the outer IP header 1052 of the PDU 1051 within the corresponding QoS flow and generates a GTP-U header 1053. The encrypted QUIC packet and the unencrypted metadata in the IP packet 1001 define a GTP-U packet. The UPF 370 forwards the PDU 1051 including the out IP header 1052, the GTP-U header 1053, and the IP packet 1001 to the RAN 105.

[0067] The transport layer router (not shown) operating in CN 110 can prioritize the downlink XRM traffic delivery based on DSCP bits marked in the outer IP header of the PDU 1051.

[0068] An XRM application executing on the AS 331 can transmit the downlink XRM traffic using one or more components of the traffic descriptions: IP flows, QUIC connections, or QUIC streams. The AS 331 can include some or all of the parameters in the unencrypted metadata, so as inform the UPF 370 about the encrypted QUIC packet of the downlink XRM traffic: (i) a downlink QUIC session correlation (QSC-ID) generated for an IP flow, a QUIC connection, or and a QUIC stream; (ii) the priority of the QUIC session, which can be unique for an XRM application, where the 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; (iii) one or more of downlink PDU Set information parameters included in the RTP Extension header of the RTP packets encapsulated in the encrypted QUIC packet. For a PDU in a certain PDU Set, the downlink PDU Set information parameters can include a PDU Set Sequence Number, an indication that the PDU is the End (last) PDU in the PDU Set, a PDU Sequence Number within the PDU Set, the size of the PDU Set in bytes, or the PDU Set Importance (PSI), which indicates the relative importance of the PDU Set com-pared to other PDU Sets within a QoS Flow

[0069] The same UDP datagram can encapsulate unencrypted metadata in the UDP-Option and partially encrypted XRM traffic in the UDP payload when, for example, the AS 331 uses RTPcryptex over UDP. In another implementation, the same UDP datagram encapsulates unencrypted metadata in the UDP-Option and fully encrypted XRM traffic in the UDP payload when, for example, the AS 331 includes a QUIC packet in the UPD payload as illustrated in Fig. 6. The XRM application executing on the AS 331 thus can generate metadata and include thePATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 metadata in the UDP-Option filed to indicate certain information about the encrypted QUIC packet.

[0070] Several example techniques for generating and processing IP packets with DL XRM traffic are discussed next with reference to Figs.11-14B. Generally speaking, events in Figs.11- 14B that are similar are labeled with similar reference numbers (e.g., event 1132 of Fig.11 is similar to block 1232, event 1180 of Fig.11 is similar to block 1280A of Fig.12A and block 1280C of Fig.12C), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures.

[0071] Fig.11 illustrates an example scenario 1100 for processing downlink XRM traffic in view of PDU Set parameters.

[0072] Generally speaking, an XRM application at the AS 331 provides downlink XRM traffic information, and the UPF 370 enables differentiated handling for transporting downlink XRM traffic by marking DSCP bits in the outer IP header of a PDU based on received DSCP assistance information and downlink XRM traffic information from the SMF 366. To support differentiated handling for transporting downlink XRM traffic, the SMF 366 (i) obtains downlink XRM traffic information from the AS 331 via the PCF 360 and the NEF 354, which receive an AF request including downlink XRM traffic information from the AF 358, (ii) binds QoS flows based on the PCC rule including downlink XRM traffic information, (iii) determines the DSCP assistance information based on the downlink XRM traffic information, and (iv) sends DSCP assistance information to the UPF 370 via an N4 message. Using (i) the downlink XRM traffic information included in the N4 message from SMF 366 (control plane) and (ii) the metadata information related to downlink encrypted XRM traffic received from the AS 331 via the N6 interface (user plane), the UPF 370 can perform downlink PDU Set based QoS handling for the downlink QoS flow enabled differentiated handling for transporting downlink XRM traffic.

[0073] The scenario 1100 begins with the XRM application 142 at the UE 102 and the AS 331 exchanging 110 downlink XRM traffic information. The AS 331 then sends 1115 downlink XRM traffic information to AF 358. The AF 358 sends 1120 an AF request message including downlink XRM traffic information to the CN 110. Depending on the particular scenario, the AFPATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 request can include an Nnef_AFsessionWithQoS_Create message or an Nnef_AFsessionWithQoS_Update message, per the procedure described in TS 23.502, clause 4.15.6.6.

[0074] According to one implementation, the AF request the AF 358 sends to the CN 110 includes downlink XRM traffic information with one or more of the following sets of parameters: (i) a Traffic Description that indicates IP flow information for the downlink XRM traffic, e.g. IP 5 tuples; (ii) Protocol Description information that indicates the use of the transport layer protocol for the downlink XRM traffic, e.g. QUIC, QUIC+RTP (RTP over QUIC), RTP over UDP with UDP-Option, etc.; (iii) a downlink QSC-ID generated based on one or more components of the Traffic Description: 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 an QoS flow; and (iv) the priority of the QUIC session identified by the QSC-ID, which is unique within the XRM application. For example, 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.

[0075] The SMF 366 receives 1130 a PCC rule including downlink XRM traffic information (e.g., as discussed above) from the PCF 360 directly or via the NEF 354. Based on the PCC rules, the SMF 366 can bind downlink XRM traffic to one or more QoS flow identified by the QoS flow ID, determine DSCP assistance information to enable or disable differentiated handling using transport level marking, and determine N4 session configuration including PDR, FAR, and QER. Example approaches according to which the SMF 366 can instruct 1132 the UPF 370 with N4 Session Configuration is considered next.

[0076] The SMF 366 can determine to enable differentiated transport level handling across one or more QoS flow(s) for downlink XRM traffic in the CN 110 by providing N4 session configuration information to the UPF 370 (and intermediate UPF(s)) via the N4 interface, after performing QoS flow binding based on the PCC rule(s) received from the PCF 370. To generate the N4 session configuration information, the SMF 366 can determine a PDR including an extended packet filter referencing the QSC-ID to handle encrypted XRM traffic based on unencrypted metadata. The UPF 370 accordingly can detect a PDU based on a UDP datagram to obtain the unencrypted metadata from the UDP-Option. Further, the SMF 366 can determine aPATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 QER including a DSCP marking indicator to enable or disable differentiated handling for transporting XRM traffic based on the marking of the outer IP header with DSCP bits, according to the FAR. Still further, the SMF 366 can determine the FAR including DSCP assistance information for unencrypted XRM traffic and / or encrypted XRM traffic.

[0077] For example, when the UPF 370 receives 1132 downlink XRM traffic information and DSCP assistance information from the SMF 366 in an N4 message, the UPF 370 can “dissect” the UDP datagram to retrieve the (unencrypted) metadata from UDP-Option and identify, based on a matched QSC-ID included in the extended packet filter set in the PDR, a QUIC session. Based on the FAR with the DSCP assistance information and the QER with the DSCP marking indicator, for the matched QUIC session based on the PDR, the UPF 370 can mark the DSCP bit in the outer IP header of the identified PDU according to the priority value indicated in the metadata.

[0078] In some implementations, the N4 session configuration information includes a PDR, an FAR, and a QER with the following parameters. 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, and (iii) an extended packet filter set based on the unencrypted metadata in the UDP-Option payload of the UDP datagram (see Fig.8). The extended packet filter set can be a new set defined specifically for the purposes of supporting QSD-IDs in the UDP-Option field. The extended packet filter set includes 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.

[0079] The FAR can include DSCP assistance information, which can include a mapping list of PSI values and the corresponding DSCP values for the unencrypted XRM traffic, or encrypted XRM traffic with unencrypted metadata including PSI. Thus, an entry in the mapping list specifies the mapping of a certain PSI value to a DSCP value. Alternatively or additionally, the DSCP assistance information can include a mapping list of priority values of a QUIC session and the corresponding DSCP values, applicable to the encrypted XRM traffic and unencrypted metadata without PSI.PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0080] The SMF 366 can generate 1130 the DSCP assistance information that provides, for unencrypted XRM traffic or encrypted XRM traffic with unencrypted metadata including PSI, a list that maps PSI values to respective DSCP values. For encrypted XRM traffic and unencrypted metadata without PSI, the DSCP assistance information provides a list that maps QUIC session priorities to respective DSCP values. The metadata in the DL XRM traffic can indicate the priority of the QUIC session.

[0081] Alternatively, for encrypted XRM traffic and unencrypted metadata without PSI, the DSCP assistance information can provide a list that maps QSC-IDs to respective DSCP values. The QSC-ID can correspond to one or more components of traffic description such as an IP flow, a QUIC connection, or a QUIC stream. As one example, an XRM application can use different IP flows (represented by different respective IP 5 tuples) for different QUIC connections, each QUIC connection contains only one QUIC stream, and the AS 331 and / or the UE 102 generate a QSC-ID per an IP flow. As another example, an XRM application uses the same IP flow (represented by IP 5 tuples) for all QUIC connections, each QUIC connection contains only one QUIC stream, and the AS 331 and / or the UE 102 generate the QSC-ID per a QUIC connection. As yet another example, an XRM application uses the same IP flow (represented by IP 5 tuples) for all QUIC connections, each QUIC connection contains only one QUIC stream, and the AS 331 and / or the UE 102 generate the QSC-ID per a QUIC connection. As another example, an XRM application uses a different IP flow (represented by IP 5 tuples) for a different set of QUIC connections, each QUIC connection contains only one QUIC stream, and the AS 331 and / or the UE 102 generate the QSC-ID per an IP flow and a QUIC connection. As still another example, an XRM application uses a different IP flow (represented by IP 5 tuples) for a different set of QUIC connections, each QUIC connection contains more than one QUIC stream, and the AS 331 and / or the UE 102 generate the QSC-ID per an IP flow, a QUIC connection, and a QUIC stream.

[0082] 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 marking indicator that instructs the UPF 370 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 partially or fully encrypted XRM traffic.PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0083] Thus, the SMF 366 can instruct 1132 the UPF 370, via an on N4 session configuration, with a QER with a PDU Set Information marking indicator to instruct the UPF 370 to insert PDU Set Information for an identified PDU in a PDU Set into a GTP-U header, and the PDU Set Information can be in an RTP extension header for unencrypted XRM traffic or in the metadata included in the UDP-Option for partially or fully encrypted XRM traffic.

[0084] With continued reference to Fig.11, the SMF 366 transmits 1144, to the RAN 105, an N2 message including N2 SM information, which in turn includes QoS profiles(s) for the QoS flow(s) of the downlink XRM traffic. The SMF 366 can send 1144 the N2 message to via the AMF 364.

[0085] The SMF 366 transmits 1170, to the UE 102, N1 SM information including QoS rules(s) for the QoS flow(s) of the downlink XRM traffic. The SMF 366 can transmit 1170 the N1 SM information in a NAS message, via the AMF 364.

[0086] The UPF 370 receives 1172, over the N6 interface, downlink XRM traffic to which the AS 331 adds metadata in the UDP-Option at UDP datagram encapsulated in QUIC packet in the downlink XRM traffic. The UPF 1180 detects 1180 the packets associated with PDU sets, marks the GTP-U header with the PDU Set information based on the metadata, and performs DSCP marking on the outer header of the downlink XRM traffic based on the metadata (at the user plane) and the DSCP assistance information (at the control plane). Using the DSCP bits in the IP header of a PDU, the transport network in the CN 110 prioritizes 1196 the XRM traffic.

[0087] The RAN 105 receives 1196 the downlink XRM traffic from the UPF 370 over the N3 interface. The RAN 105 performs 1197 downlink PDU Set based QoS handling, e.g. performs packet scheduling based on the PDU Set information marked in the GTP-U header, drops packets based on the PSI value marked in the GTP-U header for the encrypted or unencrypted XRM traffic, and performs 1197 QoS flow(s) mapping to DRB(s).

[0088] The RAN 105 then transmits 1198, to the UE 102, downlink XRM traffic. To this end, the RAN 105 maps the DRB(s) to the QoS flow(s) based on QoS rule(s) provisioned by the SMF 366. The RAN 105 then transmits 1198 the downlink XRM traffic in the DRB(s) of the QoS flow(s).PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0089] In another implementation, the AS 331 (rather than the SMF 366) determines DSCP assistance information based on PCC rules including downlink XRM traffic information, and transmits the DSCP assistance information to the UPF 370. According to this approach, the DSCP assistance information can provide, for unencrypted XRM traffic or encrypted XRM traffic with unencrypted metadata including PSI, a mapping list of PSI values and the corresponding DSCP values. For encrypted XRM traffic and unencrypted metadata without PSI, entries in the mapping list specify the mapping of a priority of a QUIC session to a DSCP value, when the metadata of the encrypted XRM traffic includes the priority of the QUIC session. Alternatively, an entry in the mapping list specifies the mapping of a QSC-ID to a DSCP value. The QSC-ID can correspond to one or more components of the traffic description such as an IP flows, a QUIC connections, and a QUIC stream.

[0090] Next, Fig.12A illustrates example method 1200 implemented in a UPF (e.g., the UPF 370) for receiving a UDP packet and generating a PDU a DSCP field based on the unencrypted metadata in the UDP packet. At block 1232, the UPF obtains DSCP assistance information related to a downlink IP flow. At block 1280A, the UPF receives a UDP packet with a UDP payload, which may be encrypted, and unencrypted metadata. At block 1281, the UPF generates a PDU with the UPD payload, and assign a DSCP value based on the obtained DSCP assistance information (i.e., control-plane information) and the unencrypted metadata in the UDP packet (i.e., user-plane data).

[0091] Fig.12B illustrates an example method 1282 in a UPF for detecting and a UDP packet related to a PDU Set and applying a rule for DSCP marking. The UPF can perform the method 1282 as a part of executing block 1281 of Fig.12A, for example. At block 1283, the UPF applies an extended packet filter according to a PDR, to detect a PDU with encrypted XRM traffic and unencrypted metadata matching the QSC-ID. At block 1284, the UPF detects a DSCP marking indicator in the relevant QER. At block 1285B, the UPF marks the PDU by setting the DSCP bits according to the DSCP assistance information in the relevant FAR.

[0092] Fig.12C illustrates an example method 1200C implemented in UPF for DSCP marking, when the UDP packet includes a PSI value. At block 1280C, the UPF receives a UDP packet with XRM traffic, which can be nonencrypted, partially encrypted, or fully encrypted, andPATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 unencrypted metadata including a PSI. At block 1285C, the UPF applies DSCP assistance information that maps one or more PSI values to respective DSCP values.

[0093] Fig.12D is a flow diagram of an example method 1200D in a UPF for DSCP marking, when the UDP packet does not include a PSI value. At block 1280D, the UPF receives a UDP packet with encrypted XRM traffic and unencrypted metadata without a PSI. At block 1290, the UPF determines whether the metadata indicates the priority of a QUIC session and, if so, the flow proceeds to block 1291. Otherwise, if the metadata does not indicate the priority of a QUIC session, the flow proceeds to block 1292. At block 1291, the UPF applies DSCP assistance information that maps one or more QUIC session priorities to respective one or more DSCP values. At block 1292, the UPF applies DSCP assistance information that maps one or more QSC-ID values to respective one or more DSCP values.

[0094] Next, Fig.13 illustrates an example method 1300 implemented in an AS (such as the AS 331) for generating a UDP packet with unencrypted metadata. The AS performs one or more of block 1321A (to include a traffic description in DL XRM traffic information), block 1321B (to include a protocol description in DL XRM traffic information), block 1321C (to include a DL QSC-ID in DL XRM traffic information), or block 1321D (to include priority of a QUIC session in DL XRM traffic information). At block 1322, the AS generates DL XRM traffic information. At block 1320, the AS sends, to the CN, an AF request messaging including the DL XRM traffic information.

[0095] Fig.14A illustrates an example method 1400A, which can be implemented in an SMF for generating DSCP assistance information for the UE, in view of whether the metadata in the IP flow includes a PSI. At block 1401, the SMF receives, from a PCF, one or more PCC rules including DL XRM traffic information. At block 1430, the SMF determines, based on the PCC rules, DSCP assistance information. At block 1435, the SMF determines whether the unencrypted metadata in the IP flow includes a PSI. If yes, the flow proceeds to block 1436, where the UPF generates DSCP assistance information that maps PSI values to respective DSCP values. Otherwise, the flow proceeds to block 1437, where the UPF generates DSCP assistance information that maps QUIC session priorities to respective DSCP values. The flow proceeds from block 1436 or block 1437 to block 1432, where the SMF transmits the DSCP assistance information to the UPF.PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0096] Finally, Fig.14B illustrates an example method 1400B in an SMF for generating a PDR, a QER, and a FAR for the UPF. At block 1451, the SMF generates a PDR including an extended packet filter for detecting a PDU with encrypted XRM traffic and unencrypted metadata matching a QSC-ID. At block 1452, the SMF generates a QER including a DSCP marking indicator. At block 1453, the SMF generates a DRA including DSCP assistance information, for marking a PDU by setting the DSCP bits.

[0097] The following list of examples reflects a variety of the embodiments explicitly contemplated by the present disclosure:

[0098] Example 1. A method implemented in a core network (CN), the method comprising: receiving, from an application server (AS), a User Data Protocol (UDP) packet including (i) a UDP payload and (ii) unencrypted metadata; generating a Packet Data Unit (PDU) including an outer Internet Protocol (IP) header and the UDP payload, the generating including: marking, based on the unencrypted metadata, the PDU by setting a Differentiated Services Code Point (DSCP) field in the outer IP header; and transmitting the PDU to a user equipment (UE) via a radio access network (RAN).

[0099] Example 2. The method of example 1, further comprising retrieving the unencrypted metadata from a UDP-option field of the UDP packet.

[0100] Example 3. The method of example 1 or 2, wherein the UDP payload includes a Quick UDP Internet Connections (QUIC) packet.

[0101] Example 4. The method of any of examples 1-3, further comprising: determining, based on the unencrypted metadata, that the UDP payload is associated with a PDU Set.

[0102] Example 5. The method of any of the preceding examples, wherein the unencrypted metadata includes PDU Set Importance (PSI).

[0103] Example 6. The method of example 3 or 4, wherein the unencrypted metadata includes a QUIC session id (QSC-ID).

[0104] Example 7. The method of example 6, wherein the QSC-ID identifies an IP flow corresponding to a single QUIC connection, the QUIC connection including a single QUIC stream.PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0105] Example 8. The method of example 6, wherein the QSC-ID identifies one of a plurality of QUIC connections associated with a same IP flow, the one of a plurality of QUIC connections including a single UIC stream.

[0106] Example 9. The method of example 6, wherein the QSC-ID identifies an IP flow and one of a plurality of QUIC connections included in the IP flow.

[0107] Example 10. The method of example 6, wherein the QSC-ID identifies an IP flow, one of a plurality of QUIC connections included in the IP flow, and one of a multiplicity of QUIC streams included in the one of the plurality of QUIC connections.

[0108] Example 11. The method of any of examples 6-10, wherein the unencrypted metadata further includes an indication of a priority corresponding to the QSC-ID.

[0109] Example 12. The method of any of the preceding examples, wherein the UDP payload is at least partially encrypted.

[0110] Example 13. The method of example 2 implemented in a User Plane Function (UPF), the method further comprising: receiving DSCP assistance information; wherein the marking of the PDU includes using the DSCP assistance information.

[0111] Example 14. The method of example 13, wherein the DSCP assistance information is received from a Session Management Function (SMF).

[0112] Example 15. The method of example 13, wherein the DSCP assistance information is received from the AS.

[0113] Example 16. The method of any of examples 13-15, wherein the DSCP assistance information includes a mapping of one or more PDU Set Importance (PSI) values to a respective one or more DSCP values.

[0114] Example 17. The method of any of examples 13-15, wherein the DSCP assistance information includes a mapping of one or more QUIC session priority values to a respective one or more DSCP values.

[0115] Example 18. The method of any of examples 13-17, further comprising receiving an N4 session configuration; wherein the marking of the PDU includes using the N4 session configuration.PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0116] Example 19. The method of example 18, wherein the N4 session configuration includes a Packet Detection Rule (PDR) including an extended packet filter set based on the unencrypted metadata; and identifying the PDU for the marking includes applying the extended packet filter.

[0117] Example 20. The method of example 18 or 19, wherein the N4 session configuration includes a Forwarding Action Rule (FAR); and the marking of the PDU includes setting one or more bits of the DSCP field according to the FAR.

[0118] Example 21. The method of example 20, wherein the N4 session configuration includes a QoS Enforcement Rule (QER) with a DSCP marking indicator; and the marking of the PDU includes applying the FAR according to the DSCP marking indicator.

[0119] Example 22. The method of any of the preceding examples, wherein the setting of the DSCP field includes assigning, to the PDU, a transport priority in a transport network of the CN.

[0120] Example 23. The method of any of the preceding examples, wherein the generating of the PDU further includes: generating a GPRS Tunneling Protocol User (GTP-U) header; and including the GTP-U header in the PDU.

[0121] Example 24. The method of example 23, wherein the generating of the GTP-U header includes: retrieving, from the unencrypted metadata, PDU Set Information; and marking the GTP-U header with the PDU Set Information.

[0122] Example 25. The method of example 24, wherein the PDU Set Information indicates at least one of: (i) a PDU Set sequence number, (ii) an End PDU; (iii) a sequence number within the PDU Set; or (iv) a size of the PDU Set.

[0123] Example 26. The method of any of the preceding examples, wherein the UDP packet is received from the AS via an N6 interface.

[0124] Example 27. The method of any of the preceding examples, wherein the PDU is transmitted via an N3 interface.

[0125] Example 28. The method of any of examples 13-17, wherein the DSCP assistance information is received via an N4 interface or an N6 interface.PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00

[0126] Example 29. The method of any of examples 1-5, further comprising: receiving, from an application function (AF), an AF request including downlink Extended Reality and Media service (XRM) traffic information for an IP flow to which the UDP packet belongs, wherein the marking of the PDU is further based on the downlink XRM traffic information.

[0127] Example 30. The method of example 29, wherein the AF request includes an Nnef_AFsessionWithQoS_Create request message.

[0128] Example 31. The method of example 29, wherein the AF request includes an Nnef_AFsessionWithQoS_Update request message.

[0129] Example 32. The method of any of examples 29-31, wherein the AF request is received a Policy Control Function (PCF).

[0130] Example 33. The method of any of examples 29-32, wherein the downlink XRM traffic information includes one or more of: (i) a traffic description including a set of IP 5 tuples; (ii) a protocol description information; (iii) a QSC-ID; or (iv) a priority of a QUIC session corresponding to the QSC-ID.

[0131] Example 34. A core network (CN) node comprising processing hardware and configured to implement a method of any of the preceding examples.

[0132] 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 internet-of-things (IoT) 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.

[0133] 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, or machine-readablePATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 instructions 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 configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) 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 configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0134] 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.”

[0135] 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. The software can be executed by one or more general-purpose processors or one or more special- purpose processors.

[0136] Upon reading this disclosure, those of skill in the art will appreciate still additional and alternative structural and functional designs for handling mobility between base stations through the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those of ordinary skill in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein.

Claims

PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 CLAIMS:

1. A method implemented in a core network (CN), the method comprising: receiving, from an application server (AS), a User Data Protocol (UDP) packet including (i) a UDP payload and (ii) unencrypted metadata; generating a Packet Data Unit (PDU) including an outer Internet Protocol (IP) header and the UDP payload, the generating including: marking, based on the unencrypted metadata, the PDU by setting a Differentiated Services Code Point (DSCP) field in the outer IP header; and transmitting the PDU to a user equipment (UE) via a radio access network (RAN).

2. The method of claim 1, further comprising: retrieving the unencrypted metadata from a UDP-option field of the UDP packet.

3. The method of claim 1 or 2, wherein the UDP payload includes a Quick UDP Internet Connections (QUIC) packet.

4. The method of any of claims 1-3, further comprising: determining, based on the unencrypted metadata, that the UDP payload is associated with a PDU Set.

5. The method of any of the preceding claims, wherein: the unencrypted metadata includes PDU Set Importance (PSI).

6. The method of claim 3 or 4, wherein the unencrypted metadata includes a QUIC session id (QSC-ID).

7. The method of any of the preceding claims, wherein the UDP payload is at least partially encrypted.

8. The method of claim 2 implemented in a User Plane Function (UPF), the method further comprising:PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 receiving DSCP assistance information; wherein the marking of the PDU includes using the DSCP assistance information.

9. The method of claim 8, wherein the DSCP assistance information includes: a mapping of one or more PDU Set Importance (PSI) values to a respective one or more DSCP values.

10. The method of claim 8, wherein the DSCP assistance information includes: a mapping of one or more QUIC session priority valuess to a respective one or more DSCP values.

11. The method of any of claims 8-10, further comprising: receiving an N4 session configuration; wherein the marking of the PDU includes using the N4 session configuration.

12. The method of claim 11, wherein: the N4 session configuration includes a Packet Detection Rule (PDR) including an extended packet filter set based on the unencrypted metadata; and identifying the PDU for the marking includes applying the extended packet filter.

13. The method of any of the preceding claims, wherein the generating of the PDU further includes: generating a GPRS Tunneling Protocol User (GTP-U) header; and including the GTP-U header in the PDU.

14. The method of claim 13, wherein the generating of the GTP-U header includes: retrieving, from the unencrypted metadata, PDU Set Information; and marking the GTP-U header with the PDU Set Information.

15. The method of any of claims 1-5, further comprising:PATENT APPLICATION Attorney Docket No.: 31730 / 307236-00 receiving, from an application function (AF), an AF request including downlink Extended Reality and Media service (XRM) traffic information for an IP flow to which the UDP packet belongs, wherein the marking of the PDU is further based on the downlink XRM traffic information.

16. A core network (CN) node comprising processing hardware and configured to implement a method of any of the preceding claims.

Images