Methods and devices for secure metadata delivery for PDU set handling of encrypted traffic

Abstract

A wireless communication method (300) performed by a network entity (140) of a 5G core network executes a user plane function, UPF, (116) to forward, according to a specific quality of service, traffic received from a traffic source (108) to a user equipment, UE, (102). The method (300) includes establishing (354) a metadata secure delivery mechanism with the traffic source, retrieving (365), from a User Datagram Protocol, UDP, datagram received from the traffic source, metadata associated with the UDP datagram. The metadata is retrieved based on the metadata secure delivery mechanism and indicates that a payload of the UDP pertains to a PDU set to be handled with a specific QoS. The method then includes forwarding (366) the payload of the UDP towards the UE according to the specific QoS.

Description

Patent Application Attorney Docket Number 0683-103-WO METHODS AND DEVICES FOR SECURE METADATA DELIVERY FOR PDU SET HANDLING OF ENCRYPTED TRAFFIC FIELD OF THE DISCLOSURE

[0001] This document generally describes methods and devices operating in wireless communication systems such as (but not limited to) the ones described in 3rd Generation Partnership Project (3GPP) technical specifications (TSs), for example, in the Fifth Generation (5G) or in the Long Term Evolution (LTE) communication systems. More particularly, the methods and devices employ techniques for secure delivery of metadata enabling packet data unit (PDU) set handling. BACKGROUND

[0002] A PDU Set is made of one or more PDUs carrying an application layer payload. In case of extended reality and media (XRM) traffic, a PDU packet payload may be a video frame, or a video slice formatted as real time protocol (RTP) packets. Note that the term “media” may be used in this document instead of XRM. One or more RTP packets may be encapsulated in a QUIC packet transported by a logical QUIC stream. Here, QUIC stands for Quick UDP Internet Connections, with UDP meaning User Datagram Protocol. When a PDU Set is transmitted from an application server (AS) to a user equipment (UE) via a PDU session anchor (PSA) user plane function (UPF), the PDU Set based quality of service (QoS) handling of the packets (e.g., by a next generation (NG) radio access network (NG-RAN) device) depends on (i) PDU Set QoS profile associated with a respective QoS Flow to which the QUIC packets pertain, and (ii) PDU Set Information carried by metadata associated with each packet. Note that in this document the “NG-RAN device” may simply be called “NG-RAN,” and an “UDP datagram” may simply be called “UDP”. The PDU Set QoS profile includes parameters such as, PDU Set Delay Budget (SDB), PDU Set Error Rate (PSER), and PDU Set Integrated Handling Information (PSIHI). The PDU Set Information may include: a PDU Set Sequence Number, an indication of End PDU of the PDU Set, a PDU Sequence Number within a PDU Set, a PDU Set Size in bytes, and a PDU Set Importance (PSI), which identifies the relative importance of a PDU Set compared toPatent Application Attorney Docket Number 0683-103-WO other PDU Sets within the QoS Flow. The PDU Set Information may be extended to cover more information for PDU Set Identification in 3GPP network.

[0003] Ongoing efforts for architecture enhancement for XRM service aim to enhance PDU Set based QoS handling, enhance support of XR based on non-3GPP access, expose XR related network capability / information towards the application layer, etc. The current 3GPP Technical Report TR 23.700-70 defines a Fully Encrypted Media Flow (FEMF) and Partially Encrypted Media Flow (PEMF) as follows. FEMF is a media flow where both the media header and media payload are encrypted from end-to-end. Fully encrypted headers and payload are not visible in the network. PEMF is a media flow where at least some media headers (e.g., the base header) are not encrypted. Other media headers (e.g., extension header) and media payload are encrypted from end-to-end. The payload and headers that are encrypted from end-to-end are not visible in the network.

[0004] Current versions of 3GPP TSs 23.501, 23.502, 23.503, and 26.522 describe 5G network cores that support PDU Set based QoS handling. In this context, the Policy and Control Function (PCF) determines a Policy Charge and Control (PCC) Rule based on PDU Set QoS Parameters provided by the application function (AF) and Protocol Description(s). The PCC rule provides information that enables identifying IP traffic flows, applying QoS parameters, filtering and charging for such flows. Upon receiving the PCC rule, the Session Management Function (SMF) binds (i.e., associates) the PCC rule to a QoS Flow within a PDU Session. The SMF also adds these PDU Set QoS parameters to the QoS Profile of the QoS Flow and then provides the QoS Profile to the NG-RAN. If the PCC rule contains one or more PDU Set QoS Parameters (PSER, PSDB, and PSIHI), the PSA UPF may use the Protocol Description(s) for identifying the PDU Set information included in XRM packet header of the XRM packet transmitted over N6 (which is a reference point or an interface between a 5G core network and a data network, depending on whether functions on either side of it are hosted by the same physical device).

[0005] The PSA UPF identifies PDUs that belong to PDU Sets and retrieves the PDU Set Information (specified above) based on the RTP extension header. The PSA UPF then sends the PDU Set Information to the NG-RAN in a GTP-U header (here,Patent Application Attorney Docket Number 0683-103-WO GTP-U stands for GPRS Tunneling Protocol User, and GPRS for General Packet Radio Service). The NG-RAN uses the PDU Set information for PDU Set based QoS handling.

[0006] The current networks generally use end-to-end encryption to provide security, which is expected also for XRM applications. The PSA UPF in 5G network cannot perform PDU Set Identification from end-to-end encrypted traffic when media packet header information necessary for PDU Set identification is partially or fully encrypted. It has been proposed to deliver metadata containing PDU Set Information via an UDP-Option which is transmitted along with the encrypted QUIC packet containing media application packets (e.g., using RTP protocol). This approach is tunnel-less but the AS / AF needs to provide information of a specific media stream correlation ID (MSC-ID) to correlate a QUIC connection and / or QUIC stream that requires a specific set of QoS requirements. Based on the MSC-ID information, the UPF can perform PDU Set Identification for the packets marked with MSC-ID received from the AS and then enforce QoS rules accordingly.

[0007] Conventionally, the metadata transmitted from the AS to the PSA UPF over N6 reference point in the user plane is not securely delivered (e.g., encrypted and integrity protected). In other words, the AS does not have a secure delivery mechanism to protect the metadata. SUMMARY

[0008] According to various embodiments, a mechanism for securely delivering the metadata is negotiated during initialization of traffic. The metadata includes PDU Set information enabling PDU Set identification and, therefore, handling the traffic downstream according to a desired QoS downstream. For example, the NG-RAN handles XRM traffic according to a QoS of the XRM flow identified using metadata transmitted by the respective XRM AS. The negotiation of parameters for the metadata secure delivery mechanism is (a) a control plane procedure between the network exposure function (NEF) and application function (AF) over N33, or (b) a user plane procedure between the PSA UPF and the AS over N6. In both cases, the negotiation may be initiated by an AF request. The AF request includes one or more of: an indication of required QoS, a QUIC session Correlation identifier, an indication of usingPatent Application Attorney Docket Number 0683-103-WO the UDP Option portion of the UDP datagram for carrying the metadata, and / or security requirements. When the metadata secure delivery mechanism includes a QUIC session Correlation identifier and the security requirements indicate an encryption mechanism, the AS encrypts the metadata using encryption keys negotiated during the traffic initialization.

[0009] In some embodiments, the metadata is included in a UDP Option portion of the UDP datagram, with the Kind field of the UDP Option portion taking a new value to indicate the use of the metadata in the UDP option portion for the metadata secure delivery mechanism. Optionally, the AS or the PSA-UPF triggers renewal of the security keys for the metadata secure delivery mechanism.

[0010] In some embodiments, the UPF acting as HTTP client establishes an N6 UDP tunnel with a proxy in the cloud. The proxy converts the UDP datagram received from the traffic source device into an HTTP datagram. The proxy then transmits the HTTP datagram to the UPF with the metadata protected using the metadata secure delivery mechanism (e.g., encryption), using a Connect-UDP upgrade token in a tunneled mode or in a forwarded mode.

[0011] In other embodiments, the UE acting as an HTTP client establishes a UDP tunnel with the UPF. Thus, the UPF operates as a proxy by converting the UDP datagram received from the traffic source device (AS) over the N6 interface into an HTTP datagram. Here, the metadata secure delivery mechanism is negotiated between the UE and the AS at an application layer and shared with the UPF. The UPF extracts, from the UDP datagram received from the traffic source device, the AS-encrypted and / or integrity protected metadata carried either within the transformed QUIC or the UDP Option for the UDP datagram.Patent Application Attorney Docket Number 0683-103-WO BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Fig.1 is a schematic representation of a wireless communication system including at least one network entity (NE) configured to perform methods according to various embodiments.

[0013] Fig.2 illustrates a 5G system architecture in reference point representation.

[0014] Fig.3 is a flowchart of a method for a network element to securely deliver metadata according to an embodiment.

[0015] Fig.4 is a schematic representation of an XRM packet including a UDP datagram.

[0016] Fig.5 is a diagram illustrating tunnel-less XRM traffic over N6 interface for a logical media session for QUIC connection / stream for transporting QUIC packet along with metadata in UDP-Option between UE and AS.

[0017] Fig.6 is a signal diagram illustrating a high level procedure for enabling the PDU Set based QoS handling with secure metadata delivery.

[0018] Fig.7 illustrates a UE-initiated PDU establishment procedure.

[0019] Fig.8 is a signal diagram illustrating a first tunnel-less procedure for enabling PDU Set based QoS handling and secure metadata delivery, according to an embodiment.

[0020] Fig.9 is a signal diagram illustrating a second tunnel-less procedure for enabling PDU Set based QoS handling and secure metadata delivery according to another embodiment.

[0021] Fig.10 is a diagram illustrating XRM traffic with a QUIC-aware HTTP proxy converting the UDP datagram into an HTTP datagram for Connect-UDP in tunneled mode according to an embodiment.

[0022] Fig.11 is a diagram illustrating XRM traffic with a QUIC-aware HTTP proxy converting the UDP datagram into an HTTP datagram for Connect-UDP in forwarded mode according to an embodiment.

[0023] Fig.12 is a signal diagram of a second high level procedure for enabling PDU Set Identification and PDU Set based QoS handling for end-to-end encrypted XRMPatent Application Attorney Docket Number 0683-103-WO traffic over a UDP tunnel over N6 with the PSA UPF as HTTP client and the HTTP proxy in the cloud according to an embodiment.

[0024] Fig.13 is schematic representation of XRM packet structure for a UDP datagram used in an UDP tunnel according to an embodiment.

[0025] Fig.14 is a signal diagram illustrating secure delivery of metadata via an N6 UDP tunnel according to an embodiment.

[0026] Fig.15 is a schematic representation of UDP datagrams in which a UDP payload contains a transformed QUIC packet including a QUIC header, the original QUIC payload, and metadata.

[0027] Fig.16 is a diagram illustrating XRM traffic when with the UE is an HTTP client and the UPF is an HTTP proxy.

[0028] Fig.17 is a signal diagram illustrating a third high level procedure for enabling PDU Set Identification and PDU Set based QoS handling with the UE as an HTTP client and the UPF as an HTTP proxy according to an embodiment.

[0029] Fig.18 is a signal diagram of a procedure for enabling PDU Set Identification and PDU Set based QoS handling with secure delivery of metadata, according to yet another embodiment. DETAILED DESCRIPTION

[0030] Methods and devices described in this section embody techniques related to secure metadata delivery from an AS to a UPF for PDU Set handling according to a required QoS of traffic such as for XRM traffic. Although the detailed embodiments refer to XRM traffic, and encryption, the techniques described in this context are pertinent for other traffic requiring PDU Set handling according to a specific QoS, and metadata secure delivery mechanisms other than encryption based techniques.

[0031] The embodiment descriptions in this section refer to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The detailed descriptions do not preclude other embodiments within the scope of the appended claims. The embodiments are not limited to the described configurations but may be extended to other arrangements.Patent Application Attorney Docket Number 0683-103-WO

[0032] Fig.1 is a schematic representation of a wireless communication system 100 including at least one network entity (NE) hosting one or more network core functions. Methods and devices embodying according to various embodiments operate within the framework of a wireless communication system as illustrated in Fig.1. Therefore, prior to discussing methods for secure metadata delivery according to various embodiments, Fig.1 schematically illustrates a wireless communication system 100 including a UE 102, a NG-RAN 104, and an NE 140 on which one or more 5G SN functions are performed, which are able and configured to perform these methods. The UE 102 uses services provided by the 5GC 110 via a NG-RAN 104 that serves UEs within a cell 124. For the sake of simplicity and clarity, the following description refers mostly to 5G radio access technology (RAT), but this RAT is an illustration and should not be interpreted as a limitation; other RATs such as a sixth generation (6G) RAT may be employed.

[0033] As illustrated in Fig.1, the NG-RAN 104 serves (i.e., intermediates communication with UEs located within) a cell 124 but it may serve plural cells (not shown) in the same Radio Access Network Notification Areas (RNA) or different RNAs. In general, a network operator owning a core network 110 provides services to end users (i.e., UEs) via any number of nodes (NG-RANs), and each of the NG-RANs can serve one, two, three, or any other suitable number of cells. Each NG-RAN may connect to 5GC NEs such as 140 (i.e., physical devices hosting 5G CN function(s)) via a 5GC-based interface (e.g., an S1 or an Ng interface). The NG-RANs may also be interconnected via other specific interfaces (e.g., an X2 or an Xn interface).

[0034] The UE 102 is equipped with processing hardware 120 that includes one or more general-purpose processors and / or special-purpose processing units. The processing hardware 120 illustrated in Fig.1 includes a processor 122 configured to process uplink (UL) data that the UE 102 transmits to the 5GC 110 via the NG-RAN 104, and / or downlink (DL) data the UE receives from or via NG-RAN 104. The processing hardware 120 also includes a transmitter 124 configured to transmit the UL data and a receiver 126 configured to receive the DL data (or, alternatively, a transceiver performing both transmitting and receiving data). The UE may include (although not shown) transmission / reception hardware for other 3GPP RAT(s) besidesPatent Application Attorney Docket Number 0683-103-WO 5G (e.g., LTE, 6G) and also for non-3GPP RAT(s) (e.g., WiFi, Bluetooth). The processing hardware 120 typically also includes a non-transitory computer-readable medium (e.g., a memory) storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units.

[0035] The NG-RAN 104 is similarly equipped with processing hardware (not shown) including one or more general-purpose processors and / or special-purpose processing units, a transmitter, a receiver and a non-transitory computer-readable medium.

[0036] The 5GC includes many functions but only a few, which are relevant to the claimed methods, are illustrated in Fig.1. Fig.2 provides a more complete illustration (as presented in 3GPP TS 23.501) of 5G CN functions and their inter-relationships in reference point representation. One or more of the 5G CN functions are hosted on an NE such as NE 130. NE 130’s processing hardware includes a processor 132 (may be more processors of various types), a transmitter 134 configured to transmit signals wirelessly, and a receiver 136 configured to receive signals wirelessly (the transmitter and the receiver may alternatively be a single transceiver). The NEs typically also include a memory storing executable instructions for the processor to perform various methods described hereinafter, and other data. The 5G CN 110 illustrated in Fig.1 includes an access and mobility management function (AMF) 112, a session management function (SMF) 114, a user plane function (UPF) 116, a policy control function (PCF) 118, and a network exposure function (NEF) 119. The same NE may execute one or more 5GC functions or instances of 5GC functions. For example, the 5GC 110 may have a plurality of UPF instances running on the same NE or on different NEs.

[0037] The AMF 112 is configured to manage authentication, registration, paging, and other related functions. The SMF 114 is configured to manage PDU sessions, and the UPF 116 is configured to transfer user-plane packets related to audio calls, video calls, XRM, etc., between the UE and a data network 108 (which for XRM applications is an AS). The PCF 118 is a network function that provides policy control and charging rules for 5G services and applications thereby facilitating network behavior control, network slicing, UE activities, and communication with other 5GC functions. The NEF isPatent Application Attorney Docket Number 0683-103-WO a function that allows third-party applications to securely access the 5G network's services and capabilities. The application function (AF) 115 (and, optionally, an HTTP proxy 109) may be located on the same physical device 140 as the AS. This device’s processing hardware includes at least one processor 142, a transmitter 144 and receiver 146 (or a transceiver) that enable wireless communication of data packets.

[0038] Fig.2 illustrates a 5G system architecture in reference point representation. Reference points (e.g., N1, N2, N4, N6) are interfaces when end points (functions) on either side thereof are hosted by different physical devices. Control plane 211 functions manage communication sessions and control communications, and User plane 221 handle traffic.

[0039] Fig.3 is a flowchart of a method 300 performed by an NE (such as, 130) of a 5G CN (e.g., 110) that executes a UPF (e.g., 116) for securely delivering metadata. The metadata enables identifying the PDU Set to which an encrypted UDP datagram payload pertains and, thereby, to forward traffic received from a traffic source device (e.g., AS 108 hosted by device 140) to a UE (e.g., 102) via an NG-RAN (e.g., 104) according to the specific PDU Set’s QoS. The method 300 includes establishing 354 a metadata secure delivery mechanism with the traffic source device. The method 300 further includes retrieving 365, from a UDP datagram received from the traffic source and using the metadata secure delivery mechanism, metadata indicating that a payload of the UDP datagram contains end-to-end encrypted XRM packet, e.g. QUIC packet, and pertains to a PDU set to be identified and handled with a specific QoS. The method 300 then includes forwarding 366 the end-to-end encrypted XRM packet towards the UE via NG-RAN for the specific QoS based on PDU Set based QoS handling.

[0040] Specific implementations of these steps are discussed below. The detailed embodiments refer in particular to XRM traffic and may start from the following assumptions: (a) RTP is used; (b) RTP over QUIC is based on Internet Engineering Task Force (IETF) draft-ietf-avtcore-rtp-over-quic-07: RTP over QUIC, whereby the end-to-end connection between the UE and the Application Server is based on QUIC; and (c) HTTP / 3 is assumed for HTTP client in solutions that apply Proxy-UDP-in HTTP / 3 and QUIC aware proxy (as described in (i) IETF RFC-9298-Proxying UDP in HTTP; (ii) IETF RFC-9297- HTTP datagram and capsule protocol; (iii) IETF RFC 9221 - An Unreliable DatagramPatent Application Attorney Docket Number 0683-103-WO Extension to QUIC; and (iv) IETF draft-ietf-masque-quic-proxy-03: QUIC-Aware Proxying Using HTTP)).

[0041] Fig.4 is a schematic representation of an XRM packet including a UDP datagram. Besides an IP header 401 and an UDP header 402, the UDP datagram 400 includes a UDP payload 410 and UDP option 420. The UDP payload 410 carries a QUIC packet 411 including a QUIC header 412 and QUIC payload 414. The QUIC payload 414 is made of one or more RTP packets 416. The UDP option 420 has a minimum length of two bytes and includes a Kind field 422 (always one byte), a Length field 424, and a Remainder of option field 426. The Length field is one byte for all lengths below 255 (including the Kind and Length fields) but a Length of 255 indicates use of the UDP option extended format. The Extended Length field is a 16-bit field in network standard byte order. The UDP options are typically a minimum of two bytes except the one-byte option "No Operation." The Remainder of option field 426 is used in some of the embodiments described below to transmit metadata including PDU Set information enabling PDU Set identification as pertaining to a PDU Set / flow and therefore handling the packet 410 according to the specific QoS based on PDU Set based QoS handling. The metadata secure delivery mechanism is applied specifically to the metadata (e.g., the metadata is encrypted and / or integrity protected using pre-negotiated security keys which may have a limited validity period).

[0042] Internet Assigned Numbers Authority (IANA) manages standardized (i.e., publicly known and used) UDP options, consisting of UDP option Kind field values and UDP Option Experimental IDs (ExIDs). Initial values of the UDP Option Kind registry are as reproduced below, including those both assigned and reserved. Additional values in this registry are to be assigned from the UNASSIGNED values by Internet Engineering Steering Group (IESG) Approval or Standards Action. An end point supporting UDP option must support at least the Kind marked with * in the following table.Patent Application Attorney Docket Number 0683-103-WO

[0043] The following UDP options are currently defined: Kind Length Meaning ---------------------------------------------- 0* - End of Options List (EOL) 1* - No operation (NOP) 2* 6 Additional payload checksum (APC) Fragmentation (FRAG)Maximum datagram size (MDS) 5* 4 Maximum reassembled datagram size (MRDS) 6* 6 Request (REQ) 7* 6 Response (RES) 8 10 Timestamps (TIME) 9 (varies) RESERVED for Authentication (AUTH) 10-126 (varies) UNASSIGNED (assignable by IANA) 127 (varies) RFC 3692-style experiments (EXP) 128-191 RESERVED 192 (varies) RESERVED for Compression (UCMP) 193 (varies) RESERVED for Encryption (UENC) 194-253 UNASSIGNED-UNSAFE (assignable by IANA) 254 (varies) RFC 3692-style experiments (UEXP) 255 RESERVED-UNSAFE

[0044] First embodiments described below provide a logical media session (tunnel- less) based approach that employ a control plane-based security keys negotiation over N33 interface, or a user plane-based security keys negotiation over N6 interface. Metadata is encrypted and / or integrity protected and transmitted using the UDP option with a Kind value added to the UDP-Option 420 described above, the new value indicating delivering metadata (that includes PDU Set Information enabling PDU set / flow identification and therefore handling according to a specific QoS based on PDU Set based handling).

[0045] Fig.5 is a diagram for a logical media session for a QUIC connection / stream between the UE 102 and the AS 108 via PSA UPF 116 (and NG-RAN such as 104 notPatent Application Attorney Docket Number 0683-103-WO shown here). In this diagram for transporting end-to-end encrypted XRM traffic (as suggested by the lock marked with letter “P” for XRM packet in UDP datagram payload) over N6, the PSA UPF 116 and the AS 108 (which may be in the cloud) can identify encrypted XRM traffic of a QUIC connection / stream based on a media session ID indicated in the received metadata; the media session ID can be a random number generated by the AS. The PSA UPF 116 performs PDU Set Identification based on the media session ID and PDU Set information included in metadata of the associated XRM packet. In an implementation, the metadata is included in UDP-Option 420. The AS 108 transmits one or more UDP datagrams to the PSA UPF 116 within the Logical Media Session of a QUIC connection / stream 504. Each UDP datagram 400 transports a QUIC packet (end-to-end 506, that is from AS to UE, security protected) as UDP payload 410 along with metadata in the UDP-Option 420. Here, the metadata is protected using a metadata secure delivery mechanism as suggested by the second lock icon marked with letter “m”.

[0046] The PSA UPF 116 retrieves the metadata using the metadata secure delivery mechanism (as suggested by the unlocked lock icon marked with letter “m”). The metadata secure delivery mechanism may be encryption / integrity keys negotiated during (a) a control plane procedure between the network exposure function (NEF) and application function (AF) over N33, or (b) a user plane procedure between the PSA UPF and the AS over N6. The PDU UPF 116 then forwards the UDP datagram using an Internet Protocol (IP) session 502 to the UE via NG-RAN 104. The UE 102 extracts the QUIC packet of XRM traffic from the UDP payload (as suggested by the unlocked lock icon marked with letter “P”).

[0047] Fig.6 is a high level procedure (i.e., without all steps detailed) for enabling the PDU Set identification and PDU Set based QoS handling with secure metadata delivery. First, the UE 102 and the AS 108 establish 652 a PDU session between the UE and the PSA UPF, and end-to-end encrypted QUIC connection between the UE and the AS. For example, the step 652 may be a UE-initiated PDU session establishment procedure 752 as illustrated in Fig.7 (and described with further details in 3GPP TS 23.502) and the UE initiated QUIC connection (established e.g., as described in IEFT RFC 9000). At 721, the UE sends a non-access stratum (NAS) message to AMF 112Patent Application Attorney Docket Number 0683-103-WO requesting PDU session establishment and indicating an initial request over an N1 reference point (i.e., in an N1 session management container). See Fig.2 system architecture for more details. The AMF 112 then selects 722 an SMF instance and sends 723 to the selected SMF instance (SMF 114) an Nsmf_PDUSession_CreateSMContext Request. The SMF 114 may (i.e., optionally) retrieve 724 the UE’s subscription information from united data management (UDM) 113 and replies 725 to the Nsmf_PDUSession_CreateSMContext Request with an Nsmf_PDUSession_CreateSMContext Response. A PDU Session authentication / authorization 726 follows. Additional steps following the ones illustrated in Fig.7 are described in 23.502.

[0048] Returning to Fig.6, the AS 108 then generates 653 a QUIC session correlation identifier (ID), for example, using a random number. This QUIC session correlation ID may be considered a logical media tunnel identifier and is associated with a QUIC connection / QUIC stream (see 504 in Fig.5) that has specific QoS requirements for the XRM traffic.

[0049] The AS 108 requests 654 the PSA UPF 116 to enable PDU Set identification for End-to-End encrypted XRM traffic and negotiates the metadata secure delivery mechanism. Negotiating the metadata secure delivery mechanism may be performed between the AF 115 and the NEF 119 in the control plane (over N33) as illustrated in Fig.8 or between the AS 108 and the UPF 116 in the user plane (over N6) as illustrated in Fig.9.

[0050] Procedure 660 illustrates XRM traffic delivery from the AS 108 to the UE 102 while using a metadata secure delivery mechanism. The AS 108 performs 662 encryption / integrity protection for the XRM metadata (as suggested by the lock icon labeled “m”) based on security keys negotiated between the PSA UPF 116 and the AS 108 in step 654. The AS 108 then generates 663 the UDP datagram including XRM metadata and the encrypted QUIC packet, (e.g., the XRM metadata may be included in UDP-Option 420 together with the QUIC packet 411 in the UDP payload 410). The AS 108 then transmits 664 the XRM traffic including the UDP datagram to the PSA UPF 116.

[0051] Upon receiving the XRM traffic, the PSA UPF 116: (a) extracts 665 the encrypted XRM metadata included in UDP-Option and also the encrypted QUIC packetPatent Application Attorney Docket Number 0683-103-WO from UDP datagram (in UDP payload); (b) decrypts the XRM metadata (as suggested by the unlocked lock icon labeled “m”); (c) performs PDU Set Identification accordingly; (d) marks GTP-U header with PDU Set information; and (e) forwards 666 the end-to-end encrypted QUIC packet containing the XRM traffic in the downlink direction to the UE 102 via the NG-RAN (not shown).

[0052] Upon receiving the UDP datagram, the UE 102: (a) extracts 668 the QUIC packet of XRM traffic from the received UDP datagram payload, and (b) forwards 669 the decrypted QUIC packet to an upper application layer of the UE.

[0053] Next, Fig.8 is a signal diagram illustrating a first tunnel-less procedure for enabling PDU Set based QoS handling and secure metadata delivery according to an embodiment. This procedure includes a control plane-based metadata secure delivery mechanism negotiation based on setting up an AF session with required QoS procedure in clause 4.15.6.6 of TS23.502 or AF session with required QoS UDPate procedure in clause 4.15.6.6a of TS23.502. This first tunnel-less procedure includes a control plane-based negotiation over N33 (or N6) interface between the AF 115 and the NEF 119 to negotiate security parameters for encryption / integrity protection of metadata. The term “negotiation” here means that the AS or the UPF may propose initial parameters of the metadata secure delivery mechanism (e.g., for generating encryption / decryption keys and / or integrity keys) and lack of a positive rejection of the proposed parameters indicates an agreement between the AS and the UPF concluding the negotiation. Alternatively, the recipient of the initially proposed parameters may confirm the agreement.

[0054] Step 852 is substantively similar to step 652 and may be implemented according to the procedure illustrated in Fig.7 and the UE initiated QUIC connection establishment based on IETF RFC 9000. The phrase “substantively similar” as used in this document indicates that although not strictly identical, two substantially similar steps employ the same type of functions or physical devices and yield both the same output(s) based on the same input(s).

[0055] Procedure 854 illustrates in detail one implementation of step 654. The AF 115 initiates the AF session with QoS by invoking Nnef_AFSessionWithQoS Create service operation as described in TS 23.502. Based on information from AS 108, the AF 115 thus sends an AF request over N33 to NEF 119 (which then forwards the informationPatent Application Attorney Docket Number 0683-103-WO to the PCF 118) or over N5 to PCF 118. To enable the PDU Set Identification for the end- to-end encrypted XRM traffic based on securely delivered metadata, the AF request includes one or more of the following pieces of information: (a) QUIC session Correlation ID, (b) a Protocol Description, and / or (c) security requirements. Although not illustrated in Fig.8, the AS may generate the QUIC session correlation ID as indicated by step 653 in Fig.6. The Protocol Description includes information related to the use of UDP-Option and the Kind value that indicates the use thereof to carry the metadata (i.e., PDU Set Information of the encrypted XRM packet). The Security requirements for metadata encryption / integrity protection include: (i) Encryption / integrity keys, and (ii) validity criterion or criteria for the encryption / integrity keys (e.g., validity timer or start / end time or renewal timer, or maximum number of packets that use the exiting security keys).

[0056] Based on information of the AF 115 sent to the PCF 118 via NEF 119 or directly, the PCF 118 generates and sends 856 a PCC rule to instruct SMF to configure N4 rules for identifying PDU Set information based on metadata included in the UDP option. The PCC rule includes the information (e.g., Protocol Description, security requirements, PDU Set QoS requirements) obtained from AF included in the AF request.

[0057] Based on the PCC rule, the SMF 114 then provides (i.e., generates and sends) 857 N4 rules to the PSA UPF 116. The N4 rules include: (a) the QUIC session Correlation ID for PDU Set Identification; (b) the indication of using UDP-Option for carrying the metadata; and (c) the security requirements for metadata (i.e., the encryption / integrity keys and the validity criteria for security protection of the XRM metadata). The SMF 114 then provides 858 a QoS profile to the NG-RAN 104, and QoS rules to the UE 102 (e.g., in a PDU Session Establishment / Modification Procedure). The configured N4 rules enable the PSA UPF to perform PDU Set Identification and marking for encrypted XRM traffic and PDU Set based QoS handling according to the specific (required) QoS. When the UPF receive the XRM traffic, it performs the following: (i) extract the encrypted XRM metadata included in UDP-Option and the QUIC packet from UDP datagram, (ii) decrypt the XRM metadata, (iii) perform PDU Set Identification accordingly, (iv) mark GTP-U header with PDU Set information, and (v) forward the QUIC packet containing the XRM packets in the downlink direction to the NG-RAN.Patent Application Attorney Docket Number 0683-103-WO

[0058] The N4 rules enable the PSA UPF 116 (i) to extract encrypted metadata from UDP-Option 420, (ii) to decrypt the metadata, and check integrity of the metadata based on current valid security keys, (iii) to identify a PDU that belongs to a PDU Set according to the metadata containing PDU Set Information, (iv) to mark the identified PDU Set information into a GTP-U header, and (v) to manage security keys based on the validity criteria.

[0059] Before expiration of the current security keys according to the validity criteria, the AF 115 may send 862 another request similar to the one sent in step 855 to initiate UDPating the security requirements. Steps 855-859 are then repeated as a step 864. Preferably the UPF / AS do not continue using the invalid security keys after they expire according to the validity criteria.

[0060] Step 860 and optional step 866 correspond to procedure 660 in Fig.6 whereby the UPF 116 forwards the QUIC packet (UDP payload) from the AS 108 to the UE 102 via NG-RAN for PDU Set based QoS handling according to the specific PDU Set QoS.

[0061] Fig.9 is a signal diagram illustrating a second tunnel-less procedure for enabling PDU Set Identification / marking, PDU Set based QoS handling and secure metadata delivery according to another embodiment. Unlike in the first tunnel-less procedure, in this second procedure the metadata secure delivery mechanism is negotiated using user plane-based signaling over N6 interface. Yet again, the encrypted and integrity protected metadata is transmitted using UDP-Option 420 with a new Kind value. Step 952 is substantively similar to steps 852 and 652 and similarly may be implemented as illustrated in Fig.7 and the UE initiated QUIC connection establishment based on IETF RFC 9000. Note that PDU Session is between the UE and the PSA UPF in 3GPP network (to get the IP address, and then uses it as source IP to establish QUIC connection with the AS).

[0062] Procedure 954 illustrates in detail another implementation of step 654. As in the first tunnel-less procedure, the AF 115 initiates an AF session with QoS by invoking Nnef_AFSessionWithQoS Create service operation as described in TS 23.502. Based on information from AS, the AF sends 955 an AF request to the NEF over N33 or to the PCF over N5 to enable the PDU Set Identification for the end-to-end encrypted XRM traffic.Patent Application Attorney Docket Number 0683-103-WO This AF request includes (a) a QUIC session Correlation ID (random number) and / or (b) a Protocol Description with an indication related to the use of UDP-Option and the Kind value that indicates the use of carrying metadata (i.e., the PDU Set Information) of the encrypted XRM packet. However, unlike the AF request in the first tunnel-less procedure described in Fig.8, the AF in this second tunnel-less procedure no longer includes the security requirements (i.e., the initial encryption / integrity keys, and validity criteria for the encryption / integrity keys). The initial encryption / integrity keys, and validity criteria for the encryption / integrity keys are later negotiated 980 between the AS 108 and the PSA UPF 116 (e.g., the AS / AF 108 may provide the security requirements to the PCF 118) in user plane over N6. However the AF request may include an indication of user plane security mechanism for the renewal of the security keys, and information related to the use of UDP-Option and the Kind value indicating that security keys for the encryption / integrity protection of the metadata are included in UDP-Option.

[0063] Steps 956, 957, 958, and 959 are substantively similar to steps 856, 857, 858, and 859 in Fig.8 and, therefore, their description is omitted. The AS 108 then transmits 960 encrypted XRM traffic with secure delivery of metadata to the UE as illustrated in procedure 860. Another user-plane security requirements negotiation of the metadata secure delivery mechanism may (i.e., optionally, as suggested by the dashed line) occur during a User Plane Security Renewal Mechanism 965. For example, step 965 may be triggered by an upcoming validity criterion expiration. The step 965 may also use the UDP-Option 420 for carrying security keys. After step 965, the AS 108 continues transmitting 966 encrypted XRM traffic with secure delivery of metadata to the UE using the renewed encryption keys similar to procedure 866.

[0064] In the second set of embodiments described below, the UPF as HTTP client establishes N6 UDP tunnel with HTTP proxy in the cloud using Connect-UDP upgrade token in tunneled mode or in forwarded mode, whereby Connect ID is used to indicate a specific HTTP datagram format that carries the metadata. The HTTP proxy 109 can proxy UDP in HTTP datagram and perform QUIC aware proxy functionality to forward the UDP datagram between the PSA UPF and the HTTP proxy / application servers in the cloud. In addition, the UDP datagram can encapsulate packets in different formats (e.g., a QUIC datagram frame using HTTP / 3 datagram format).Patent Application Attorney Docket Number 0683-103-WO

[0065] The HTTP proxy 109 encapsulates the end-to-end encrypted QUIC packets into a HTTP / 3 datagram before transmitting them to the PSA UPF via the UDP-tunnel over N6. The QUIC-Aware proxy using HTTP forwards all XRM packets using the Tunneled Mode or Forwarded mode in the UDP-tunnel over N6. If in Tunneled Mode, the HTTP proxy 109 encapsulates and re-encrypts the XRM packet (i.e., QUIC packet), which has a disadvantage of double encryption because XRM payload packets are already encrypted within the QUIC connection between the UE 102 and the AS 108. Figs.10 and 11 are diagrams illustrating XRM traffic with the UDP-tunnel over N6 between the QUIC- aware HTTP proxy 109 and PSA UPF. The QUIC-aware HTTP proxy 109 converts the UDP datagram into an HTTP datagram. The metadata (which includes PDU set information enabling PDU Set identification and therefore PDU Set based QoS) is encrypted (thus, securely delivered) between the HTTP proxy 109 in the cloud and the PSA UPF 116. The metadata may be carried within the UDP-option 420 of the UDP datagram, and / or separately in the HTTP datagram.

[0066] In Fig.10, the HTTP proxy 109 applies the metadata secure delivery mechanism (e.g., security keys) negotiated with the PSA UPF 116 to the UDP datagram 1006 to protect the metadata in the HTTP datagram 1004 (which results in double encryption for the UDP payload, that is, the QUIC packet carrying the XRM traffic) or to protect the metadata in the UDP option 420. IP session 1002 is similar to IP session 502. Within the framework of the End-to-end QUIC connection 1008 the between the UE 102 and the AS 108, data flow between the PSA UPF 116 and the HTTP proxy 109 as well as between the HTTP proxy 109 and the AS 108 (which may be collocated with the AS 108 or both the HTTP proxy 109 and the AS 108 may be in the cloud) is a flow of unreliable messages 1005.

[0067] In Fig.11, the HTTP proxy 109 applies the metadata secure delivery mechanism (e.g., security keys) negotiated with the PSA UPF 116 to the transformed QUIC packet which includes metadata. In this case the end-to-end QUIC connection 1108 carrying the encrypted QUIC packet (as suggested by the icon with “p” in the middle) is made of an HTTP communication between the UE 102 and the PSA UPF 116 using an HTTP datagram 1102 (based on an Internet Protocol, IP), and an end-to-end flow of unreliable messages 1105 between the PSA-UPF 116 and the AS 108. The end-to-endPatent Application Attorney Docket Number 0683-103-WO flow of unreliable messages 1105 consists of a first portion between the AS 108 and the HTTP proxy 109 (which are more likely than not both in the cloud) communicating UDP datagrams 1106 and a second portion, which is an N6 UDP tunnel between the HTTP proxy 109 and the PSA UPF 116 communicating using an HTTP / 3 Extended CONNECT packet including a transformed QUIC and UDP 1104 having both the payload (i.e., the QUIC packet) and the metadata protected as suggested by the icons with “p” and “m” in the middle.

[0068] Figure 12 illustrates a high level procedure for enabling PDU Set QoS identification using an HTTP proxy between the UPF and the AS (as illustrated in Figs.10 and 11) according to an embodiment. The UE 102 and the AS 108 establish 1252 (which is substantially similar to 652) a PDU session as described in Fig.7, and the UE initiated QUIC connection establishment based on IETF RFC 9000. Note that the PDU Session is between the UE 102 and the PSA UPF 116 in 3GPP network (thereby, the UE getting the IP address that the UE then uses as source IP to establish QUIC connection with the AS 108).

[0069] Then, in the step 1254, which is substantially similar to the step 654, AS / AF / HTTP proxy 108 / 115 / 109 requests 1254 the PSA UPF 116 to enable PDU Set identification for End-to-End encrypted XRM traffic including negotiating the metadata secure delivery mechanism. The AS 108, the AF 115, and the HTTP proxy 109 are typically all located in the cloud, which may be considered similar to being collocated with secure communications therebetween. The AF 115 initiates enabling the PDU Set identification for End-to-End encrypted XRM traffic by sending an AF request. The HTTP proxy 109 negotiates the security keys with the PSA UPF 116.

[0070] Upon receiving 1270 an uplink IP packet with a configured destination IP address of the AS 108, the PSA UPF 116 as an HTTP client may trigger establishing 1272 a UDP connection using encapsulation protocol (i.e., an UDP-tunnel over N6 interface) with HTTP proxy in the cloud by sending a Connect-UDP upgrade token in tunneled mode or in forwarded mode. Based on operator’s policies, the PSA UPF 116 determines how to use the UDP tunnel for transporting XRM traffic for different application servers managed by the same HTTP proxy 109 in the cloud (e.g., for one or more XRM applications) or byPatent Application Attorney Docket Number 0683-103-WO the same HTTP proxy in the cloud for a group of UEs. The PSA UPF 116 then establishes 1274 a QUIC connection with the AS 108.

[0071] The procedure labeled 1260 groups steps illustrating an implementation of the AS 108 transmitting encrypted XRM traffic with metadata to the UE 102. In step 1276 or 1277, the AS 108 generates the UDP datagram 400 including metadata and the QUIC packet of XRM traffic. The metadata does not typically need encryption and / or integrity protection at this stage. In one embodiment, however, the metadata is encrypted and / or integrity protected using the same or different session keys based on QUIC layer security mechanism using transport layer security (TLS) between the HTTP client and the HTTP proxy, which mechanism can be negotiated using HTTP protocol.

[0072] According to an embodiment, the HTTP proxy 109 operating in tunneled mode decapsulates the encrypted metadata from the UDP datagram, and decrypts the metadata if needed, and applies 1278 the secure metadata delivery mechanism (e.g., (re-)encrypts the metadata using security keys) to the metadata. The HTTP proxy 109 and the PSA UPF 116 as HTTP client may negotiate the secure delivery mechanism via HTTP protocol (e.g., using Connect-UDP upgrade grant). The Connect-UDP as defined in IEFT RFC 9298 is part of the HTTP protocol, but it leverages the HTTP framework to negotiate and establish a tunnel for proxying UDP datagrams. That is HTTP framework is the foundation because the initial interaction uses HTTP mechanisms (like an Extended CONNECT request with the connect-UDP upgrade token) to set up the tunnel. This negotiation happens within the context of an HTTP connection. Once the tunnel is established, the actual data flows through UDP, not HTTP. IEFT RFC 9297 describes the manner in which the UDP datagrams are encapsulated and carried within the HTTP- negotiated tunnel.

[0073] According to another embodiment, the HTTP proxy 109 operating in forward mode forwards the transformed QUIC packet containing metadata in an HTTP datagram, which metadata is security protected based on QUIC layer security using TLS negotiated between the HTTP client 116 and the HTTP proxy 109. The HTTP proxy 109 then transmits 1264 the HTTP datagram over the N6 UDP tunnel to the PSA UPF 116.

[0074] Upon receiving the HTTP datagram, the PSA UPF 116 extracts and decrypts 1265 the metadata. In tunneled mode, the UPF 116 extracts the metadataPatent Application Attorney Docket Number 0683-103-WO carried in UDP-Option of the UDP datagram (corresponding to 1276) or extracts the metadata and the QUIC packet from the HTTP datagram based on a first specific Context ID. In the forwarded mode, the UPF 116 extracts the metadata from the transformed QUIC packet in the HTTP datagram (corresponding to 1277) based on a second specific Context ID. The PSA UPF 116 then decrypts the metadata (as suggested by the unlocked lock icon labeled “m”), marks the PDU Set Information into a GTP-U header, and forwards the QUIC packet in the downlink direction (i.e., towards the UE 102 via the NG-RAN). The UPF 116 maintains the UDP tunnel over N6 for uplink traffic from the UE 102. Step 1266 is substantively the same as step 666.

[0075] In 1268, upon receiving the UDP datagram, the UE 102 extracts 1268 (which is substantially similar to 668) the QUIC packet of XRM traffic from the UDP datagram payload 410. The UE 102 then forwards 1269 (which is substantially similar to 668) the QUIC packet to the UE’s upper layer.

[0076] Fig.13 illustrates a QUIC datagram frame using HTTP / 3 datagram format 1300 that contains a new Context ID for indicating the format of the UDP datagram payload (based on IETF RFC-9297). The UDP datagram 130 conveyed via an UDP tunnel contains a QUIC packet 1320 whose QUIC DATAGRAM frame hosts a quarter stream identifier (ID) 1322, a context ID 1324 and the UDP datagram payload 1326 which carries application data such a XRM traffic made of RTP frame(s).

[0077] Fig.14 is a signal diagram of a first procedure for securely delivering metadata via an N6 UDP tunnel according to an embodiment. Step 1452 is substantially similar to step 652 and, therefore, its description is omitted. The steps 1455-1459 grouped under label 1454 illustrate a detailed implementation of the step 1254. The AF 115 initiates an AF session with QoS by invoking Nnef_AFSessionWithQoS Create service operation as described in TS 23.502.

[0078] Based on information from AS 108, the AF 115 sends 1455 an AF request to the NEF / PCF 118 over N33 to enable the PDU Set Identification for the end-to-end encrypted XRM traffic. The AF request includes a Protocol Description and / or Security requirements for metadata encryption / integrity protection. The Protocol description includes information related to the use of the UDP-tunnel over N6, that is, one or more of: (i) an indication of using Connect-UDP upgrade token in tunneled mode (including usingPatent Application Attorney Docket Number 0683-103-WO UDP-Option for XRM metadata or using HTTP datagram), or in forwarded mode, (ii) configuration information of N6 tunnel, including an indication of PSA UPF role as an HTTP client, the address of the HTTP proxy in the cloud for the UDP tunnel, and addresses of one or more application server(s) or GPSI of a group of UEs that can use the UDP tunnel managed by the HTTP proxy, and / or (iii) Security requirements for metadata.

[0079] For HTTP proxy operated in tunneled mode, the information of the Context ID of the UDP datagram payload carried in the HTTP datagram may have a first specific format as illustrated in Fig.13. In one example, the context ID specifies (a) that the HTTP datagram encapsulates QUIC packet of the XRM traffic as well as metadata in the UDP- Option 420 and (b) the UDP-Option’s Kind value indicating the use of the UDP-Option 420 for metadata. This UDP-Option’s Kind value is then used when the AS transmits the metadata using the UDP-Option 420. In another example, the context ID specifies that the HTTP datagram encapsulates a first QUIC packet of the XRM traffic and a second QUIC packet with metadata.

[0080] For HTTP proxy operated in forwarded mode (e.g., as in Fig.11), the information of the Context ID of the UDP datagram payload carried in the HTTP datagram may have a first specific format of a transformed QUIC packet. Alternatively, if the Context ID indicates a QUIC datagram frame in HTTP / 3 datagram format, the HTTP proxy applies a pre-configured format of the transformed QUIC packet. In one example, the Context ID represents the transformed QUIC packet is with extended QUIC payload including (a) one or two bits of length information defined for the metadata of the XRM packet, and (b) the metadata of the XRM packet appended either before or after the original QUIC payload of the XRM packet. In another example, the Context ID represents the transformed QUIC packet with extended QUIC payload including a fixed length metadata of the XRM packet appended either before or after the original QUIC payload of the XRM packet.

[0081] The security requirements for metadata encryption / integrity protection may include: (1) an indication that the method of security keys negotiation (e.g., based on QUIC layer TLS or shared keys mechanism or public keys mechanism) is based on HTTP protocol (e.g. using Connect-UDP upgrade grant) between the PSA UPF / HTTP client 116 and the HTTP proxy 109 in the cloud, whereby the encryption / integrity protection of the XRM metadata can be done by the HTTP proxy 109 or AS 108, and (2) validity criteria forPatent Application Attorney Docket Number 0683-103-WO the encryption / integrity keys, e.g., validity timer or start / end time or renewal timer, or maximum number of packets that use the current security keys.

[0082] Based on information of the AF request received 1455 via NEF or directly, the PCF 118 generates and sends 1456 a PCC rule to instruct the SMF 114 to configure the UPF 116 to identify PDU Set information based on the metadata included in the UDP option. The PCC rule includes the information included in the AF request.

[0083] The SMF 114 then provides 1457 N4 rules to PSA UPF 116. The N4 rules may include: (a) an indication of N6 tunnel using Connect-UDP upgrade token in tunneled mode, or in forwarded mode, (b) Configuration Information of UDP tunnel over N6, including indication of UPF role as HTTP client, address of an HTTP proxy in the cloud for UDP tunnel, and addresses of one or more application server(s) or GPSI of a group of UEs that can use the UDP tunnel managed by the HTTP proxy, and / or (c) Security requirements for metadata. For Connect-UDP in tunneled mode (see Fig.10), the configuration information also includes the information of the Context ID that specifies the first specific format of the UDP datagram payload carried in the HTTP datagram. If using UDP-Option 420 to carry the metadata, a specific Kind value is also indicated. For Connect-UDP in forwarded mode (see Fig.11), the configuration information also includes the information of the Context ID that specifies the second specific format of the transformed QUIC packet carried in the HTTP datagram.

[0084] The Security requirements for the metadata, for example, include an indication of security keys negotiation based on HTTP protocol between the PSA UPF / HTTP client 116 and the HTTP proxy 109 in the cloud, and one or more validity criteria for security protection of the metadata.

[0085] Based on N4 rules, the PSA UPF 116 supports the HTTP Client functionality for establishing a UDP tunnel to the HTTP Proxy with the connect-UDP upgrade token in tunneled mode or in forwarded mode. For tunneled mode, the PSA UPF 116 extracts the metadata and the QUIC packet from the HTTP datagram based on a specific Context ID. For forwarded mode, the PSA UPF 116 extracts the metadata from the transformed QUIC packet in the HTTP datagram based on a specific Context ID. Further, the PSA UPF 116 decrypts the XRM metadata and performs PDU Set Identification accordingly, to mark the PDU Set Information into a GTP-U header, to forward the QUIC packet in the downlinkPatent Application Attorney Docket Number 0683-103-WO direction towards the UE via the NG-RAN, and to manage UDP tunnel over N6 for media transport for one or more UE(s). Steps 1458 and 1459 are substantially similar to steps 858 and 859.

[0086] Upon receiving 1470 an uplink packet with the destination AS address from the UE, in view of the configuration information of HTTP proxy / AS 109 address, the PSA UPF 116 (which operates as the HTTP client) establishes 1472 a UDP tunnel over N6 towards the HTTP proxy 109 and the AS 108 and a QUIC connection as in 1274.

[0087] The AS 108 then transmits 1460 encrypted XRM traffic in the downlink direction substantially in the same manner as described in the steps grouped under label 1260. Thus, the UPF / HTTP proxy 116 forwards the original QUIC packet with XRM traffic to the UE in the downlink direction.

[0088] Before expiration of validity criteria for the existing security keys, the PSA UPF 116 and the AS 108 negotiate 1462 new security keys over N6 UDP tunnel based on HTTP protocol so that the UPF and the AS do not use invalid security keys for the metadata.

[0089] In a third set of embodiments described below, the UE 102 is an HTTP client and establishes an UDP tunnel with the PSA UPF 116 as the HTTP proxy, using Connect- UDP upgrade token in forwarded mode. In the third set of embodiments, the AS may transmit the metadata (A) using the UDP-option 420 or using a transformed QUIC that includes the metadata with the original QUIC payload (e.g., as in Fig.11). In view of Fig.4, Fig.15 illustrates a UDP datagram 1500 that includes an IP header 1501, a UDP header 1502 and the UDP payload 1510. The UDP payload 1510 carries a transformed QUIC packet (based on QUIC-Aware Proxying Using HTTP as in IETF draft-ietf-masque-quic- proxy-01) including QUIC header 1512 and QUIC payload 1514 with at least one RTP header, RTP payload, and metadata.

[0090] Fig.16 is a diagram that illustrates an end-to-end QUIC connection 1608 for transporting encrypted XRM traffic over N6 interface, whereby the UE 102 as an HTTP client establishes a UDP-tunnel with the PSA UPF 116 as an HTTP proxy using Connect- UDP upgrade token in forwarded mode. The PSA UPF 116 converts the UDP 1606 into an HTTP datagram 1604. The PSA UPF 116 thus performs a QUIC aware proxy functionality to forward the UDP datagram carrying XRM traffic from the AS 108 in the cloud to the UEPatent Application Attorney Docket Number 0683-103-WO 102. This method avoids re-encapsulation and re-encryption because the XRM packets are forwarded using the Forwarded Mode in QUIC-Aware Proxying using HTTP.

[0091] Fig.17 is a signal diagram illustrating a third high level procedure for enabling PDU Set QoS handling with the UE as an HTTP client and the UPF as an HTTP proxy according to an embodiment.

[0092] Upon receiving an upper layer request, or an uplink IP packet with a configured destination IP address of the AS, the UE 102 as an HTTP client triggers establishment of a UDP connection using encapsulation protocol (i.e., a UDP tunnel with PSA UPF as an HTTP proxy by sending Connect-UDP upgrade token in forwarded mode). Based on operator’s policies, the PSA UPF 116 determines the manner of using the UDP tunnel for transporting XRM traffic in different scenarios for different ASs managed by the same HTTP proxy (e.g. for one or more XRM applications of one or more UEs). Thus, step 1752 represents establishing a PDU session and connection between the UE 102 and the AS 108 via the PSA UPF 116 (the detailed description is not repeated).

[0093] In other words, step 1752 is similar to step 652 with the following additions: (i) the PDU Session Establishment / Modification Request message indicates capability of HTTP client for UDP tunnel in forwarded mode for handling encrypted XRM traffic, and (ii) the PDU Session Establishment Accept message or PDU Session Modification Command message includes HTTP proxy address information at PSA UPF in protocol configuration options (PCO) information element (IE) or an extended PCO (ePCO) IE.

[0094] During the procedure 1754, which may be initiated by an AF request (e.g., the AF initiates the AF session with QoS by invoking Nnef_AFSessionWithQoS Create service operation, for example, as described in 3GPP TS 23.502), the AS obtains security keys from the UE for XRM metadata encryption via application layer signaling. The security keys are negotiated based on HTTP protocol between the UE / HTTP client 102 and the PSA UPF / HTTP proxy 116 enabling the AS to encrypt the XRM metadata using the security keys. The AS is also enabled to transform an original QUIC packet by adding XRM metadata to the original QUIC packet that contains XRM traffic (see Fig.15) to create a transformed QUIC packet 1511, and to transport the UDP datagram 1500 including transformed QUIC packet to the UPF / HTTP proxy 116.Patent Application Attorney Docket Number 0683-103-WO

[0095] The UE 102 then establishes 1790 a UDP tunnel with HTTP proxy / PSA UPF 116 using Connect-UDP upgrade token, and then establishes 1792 an End-to-End QUIC connection with the AS 108. The following steps 1776 and 1777 are substantially similar to the steps 1276 and 1277. In step 1778, the AS 108 transmits the encrypted XRM traffic and the metadata to the UE 102. The AS 108 then transmits 1760 (which is substantially similar to 1260) the encrypted XRM traffic and metadata to the UE 102.

[0096] Fig.18 is a signal diagram of a procedure for enabling PDU Set QoS handling with secure delivery of metadata, according to yet another embodiment. After step 1852, which is substantially similar to step 1752 discussed above, procedure 1854 illustrates in detail an implementation of step 1754. Based on information from the AS 108, the AF 115 sends 1855 an AF request to the PCF 118 via NEF 119 over N33 or directly over N6. The AF request includes information enabling the PDU Set identification for the end-to-end encrypted XRM traffic. The AF request includes a Protocol Description that includes information related to the use of the UDP-tunnel over N6, and / or Security requirements for the metadata encryption / integrity protection.

[0097] The information related to the use of the UDP-tunnel over N6 includes one or more of: (i) an indication of using Connect-UDP upgrade token in forwarded mode; (ii) Configuration Information of UDP tunnel, including indication of PSA UPF role as HTTP proxy, IP address of the UE as HTTP client, and addresses of one or more application server(s) that can use the N6 tunnel managed by the PSA / UPF HTTP proxy; and / or (iii) Context Type ID information represents the type of protocol packets (e.g., QUIC per Fig. 15 or UDP-Option per Fig.4, used by the metadata which is included in the UDP datagram). The Context type ID may indicate UDP-Option for metadata in the UDP datagram, and a Kind value indicates the manner of conveying the metadata carrying PDU Set information. The Context type ID may additionally or alternatively indicate the use of transformed QUIC packet with a specific format that extends QUIC payload with metadata such as: (A) one or two bits of length information defined for the metadata of the XRM packet; (B) the metadata of the XRM packet appended before the original QUIC payload of the XRM packet or after the original QUIC payload of the XRM packet; (C) the extended QUIC payload includes a fixed length metadata of the XRM packet appended before thePatent Application Attorney Docket Number 0683-103-WO original QUIC payload of the XRM packet or after the original QUIC payload of the XRM packet.

[0098] Security requirements for metadata encryption / integrity protection indicates: (i) the method of security keys negotiation based on HTTP protocol between the UE 102 and PSA UPF / HTTP proxy 116, and (ii) validity criteria for the encryption / integrity keys. The encryption / integrity protection of the metadata is done by the AS 108 which obtains the security keys information from the UE 102 in the application layer signaling. The validity criteria for the encryption / integrity keys may be, for example, a validity timer or start / end time or renewal timer, or a maximum number of packets that can use the existing security keys.

[0099] Based on information in the AF request, the PCF 118 generates and sends 1856 a PCC rule to instruct SMF / UPF 114 / 116 to identify PDU Set information based on metadata included in UDP option 420 or transformed QUIC packet 1511. The PCC rule includes the information obtained from AF 115 included in the AF request in step 1855.

[0100] The SMF 114 then provides 1857 N4 rules to the PSA UPF 116. The N4 rules include an indication of N6 tunnel using Connect-UDP upgrade token in forwarded mode, configuration information of the UDP tunnel, a context type ID, and / or security requirements. The configuration information of the UDP tunnel includes an indication of the PSA UPF role as HTTP proxy, an IP address of the UE 102 as HTTP client, and addresses of one or more application server(s) that can use the N6 tunnel managed by the PSA / UPF HTTP proxy 116. The context type ID represents the type of protocol packets (e.g., QUIC 1511 or UDP-Option 420) used to convey the metadata via the UDP datagram over N6. The security requirements for metadata include (i) an indication of the method of security keys negotiation based on HTTP protocol between the UE / HTTP client 102 and the PSA UPF 116 as an HTTP proxy, and (ii) the validity criteria for security protection of the metadata

[0101] Based on N4 rules, the PSA UPF 116 supports the HTTP Proxy functionality in order to manage a UDP tunnel with the UE as HTTP client using connect-UDP upgrade token in forwarded mode. The PSA UPF 116 is thus able to extract the encrypted metadata from the transformed QUIC packet 1511 in the UDP datagram 1500 based on a specific Context ID or Context ID with Kind value for the use of UDP-Option for XRMPatent Application Attorney Docket Number 0683-103-WO metadata. The PSA UPF 116 then decrypts the metadata for performing PDU Set identification accordingly. Based on identified PDU Set, the PSA UPF marks the PDU Set information into GTP-U header and forwards the QUIC packet in the downlink direction to the UE via the NG-RAN for PDU Set based QoS handling). That is, the PSA UPF manages the UDP tunnel with the UE 102 as HTTP client for XRM traffic. Steps 1858 and 1859 are substantially similar to steps 858 and 859.

[0102] Upon receiving an uplink packet from the upper layer and configuration information of HTTP proxy / PSA UPF address, the UE establishes 1892 a UDP tunnel towards HTTP proxy at the PSA UPF 116 and an end-to-end QUIC connection between the UE 102 and the AS 108 based on RFC 9000. The step 1892 is substantially similar to step 1792 described above.

[0103] The step 1860 is substantially similar to procedure 1760 for transmitting XRM traffic in the downlink direction with secure delivery of the metadata to the UE.

[0104] Before expiration of validity criteria for the current security keys for the metadata, the UE and PSA UPF may negotiate new security keys over the UDP tunnel thus enacting a security renewal 1862, based on HTTP protocol. The UE 102 then uses the renewed security keys when communicating with the AS 108.

[0105] Reference throughout this section to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

[0106] Numerical adjectives “first”, “second”, and “third” do not imply any order (are not ordinals) but are markers to distinguish separate instances of similar elements. References to the singular (e.g., “a” or “an”, “the”) should include the plural unless clearly indicated otherwise.

[0107] As used herein, a phrase referring to “at least one of” or “one or more of” a list of items refers to any combination of those items, including single members. For example, “at least one of: a, b, or c” is intended to cover the possibilities of: a only, b only,Patent Application Attorney Docket Number 0683-103-WO c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0108] Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.

Claims

Patent Application Attorney Docket Number 0683-103-WO WHAT IS CLAIMED IS:

1. A wireless communication method (300) performed by a network entity, NE, (140) of core network, CN, that executes a user plane function, UPF, (116) to forward, traffic received from a traffic source (108) to a user equipment, UE, (102), the method comprising: establishing (354) a metadata secure delivery mechanism with the traffic source; retrieving (365), from a User Datagram Protocol, UDP, datagram received from the traffic source, metadata associated with the UDP datagram, the metadata being retrieved based on the metadata secure delivery mechanism and indicating that a payload of the UDP datagram pertains to a PDU Set to be handled with a specific QoS; and forwarding (366) the payload of the UDP datagram towards the UE according to the specific QoS.

2. The wireless communication method of claim 1, wherein the UDP datagram carries a Quick UDP Internet Connections, QUIC, packet with a QUIC packet payload including one or more Real Time Protocol, RTP, packets.

3. The wireless communication method of claims 1 or 2, wherein the metadata is included in a UDP Option portion of the UDP datagram.

4. The wireless communication method of claim 3, wherein a Kind field of the UDP Option portion has a value indicating that the traffic source uses the metadata secure delivery mechanism.

5. The wireless communication method of any of claims 1 to 4, wherein the metadata secure delivery mechanism employs an encryption key for encrypting the metadata included in the UDP datagram, and the retrieving includes decrypting the metadata using a decryption key corresponding to the encryption key.Patent Application Attorney Docket Number 0683-103-WO 6. The wireless communication method of any of claims 1 to 5, further comprising: configuring the metadata secure delivery mechanism based on security requirements provided by the traffic source to a policy control function, PCF, via a network exposure function, NEF, or directly from the traffic source over an N33 reference point, the UPF, the PCF, the NEF, and the N33 reference point being defined in 3GPP technical specifications.

7. The wireless communication method of claim 6, further comprising: renewing the security requirements or the metadata secure delivery mechanism.

8. The wireless communication method of claim 7, wherein the renewing of the metadata secure delivery mechanism is a control plane procedure.

9. The wireless communication method of claim 7, wherein the renewing of the metadata secure delivery mechanism is a user plane procedure.

10. The wireless communication method of any of claims 6 to 9, wherein the security requirements include: an indication of security keys negotiation based on an HTTP protocol between the UPF as an HTTP client and an HTTP proxy relaying the UDP datagram from the traffic source to the UPF; and / or a validity criterion for parameters of the metadata secure delivery mechanism.

11. The wireless communication method of any of claims 1 to 5, further comprising: establishing an UDP tunnel with the UE as an HTTP client, the UPF operating as a proxy converting the UDP datagram received from the traffic source into an HTTP datagram.Patent Application Attorney Docket Number 0683-103-WO 12. The wireless communication method of claim 11, wherein the establishing the UDP tunnel includes: receiving a packet data unit, PDU, session establishment / modification request from the UE, the PDU session establishment / modification request indicating a capability of the UE to operate as the HTTP client for the UDP tunnel in a forwarded mode to handle encrypted traffic; and transmitting a response to the PDU session establishment / modification request, the PDU session establishment accept or the PDU session establishment / modification request including an HTTP proxy address.

13. The wireless communication method of claim 11 or 12, wherein the establishing the metadata secure delivery mechanism includes receiving one or more of: (a) an indication of using Connect-UDP upgrade token in a forwarded mode, (b) configuration information of the UDP tunnel including an Internet Protocol, IP, address of the UE as the HTTP client, and / or an address of the traffic source allowed to use an N6 UDP tunnel to the UPF, (c) context type identifier information specifying types of protocol packets included in the UDP datagram, and / or (d) security requirements for the metadata secure delivery mechanism.

14. The wireless communication method of any of claims 1 to 13, wherein the traffic is an extended reality and media, XRM, traffic.

15. A network entity, NE, (140) comprising a processor (142) and a transceiver (144, 146) configured to cooperatively execute the methods of claims 1 to 14.

Images