Transmitting PDU sets in wireless communication system

Abstract

A method for packet data unit (PDU) handling is implemented in a policy control function (PCF) of a core network (CN) and includes: receiving an indication related to handling a PDU set, the PDU set including a plurality of PDUs associated with an information unit generated at an application level; and providing, to a session management function (SMF) of the CN, a rule for processing the PDU according to the indication.

Description

Technical Field

[0001] The present disclosure relates generally to wireless communications, and more particularly to supporting advanced media services in 5G System (5GS) support for advanced media services. Background Art

[0002] This background description is provided for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors, to the extent that it is described in this background section, and aspects of the specification that might not have been identified as prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0003] The 3rd Generation Partnership Project (3GPP) recently proposed that the 5G system (5GS) begin to provide support for advanced media services, such as high data rate low latency (HDRLL) services, augmented reality (AR) / virtual reality (VR) / extended reality (XR) services, and tactile / multimodal communication services. XR and media services may also be referred to as "XRM services". In general, 3GPP proposes to study enhancements to network openness to support interactions between 5GS and XRM applications, as well as enhancements to the quality of service (QoS) and policies for the transmission of XR services and media services.

[0004] In the current 5GS, QoS flow represents the finest granularity of QoS differentiation in a PDU session. 5G QoS characteristics correspond to 5G QoS identifiers (5QIs). 5GS treats each packet in a QoS flow according to the same QoS requirements. However, it has been proposed that a session management function (SMF) controls QoS flows and pre-configures or establishes QoS flows via a protocol data unit (PDU) session establishment procedure or a PDU session modification procedure.

[0005] The characteristics of a QoS flow include a QoS profile, which the SMF may provide to the AN (Access Network) via the Access and Mobility Management Function (AMF) over the N2 reference point, or the AN may pre-configure the QoS profile. The characteristics of a QoS flow further include one or more QoS rules and QoS flow-level QoS parameters optionally associated with these QoS rules, which the SMF may provide to the User Equipment (UE) via the AMF and over the N1 reference point, or the UE may derive them by applying reactive QoS control. Further, the characteristics of a QoS flow include one or more uplink (UL) and downlink (DL) packet detection rules (PDRs), which the SMF may provide to the User Plane Function (UPF).

[0006] However, XRM services may rely on PDU sets, which are groups of packets carrying payloads such as, for example, frames, slices, or tiles. More specifically, a PDU set consists of one or more PDUs carrying the payload of an information unit generated at the application level (e.g., a frame or video slice for an XRM service), which have the same importance requirements at the application layer. The application layer typically requires that all PDUs in a PDU set are required to process the corresponding information unit. However, in some cases, when some PDUs in a PDU set are lost, the application layer may recover part of the information unit.

[0007] The media layer decodes and handles the packets in such a PDU set as a whole because the packets within a PDU set have inherent dependencies on each other at the media layer. For example, the media layer can decode a frame / video slice only if all packets or a certain minimum number of packets in the packet carrying the frame / video slice are successfully delivered. As another example, a client application can decode a frame within a GOP (Group of Pictures) only after successfully receiving all frames that a particular frame depends on.

[0008] Because XRM services typically require high data rates and low latency, the 5GS QoS framework needs to be enhanced to support different QoS treatments for PDU sets. Without considering such dependencies between packets within a PDU set, 5GS may only perform scheduling with low efficiency. For example, 5GS may discard some packets, but try to deliver other packets that the client application of the same PDU set cannot use, and thus unnecessarily spend radio resources. Similarly, audio samples, tactile applications, and remote control operations can benefit from 5GS, taking into account the PDU set characteristics. As another example, a PDU set may carry different content (e.g., I / B / P frames, slices / tiles within I / B / P frames, etc.), and thus allow 5GS to process packets (e.g., PDUs) belonging to less important PDU sets differently to utilize resources more efficiently.

[0009] Most XRM services are streamed using streaming protocols based on the Real-time Transport Protocol (RTP) or Secure RTP (SRTP) or HTTP. For end-to-end encryption, DTLS or TLS is further applied to the RTP / SRTP or HTTP-based protocols respectively.

[0010] Existing solutions typically rely on traffic (application / packet) detection at the UPF for PDU set identification and classification, and are based on matching RTP / SRTP headers / payloads. These approaches assume that some header information necessary to identify the PDU is not encrypted. Therefore, these solutions are insufficient for implementations where header information is encrypted for privacy protection. Further, because conventional processing techniques at both the Radio Access Network (RAN) and the Core Network (CN) are packet-based, i.e., individual packets need to be processed, enhancements are required to allow the 5GS to receive and process PDU sets, and provide the RAN with the information required for the RAN to efficiently schedule radio resources. For example, it is currently unclear how the 5GS should implement security mechanisms for XRM traffic and PDU set handling. Summary of the invention

[0011] An example embodiment of the technology of the present disclosure is a method for packet data unit (PDU) handling. The method is implemented in a policy control function (PCF) of a core network (CN) and includes: receiving an indication related to handling a PDU set, the PDU set including multiple PDUs associated with an information unit generated at the application level; and providing a session management function (SMF) of the CN with rules for processing the PDU according to the indication.

[0012] Another example embodiment of these techniques is a method for packet data unit (PDU) handling. The method is implemented in a session management function (SMF) of a core network (CN) and includes: receiving a first rule related to handling of a PDU set from a policy control function (PCF); and providing a second rule for classifying a data packet as belonging to the PDU set to a user plane function (UPF) of the CN, the second rule being based on the first rule.

[0013] Yet another example embodiment of the techniques is a node in a core network (CN), the node comprising one or more processors and configured to implement one of the above methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 is a block diagram of an example wireless communication system in which a user equipment (UE), a radio access network (RAN) and / or a core network (CN), a base station may implement the disclosed techniques for processing a PDU set;

[0015] Figure 2 is a block diagram of an example protocol stack, according to which, Figure 1 The UE can be used with Figure 1 Communicate with the RAN;

[0016] Figure 3It is a service-based 5GS architecture representation, including the overall non-roaming reference architecture of the 5GS policy and charging control framework;

[0017] Figure 4 It is a 5GS architecture representation based on reference points, including the overall non-roaming reference architecture of the 5GS policy and charging control framework;

[0018] Figure 5 is a block diagram of an example PDU set that may be transmitted by a CN node, RAN node, or UE of the present disclosure;

[0019] Figure 6 is a message passing diagram of an example process for packet flow detection (PFD) management in which an application function (AF) provides PDU set handling information to a network exposure function (NEF) in an AF request message;

[0020] Figure 7 is a message passing diagram of an example procedure for PFD management in a user plane function (UPF), which may be used by a session management function (SMF) to provide PDU set handling information to the UPF;

[0021] Figure 8 is a message passing diagram of an example process for PDU set handling in a CN;

[0022] Fig. 9 is a flow chart of an example method for PDU handling, which may be used in Figure 1 Implementation in the policy control function (PCF) of the CN; and

[0023] Fig.10 is a flow chart of an example method for PDU handling, which may be used in Figure 1 The CN is implemented in SMF. DETAILED DESCRIPTION

[0024] Overview

[0025] Nodes in CN, RAN and / or UE can utilize the techniques disclosed herein to efficiently support advanced media services in 5GS.

[0026] More specifically, these technologies address a security vulnerability of the Secure Real-time Transport Protocol (SRTP) for XRM services in 5GS. The security vulnerability is due to the fact that SRTP encrypts the payload of the RTP packets instead of the RTP extension headers. These extension headers may contain sensitive information, such as the per-packet sound level of the media data in the RTP payload (and therefore an eavesdropper may determine that a particular conversation between two individuals is ongoing, which may lead to privacy breaches). The disclosed system addresses the need for a security mechanism to specify how application servers in trusted or untrusted domains and 5G networks in the operator's trusted domain encrypt RTP header extensions when no DTLS / TLS is available or allowed, so as to achieve complete encryption of XRM traffic using the RTP / SRTP streaming protocol.

[0027] Further, when encryption of RTP / SRTP or RTP extension headers is required, XRM applications may use a fully encapsulated protocol (such as DTLS) and its per-packet overhead. Some XRMs may also use Hypertext Transfer Protocol (HTTP) or HTTPS with Transport Layer Security (TLS) for streaming data. For XRM traffic using HTTPS or SRTP with DTLS or SRTP with encrypted RTP header extensions, it is not feasible to identify the PDU set of the XRM traffic based on matching RTP / SRTP header / payload or SRTP extension headers because the relevant header / payload information used to identify the PDU is encrypted. The present discussion addresses the lack of a viable solution for PDU set identification and classification by 5GS for such fully encrypted XRM traffic using DTLS / TLS.

[0028] Still further, the techniques of any of the solutions of the present disclosure support bidirectional XRM traffic, ie both uplink (UL) and downlink (DL), for PDU set handling in XRM services.

[0029] More specifically, the techniques of the present disclosure support PDU set handling for encrypted XRM traffic in 5GS by solving the problem of how a 5G network can perform PDU set identification and classification for XRM services that may or may not be encrypted (particularly, what PDU set information should be provided to 5GS (including UE, RAN and / or UPF), and how should such information be transmitted? In addition, how can 5GS determine that a certain PDU belongs to a specific PDU set based on the received PDU set information?) Further, these techniques solve the problem of how CN and RAN in 5G configure QoS based on PDU sets of XRM services (particularly, whether and how to enhance QoS models and policy control to handle PDU sets with integrated grouping, including considering importance / dependency information associated with a given PDU set; and whether QoS of PDU sets should be configured for both uplink traffic and downlink traffic?)

[0030] According to one example solution, the SMF provides a Packet Detection Rule (PDR) to the UPF via the N4 interface, the PDR including rules for PDU Set Identification and Classification (PSICR). Another example solution is a PDR enhancement with PDU Set handling, including IP Packet Filter Set enhancement for security parameters. Another example solution is a PDR with an application identifier associated with a PFD (Packet Flow Description) with PDU Set information, including PFD enhancement for security parameters. Another example solution includes traffic treatment rules for PDU Sets (e.g., PDU Set QoS Implementation Rules, PS-QER). Yet another example solution includes detailed procedures for PDU Set QoS configuration via AF request, such as creating / updating an AF session.

[0031] Example systems and protocol stacks

[0032] First reference Figure 1 , the techniques of the present disclosure may be performed by an example wireless communication system 100. The example wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, and a core network (CN) 110. The base stations 104 and 106 may operate in a RAN 105 connected to the core network (CN) 110. For example, the CN 110 may be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160. In another example, the CN 110 may also be implemented as a sixth generation (6G) core.

[0033] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, cell 124 is an NR cell. If base station 124 is an ng-eNB, cell 124 is an Evolved Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, if base station 106 is a gNB, cell 126 is an NR cell, and if base station 126 is an ng-eNB, cell 126 is an E-UTRA cell. Cells 124 and 126 may be located in the same radio access network notification area (RNA) or in different RNAs. Cells 124 and 126 may partially overlap, so that UE 102 may select, reselect, or switch from one of cells 124 and 126 to another. In general, RAN 105 may include any number of base stations, and each of the base stations may cover one, two, three, or any other suitable number of cells. UE 102 may support at least 5G NR (or simply “NR”) or E-UTRA air interface to communicate with base stations 104 and 106. Each of base stations 104, 106 may be connected to CN 110 via an interface (e.g., S1 or NG interface). Base stations 104 and 106 may also be interconnected via an interface for interconnecting NG RAN nodes (e.g., X2 or Xn interface).

[0034] Among other components, the EPC 111 may also include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. In general, the SGW 112 is configured to deliver user plane packets associated with audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks (e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network). The 5GC 160 includes a user plane function (UPF) 162 and an access and mobility management (AMF) 164, and / or a session management function (SMF) 166. Generally speaking, UPF 162 is configured to deliver user plane packets associated with audio calls, video calls, Internet traffic, etc., AMF 164 is configured to manage authentication, registration, paging, and other related functions, and SMF 166 is configured to manage PDU sessions.

[0035] Although Figure 1Not shown, CN 110 may include processing hardware that may include one or more general purpose processors (e.g., CPUs) and non-transitory computer readable memory storing instructions, and the one or more general purpose processors execute the instructions. Additionally or alternatively, the processing hardware may include a dedicated processing unit. The processing hardware may be configured to implement the techniques of the present disclosure to enable 5GS support for advanced media services.

[0036] As used in the present disclosure, the term "data" or "data packet" may refer to signaling, control plane information at a protocol layer for controlling radio resources (e.g., RRC), controlling mobility management (MM), controlling session management (SM), or to non-signaling, non-control plane information at a protocol layer above a layer of a protocol for controlling radio resources (e.g., RRC), above a layer of a protocol for controlling mobility management (MM), above a layer of a protocol for controlling session management (SM), or above a layer of a protocol for controlling quality of service (QoS) flows (e.g., Service Data Adaptation Protocol (SDAP)). The data to which the UE, CN, and / or RAN apply the techniques of the present disclosure may include, for example, Internet of Things (IoT) data, Ethernet traffic data, Internet traffic data, or a Short Message Service (SMS) message.

[0037] The base station 104 is equipped with processing hardware 130, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable memory storing instructions, and the one or more general-purpose processors execute the instructions. In addition or alternatively, the processing hardware 130 may include a dedicated processing unit. The processing hardware 130 in the example implementation includes a PDU set manager 132.

[0038] The UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors (such as CPUs) and non-transitory computer-readable memory storing machine-readable instructions that can be executed on one or more general-purpose processors, and / or a dedicated processing unit. The processing hardware 130 in the example implementation includes a PDU set manager 152.

[0039] Figure 2An example protocol stack 200 is shown in a simplified manner, according to which a UE 102 can communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106). In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to an EUTRA MAC sublayer 204A, which in turn provides logical channels to an EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, an NR PHY 202B provides transport channels to an NR MAC sublayer 204B, which in turn provides logical channels to an NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 may then provide a service data adaptation protocol (SDAP) 212 or a radio resource control (RRC) sublayer ( Figure 2 In some implementations, UE 102 supports the following: Figure 2 Both the EUTRA and NR stacks shown are provided to support switching between EUTRA and NR base stations and / or to support DC via EUTRA and NR interfaces. Figure 2 As shown, the UE 102 may support the layering of the NR PDCP 210 on the EUTRA RLC 206A, and the layering of the SDAP sublayer 212 on the NR PDCP sublayer 210.

[0040] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets, which may be referred to as service data units (SDUs) (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on the PDCP layer 208 or 210), and output packets, which may be referred to as protocol data units (PDUs) (e.g., to the RLC layer 206A or 206B). For simplicity, this disclosure refers to both SDUs and PDUs as "packets", except where the distinction between SDUs and PDUs is relevant.

[0041] For example, on the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide a signaling radio bearer (SRB) or an RRC sublayer ( Figure 2(not shown) to exchange RRC messages or non-access stratum (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide data radio bearers (DRBs) to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0042] Example 5GS Reference Architecture

[0043] Figure 3 300 is a service-based 5GS architecture representation. In the representation 300, the overall non-roaming reference architecture of the policy and charging control (PCC) framework of the 5GS includes components shown using solid lines, and other components are shown using dashed lines. According to the representation, a network function enables other authorized network functions to access the services of the network function. Components outside the PCC framework include a network slice selection function (NSSF) 302, a network repository function (NRF) 306, a unified data management (UDM) 308, an edge application server discovery function (EASDF) 310, a network slice specific authentication and authorization function (NSAAF) 312, an authentication server function (AUSF) 314, a service communication agent (SCP) 316, and a network slice admission control function (NSACF) 316. The non-PCC architecture further includes a UE 102, a RAN 105, and a data network (DN) 330.

[0044] The PCC framework in architecture 300 includes a unified data repository (UDR) 352, a network exposure function (NEF) 354, a network data analysis function (NWDAF) 356, an application function (AF) 357, a policy control function (PCF) 360, a charging function (CHF) 362, an access and mobility management function (AMF) 364, a session management function (SMF) 366 and a user plane function (UPF) 370.

[0045] In an example implementation, the PCF 360 includes a PDU set manager 390 , the SMF 366 includes a PDU set manager 392 , and the UPF 170 includes a PDU set manager 394 .

[0046] Figure 4 The 5GS architecture is based on reference point representation 400. Figure 4 In the figure, the non-roaming reference architecture of the PCC framework of 5GS is shown as blocks and connections using solid lines, and components and connections outside the PCC framework are shown using dashed lines.

[0047] As discussed below, various techniques of the present disclosure relate to message passing between network functions of 5GS (e.g., network functions of CN 110) and between the CN (e.g., CN 110), RAN (e.g., RAN 105) and UE (e.g., 102) of 5GS.

[0048] Example PDU Set and QoS Flow

[0049] For the sake of clarity, Figure 5 Shows Figure 1 An example known PDU set 500 that a CN node, RAN node, or UE may send or receive. According to the method, a device (such as a RAN node, CN node, or UE) marks the first PDU in each PDU set, but does not mark the last PDU in the PDU set.

[0050] Regarding QoS flows, a QoS flow in 5GS is associated with QoS requirements specified by QoS parameters and QoS characteristics. A QoS flow represents the finest granularity of QoS differentiation within a PDU session. A QoS Flow ID (QFI) identifies a QoS flow in a 5G system. User plane flows with the same QFI within a PDU session receive the same traffic forwarding treatment (e.g. scheduling, admission thresholds). The QFI is carried in the encapsulation header on N3 (and N9), i.e. without any changes to the e2e packet header.

[0051] The following discussion can be Figure 1 In general, these techniques can be combined in any suitable manner.

[0052] Solution 1. PDR with PSIC Rules (PSICR) for PDU Set Identification and Classification

[0053] In general, SMF 366 configures UPF 370 with instructions related to detecting user data traffic that matches (or belongs to) a PDR. SMF 366 controls traffic detection at UPF 370 by providing detection information for each PDR. PDRs contain information for classifying traffic, such as PDUs arriving at UPF 370.

[0054] In the case of a PDU set handling indication and a PCC rule enhanced with information for handling a PDU set, the SMF generates a PDU set identification and classification rule (PSICR), which the UPF can use to identify packets and then further classify the identified packets into a specific PDU set. Based on the PDR and PSICR, the UPF can further implement packet treatment rules for the PDU set. The same PDR can be used to handle packets that do or do not require PDU set handling for traffic treatment rules (e.g., QER (QoS implementation rules), FAR (forwarding action rules), etc.). For example, a QER can be applied to a packet based on the associated PDR (TS23.501 Section 5.8.2.1.1.4). For example, a PS-QER (PDU set QoS implementation rule) can be applied to a packet based on the associated PDR and PSICR. (PS-QER is described in detail in Solution 4.2). Reference is made below. Figure 8 Event 850 described includes the SMF configuring the UPF with the PDR and PSICR.

[0055] The PSICR may include the following information: (i) N4 Session ID: This provides the associated N4 session; (ii) PDR Rule ID: This provides the associated PDR; (iii) Identification and Classification Type: Indicates the use of RTP / SRTP header or RTP extension header, metadata piggybacked in XRM packets, IP header of TOS / DTRS, or specific IP header configuration of XRM traffic; and (iv) Identification and Classification Rule: Contains information related to packet identification and classification of traffic identified by the PDR for a specific N4 session. In particular, (iv-a): If based on the RTP / SRTP header or RTP extension header, the rule indicates a specific bit used for identification of the PDU of the PDU set, for example, the M bit indicates the start of the PDU set based on the RTP header; the "S" bit and the "E" bit in the frame marker RTP header extension indicate the start and end of the video frame, respectively. UPF can identify the start and end of a PDU set / frame based on the "S" and "E" bits; (iv-b): If an IP header or other specific IP header settings of TOS / DSCP (Type of Service / Differentiated Services Code Point (DSCP)) are indicated, the rules provide TOS / DSCP settings or specific IP header settings for identifying and classifying packets of PDU sets; and (iv-c): If metadata is piggybacked in an XRM packet, the rules indicate how to identify XRM packets based on metadata, which can be based on an RTP / SRTP header or N6 tunnel header information or IP header information.

[0056] Solution 2. PDR enhancement for PDU set handling

[0057] As a further improvement to Solution 1, the detection process at UPF 370 identifies that the packet belongs to a session or service data flow. Based on TS 23.501, Table 5.8.2.11.3-1: Attributes within the Packet Detection Rule (PDR). For IPv4 or IPv6 or IPv4v6 PDU session type, the detection information is a combination of the following: IP packet filter set (enhancement in Solution 2); CN tunnel information (enhancement in Solution 2.1); Application identifier: The application identifier is an index of the application detection rule set configured in the UPF and associated with the packet flow description (PFD) (enhancement in Solution 3); PDU Set QFI (PSQFI) (enhancement in Technology 4).

[0058] Solution 2.1: PDR with IP Packet Filter Set Enhancement for Security Parameters

[0059] As a further improvement to Solution 2, the IP packet filter set may include an IP PDU session type, and the packet filter set may support packet filters based on at least any combination of the following: source / destination IP address or IPv6 prefix; source / destination port number; protocol ID / next header type of the protocol above IP; Type of Service (TOS) (IPv4) / traffic class (IPv6) and mask; flow label (IPv6); security parameter index or security parameter setting; packet filter direction.

[0060] The security parameter setting is further extended from the security parameter index to implement the following: For example, the security parameters contain information to generate symmetric keys or provide asymmetric encryption of public keys to encrypt the streaming packets of a specific XRM service (the application server encrypts the packets with a private key), which uses the RTP / SRTP streaming protocol (without DLTS) to provide complete encryption protection for the packets of XRM traffic (including packet headers and payload). If the XRM traffic is encrypted using HTTPS above the IP layer, that is, HTTP and TLS as the streaming protocol. An additional security protection layer with symmetric keys or public keys between the UPF and the application server is optional. For example, if SRTP is used as the streaming protocol, the security parameters contain the same encryption key used for SRTP packet payload encryption to retrieve the metadata piggybacked in the encrypted SRTP payload.

[0061] Solution 2.2

[0062] As a further improvement to Solution 2.1, based on the PDR with security parameters and the PSICR rules with XRM traffic identification / classification type, the UPF handles the packets of XRM traffic by performing the following steps: trigger PDU set handling for the XRM packets received from N6 / N3; decrypt the XRM packets based on the security parameters indicated in the PDR; apply the corresponding mechanism indicated in the identification / classification type for PDU set identification and classification; mark the forwarded packets with the PDU set handling rules, such as the PDU set flow ID (PSQFI).

[0063] Solution 2.3

[0064] As a further improvement to solution 2 or 2.1, the UPF may further classify the PDUs under the PDU set based on the additional N6 tunnel information provided in the N4 message (if available), where the N6 tunnel information associates the DNN, S-NSSAI and DNAI, which may further provide another level of classification based on the target application server location. The DNAI may be distinguished by the application server based on the QoS requirements for a particular PDU set. That is, different PDU sets are associated with different DNAIs within the same DNN and S-NSSAI.

[0065] Solution 3. PDR with application identifier associated with PFD with PDU set information

[0066] As a further improvement to Solution 2, the application identifier may be associated with the information stored in the UDR 352.

[0067] Solution 3.1

[0068] Solution 3 is followed, where the application identifier is associated with a PFD (Packet Flow Description) stored in the UDR 352, which is based on a service level agreement between the operator and the application server provider. The PFD is part of the application detection filter in the SMF / UPF and is therefore used as part of the logic for detecting traffic generated by the application. The Application Service Provider (ASP) can remove or modify some or all of the PFDs that have been previously provided for one or more application identifiers. The Application Service Provider (ASP) can provide the SMF via the PFD Management Service (PFDF) in the NEF with a separate PFD or a complete set of PFDs for each application identifier (App ID) maintained by the ASP, and the information is stored at the UDR as part of the application related information. There can be different PFD types associated with the application identifier.

[0069] The PFD includes the following information: (i) PFD id; and (ii) one or more of the following: (a) a 3-tuple including the protocol, server-side IP address, and port number; (b) The important part of the URL to be matched, such as the host name; or (c) domain name matching criteria and information about the applicable protocol; (ii) for XRM type traffic, the following PDU set handling information can be further provided based on the agreement between the AF and the mobile operator: (a) Identification and classification type: indicating the use of RTP / SRTP header or RTP extension header, metadata carried in the XRM packet, IP header of TOS / DTRS, or specific IP header configuration of XRM traffic; (b) Identification and classification rules: containing information related to packet identification and classification of traffic identified by the PDR for a specific N4 session: (1) If based on RTP / SRTP header or RTP extension header, the rule indicates the specific bit used to identify the PDU of the PDU set, for example, the M bit indicates the start of the PDU set based on the RTP header; the "S" bit and "E" bit in the frame marker RTP header extension indicate the start and end of the video frame, respectively. UPF can identify the start and end of a PDU set / frame based on the "S" and "E" bits; (2) If an IP header of TOS / DSCP (Type of Service / Differentiated Services Code Point (DSCP)) or other specific IP header settings is indicated, the rule provides TOS / DSCP settings or specific IP header settings for identifying and classifying packets of PDU sets; (3) If metadata is piggybacked in an XRM packet, the rule indicates how to identify an XRM packet based on metadata, which can be based on RTP / SRTP headers or N6 tunnel header information or IP header information; (c) Security parameter settings are used to implement the following situations: (1) For example, the security parameters contain information for generating symmetric keys or providing public key asymmetric encryption for a specific XRM service (the application server encrypts the packet with a private key), which uses the RTP / SRTP streaming protocol (without DLTS) to provide complete encryption protection for packets of XRM traffic (including packet headers and payloads). If the XRM traffic is encrypted using HTTPS above the IP layer, i.e., HTTP and TLS as streaming protocols. An additional layer of security protection with symmetric or public keys between the UPF and the application server is optional; (2) For example, if SRTP is used as the streaming protocol, the security parameters contain the same encryption key used for encryption of the SRTP packet payload to retrieve the metadata piggybacked in the encrypted SRTP payload.

[0070] Figure 6A PFD management process is shown, which can be enhanced using the techniques of the present disclosure, as described below. Information on PDU set handling for XRM traffic is provided by the PFD management process at events 602, 622, and 624. The AF 358 calls 602 the Nnef_PFDManagement_Create / Update / Delete service. The allowed delay is an optional parameter. If the allowed delay is included, it indicates that the PFD list in the request should be configured to the SMF within the time interval indicated by the allowed delay, and the SMF has subscribed to the PFD management service using the Nnef_PFDManagement_Subscribe service operation. The PDU set handling information is provided to the NEF in the AF request message.

[0071] Next, the NEF 354 checks 610 whether the AF is authorized to perform the request, and the NEF (PFDF) checks whether the AF is authorized to configure the PFD data based on the operator policy. The NEF (PFDF) 354 calls 622 Nudr_DM_Create / Update / Delete (application identifier, one or more PFD sets, allowed delays, PDU set handling information) to the UDR. The UDR 352 updates 630 the list of PFDs with PDU set handling information for the application identifier. Next, the UDR 352 sends 624 Nudr_DM_Create / Update / Delete response to the NEF (PFDF). The NEF 354 sends 604 Nnef_PFDManagement_Create / Update / Delete response to the AF 358.

[0072] Reference now Figure 7In the scenario 700, the SMF 366 uses the N4 procedure to configure or remove all PFDs with PDU set handling information belonging to the application identifier in the UPF 370 (see event 710). The same PFD management request message can be used to manage PFD sets belonging to different applicant identifiers. The N4 PFD management procedure is a node-level procedure, i.e., independent of any PDU session. The SMF 366 is triggered to configure or remove 702 the PFD set belonging to the application identifier in the following cases: when the cache timer expires and there is no active PCC rule referencing the corresponding application identifier, the SMF notifies the UPF to remove the PFD identified by the application identifier; when providing PCC rules for an application identifier corresponding to a PFD that has not yet been provided to the UPF, the SMF shall provide the PFD to the UPF (if there is no cached PFD, the SMF retrieves the PFD from the NEF (PFDF) as described in TS 23.503); when any update to the PFD is received from the NEF (PFDF) and there are still active PCC rules for the application identifier in the UPF. Next, the SMF 366 sends 710 a PFD management request including PDU set handling information to the UPF to configure / remove a PFD corresponding to the application identifier. The UPF 370 updates 712 the PFD according to the request and confirms by responding with a PFD management response message.

[0073] Traffic treatment rules for PDU sets

[0074] Further with respect to Solution 1 discussed above, other parameters may be provided as a set of traffic treatment rules within a PDR with a PSICR, which PSICR describes how the UPF should treat packets that match the detection information and the PDU set identification and classification information, wherein for the traffic identified by the PDR with a PSICR, at least one of the following traffic treatment rules in TS 23.501 may be included: Section 5.8.2.11.4: QoS implementation rules; Section 5.8.2.11.5: Usage reporting rules; Section 5.8.2.11.6: Forwarding action rules; Section 5.8.2.11.7: Usage reports generated by the UPF; Section 5.8.2.11.8: Multiple access rules.

[0075] Solution 4.1: QoS model for PDU sets

[0076] As a further enhancement to solutions 4 and 1, based on the existing QoS model in clause 5.7 of TS23.501, packets can be further indicated by a PDU set QoS flow ID (PSQFI), which is associated with a set of PDU set QoS requirements and QoS characteristics, such as PDU set delay budget, PDU set packet error rate, averaging window, importance level of the PDU set (e.g., an indication of the level of PDU discard rate), dependency on previous PDU sets, dependency on previous PDUs within a PDU set, PDU set burst size (the number of PDUs in a PDU set), PDU set burst arrival time at the UE (the number of PDUs in a PDU set) or PDU set burst arrival time at the UPF (downlink), periodicity of the PDU set, and existence time of the PDU set.

[0077] A QoS flow with a PSQFI is defined as a PDU set QoS flow, which can be used by the 5G system to provide QoS differentiation for the PDU set of XRM packets in a PDU session, with the following enhancements: the PDU set QoS flow ID (PSQFI) is used to identify the QoS flow with the PDU set in the 5G system; user plane packets with the same PSQFI within a PDU session receive the same traffic forwarding treatment (e.g. scheduling, admission threshold); QFI, PSQFI or both are carried in the encapsulation header (i.e. GTP-U header) on N3 (and N9), i.e. there is no change to the e2e packet header; the PSQFI should be unique within a PDU session; the PSQFI can be dynamically assigned, or can be equal to the PSQI (PDU set QoS index) defined by 3GPP.

[0078] Any PDU Set QoS flow may be characterized by: (i) one or more UL and DL PDRs with PSICR provided by the SMF to the UPF as described in Solution 1; (ii) a QoS profile provided by the SMF via the AMF over the N2 reference point to the (R)AN (including both 3GPP or non-3GPP access networks) or pre-configured in the (R)AN, the QoS profile having PDU Set information including PSQFI and PDU Set QoS requirements and QoS characteristics. The SMF may additionally provide one or more QoS profiles (without PDU Set information) to the (R)AN as a fallback solution. In such fallback cases, the (R)AN implements the QoS profile in case the QoS profile of the PDU Set is not applicable due to implementation reasons; (iii) one or more QoS rules for the PDU Set and optionally PDU Set QoS flow level related PDU Set QoS parameters associated with these QoS rules for the PDU Set, which may be provided by the SMF via the AMF over the N1 reference point to the UE. The QoS rules may be applied to handle the corresponding traffic in the UL direction, the DL direction or both. One or more QoS rules and QoS flow level related QoS parameters associated with these QoS rules may additionally be provided by the SMF via the AMF to the UE over the N1 reference point and may be applied to process the corresponding traffic in the UL direction, DL direction or both. As a fallback solution, the UE implements the QoS rules in the case where the QoS rules of the PDU set are not applicable due to implementation reasons.

[0079] Solution 4.2: PS-QER (PDU Set QoS Implementation Rules)

[0080] Further to the discussion of Solution 4 and Solution 1, the PS-QER includes the following information: PSQFI; Gate status UL / DL (instructing the UPF to let the PDU set flow through or block the flow); Maximum bit rate of the PDU set (the uplink / downlink maximum bit rate to be implemented for the packets within the PDU set); Guaranteed bit rate of the PDU set (the uplink / downlink guaranteed bit rate authorized for the packets within the PDU set); Averaging window (indicates the duration over which the maximum bit rate and guaranteed bit rate of the PDU set should be calculated); Downlink flow level tag (flow level grouping within the PDU set tag in the downlink); Packet rate of the PDU set (the number of packets to be implemented per time interval in the PDU set); PDU set rate (the number of PDU sets to be implemented per time interval).

[0081] AFsession_WithQoS_Create / Update request process

[0082] The solution proposes to implement support for XRM services, allowing the ASP to request the 5GS to configure the required PDU set QoS requirements for some traffic flows or applications of the UE. For example, the process in Section 4.15.6.6 of TS 23.502 can be enhanced with the following aspects. The AF request is an AFsessionWithQoS_Create message that includes PDU QoS requirements and PDU set handling indications. The PDU set QoS requirements may include one or more of the following: PDU set delay budget, PDU set packet error rate, average window, PDU set size (the number of PDUs in the PDU set), the importance level of the PDU set (for example, an indication of the level of PDU discard rate), dependencies on previous PDU sets, dependencies on previous PDUs within a PDU set, etc. The PDU set handling indication includes at least one of the following information: indicating further specific actions for PDU set handling of XRM traffic, such as activation, modification, deactivation; PDU set identification and classification type (indicating the use of RTP / SRTP header or RTP extension header, metadata carried in XRM packet, IP header of TOS / DTRS, or specific IP header configuration of XRM traffic); PDU set identification and classification rules (including information related to packet identification and classification of traffic, which can be used as input by SMF for generating PDR for specific N4 session); security parameters (including information for generating symmetric keys or providing asymmetric encryption of public keys for encrypting streaming packets of specific XRM services). NEF or PCF or SMF can retrieve PFD information from UDR based on application ID or flow description received from AF. Based on the PDU set handling indication, PCF generates PCC rules for PDU set handling and PDU set QoS policy to SMF. The SMF further generates a rule set in the N4 message to configure the UPF, where the rule includes a PDR and a PSICR with a traffic treatment rule set for handling the PDUs in each PDU set. Based on the N4 message, the UPF applies the PDR rule and the PSICR rule to identify the PDU and classify the PDU into a specific PDU set. The UPF may further configure the N3 GTP header information in the GTP-U packet, which provides the PDU set classification information (in-band) to the RAN.

[0083] Reference now Figure 8, scenario 800 involves establishing an AF session with the required QoS. According to the techniques of the present disclosure, the process can be enhanced as follows. The AF 358 sends 802 a request to the NEF to reserve resources for the AF session using the Nnef_AFsessionWithQoS_Create / Update request message (UE address, AF identifier, flow description or external application identifier, PDU set handling indication, PDU set QoS requirements, DNN, S-NSSAI). The NEF 354 assigns 810 a transaction reference ID to the Nnef_AFsessionWithQoS_Create request. The NEF 354 authorizes the AF request and may apply policies to control the total amount of QoS authorized for the AF. If authorization is not granted, all steps (except event 804) are skipped and the NEF replies to the AF with a result value indicating that the authorization failed. The NEF may retrieve the PFD information associated with the application identifier indicated in the AF request from the UDR.

[0084] If the AF 258 is deemed to be trusted by the operator, the AF 358 interacts directly with the PCF using 820 Npcf_PolicyAuthorization_Create request message to request to reserve resources for the AF session. If the AF request is sent to the NEF 354, the NEF 354 determines to contact the PCF 360 directly. Alternatively, the NEF 354 may contact a new network function that provides a specific service (e.g., to propose the required PDU set QoS parameters based on the PDU set QoS requirements, flow description or PFD associated with the application identifier, AF identifier from the AF; to use the AUSF service to generate / retrieve security keys based on security parameters. If the NEF 354 determines to contact the PCF directly, the NEF uses the UE address to discover the PCF from the BSF. The NEF 354 interacts with the PCF by triggering the Npcf_PolicyAuthorization_Create request and provides the UE address, AF identifier, flow description or application ID, PDU set QoS requirements, and PDU set handling indication.

[0085] For a request received from the NEF 354 (event 820), the PCF 360 determines whether the request is authorized, and notifies 822 the NEF if the request is not authorized. If the request is authorized, the PCF derives the required PDU Set QoS parameters based on the information provided by the NEF, and determines whether the PDU Set QoS is allowed (according to the PCF configuration), and notifies the NEF of the result. If the AF is deemed to be trusted by the operator, the PCF sends a Npcf_PolicyAuthorization_Create response message directly to the AF. If the PCF determines that the SMF requires updated policy information, the PCF issues a Npcf_SMPolicyControl_UpdateNotify request with updated policy information about the PDU Session, as described in the PCF-Initiated SM Policy Association Modification Procedure in Section 4.16.5.2 of TS 23.502. If the request is not authorized, or the required PDU Set QoS requirement is not allowed, the NEF responds to the AF with a result value indicating the reason for the failure. If the PCF determines that the SMF requires updated policy information, the PCF issues a Npcf_SMPolicyControl_UpdateNotify request with updated policy information about the PDU session, as described in the PCF-Initiated SM Policy Association Modification procedure in clause 4.16.5.2.

[0086] At event 804, NEF 354 sends a Nnef_AFsessionWithQoS_Create response message (transaction reference ID, result) to AF. The result indicates whether the request is granted. NEF 354 sends 824 Npcf_PolicyAuthorization_Subscribe message to PCF to subscribe to notifications of resource allocation status, and may subscribe to other events described in Section 6.1.3.18 of TS23.503. At event 826, when the event condition is met (e.g., the success or failure of the establishment of transmission resources corresponding to the PDU set QoS update), PCF sends Npcf_PolicyAuthorization_Notify message to NEF notifying the event. If the AF is considered to be trusted by the operator, the PCF sends the Npcf_PolicyAuthorization_Notify message directly to the AF. At event 806, NEF 354 sends a Nnef_AFsessionWithQoS_Notify message to AF 358 under the event reported by PCF 360. At event 840, PCF 360 checks whether the PDU Set QoS parameters correspond to the authorized PS QoS policy for AF. If the check is successful, PCF 360 notifies SMF 366 via a Npcf_SMPolicyControl_UpdateNotify message including PCC rules. PCC rules contain PFD, PDU Set QoS policy.

[0087] At event 840, a QoS profile with PDU set information including PSQFI and PDU set QoS requirements and QoS characteristics is provided by the SMF via the AMF to the (R)AN (including both 3GPP or non-3GPP access networks) over the N2 reference point, or is pre-configured in the (R)AN. At event 850, based on the PCC rules received from the PCF, the SMF configures the UPF via an N4 message including PDR (e.g., traffic classifier policy / application ID based on PFD), PSICR, and PS-QER, etc. At event 860, one or more QoS rules for the PDU set and PDU set QoS flow level-related PDU set QoS parameters associated with these QoS rules for the PDU set may be provided by the SMF via the AMF over the N1 reference point to the UE for uplink / downlink PDU set handling for the required QoS. The PDU set QoS rules may be applied to handle corresponding traffic in the UL direction, DL direction, or both. Event 850 relates to, for example, solutions 1, 2, and 3 described above. Events 840, 850, and 860 also involve Solution 4.

[0088] At event 870, UPF 370 implements the configured rules to detect / identify / classify packets received from the N3 / N9 / N6 interface, implement PDU set QoS treatment for the identified packets based on PS-QER, and mark the classified packets before forwarding the packets. UPF 370 may further configure 880 N3 GTP header information (e.g., QFI+PSQFI) in the GTP-U packet, which provides the PDU set classification information (in-band) to the RAN 105.

[0089] Fig. 9 is a flowchart 900 of an example method for PDU handling, which may be performed in Figure 1 The PCF may be implemented in a policy control function (PCF) of a CN of the SMF. At block 902, the PCF may receive an indication related to handling a PDU set including a plurality of PDUs. At block 904, the PCF may provide a rule for processing the PDU according to the indication to the SMF.

[0090] Fig.10 is a flowchart 100 of an example method for PDU handling, which may be performed in Figure 1 At block 1002, the SMF receives rules (e.g., PCC rules) related to handling PDU sets from the PCF. At block 1004, the SMF generates and provides to the UDF a second rule for classifying a data packet as belonging to a PDU set based on the first rule.

[0091] The following list of examples reflects various embodiments expressly contemplated by the present disclosure:

[0092] Example 1. A method for QoS configuration for XR and media services in 5GS based on PDU set QoS requirements and PDU set handling indications provided by application functions to achieve PDU set handling for packets traversing a 5G network.

[0093] Example 2. A method according to Example 1, wherein the PDU set QoS requirements include: PDU set delay budget, PDU set packet error rate, averaging window, importance level of the PDU set (for example, an indication of the level of PDU discard rate), dependency on previous PDU sets, dependency on previous PDUs within the PDU set, PDU set burst size (the number of PDUs in the PDU set), PDU set burst arrival time at the UE (the number of PDUs in the PDU set) or PDU set burst arrival time at the UPF (downlink), periodicity of the PDU set, and existence time of the PDU set.

[0094] Example 3. A method according to Example 2, wherein the PDU set handling indication includes at least one of the following information: identification and classification type (indicating the use of RTP / SRTP header or RTP extension header, metadata carried in XRM packet, IP header of TOS / DTRS, or specific IP header configuration of XRM traffic); identification and classification rules (containing information related to packet identification and classification of traffic identified by the PDR for a specific N4 session); security parameter settings for using a specific streaming protocol (such as RTP / SRTP) to achieve complete encryption for XRM packets by generating symmetric keys for specific XRM services or providing asymmetric encryption of public keys (the application server encrypts the packets with a private key), thereby providing complete encryption protection.

[0095] Example 4. The method of Example 3, wherein the AF sends an AF request to request the NEF or PCF to configure required PDU set QoS requirements to some traffic flows or applications of the UE based on the PDU set handling indication.

[0096] Example 5. The method of example 4, wherein the AF request includes an application ID or a flow description.

[0097] Example 6. The method of Example 5, wherein the AF request is a Nnef_AFsessionWithQoS_Create / Update request message or a new message dedicated to a procedure for handling a PDU set, such as a Nnef_AFsessionWithPSQoS_Create / Update request.

[0098] Example 7. The method of Example 6, wherein the PCF generates a PCC rule for PDU set handling and a PDU set QoS policy to the SMF based on the PDU set handling indication and the PDU set QoS requirement.

[0099] Example 8. The method of Example 7, wherein the SMF further generates a rule set in an N4 message to configure the UPF, wherein the rule includes a PDR and a PSICR having a traffic treatment rule set for handling the PDUs in each PDU set.

[0100] Example 9. The method of Example 8, wherein based on the N4 message, the UPF applies a PDR rule and a PSICR rule to identify the PDUs and classify the PDUs into a specific PDU set.

[0101] Example 10. The method of Example 9, wherein the UPF may further configure N3 GTP header information (eg, PSQFI) in the GTP-U packet, which provides PDU set classification information (in-band) to the RAN.

[0102] Example 11. The method of Example 10, wherein the PSQFI is defined as a PDU set QoS flow used by the 5G system to provide QoS differentiation for PDU sets of XRM packets in a PDU session.

[0103] Example 12. The method of Example 11, wherein user plane packets with the same PSQFI within a PDU session receive the same traffic forwarding treatment (eg, scheduling, admission threshold).

[0104] Example 13. The method of Example 12, wherein the QFI, PSQFI, or both are carried in the encapsulation header (ie, GTP-U header) at N3 (and N9), ie, without any changes to the e2e packet header.

[0105] Example 14. The method of Example 13, wherein the PDU set QoS flow may be characterized by one or more UL and DL PDRs with PSICR provided by the SMF to the UPF.

[0106] Example 15. A method according to Example 14, wherein a QoS profile having PDU set information including PSQFI and PDU set QoS requirements and QoS characteristics is provided by the SMF to the (R)AN (including both 3GPP or non-3GPP access networks) via the AMF over the N2 reference point, or is pre-configured in the (R)AN.

[0107] Example 16. A method according to Example 15, wherein a QoS profile having a QFI as well as QoS requirements and QoS characteristics is provided by the SMF via the AMF over the N2 reference point to the (R)AN (including both 3GPP or non-3GPP access networks), or is pre-configured in the (R)AN.

[0108] Example 17. A method according to Example 14, wherein one or more QoS rules of a PDU set and PDU set QoS flow level-related PDU set QoS parameters associated with these QoS rules of the PDU set can be provided by the SMF to the UE via the AMF over the N1 reference point and can be applied to process corresponding traffic in the UL direction, DL direction, or both.

[0109] Example 18. A method according to Example 17, wherein one or more QoS rules and QoS flow level-related QoS parameters associated with these QoS rules may be additionally provided by the SMF to the UE via the AMF over the N1 reference point and may be applied to process corresponding traffic in the UL direction, the DL direction, or both.

[0110] Example 19. The method of Example 18, wherein the UE implements the QoS rules if the QoS rules of the PDU set are not applicable due to implementation reasons.

[0111] The following description can be applied to the above description.

[0112] The user device (e.g., UE 102) in which the technology of the present disclosure can be implemented can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device (such as a smart watch), a wireless hotspot, a femtocell, or a broadband router. Further, in some cases, the user device can be embedded in an electronic system such as a head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0113] Certain embodiments are described in the present disclosure as including logic or multiple components or modules. A module may be a software module (e.g., code stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit that is capable of performing certain operations and may be configured or arranged in a particular manner. A hardware module may include a dedicated circuit system or logic that is permanently configured (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuit systems (e.g., contained 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 permanently configured circuit system or in a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

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

Claims

1. A method for packet data unit (PDU) handling, the method being implemented in a policy control function (PCF) of a core network (CN), and the method comprising: receiving an indication related to handling a PDU set, the PDU set including a plurality of PDUs associated with an information unit generated at an application level; as well as A Session Management Function (SMF) of the CN is provided with rules for processing the PDU according to the indication.

2. The method according to claim 1, further comprising: A quality of service (QoS) requirement is received for the set of PDUs.

3. The method according to claim 2, further comprising: Policy and Charging Control (PCC) rules including a QoS policy for the PDU set are provided to the SMF.

4. The method according to claim 3, wherein: Providing the PCC rules to the SMF is in response to determining that the QoS parameters based on the QoS requirements correspond to an authorized packet switched (PS) QoS policy of an application function (AF) of the CN.

5. The method according to claim 3 or 4, wherein providing the PCC rules to the SMF comprises: Send Npcf_SMPolicyControl_UpdateNotify message.

6. The method according to any one of claims 2 to 5, wherein the QoS requirements include one or more of the following: (i) PDU set delay budget, (ii) PDU set packet error rate, (iii) Averaging window, (iv) PDU set size, (v) the importance level of the PDU set, (vi) Dependency on previous PDU sets.

7. A method according to any one of the preceding claims, wherein: The indication related to the handling of the set of PDUs is received from a network opening function (NEF).

8. The method according to any one of claims 1 to 3, wherein: The indication related to the handling of the set of PDUs is received directly from an AF.

9. The method according to claim 7 or 8, wherein: The indication related to the handling of the PDU set is included in an Npcf_PolicyAuthorization_Create request message.

10. The method according to any one of the preceding claims, wherein the indication related to the handling of the PDU set indicates one of: (i) Activation, (ii) deactivate, or (iii) Modification.

11. The method according to any one of the preceding claims, wherein the indication related to the handling of the PDU set comprises one or more of the following: (i) PDU set identification and classification type, (ii) PDU set identification and classification rules, and (iii) Safety parameters.

12. A method for packet data unit (PDU) handling, the method being implemented in a session management function (SMF) of a core network (CN), and the method comprising: receiving a first rule related to handling of a set of PDUs from a policy control function (PCF); as well as A second rule for classifying a data packet as belonging to the PDU set is provided to a user plane function (UPF) of the CN, the second rule being based on the first rule.

13. The method according to claim 12, wherein: The first rule is a Policy and Charging Control (PCC) rule, the PCC rule comprising (i) one or more Packet Flow Descriptors (PFDs) and (ii) a PDU Set QoS policy.

14. The method according to claim 12 or 13, wherein the receiving of the first rule comprises: Receive Npcf_SMPolicyControl_UpdateNotify message.

15. The method according to any one of claims 12 to 14, wherein: The second rule is a packet detection rule (PDR), and the PDR includes one or more of the following: (i) Traffic classifier strategy, (ii) PDU Set Identification and Classification (PSICR), or (iii) PDU Set QoS Implementation Rules (PS-QER).

16. The method according to any one of claims 12 to 15, further comprising: A QoS profile including PDU set information is provided to a Radio Access Network (RAN).

17. The method according to claim 16, wherein the PDU set information comprises at least one of the following: (i) PDU Set QoS Flow Identifier (PSQFI), (ii) PDU set QoS requirements, or (iii) PDU set QoS characteristics.

18. The method according to any one of claims 12 to 17, further comprising: One or more QoS rules associated with the set of PDUs are provided to a user equipment (UE).

19. The method according to claim 18, further comprising: PDU set QoS parameters related to the QoS flow and associated with the one or more QoS rules are provided to the UE.

20. A node in a core network (CN), the node comprising one or more processors and configured to implement the method according to any one of the preceding claims.

Images