Differentiated handling for uplink encrypted XRM traffic

Abstract

A node in a radio access network (RAN) receives (1281), from a user equipment (UE)), a User Data Protocol (UDP) packet including (i) a UDP payload and (ii) unencrypted metadata. The node further receives (1240) Differentiated Services Code Point (DSCP) assistance information. The node marks (1292), based on the unencrypted metadata and DSCP assistance information, a Packet Data Unit (PDU) including the UDP payload, including setting a DSCP field in an IP header of the PDU; and transmits (1299) the PDU to a core network (CN).

Description

DIFFERENTIATED HANDLING FOR UPLINK ENCRYPTED XRM TRAFFICCROSS-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,771 entitled “Differentiated Handling for Uplink Encrypted XRM Traffic,” filed on January 12, 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 supporting uplink 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.

[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 profde. 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 vO.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 ofRTP 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 vO.1.1 (2023-08), this approach considers only downlink traffic and, moreover, this approach is based on the assumption that the media packet header information necessary for PDU Set identification is unencrypted, and that a network element can identify a PDU Set and perform GTP-U header marking with the PDU Set information. Thus, it is unclear how a RAN or 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 node of a radio access network (RAN). The method comprises receiving, from a user equipment (UE)), a User Data Protocol (UDP) packet including (i) a UDP payload and (ii) unencrypted metadata; receiving Differentiated Services Code Point (DSCP) assistance information; marking, based on the unencrypted metadata and DSCP assistance information, a Packet Data Unit (PDU) including the UDP payload, including setting a DSCP field in an IP header of the PDU; and transmitting the PDU to a core network (CN).

[0014] Another example embodiment of these techniques is 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. l is a block diagram of an example wireless communication system, such as 5GS, that supports PDU set handling in the uplink 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) and a UPF can exchange 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 is a block diagram of an example system in which a RAN receives, from a UE, an 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 UPF for forwarding to the AS;

[0024] Fig. 10A is a messaging diagram of an example scenario in which a RAN receives DSCP assistance information as well as uplink XRM traffic information via the N2 interface andmarks the outer IP header of a packet enclosing uplink XRM traffic based on the metadata received from the UE and the DSCP assistance information;

[0025] Fig. 10B is a messaging diagram of an example scenario generally similar to that of Fig. 10A, but in which the RAN receives the DSCP assistance information from the UE via an RRC message, and the UE receives uplink XRM traffic information from the CN in a NAS message;

[0026] Fig. 10C is a messaging diagram of an example scenario generally similar to that of Fig. 10A, but in which the RAN receives the DSCP assistance information from the UE via an RRC message, and the UE receives uplink XRM traffic information from an upper layer;

[0027] Fig. 11 A is a flow diagram of an example method in a RAN node for obtaining, from a Session Management Function (SMF), control-plane information for processing uplink XRM data from a UE;

[0028] Fig. 1 IB is a flow diagram of an example method generally similar to that of Fig. 11A, but according to which the RAN receives the DSCP assistance information from the UE via an RRC message and forwards uplink XRM traffic information to the UE;

[0029] Fig. 11C is a flow diagram of an example method generally similar to that of Fig. 1 IB, but according to which the RAN forwards QoS rules but not the uplink XRM traffic information to the UE; and

[0030] Fig. 12 is a flow diagram of an example method in a RAN node for processing an uplink XRM packet.DETAILED DESCRIPTION OF THE DRAWINGS

[0031] As discussed in more detail below, the radio access network of a wireless communication system provides differentiated handling for transporting uplink encrypted XRM traffic. Example techniques are discussed primarily with reference to QUIC packets transporting uplink XRM traffic. However, at least some of these techniques are applicable to all implementations that use partially or fully encrypted RTP headers, such that PDU Set information is not available fort PDU Set identification. More generally, the solutions discussed below are applicable to all partially or fully encrypted XRM traffic.

[0032] Generally speaking, a RAN node (e.g., a base station, a central unit (CU) of a distributed base station; may be referred to simply as “the RAN”) uses DSCP assistance information to perform DSCP marking to differentiate uplink XRM traffic for transporting purposes. The RAN node can obtain control-plane information such as uplink XRM traffic information and the DSCP assistance information from the CN or a UE, depending on the implementation. An XRM application executing at the UE includes user-plane metadata related to the encrypted XRM traffic in uplink packets, and the RAN accordingly uses the control-plane information and the user-plane metadata to generate transport-layer packets with a header that allows differentiated handling.

[0033] According to one such approach, the RAN node obtains the uplink XRM traffic information and the DSCP assistance information from the SMF. According to another approach, the RAN node obtains the DSCP assistance information from the UE via an RRC message. The UE receives the uplink XRM traffic information from the SMF via a NAS message

[0034] According to yet another approach, the RAN node obtains DSCP assistance information from the UE via an RRC message, and the UE receives the uplink XRM traffic information from an upper layer at the UE.

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

[0036] 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 basestation 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.

[0037] While not shown in Fig. 1 to avoid clutter, the CN 1 10 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 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 communicate 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 amemory 164 storing a PDU Set controller 162 and a UL PDU Set Controller for XRM traffic 112. The base station 104 can have a similar implementation.

[0040] In operation, the UL PDU Set Controller for XRM traffic 112 receives UDP packets including XRM traffic from the UE 102 and, using the unencrypted metadata in the UDP packets, generates PDUs for sending via the transport-layer network of the CN 110, toward the UPF 370, using the techniques discussed in detail with reference to Figs. 6-12.

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

[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, theEUTRA 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 Function (CHF) 362, an Access & Mobility Management Function (AMF) 364, a Session Management Function (SMF) 366, and a User Plane Function (UPF) 370.

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

[0047] 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, theUE 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).

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

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

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

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

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

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

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

[0055] 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 header 730 and a QUIC payload 732, which encapsulates multiple RPT packets 740A, 740B, etc. This approach reduces overhead associated with RTP transmissions.

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

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

[0058] 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 anothertransport layer protocol can use the UDP payload as the encapsulation layer (e.g., QUIC over UDP, RTP over UDP, RTP over QUIC).

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

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

[0061] Referring to Fig. 9, in an example system 900, the RAN 105 implements differentiated handling for transporting uplink encrypted XRM traffic in CN to detect an IP flow with encrypted XRM traffic and identify, in an example IP packet 901, a PDU associated with a PDU based on unencrypted metadata in the UDP-Option for a corresponding QUIC packet (on the user plane) and uplink XRM traffic information (on the control plane). The RAN 105 marks DSCP bits in an outer IP header 952 of a PDU 951 included in a PDU Set for the transport layer, based on DSCP assistance information. The IP payload encapsulates QUIC packets with XRM traffic received from the UE 102.

[0062] An XRM application executing on the UE 102, such as the XRM application 142, can transmit the uplink XRM traffic using one or more components of the traffic description: IP flows, QUIC connections, or QUIC streams. The UE 102 can include some or all of the parameters in the unencrypted metadata, so as inform the RAN 105 about the encrypted QUIC packet of the uplink XRM traffic: (i) a uplink 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 the 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 uplink 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 uplnik PDU Set information parameters can include a PDU Set SequenceNumber, 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.

[0063] 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 UE 102 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 UE 102 includes a QUIC packet in the UPD payload as illustrated in Fig. 6. The XRM application executing on the UE 102 thus can generate metadata and include the metadata in the UDP-Option filed to indicate certain information about the encrypted QUIC packet.

[0064] As illustrated in Fig. 10, the RAN 105 can generate a transport layer packet 951, which is a PDU 350 within a certain QoS flow, based on the IP packet 901 from the UE 102. The IP packet 901 can include a QUIC packet and metadata such as a UDP-option field, as discussed above with reference to Figs. 6-8. The UDP payload can include an RTP packet associated with a certain session. The RAN 105 can generate an outer IP header 952 and a GTP-U header 953 of the transport layer packet 951, to enclose the inner IP packet 901.

[0065] The SMF 366 can generate DSCP assistance information and transmit the DSCP assistance information to the RAN 105. The DSCP assistance information can provide, 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.

[0066] 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, eachQUIC 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.

[0067] On the control plane, the uplink XRM traffic information can include one or more of the following sets of parameters: (i) a Traffic Description that indicates IP flow information for the uplink XRM traffic, e.g. IP 5 tuples; (ii) Protocol Description information that indicates the use of the transport layer protocol for the uplink XRM traffic, e.g. QUIC, QUIC+RTP (RTP over QUIC), RTP over UDP with UDP-Option, etc.; (iii) a uplink 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.

[0068] Several example techniques for generating and processing IP packets with UL XRM traffic are discussed next with reference to Figs. 10-12. Generally speaking, events in Figs. 10- 12 that are similar are labeled with similar reference numbers (e g., event 1044 of Fig. 10B is similar to block 1144 in Fig. 1 IB), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternativeimplementations 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.

[0069] Now referring to Fig. 10A, in an example scenario 1000A, the RAN receives DSCP assistance information as well as uplink XRM traffic information via the N2 interface.

[0070] The XRM application 142 provides 1010 uplink XRM traffic information discussed above to the AS 331, via the application layer. The AS 331 then sends 1020 the uplink XRM traffic information to AF 358. The AF 358 sends 1022 an AF request message including uplink XRM traffic information to the CN 110. The AF request can include an Nnef_AFsessionWithQoS_C reate request message or an Nnef_AFsessionWithQoS_Update request message, as described in TS 23.502, clause 4.15.6.6.

[0071] The SMF 366 receives 1022 a PCC rule including uplink 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 1030 uplink 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 1030 N4 session configuration including PDR, FAR, and QER. Thus, to provide support for differentiated handling when transporting uplink XRM traffic, the SMF 366 can obtain 1030 uplink XRM traffic information from the AF 358, bind QoS flows based on the PCC rule including uplink XRM traffic information, determine the DSCP assistance information based on the uplink XRM traffic information, and sends 1042 the DSCP assistance information to the RAN 105.

[0072] Based on the N4 session configuration, the SMF sends 1032, to the UPF 370, an N4 message including a PDR, a FAR, and a QER. For the UPF 370, the QER specifically includes a PDU Set Information marking indicator to instruct the UPF 370 to insert PDU Set Information related to packets belonging to a PDU Set into GTP-U header.

[0073] The SMF 366 sends 1042, to the RAN 105, an N2 SM information including QoS profiles(s) and assistance information for the QoS flow(s) of the uplink XRM traffic. Further, the SMF 366 sends 1070, to the UE 102, a NAS message with N1 SM information including QoS rules(s) for the QoS flow(s) of the uplink XRM traffic. The SMF 366 can send 1042, 1070 these messages via the AMF 364.

[0074] On the user plane, the XRM application 142 adds 1050 metadata to the UDP-Option of a UDP datagram encapsulated in QUIC packet of the uplink XRM traffic. The UE 102 receiving uplink XRM traffic from the XRM application 142 maps 1080 the DRB(s) to the QoS flow(s) based on QoS rule(s) provisioned by the SMF 366. Thus, the DRB(s) of the QoS flow(s) carry the XRM traffic.

[0075] The RAN 105 receives 1082 the uplink XRM traffic from the UE 102. Using the received 1042 DSCP assistance information, the RAN 105 can perform 1090 uplink PDU Set based QoS handling and DSCP marking of the outer IP header of uplink XRM traffic, and send 1097 the uplink XRM traffic over the N3 interface to the UPF 370. Thus, the RAN 105 enables 1090 differentiated handling for transporting uplink XRM traffic by marking DSCP bits in the outer IP header, based on the DSCP assistance information received from the SMF 366.

[0076] Thus, the RAN 105 can perform (or forego) uplink PDU Set based QoS handling based on the following information, for an uplink QoS flow configured to provide differentiated handling for transporting uplink XRM traffic: (i) the uplink XRM traffic information included in N2 message from the SMF 366, and (ii) the metadata information related to the uplink encrypted XRM traffic, received from the UE 102 on the user plane.

[0077] The transport network of the CN 110 prioritizes 1097 the XRM traffic according to the DSCP bits in the outer IP header. Based on applying 1098 the relevant PDR and FAR, the UPF 370 then forwards 1099 the uplink XRM traffic to the AS 331, over the N6 interface.

[0078] Fig. 10B illustrates an example scenario 1000B generally similar to the scenario 1000A of Fig. 10A, but here the RAN 105 receives 1076 the DSCP assistance information from the UE 102 via an RRC message, and the UE 1071 receives uplink XRM traffic information from the CN in a NAS message. In particular, the SMF 366 sends 1071 N1 SM information including QoS rules(s) and uplink XRM traffic information for the QoS flow(s) of the uplink XRM traffic, in an NAS message, and the UE 102 sends 1076, to the RAN 105, an RRC message including DSCP assistance information, so that the RAN 105 can differentiate the handling of XRM traffic when transporting uplink XRM traffic in the CN 110. In some cases, the UE 102 sends 1076 the RRC message 414 in response to the RAN 105 querying 1075 the UE 102 for DSCP assistance information.

[0079] The SMF 366 transmits 1044 N2 SM information including QoS profiles(s) to the RAN 105 for the QoS flow(s) of the uplink XRM traffic. In addition to sending 1010 the uplink XRM traffic information to the AS 331, the XRM application 142 at the UE 102 can provide the uplink XRM traffic information to the lower layer at the UE 102, where the uplink XRM traffic information is associated with one or more components of the traffic description: IP flows, QUIC connections, and QUIC streams.

[0080] More particularly, the RAN 105 enables differentiated handling for transporting uplink XRM traffic by marking DSCP bits in the outer IP header based on the DSCP assistance information which the UE 102 provides via an RRC message. The UE 102 performs the following to provide support for enabling differentiated handling when transporting uplink XRM traffic: (i) obtains 1072 uplink XRM traffic information via a NAS message from the SMF 366, (ii) determines the DSCP assistance information based on the uplink XRM traffic information, and (iii) sends 1076 DSCP assistance information to the NG-RAN via RRC message.

[0081] The RAN 105 may perform (or forego) uplink PDU Set based QoS handling based on the following two factors, for an uplink QoS flow that supports differentiated handling for transporting uplink XRM traffic: (i) the uplink XRM traffic information from UE 102 via a control-plane RRC message, and (ii) metadata related to uplink encrypted XRM traffic, which the UE 102 provides on the user plane.

[0082] The SMF 366 can provide 1071 the uplink XRM information to the UE 102 using one of the options described below. According to the first option, the SMF 366 adds a second QoS rule, as an extended QoS rule, for handling unlink encrypted XRM traffic. For example, in addition to the Authorized QoS rule, the SMF 366 can provide an extended Authorized QoS rule with one or more of the following parameters: a QRI, the length of QoS rule, a Rule operation code, a DQR bit, the number of packet filters, a packet filter list, packet filter precedence, and a QFI.

[0083] According to another option, the SMF 366 includes, in the existing Authorized QoS rule, a dedicated special-purpose IE as to add uplink XRM traffic information, e.g. QSC-ID, to define an extended Authorized QoS rule. Further, the SMF 366 can indicate the extended packet filter precedence for uplink encrypted XRM traffic. For example, an Authorized QoS rule can include a new IE, so that the new rule definition becomes: a QRI, the length of QoS rule, a Ruleoperation code, a DQR bit, the number of packet filers, a packet filter list, packet filter precedence, the added special-purpose IE, and a QFI.

[0084] According to yet another option, the SMF 366 adds a dedicated, special-purpose IE to an Authorized QoS flow description to define an extended QoS flow descriptions for uplink encrypted XRM traffic. For example, an Authorized QoS flow description can include a new IE, so that the new definition becomes: a QFI, an operation code (create, modify, delete), QoS parameters (5QI, GFBR / MFBR uplink / downlink, avg. window, EPS bearer ID), an RQ timer value, and the added special-purpose IE.

[0085] Fig. 10C illustrates a scenario 1000C generally similar to that of Fig. 10A, but in which the RAN receives the DSCP assistance information from the UE via an RRC message, and the UE receives uplink XRM traffic information from an upper layer. Here, the RAN 105 enables differentiated handling for transporting uplink XRM traffic by marking DSCP bits in the outer IP header based on the DSCP assistance information received from the UE 102 in an RRC message from UE 102. The UE 102 performs the following to provide support for enabling differentiated handling when transporting uplink XRM traffic: (i) obtains uplink XRM traffic information discussed above from the upper-layer XRM application 142, (ii) determines the DSCP assistance information based on uplink XRM traffic information, and (iii) sends the DSCP assistance information to the RAN 105 in an RRC message.

[0086] The RAN 105 may perform or forego uplink PDU Set based QoS handling based on the following factors, for an uplink QoS flow that supports differentiated handling for transporting uplink XRM traffic: (i) the uplink XRM traffic information, received from the UE 102 in a control -plane RRC message, and (ii) metadata related to the uplink encrypted XRM traffic, received from the UE 102 on the user plane.

[0087] In particular, the XRM application 142 provides 1012 uplink XRM traffic information to the lower layer at the UE 102. Similar to the examples above, the uplink XRM traffic information is associated with one or more components of the traffic description: IP flows, QUIC connections, and QUIC streams. The SMF 366 sends 1044, to the RAN 105, N2 SM information including QoS profiles(s) for the QoS flow(s) of the uplink XRM traffic, in an N2 message. The SFMF 366 sends 1070, to the UE 102, N1 SM information including QoS rules(s) for the QoS flow(s) of the uplink XRM traffic, in a NAS message.

[0088] Fig. 11A is a flow diagram of an example method 1100A, which can be implemented in a RAN node to obtain, from an SMF, control-plane information for processing uplink XRM data from a UE. At block 1142, the RAN node receives, from the SMF, N2 SN information including QoS profiles and DSCP assistance information for QoS flows corresponding to the uplink XRM traffic. At block 1170, the RAN node forwards, between the SMF and the UE, a NAS message including N1 information containing QoS rules for the QoS flow(s) corresponding to the uplink traffic. At block 1182, the RAN node receives, from an XRM application executing at the UE and over a DRB mapped to a QoS flow, a UDP packet carrying a QUIC packet, with the UDP -option field including metadata for the QUIC packet.

[0089] Fig. 1 IB is a flow diagram of an example method 1100B according to which the RAN receives the DSCP assistance information from the UE via an RRC message and forwards uplink XRM traffic information to the UE. At block 1144, the RAN node receives, from the SMF, N2 SN information including QoS profiles for QoS flow(s) corresponding to uplink XRM traffic. At block 1171, the RAN node forwards, between the SMF and the UE, a NAS message including N1 information containing QoS rules for the QoS flow(s) corresponding to the uplink traffic and uplink XRM traffic information. Optionally, at block 1175, the RAN node queries the UE for DSCP assistance information. At block 1176, the RAN node receives the DSCP assistance information from the UE. At block 1182, the RAN node receives, from an XRM application executing at the UE and over a DRB mapped to a QoS flow, a UDP packet carrying a QUIC packet, with the UDP-Option field including metadata for the QUIC packet.

[0090] Fig. 11C illustrates an example method 1100C according to which the RAN forwards QoS rules but not the uplink XRM traffic information to the UE. At block 1144, the RAN node receives, from the SMF, N2 SN information including QoS profiles for QoS flow(s) corresponding to uplink XRM traffic. After executing blocks 1170, 1175, and 1176 discussed above, the RAN node at block 1182 receives, from an XRM application executing at the UE and over a DRB mapped to a QoS flow, a UDP packet carrying a QUIC packet, with the UDP- Option field including metadata for the QUIC packet.

[0091] Finally, Fig. 12 illustrates an example method 1200 in a RAN node for processing an uplink XRM packet. At block 1240, the RAN node receives, from the CN or the UE, DSCP assistance information. At block 1281, the RAN node receives a UDP packet with a UDPpayload and unencrypted metadata. At block 1291, the RAN node determines that the UDP packet includes a PDU in a PDU Set, based on the unencrypted metadata. At block 1292, the RAN node marks a PDU that includes the UDP payload, by setting DSCP bits in the IP header. At block 1299, the RAN node transmits the UDP with the marked IP header (defining a transport-layer packet) to the UPF.

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

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

[0094] Example 2. The method of example 1, further comprising obtaining uplink Extended Reality and Media service (XRM) traffic information; wherein the marking of the PDU includes using the uplink XRM traffic information.

[0095] Example 3. The method of example 2, wherein the DSCP assistance information and the uplink XRM traffic information are received from the CN.

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

[0097] Example 5. The method of example 4, wherein the DSCP assistance information is included in an N2 SM information, the N2 SM information further including a Quality of Service (QoS) profile for a QoS flow to which the UDP packet belongs.

[0098] Example 6. The method of example 2, wherein the DSCP assistance information is received from the UE, and the uplink XRM traffic information is received from the CN.

[0099] Example 7. The method of example 6, wherein the DSCP assistance information is received in a Radio Resource Control (RRC) message.

[0100] Example 8. The method of example 6 or 7, wherein the uplink XRM traffic information is received from an SMF in a non-access stratum (NAS) message.

[0101] Example 9. The method of any of examples 6-8, further comprising transmitting the uplink XRM traffic information to the UE, for generating the DSCP assistance information.

[0102] Example 10. The method of any of examples 6-9, wherein the uplink XRM traffic information includes an extended authorized QoS rule dedicated to handling uplink encrypted XRM traffic.

[0103] Example 11. The method of any of examples 6-9, wherein the uplink XRM traffic information includes an authorized QoS rule including an information element (IE) with a QUIC session id (QSC-ID).

[0104] Example 12. The method of example 2, wherein the DSCP assistance information and the XRM traffic information are received from the UE.

[0105] Example 13. The method of any of the preceding examples, 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.

[0106] Example 14. The method of any of examples 1-12, wherein the DSCP assistance information includes a mapping of one or more QUIC session priority values to a respective one or more DSCP values.

[0107] Example 15. The method of example 2 or 3, wherein the uplink 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.

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

[0109] Example 17. The method of any of examples 1- 5 or 6-16, wherein the UDP packet is received via a data radio bearer (DRB) to which a QoS flow of the UDP packet is mapped.

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

[0111] Example 19. The method of any of the preceding examples, wherein the UDP payload includes a Quick UDP Internet Connections (QUIC) packet.

[0112] Example 20. The method of example 19, wherein the unencrypted metadata includes a QSC-ID.

[0113] Example 21. The method of example 20, wherein the QSC-ID identifies one of: an IP flow to which the UDP packet belongs, a QUIC connection to which the UDP packet belongs, or a QUIC stream to which the UDP packet belongs.

[0114] Example 22. The method of example 19, wherein the unencrypted metadata includes a priority of a QUIC session corresponding to a single Internet Protocol (IP) flow.

[0115] Example 23. The method of any of the preceding examples, wherein the unencrypted metadata includes a Packet Data Unit (PDU) Set information for a PDU Set to which the UDP packet belongs.

[0116] Example 24. The method of claim 23, wherein the PDU Set information includes a PSI value that indicates an importance of the PDU Set relative to one or more other PDU Sets included in a QoS flow of the UDP packet.

[0117] Example 25. A node in a Radio Access Network (RAN) comprising: a transceiver; and

[0118] processing hardware configured to implement a method of any of the preceding examples.

[0119] 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 (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.

[0120] 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-readable 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.

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

[0122] 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 specialpurpose processors.

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

CLAIMS:

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

2. The method of claim 1, further comprising: obtaining uplink Extended Reality and Media service (XRM) traffic information; wherein the marking of the PDU includes using the uplink XRM traffic information.

3. The method of claim 2, wherein: the DSCP assistance information and the uplink XRM traffic information are received from the CN.

4. The method of claim 2, wherein: the DSCP assistance information is received from the UE, and the uplink XRM traffic information is received from the CN.

5. The method of claim 4, further comprising: transmitting the uplink XRM traffic information to the UE.

6. The method of claim 2, wherein: the DSCP assistance information and the XRM traffic information are received from the UE.

7. The method of any of the preceding claims, 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.

8. The method of any of claims 1-6, wherein the DSCP assistance information includes: a mapping of one or more QUIC session priority values to a respective one or more DSCP values.

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

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

11. The method of any of the preceding claims, wherein the UDP payload includes a Quick UDP Internet Connections (QUIC) packet.

12. The method of claim 13, wherein: the unencrypted metadata includes a QSC-ID.

13. The method of claim 13, wherein the unencrypted metadata includes: a priority of a QUIC session corresponding to a single Internet Protocol (IP) flow.

14. The method of any of the preceding claims, wherein the unencrypted metadata includes: a Packet Data Unit (PDU) Set information for a PDU Set to which the UDP packet belongs.

15. The method of claim 14, wherein the PDU Set information includes a PSI value that indicates an importance of the PDU Set relative to one or more other PDU Sets included in a QoS flow of the UDP packet.

16. A node in a Radio Access Network (RAN) comprising: a transceiver; and processing hardware configured to implement a method of any of the preceding claims.

Images