Quality of service provisioning for application traffic in a communication system

Abstract

This disclosure provides systems, methods and apparatuses for implementing quality-of-service (QoS) for protocol data unit (PDU) Set handling of an application packet in an application service data flow between an application server (AS 150) and a user equipment (UE 102). An application function (AF 170) can request QoS for various media streams (or media traffic types). The AF provides QoS requirements and traffic detection information (including media stream identification information) to a session management function (SMF 115). The SMF configures (162) a user plane (198) with PDU Set identification information and traffic detection information to enable the user plane to implement a PDU Set based QoS handling at a radio access network, RAN, (105) and a user plane function, UPF, (160). The AS transmits (172) an application packet that includes metadata matching the traffic detection information (and media stream identification information) to enable the UPF to identify the PDU Set for the media stream.

Description

Docket No. 14730694300PCT QUALITY OF SERVICE PROVISIONING FOR APPLICATION TRAFFIC IN A COMMUNICATION SYSTEM CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This Patent Application claims benefit of priority to U.S. Provisional Patent Application No. 63 / 598,540, filed November 13, 2023, entitled “QOS PROVISIONING FOR ENCRYPTED XRM TRAFFIC IN A COMMUNICATION SYSTEM” and assigned to the assignee hereof, the disclosure of which is incorporated by reference in this Patent Application. FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communication and some aspects enable traffic detection and identification of encrypted traffic associated with protocol data unit (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. As bandwidth capabilities increase, new applications and services can enjoy high data rates and low-latency. In some cases, a base station can transmit to a user device, or a user equipment (UE), data associated with extended reality and media (XRM) service, which refers to such technologies as eXtended Reality (XR), Augmented Reality (AR), Virtual Reality (VR), Mixed Reality (MR), or cloud gaming, among other examples. The technologies generally involve quasi-periodic streaming of audio and / or video data.

[0005] The 3rd Generation Partnership Project (3GPP) is developing technologies 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. To support XR communications (or, more generally, a data-intensive service), an application executing on a UE can receive or originate a data burst. The 5G core network (CN) and radio access network (RAN) transport data via a protocol data unit (PDU). A data burst can beDocket No. 14730694300PCT understood as multiple units (e.g., PDUs) communicated within a relatively short period of time. A PDU refers to a unit of information (e.g., packetized data) at a protocol layer. A payload of application data can be split into more than one PDU for transmission via the network. A “PDU Set” refers to one or more PDUs carrying the payload of one unit of application-level information (e.g., frame(s) or video slice(s) etc. for XR Services). The PDUs for a PDU Set can correspond to the same Quality-of-Service (QoS) flow through the network (e.g., including a core network (CN) and a radio access network (RAN)). The network manages QoS flows based on the QoS requirements for a PDU Set.

[0006] A next generation radio access network (NG-RAN) may be aware of XRM services the 5G CN provides. Application awareness (or XR-awareness) refers to a technique in which the CN can inform the NG-RAN some information about the PDU Set. For example, if the NG-RAN fails to receive one PDU in the PDU Set from the CN, the NG-RAN may discontinue transmitting other PDUs of that PDU Set over a radio access network. Thus, the NG-RAN can conserve bandwidth and / or power since the PDU Set (not including the lost PDU) would be incomplete and unusable. Current technologies for application awareness are limited. Better coordination between the 5GS and XRM applications may enhance QoS and policy for XR services and media service transmissions. BRIEF SUMMARY

[0007] The systems, methods, and apparatuses of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

[0008] One innovative aspect of the subject matter described in this disclosure can be implemented as a method of a user plane function (UPF) in a core network (CN) of a wireless communication system. The method includes the UPF receiving, via a control plane of the CN, a configuration including at least one rule for protocol data unit (PDU) Set based quality of service (QoS) handling of a plurality of media streams of an application service data flow. The configuration includes traffic detection information and one or more QoS parameters associated with the plurality of media streams. The traffic detection information includes media stream identification information for at least a first media stream of the plurality of media streams. The method includes the UPF receiving a first application packet including metadata. The method includes the UPF identifying a PDU Set for the first media stream of the plurality of media streams based on the metadata matching the traffic detection information and the media stream identification information for the first media stream. The method includes the UPF communicating the first application packet via one or more PDUsDocket No. 14730694300PCT in the PDU Set to a radio access network (RAN) for transmission to a user equipment (UE) fulfilling the one or more QoS parameters.

[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method of a policy control function (PCF) of a CN of a wireless communication system. The method includes the PCF receiving an application request for QoS for one or more media streams of an application service data flow between an application server (AS) and a user equipment (UE) and application assistance information including media stream identification information associated with the one or more media streams. The method includes the PCF generating a policy and charging control (PCC) rule based on the application request, the PCC rule being specific to a first media stream of the one or more media streams, and transmitting the PCC rule to a session management function (SMF) of the CN.

[0010] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method of an SMF in a CN of a wireless communication system. The method includes the SMF receiving a PCC rule from a PCF of the CN based on an application request for QoS for a plurality of media streams of an application service data flow between an AS and a UE and application assistance information associated with the media stream. The method includes the SMF configuring a RAN with a QoS profile based on a requested QoS for the media stream. The method includes the SMF communicating a configuration to a UPF of the CN, the configuration including at least one rule for PDU Set based QoS handling of a first media stream of the plurality of media streams. The configuration includes traffic detection information based on the application assistance information. The traffic detection information includes media stream identification information for at least the first media stream of the plurality of media streams, and one or more QoS parameters for a PDU Set associated with the first media stream of the plurality of media streams.

[0011] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method of an application function (AF). The method includes the AF communicating a request to a control plane of a CN, the request indicating a QoS requirement for at least a first media stream of a plurality of media streams of an application service data flow between the AS and a UE. The request including application assistance information including media stream identification information associated with the first media stream.

[0012] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method of an AS. The method includes the AS communicating, to a UPF of the CN, an application packet for the first media stream. The application packet includesDocket No. 14730694300PCT metadata for matching to traffic detection information that is based on the media stream identification information.

[0013] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus that includes a communication unit and a processing system configured to control the communication unit to implement any one of the above-referenced methods.

[0014] Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Like reference numbers and designations in the various drawings indicate like elements. Note that the relative dimensions of the figures may not be drawn to scale. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0016] FIG. 1A shows an example wireless communication system and protocol data unit (PDU) Set based quality of service (QoS) handling.

[0017] FIG.1B shows a block diagram of an example wireless communication system, such as 5GS, that supports PDU Set handling using the techniques of this disclosure.

[0018] FIG. 2 shows a block diagram of an example protocol stack according to which the UE of FIG. 1B can communicate with the RAN of FIG. 1B.

[0019] FIG. 3 shows 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.

[0020] FIG. 4 shows a service-based reference-point based representation of the 5GS architecture, including the overall non-roaming reference architecture of policy and charging control framework for the 5GS.

[0021] FIG. 5 shows a high-level messaging diagram of an example scenario in which a UE uses extended reality and media (XRM) services using PDU Set handling.

[0022] FIG. 6 shows an example IP packet structure with an example quick user datagram Internet connection (QUIC) payload having one example real-time protocol (RTP) packet sent over N6 to PDU session anchor user plane function (PSA UPF) in 5G network.Docket No. 14730694300PCT

[0023] FIG. 7 shows an example IP packet structure with an example QUIC payload having one or more RTP packets sent over N6 to PSA UPF in 5G network.

[0024] FIG. 8A shows another example IP packet structure sent over N6 to PSA UPF in 5G network;

[0025] FIG. 8B shows example metadata.

[0026] FIG. 9 shows an example procedure for enabling PDU Set based handling, including PDU Set based QoS provisioning, traffic detection and PDU Set Identification, for end-to- end encrypted traffic in 5G network.

[0027] FIG. 10 shows example operations of a PSA UPF.

[0028] FIG. 11 shows example operations of a policy control function (PCF) of a 5GS.

[0029] FIG. 12 shows example operations of a session management function (SMF) of a 5GS.

[0030] FIG. 13 shows example operations of an application server.

[0031] FIG. 14 shows a block diagram of an example wireless communication system showing hardware features and communication interfaces. DETAILED DESCRIPTION

[0032] The following description is directed to certain implementations for the purpose of describing innovative aspects of this disclosure. However, a person having ordinary skill in the art will readily recognize that the teachings herein can be applied in a multitude of different ways. Some of the examples in this disclosure are based on wireless communication according to the 3rd Generation Partnership Project (3GPP) wireless standards, such as the 4th generation (4G) Long Term Evolution (LTE) and 5th generation (5G) New Radio (NR) standards. However, the described implementations can be implemented in any device, system, or network that is capable of transmitting and receiving radio frequency signals according to any of the wireless communication standards, including any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 or 802.16 wireless standards, or other known signals that are used to communicate within a wireless, cellular, or internet-of-things (IoT) network, such as a system utilizing 4G, 5G, 6th generation (6G), ZigBee, Bluetooth, WiFi, or future radio technology.

[0033] A user equipment (UE) can receive application data from an application server (AS) via a communication network. In the case of a wireless communication system, such as a 5G system (5GS), the core network (CN) and a radio access network (RAN) transport data via protocol data unit (PDUs). Typically, a protocol data unit (PDU) session anchor user planeDocket No. 14730694300PCT function (PSA UPF) (herein referred to as “UPF” for brevity) of the CN receives an application packet and prepares a PDU Set for transmission via the RAN. In some implementations, the application packet carries encrypted traffic. Absent the techniques of this disclosure, a UPF may be unable perform PDU Set identification for end-to-end encrypted traffic, when media packet header information necessary for PDU Set identification is partially or fully encrypted. It is possible for an application (such as extended reality and media (XRM)) to generate traffic with multiple media types (e.g., voice, video, text, haptics, among other examples), each having different quality-of-service (QoS) requirements.

[0034] This disclosure provides systems, methods, and apparatuses for fulfilling QoS of application traffic having multiple media streams over a wireless communication system. Examples of this disclosure are based on a 5GS and an XRM application. However, the techniques can apply to different types of communication networks that transport data bursts for applications having QoS parameters (such as low latency) on a per-media-stream basis (or per-media-type basis). The application (such as XRM application) may provide application layer data via one or more application packets. The application packet can encapsulate one or more real-time protocol (RTP) packets for one or more media streams. In some implementations, the RTP packets are encapsulated in a quick user datagram protocol (UDP) connection (QUIC) packet that is carried in a UDP payload of an internet protocol (IP) packet. This disclosure provides a mechanism to make PDU Set Identification possible on a per- media-stream basis at the UPF. In some implementations, a transport layer protocol (such as QUIC) can carry multiple media streams (e.g., for different media types). The AS can provide metadata for media stream identification and PDU Set identification in a 5G network using a UDP-Option field. The metadata enables the wireless communication system to determine which media stream (or media traffic type) is carried in the RTP packets so that when the application packet is transported as a PDU Set in the RAN, the PDU Set has QoS handling based on QoS requirements for the media stream.

[0035] In some instances, several media streams can be multiplexed on a single IP 5-tuple with a transport protocol such as the one described in IETF RFC 9000, using different QUIC connections or different QUIC streams (these can be identified by a unique Connection ID + Stream ID). A 5-tuple refers to a set of five elements that uniquely identify a network connection. These elements typically include: source IP address, destination IP address, source port number, destination port number, and protocol (e.g., TCP, UDP). Because an application can have multiple media streams that share the same internet protocol (IP) 5-tuple, absent the techniques of this disclosure, the UPF may be unable to determine which media stream is carried in each application packet. In accordance with aspects of this disclosure, aDocket No. 14730694300PCT wireless communication system can support differentiated QoS for multiplexed media streams when these streams share the same IP 5 tuple. Several media streams may be multiplexed on the same end-to-end transport layer connection. Multiple RTP flows, real-time control protocol (RTCP) flows, and non-RTP flows can be distinguished even if they are carried on the same QUIC connection.

[0036] The techniques of this disclosure address at least the following issues: (i) when QUIC packets travel through a wireless communication system, the middle network entities might change the QUIC connection during network migration and it may be unclear how to enable the association between a QUIC connection and the RTP sessions of the QUIC connection; (ii) it may be unclear what information needs to be made aware by the 5G network for traffic detection and PDU Set identification; and (iii) it may be unclear how the 5GS performs traffic detection, traffic identification and QoS Flow mapping for multiplexed media streams of different media types with different QoS requirements within a single end-to-end transport connection.

[0037] In accordance with aspects of this disclosure, a control plane of the 5GS obtains QoS requirements for various media streams of the application service data flow. A CN entity (such as a policy control function (PCF) or network exposure function (NEF)) of the 5GS can receive a request indicating the requested QoS for each of a plurality of media streams and application assistance information associated with the media streams. Application assistance information can be referred to by other terms, such as traffic detection assistance information, QoS assistance information, XRM awareness information, etc.). In accordance with aspects of this disclosure, the application assistance information includes information based on media traffic types associated with different media streams. For each media stream, the control plane can map a requested QoS to a QoS profile and configure the QoS profile in a radio access network (RAN), such as a next generation RAN (NG-RAN). The control plane prepares traffic detection information based on the application assistance information and provides the traffic detection information to the UPF. For example, a session management function (SMF) can provide the traffic detection information and one or more QoS parameters to the UPF to cause the UPF to apply the one or more QoS parameters to a PDU Set carrying an application packet when the application packet includes metadata matching the traffic detection information on a per-media-stream basis. The traffic detection information can differentiate different media traffic types. For example, the traffic detection information can include media stream identification information that corresponds to particular media streams.

[0038] An application function (AF) (or an application server, AS) can request QoS for media streams and provide the application assistance information to the 5GS. For example,Docket No. 14730694300PCT the AF can provide the QoS requirements and application assistance information to the PCF of the CN. For each media stream, the PCF can prepare a policy and charging control (PCC) rule based on the requested QoS and application assistance information. The SMF uses the PCC rule to configure the UPF with the traffic detection information and one or more QoS parameters. To enable QoS in the 5GS, the AF communicates the request with application assistance information. The application assistance information enables the 5GS to identify a stream with different media types and corresponding QoS parameters. The PCF prepares PCC rules based on the QoS parameters. The SMF applies the PCC rules via QoS Flows in the RAN and N4 rules that the SMF provides to the UPF. The application assistance information also enables the SMF to configure the UPF for PDU Set identification.

[0039] When the AS communicates application packets for the media stream to the UPF, the AS populates the application packets with the metadata to enable the UPF to perform traffic detection (as well as media stream identification) based on the N4 rules. For example, the AS can include the metadata in a UDP-Option field appended or prepended to a UDP payload of an application packet. Because the UDP payload of the application packet may be encrypted, the UPF may be unable to retrieve information from the RTP header extension field. The AS populates the unencrypted UDP-Option field with metadata to enable the UPF to match the application packet to the PDU Set Information for a QoS Flow. In some implementations, the metadata includes information based on the RTP header extension field to enable the UPF to identify a stream based on the media type and apply the PDU Set based QoS handling. The RTP header extension (or RTP header extension field) can also be referred to as an “RTP extension header” (or RTP extension header field).

[0040] Particular implementations of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. A 5GS can enable QoS handling on a per-PDU-Set basis and per-media-stream basis for application packets of an application service data flow. The AS can coordinate QoS requirements with the 5GS so that application packets can be conveyed in a PDU Set with end-to-end QoS through the core network and RAN. In some aspects, the application packet includes the metadata in an unencrypted portion (such as an UDP-Option field) and includes the application data in an encrypted portion such as the UDP payload. A potential technical advantage of including the metadata in the UDP-Option is that the UPF can quickly perform traffic detection and media stream identification for various media streams. Because the metadata can include media stream identification information, a transport layer protocol can support multiple media streams without requiring multiple transport layer protocol sessions. This enables the network elements (such as network address translation (NAT) entities and firewalls) is to conserveDocket No. 14730694300PCT ports. The 5GS can use the techniques of this disclosure for application packets in tunneled or tunnel-less implementations of a user plane network.

[0041] Although examples of this disclosure are based on downlink application traffic (e.g., from AS to UE via the 5GS), the techniques of this disclosure can be applied to uplink application traffic (e.g., from the UE to the AS via the 5GS). For example, a UE can transmit uplink application traffic to the AS via the RAN and UPF. An application client at the UE can include the UDP-Option field with metadata to provide media stream identification information. The metadata can include media information based on the RTP header extension. The UE can mark the PDUs with PDU Set Information associated with a QoS flow in the RAN. In some implementations, the UE implements features similar to the PSA UPF described in examples of this disclosure to implement traffic detection and PDU Set identification. The NG-RAN can use the PDU Set information to manage uplink radio resources.

[0042] FIG. 1A shows an example wireless communication system 100A and PDU Set based QoS handling. The example wireless communication system 100A shows a control plane 199 and a user plane 198 of a CN in a 5GS (sometimes referred to as a 5GC). An access and mobility management function (AMF) and an SMF are shown collectively as AMF / SMF 115. A PCF and a network exposure function (NEF) are shown collectively as PCF / NEF 114. An AF 170 can be included in the CN or can be collocated with an AS 150. The AMF / SMF 115, the PCF / NEF 114, and the AF 170 form part of a control plane 199 of the 5GS. Application data traverses a user plane 198, which includes a UPF 160, the RAN 105, and the UE 102. The UPF 160 can also be referred to as a PDU session anchor user plane function (PSA UPF). The control plane 199 controls operation of the user plane 198 using non-access stratum (NAS) control messages. In the UE 102, a modem 164 may provide physical layer (PHY) access to the RAN 105 via a radio interface (referred to as a “Uu” interface). The UE 102 also can operate an application 190 (such as using an application processor, not shown) that sends / receives data to / from the AS 150.

[0043] FIG. 1A also shows some of the network interfaces between various elements, including an N5 interface between the AF 170 and the PCF / NEF 114, an N4 interface between the AMF / SMF 115 and the UPF 160, and an N6 interface between the AS 150 and the UPF 160. The UPF 160 communicates with the RAN 105 via an N3 interface. The AMF (in AMF / SMF 115) controls the RAN 105 via an N2 interface, and the AMF controls the UE 102 via an N1 interface. In some examples of this disclosure, the AS 150 serves an XRM application and can include an XR Data Server. The application 190 can be an XR / AR / VR / MR application. In a 5GS, the RAN 105 may implement 5G new radio (NR) andDocket No. 14730694300PCT may be referred to as a next generation RAN (NG-RAN). The NG-RAN 105 receives, from the SMF 115 over the N2 interface, PDU Set QoS parameters in a QoS profile. The NG-RAN 105 further receives, from a UPF 160 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.

[0044] To support PDU Set based QoS handling for XRM services, a PSA UPF 160 identifies PDUs that belong to PDU Sets and determines the below PDU Set Information, based on the RTP header extension defined in 3GPP TS 26.522, which it sends to the NG- RAN 105. In some implementations, the UPF 160 sends the PDUs via a GPRS tunneling protocol user plane (GTP-U). The UPF 160 can send the PDU Set information in a GTP-U header. The NG-RAN 105 uses the PDU Set information for PDU Set based QoS handling as 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, and (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.

[0045] The usage of end-to-end encryption is broadly deployed in current networks to provide security and may be used for XR and Media (XRM) applications. Typically, the PSA UPF in a 5G network cannot perform PDU Set Identification as indicated in 3GPP TS 23.501, 3GPP TS 23.502, 3GPP TS 23.503, or 3GPP TS 26.522 for example, from end-to-end encrypted traffic when media packet header information necessary for PDU Set identification is partially or fully encrypted. When considering end-to-end encryption for media traffic, RTP over QUIC is a promising protocol that allows RTP (real-time transport protocol) packets to be encapsulated within QUIC packets via QUIC streams and datagrams to transport real-time data within a QUIC connection for a specific IP 5 tuple. In some implementations, it is possible to provide media packet header information necessary for PDU Set identification in a 5G network using a UDP-Option field of an application packet that includes a UDP payload with encrypted application data. However, improvements are needed to make PDU Set Identification possible at PSA UPF in 5G network. When QUIC packets traverse through the network, a QUIC connection may be changed by the middle network entities during network migration. Traditional 5G deployments may not associate a QUIC connection with the RTP sessions of the QUIC connection. When a QUIC connection encapsulates an RTP packet, e.g. I / P / B frame, it is not clear what information that needs to be made available (e.g., via an UDP- Option field) to the 5G network for traffic detection.Docket No. 14730694300PCT

[0046] This disclosure provides solutions and potential technical advantages to enable PDU Set related handling for end-to-end encrypted traffic using RTP over QUIC. Using the techniques of this disclosure, an AS (such as for an XRM application) can send data traffic of different media components with different QoS requirements. When the UPF 160 operates as a PDU Sesson Anchor (PSA) UPF, to support PDU Set based QoS handling for an application (such as XRM services), the UPF 160 identifies PDUs that belong to PDU Sets and determines the PDU Set Information. In accordance with this disclosure, the UPF 160 determines the PDU Set information based on traffic detection information, where the traffic detection information includes media stream identification information.

[0047] Referring to FIG. 1A, example operations illustrate a potential implementation. At block 152, an AF 170 can provide QoS requirements and application assistance information for an application. In some implementations, the QoS requirements are based on media streams, such that each media stream (for corresponding media traffic types) can have different QoS requirements. The AF 170 can also provide traffic description(s) for the media stream(s) and / or media traffic type(s). The AF 170 can provide the QoS requirements and application assistance information to the PCF (either directly to the PCF or via an NEF). At block 154, the PCF can prepare a PCC rule and provide the PCC rule to the SMF. For example, the PCC rule can indicate the QoS policy that is to be used for a particular media stream. The PCC rule can include the application assistance information (or traffic detection information based on the application assistance information) for traffic detection in the user plane. In this disclosure, the traffic detection information also includes media stream identification information. Examples of media stream identification information include a Correlation identification (ID), Media Stream ID, or a QUIC Stream ID, among other examples.

[0048] At block 162, the AMF / SMF 115 can configure the user plane with QoS parameters based on the PCC rule. For example, the SMF can cause the AMF to configure the RAN 105 with a QoS profile for a QoS flow that is mapped to the QoS requirements. The SMF can provide a configuration to the UPF 160 that indicates one or more QoS parameters for a PDU Set to be used for application packets of a particular media stream. The configuration can include different QoS parameters for different PDU Sets associated with different media streams. The SMF can also provide traffic detection information (including media stream identification information) based on the application assistance information to enable the UPF 160 to detect the media stream. For example, the traffic detection information can indicate the metadata expected in an UDP-Option field of application packets for a media stream.Docket No. 14730694300PCT

[0049] At block 172, the AS 150 communicates application packets to the UPF 160. The application packets can include metadata (such as in the UDP-Option field) to enable the UPF 160 to detect that the application packet is related to a particular media stream and the PDU Set QoS parameters. As an example, the metadata can be based on a Media Stream ID, a QUIC Stream ID, an RTP Stream ID, or a random number associated with a stream, among other examples. At block 174, the UPF 160 can identify the media stream for the PDU Set based QoS handling based on the metadata matching the traffic detection information. In some implementations, the UPF 160 first detects the application packet satisfies a packet detection rule (PDR) for the PDU Set and then determines whether the application packet has metadata matching the traffic detection information. The traffic detection information can also be referred to by other terms, such as traffic detection assistance information (or “assistance information” for brevity), media stream detection information, media identification information, or other terms to refer to information that can be matched to metadata in an UDP-Option field of the application packet. This disclosure includes several examples of traffic detection information and metadata, such as a correlation identification (ID), Stream ID, mapped Stream ID, RTP session information, QUIC stream ID, among other examples. In some implementations, the metadata “matches” the traffic detection information when the metadata is the same as the traffic detection information. In some implementations, the metadata matches the traffic detection information when the UPF 160 determines that the metadata is related to the traffic detection information, even if the actual content of the metadata differs from the traffic detection information. For example, the traffic detection information can include rules or information that the UPF 160 can use to detect that the metadata is related to the traffic detection information. The term “matches” can be replaced with any word or phrase that describes a relationship between information, including “satisfies,” “corresponds,” “correlates,” “conforms,” “derives,” “aligns,” etc.

[0050] At block 174, when the metadata matches the traffic detection information, the UPF 160 may determine that the application packet is related to the PDU Set QoS parameters. The UPF 160 applies the one or more QoS parameters to the PDUs of the PDU Set. For example, the UPF 160 can update the PDU Set information in the GTP-U header of the PDUs to enable the RAN 105 to transport the PDU Set according to a QoS profile for the one or more QoS parameters. At block 176, the RAN 105 transports the PDU Set according to the QoS profile, where the QoS profile is mapped to the QoS requirements in the PCC rule.

[0051] FIG. 1B is a block diagram of an example wireless communication system 100B, such as 5GS, that supports PDU Set handling using the techniques of this disclosure. The example wireless communication system 100B includes UEs 102A and 102B, a base stationDocket No. 14730694300PCT (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. Although described as a 5GC, the CN 110 can also be implemented as a sixth generation (6G) core or another suitable core network.

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

[0053] Several network functions (NFs) that make up the CN 110 are discussed below with reference to FIG. 3 and FIG. 4. One or more of the NFs of the CN 110 implement the PDU Set controller 112 which determines how and when to provide information related to PDU- Set-based handling to the UEs 102A and 102B and / or the RAN 105.

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

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

[0056] The UE 102A is equipped with processing hardware 130A that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The UE 102A also includes a transceiver 132A to communicate with the RAN 105 over a radio interface. Further, the UE 102A includes a memory 134A storing a PDU Set controller 142A. An example application 190 can use the PDU Set controller 142A to operate on PDU Sets. For example, the application 190 can set an RTP header to utilize PDU Set based processing. The UE 102B can have a similar implementation. Similarly, each of the base stations 104 and 106 can include processing hardware 130B, a transceiver 132B, and memory 134B for implementing a PDU Set controller 142A.

[0057] FIG. 2 is a block diagram of an example protocol stack according to which the UE of FIG. 1B can communicate with the RAN of FIG. 1B. FIG. 2 illustrates, in a simplified manner, an example protocol stack 200 for a UE 102 and 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.

[0058] 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.”Docket No. 14730694300PCT

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

[0060] FIG. 3 shows a service-based representation 300 of the 5GS architecture, including the overall non-roaming reference architecture of the policy and charging control framework for the 5GS. 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 (NSSAAF 322), an Authentication Server Function (AUSF 324), a Service Communication Proxy (SCP 374), and a Network Slice Admission Control Function (NSACF 326). The non-PCC architecture further includes the UE 102, the RAN 105, and a data network (DN 330). An application server (AS) 150 can operate in the DN 330.

[0061] The PCC framework in the architecture 300 includes a Unified Data Repository (UDR 352), a Network Exposure Function NEF 313, a network data analytics function (NWDAF 356), an Application Function (AF 170), a Policy Control Function (PCF 314), a Charging Function (CHF 362), an Access & Mobility Management Function (AMF 316), a Session Management Function (SMF 315), and a User Plane Function (UPF 160).

[0062] N1 is a reference point between the UE 102 and the AMF 316. N2 is a reference point between the RAN 105 and the AMF 316. N3 is a reference point between the RAN 105 and the UPF 160. N4 is a reference point between the SMF 315 and the UPF 160. N6 is a reference point between the UPF 160 and a DN 330.

[0063] When the UPF 160 operates as a PDU Session Anchor (PSA) UPF, to support PDU Set based QoS handling for XRM services, the PSA UPF 160 identifies PDUs that belong to PDU Sets and determines the following PDU Set Information, based for example on the RTP header extension defined in 3GPP TS 26.522, which the PSA UPF 160 transmits to the NG- RAN 105 in the GTP-U header. The NG-RAN 105 can use the PDU Set information for PDUDocket No. 14730694300PCT Set based QoS handling (e.g., as described in 3GPP TS 23.501, for example). The PDU Set Information can include (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.

[0064] 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. 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 (NSSAAF 322), an Authentication Server Function (AUSF 324), a Service Communication Proxy (SCP 374), and a Network Slice Admission Control Function (NSACF 326). The non-PCC architecture further includes the UE 102, the RAN 105, and a data network DN 330.

[0065] The PCC framework in the reference-point based representation 400 includes a Unified Data Repository (UDR 352), a Network Exposure Function (NEF 313), a network data analytics function (NWDAF 356), an Application Function (AF 170), a Policy Control Function (PCF 314), a Charging Function (CHF 362), an Access & Mobility Management Function (AMF 316), a Session Management Function (SMF 315), and a User Plane Function (UPF 160). In an example implementation, the AF 170 includes a user consent controller, and the NEF 313 includes a user consent controller. The CN 110 in various implementations can include only the user consent controller of the AMF 316, only the user consent controller of the NEF 313, or both. The user consent controllers of AMF 316 and NEF 313 collectively can be referred to as the user consent control logic of the CN 110.

[0066] N1 is a reference point between the UE 102 and the AMF 316. N1 is a reference point between the RAN 105 and the AMF 316. N3 is a reference pint between the RAN 105 and the UPF 160. N4 is a reference point between UPF 160 and SMF 315. N6 is a reference point between DN 330 and UPF 160. N7 is a reference point between SMF 315 and PCF 314. N10 is a reference point between UDM 308 and SMF 315. N12 is a reference point between AUSF 324 and AMF 316. N13 is a reference point between UDM 308 and AUSF 324. N5 is aDocket No. 14730694300PCT reference point between AF 170 and PCF 314. N22 is a reference point between NSSF 302 and AMF 316. N23 is a reference point between AF 170 and PCF 314. N28 is a reference point between PCF 314 and CHF 362. N29 is a reference point between SMF 315 and NEF 313. N30 is a reference point between PCF 314 and NEF 313. N36 is a reference point between PCF 314 and UDR 352. N40 is a reference point between SMF 315 and CHF 362. N58 is a reference point between AMF 316 and NSSAAF 322. N59 is a reference point between NSSAAF 322 and UDM 308. N80 is a reference point between AMF 316 and NSACF 326. N81 is a reference point between SMF 315 and NSACF 326.

[0067] Several example techniques for PDU Set based QoS handling are discussed next. Generally speaking, events in Figs. 5-12 that are similar are labeled with similar reference numbers, with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures.

[0068] FIG. 5 shows a high-level messaging diagram of an example scenario in which a UE uses XRM services using PDU Set handling. During the registration procedure and PCF / UE associations 522, the AMF 316 determines 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.

[0069] After successful registration, the UE 102 requests PDU establishment procedure 524, and the NG-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 315 via N2 interface and GTP-U header via N3 interface from the UPF 160. The UE or network can initiate a PDU session modification procedure 526 for the existing PDU Session.

[0070] The SMF 315 determines a QoS Profile for the QoS Flow, which is based on received a PCC rule or pre-configuration. For downlink traffic, the PSA UPF 160 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 3GPP TS 23.501 clause 5.37.5.2, (iii) and performs PDU-Set- based parameters based on received QoS Enforcement Rule (QER). The PSA UPF 160 communicates the PDU Set to the RAN 105 for transmission to the UE 102. For uplink traffic, the RAN 105 instructs UE 102 with uplink PDU-Set-based Handling information to perform PDU-Set-based handling including PDU Set Identification and marking on the uplink mediaDocket No. 14730694300PCT service data flow received from upper layer to provide NG-RAN in band uplink PDU Set information.

[0071] According to one implementation, the RAN 105 performs PDU-Set-based QoS handling for radio resources management based on the following information: (i) PDU Set information received from the PSA UPF 160 or the UE 102, and (ii) QoS profile containing PDU-Set-based QoS parameters. The PDU Set Information can include one or more of: (i) a PDU Set Sequence Number, (ii) an Indication of End PDU of the PDU Set, (iii) PDU Sequence Number within a PDU Set, (iv) PDU Set Size in bytes, and (v) PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.

[0072] Next, FIGs. 6–9 provides more detail regarding several solutions (numbered for brevity as Solution 0-6). At a high level, below is a brief description of some example solutions: ^ Solution 0 provides an example IP packet structure using RTP over QUIC and UDP- Option. Solution 0X provides an example definition of a UDP-Option header for the UDP-Option. FIGs.6, 7, and 8A show example implementations related to Solution 0 / 0X. ^ Solution 1 provides an example of metadata in UDP-Option field, further described with reference to FIG. 8B. ^ Solution 2 provides mapping of an RTP session and QUIC Connections, further described with reference to FIG. 8B. Solution 2.1: provides different RTP session maps to different QUIC connections. Solution 2.2 provides different RTP sessions that are mapped to different QUIC streams of a QUIC connection. Solution 2.3 provides the same RTP session multiplexed with multiple media types is mapped to different QUIC streams of a QUIC connection. ^ Solution 3 addresses further metadata handling, further described after FIGs. 6-8B. ^ Solution 4 provides PDU Set information marking in the GTP-U header, further described after FIGs. 6-8B. ^ Solution 5 provides control plane signaling over the N33 interface, further described after FIGs. 6-8B. More particularly, according to this solution, an AF request message includes assistance information for enabling PDU Set based handling in 5GS for the end- to-end encrypted traffic. ^ Solution 6, further described with reference to FIG.9, provides a high-level procedure for enabling PDU Set based Identification and QoS provisioning for end-to-end encrypted traffic of a specific media stream that is associated with a media type that requires PDUDocket No. 14730694300PCT Set based handling. More specifically, solution 6 includes an AF request (based on Solution 5); metadata information in UDP-Option (based on Solutions 1, 2, 3, and 4); PCF providing a PCC rule to the SMF; the SMF configuring the PSA UPF via an N4 session; the PSA UPF performing traffic detection and PDU Set based handling and performs PDU Set marking over GTP-U header; the NG-RAN performing PDU Set based QoS handling based on GTP-U header marked by the PSA UPF, and QoS profile including PDU Set based QoS parameters provided by the SMF.

[0073] FIG. 6 shows an example IP packet structure sent over N6 to PDU session anchor user plane function (PSA UPF) in 5G network. To enable PDU Set based handling in the 5G network for the end-to-end encrypted traffic using QUIC based transport layer protocol, the IP packet structure using RTP over QUIC and UDP-Option is shown in sections A-C of FIG. 6.

[0074] In FIG. 6, section A (shown at arrow 601), the IP packet contains IP header 682 and the UDP datagram. The UDP datagram includes UDP header 684, UDP header 684, and UDP option 688, where the QUIC packet is encapsulated in the UDP payload 686, and the UDP option 688 contains metadata, including necessary RTP session information. This RTP session information is mapped to the QUIC streams of the QUIC connection for PDU Set Based Identification by the PSA UPF in the 5G network.

[0075] In FIG. 6, section B (shown at arrow 602), the UDP payload 686 contains one QUIC packet of a specific QUIC stream 676 within a QUIC connection for a specific RTP session (i.e., only one QUIC stream is used for a specific RTP session).

[0076] In FIG.6, section C (shown at arrow 603), in the QUIC stream 676, the QUIC packet includes a QUIC header 674 and QUIC payload 672. The QUIC payload 672 encapsulates one or more RTP packets containing RTP header and RTP payload.

[0077] In some implementations, the signaling overhead is reduced using an enhancement. One QUIC packet can encapsulate more than one RTP packet with the same RTP session properties for a RTP session within a QUIC connection, including the following: media frame type, e.g. I / P / B type, QUIC connection and QUIC stream, PDU Set, Data burst, PDU Set Importance.

[0078] In some implementations, the correlation ID can be generated and used to identify one specific QUIC connection and QUIC stream 676 for a service data flow that share the same IP 5 tuple. For two QUIC streams within the same QUIC connection (with the same QUIC connection ID), the correlation IDs are set differently for the service data flows that share the same IP 5 tuple.Docket No. 14730694300PCT

[0079] In some implementations, the metadata may be integrity protected by using a secure hash function (e.g., SHA-256, SHA-3, and BLAKE2), which can be negotiated between the 5GC and the application or based on service level agreement. If based on service level agreement, the PSA UPF may be pre-configured with the secure hash function. If metadata needs to perform integrity protection, the application generates a hash of the metadata and includes it in the UDP option 688.

[0080] FIG. 7 illustrates an example 700 IP packet structure sent over N6 to PSA UPF in 5G network. The examples described in relation to FIG. 7 can reduce overhead. In FIG. 7, one QUIC packet can encapsulate more than one RTP packet within the same QUIC connection.

[0081] In FIG. 7, section A (shown at arrow 705), the IP packet contains an IP header 682 and the UDP datagram (shown as UDP header 684, UDP header 684, and UDP option 688). The UDP-Option UDP Option 688 contains metadata, including necessary RTP session information that is mapped to the QUIC streams of the QUIC connections.

[0082] In FIG. 7, section B (shown at arrow 707), the UDP payload contains one QUIC packet of a specific QUIC stream within a QUIC connection for a specific RTP session, i.e., one QUIC stream is used for a specific RTP session.

[0083] In FIG. 7, section C (shown at arrow 709), for the QUIC stream, the QUIC packet includes QUIC header and QUIC payload, whereby the QUIC payload encapsulates one or more RTP packets that shared the same RTP packets properties, e.g. I / P / B media frame type. When one RTP packet is encapsulated in the QUIC payload, Figure 6 (section C) is the same as Figure 7 (section C).

[0084] FIG. 8A illustrates another example 800 IP packet structure sent over N6 to PSA UPF in 5G network. The method corresponding to this structure defines the UDP-Option header 888A for the UDP option 688 if UDP payload 686 is used by other transport layer protocol as encapsulation layer (e.g., QUIC over UDP, RTP over UDP, RTP over QUIC) to provide metadata related to the encapsulated packets which encrypt required information for packet handling and routing in the specific network (e.g., PDU Set based handling in 5GS).

[0085] The UDP-Option header 888A may include one or more of the following pieces of information: ^ PT (Payload type): Indicates the format of the metadata payload and thus determines its interpretation by the application. For example, the value can be encapsulation layer protocol specific to the UDP payload, e.g. QUIC, RTP, or both (QUIC over RTP).Docket No. 14730694300PCT ^ X (Extension): (1 bit) Indicates presence of an extension header between the UDP- Option header and UDP-Option payload data. The extension header is application or profile specific. ^ Header extension: (optional, presence indicated by Extension field). For example, the first X-bit word contains a profile-specific identifier and a length specifier that indicates the length of the extension in X-bit units, excluding the X bits of the extension header. The extension header data follows.

[0086] Having illustrated separate FIGs. 6, 7, and 8A for Solutions 0 / 0X, details regarding Solution 1 are described by reference to previously-described network functions, interfaces, and metadata. Solution 1 provides additional example implementations of metadata in as shown in FIG. 8B.

[0087] The metadata that contains necessary RTP session information can include any of the following information (or combinations of the following information): ^ Correlation ID 892: a fixed length hash value generated by the application, which is used to associate the QUIC Connection ID that may change throughout the lifetime of the QUIC connection. ^ Media Stream ID 891: The Media Stream ID is unique within a QUIC Connection to identify a QUIC stream that encapsulates “RTP stream” in a QUIC connection, which can be set using the one of the following options: o Option 1: QUIC Stream ID within the associated QUIC Connection, as contained in the QUIC header of the QUIC packet. o Option 2: a fixed length random number 894, e.g. using a hash function, generated by the application. ^ Stream ID 893: The Stream ID is unique within the QUIC Connection. This information element (IE) can be set as Stream ID or a mapped value of Stream ID as contained in the QUIC header of the QUIC packet encapsulated in the UDP payload. ^ Timestamp: to provide time instance information of the encapsulate RTP packet. ^ Information in RTP header extension, such as: o End PDU of the PDU Set [E] (1 bit), o End of Data Burst [EDB] (3 bits), o PDU Set Importance [PSI] (4 bits), o PDU Set Sequence Number [PSSN] (10 bits), o PDU Sequence Number within a PDU Set [PSN] (6 bits), and / or o PDU Set Size [PSSize] (24 bits).Docket No. 14730694300PCT

[0088] In some implementations, the metadata further includes: ^ Priority of the QUIC stream: this value defines the relative priority within the QUIC connection. o For example, the priority value of the QUIC stream can be based on the media types if media traffic with multiple media types (e.g., voice, video, data) are multiplexed to different QUIC streams. o For example, the priority value of the QUIC stream can be based on the media frame types (e.g., I / P / B frame) if media traffic is the video which is with multiple media frame types multiplexed to different QUIC streams. o For example, the QUIC protocol can perform congestion control by creating new QUIC stream for different routing settings. The application can indicate the Priority value of the QUIC stream based on the application settings.

[0089] In some implementations (referred to as solution 1.1), a Media Stream ID can be integrated with Correlation ID as one IE, Media correlation ID, to identify a QUIC stream and a QUIC connection for an RTP session of an application. In some implementations, the Media Correlation ID can be a fixed length hash value generated by the application, e.g. using both initial QUIC connection ID and QUIC Stream ID, which is used to associate a QUIC stream within a QUIC connection that may be changed throughout the lifetime of the QUIC connection.

[0090] FIG. 8B shows example metadata that can be included in a UDP Option 688. In some examples 890, the metadata includes one or more of Media Stream ID 891, Correlation ID 892, QUIC Stream ID 893, or a random number 894 (that uniquely identifies a stream within an RTP session). The media stream identification information can enable the UPF to associate the media stream with the media information associated with QoS parameters (e.g., for a PDU Set). When the application packet is associated with a particular media stream of an application, the UPF can transmit the downlink PDU Set in a QoS flow based on a PCC rule (e.g., for binding the media stream to a QoS flow that fulfills the QoS requirements for the media type) Because an application may have multiple media types, the UPF can identify the multiple media streams using media stream identification information and transmit them in PDU Sets according to their respective QoS flows.

[0091] In some implementations, the metadata can include other information 895 related to media traffic type, PDU Set handling, and / or QoS requirements. For example, the metadata can include media info 898 (e.g., based on information in the RTP header extension fieldDocket No. 14730694300PCT and / or PDU Set information). Alternatively, or additionally, the metadata can include information 897 based on the RTP session (e.g., any information that might be included in RTP headers or based on any information for an RTP protocol between the AS and the UE). Alternatively, or additionally, the metadata can include any information that describes the media type carried in the application packet. In some implementations, the metadata is based on information in an RTP header extension for PDU Set handling, such as End PDU of the PDU Set, End of Data Burst, PDU Set Importance, PDU Set Sequence Number, PDU Sequence Number within a PDU Set, and / or PDU Set Size. The UPF can use the metadata to identify the appropriate PCC rule which defines a QoS profile for a QoS Flow in the RAN and apply the PDU Set information to the downlink PDUs that the UPF transmits based on the application packet and metadata.

[0092] Solution 2 describes the mapping of RTP session and QUIC Connections. RTP packets are encapsulated in QUIC stream with the following mapping methods. ^ Solution 2.1: different RTP sessions are mapped to QUIC streams in different QUIC connections (1 RTP session per QUIC connection). ^ Solution 2.2: different RTP sessions are mapped to different QUIC streams (multiple RTP sessions per QUIC connection, each RTP session is for one media type). ^ Solution 2.3: same RTP session multiplexed with multiple media types is mapped to different QUIC streams (one RTP session per QUIC connection, the RTP session can multiplexed with multiple media types).

[0093] The application implements the RTP over QUIC protocol for the media traffic of a specific media type by one of the following methods: ^ one QUIC packet contains one or more RTP packets. ^ UDP Option contains the metadata with information for the encrypted RTP packet and the QUIC streams of the QUIC connection. ^ one or more QUIC streams is used for a specific RTP session containing RTP media stream and RTCP stream. ^ Different QUIC streams which are synchronous can be further used to transmit RTP packets with different media frame types (e.g. I / P / B frame) for the RTP session. ^ [QoS requirement]: different QUIC streams within the QUIC connection are subjective to the media traffic, e.g. RTP, RTCP, of the RTP session, and QUIC related signaling. The 5G network needs to provision QoS for the QUIC connection by differentiating the QUIC streams with the corresponding required QoS parameters.Docket No. 14730694300PCT

[0094] In Solution 2.1, different RTP session map to different QUIC connections. The application implements the RTP over QUIC protocol for the media traffic with the following additional method: ^ one QUIC connection is used for the media traffic of a specific media type. ^ RTP packets of the RTP session are of one media type. ^ RTP packets with different media types are transmitted via different QUIC connections, which correspond to different RTP sessions. That is, one RTP session is mapped to one QUIC connection. ^ The application uses flow identification (FID) information in the RTP packet header to differentiate different media types of the media traffic and can then use different QUIC connection for different media types associated with different RTP sessions. ^ Metadata for identifying a RTP stream within a QUIC connection (following solution 2): o Correlation ID: a fixed length hash value generated by the application, which is used to associate the QUIC Connection ID that may be changed throughout the lifetime of the QUIC connection. o Media Stream ID: unique within a QUIC Connection to identify a QUIC stream that encapsulates “RTP stream” in a QUIC connection, which can be set using the following option: ^ Option 1: QUIC Stream ID within the associated QUIC Connection, as contained in the QUIC header of the QUIC packet. ^ Option 2: a fixed length random number, e.g. using a hash function, generated by the application. ^ Option 3: FID, as contained in the QUIC payload of the QUIC packet. ^ The QUIC Connection can contain different QUIC streams for media traffic in the RTP Session, e.g. RTP / RTCP. ^ [QoS requirement]: for different media types, the QoS requirements of a media traffic is associated with the QUIC stream that carries RTP media packets in different QUIC connections.

[0095] Table 1 shows the example of mapping among media types, RTP session, QUIC connection, and QUIC stream. Media Type RTP Session QUIC Connection (FID) (QUIC Connection ID)Docket No. 14730694300PCT Media Type A FID#A QUIC Connection ID#A Media Type B FID#B QUIC Connection ID#B Media Type C FID#C QUIC Connection ID#C Table 1: diagram for RTP sessions encapsulations in QUIC connection

[0096] In Solution 2.2, different RTP sessions are mapped to different QUIC streams. The application implements the RTP over QUIC protocol for the media traffic with the following additional method: ^ one QUIC connection is used for media traffic of multiple media types. ^ RTP packets of the RTP session are of one media type. ^ RTP packets with different media types are transmitted via different QUIC streams within one QUIC connection, in which each QUIC stream is corresponding to different RTP sessions. That is, one RTP session is mapped to one QUIC stream within one QUIC connection. ^ The application uses FID (flow identifier) information in QUIC payload to differentiate RTP sessions and then uses one QUIC stream for each RTP session with different media type. ^ Metadata for identifying a RTP stream within a QUIC connection (following solution 2): o Correlation ID: a fixed length hash value generated by the application, which is used to associate the QUIC Connection ID that may be changed throughout the lifetime of the QUIC connection. o Media Stream ID: unique within a QUIC Connection to identify a QUIC stream that encapsulates “RTP stream” in a QUIC connection, which can be set using the following option: ^ Option 1: QUIC Stream ID within the associated QUIC Connection, as contained in the QUIC header of the QUIC packet. ^ Option 2: a fixed length random number, e.g. using a hash function, generated by the application.Docket No. 14730694300PCT ^ Option 3: FID, as contained in the QUIC payload of the QUIC packet. ^ [QoS requirement]: for different media types, the QoS requirements of a media traffic are associated with the QUIC stream that carries RTP media packets of different RTP Sessions in the QUIC connection.

[0097] Table 2 shows the example of mapping among media types, RTP session, QUIC connection, and QUIC stream. Media Type RTP Session QUIC Connection (differentiated via FID) (QUIC Connection ID) Media Type A FID#A Stream-ID#A Media Type B FID#B Stream-ID#B Media Type C FID#C Stream-ID#C Table 2: diagram for RTP sessions encapsulations in QUIC connection

[0098] In Solution 2.3, the same RTP session multiplexed with multiple media types is mapped to different QUIC streams. The application implements the RTP over QUIC protocol for the media traffic with the following additional method: ^ one QUIC connection is used for media traffic of multiple media types. ^ one QUIC stream is used for a specific media type in a RTP session. ^ RTP packets of the RTP session are of multiple media types. ^ RTP packets with different media types are transmitted via different QUIC streams within one QUIC connection, in which each QUIC stream is corresponding to different media types multiplexed in one RTP session. That is, one RTP stream with a specific media type within one RTP session is mapped to one QUIC stream within one QUIC connection. ^ The application uses SSRC information in RTP packet header to differentiate media type of a RTP stream within a RTP session (with a specific flow identifier, FID) and then use different QUIC stream for different media type of the RTP stream in the RTP session. ^ Metadata for identifying a RTP stream within a QUIC connection (following solution 2):Docket No. 14730694300PCT o Correlation ID: a fixed length hash value generated by the application, which is used to associate the QUIC Connection ID that may be changed throughout the lifetime of the QUIC connection. o Media Stream ID: unique within a QUIC Connection to identify a QUIC stream that encapsulates “RTP stream” with a specific media type in a QUIC connection, which can be set using the following option: ^ Option 1: QUIC Stream ID within the associated QUIC Connection, as contained in the QUIC header of the QUIC packet. ^ Option 2: a fixed length random number, e.g. using a hash function, generated by the application. ^ Option 3: SSRC, as contained in the RTP header of the RTP packet encapsulated in the QUIC packet. ^ [QoS requirement]: for different media types, the QoS requirements of a media traffic are associated with the QUIC stream that carries a RTP stream within a RTP Session in the QUIC connection.

[0099] Table 3 shows the example of mapping among media types, RTP session, QUIC connection, and QUIC stream. Media Type RTP Session QUIC Connection (FID#X) (QUIC Connection ID) Media Type A RTP stream with SSRC#A QUIC stream-ID#A Media Type B RTP stream with SSRC#B QUIC stream-ID#B Media Type C RTP stream with SSRC#C QUIC stream-ID#C Table 3: diagram for RTP sessions encapsulations in QUIC connection

[0100] Having described the UDP-Option and mapping of media streams to metadata options, Solution 3 provides more examples of metadata for media stream identification. In some implementations, the Correlation ID can be generated and used to identify one specific QUIC connection and QUIC stream for a service data flow that share the same IP 5 tuple. For two QUIC streams within the same QUIC connection (with the same QUIC Connection ID), the Correlation ID are set different for the service data flow that share the same IP 5 tuple.Docket No. 14730694300PCT

[0101] In some implementations, the metadata may be integrity protected by using a secure hash function, e.g., SHA-256, SHA-3, and BLAKE2, which can be negotiated between the 5GC and the application or based on service level agreement. If based on service level agreement, the PSA UPF may be pre-configured with the secure hash function. If metadata needs to perform integrity protection, the application generates a hash of the metadata and includes it in the UDP-Option.

[0102] Solution 4 provides example implementations for PDU Set information marking in the GTP-U header. Based on the assistance information configured by the SMF via N4 session and the metadata included in the UDP-Option from an IP packet over the N6 interface, the PSA UPF can perform the following: ^ identify a PDU (Packet Data Unit) that belongs to a specific PDU Set and performs PDU Set based QoS handling according to QER included in N4 rule. ^ mark the identified PDU with PDU Set Information in GTP-U header to provide PDU Set Information to the NG-RAN, whereby the PDU Set information includes the following: o QoS Flow ID that is corresponding to the QUIC Stream ID. o Timestamp: to provide time instance information of the last encapsulated RTP packet. o Priority of the QUIC stream: define the relative priority within the QUIC connection. o QUIC packet Information: include information based on RTP header extension, e.g. based on 3GPP TS 26.522, for the last RTP packet: ^ End PDU of the PDU Set ^ End of Data Burst ^ PDU Set Importance ^ PDU Set Sequence Number ^ PDU Sequence Number within a PDU Set ^ PDU Set Size ^ Number of RTP packets in the QUIC packet.

[0103] Solution 5 provides example implementations of an AF (or AS) request. The AF request is communicated using control plane signaling over N33 interface between the AF and the PCF (or NEF). The request includes application assistance information for enabling PDU Set based handling, including traffic detection, PDU Set based identification, and QoS flow mapping, at PSA UPF. The AF sends AF request message to the NEF / PCF including the following information (or any combination of the following information):Docket No. 14730694300PCT ^ QoS requirements for the service data flow ^ Additional QoS requirements for the media traffics within a QUIC connection. o QoS requirements and corresponding QoS correlation ID for associating additional traffic description. ^ Traffic description includes IP 5 tuples. ^ Additional traffic description includes a list of the following information: o QoS Correlation ID o Transport Connection Correlation ID included in the metadata. o Transport Connection Associated Stream ID included in the metadata. ^ Protocol Description indicates RTP / SRTP with RTP header extension defined in 3GPP TS 26.522 for the applicable QUIC connection and QUIC stream. This IE indicates the real-time transport layer protocol applied for the encapsulation layer for user plane traffic over N6, e.g. based on IETF RFC 3550: The Real-time Transport Protocol (RTP), IETF RFC 3711: The Secure Real-time Transport Protocol (SRTP), and 3GPP TS 26.522: 5G Real-time Media Transport Protocol Configurations. ^ PDU Set Handling List of Stream ID(s) that require PDU Set Handling within the QUIC connection. This information indicates, to the PCF / SMF / UDF, the need for PDU Set handling. Some QUIC streams that carry control signaling do not need PDU Set handling. ^ Additional Transport layer Protocol Description: indicate transport layer protocol that encapsulates upper layer packets, including: QUIC over UDP, UDP-Option, RTP. The UPF can use this information to perform corresponding traffic detection, PDU Set information identification.

[0104] Solution 5.1 is an example of Solution 2.1. The example of AF request for QoS provisioning are based on two media types, referred to as Media Type#A (for video traffic) and Media Type#B (for voice traffic). Each Media Type is associated with a corresponding Correlation ID (e.g., Correlation ID#A and Correlation ID#B, respectively) and a corresponding Stream ID (e.g., Stream ID#X and Stream ID#Y, respectively)

[0105] For Media Type#A for video that requires PDU Set based QoS, the AF request can include: ^ QoS requirements for a service data flow as indicated in 3GPP TS 23.501 ^ Additional QoS requirements for the service data flows using QUIC over UDP.Docket No. 14730694300PCT o QoS Correlation ID#1, PDU Set based QoS parameters includes PDU Set Error Rate (PSER), PDU Set Delay Budget (PSDB), PDU Set Integrated Handling Information (PSIHI) ^ Traffic description includes IP 5 tuple for the service data flow#B for the QUIC connection. ^ Protocol Description indicates RTP / SRTP with RTP header extension defined in 3GPP TS 26.522. ^ Additional traffic description includes a list of the following information: o QoS Correlation ID#1 o Transport link Correlation ID#A o The associated Stream ID#X.

[0106] For Media type#B for voice that requires QoS parameters as indicated in 3GPP TS 23.501, the AF request can include: ^ QoS requirements for a service data flow as indicated in 3GPP TS 23.501 ^ Additional QoS requirements for the service data flows using QUIC over UDP. o QoS Correlation ID#2, QoS parameters for voice service as indicated in 3GPP TS 23.501 o Traffic description includes IP 5 tuple for the service data flow#B for the QUIC connection. o Additional traffic description includes a list of the following information: ^ QoS Correlation ID#2 ^ Transport link Correlation ID#B ^ The associated Stream ID#Y.

[0107] Solution 5.1 is an example of Solution 2.2 and 2.3. The example of AF request for QoS provisioning are as follows: ^ For a QUIC connection with Media Type#A for video and Media Type#B for voice that requires PDU Set based QoS: o QoS requirements for a service data flow as indicated in 3GPP TS 23.501. o Additional QoS requirements for the service data flows using QUIC over UDP. ^ QoS Correlation ID#1, PDU Set based QoS parameters includes PDU Set Error Rate (PSER), PDU Set Delay Budget (PSDB), PDU Set Integrated Handling Information (PSIHI) ^ QoS Correlation ID#2, QoS parameters for voice service as indicated in 3GPP TS 23.501Docket No. 14730694300PCT o Traffic description includes IP 5 tuple for the service data flow. o Protocol Description indicates RTP / SRTP with RTP header extension defined in 3GPP TS 26.522 for the applicable QUIC connection and QUIC stream. o Additional traffic description includes a list of the following information: ^ QoS Correlation ID#1, Transport link Correlation ID#X, The associated Stream ID#A. ^ QoS Correlation ID#2, Transport link Correlation ID#X, The associated Stream ID#B.

[0108] FIG. 9 shows an example procedure 900 for enabling PDU Set based handling, including PDU Set based QoS provisioning, traffic detection, and PDU Set Identification, for end-to-end encrypted traffic in 5G network. Following Solution 5 for the AF request and Solution 1 / 2 / 3 for the metadata information in UDP-Option, and referring to FIG. 9, this solution proposes procedures to enable PDU Set based handling, including PDU Set based QoS provisioning, traffic detection, and PDU Set Identification, for the end-to-end encrypted traffic using RTP over QUIC in 5G network. FIG. 9 shows the UE 102, the RAN 105, the UPF 160, the AMF / SMF 115, the PCF / NEF 114, and the AF 170 which correspond to same- numbered entities in FIG. 1A.

[0109] For brevity, the operations in FIG. 9 are described as numbered steps (e.g.., Step "0" 920, Step "1" 952, and so on). Step numbers are intended to provide clarity of description and do not necessarily require a specific order or sequence of the operations. Furthermore, some steps may be omitted or added to various implementations.

[0110] Step "0" 920 shows performance of a PDU Session Establishment procedure (defined in 3GPP TS 23.502 clause 4.3.2.2.1). In some implementations, a network slice type for XR service can be used for such a PDU Session. The Step "0" 920 may include one or more operations described with reference to FIG. 5.

[0111] Step "1" 952 shows AF 170 to PCF / NEF 114 communication: the AF sends AF request with information indicated in Solution 4, e.g., a new request message, or Nnef_AFsessionWithQoS_Create request as defined in 3GPP TS 23.502 clause 4.15.6.6, to the 5GC via NEF / PCF to provide PDU Set based QoS requirement of the end-to-end encrypted media traffic and assistant information for traffic detection, PDU Set identification, PDU Set marking, and QoS associated to a media type that requires PDU Set based handling. The PCF can use the AF provided information to determine a PCC rule as defined in 3GPP TS 23.503 clause 6.1.3.27.4 and for identifying the PDU Set information from the end-to-end encrypted media traffic by the PSA UPF.Docket No. 14730694300PCT

[0112] Step "2" 954 shows: based on assistance information and PDU Set based QoS requirement from the AF directly or via NEF, the PCF determines that PDU Set based QoS Handling is to be performed for an end-to-end encrypted media stream within a service data flow (based on IP 5 tuple) of an application. The PCF determines the PDU Set QoS Parameters based on information provided by AF and / or local configuration to generates PCC rule(s), containing the PDU Set QoS parameters (e.g., PSER, PSDB, PSIHI, etc.) and traffic detection assistance information with media stream identification information for a specific media stream that is associated to a media type that requires PDU Set based handling. At Step "2b" 956, the PCF sends session management policy association establishment or session modification message (a PCC rule) to the SMF.

[0113] At Step "3" 958: According to the PCC rule from PCF 114, the SMF 115 performs QoS flow mapping to map a specific media stream (identified by Correlation ID and Media Stream ID based on solution 1 or Media Correlation ID based on solution 1.1) within the service data flow to a QoS flow, determines a QoS Profile for the QoS Flow, and determines N4 rules including QoS Enforcement Rule (QER) with PDU Set based QoS parameters and Packet Detection Rule (PDR) with assistance information for a specific media stream included in Packet Detection Information. Alternatively, the SMF may be configured to support PDU Set QoS handling without receiving a PCC rule from a PCF. ^ At Step "3a" 962: the SMF 115 sends the N4 rules including QER and PDR with Packet Detection Information for a specific media stream to the PSA UPF. ^ At Step "3b" 964: the SMF 115 sends the QoS profiles and QoS rules containing in the NAS message to the NG-RAN via AMF. ^ At Step "3c" 966: the SMF 115 sends the QoS rules in a NAS message to the UE via AMF and NG-RAN.

[0114] At Step "4" 972 (performed by the AS or AF 170): the application encapsulates RTP packets in QUIC packets and transmits the QUIC packet with UDP-Option containing metadata according to any of the Solutions 1-5 within a QUIC connection containing one or more QUIC streams over N6 interface to PSA UPF.

[0115] At Step "5" 974 (performed by the UPF 160): When receiving IP packets from Application server over N6, the PSA UPF performs traffic detection based on configured PDR received in Step 3a and PDU Set Identification based on the metadata included in the UDP- Option and the assistance information received from the SMF. As an example, Step 5 can include a Step 5a: based on the PDR with assistance information configured by the SMF via N4 session in Step 3b and the metadata included in the UDP-Option from an IP packet overDocket No. 14730694300PCT N6 interface, the PSA UPF can identify a PDU (Packet Data Unit) that belongs to a specific PDU Set and performs PDU Set based QoS handling according to QER included in N4 rule. At Step "5b" 976 (showing UPF 160 to RAN 105 communication over N3): the PSA UPF marks the identified PDU with PDU Set Information in GTP-U header to provide PDU Set Information to the NG-RAN.

[0116] In some implementations, the PSA UPF may remove UDP-Option or replace it with padding bits before forwarding the PDUs.

[0117] At Step "6" 978 (performed by the RAN 105): Based on the PDU Set Information in GTP-U header, RAN performs PDU Set based QoS handling, and maps the QoS flow to one or more DRB. For example, at Step "6a" 979, the NG-RAN transmits DRBs over NR-Uu to the UE. At Step "6b" 990, the UE maps the received DRBs to the QoS flows based on QoS rules and then forwards Downlink packet to XRM application.

[0118] FIG. 10 shows example operations 1000 of a PSA UPF (such as the UPF 160). At block 1062, the UPF receives, via a control plane of the CN, a configuration including at least one rule for PDU Set based quality of service (QoS) handling of a plurality of media streams of an application service data flow. The configuration includes traffic detection information and one or more QoS parameters associated with the plurality of media streams. The traffic detection information including media stream identification information for at least a first media stream of the plurality of media streams. At block 1072, the UPF receives a first application packet of the application service data flow, with the first application packet including metadata. At block 1074, the UPF 160 identifies a PDU Set for the first media stream of the plurality of media streams based on the metadata matching the traffic detection information and the media stream identification information for the first media stream. At block 1076, the UPF communicates the first application packet via one or more PDUs in the PDU Set to a radio access network (RAN) for transmission to a user equipment (UE) using the one or more QoS parameters.

[0119] FIG. 11 shows example operations 1100 of a PCF (such as the PCF 114 or PCF 314) of a 5GS. At block 1152, the PCF receives an application request for quality of service (QoS) for one or more media streams of an application service data flow between an application server (AS) and user equipment (UE), along with application assistance information, including media stream identification information associated with the media streams. At block 1154, the PCF generates a policy and charging control (PCC) rule based on the application request, with the PCC rule being specific to a first media stream of the one or more mediaDocket No. 14730694300PCT streams. At block 1156, the PCF transmits the PCC rule to a session management function (SMF) of the CN.

[0120] FIG. 12 shows example operations 1200 of an SMF (such as the SMF 115 or SMF 315) of a 5GS. At block 1256, the SMF receives a policy and charging control (PCC) rule from a policy control function (PCF) of the core network (CN) based on an application request for quality of service (QoS) for a plurality of media streams in an application service data flow between an application server (AS) and user equipment (UE), along with application assistance information associated with the media streams. At block 1264, the SMF configures a radio access network (RAN) with a QoS profile based on the requested QoS for the media streams. At block 1262, the SMF communicates a configuration to a user plane function (UPF) of the CN, including at least one rule for protocol data unit (PDU) Set-based QoS handling of a first media stream among the plurality of media streams. The configuration includes traffic detection information, based on the application assistance information, which contains media stream identification information for at least the first media stream. The configuration specifies one or more QoS parameters for a PDU Set associated with the first media stream among the plurality of media streams.

[0121] FIG. 13 shows example operations 1300 of an application server (such AS 150). At block 1352, the AS communicates a request via an application function (AF) to a control plane of a core network (CN), indicating a quality of service (QoS) requirement for at least a first media stream among a plurality of media streams in an application service data flow between the AS and user equipment (UE). The request includes application assistance information containing media stream identification information associated with the first media stream. At block 1372, the AS communicates an application packet for the first media stream to a user plane function (UPF) of the CN. This packet includes metadata for matching traffic detection information based on the media stream identification information.

[0122] FIG. 14 shows a block diagram of an example wireless communication system 1400 showing hardware features and communication interfaces. The depicted hardware configurations may omit certain components well-understood to be frequently implemented in such electronic devices, such as displays, peripherals, power supplies, and the like. The example wireless communication system 1400 includes the same elements as described with reference to FIG. 1A, including the UE 102 and the RAN 105. FIG. 14 also shows a second network entity 1406 and the core network 1411. In some implementations, the UE 102 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the RAN 105. The RAN 105 connects to the RAN 105 via an interface (e.g., S1 or NG interface). The RAN 105 can connect to other base stations (including the second network entity 1406)Docket No. 14730694300PCT via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes. In FIG. 14, the second network entity 1406 operates a second cell 1408B.

[0123] The RAN 105 is equipped with processing hardware 1404 that can include a receiver 1407B configured to receive data in the uplink direction. The processing hardware 1404 can also include a transmitter 1407A configured to transmit data in the downlink direction. The processing hardware can include one or more general-purpose processor(s) 1407C (e.g., CPUs) and a non-transitory computer-readable memory (CRM 1407D) storing instructions that the one or more general-purpose processors execute. Additionally, or alternatively, the processing hardware 1404 can include special-purpose processing units. The processor 1407C may include, for example, one or more central processing units, graphics processing units (GPUs), or other application-specific integrated circuits (ASICs), and the like. CRM 1407D may include any suitable memory or storage device such as random-access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory usable to store device data of the RAN 105.

[0124] The UE 102 is equipped with processing hardware 1402 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory 1403D storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 1402 can also include a transmitter 1403A configured to transmit data in the downlink direction. The processing hardware can include a receiver 1403B configured to receive data in the uplink direction. The processing hardware 1402, in an example implementation, includes a processor 1403C to process data that the UE 102 will transmit in the uplink direction or process data received by UE 102 in the downlink direction. The processor(s) 1403C may include, for example, one or more central processing units, GPUs, or other ASICs, and the like. To illustrate, the processor(s) 1403C may include an application processor (AP) utilized by the UE 102 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor. The CRM 1403D may include any suitable memory or storage device such as RAM, SRAM, DRAM, NVRAM, ROM, Flash memory, SSD or other mass-storage devices, and the like useable to store one or more sets of executable software instructions and associated data that manipulate the one or more processor(s) 1403C and other components of the processing hardware 1402 to perform the various functions described herein and attributed to the UE 102. The sets of executable software instructions include, for example, an operating system (OS) and various drivers (not shown), and various software applications (not shown), which are executable by processor(s)Docket No. 14730694300PCT 1403C to enable user-plane communication, control-plane signaling, and user interaction with the UE 102.

[0125] The core network 1411 can be an Evolved Packet Core (EPC) and / or a 5G core (5GC). Among other components, the EPC can include a Serving Gateway (SGW), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), and a Packet Data Network Gateway (PGW). The SGW in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME is configured to manage authentication, registration, paging, and other related functions. The PGW provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC includes a User Plane Function (UPF), a Unified Data Management (UDM), an Access and Mobility Management Function (AMF), and / or Session Management Function (SMF). Generally speaking, the UPF is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF is configured to manage authentication, registration, paging, and other related functions, and the SMF is configured to manage PDU sessions. The HSS and the UDM store and maintain subscription information regarding the UE 102. The core network 1411 can be implemented by one or more processing elements (shown as processing hardware 1410). The processing hardware 1410 can include a transmitter 1411A, a receiver 1411B, a processor 1411C, and a CRM 1411D, similar to corresponding components described with reference to processing hardware 1402 and 1404.

[0126] The transmitters 1403A, 1407A, and 1411A and receivers 1403B, 1407B, and 1411B are examples of a communication unit. The processors 1403C, 1407C, and 1411C can also be referred to as a processing system. Other examples of a communication unit and a processing system are possible, including some examples that are commonly used in a wireless communication system. The RAN 105, UE 102, second network entity 1406, and core network 1411 can include other components not illustrated in FIG. 14.

[0127] FIG. 1A through FIG. 14 and the operations described herein are examples meant to aid in understanding example implementations and should not be used to limit the potential implementations or limit the scope of the claims. some implementations may perform additional operations, fewer operations, operations in parallel or in a different order, and some operations differently.

[0128] Aspects of the subject matter described in this disclosure can be implemented as a computer-readable medium having stored therein instructions which, when executed by a processor, causes the processor to perform any one of the above-mentioned functionalities.Docket No. 14730694300PCT Aspects of the subject matter described in this disclosure can be implemented as a system having means for implementing any one of the above-mentioned functionalities. Aspects of the subject matter described in this disclosure can be implemented as an apparatus having one or more processors configured to perform one or more operations from any one of the above- mentioned functionalities.

[0129] The following additional considerations may apply to the foregoing and the following discussions.

[0130] Generally speaking, description for one of the above figures can apply to another of the above figures. Any event or block described above can be optional. For example, an event or block with dashed lines can be optional. In some implementations, “message” is used and can be replaced by “information element (IE),” and vice versa. In some implementations, “IE” is used and can be replaced by “field,” and vice versa. In some implementations, “subband” can be replaced with “sub-band.” In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters,” and vice versa. In some implementations, “some” means “one or more.” In some implementations, “at least one” means “one or more.” The “eNB” can be replaced by “base station,” “gNB,” “6G base station,” “evolved gNB,” or 6G gNB. “MME” can be replaced by AMF or evolved AMF or 6G AMF. “Core network (CN)” can be replaced by EPC, 5GC or 6GC.

[0131] Unless defined otherwise, technical and scientific terms used herein have the same meaning as is commonly understood by one of ordinary skill in the art to which this specification belongs. The terms “first,” “second,” and the like, as used herein do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The use of terms “including,” “comprising” or “having” and variations thereof herein are meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The terms “connected” and “coupled” are not restricted to physical or mechanical connections or couplings and can include electrical connections or couplings, whether direct or indirect. Furthermore, terms “circuit” and “circuitry” and “control unit” may include either a single component or a plurality of components, which are either active and / or passive and are connected or otherwise coupled together to provide the described function. In addition, the term operationally coupled as used herein includes wired coupling, wireless coupling, electrical coupling, magnetic coupling, radio communication, software based communication, or combinations thereof.

[0132] Some or all of the foregoing or the following implementations can be jointly combined or formed to be a new or another one implementation. The foregoing or theDocket No. 14730694300PCT following techniques can be used to solve at least (but not limited to) the issue(s) or scenario(s) mentioned in this disclosure. Any two or more than two of the foregoing or the following paragraphs, (sub)-bullets, points, actions, or claims described in each method / technique / implementation may be combined logically, reasonably, and properly to form a specific method. Any sentence, paragraph, (sub)-bullet, point, action, or claim described in each of the foregoing or the following technique(s) / implementation(s) / concept(s) may be implemented independently and separately to form a specific method. Dependency, such as “based on,” “more specifically,” “where” or etc., in technique(s) / implementation(s) / concept(s) mentioned in this disclosure is just one possible implementation which would not restrict the specific method.

[0133] As used herein, the terms “user device”, “user equipment” (for example, UE 102), “wireless communication device”, “mobile communication device”, “communication device”, or “mobile device” refer to any one or all of cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, Internet-of-Things (IoT) devices, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, display sub-systems, driver assistance systems, vehicle controllers, vehicle system controllers, vehicle communication system, infotainment systems, vehicle telematics systems or subsystems, vehicle display systems or subsystems, vehicle data controllers, point- of-sale (POS) terminals, health monitoring devices, drones, cameras, media-streaming dongles or another personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, broadband routers or other types of routers, and similar electronic devices which include a programmable processor and memory and circuitry configured to perform operations as described herein. Further, the user device, in some implementations, may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of- things (IoT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0134] Certain techniques are described in this disclosure as including logic or a number of components or modules. Modules 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 asDocket No. 14730694300PCT 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.

[0135] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

[0136] As used herein, the terms “component” and “module” are intended to be broadly construed as hardware, firmware, or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, or a combination of hardware and software. As used herein, the phrase “based on” is intended to be broadly construed to mean “based at least in part on.”

[0137] As used herein, a phrase referring to a list of items separated by “or” refers to any combination of those items, including single members. For example, “a, b, or c” is intended to cover the possibilities of: a only, b only, 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.

[0138] In this disclosure, an expression of “X / Y” may include meaning of any of the following: “X or Y” or “X and Y” or “X and / or Y." An expression of “(A) B” or “B (A)” may include concept of “only B.” An expression of “(A) B” or “B (A)” may include the concept of “A+B” or “B+A.”

[0139] In this disclosure, the term "can" indicates a capability, or alternatively indicates a possible implementation option. The term "may" indicates a permission or a possible implementation option.

[0140] Some aspects are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.

[0141] The various illustrative components, logic, logical blocks, modules, circuits, operations and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, orDocket No. 14730694300PCT combinations of hardware, firmware or software, including the structures disclosed in this specification and the structural equivalents thereof. The interchangeability of hardware, firmware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware, firmware or software depends upon the particular application and design constraints imposed on the overall system.

[0142] As described above, some aspects of the subject matter described in this specification can be implemented as software. For example, various functions of components disclosed herein, or various blocks or steps of a method, operation, process or algorithm disclosed herein can be implemented as one or more modules of one or more computer programs. Such computer programs can include non-transitory processor-executable or computer-executable instructions encoded on one or more tangible processor-readable or computer-readable storage media for execution by, or to control the operation of, a data processing apparatus including the components of the devices described herein. By way of example, and not limitation, such storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store program code in the form of instructions or data structures. Combinations of the above should also be included within the scope of storage media.

[0143] Various modifications to the implementations described in this disclosure may be readily apparent to persons having ordinary skill in the art, and the generic principles defined herein may be applied to other implementations without departing from the scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shown herein but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

[0144] Additionally, various features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. As such, although features may be described above as acting in particular combinations, and even initially claimed as such, one or more features from a claimed combination can, in some implementations, be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0145] The drawings may schematically depict one or more example processes in the form of a flowchart or flow diagram. However, other operations that are not depicted can beDocket No. 14730694300PCT incorporated in the example processes that are schematically illustrated. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Additionally, other implementations are within the scope of the following claims. In some implementations, the actions recited in the claims can be performed in a different order and still achieve desirable results.

[0146] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the aspects. While the aspects of the disclosure have been described in terms of various examples, any combination of aspects from any of the examples is also within the scope of the disclosure. The examples in this disclosure are provided for pedagogical purposes.Docket No. 14730694300PCT APPENDIX A IETF RoQ

[0013] ^ Flow Identifier (FID): Flow identifier to demultiplex different data flows on the same QUIC connection. ^ The payload in a QUIC stream starts with the flow identifier followed by one or more RTP / RTCP payloads. ^ All RTP / RTCP payloads sent on a stream MUST belong to the RTP session with the same flow identifier. ^ Each payload begins with a length field indicating the length of the RTP / RTCP packet, followed by the packet itself. QUIC packet: [FID, (length[1], RTP packet#1), (length[2], RTP packet#2), …, (length[N], RTP packet#N) ] IETF RFC 3500: RTP header:IETF RFC 8860: ^ SSRC: (32 bits) o Synchronization source identifier uniquely identifies the source of a stream. o The synchronization sources within the same RTP session will be unique. ^ RTP payload type is never used to distinguish RTP streams. o The RTP packets are demultiplexed into RTP streams based on their SSRC; o the RTP payload type is then used to select the correct media-decoding pathway for each RTP stream.Docket No. 14730694300PCT ^ The RTP session used for the original streams can include multiple RTP streams, and those RTP streams can use multiple media types. ^ Within an RTP session where multiple media types have been configured for use, an SSRC can only send one type of media during its lifetime (i.e., it can switch between different audio codecs, since those are both the same type of media, but it cannot switch between audio and video).

Claims

Docket No. 14730694300PCT CLAIMS What is claimed is:

1. A method of a user plane function (UPF) in a core network (CN) of a wireless communication system, the method comprising: receiving, via a control plane of the CN, a configuration (162) including at least one rule for protocol data unit (PDU) Set based quality of service (QoS) handling of a plurality of media streams of an application service data flow, the configuration including traffic detection information and one or more QoS parameters associated with the plurality of media streams, the traffic detection information including media stream identification information for at least a first media stream of the plurality of media streams; receiving a first application packet including metadata; identifying a PDU Set for the first media stream of the plurality of media streams based on the metadata matching the traffic detection information and the media stream identification information for the first media stream; and communicating the first application packet via one or more PDUs in the PDU Set to a radio access network (RAN) for transmission to a user equipment (UE) fulfilling the one or more QoS parameters.

2. The method of claim 1, wherein the metadata includes information based on a media traffic type of the first media stream in a real-time protocol (RTP) session.

3. The method of claim 1 or 2, wherein the metadata includes a media stream identification (ID) value matching the media stream identification information.

4. The method of any one of claims 1 to 3, wherein the first application packet includes an internet protocol (IP) header, a user datagram protocol (UDP) header, a UDP payload carrying a quick UDP Internet connection (QUIC) packet that encapsulates at least one real-time protocol (RTP) packet, and a UDP- Option field carrying the metadata, and wherein the metadata includes at least one of: a correlation identification (ID) value associated with a QUIC connection ID of an RTP session; media stream identification information associated with the first media stream; a stream ID value based on a QUIC header of the QUIC packet; a mapped value based on a Stream ID in the QUIC header of the QUIC packet;Docket No. 14730694300PCT a timestamp indicating time instance information of a most recent RTP packet encapsulated in the QUIC packet; priority information associated with the first media stream; information based on an RTP header extension of the RTP packet; or a number of RTP packets in the QUIC packet.

5. The method of claim 4, wherein the metadata includes at least one of: a media Stream ID value that identifies a QUIC stream specific to the first media stream; a QUIC Stream ID associated with the first media stream, the QUIC Stream ID based on the QUIC header of the QUIC packet; or a random number that is uniquely associated with the first media stream within the QUIC connection.

6. The method of claim 4 or 5, wherein the priority information includes at least one of: a priority value based on a media type of the first media stream; a priority value based on a media frame type of media traffic in the first media stream; or a priority value of the first media stream based on application settings.

7. The method of any one of claims 1 to 6, wherein the media stream identification information is based on flow identifier (FID) information, the FID information being specific to a media type of the first media stream from among a plurality of media types associated with a respective plurality of user datagram protocol (UDP) connections.

8. The method of any one of claims 1 to 7, wherein the metadata is based on a Correlation identification (ID) that identifies a QUIC connection and QUIC stream.

9. The method of any one of claims 1 to 8, wherein the metadata is integrity protected using a secure hash function and the media stream identification information includes a configuration of the secure hash function.

10. The method of any one of claims 1 to 9, wherein the first media stream is associated with a real-time protocol (RTP) session of a QUIC connection and wherein the QUIC connection is specific to the RTP session.Docket No. 14730694300PCT 11. The method of any one of claims 1 to 9, wherein the first media stream is associated with a real-time protocol (RTP) session of a QUIC connection and wherein the QUIC connection is associated with multiple RTP sessions for respective multiple media streams.

12. The method of any one of claims 1 to 9, wherein the first media stream is associated with a real-time protocol (RTP) session of a QUIC connection, wherein the RTP session is associated with multiple media streams of differing media types, and wherein each media stream is associated with a unique QUIC Stream identification (ID) within the QUIC connection, the media stream identification information based on the QUIC Stream ID.

13. A method of a policy control function (PCF) of a core network (CN) of a wireless communication system, the method comprising: receiving an application request for quality of service (QoS) for one or more media streams of an application service data flow between an application server (AS) and a user equipment (UE) and application assistance information including media stream identification information associated with the one or more media streams; generating a policy and charging control (PCC) rule based on the application request, the PCC rule being specific to a first media stream of the one or more media streams; and transmitting the PCC rule to a session management function (SMF) of the CN.

14. The method of claim 13, further comprising: receiving the request from an application function (AF) of the CN or a via network exposure function (NEF) of the CN; and generating the PCC rule with PDU Set QoS parameters based on the application assistance information, wherein the PCC rule includes traffic detection information that includes media stream identification information.

15. A method of a session management function (SMF) in a core network (CN) of a wireless communication system, the method comprising: receiving, at a session management function (SMF) of the CN, a policy and charging control (PCC) rule from a policy control function (PCF) of the CN based on an application request for quality of service (QoS) for a plurality of media streams of an application service data flow between an application server (AS) and a user equipment (UE) and application assistance information associated with the media stream; configuring a radio access network (RAN) with a quality of service (QoS) profile based on a requested QoS for the media stream; andDocket No. 14730694300PCT communicating a configuration to a user plane function (UPF) of the CN, the configuration including at least one rule for protocol data unit (PDU) Set based QoS handling of a first media stream of the plurality of media streams, the configuration including: traffic detection information based on the application assistance information, the traffic detection information including media stream identification information for at least the first media stream of the plurality of media streams, and one or more QoS parameters for a PDU Set associated with the first media stream of the plurality of media streams.

16. The method of claim 15, wherein the media stream identification information includes at least one of: a media Stream ID value that identifies a QUIC stream specific to the first media stream; a QUIC Stream ID associated with the first media stream, the QUIC Stream ID based on the QUIC header of the QUIC packet; or a random number that is uniquely associated with the first media stream within the QUIC connection.

17. A method of an application function (AF), the method comprising: communicating a request via an application function (AF) to a control plane of a core network (CN), the request indicating a quality of service (QoS) requirement for at least a first media stream of a plurality of media streams of an application service data flow between the AS and a user equipment (UE), the request including application assistance information including media stream identification information associated with the first media stream; and causing an application server (AS) to communicate, to a user plane function (UPF) of the CN, an application packet for the first media stream, the application packet including metadata for matching to traffic detection information that is based on the media stream identification information.

18. The method of claim 17, wherein the request includes information about multiple media streams, including: a first QoS requirement for the first media stream, a first protocol description for the first media stream, a second QoS requirement for a second media stream, and a second protocol description for the second media stream.Docket No. 14730694300PCT 19. The method of claim 17 or 18, wherein the application assistance information includes one or more of: QoS requirements for the application service data flow associated with a QUIC connection; a traffic description including at least one Internet Protocol (IP) 5 tuple; additional QoS requirements for the media traffics within the QUIC connection, the additional QoS requirements associated with corresponding QoS correlation IDs; and additional traffic description for the first media stream including: a QoS Correlation ID of the first media stream, Transport Connection Correlation ID included in the metadata, or Transport Connection Associated Stream ID included in the metadata.

20. The method of any one of claims 17 to 19, wherein the application assistance information further includes: for the first media stream: PDU Set based QoS parameters including at least one of PDU Set Error Rate (PSER), PDU Set Delay Budget (PSDB), or PDU Set Integrated Handling Information (PSIHI).

21. A method of an application server (AS), the method comprising: causing an application function (AF) to communicate a request to a control plane of a core network (CN), the request indicating a quality of service (QoS) requirement for at least a first media stream of a plurality of media streams of an application service data flow between the AS and a user equipment (UE), the request including application assistance information including media stream identification information associated with the first media stream; and communicating, to a user plane function (UPF) of the CN, an application packet for the first media stream, the application packet including metadata for matching to traffic detection information that is based on the media stream identification information.

22. The method of claim 21, wherein the application packet includes an internet protocol (IP) header, a user datagram protocol (UDP) header, a UDP payload carrying a quick UDP Internet connection (QUIC) packet that encapsulates at least one real-time protocol (RTP) packet, and a UDP-Option field carrying the metadata, and wherein the metadata includes at least one of: a correlation identification (ID) value associated with a QUIC connection ID of an RTP session; media stream identification information associated with the first media stream;Docket No. 14730694300PCT a stream ID value based on a QUIC header of the QUIC packet; a mapped value based on a Stream ID in the QUIC header of the QUIC packet; a timestamp indicating time instance information of a most recent RTP packet encapsulated in the QUIC packet; priority information associated with the first media stream; information based on an RTP header extension of the RTP packet; or a number of RTP packets in the QUIC packet.

23. The method of claim 21 or 22, wherein the metadata further includes at least one of: a media Stream ID value that identifies a QUIC stream specific to the first media stream; a QUIC Stream ID associated with the first media stream, the QUIC Stream ID based on the QUIC header of the QUIC packet; or a random number that is uniquely associated with the first media stream within the QUIC connection.

24. The method of claim 22 or 23, wherein the priority information includes at least one of: a priority value based on a media type of the first media stream; a priority value based on a media frame type of media traffic in the first media stream; or a priority value of the first media stream based on application settings.

25. The method of any one of claims 21 to 24, wherein the metadata includes information based on a real-time protocol (RTP) RTP header extension field of the application packet, wherein the RTP header extension field includes one or more of the following fields: End PDU of the PDU Set, End of Data Burst, PDU Set Importance, PDU Set Sequence Number, PDU Sequence Number within a PDU Set, PDU Set Size, or other RTP header extension fields.

26. An apparatus, comprising: a communication unit; and a processing system configured to control the communication unit to implement a method according to any one of claims 1 to 25.

Images