Quality of service provisioning for application services in a communication system

Abstract

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

Description

[0001] Cross-reference to related applications

[0002] This patent application claims priority to U.S. Provisional Patent Application No. 63 / 598,540, filed November 13, 2023, entitled “QOS PROVISIONING FOR ENCRYPTED XRMTRAFFIC IN A COMMUNICATION SYSTEM”, which has been assigned to the assignee of this application, the disclosure of which is incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and some aspects implement service detection and identification of encrypted services associated with a set of Protocol Data Units (PDUs). Background Technology

[0004] This background description is provided for the purpose of presenting the general context of this disclosure. The work of the currently attributed inventors (to the extent described in this background section) and aspects of the specification that would not have been considered prior art at the time of filing are neither expressly nor impliedly acknowledged as prior art to this disclosure.

[0005] Base stations operating according to the fifth-generation (5G) New Radio (NR) requirements support significantly greater bandwidth than fourth-generation (4G) base stations. With this increased bandwidth capability, new applications and services can enjoy high data rates and low latency. In some cases, among other examples, base stations can transmit data associated with Extended Reality and Media (XRM) services to user devices or user equipment (UEs), referring to technologies such as Extended Reality (XR), Augmented Reality (AR), Virtual Reality (VR), Mixed Reality (MR), or cloud gaming. These technologies generally involve quasi-periodic streaming of audio and / or video data.

[0006] The 3rd Generation Partnership Project (3GPP) is developing technologies to provide 5G System (5GS) support for advanced media services such as High Data Rate Low Latency (HDRLL) services, AR / VR / XR services, and haptic / multimodal communication services. To support XR communications (or more generally, data-intensive services), applications running on the UE can receive or initiate data bursts. The 5G Core Network (CN) and Radio Access Network (RAN) transmit data via Protocol Data Units (PDUs). A data burst can be understood as multiple units (e.g., PDUs) transmitted within a relatively short time period. A PDU refers to a unit of information at the protocol layer (e.g., packetized data). The payload of application data can be broken down into more than one PDU for transmission over the network. A “PDU set” refers to one or more PDUs carrying a payload of an application-level unit of information (e.g., a frame or video slice for an XR service). A PDU for a PDU set can correspond to the same Quality of Service (QoS) flow passing through the network (e.g., including the core network (CN) and radio access network (RAN)). The network manages QoS flows based on the QoS requirements for the PDU set.

[0007] Next-generation radio access networks (NG-RAN) can be aware of XRM services provided by 5G CNs. Application awareness (or XR awareness) refers to a technology where the CN can inform the NG-RAN of certain information about a PDU set. For example, if the NG-RAN fails to receive one PDU from the CN, it can stop transmitting other PDUs in that set through the radio access network. Therefore, the NG-RAN can conserve bandwidth and / or power because the PDU set (excluding the lost PDU) will be incomplete and unavailable. Current technologies for application awareness are limited. Better coordination between 5GS and XRM applications can enhance QoS and policies for XR and media service transmissions. Summary of the Invention

[0008] The systems, methods, and apparatus disclosed herein each have several innovative aspects, and no single innovative aspect is solely responsible for the desired properties disclosed herein.

[0009] One innovative aspect of the subject matter described in this disclosure can be implemented as a method for a User Plane Function (UPF) in the core network (CN) of a wireless communication system. The method includes: the UPF receiving configuration via the control plane of the CN, the configuration including at least one rule for Quality of Service (QoS) handling of a set of Protocol Data Units (PDUs) for multiple media streams of an application service data stream. The configuration includes service detection information and one or more QoS parameters associated with the multiple media streams. The service detection information includes media stream identification information for at least a first media stream among the multiple media streams. The method includes: the UPF receiving a first application packet including metadata. The method includes: the UPF identifying a set of PDUs for the first media stream based on the metadata matching the service detection information and the media stream identification information for the first media stream among the multiple media streams. The method includes: the UPF transmitting the first application packet to a Radio Access Network (RAN) via one or more PDUs in the PDU set for transmission to a User Equipment (UE) fulfilling one or more QoS parameters.

[0010] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method for a Policy Control Function (PCF) of a CN in a wireless communication system. The method includes: the PCF receiving an application request for QoS of one or more media streams of an application service data stream between an application server (AS) and a user equipment (UE), and application auxiliary information including media stream identification information associated with the one or more media streams. The method further includes: the PCF generating a Policy and Charging Control (PCC) rule based on the application request, the PCC rule being specific to a first media stream among the one or more media streams, and sending the PCC rule to the Session Management Function (SMF) of the CN.

[0011] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method for an SMF in a CN (Network Component ) of a wireless communication system. The method includes: the SMF receiving a PCC (Personal Control Code) rule from a PCF (Personal Control Function) of the CN, the PCC rule being an application request for QoS of multiple media streams for an application service data stream between an AS (Application Service Assignment System) and a UE (User Equipment), and application auxiliary information associated with the media streams. The method includes: the SMF configuring a QoS profile to the RAN (RAN) based on the requested QoS for the media streams. The method includes: the SMF communicating a configuration to a UPF (User Component Component) of the CN, the configuration including at least one rule for QoS handling of a first media stream among the multiple media streams based on a PDU set. The configuration includes service detection information based on the application auxiliary information. The service detection information includes media stream identification information for at least a first media stream among the multiple media streams, and one or more QoS parameters for the PDU set associated with the first media stream among the multiple media streams.

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

[0013] Another innovative aspect of the subject matter described in this disclosure can be implemented as an AS method. This method includes: the AS communicating an application packet for a first media stream to the UPF of the CN. The application packet includes metadata for matching service detection information based on media stream identification information.

[0014] Another innovative aspect of the subject matter described in this disclosure can be implemented as a device comprising a communication unit and a processing system configured to control the communication unit to implement any of the methods mentioned above.

[0015] 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 specification, drawings, and claims. Attached Figure Description

[0016] The same reference numerals and names in the various figures indicate the same elements. It should be noted that the relative dimensions of the figures may not be drawn to scale. For ease of identification of the discussion of any particular element or action, one or more of the highest significant digits in the reference numerals refer to the figure number in which that element was first introduced.

[0017] Figure 1A An example wireless communication system and Quality of Service (QoS) handling based on Protocol Data Unit (PDU) sets are illustrated.

[0018] Figure 1B A block diagram of an example wireless communication system, such as 5GS, is shown, using the techniques of this disclosure to support PDU set processing.

[0019] Figure 2 A block diagram of an example protocol stack is shown. Figure 1B The UE can use this example protocol stack to communicate with Figure 1B RAN communication.

[0020] Figure 3 A service-based representation of the 5GS architecture is shown, including the overall non-roaming reference architecture of the 5GS policy and charging control framework.

[0021] Figure 4The service-based, reference-point representation of the 5GS architecture is shown, including the overall non-roaming reference architecture of the 5GS policy and charging control framework.

[0022] Figure 5 A high-level messaging diagram is shown for an example scenario in which the UE uses Extended Reality and Media (XRM) services processed using a PDU set.

[0023] Figure 6 An example IP packet structure is shown, which has an example Fast User Datagram Internet Connection (QUIC) payload, which has an example Real-Time Protocol (RTP) packet sent via N6 to the PDU Session Anchor User Plane Function (PSA UPF) in the 5G network.

[0024] Figure 7 An example IP packet structure is shown, which has an example QUIC payload, which has one or more RTP packets sent via N6 to the PSA UPF in the 5G network.

[0025] Figure 8A Another example IP packet structure for PSA UPF transmitted to a 5G network via N6 is shown; Figure 8B Example metadata is shown.

[0026] Figure 9 An example process is shown for implementing PDU set-based processing (including PDU set-based QoS configuration, service detection, and PDU set identification) for end-to-end encrypted services in 5G networks.

[0027] Figure 10 An example operation of PSA UPF is shown.

[0028] Figure 11 An example operation of the Policy Control Function (PCF) of 5GS is shown.

[0029] Figure 12 An example operation of the 5GS Session Management Function (SMF) is shown.

[0030] Figure 13 An example operation of the application server is shown.

[0031] Figure 14 A block diagram of an example wireless communication system is shown, illustrating its hardware features and communication interface. Detailed Implementation

[0032] For the purpose of describing the innovative aspects of this disclosure, the following description relates to certain implementations. However, those skilled in the art will readily recognize that the teachings herein can be applied in a variety of different ways. Some examples in this disclosure are based on wireless communications according to 3GPP wireless standards, such as 4G Long Term Evolution (LTE) standards and 5G New Radio (NR) standards. However, the described implementations can be implemented in any apparatus, system, or network capable of transmitting and receiving radio frequency signals according to any of the wireless communication standards (including any of the IEEE 802.11 or 802.16 wireless standards) or other known signals used for communication within wireless, cellular, or Internet of Things (IoT) networks such as those utilizing 4G, 5G, 6G, ZigBee, Bluetooth, WiFi, or future radio technologies.

[0033] User equipment (UE) can receive application data from an application server (AS) via a communication network. In the case of wireless communication systems such as 5G systems (5GS), the core network (CN) and radio access network (RAN) transmit data via protocol data units (PDUs). Typically, the CN's Protocol Data Unit (PDU) Session Anchor User Plane Function (PSA UPF) (referred to herein as "UPF" for brevity) receives application packets and prepares a PDU set for transmission via the RAN. In some implementations, application packets carry encrypted services. Without the technology disclosed herein, the UPF may be unable to perform PDU set identification for end-to-end encrypted services when the media packet header information necessary for PDU set identification is partially or fully encrypted. Applications (such as Extended Reality and Media (XRM)) may generate services with multiple media types (e.g., voice, video, text, haptic, among other examples), each with different Quality of Service (QoS) requirements.

[0034] This disclosure provides systems, methods, and apparatus for fulfilling QoS for application services with multiple media streams via a wireless communication system. Examples of this disclosure are based on 5GS and XRM applications. However, these techniques can be applied to different types of communication networks that transmit data bursts for applications with QoS parameters (such as low latency) based on per-media-stream (or per-media-type). Applications (such as XRM applications) can provide application-layer data via one or more application packets. Application packets can encapsulate one or more Real-Time Protocol (RTP) packets for one or more media streams. In some implementations, RTP packets are encapsulated in Fast User Datagram Protocol (UDP) Connection (QUIC) packets carried within a UDP payload of an Internet Protocol (IP) packet. This disclosure provides a mechanism to enable PDU set identification on a per-media-stream basis at the UPF. In some implementations, transport layer protocols (such as QUIC) can carry multiple media streams (e.g., for different media types). The AS can use the UDP-option field to provide metadata for media stream identification and PDU set identification in a 5G network. This metadata enables the wireless communication system to determine which media stream (or media service type) is carried in RTP packets, ensuring that when application packets are transmitted as PDU sets in the RAN, the PDU set has QoS handling based on the QoS requirements for that media stream.

[0035] In some instances, multiple media streams can be multiplexed onto a single IP 5-tuple using transport protocols such as those described in IETF RFC 9000, different QUIC connections, or different QUIC streams (which can be identified by a unique connection ID + stream ID). A 5-tuple refers to a set of five elements that uniquely identify a network connection. These elements typically include: source IP address, destination IP address, source port number, destination port number, and protocol (e.g., TCP, UDP). Because an application can have multiple media streams sharing the same Internet Protocol (IP) 5-tuple, without the techniques of this disclosure, the UPF might be unable to determine which media stream is offloaded in each application packet. According to aspects of this disclosure, when multiplexed media streams share the same IP 5-tuple, the wireless communication system can support differentiated QoS for these streams. Multiple media streams can be multiplexed over the same end-to-end transport layer connection. Even if multiple RTP streams, Real-Time Control Protocol (RTCP) streams, and non-RTP streams are carried over the same QUIC connection, they can be distinguished.

[0036] The technology disclosed herein addresses at least the following issues: (i) when QUIC packets travel through a wireless communication system, intermediate network entities may change QUIC connections during network migration and may not know how to establish association between the QUIC connection and the RTP session of that QUIC connection; (ii) it may not be clear what information the 5G network needs to know for service detection and PDU set identification; and (iii) it may not be clear how 5GS performs service detection, service identification, and QoS stream mapping within a single end-to-end transport connection for multiplexed media streams of different media types with different QoS requirements.

[0037] According to various aspects of this disclosure, the 5GS control plane obtains QoS requirements for various media streams for application service data streams. The 5GS's CN entities (such as Policy Control Functions (PCF) or Network Open Functions (NEF)) can receive requests indicating requested QoS for each of multiple media streams, along with application ancillary information associated with those media streams. Application ancillary information can be referred to by other terms, such as service detection ancillary information, QoS ancillary information, XRM-aware information, etc. According to various aspects of this disclosure, application ancillary information includes information based on the media service type associated with different media streams. For each media stream, 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 service detection information based on the application ancillary information and provides that service detection information to the UPF. For example, the Session Management Function (SMF) can provide the UPF with the service detection information and one or more QoS parameters so that the UPF applies one or more QoS parameters to the PDU set carrying the application packet when the application packet includes metadata matching the service detection information per media stream. Service detection information can distinguish different media service types. For example, service detection information may include media stream identification information corresponding to a specific media stream.

[0038] Application Functions (AFs) (or Application Servers, ASs) can request QoS for media streams and provide application-aided information (AAFs) to the 5GS. For example, an AF can provide QoS requirements and AAFs to the PCF of the CN. For each media stream, the PCF can prepare Policy and Charging Control (PCC) rules based on the requested QoS and AAFs. The SMF uses these PCC rules to configure service detection information and one or more QoS parameters to the UPF. To implement QoS in the 5GS, the AF utilizes the AAFs to communicate the request. The AAFs enable the 5GS to identify streams with different media types and corresponding QoS parameters. The PCF prepares PCC rules based on the QoS parameters. The SMF applies the PCC rules via the QoS streams in the RAN and the N4 rules provided to the UPF by the SMF. The AAFs also enable the SMF to configure the UPF for PDU set identification.

[0039] When the AS communicates application packets for a media stream to the UPF, the AS populates the application packets with metadata so that the UPF can perform service detection (and media stream identification) based on the N4 rules. For example, the AS can include metadata in the UDP payload appended to the application packet or in the UDP-options field preceding the UDP payload of the application packet. Because the UDP payload of the application data packet may be encrypted, the UPF may not be able to retrieve information from the RTP header extension fields. The AS populates the unencrypted UDP-options fields with metadata so that the UPF can match the application packet to the PDU set information for the QoS stream. In some implementations, the metadata includes information based on the RTP header extension fields so that the UPF can identify the stream based on the media type and apply QoS handling based on the PDU set. The RTP header extension (or RTP header extension field) can also be referred to as the "RTP extension header" (or RTP extension header field).

[0040] Specific implementations of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. 5GS can implement QoS handling based on per-PDU set and per-media stream for application packets of application service data streams. AS can coordinate QoS requirements with 5GS, enabling application packets to be delivered over the core network and RAN in PDU sets with end-to-end QoS. In some aspects, application packets include metadata in unencrypted portions (such as UDP-option fields) and application data in encrypted portions such as UDP payloads. A potential technical advantage of including metadata in UDP-option fields is that UPF can quickly perform traffic detection and media stream identification for various media streams. Since metadata can include media stream identification information, transport layer protocols can support multiple media streams without multiple transport layer protocol sessions. This allows network elements (such as Network Address Translation (NAT) entities and firewalls) to save ports. 5GS can use the techniques of this disclosure for application packets in tunneled or tunnelless implementations of user plane networks.

[0041] Although the examples in this disclosure are based on downlink application services (e.g., from AS to UE via 5GS), the techniques disclosed herein can be applied to uplink application services (e.g., from UE to AS via 5GS). For example, the UE can transmit uplink application services to the AS via the RAN and UPF. The application client at the UE can include metadata in the UDP-options field to provide media stream identification information. The metadata may include media information based on RTP header extensions. The UE can use PDU set information associated with QoS flows in the RAN to tag PDUs. In some implementations, the UE implements features similar to the PSA UPF described in the examples of this disclosure to achieve service detection and PDU set identification. The NG-RAN can use the PDU set information to manage uplink radio resources.

[0042] Figure 1AAn example wireless communication system 100A and QoS handling based on a PDU set are illustrated. Example wireless communication system 100A shows the control plane 199 and user plane 198 of the CN in 5GS (sometimes referred to as 5GC). Access and Mobility Management Functions (AMF) and SMF are collectively shown as AMF / SMF 115. PCF and Network Open Function (NEF) are collectively shown as PCF / NEF 114. AF 170 may be included in the CN or may be co-located with AS 150. AMF / SMF 115, PCF / NEF 114, and AF 170 form part of the control plane 199 of the 5GS. Application data traverses the user plane 198, which includes UPF 160, RAN 105, and UE 102. UPF 160 may also be referred to as PDU Session Anchor User Plane Function (PSA UPF). Control plane 199 uses Non-Access Stratum (NAS) control messages to control the operation of user plane 198. In UE 102, modem 164 can provide physical layer (PHY) access to RAN 105 via a radio interface (referred to as the "Uu" interface). UE 102 can also (such as using an application processor, not shown) operate application 190, which sends data to / receives data from AS 150.

[0043] Figure 1A Some network interfaces among the various components are also shown, including the N5 interface between AF 170 and PCF / NEF 114, the N4 interface between AMF / SMF 115 and UPF 160, and the N6 interface between AS 150 and UPF 160. UPF 160 communicates with RAN 105 via the N3 interface. AMF (in AMF / SMF 115) controls RAN 105 via the N2 interface, and AMF controls UE 102 via the N1 interface. In some examples of this disclosure, AS 150 serves XRM applications and may include an XR data server. Application 190 may be an XR / AR / VR / MR application. In 5GS, RAN 105 may implement 5G New Radio (NR) and may be referred to as Next Generation RAN (NG-RAN). NG-RAN 105 receives PDU set QoS parameters from the QoS profile of SMF 115 via the N2 interface. The NG-RAN 105 further receives PDU set information for downlink XRM services from the UPF 160 via the N3 interface, or receives PDU set information for uplink XRM services from the UE via the Uu interface.

[0044] To support PDU-based QoS handling for XRM services, the PSA UPF 160 identifies PDUs belonging to a PDU set based on the RTP header extension defined in 3GPP TS 26.522 and determines the PDU set information below, which is then sent to NG-RAN 105. In some implementations, the UPF 160 transmits PDUs via the GPRS Tunneling Protocol User Plane (GTP-U). The UPF 160 may send the PDU set information in the GTP-U header. NG-RAN 105 uses the PDU set information for PDU-based QoS handling, as described in 3GPP TS 23.501. PDU set information includes (i) the PDU set sequence number, (ii) an indication of the last PDU in the PDU set, (iii) the PDU sequence numbers within the PDU set, (iv) the PDU set size in bytes, and (v) the PDU set importance, which identifies the relative importance of a PDU set compared to other PDU sets within a QoS flow. NG-RAN can use priority levels across QoS flows and PDU set importance within QoS flows to perform PDU set-level packet dropping in the event of congestion.

[0045] End-to-end encryption is widely deployed in current networks to provide security and can be used for XR and media (XRM) applications. Typically, when the media packet header information necessary for PDU set identification is partially or fully encrypted, the PSA UPF in a 5G network cannot perform PDU set identification as indicated in, for example, 3GPP TS 23.501, 3GPP TS 23.502, 3GPP TS 23.503, or 3GPP TS 26.522, for end-to-end encryption services. When considering end-to-end encryption for media services, QUIC-based RTP (RTP over QUIC) is a promising protocol that allows RTP (Real-Time Transport Protocol) packets to be encapsulated within QUIC packets via QUIC streams to transmit real-time data within a QUIC connection for a specific IP 5-tuple. In some implementations, the UDP-options field of the application packet might be used to provide the media packet header information necessary for PDU set identification in the 5G network. This application packet includes a UDP payload with encrypted application data. However, improvements are needed to enable PDU set identification at the PSA UPF in the 5G network. When QUIC packets traverse the network, QUIC connections may be altered by intermediate network entities during network migration. Traditional 5G deployments may not associate QUIC connections with RTP sessions for those connections. When QUIC connections encapsulate RTP packets (e.g., I / P / B frames), it is unclear what information (e.g., via the UDP-options field) needs to be provided to the 5G network for service detection.

[0046] This disclosure provides solutions and potential technical advantages for implementing PDU set-related processing for end-to-end encrypted services using QUIC-based RTP. Using the techniques of this disclosure, an AS (such as for XRM applications) can transmit data services from different media components with varying QoS requirements. When the UPF 160 operates as a PDU Session Anchor (PSA) UPF, to support PDU set-based QoS processing for applications such as XRM services, the UPF 160 identifies PDUs belonging to the PDU set and determines PDU set information. According to this disclosure, the UPF 160 determines the PDU set information based on service detection information, which includes media stream identification information.

[0047] refer to Figure 1AThe example operation illustrates a potential implementation. At box 152, AF 170 can provide QoS requirements and application-aided information for the application. In some implementations, the QoS requirements are based on media streams, allowing each media stream (for the corresponding media service type) to have different QoS requirements. AF 170 can also provide service descriptions for media streams and / or media service types. AF 170 can provide QoS requirements and application-aided information to the PCF (either directly to the PCF or via the NEF). At box 154, the PCF can prepare PCC rules and provide them to the SMF. For example, the PCC rules can indicate the QoS policy to be used for a specific media stream. The PCC rules can include application-aided information (or service detection information based on application-aided information) for service detection in the user plane. In this disclosure, the service detection information also includes media stream identification information. Among other examples, examples of media stream identification information include a relevance identifier (ID), a media stream ID, or a QUIC stream ID.

[0048] At box 162, the AMF / SMF 115 can configure QoS parameters to the user plane based on PCC rules. For example, the SMF can configure the AMF to the RAN 105 with QoS profiles mapped to QoS requirements for QoS flows. The SMF can provide configuration to the UPF 160 indicating one or more QoS parameters for the PDU set of application packets to be used for a specific media flow. The configuration can include different QoS parameters for different PDU sets associated with different media flows. The SMF can also provide service detection information (including media flow identification information) based on application auxiliary information to enable the UPF 160 to detect media flows. For example, the service detection information can indicate the metadata expected in the UDP-options field of the application packets for the media flow.

[0049] At box 172, AS 150 communicates the application data packet to UPF 160. The application packet may include metadata (such as in the UDP-options field) that enables UPF 160 to detect that the application packet is associated with a specific media stream and PDU set QoS parameters. As an example, among other examples, the metadata may be based on a media stream ID, a QUIC stream ID, an RTP stream ID, or a random number associated with the stream. At box 174, UPF 160 may identify the media stream for PDU set-based QoS handling based on matching service detection information with the metadata. In some implementations, UPF 160 first detects that the application packet satisfies the Packet Detection Rule (PDR) for the PDU set and then determines whether the application packet has metadata that matches the service detection information. Service detection information may also be referred to by other terms such as service detection auxiliary information (or, for brevity, "auxiliary information"), media stream detection information, media identification information, or other terms used to refer to information that can be matched with the metadata in the UDP-options field of the application packet. Among other examples, this disclosure includes several examples of service detection information and metadata, such as relevance identifiers (IDs), flow IDs, mapped flow IDs, RTP session information, and QUIC flow IDs. In some implementations, metadata “matches” service detection information when it is identical to the service detection information. In some implementations, metadata also matches service detection information when UPF 160 determines that the metadata is relevant to the service detection information (even if the actual content of the metadata differs from the service detection information). For example, service detection information may include rules or information that UPF 160 can use to detect the relevance of the metadata to the service detection information. The term “match” can be replaced with any word or phrase describing the relationship between the information, including “satisfies,” “corresponds,” “relevant,” “conforms,” “derives,” “aligns,” etc.

[0050] At box 174, when metadata matches service detection information, UPF 160 can determine that the application packet is associated with QoS parameters of the PDU set. UPF 160 applies one or more QoS parameters to the PDUs in the PDU set. For example, UPF 160 can update the PDU set information in the GTP-U header of the PDU so that RAN 105 can transmit the PDU set according to the QoS profile of one or more QoS parameters. At box 176, RAN 105 transmits the PDU set according to the QoS profile, where the QoS profile is mapped to the QoS requirements in the PCC rules.

[0051] Figure 1BThis is a block diagram of an example wireless communication system 100B, such as 5GS, that uses the techniques of this disclosure to support PDU set processing. The example wireless communication system 100B includes UEs 102A and 102B, base station (BS) 104, base station 106, and a core network (CN) 110, such as a fifth-generation (5G) core (5GC). Base stations 104 and 106 can operate in RAN 105 connected to CN 110. Although described as 5GC, CN 110 can also be implemented as a sixth-generation (6G) core or another suitable core network.

[0052] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, then cell 124 is an NR cell. If base station 124 is an ng-eNB, then cell 124 is an Evolved Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, if base station 106 is a gNB, then cell 126 is an NR cell, and if base station 126 is an ng-eNB, then cell 126 is an E-UTRA cell. Cells 124 and 126 can be located in the same Radio Access Network Notification Area (RNA) or in different RNAs. Cells 124 and 126 can partially overlap, allowing UE 102A or 102B to select, reselect, or transfer from one cell to the other. Generally, RAN 105 can include any number of base stations, and each base station can cover one, two, three, or any other suitable number of cells. UE 102 may support at least a 5G NR (or simply "NR") air interface to communicate with base stations 104 and 106. Each of base stations 104 and 106 may be connected to CN 110 via an interface (e.g., an S1 or NG interface). Base stations 104 and 106 may also be interconnected via an interface used to interconnect NG RAN nodes (e.g., an X2 or Xn interface).

[0053] The following text is for reference only. Figure 3 and Figure 4 Several network functions (NFs) that make up CN 110 are discussed. One or more of the NFs of CN 110 implement PDU set controller 112, which determines how and when to provide UEs 102A and 102B and / or RAN 105 with information related to PDU set-based processing.

[0054] Although not shown in Figure 1 to avoid clutter, CN 110 may include processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable storage of instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include dedicated processing units. The processing hardware may be configured to implement the techniques of this disclosure to achieve 5GS support for advanced media services.

[0055] Base station 104 is equipped with processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable storage (not shown) storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include dedicated processing units.

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

[0057] Figure 2 This is a block diagram of an example protocol stack. Figure 1B The UE can use this example protocol stack to communicate with Figure 1B RAN communication. Figure 2A simplified example protocol stack 200 for UE 102 and eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106) is illustrated. In the example stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then be routed to the Service Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer. Figure 2 (Not shown in the image) provides data transmission services. In some implementations, UE 102 supports, for example... Figure 2 The EUTRA and NR stacks shown are designed to support handover between EUTRA and NR base stations and / or support DCs via the EUTRA and NR interfaces. Further, as... Figure 2 As illustrated, UE 102 can support NR PDCP 210 layered on EUTRA RLC 206A, and SDAP sublayer 212 layered on NR PDCP sublayer 210.

[0058] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on PDCP layers 208 or 210) receive packets that can be referred to as Service Data Units (SDUs), and (e.g., to RLC layers 206A or 206B) output packets that can be referred to as Protocol Data Units (PDUs). Except where the difference between SDU and PDU is relevant, for simplicity, this disclosure refers to both SDU and PDU as "packets".

[0059] For example, on the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide signaling radio bearer (SRB) or RRC sublayer ( Figure 2(Not shown in the diagram) to exchange RRC messages or Non-Access Stratum (NAS) messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide data radio bearers (DRBs) to support data exchange. The data exchanged on NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0060] Figure 3 A service-based representation 300 of the 5GS architecture is shown, including the overall non-roaming reference architecture of the 5GS Policy and Charging Control (PCC) framework. The overall non-roaming reference architecture of the 5GS PCC framework includes components illustrated with solid lines, and other components illustrated with dashed lines. According to this representation, network functions enable other authorized network functions to access the services of these network functions. Components outside the PCC framework include network slice selection functionality (NSSF 302), network repository functionality (NRF 306), unified data management (UDM 308), edge application server discovery functionality (EASDF 310), network slice-specific authentication and authorization functionality (NSSAAF 322), authentication server functionality (AUSF 324), service communication broker (SCP 374), and network slice admission control functionality (NSACF 326). The non-PCC architecture further includes UE 102, RAN 105, and data network (DN 330). Application server (AS) 150 can operate in DN 330.

[0061] The PCC framework in Architecture 300 includes Unified Data Repository (UDR 352), Network Open Function (NEF 313), Network Data Analysis Function (NWDAF 356), Application Function (AF 170), Policy Control Function (PCF 314), Charging Function (CHF 362), Access and Mobility Management Function (AMF 316), Session Management Function (SMF 315), and User Plane Function (UPF 160).

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

[0063] When UPF 160 operates as a PDU Session Anchor (PSA) UPF to support PDU set-based QoS handling for XRM services, PSA UPF 160 identifies PDUs belonging to the PDU set, for example, based on the RTP header extension defined in 3GPP TS 26.522, and determines subsequent PDU set information. PSA UPF 160 sends this PDU set information to NG-RAN 105 in a GTP-U header. NG-RAN 105 can use the PDU set information for PDU set-based QoS handling (e.g., as described in, for example, 3GPP TS 23.501). PDU set information may include (i) the PDU set sequence number, (ii) an indication of the last PDU in the PDU set, (iii) the PDU sequence number within the PDU set, (iv) the PDU set size in bytes, and (v) the PDU set importance, which indicates the relative importance of a PDU set compared to other PDU sets within a QoS flow. NG-RAN can use priority levels across QoS flows and PDU set importance within QoS flows to perform PDU set-level packet dropping in the event of congestion.

[0064] Figure 4 It is a reference-point based representation of the 5GS architecture 400. Figure 4 In the diagram, the non-roaming reference architecture of the 5GS PCC framework is illustrated with solid lines representing boxes and connections, while components and connections outside the PCC framework are illustrated with dashed lines. According to this representation, network functions enable other authorized network functions to access the services of these network functions. Components outside the PCC framework include the Network Slice Selection Function (NSSF 302), Network Repository Function (NRF 306), Unified Data Management (UDM 308), Edge Application Server Discovery Function (EASDF 310), Network Slice Specific Authentication and Authorization Function (NSSAAF 322), Authentication Server Function (AUSF 324), Service Communication Agent (SCP 374), and Network Slice Admission Control Function (NSACF 326). The non-PCC architecture further includes UE 102, RAN 105, and data network DN 330.

[0065] The PCC framework in Reference Point Representation 400 includes a Unified Data Repository (UDR 352), Network Open Functions (NEF 313), Network Data Analysis Functions (NWDAF 356), Application Functions (AF 170), Policy Control Functions (PCF 314), Charging Functions (CHF 362), Access and Mobility Management Functions (AMF 316), Session Management Functions (SMF 315), and User Plane Functions (UPF 160). In the example implementation, AF 170 includes a user consent controller, and NEF 313 includes a user consent controller. In various implementations, CN 110 may include a user consent controller with only AMF 316, a user consent controller with only NEF 313, or both. The user consent controllers of AMF 316 and NEF 313 can be collectively referred to as the user consent control logic of CN 110.

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

[0067] The following section discusses several example techniques for QoS handling based on PDU sets. Generally speaking, Figures 5 to 12Similar events in the figures are labeled with similar reference numerals, with differences discussed below where appropriate. Apart from the differences shown in the figures and discussed below, any of the alternative implementations discussed for specific events (e.g., those used for messaging and processing) can be applied to events labeled with similar reference numerals in other figures.

[0068] Figure 5 A high-level messaging diagram is shown for an example scenario where the UE uses XRM services processed using a PDU set. During the registration process and PCF / UE association 522, AMF 316 determines whether UE 102 is authorized to use XRM services based on the UE's XRM service capabilities and the XRM service authorization included in the subscription data received from the UDM.

[0069] After successful registration, UE 102 requests PDU establishment procedure 524, and the NG-RAN capable of XRM services can perform PDU set processing on the QoS flow in the PDU session based on the XRM service authorization and information received from SMF 315 via the N2 interface and the GTP-U header received from UPF 160 via the N3 interface. The UE or network can initiate PDU session modification procedure 526 for an existing PDU session.

[0070] SMF 315 determines the QoS profile for the QoS flow, based on the received PCC rules or pre-configuration. For downlink services, PSA UPF 160 performs the following operations: (i) identifying PDUs belonging to the PDU set according to the protocol description based on the received PDR (Packet Detection Rule); (ii) marking the PDU set information in the GTP-U header as described in Clause 5.37.5.2 of 3GPP TS 23.501; and (iii) executing PDU set-based parameters based on the received QoS Enforcement Rules (QER). PSA UPF 160 transmits the PDU set to RAN 105 for transmission to UE 102. For uplink services, RAN 105 uses the uplink PDU set-based processing information instruction to instruct UE 102 to perform PDU set-based processing on the uplink media service data stream received from the upper layer, including PDU set identification and marking, to provide NG-RAN in-band uplink PDU set information.

[0071] According to one implementation, RAN 105 performs PDU set-based QoS processing for radio resource management based on the following information: (i) PDU set information received from PSA UPF 160 or UE 102, and (ii) a QoS profile containing PDU set-based QoS parameters. The PDU set information may include one or more of the following: (i) PDU set sequence number, (ii) an indication of the end PDU in the PDU set, (iii) PDU sequence numbers within the PDU set, (iv) the PDU set size in bytes, and (v) PDU set importance, which identifies the relative importance of a PDU set compared to other PDU sets within a QoS flow.

[0072] Next, Figures 6 to 9 More details are provided about several solutions (numbered 0-6 for brevity). At a higher level, a brief description of some example solutions follows: Solution 0 provides a sample IP packet structure using QUIC-based RTP and UDP-options. Solution 0X provides a sample definition of the UDP-options header for UDP-options. Figure 6 , Figure 7 and Figure 8A An example implementation related to solution 0 / 0X is shown.

[0073] Solution 1 provides an example of metadata in the UDP-options field; further reference is available. Figure 8B Describe it.

[0074] Solution 2 provides a mapping between RTP sessions and QUIC connections; see further reference. Figure 8B The following are descriptions: Solution 2.1 provides: different RTP sessions are mapped to different QUIC connections. Solution 2.2 provides: different RTP sessions are mapped to different QUIC streams on a QUIC connection. Solution 2.3 provides: the same RTP session with multiple media types is multiplexed and mapped to different QUIC streams on a QUIC connection.

[0075] Solution 3 involves further metadata processing, in Figures 6 to 8B Further details will follow.

[0076] Solution 4 provides a PDU set information marker in the GTP-U header, in Figures 6 to 8B Further details will follow.

[0077] Solution 5 provides control plane signaling via the N33 interface, in Figures 6 to 8B This will be described further later. More specifically, according to this solution, the AF request message includes auxiliary information for enabling PDU-based processing of end-to-end encrypted services in 5GS.

[0078] Solution 6 (further reference) Figure 9 The described procedure provides an advanced process for implementing PDU-based identification and QoS provisioning for end-to-end encrypted services of specific media streams associated with media types requiring PDU-based processing. More specifically, Solution 6 includes: an AF request (based on Solution 5); metadata information in UDP options (based on Solutions 1, 2, 3, and 4); the PCF providing PCC rules to the SMF; the SMF configuring the PSA UPF via an N4 session; the PSA UPF performing service detection and PDU-based processing, and performing PDU-based marking via a GTP-U header; and the NG-RAN performing PDU-based QoS processing based on the GTP-U header marked by the PSA UPF and a QoS profile provided by the SMF that includes PDU-based QoS parameters.

[0079] Figure 6 This illustrates an example IP packet structure for PDU Session Anchor User Plane Function (PSA UPF) sent to a 5G network via N6. To implement PDU-based processing for end-to-end encrypted services using a QUIC-based transport layer protocol in a 5G network, an IP packet structure with QUIC-based RTP and UDP options is used. Figure 6 Part of AC is shown.

[0080] exist Figure 6 In part A (shown by arrow 601), the IP packet contains an IP header 682 and a UDP datagram. The UDP datagram includes a UDP header 684, UDP options 688, where the QUIC packet is encapsulated in a UDP payload 686, and UDP options 688 contain metadata including necessary RTP session information. This RTP session information is mapped to the QUIC stream of the QUIC connection for PSA UPF identification based on PDU sets in the 5G network.

[0081] exist Figure 6 In part B (shown by arrow 602), the UDP payload 686 contains a QUIC packet of a specific QUIC stream 676, which is located within a QUIC connection for a specific RTP session (i.e., only one QUIC stream is used for a specific RTP session).

[0082] exist Figure 6 In part C (shown by arrow 603), within QUIC stream 676, the QUIC packet includes a QUIC header 674 and a QUIC payload 672. The QUIC payload 672 encapsulates one or more RTP packets, which contain an RTP header and an RTP payload.

[0083] In some implementations, enhancements are used to reduce signaling overhead. A QUIC packet can encapsulate more than one RTP packet with the same RTP session attributes for an RTP session within a QUIC connection. These attributes include: media frame type (e.g., I / P / B type), QUIC connection and QUIC stream, PDU set, data burst, and PDU set importance.

[0084] In some implementations, a correlation ID can be generated and used to identify a specific QUIC connection and QUIC flow 676 for service data flows sharing the same IP 5-tuple. For two QUIC flows within the same QUIC connection (with the same QUIC connection ID), the correlation ID is set differently for service data flows sharing the same IP 5-tuple.

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

[0086] Figure 7 An example 700 IP packet structure for PSA UPF transmitted over N6 to a 5G network is shown. (About...) Figure 7 The described example can reduce overhead. Figure 7 In a QUIC connection, a single QUIC packet can encapsulate more than one RTP packet within the same QUIC connection.

[0087] exist Figure 7 In section A (shown as arrow 705), the IP packet contains an IP header 682 and a UDP datagram (shown as UDP header 684, UDP header 684, and UDP options 688). UDP options 688 contain metadata, which includes the necessary RTP session information for the QUIC stream mapped to the QUIC connection.

[0088] exist Figure 7 In part B (shown as arrow 707), the UDP payload contains a QUIC packet for a specific QUIC stream, which is located within a QUIC connection for a specific RTP session; that is, a QUIC stream is used for a specific RTP session.

[0089] exist Figure 7 In section C (shown as arrow 709), for this QUIC stream, the QUIC packet includes a QUIC header and a QUIC payload, whereby the QUIC payload encapsulates one or more RTP packets sharing the same RTP packet attributes (e.g., I / P / B media frame type). When an RTP packet is encapsulated in a QUIC payload, Figure 6 (Part C) and Figure 7 (Part of C) is the same.

[0090] Figure 8A An example 800 IP packet structure is shown for PSA UPF transmission over N6 to a 5G network. If the UDP payload 686 is used as an encapsulation layer by other transport layer protocols (e.g., UDP-based QUIC, UDP-based RTP, QUIC-based RTP), the corresponding method defines a UDP-option header 888A for UDP-option 688 to provide metadata related to the encapsulated packets, which encrypt information required for packet handling and routing in a particular network (e.g., PDU-based handling in 5GS).

[0091] The UDP Options header 888A may include one or more of the following information segments: PT (Payload Type): Indicates the format of the metadata payload and thus determines how the application interprets it. For example, this value can be the encapsulation layer protocol specific to the UDP payload, such as QUIC, RTP, or both (QUIC based on RTP).

[0092] X (Extended): (1 bit) Indicates the presence of an extension between the UDP-options header and the UDP-options payload data. Expand Exhibition Header This extended header is application-specific or profile-specific.

[0093] Header extension: (Optional, may be provided by...) Extend (Field Indicators). For example, the first X bits contain a profile-specific identifier and a length indicator that indicates the length of the extension in X bits (excluding the X bits of the extended header). The extended header data follows immediately.

[0094] A separate example is provided for solution 0 / 0X. Figure 6 , Figure 7 and Figure 8A Next, details regarding Solution 1 will be described with reference to the previously described network functions, interfaces, and metadata. Solution 1 provides, as follows: Figure 8B Additional example implementations of the metadata shown.

[0095] Metadata containing necessary RTP session information may include any of the following (or a combination thereof): Relevance ID 892: A fixed-length hash value generated by the application. This Relevance ID is used to associate a QUIC connection ID, which can change throughout the lifecycle of the QUIC connection.

[0096] Media Stream ID 891: The media stream ID is unique within a QUIC connection to identify the QUIC stream encapsulated as an "RTP stream" within the QUIC connection. This media stream ID can be set using one of the following options: Option 1: The QUIC stream ID within the associated QUIC connection, if included in the QUIC header of the QUIC packet.

[0097] Option 2: A fixed-length random number 894 generated by an application (e.g., using a hash function).

[0098] Stream ID 893: The stream ID is unique within a QUIC connection. This information element (IE) can be set to the stream ID, or to a mapped value of the stream ID, as included in the QUIC header of a QUIC packet encapsulated in a UDP payload.

[0099] Timestamp: Used to provide time instance information for the encapsulated RTP packets.

[0100] Information in the RTP header extension, such as: The end PDU [E] (1 bit) in the PDU set. End of data burst [EDB] (3 bits), PDU set importance [PSI] (4 bits), PDU set sequence number [PSSN] (10 bits), The PDU sequence number [PSN] (6 bits) within the PDU set, and / or PDU set size [PSSize] (24 bits).

[0101] In some implementations, the metadata further includes: QUIC Stream Priority: This value defines the relative priority within a QUIC connection.

[0102] For example, if media services with multiple media types (e.g., voice, video, data) are multiplexed into different QUIC streams, the priority value of the QUIC stream can be based on the media type.

[0103] For example, if the media service is a video with multiple media frame types multiplexed into different QUIC streams, the priority value of the QUIC stream can be based on the media frame type (e.g., I / P / B frames).

[0104] For example, the QUIC protocol can perform congestion control by creating new QUIC flows for different routing settings. The application can then specify the priority value of the QUIC flows based on application settings.

[0105] In some implementations (referred to as Solution 1.1), the media stream ID can be integrated with the relevance ID into a single IE, the media relevance ID, to identify the QUIC stream and QUIC connection used for an application's RTP session. In some implementations, the media relevance ID can be a fixed-length hash value generated by the application, for example, using both the initial QUIC connection ID and the QUIC stream ID. This media relevance ID is used to associate the QUIC stream within the QUIC connection, which can change throughout the QUIC connection's lifecycle.

[0106] Figure 8BExample metadata that can be included in UDP option 688 is shown. In some examples 890, the metadata includes one or more of a media stream ID 891, a correlation ID 892, a QUIC stream ID 893, or a random number 894 (which uniquely identifies the stream within an RTP session). Media stream identification information allows the UPF to associate media streams with media information associated with QoS parameters (e.g., for a set of PDUs). When an application packet is associated with a specific media stream of an application, the UPF can send a set of downlink PDUs in the QoS stream based on PCC rules (e.g., rules for binding a media stream to a QoS stream that fulfills the QoS requirements for that media type). Since an application can have multiple media types, the UPF can use media stream identification information to identify multiple media streams and send those multiple media streams in the PDU set according to the corresponding QoS streams within those multiple media streams.

[0107] In some implementations, metadata may include additional information 895 related to media service type, PDU set handling, and / or QoS requirements. For example, metadata may include media information 898 (e.g., information based on RTP header extension fields and / or PDU set information). Alternatively or additionally, metadata may include information based on the RTP session 897 (e.g., any information that may be included in the RTP header, or any information based on the RTP protocol used between the AS and UE). Alternatively or additionally, metadata may include any information describing the media type carried in the application packet. In some implementations, metadata is based on information in the RTP header extension used for PDU set handling, such as the last PDU in the PDU set, the end of the data burst, PDU set importance, PDU set sequence number, PDU sequence numbers within the PDU set, and / or PDU set size. The UPF may use metadata to identify appropriate PCC rules that define QoS profiles for QoS flows in the RAN and to apply PDU set information to downlink PDUs sent by the UPF based on application packets and metadata.

[0108] Solution 2 describes the mapping between RTP sessions and QUIC connections. RTP packets are encapsulated in QUIC streams using the following mapping method.

[0109] Solution 2.1: Different RTP sessions are mapped to QUIC streams in different QUIC connections (one RTP session per QUIC connection).

[0110] Solution 2.2: Different RTP sessions are mapped to different QUIC streams (each QUIC connects to multiple RTP sessions, and each RTP session is for a specific media type).

[0111] Solution 2.3: The same RTP session with multiple media types is multiplexed and mapped to different QUIC streams (each QUIC connection is an RTP session, which can be multiplexed with multiple media types).

[0112] This application implements the QUIC-based RTP protocol through one of the following methods for media services specific to a particular media type: A QUIC packet contains one or more RTP packets.

[0113] The UDP option includes metadata that contains information about the encrypted RTP packets and the QUIC stream for the QUIC connection.

[0114] One or more QUIC streams are used for a specific RTP session that includes RTP media streams and RTCP streams.

[0115] The synchronized different QUIC streams can be further used to send RTP packets with different media frame types (e.g., I / P / B frames) for the RTP session.

[0116] [QoS Requirements]: Different QUIC flows within a QUIC connection depend on the media services of the RTP session (e.g., RTP, RTCP) and QUIC-related signaling. 5G networks need to configure QoS for QUIC connections by differentiating QUIC flows with the corresponding required QoS parameters.

[0117] In Solution 2.1, different RTP sessions are mapped to different QUIC connections. The application implements the QUIC-based RTP protocol for media services using the following additional methods: A QUIC connection is used for media services of a specific media type.

[0118] RTP packets in an RTP session belong to a media type.

[0119] RTP packets of different media types are sent via different QUIC connections, and these QUIC connections correspond to different RTP sessions. In other words, one RTP session is mapped to one QUIC connection.

[0120] The application uses Stream Identifier (FID) information in the RTP packet header to distinguish different media types of media services, and can then use different QUIC connections for different media types associated with different RTP sessions.

[0121] Metadata used to identify RTP streams within a QUIC connection (following Solution 2): Relevance ID: A fixed-length hash value generated by the application. This Relevance ID is used to associate a QUIC connection ID, which can change throughout the lifecycle of the QUIC connection.

[0122] Media Stream ID: Unique within a QUIC connection, this ID identifies the QUIC stream encapsulated as an "RTP stream" within the QUIC connection. This Media Stream ID can be set using the following options: Option 1: The QUIC stream ID within the associated QUIC connection, if included in the QUIC header of the QUIC packet.

[0123] Option 2: A fixed-length random number generated by an application (e.g., using a hash function).

[0124] Option 3: FID, such as included in the QUIC payload of the QUIC group.

[0125] A QUIC connection can contain different QUIC streams for media services (e.g., RTP / RTCP) in an RTP session.

[0126] [QoS Requirements]: For different media types, the QoS requirements of media services are associated with the QUIC streams carrying RTP media packets in different QUIC connections.

[0127] Table 1 shows examples of mappings among media types, RTP sessions, QUIC connections, and QUIC streams.

[0128]

[0129] Table 1: Diagram of RTP session encapsulation in QUIC connection

[0130] In Solution 2.2, different RTP sessions are mapped to different QUIC streams. The application implements the QUIC-based RTP protocol for media services using the following additional methods: A single QUIC connection can be used for media services of multiple media types.

[0131] RTP packets in an RTP session belong to a media type.

[0132] RTP packets of different media types are sent via different QUIC streams within a single QUIC connection, where each QUIC stream corresponds to a different RTP session. In other words, an RTP session is mapped to a single QUIC stream within a single QUIC connection.

[0133] The application uses FID (Stream Identifier) ​​information in the QUIC payload to distinguish RTP sessions, and then uses a QUIC stream for each RTP session with different media types.

[0134] Metadata used to identify RTP streams within a QUIC connection (following Solution 2): Relevance ID: A fixed-length hash value generated by the application. This Relevance ID is used to associate a QUIC connection ID, which can change throughout the lifecycle of the QUIC connection.

[0135] Media Stream ID: Unique within a QUIC connection, this ID identifies the QUIC stream encapsulated as an "RTP stream" within the QUIC connection. This Media Stream ID can be set using the following options: Option 1: The QUIC stream ID within the associated QUIC connection, if included in the QUIC header of the QUIC packet.

[0136] Option 2: A fixed-length random number generated by an application (e.g., using a hash function).

[0137] Option 3: FID, such as included in the QUIC payload of the QUIC group.

[0138] [QoS Requirements]: For different media types, the QoS requirements of media services are associated with the QUIC stream carrying RTP media packets of different RTP sessions in the QUIC connection.

[0139] Table 2 shows examples of mappings among media types, RTP sessions, QUIC connections, and QUIC streams.

[0140]

[0141] Table 2: Diagram of RTP session encapsulation in QUIC connection

[0142] In Solution 2.3, the same RTP session with multiple media types is multiplexed and mapped to different QUIC streams. The application implements the QUIC-based RTP protocol for media services through the following additional methods: A single QUIC connection can be used for media services of multiple media types.

[0143] A QUIC stream is used for a specific media type in an RTP session.

[0144] RTP packets in an RTP session belong to multiple media types.

[0145] RTP packets with different media types are sent via different QUIC streams within a single QUIC connection, where each QUIC stream corresponds to a different media type multiplexed within an RTP session. In other words, an RTP stream with a specific media type within an RTP session is mapped to a single QUIC stream within a QUIC connection.

[0146] The application uses the SSRC information in the RTP packet header to distinguish the media type of the RTP stream within an RTP session (with a specific stream identifier FID), and then uses different QUIC streams for different media types of the RTP streams in that RTP session.

[0147] Metadata used to identify RTP streams within a QUIC connection (following Solution 2): Relevance ID: A fixed-length hash value generated by the application. This Relevance ID is used to associate a QUIC connection ID, which can change throughout the lifecycle of the QUIC connection.

[0148] Media Stream ID: Unique within a QUIC connection, this ID identifies a QUIC stream encapsulated with a specific media type, designated as an "RTP stream," within the QUIC connection. This Media Stream ID can be set using the following options: Option 1: The QUIC stream ID within the associated QUIC connection, if included in the QUIC header of the QUIC packet.

[0149] Option 2: A fixed-length random number generated by an application (e.g., using a hash function).

[0150] Option 3: SSRC, such as in the RTP header of an RTP packet encapsulated in a QUIC packet.

[0151] [QoS Requirements]: For different media types, the QoS requirements of media services are associated with the QUIC stream carrying the RTP stream within the RTP session in the QUIC connection.

[0152] Table 3 shows examples of mappings among media types, RTP sessions, QUIC connections, and QUIC streams.

[0153]

[0154] Table 3: Diagram of RTP session encapsulation in QUIC connection

[0155] Having described the UDP options and the mapping from media streams to metadata options, Solution 3 provides further examples of metadata for media stream identification. In some implementations, a correlation ID can be generated and used to identify a specific QUIC connection and QUIC stream for service data streams sharing the same IP 5-tuple. For two QUIC streams within the same QUIC connection (with the same QUIC connection ID), the correlation ID is set differently for service data streams sharing the same IP 5-tuple.

[0156] In some implementations, metadata can be protected for integrity using a secure hash function (e.g., SHA-256, SHA-3, and BLAKE2), which can be negotiated between 5GC and the application, or it can be based on a service level agreement (SLA). If based on a SLA, the PSA UPF can have the secure hash function pre-configured. If metadata requires integrity protection, the application generates a hash of the metadata and includes that hash in the UDP options.

[0157] Solution 4 provides an example implementation for marking PDU set information in the GTP-U header. Based on auxiliary information configured by the SMF via the N4 session and metadata from IP packets via the N6 interface included in the UDP-option, the PSA UPF can perform the following operations: Identify PDUs (Packet Data Units) belonging to a specific PDU set and perform QoS handling based on the PDU set according to the QER included in the N4 rule.

[0158] The identified PDU is marked with PDU set information in the GTP-U header to provide PDU set information to NG-RAN. This PDU set information includes the following items: QoS Stream ID, which corresponds to the QUIC Stream ID.

[0159] Timestamp: Used to provide time instance information for the last encapsulated RTP packet.

[0160] QUIC stream priority: Defines the relative priority within a QUIC connection.

[0161] QUIC packet information: includes information based on RTP header extensions (e.g., based on 3GPP TS 26.522) for the last RTP packet: End of PDU set The end of the data burst PDU set importance PDU set serial number PDU serial number within the PDU set PDU set size The number of RTP packets in a QUIC packet.

[0162] Solution 5 provides an example implementation of an AF (or AS) request. The AF request is communicated using control plane signaling via the N33 interface between the AF and the PCF (or NEF). This request includes application support information for implementing PDU-based processing at the PSA UPF, including service detection, PDU-based identification, and QoS flow mapping. The AF sends an AF request message to the NEF / PCF, which includes the following information (or any combination thereof): QoS requirements for service data streams Additional QoS requirements for media services within a QUIC connection.

[0163] QoS requirements and the corresponding QoS relevance ID used to associate additional service descriptions.

[0164] The business description includes an IP 5-tuple.

[0165] The additional business description includes a list of the following information: QoS Relevance ID Includes the transport connection-related ID in the metadata.

[0166] The transport connection is associated with the stream ID, which is included in the metadata.

[0167] The protocol description indicates that RTP / SRTP has the RTP header extension defined in 3GPP TS 26.522 for applicable QUIC connections and QUIC flows. This IE indication applies to real-time transport layer protocols for the encapsulation layer of user plane services via N6, such as those based on IETF RFC 3550: Real-time Transport Protocol (RTP), IETF RFC 3711: Secure Real-time Transport Protocol (SRTP), and 3GPP TS 26.522: 5G Real-time Media Transport Protocol configuration.

[0168] A list of PDU set handling requirements for flow IDs within a QUIC connection. This information indicates the need for PDU set handling to the PCF / SMF / UDF. Some QUIC flows carrying control signaling do not require PDU set handling.

[0169] Additional transport layer protocol description: Indicates the transport layer protocol encapsulating the upper-layer packets, including: UDP-based QUIC, UDP-options, and RTP. UPF can use this information to perform corresponding service detection and PDU set information identification.

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

[0171] For media type #A that requires QoS based on PDU sets for video, the AF request may include: QoS requirements for service data streams as indicated in 3GPP TS 23.501 Additional QoS requirements for service data streams using UDP-based QUIC.

[0172] QoS Relevance ID #1, based on PDU set QoS parameters including PDU set error rate (PSER), PDU set delay budget (PSDB), and PDU set integrated processing information (PSIHI). The service description includes the IP 5-tuple for service data stream #B for the QUIC connection.

[0173] The protocol description indicates RTP / SRTP with the RTP header extension defined in 3GPP TS 26.522.

[0174] The additional business description includes a list of the following information: QoS Relevance ID#1 Transmission Link Dependency ID#A Related flow ID#X.

[0175] For media type #B of voice that requires QoS parameters as indicated in 3GPP TS 23.501, the AF request may include: QoS requirements for service data streams as indicated in 3GPP TS 23.501 Additional QoS requirements for service data streams using UDP-based QUIC.

[0176] QoS Relevance ID#2, as indicated in 3GPP TS 23.501, refers to the QoS parameters for voice services. The service description includes the IP 5-tuple for service data stream #B for the QUIC connection.

[0177] The additional business description includes a list of the following information: QoS Relevance ID#2 Transmission Link Dependency ID#B Related flow ID#Y.

[0178] Solution 5.1 is an example of Solutions 2.2 and 2.3. An example of an AF request for QoS configuration is as follows: For QUIC connections with video media type #A and voice media type #B that require QoS based on PDU sets: Such as the QoS requirements for service data streams indicated in 3GPP TS 23.501.

[0179] Additional QoS requirements for service data streams using UDP-based QUIC.

[0180] QoS Relevance ID #1, based on PDU set QoS parameters including PDU set error rate (PSER), PDU set delay budget (PSDB), and PDU set integrated processing information (PSIHI). QoS Relevance ID#2, as indicated in 3GPP TS 23.501, refers to the QoS parameters for voice services. The business description includes a 5-tuple of IP addresses for the service data stream.

[0181] The protocol description indicates that RTP / SRTP with the RTP header extension defined in 3GPP TS 26.522 is applicable to QUIC connections and QUIC flows.

[0182] The additional business description includes a list of the following information: QoS correlation ID#1, transmission link correlation ID#X, associated flow ID#A.

[0183] QoS correlation ID#2, transmission link correlation ID#X, associated flow ID#B.

[0184] Figure 9 An example procedure 900 is shown for implementing PDU set-based processing (including PDU set-based QoS configuration, service detection, and PDU set identification) for end-to-end encrypted services in 5G networks. It follows Solution 5 for AF requests and Solutions 1 / 2 / 3 for metadata information in UDP-options, and references... Figure 9 The solution proposes a process for implementing PDU set-based processing (including PDU set-based QoS configuration, service detection, and PDU set identification) for end-to-end encrypted services using QUIC-based RTP in 5G networks. Figure 9 The diagram shows UE 102, RAN 105, UPF 160, AMF / SMF 115, PCF / NEF 114, and AF 170, which are entities related to... Figure 1A Entities with the same number in the text correspond to each other.

[0185] For the sake of brevity, Figure 9 The operations are described as numbered steps (e.g., step "0" 920, step "1" 952, etc.). Step numbering is intended to provide clarity of description and does not necessarily require a specific order or sequence of operations. Furthermore, some steps may be omitted or added in various implementations.

[0186] Step “0” 920 illustrates the execution of the PDU session establishment procedure (defined in 3GPP TS 23.502 Clause 4.3.2.2.1). In some implementations, the network slice type used for XR services can be used for this PDU session. Step “0” 920 may include references Figure 5 One or more operations as described.

[0187] Step “1” 952 illustrates the communication between AF 170 and PCF / NEF 114: AF sends an AF request to 5GC via NEF / PCF, the AF request containing information indicated in Solution 4, such as a new request message or as defined in Clause 4.15.6.6 of 3GPP TS 23.502. Nnef_AFsessionWithQoS_Create The request provides PDU set-based QoS requirements for end-to-end encrypted media services, as well as auxiliary information for service detection, PDU set identification, PDU set marking, and QoS associated with media types requiring PDU set-based processing. The PCF may use the information provided by the AF to determine PCC rules (as defined in Clause 6.1.3.27.4 of 3GPP TS 23.503) and to identify PDU set information in end-to-end encrypted media services by the PSA UPF.

[0188] Step “2” 954 shows that, based on auxiliary information from the AF directly or via the NEF and QoS requirements based on the PDU set, the PCF determines to perform PDU set-based QoS processing on the end-to-end encrypted media stream within the application's service data stream (based on IP 5-tuples). The PCF determines the PDU set QoS parameters based on information provided by the AF and / or local configuration to generate PCC rules. These PCC rules include the PDU set QoS parameters (e.g., PSER, PSDB, PSIHI, etc.) and service detection auxiliary information with media stream identification information for a specific media stream associated with the media type requiring PDU set-based processing. At step “2b” 956, the PCF sends a Session Management Policy Association Establishment or Session Modification message (PCC rule) to the SMF.

[0189] At step “3” 958: Based on the PCC rules from PCF 114, SMF 115 performs QoS flow mapping to map a specific media stream within the service data stream (identified by the relevance ID and media stream ID based on Solution 1, or the media relevance ID based on Solution 1.1) to a QoS stream, determines a QoS profile for that QoS stream, and determines N4 rules, which include QoS enforcement rules (QER) with QoS parameters based on the PDU set and packet detection rules (PDR) with auxiliary information for the specific media stream, which is included in the packet detection information. Alternatively, SMF can be configured to support PDU set QoS processing without receiving PCC rules from PCF.

[0190] At step “3a” 962: SMF 115 sends N4 rules to PSA UPF, which include QER and PDR with packet detection information for a specific media stream.

[0191] At step “3b”964: SMF 115 sends a QoS profile and QoS rules contained in the NAS message to NG-RAN via AMF.

[0192] At step “3c”966: SMF 115 sends QoS rules to the UE in a NAS message via AMF and NG-RAN.

[0193] At step “4” 972 (performed by AS or AF 170): The application encapsulates the RTP packet in a QUIC packet and sends the QUIC packet with UDP-option to the PSA UPF within the QUIC connection via the N6 interface. The UDP-option contains metadata according to any of solutions 1-5. The QUIC connection contains one or more QUIC streams.

[0194] At step “5” 974 (performed by UPF 160): When receiving IP packets from the application server via N6, PSAUPF performs service detection based on the configured PDR received in step 3a, and performs PDU set identification based on metadata included in the UDP-options and auxiliary information received from the SMF. As an example, step 5 may include step 5a: Based on the PDR with auxiliary information configured by the SMF via the N4 session in step 3b and metadata from IP packets via the N6 interface included in the UDP-options, PSA UPF can identify PDUs (Packet Data Units) belonging to a specific PDU set, and perform QoS handling based on the PDU set according to the QER included in the N4 rules. At step “5b” 976 (showing communication from UPF 160 to RAN 105 via N3): PSA UPF marks the identified PDUs with PDU set information in the GTP-U header to provide PDU set information to the NG-RAN.

[0195] In some implementations, PSA UPF can remove the UDP-option or replace the UDP-option with padding bits before forwarding the PDU.

[0196] At step “6” 978 (executed by RAN 105): Based on the PDU set information in the GTP-U header, the RAN performs QoS processing based on the PDU set and maps the QoS flow to one or more DRBs. For example, at step “6a” 979, the NG-RAN sends the DRB to the UE via NR-Uu. At step “6b” 990, the UE maps the received DRB to the QoS flow based on QoS rules and then forwards the downlink packets to the XRM application.

[0197] Figure 10Example operation 1000 of a PSA UPF (such as UPF 160) is illustrated. At box 1062, the UPF receives a configuration via the control plane of the CN, which includes at least one rule for Quality of Service (QoS) handling of multiple media streams of an application service data stream based on a PDU set. This configuration includes service detection information and one or more QoS parameters associated with the multiple media streams. The service detection information includes media stream identification information for at least a first media stream among the multiple media streams. At box 1072, the UPF receives a first application packet of the application service data stream, wherein the first application packet includes metadata. At box 1074, the UPF 160 identifies the PDU set for the first media stream based on the metadata, matching the service detection information and the media stream identification information for the first media stream among the multiple media streams. At box 1076, the UPF forwards the first application packet to the radio access network (RAN) via one or more PDUs in the PDU set for transmission to a user equipment (UE) using one or more QoS parameters.

[0198] Figure 11 Example operation 1100 of a 5GS PCF (such as PCF 114 or PCF 314) is shown. At box 1152, an application request for Quality of Service (QoS) of one or more media streams of an application service data stream between an application server (AS) and a user equipment (UE) is received, along with application auxiliary information including media stream identification information associated with the media stream. At box 1154, the PCF generates a Policy and Charging Control (PCC) rule based on the application request, wherein the PCC rule is specific to a first media stream among the one or more media streams. At box 1156, the PCF sends the PCC rule to the Session Management Function (SMF) of the CN.

[0199] Figure 12Example operation 1200 of a 5GS SMF (such as SMF 115 or SMF 315) is shown. At box 1256, the SMF receives policy and charging control (PCC) rules from the core network's (CN) Policy Control Function (PCF). These PCC rules are based on application requests for Quality of Service (QoS) for multiple media streams in the application service data stream between the application server (AS) and user equipment (UE), along with application auxiliary information associated with the media streams. At box 1264, the SMF configures a QoS profile to the radio access network (RAN) based on the requested QoS for the media streams. At box 1262, the SMF communicates the configuration to the CN's User Plane Function (UPF). This configuration includes at least one rule for QoS handling of a first media stream based on a set of Protocol Data Units (PDUs) among the multiple media streams. This configuration includes service detection information based on application auxiliary information, which contains media stream identification information for at least the first media stream. This configuration specifies one or more QoS parameters for the set of PDUs associated with the first media stream among multiple media streams.

[0200] Figure 13 Example operation 1300 of an application server (such as AS 150) is illustrated. At box 1352, the AS communicates a request to the control plane of the core network (CN) via an application function (AF), indicating a Quality of Service (QoS) requirement for at least a first media stream among multiple media streams in an application service data stream between the AS and the user equipment (UE). The request includes application auxiliary information containing media stream identification information associated with the first media stream. At box 1372, the AS communicates an application packet for the first media stream to the user plane function (UPF) of the CN. This packet includes metadata for matching service detection information based on the media stream identification information.

[0201] Figure 14 A block diagram of an example wireless communication system 1400, illustrating its hardware features and communication interface, is shown. The depicted hardware configuration may omit certain components frequently implemented in such electronic devices, such as displays, peripherals, and power supplies. The example wireless communication system 1400 includes components related to the reference... Figure 1A The same elements described include UE 102 and RAN 105. Figure 14The second network entity 1406 and core network 1411 are also shown. In some implementations, UE 102 may support at least 5G NR (or simply "NR") or E-UTRA air interface for communication with RAN 105. RAN 105 is connected via an interface (e.g., an S1 or NG interface). RAN 105 may be connected to other base stations (including the second network entity 1406) via interfaces used to interconnect NG RAN nodes (e.g., an X2 or Xn interface). Figure 14 In the middle, the second network entity 1406 operates the second cell 1408B.

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

[0203] UE 102 is equipped with processing hardware 1402, which may include one or more general-purpose processors such as a CPU and a non-transitory computer-readable memory 1403D storing machine-readable instructions executable on the one or more general-purpose processors, and / or dedicated processing units. Processing hardware 1402 may also include a transmitter 1403A configured to transmit data in the downlink direction. Processing hardware may include a receiver 1403B configured to receive data in the uplink direction. In an example implementation, processing hardware 1402 includes a processor 1403C to process data that UE 102 will transmit in the uplink direction or to process data received by UE 102 in the downlink direction. Processor 1403C may include, for example, one or more central processing units, GPUs, or other ASICs. For illustration, processor 1403C may include an application processor (AP) used by UE 102 to execute an operating system and various user-level software applications, and one or more processors utilized by a modem or baseband processor. CRM 1403D may include any suitable memory or storage device, such as RAM, SRAM, DRAM, NVRAM, ROM, flash memory, SSD, or other high-capacity storage devices, which may be used to store one or more executable software instruction sets and associated data, which manipulate one or more processors 1403C and other components of processing hardware 1402 to perform the various functions described herein and attributed to UE 102. The executable software instruction sets include, for example, an operating system (OS) and various drivers (not shown) and various software applications (not shown), which can be executed by processor 1403C to enable user plane communication, control plane signaling, and user interaction with UE 102.

[0204] The core network 1411 can be an evolved packet core (EPC) and / or a 5G core (5GC). Among other components, the EPC may include a Serving Gateway (SGW), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), and a Packet Data Network Gateway (PGW). The SGW is generally configured to deliver user plane packets related to audio calls, video calls, internet services, 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., internet networks and / or internet protocol (IP) multimedia subsystem (IMS) networks). The 5GC includes User Plane Functions (UPF), Unified Data Management (UDM), Access and Mobility Management Functions (AMF), and / or Session Management Functions (SMF). Generally, the UPF is configured to deliver user plane packets related to audio calls, video calls, internet services, 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 UDM store and maintain subscription information about UE 102. The core network 1411 may be implemented by one or more processing elements (shown as processing hardware 1410). Processing hardware 1410 may include a transmitter 1411A, a receiver 1411B, a processor 1411C, and a CRM 1411D, similar to the corresponding components described in reference processing hardware 1402 and 1404.

[0205] Transmitters 1403A, 1407A, and 1411A, and receivers 1403B, 1407B, and 1411B are examples of communication units. Processors 1403C, 1407C, and 1411C may also be referred to as processing systems. Other examples of communication units and processing systems are possible, including some commonly used examples in wireless communication systems. RAN 105, UE 102, second network entity 1406, and core network 1411 may include... Figure 14 Other components not listed in the table.

[0206] Figures 1A to 14 The operations described herein are examples intended to aid in understanding exemplary implementations and should not be used to limit potential implementations or the scope of the claims. Some implementations may perform additional operations, fewer operations, operations in parallel or in a different order, and some operations in different ways.

[0207] Aspects of the subject matter described in this disclosure can be implemented as a computer-readable medium having instructions stored therein, which, when executed by a processor, cause the processor to perform any of the functions described above. Aspects of the subject matter described in this disclosure can be implemented as a system having components for implementing any of the functions described above. Aspects of the subject matter described in this disclosure can be implemented as a device having one or more processors configured to perform one or more operations from any of the functions described above.

[0208] The following additional considerations may apply to the foregoing and the following discussion.

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

[0210] Unless otherwise defined, the technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this specification pertains. The terms “first,” “second,” etc., as used herein, do not indicate any order, quantity, or importance, but are used to distinguish one element from another. The terms “including,” “comprising,” or “having,” and variations thereof, used herein, are intended to encompass the items listed thereafter and their equivalents, as well as additional items. The terms “connection” and “coupling” are not limited to physical or mechanical connections or couplings, but may include electrical connections or couplings, whether direct or indirect. Furthermore, the terms “circuit,” “circuit system,” and “control unit” may include a single component or multiple components that are active and / or passive and are connected or otherwise coupled together to provide the described function. Additionally, the term “operationally coupled,” as used herein, includes wired coupling, wireless coupling, electrical coupling, magnetic coupling, radio communication, software-based communication, or combinations thereof.

[0211] Some or all of the foregoing or following implementations may be combined or combined to form a new or other implementation. The foregoing or following techniques may be used to solve at least (but not limited to) the problems or scenarios mentioned in this disclosure. Any two or more of the foregoing or following paragraphs, (sub)bullets, points, actions, or claims described in each method / technique / implementation may be logically, reasonably, and appropriately combined to form a particular method. Any sentence, paragraph, (sub)bullet, point, action, or claim described in each of the foregoing or following techniques / implementations / concepts may be implemented independently and separately to form a particular method. Dependencies such as “based on,” “more specifically,” “wherein,” etc., in the techniques / implementations / concepts mentioned in this disclosure are merely one possible implementation that does not limit the specific method.

[0212] As used herein, the terms “user device,” “user equipment” (e.g., UE 102), “wireless communication device,” “mobile communication device,” “communication device,” or “mobile device” refer to any or all of the following: a cellular phone, smartphone, portable computing device, personal or mobile multimedia player, laptop computer, tablet computer, smartbook, Internet of Things (IoT) device, handheld computer, wireless email receiver, cellular phone with multimedia Internet support, wireless game controller, display subsystem, driver assistance system, vehicle controller, vehicle system controller, vehicle communication system, infotainment system, vehicle telematics system or subsystem, vehicle display system or subsystem, vehicle data controller, point-of-sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle or other personal media device, wearable device (such as a smartwatch), wireless hotspot, femtocell, broadband router, or other type of router, as well as similar electronic devices including programmable processors and memories and circuitry systems configured to perform the operations described herein. Furthermore, in some implementations, the user device may be embedded in an electronic system such as the main unit of a vehicle or an advanced driver assistance system (ADAS). Furthermore, the user device can operate as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

[0213] Certain techniques described in this disclosure are included as comprising logic or multiple components or modules. A module can be a software module (e.g., code or machine-readable instructions stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and can be configured or arranged in a certain manner. A hardware module may include a dedicated circuit system or logic that is persistently configured (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC), digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also include programmable logic or circuit systems (e.g., as encompassed within a general-purpose processor or other programmable processor) that are temporarily configured by software to perform certain operations. The decision to implement a hardware module in a dedicated and persistently configured circuit system or in a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

[0214] When implemented in software, these technologies can be provided as part of an operating system, a library used by multiple applications, or a specific software application. The software can be executed by one or more general-purpose processors or one or more dedicated processors.

[0215] As used herein, the terms “component” and “module” are intended to be broadly interpreted 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 interpreted as meaning “at least partially based on”.

[0216] As used herein, a phrase referring to a list of items separated by "or" refers to any combination of those items, including a single member. For example, "a, b, or c" is intended to cover the following possibilities: only a, only b, only c, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a, b, and c.

[0217] In this disclosure, the expression “X / Y” can include the meaning of any of the following: “X or Y”, or “X and Y”, or “X and / or Y”. The expression “(A) B” or “B (A)” can include the concept of “B only”. The expression “(A) B” or “B (A)” can include the concept of “A+B” or “B+A”.

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

[0219] This article describes several aspects in conjunction with thresholds. As used in this article, meeting a threshold can refer to a value that is 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, or not equal to the threshold.

[0220] The various illustrative components, logic, logic blocks, modules, circuits, operations, and algorithmic processes described in conjunction with the implementation methods disclosed herein can be implemented as electronic hardware, firmware, software, or a combination of hardware, firmware, or software, including the structures disclosed in this specification and their structural equivalents. The interchangeability of hardware, firmware, and software has been generally described 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 on the specific application and design constraints imposed on the system as a whole.

[0221] As described above, some aspects of the subject matter described in this specification can be implemented as software. For example, the various functions of the components disclosed herein, or the various blocks or steps of the methods, operations, processes, or algorithms disclosed herein, can be implemented as one or more modules of one or more computer programs. Such computer programs may include non-transitory processor-executable instructions or computer-executable instructions encoded on one or more tangible processor-readable or computer-readable storage media for execution by or control of the operation of a data processing apparatus that includes components of the apparatus 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 can 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.

[0222] Various modifications to the implementations described in this disclosure will be apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations without departing from the scope of this disclosure. Therefore, the claims are not intended to be limited to the implementations shown herein, but are given the widest scope consistent with this disclosure, the principles disclosed herein, and the novel features.

[0223] Additionally, the various features described in this specification in the context of individual implementations can also be implemented in combination in a single implementation. Conversely, the various features described in the context of a single implementation can also be implemented individually or in any suitable sub-combination in multiple implementations. Thus, although features may be described above as functioning in a particular combination and even initially claimed in this way, in some implementations one or more features from the claimed combination may be removed, and the claimed combination may involve sub-combinations or variations of sub-combinations.

[0224] The accompanying drawings may schematically depict one or more example processes in the form of a flowchart or table. However, other operations not depicted may be incorporated into the schematically illustrated example processes. For example, one or more additional operations may be performed before, after, simultaneously with, or between any of the illustrated operations. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of the various system components in the implementations described above should not be construed 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 set forth in the claims may be performed in a different order and still achieve the desired result.

[0225] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations can be made based on the foregoing disclosure, or from practice in the aspects. Although aspects of this disclosure have been described with respect to various examples, any combination of aspects from any example is also within the scope of this disclosure. The examples in this disclosure are provided for illustrative purposes only.

[0226] Appendix A

[0227] IETF RoQ

[13] Stream Identifier (FID): A stream identifier used to demultiplex different data streams on the same QUIC connection.

[0228] The payload in a QUIC stream begins with a stream identifier, followed by one or more RTP / RTCP payloads.

[0229] All RTP / RTCP payloads sent on a stream must belong to an RTP session with the same stream identifier.

[0230] Each payload begins with a length field indicating the length of the RTP / RTCP packet, followed by the packet itself.

[0231] QUIC Grouping: [FID, (length[1], RTP group #1), (length[2], RTP group #2), …, (length[N], RTP group #N) ]

[0232] IETF RFC 3500: RTP header:

[0233] PT: RTP payload type

[0234] IETF RFC 8860: SSRC: (32 bits) Synchronization source identifiers uniquely identify the source of a stream.

[0235] The synchronization source within the same RTP session will be unique.

[0236] RTP payload type is never used to distinguish RTP streams.

[0237] RTP packets are demultiplexed into RTP streams based on their SSRC; Then, the RTP payload type is used to select the correct media decoding path for each RTP stream.

[0238] An RTP session for a raw stream can include multiple RTP streams, and those RTP streams can use a variety of media types.

[0239] Within an RTP session where multiple media types have been configured for use, SSRC can only send one type of media during its lifetime (i.e., it can switch between different audio codecs because those are all of the same type of media, but it cannot switch between audio and video).

Claims

1. A method for User Plane Function (UPF) in the core network (CN) of a wireless communication system, the method comprising: The configuration (162) is received via the control plane of the CN. The configuration includes at least one rule for QoS handling of multiple media streams of the application service data stream based on the Protocol Data Unit (PDU) set. The configuration includes service detection information and one or more QoS parameters associated with the multiple media streams. The service detection information includes media stream identification information for at least a first media stream among the multiple media streams. Receive the first application packet, which includes metadata; The PDU set for the first media stream is identified by matching the service detection information with the metadata and the media stream identification information for the first media stream among the multiple media streams. as well as The first application packet is transmitted to the radio access network (RAN) via one or more PDUs in the PDU set for transmission to the user equipment (UE) that performs the one or more QoS parameters.

2. The method of claim 1, wherein the metadata includes information on the media service type of the first media stream based on a Real-Time Protocol (RTP) session.

3. The method of claim 1 or 2, wherein the metadata includes a media stream identifier ID value that matches the media stream identifier information.

4. The method as described in any one of claims 1 to 3, The first application packet includes an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, a UDP payload, and a UDP-options field. The UDP payload carries a Fast UDP Internet Connection (QUIC) packet encapsulating at least one Real-Time Protocol (RTP) packet. The UDP-options field carries the metadata. The metadata mentioned therein includes at least one of the following: The correlation identifier ID value associated with the QUIC connection ID of the RTP session; Media stream identification information associated with the first media stream; Based on the stream ID value of the QUIC header of the QUIC group; Based on the mapping value of the stream ID in the QUIC header of the QUIC packet; A timestamp indicating the time instance information of the most recent RTP packet encapsulated in the QUIC packet; Priority information associated with the first media stream; Information based on the RTP header extension of the RTP packet; or The number of RTP packets in the QUIC packet.

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

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

7. The method of any one of claims 1 to 6, wherein the media stream identification information is based on stream identifier (FID) information, the FID information being specific to a media type of the first media stream from a plurality of media types associated with a plurality of corresponding User Datagram Protocol (UDP) connections.

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

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

10. The method of any one of claims 1 to 9, wherein the first media stream is associated with a Real-Time Protocol (RTP) session of a QUIC connection, and wherein the QUIC connection is specific to the RTP session.

11. The method of any one of claims 1 to 9, wherein the first media stream is associated with a Real-Time Protocol (RTP) session of a QUIC connection, and wherein the QUIC connection is associated with multiple RTP sessions for corresponding multiple media streams.

12. The method of any one of claims 1 to 9, wherein the first media stream is associated with a Real-Time Protocol (RTP) session of a QUIC connection, wherein the RTP session is associated with multiple media streams of different media types, and wherein each media stream is associated with a unique QUIC stream identifier ID within the QUIC connection, the media stream identifier information being based on the QUIC stream ID.

13. A method for the policy control function (PCF) of a core network (CN) of a wireless communication system, the method comprising: Receive application requests for the Quality of Service (QoS) of one or more media streams of the application service data stream between the application server AS and the user equipment UE, as well as application auxiliary information including media stream identification information associated with the one or more media streams; Based on the application request, policy and charging control (PCC) rules are generated, the PCC rules being specific to a first media stream among the one or more media streams; as well as The PCC rule is sent to the Session Management Function (SMF) of the CN.

14. The method of claim 13, further comprising: The request is received from the application function AF of the CN or via the network open function NEF of the CN; as well as The PCC rule with PDU set QoS parameters is generated based on the application auxiliary information, wherein the PCC rule includes service detection information, and the service detection information includes media stream identification information.

15. A method for a Session Management Function (SMF) in the core network (CN) of a wireless communication system, the method comprising: At the Session Management Function (SMF) of the CN, policy and charging control (PCC) rules are received from the Policy Control Function (PCF) of the CN. The PCC rules are application requests for Quality of Service (QoS) of multiple media streams for application service data streams between the Application Server (AS) and the User Equipment (UE), as well as application auxiliary information associated with the media streams. Configure a QoS profile in the radio access network (RAN) based on the requested Quality of Service (QoS) for the media stream; as well as The configuration is communicated to the User Plane Function (UPF) of the CN, the configuration including at least one rule for QoS handling of a first media stream among the plurality of media streams based on a Protocol Data Unit (PDU) set, the configuration including: Service detection information based on the application auxiliary information, the service detection information including media stream identification information for at least the first media stream among the plurality of media streams, and One or more QoS parameters for the set of PDUs associated with the first media stream among the plurality of media streams.

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

17. A method for applying function AF, the method comprising: The application function (AF) transmits a request to the control plane of the core network (CN), the request indicating a Quality of Service (QoS) requirement for at least a first media stream among a plurality of media streams of the application service data stream between the AS and the user equipment (UE), the request including application auxiliary information, the application auxiliary information including media stream identification information associated with the first media stream; as well as The application server AS communicates an application packet for the first media stream to the user plane function UPF of the CN. The application packet includes metadata for matching service detection information based on the media stream identification information.

18. The method of claim 17, wherein the request includes information about a plurality of media streams, including: Regarding the first QoS requirement of the first media stream, The first protocol description for the first media stream, The second QoS requirements for the second media stream, and A second protocol description for the second media stream.

19. The method of claim 17 or 18, wherein the application assistance information includes one or more of the following: QoS requirements for the application service data streams associated with the QUIC connection; The service description includes at least one Internet Protocol (IP) 5-tuple; Additional QoS requirements for media services within the QUIC connection, wherein the additional QoS requirements are associated with a corresponding QoS relevance ID; and Additional service descriptions for the first media stream, the additional service descriptions include: QoS relevance ID of the first media stream Included in the transport connection-related ID in the metadata, or The transport connection associated stream ID is included in the metadata.

20. The method of any one of claims 17 to 19, wherein the application assistance information further comprises: For the first media stream: QoS parameters based on the PDU set, including at least one of the following: PDU set error rate (PSER), PDU set latency budget (PSDB), or PDU set integrated processing information (PSIHI).

21. A method for using an application server (AS), the method comprising: The application function (AF) communicates a request to the control plane of the core network (CN), the request indicating a Quality of Service (QoS) requirement for at least a first media stream among a plurality of media streams of the application service data stream between the AS and the user equipment (UE), the request including application auxiliary information, the application auxiliary information including media stream identification information associated with the first media stream; as well as The application group for the first media stream is communicated to the User Plane Function (UPF) of the CN. The application group includes metadata for matching service detection information based on the media stream identification information.

22. The method of claim 21, wherein the application packet includes an Internet Protocol (IP) header, a User Datagram Protocol (UDP) header, a UDP payload, and a UDP-options field, the UDP payload carrying a Fast UDP Internet Connection (QUIC) packet encapsulating at least one Real-Time Protocol (RTP) packet, and the UDP-options field carrying the metadata, and The metadata mentioned therein includes at least one of the following: The correlation identifier ID value associated with the QUIC connection ID of the RTP session; Media stream identification information associated with the first media stream; Based on the stream ID value of the QUIC header of the QUIC group; Based on the mapping value of the stream ID in the QUIC header of the QUIC packet; A timestamp indicating the time instance information of the most recent RTP packet encapsulated in the QUIC packet; Priority information associated with the first media stream; Information based on the RTP header extension of the RTP packet; or The number of RTP packets in the QUIC packet.

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

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

25. The method of any one of claims 21 to 24, wherein the metadata includes information based on the Real-Time Protocol (RTP) header extension fields of the application packet, wherein the RTP header extension fields include one or more of the following fields: The end PDU in the PDU set, The end of the data burst, PDU set importance PDU set sequence number, PDU sequence number within the PDU set PDU set size, or Other RTP header extension fields.

26. An apparatus comprising: Communication unit; as well as A processing system configured to control the communication unit to implement the method as described in any one of claims 1 to 25.

Images