Traffic detection for quality of service in a communication system

Abstract

This disclosure provides systems, methods and apparatuses for implementing quality-of-service (QoS) in a wireless communication system. The QoS can be applied to a protocol data unit, PDU, set for an application packet in an application service data flow between an application server and a user equipment (UE). A session management function, SMF, (115) can obtain (152) QoS requirements for a media stream of the application service data flow. An application function, AF, (170) can request QoS for a media stream and provide application assistance information associated with the media stream. The SMF configures (154) a user plane (198) with QoS 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 application server, AS, (150) transmits (172) an application packet that includes metadata matching the traffic detection information.

Description

TRAFFIC DETECTION FOR QUALITY OF SERVICE IN A COMMUNICATIONSYSTEMCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This Patent Application claims benefit of priority to U.S. Provisional Patent Application No. 63 / 547.333, filed November 3, 2023, entitled TRAFFIC DETECTION AND IDENTIFICATION 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 reality7and media (XRM) service, which refers to such technologies as extended Reality7(XR), Augmented Reality7(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 beunderstood 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 media stream of an application service data flow. The configuration includes traffic detection information and one or more QoS parameters. The method includes the UPF receiving a first application packet of the application service data flow. The first application packet includes metadata. The method includes the UPF communicating the first application packet via one or more PDUs in a PDU Set to a radio access network (RAN) for transmission to a user equipment (UE), where the UPF communicates the PDU Set using the one or more QoS parameters when the metadata matches the traffic detection information.

[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method of a control plane in a CN. The method includes the control plane receiving a request for QoS for a media stream of an application service data flow between an application server (AS) and a UE. The request includes application assistance information associated with the media stream. The method includes the control plane configuring a RAN with a QoS profile based on a requested QoS. The method includes the control plane communicating a configuration to a UPF of the CN. The configuration includes at least one rule for PDU Set based QoS handling of the media stream. The configuration includes traffic detection information based on the application assistance information and one or more QoS parameters for a PDU Set associated with the media stream.

[0010] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method of an application an AS. The method includes the AS communicating a request via an application function (AF) to a control plane of a CN. The request indicates a QoS for a media stream of an application service data flow between the AS and a UE. The request also includes application assistance information associated with the media stream. The method includes the AS communicating, to a UPF of the CN, an application packet for the media stream. The application packet includes metadata to match traffic detection information, where the traffic detection information is based on the application assistance information.

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

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

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

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

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

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

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

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

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

[0020] FIG. 6 shows an example IP packet structure sent over N6 to PDU session anchor user plane function (PSA UPF) in 5G network.

[0021] FIG. 7 shows an example IP packet structure sent over N6 to PSA UPF in 5G network.

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

[0023] 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 5 G network.

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

[0025] FIG. 11 shows example operations of a control plane of a 5GS.

[0026] FIG. 12 shows example operations of an application server.

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

[0028] 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 (3 GPP) 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 (loT) network, such as a system utilizing 4G, 5G, 6th generation (6G), ZigBee, Bluetooth, WiFi, or future radio technology.

[0029] This disclosure provides systems, methods, and apparatuses for coordinating quality- of-service (QoS) of an application service data flow between an application server and a user equipment (UE) via a wireless communication system. Examples of this disclosure are based on a 5G system (5GS) and an extended reality (XR) and media (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). The application (such as XRM application) may provide application layer data via an application packet. The application packet can encapsulate one or more real-time protocol (RTP) packets for a media stream of the application service data flow. 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. In the 5GS, a payload unit of application layer data (such as an application packet) may be segmented into one or more protocol data units (PDUs), collectively referred to as a PDU Set.

[0030] In accordance with aspects of this disclosure, a control plane of the 5GS obtains QoS requirements for a media stream of the application service data flow. A core network (CN) entity of the 5GS can receive a request indicting a requested QoS for the media stream and application assistance information associated with the media stream. Application assistance information can be referred to by other terms, such as traffic detection assistance information, QoS assistance information, XRM awareness information, etc.). The control plane can map the 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 a user plane function (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.

[0031] An application function (AF) (or an application server, AS) can request QoS for a media stream and provide the application assistance information to the 5GS. For example, the AF can provide the QoS requirements and application assistance information to a policy and charging control (PCC) of the CN. The PCC can prepare a PCC rule based on the requested QoS and application assistance information. The SMF uses the a PCC rule to configure the UPF with the traffic detection information and one or more QoS parameters. 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 based on the traffic detection information. For example, the AS can include the metadata in a UDP-Option field appended or prepended to a UDP payload of an application packet.

[0032] 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-traffic-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 for a media stream. The 5GS can use the techniques of this disclosure for application packets in tunneled or tunnel-less implementations of a user plane network.

[0033] 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 can 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 UE102 also can operate an application 190 (such as using an application processor, not shown) that sends / receives data to / from the AS 150.

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

[0035] 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 extension header defined in 3GPP TS 26.522 vO.1.1 (2023-08), 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 PDU Set information is used by the NG-RAN 105 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, (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.

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

[0037] In at least some of the cases, the solutions discussed below are based on one or more of the following assumptions: (i) the media application transmits RTP packets using RTP over QUIC transport layer protocol, whereby QUIC works as encryption and encapsulation layer for RTP sessions; (ii) one media type is supported in one RTP session which is transmitted within one QUIC connection; (iii ) the QUIC packet is encrypted based on IETF RFC 9000: “QUIC: A UDP-Based Multiplexed and Secure Transport”; (iv) the UDP-Option is used to provide metadata based on concept introduced in IETF draft-ietf-tsvwg-UDP-Options-23: “Transport options for UDP” and IETF draft-kaippallimalil-tsvwg-media-hdr-wireless-03: “Media Header Extensions for Wireless Networks.”

[0038] This disclosure provides solutions and potential technical advantages to enable PDU Set related handling for end-to-end encrypted traffic using RTP over QUIC. At a high level, below is a brief description of some example solutions:• Solution 1 (user plane over N6 interface) involves an IP packet structure using RTP over QUIC transport layer protocol and UDP-Option containing metadata (one QUIC packet can encapsulate one RTP packet).• Solution 2 (user plane over N6 interface) involves an IP packet structure using RTP over QUIC transport layer protocol and UDP-Option containing metadata (One QUIC packet can encapsulate more than one RTP packet).• Solution 3 (user plane over N6 interface) involves defining UDP-Option header for the UDP-Option if UDP payload is used by other transport layer protocol as encapsulation layer, e g., QUIC over UDP, RTP / SRTP over UDP.• Solution 4 (control plane signaling over N33 interface) involves an AF request message including assistance information for enabling PDU Set based handling in 5GS for the end-to-end encry pted traffic.• Solution 5 involves a high level-procedure for enabling PDU Set based Identification for end-to-end encrypted traffic. The solution can involve one or more of (i) an AF request (following Solution 4), (ii) metadata information in UDP-Option (following Solution 1 / 2 / 3), (iii) PCF providing a PCC rule to SMF, (iv) the SMF configuring PSA UPF via an N4 session, (v) a PSA UPF performing traffic detection and PDU Set based handling and performs PDU Set marking over GTP-U header, and (vi) NG-RAN performs 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.

[0039] Referring to FIG. 1 A, example operations illustrate a potential implementation and context for solutions 1-5. At block 152, an AF 170 can provide QoS requirements and application assistance information for a media stream to the PCF (either directly to the PCF or via an NEF). The PCF can prepare a PCC rule and provide the a PCC rule to the SMF. For example, the a PCC rule can indicate the QoS policy that is to be used for the media stream. The a PCC rule can also include the application assistance information (or traffic detection information based on the application assistance information) for traffic detection in the user plane.

[0040] At block 154, the AMF / SMF 115 can configure the user plane with QoS parameters based on the a 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 the media stream. The SMF can also provide traffic detection information based on the application assistance information to enable the UPF 160 to detect the traffic for the media stream. For example, the traffic detection information can indicate the metadata expected in an UDP-Option field of application packets for the media stream.

[0041] 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 the media stream and the PDU Set QoS parameters. At block 174, the UPF 160 can identify the application packets 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, mediaidentification 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 example 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.

[0042] 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 a PCC rule.

[0043] FIG. IB is a block diagram of an example wireless communication system 100B, such as 5GS, that supports PDU Set handling in the uplink direction using the techniques of this disclosure. The example wireless communication system 100B includes UEs 102A and 102B, a base station (BS) 104. a base station 106, and a core network (CN) 110, such as a fifth generation (5G) core (5GC). The base stations 104 and 106 can operate in a RAN 105 connected to the CN 110. Although described as a 5GC, the CN 110 can also be implemented as a sixth generation (6G) core or another suitable core network.

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

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

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

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

[0048] The UE 102A is equipped with processing hardware 130 A that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The UE 102A also includes a transceiver 132 A to communicate with the RAN 105 over a radio interface. Further, the UE 102A includes a memory 134A storing a PDU Set controller 142AA. 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, atransceiver 132B, and memory 134B for implementing aPDU Set controller 142 A.

[0049] FIG. 2 is a block diagram of an example protocol stack according to which the UE of FIG. IB can communicate with the RAN of FIG. IB. FIG. 2 illustrates, in a simplifiedmanner, 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.

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

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

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

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

[0054] N1 is a reference point between the UE 102 and the AMF 316. N2 is a reference point betyveen the RAN 105 and the AMF 316. N3 is a reference point betyveen 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.

[0055] 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 extension header 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 PDU 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 yvithin a QoS Flo v. 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.

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

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

[0058] 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 a 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.

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

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

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

[0062] The UE 102 or RAN 105 initiate PDU session modification procedure 526 for the existing PDU Session as described in 3GPP TS 23.502 clauses 4.3.2.2 and 4.3.2.3. The UE 102 may repeat the PDU establishment procedure 524 for multiple PDU Sessions which are associated with the same or different DNN and S-NSSAI.

[0063] When the PLMN provides homogeneous NG-RANs’ support of PDU-Set-based handling, the scenario 500 can be applied with the following enhancement for supporting PDU-Set-based QoS. The PCF 314 provides a PCC rule for an application service flow as defined in 3GPP TS 23.503 clause 6.1.3.27.4 that includes PDU Set QoS parameters (e.g., PSER, PSDB and PSIHI) and Protocol Description. The SMF 315 determines a QoS Profile for the QoS Flow, which is based on received a PCC rule or pre-configuration. 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 QER (QoS Enforcement Rule).

[0064] 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 media service data flow received from upper layer to provide NG-RAN in band uplink PDU Set information. According to one implementation, the RAN 105 performs PDU-Set-based QoS handling for radio resources management based on the following information: (i) uplink PDU Set information received from the UE 102 over air interface, and (ii) QoS profile containing uplink PDU-Set-based QoS parameters. The uplink 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.

[0065] Next, FIGs. 6-9 provides more detail regarding solutions 1-5 summarized above. FIG. 6 shows example implementations related to Solution 1. FIG. 7 shows example implementations related to Solution 2. FIG. 8 shows example implementations related to Solution 3. FIG. 9 shows example implementations related to Solution 5.

[0066] 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, it is proposed to implement QUIC protocol over UDP as shown in sections A-C of FIG. 6.

[0067] 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 stream for PDU Set Based Identification by the PSA UPF in the 5G network.

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

[0069] 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 that share the same RTP properties (e.g., I / P / B media frame ty pe).

[0070] The metadata that contains necessary RTP session information can include any of the following information (or combinations of the following information):• Correlation ID: 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.• Stream ID: The stream ID is unique within the QUIC Connection. This 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 extension header, 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).

[0071] The application can implement the RTP over QUIC protocol for the media traffic of a specific media type with the any of the following techniques:• one QUIC stream 676 is used for a specific RTP session;• one QUIC packet contains only one RTP packet;• UDP option 688 contains the metadata with information for the encrypted RTP packet and the QUIC streams 676 of the QUIC connection;• RTP packet of the RTP session is of one media type; and• RTP packet with different media types are multiplexed into different QUIC streams 676.

[0072] 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 as described below. In FIG. 7, one QUIC packet can encapsulate more than one RTP packets with the same QUIC connection and RTP session properties, including media frame type (e.g., I / P / B type), QUIC connection and QUIC stream 676, PDU Set. data burst, and PDU Set importance. Different QUIC streams which are synchronous transmit RTP packets with different media frame types (e.g., I / P / B type). For example, I media frames are transmitted via QUIC stream #A, P media frames are transmitted via QUIC stream #B, and B media frames are transmitted via QUIC stream #C, in which QUIC stream# A. QUIC stream#B, QUIC stream#C are within a common QUIC connection which shares the same IP 5 tuples.

[0073] The metadata that contains RTP session information can include any of the following information (or any combination of the following information):• 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.• Stream ID: The stream ID is unique within the QUIC Connection. This 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 extension header, e.g., based on [4], for the last RTP packet in the QUIC packet, 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), o Number of RTP packets in the QUIC packet, and / Or o Media frame ty pe of the PTP packets in the QUIC packet or Priority7of the QUIC packet based on the media frame type.

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

[0075] In some implementations, the metadata may be integrity7protected 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.

[0076] FIG. 8 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).

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

[0078] Having illustrated separate FIGs for Solutions 1-3, the details regarding Solution 4 are described by reference to previously-described NFs, interfaces, and metadata. Solution 4 describes an AF request (e.g., control plane signaling over an N5 or N33 interface between an AF and the PCF / NEF). This solution is proposed to provide assistance information from AF (application function) to 5G network for enabling PDU Set based handling at PSA UPF. The AF sends AF request message to the NEF / PCF can include any of the following assistance information (or any combination of the information):• QoS requirement that contains PDU Set based QoS parameters.• Traffic description that includes IP 5 tuples.• Additional traffic description that is included in the metadata, such as: o Transport Connection Correlation ID, or o Transport Connection Associated Stream ID(s).• Protocol Description: indicating the real-time transport layer protocol applied for the encapsulation layer for user plane traffic over N6, e.g., based on IETF RFC 3550. IETF RFC 3711, and 3GPP TS 26.522.• PDU Set Handling List of Stream ID(s) that require PDU Set Handling within the QUIC connection.• Additional Transport layer Protocol Description: indicating transport layer protocol that encapsulates upper layer packets, such as: o QUIC over UDP, and / or o UDP-Option.

[0079] For example, for application uses QUIC over UDP and UDP-Option following solution 1 -3, an AF request can provide the following information to the NEF / PCF in 5G network:• Traffic description includes IP 5 tuple for the service data flow.• QoS requirement for PDU Set based QoS handling including PDU Set Error Rate (PSER), PDU Set Delay Budget (PSDB), and / or PDU Set Integrated Handling Information (PSIHI).• Protocol Description indicating RTP / SRTP with RTP extension header defined in3GPP TS 26.522.• Additional traffic description including a Transport link Correlation ID and associated Stream ID(s): o For Solution 1, one associated Stream ID is indicated. o For Solution 2, multiple associated Stream IDs are indicated for associated media frame types.• Additional Transport layer Protocol Description indicating both QUIC, and UDP- Option.• PDU Set Handling List of Stream ID(s).

[0080] For example, for applications using RTP over UDP following 3GPP TS 23.501, 3GPP TS 23.502, and 3GPP TS 23.503, the AF request can provide the following information to the NEF / PCF in 5G network:• Traffic description includes IP 5 tuple for the service data flow• QoS requirement for PDU Set based QoS handling including PDU Set Error Rate (PSER), PDU Set Delay Budget (PSDB), PDU Set Integrated Handling Information (PSIHI).• Protocol Description indicating RTP / SRTP with RTP extension header defined in 3GPP TS 26.522.

[0081] 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 encry pted traffic in 5G network. Following Solution 4 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.

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

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

[0084] Step " 1" 952 shows AF 170 to PCF / NEF 114 communication: the AF sends AF request, 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 encry pted media traffic and assistant information for traffic detection, PDU Set identification and marking on the end-to-end encrypted media traffic. 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 encry pted media traffic by the PSA UPF.

[0085] The AF request can include at least one of the following pieces of information:• Traffic description,• Additional traffic description, including: o Transport Connection Correlation ID, and / or o Transport Connection Associated Stream ID(s).• QoS requirement.• Protocol Description: indicating the real-time transport layer protocol applied for the encapsulation layer for user plane traffic over N6, e.g. based on IETF RFC 3550: IETF RTP, IETF RFC 6904: IETF SRTP, and 3GPP TS 26.522: RTP extension header.• Additional Transport layer Protocol Description: indicate transport layer protocol that encapsulates upper layer packets, including: QUIC over UDP, UDP-Option, etc.• PDU Set Handling List of Stream ID(s).

[0086] For example, PDU Set QoS Parameters can include but are not limited to: PDU Set Delay Budget (PSDB). PDU Set Error Rate (PSER), and PDU Set Integrated Handling Information (PSIHI), etc.

[0087] For example, following solution 4, the assistance information can include but not limited to:• Additional traffic description of the metadata, such as: o Transport Connection Correlation ID, o Transport Connection Associated Stream ID(s), and / or o Protocol Description: indicate the real-time transport layer protocol applied for the encapsulation layer for user plane traffic over N6, e g. based on IETF RFC 3550: IETF RTP, 14: IETF SRTP and 3GPP TS 26.522: RTP extension header. o Additional Transport layer Protocol Description: indicate transport layer protocol that encapsulates upper layer packets, including: QUIC over UDP. UDP- Option, etc.o PDU Set Handling List of Stream ID(s).

[0088] 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 end-to-end encrypted traffics from a service data flow 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 and PSIHI) and traffic detection assistance information. At Step "2b" 956, the PCF sends session management policy association establishment or modification message session (a PCC rule) to the SMF.

[0089] At Step "3" 958: According to the a PCC rule from PCF, the SMF 115 performs QoS flow mapping to map a 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 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 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.

[0090] 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 within a QUIC connection containing one or more QUIC streams over N6 interface to PSA UPF.

[0091] 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 over 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 UPFmarks the identified PDU with PDU Set Information in GTP-U header to provide PDU Set Information to the NG-RAN.

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

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

[0094] FIG. 10 shows example operations 1000 of a PSA UPF (such as the UPF 160). At block 1054, the UPF receives, via a control plane of the CN, a configuration including at least one rule for protocol data unit (PDU) set-based quality7of service (QoS) handling of a media stream of an application service data flow. The configuration includes traffic detection information and one or more QoS parameters. 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 communicates the first application packet via one or more PDUs in a PDU Set to a radio access network (RAN) for transmission to user equipment (UE). wherein the UPF utilizes the PDU Set using the one or more QoS parameters when the metadata corresponds to the traffic detection information.

[0095] FIG. 11 shows example operations 1100 of a control plane of a 5GS. The example operations 1100 can include operations of a SMF (such as the AMF / SMF 115 or the SMF 315) and / or a PCF (such as the PCF / NEF 114 or the PCF 314). For brevity, the operations 1100 are described as performed by a UPF. At block 1054, the UPF receives, via a control plane of the CN, a configuration including at least one rule for protocol data unit (PDU) setbased quality of service (QoS) handling of a media stream of an application service data flow. The configuration includes traffic detection information and one or more QoS parameters. 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 communicates the first application packet via one or more PDUs in a PDU Set to a radio access network (RAN) for transmission to user equipment (UE), wherein the UPF utilizes the PDU Set using the one or more QoS parameters when the metadata corresponds to the traffic detection information.

[0096] FIG. 12 shows example operations 1200 of an application server (such as AS 150). At block 1252, the AS communicates a request via an application function (AF) to a controlplane of a core network (CN). The request indicates a quality of service (QoS) for a media stream of an application service data flow between the AS and user equipment (UE) and includes application assistance information associated with the media stream. At block 1272, the AS communicates an application packet for the media stream to a user plane function (UPF) of the CN. The application packet includes metadata designed to match traffic detection information, where the traffic detection information is based on the application assistance information.

[0097] FIG. 13 shows a block diagram of an example wireless communication system 2300 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 2300 includes the same elements as described with reference to FIG. 1A, including the UE 102 and the RAN 105. FIG. 13 also shows a second network entity 2306 and the core network 2311. In some implementations, the UE 102 can support at least a 5GNR (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.. SI or NG interface). The RAN 105 can connect to other base stations (including the second network entity 2306) via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes. In FIG. 13, the second network entity 2306 operates a second cell 2308B.

[0098] The RAN 105 is equipped with processing hardware 2304 that can include a receiver 2307B configured to receive data in the uplink direction. The processing hardware 2304 can also include a transmitter 2307A configured to transmit data in the downlink direction. The processing hardware further can one or more general-purpose processor(s) 2307C (e.g., CPUs) and a non-transitory computer-readable memory (CRM 2307D) storing instructions that the one or more general-purpose processors execute. Additionally, or alternatively, the processing hardware 2304 can include special-purpose processing units. The processor 2307C 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 2307D 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.

[0099] The UE 102 is equipped with processing hardware 2302 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory 2303D storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 2302 can alsoinclude a transmiter 2303A configured to transmit data in the downlink direction. The processing hardware further can include a receiver 2303B configured to receive data in the uplink direction. The processing hardware 2302, in an example implementation, includes a processor 2303C 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) 2303C may include, for example, one or more central processing units, GPUs, or other ASICs, and the like. To illustrate, the processor(s) 2303C 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 2303D 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) 2303C and other components of the processing hardware 2302 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) 2303C to enable user-plane communication, control-plane signaling, and user interaction with the UE 102.

[0100] The core network 2311 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 2311 can be implemented by one or more processing elements (shown as processing hardware 2310). The processing hardware 2310 can include atransmiter 2311 A, a receiver 231 IB, a processor 2311C, and a CRM 23 HD, similar to corresponding components described with reference to processing hardware 2302 and 2304.

[0101] The transmitters 2303A, 2307A, and 2311A and receivers 2303B, 2307B, and 231 IB are examples of a communication unit. The processors 2303C, 2307C. and 2311C 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 2306, and core network 2311 can include other components not illustrated in FIG. 13.

[0102] FIG. 1A through FIG. 13 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.

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

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

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

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

[0107] 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 the 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.

[0108] 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, Intemet-of-Things (loT) 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 (loT) device or a mobile-internet device (MID). Depending on the ty pe, 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.

[0109] 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 as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry7(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 circuitry7(e.g., configured by software) may be driven by7cost and time considerations.

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

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

[0112] 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 intendedto 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.

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

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

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

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

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

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

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

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

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

[0122] The discussion below concerns a solution for enabling the support of PDU Set detection and identification for e2e encrypted XRM traffics. This Appendix includes a proposed solution based on RTP over QU1C to enhance traffic detection and PDU Set information Identification for encrypted XRM in 5G networks. The solution solves an issue of if and how the 5GS performs PDU Set information Identification in an end-to-end encryption scenario.

[0123] The solution provides RTP over QUIC based Encrypted Traffic Detection, Identification, and QoS flows mapping. This solution addresses Key Issue #2: "Support PDU Set information identification for end-to-end encrypted XRM traffic" and Key Issue #Y: "Traffic detection and QoS flow mapping for multiplexed data flows".

[0124] This solution is proposed to enable the support of PDU Set related handling for end- to-end encrypted traffic using RTP over QUIC (RoQ) [IETF RFC 8835], RTP over QUIC allows RTP 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.

[0125] As shown in FIG. 7, the RTP over QUIC uses nest encapsulation that encapsulates RTP packets in QUIC payload. The necessary PDU Set Information contained in the RTP Extension header in 3GPP TS 23.501 is encrypted and become undetectable by the 5G network for traffic detection and PDU Set identification. The UDP Option in IETF draft-ietf- tsvwg-udp-options is a suitable tool to provide in-band metadata for the encrypted QUIC packet with encapsulated RTP packets.

[0126] This document contains provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.• [1] 3GPP TR 21.905: ‘'Vocabulary for 3GPP Specifications”.• [2] 3GPP TS 23.501: “System Architecture for the 5G System (5GS); Stage 2”.• [3] 3GPP TS 23.502: “Procedures for the 5G System; Stage 2”.• [4] 3GPP TS 23.503: "Policies and Charging control framework for the 5G System; Stage 2”.• [5] IETF RFC 3711: “The Secure Real-time Transport Protocol (SRTP)”, March 2004.• [6] IETF RFC 6904: '‘Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)”.• [7] IETF RFC 9335: “Completely Encrypting RTP Header Extensions and Contributing Sources’;• [8] IETF draft-ietf-avtcore-rtp-over-quic: “RTP over QUIC (RoQ)”.• [9] IETF draft-ietf-moq-transport: “Media over QUIC Transport”.•

[0010] IETF experimental draft-ietf-avtext-framemarking: “Frame Marking RTP Header Extension”.• [X] IETF TS 26.522: "5G Real-time Media Transport Protocol Configurations".• [Y] IETF draft-ietf-tsvwg-udp-options: "Transport options for UDP".

Claims

CLAIMSWhat 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 (154) including at least one rule for protocol data unit (PDU) set based quality of service (QoS) handling of a media stream of an application service data flow, the configuration including traffic detection information and one or more QoS parameters; receiving a first application packet of the application service data flow, the first application packet including metadata; and when the UPF identifies a PDU Set based on metadata matching the traffic detection information, 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) using the one or more QoS parameters.

2. The method of claim 1, wherein the configuration includes a packet detection rule (PDR) with packet detection information for the application service data flow, the method further comprising: detecting that the first application packet is associated with the application service data flow based on the packet detection information; and when the first application packet is associated with the application service data flow: determining that the at least one rule applies to the first application packet based on the metadata matching the traffic detection information.

3. The method of claim 1 or 2, wherein the first application packet includes an internet protocol (IP) header, a user datagram protocol (UDP) header, a UDP payload earn ing encrypted data, and an unencrypted UDP-Option field carrying the metadata.

4. The method of claim 3, wherein the UDP payload includes a quick user datagram protocol (UDP) Internet connection (QUIC) packet that encapsulates at least one real-time protocol (RTP) packet, and wherein the metadata includes at least one of: a correlation identification (ID) value associated with a QUIC connection ID of an RTP session;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 of the QUIC packet based on media type; information based on an RTP extension header of the RTP packet; or a number of RTP packets in the QUIC packet.

5. The method of any one of claims 1 to 4, wherein the metadata includes information based on real-time protocol (RTP) session information associated with an RTP session for the media stream.

6. The method of claim 5, wherein the metadata includes information based on an RTP extension header of the application packet, wherein the RTP extension header includes 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, andPDU Set Size.

7. The method of any one of claims 1 to 5, further comprising: receiving the configuration from a session management function (SMF) in the control plane of the CN, the configuration being associated with a QoS profile of a QoS flow in a radio access network (RAN).

8. The method of any one of claims 1-5 or 7, further comprising: receiving a plurality of application packets via an N6 interface between the UPF and an application server (AS), the plurality of application packets including the first application packet and a second application packet; implementing the one or more QoS parameters for the PDU Set associated with the first application packet based on the first application packet including the metadata matching the traffic detection information; and refraining from implementing the one or more QoS parameters for a second PDU Set associated with the second application packet based on the second application packet not including the metadata matching the traffic detection information.

9. The method of any one of claims 1-5 or 7, wherein the configuration includes: a QoS Enforcement Rule (QER) indicating the one or more QoS parameters; a Packet Detection Rule (PDR) indicating packet detection information; and the traffic detection information, wherein the traffic detection information is included in PDR or in a separate rule for traffic detection assistance information.

10. 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 a media stream 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; generating a policy and charging control (PCC) rule based on the application request; and transmitting the PCC rule to a session management function (SMF) of the CN.

11. The method of claim 10, 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.

12. 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 media stream 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; and 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 the media stream, the configuration including traffic detection information based on the application assistance information and one or more QoS parameters for a PDU Set associated with the media stream.

13. The method of claim 12, further comprising: mapping, by the SMF, the PCC rule to generate the QoS profile for a QoS flow in the RAN; communicating the QoS profile from the SMF to the RAN via an access and mobility' management function (AMF) of the CN; and wherein the communicating the configuration rules to the UPF via an N4 interface between the SMF and the UPF.

14. The method of claim 12, further comprising: mapping, by a session management function (SMF) of the CN, the requested QoS of the media stream to the QoS profile for a QoS flow in the RAN.

15. The method of any one of claims 12 to 14, further comprising: communicating, to the UE, a non-access stratum (NAS) message indicating QoS rules for the PDU Set.

16. A method of an application server (AS), 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 a media stream of an application service data flow between the AS and a user equipment (UE), the request including application assistance information associated with the media stream; and communicating, to a user plane function (UPF) of the CN, an application packet for the media stream, the application packet including metadata for matching to traffic detection information that is based on the application assistance information.

17. The method of claim 16, wherein the application packet includes an internet protocol (IP) header, a user datagram protocol (UDP) header, a UDP payload carrying application data, and an unencrypted UDP-Option field carrying the metadata.

18. The method of claim 17, further comprising: encapsulating the application data for the media stream in one or more real-time protocol (RTP) packets; encapsulating the one or more RTP packets in a quick user UDP Internet connection (QUIC) packet; populating the UDP payload with the QUIC packet; andpopulating the UDP-Option field with the metadata, wherein the metadata includes at least one of: a correlation identification (ID) value associated with a QUIC connection ID of the one or more RTP packets; 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 of the QUIC packet based on media type; information based on an RTP extension header of the one or more RTP packets; or a number of RTP packets in the QUIC packet.

19. The method of any one of claims 16 to 18, wherein the metadata includes information based on a real-time protocol (RTP) extension header of the application packet, wherein the RTP extension header includes 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, andPDU Set Size.

20. The method of any one of claims 16 to 19, wherein the application assistance information includes one or more of: the QoS requirements that contains PDU Set based QoS parameters; traffic description that includes IP 5 tuples; traffic description associated with the metadata, the traffic description including a Transport Connection Correlation identification (ID) or Transport Connection Associated Stream ID(s); a protocol description including a real-time transport layer protocol applied for an encapsulation layer for user plane traffic from the AS to the UPF;PDU Set Handling List of Stream ID(s) that require PDU Set Handling within a quick user datagram protocol (UDP) connection (QUIC); andadditional transport layer protocol description indicating a transport layer protocol that encapsulates upper layer packets, the transport layer protocol including QUIC over UDP, UDP-Option, or both.

21. 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 20.

Images