Pdu session with ran support in a communication system

Abstract

A node of a core network (CN) associated with a serving radio access network (RAN) receives (1102), from a roaming user equipment (UE) via the serving RAN, a request to establish a protocol data unit (PDU) session; determines (1111) whether the serving RAN supports PDU Set handling; and provides (1131) an indication of whether the serving RAN supports the PDU Set handling to a home CN of the roaming UE.

Description

PDU SESSION WITH RAN SUPPORT IN A COMMUNICATION SYSTEMCROSS-REFERECE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 519,227 entitled “PDU Session with NG-RAN Support for XR and Media Services in a communication System,” filed on August 11, 2023 and U.S. provisional U.S. Patent Application No. 63 / 541,458 entitled “PDU Session with NG-RAN Support for XR and Media Services in a communication System,” filed on September 29, 2023. The entire contents of the provisional applications are hereby expressly incorporated herein by reference.FIELD OF THE DISCLOSURE

[0001] This disclosure relates generally to wireless communications and, more particularly, to managing user consent for analytic and event monitoring operations in a cellular communication networks.BACKGROUND

[0002] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0003] Generally speaking, a base station operating a cellular radio access network (RAN) communicates with a user equipment (UE) using a certain radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of a RAT provides transport channels to the Medium Access Control (MAC) sublayer, which in turn provides logical channels to the Radio Link Control (RLC) sublayer, and the RLC sublayer in turn provides data transfer services to the Packet Data Convergence Protocol (PDCP) sublayer. The Radio Resource Control (RRC) sublayer is disposed above the PDCP sublayer. A Service Data Adaptation Protocol (SDAP) layer, disposed above the PDCP layer, supports Packet Data Units (PDU) sessions, which include one or more quality-of-service (QoS) flows. A core network (CN) communicates data with the UE via the RAN using multiple layers of a protocol stack.

[0004] Some of the services fifth-generation systems (5GS) require a high data rate and low- latency transmissions. One example of such services is extended Reality (XR), which includes Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR). In virtual reality applications, the user is fully immersed in a virtual environment that fully replaces the real, physical environment, typically by wearing a head-mounted device. In augmented reality, an application augments the perception of the real environment by overlaying virtual elements on the perception of the real environment. Augmented reality recently became the foundation of a widely popular game in which players seek out and interact with virtual creatures superimposed onto a real-time video stream of the real world. Finally, mixed reality is an extension of AR, where real and virtual elements can interact in real time.

[0005] XR games and other applications often run on cloud platforms that include remote servers, and generally do not require games consoles, high-spec CPUs, or high-spec GPUs. Cloud gaming involves streaming a game similar to streaming a video, and the game responds to the gamer’s commands and controls in real time.

[0006] To better support high-data-rate, low-latency services such as XR, the 3rd Generation Partnership Project (3GPP) recently proposed to group certain Packet Data Units (PDUs) into sets of multiple PDUs carrying the pay load of one unit of information generated at the application level (e.g., frames or video slices). The PDUs in a PDU Set can have the same importance for the application level. The 3GPP further proposed to support PDU set-based quality of service (QoS) requirements.

[0007] A RAN can handle PDU Sets according to PDU Set QoS parameters and PDU Set information in the header of a General Packet Radio Service (GPRS) Tunnelling Protocol (GTP)- U packet, dedicated to GTP user data. A PDU Session Anchor (PSA) User Plane Function (UPF), operating in the core network, provides the PDU Set information. In the CN, a Session Management Function (SMF) performs QoS flow binding based on a service data flow, configures the UPF with rules for PDU Set identification and marking via the GTP-U header, and provides QoS profiles including PDU Set QoS parameters to the RAN over the N2 interface. More particularly, the SMF can provide the UPF with a protocol description indicating theheader (e.g., RTP / SRTP) and pay load type (e.g. H.264) of the service data flow(s) of a media stream from the application server.

[0008] The PSA UPF can receive a downlink (DL) PDU from a data network (DN) over the N6 interface and, when PDU Set handling applies, apply the rules for PDU Set identification and provide, in the GTP-U header, PDU Set Information for the RAN. If the RAN receives PDU Set QoS Parameters and supports such parameters, the RAN enables PDU Set-based QoS handling and applies PDU Set QoS parameters.

[0009] Generally speaking, PDU Set Identification and marking is resource- and timeintensive operation at the UPF. However, currently it is not clear how the SMF can be aware of support or lack of support of PDU Set based handling at the RAN, and when the SMF should instruct UPF whether to perform PDU Set Identification and marking. Further, when a UE associated with a Home Public Land Mobile Network (HPLMN) roams into a Visited Public Land Mobile Network (VPLMN), it is unclear how the home SMF (H-SMF) should handle the home-routed roaming case, in which the serving RAN may not always support PDU Set based handling. As a result, the CN can perform unnecessary PDU Set Identification and marking, which is a resource- and time-intensive operation.SUMMARY

[0010] An example embodiment of the techniques of this disclosure is method implemented in a node of a CN associated with a serving RAN. The method comprises receiving, from a roaming UE via the serving RAN, a request to establish a PDU session, determining whether the serving RAN supports PDU Set handling, and providing an indication of whether the serving RAN supports the PDU Set handling to a home CN of the roaming UE.

[0011] Another example embodiment of these techniques is a method implemented in a node of a home CN. The method comprises receiving, from a visited CN, a request to create a PDU session for a roaming UE associated with the home CN; receiving, from the visited CN, an indication whether a serving RAN associated with the visited CN supports PDU Set handling, and activating or deactivating the PDU Set handling at the home CN in accordance with the indication.

[0012] Yet another example embodiment of these techniques is a method implemented in a node of a CN. The method comprises receiving, from a UE) via a RAN, a request to establish a PDU session, receiving, from the RAN, (i) an indication that the RAN does not support PDU Set handling and (ii) a list of rejected qualify-of-service (QoS) flow identifiers (QFIs), and releasing resources only for the rejected QFIs.

[0013] Still another example embodiment of these techniques is a node in a CN comprising processing hardware and configured to implement one of the methods above.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Fig. 1 is a block diagram of an example wireless communication system in which a user equipment unit (UE) associated with a HPLMN accesses a VPLMN via the serving RAN, and the VPLMN and / or HPLMN can determine whether to activate PDU Set handling for the UE;

[0015] Fig. 2 is a block diagram of an example protocol stack according to which the UE of Fig. 1 can communicate with the RAN of Fig. 1;

[0016] Fig. 3 is a service-based representation of a CN architecture, including the overall nonroaming reference architecture of the policy and charging control framework for a cellular communication system;

[0017] Fig. 4 is a reference-point based representation of the CN architecture, including overall non-roaming reference architecture of the policy and charging control framework of the cellular communication system;

[0018] Fig. 5 illustrates a reference procedure for establishing and modifying a PDU session, which can be implemented in the system of Fig. 1 ;

[0019] Fig. 6 A is a messaging diagram of an example scenario in which the SMF determines, based on the cause value the RAN provided when accepting or rejecting QoS flows, whether to activate PDU Set handling;

[0020] Fig. 6B is a messaging diagram of an example scenario in which the RAN provides, to the SMF, an indication of support or lack of support of PDU Set handling prior to the SMF performing the UPF selection and configuration;

[0021] Fig. 6C is a messaging diagram of an example scenario in which the RAN provides, to the SMF, an indication of support or lack of support of PDU Set handling in an N2 PDU session response message;

[0022] Fig. 7 A is a messaging diagram of an example home-routed scenario in which the H- SMF performs PDU Set identification and marking, and in which the V-SMF notifies the H-SMF of a reason for rejecting certain QFIs;

[0023] Fig. 7B is a messaging diagram of an example home-routed scenario in which the serving RAN provides, to the V-SMF, an indication of support or lack of support of PDU Set handling prior to the V-SMF performing the UPF selection and configuration;

[0024] Fig. 7C is a messaging diagram of an example home-routed scenario in which the serving RAN provides, to the V-SMF, an indication of support or lack of support of PDU Set handling in an N2 PDU session response message;

[0025] Fig. 8 is a messaging diagram of an example scenario in which a RAN node notifies the Access and Mobility Management Function (AMF) of support or lack of support of PDU Set handling in a RAN Configuration Update message;

[0026] Fig. 9 is a messaging diagram of an example scenario in which a RAN node notifies the AMF of support or lack of support of PDU Set handling using a dedicated procedure;

[0027] Fig. 10 is a messaging diagram of an example scenario in which a RAN node notifies the AMF of support or lack of support of PDU Set handling using a dedicated message;

[0028] Fig. 11 is a flow diagram of an example method for processing a request to establish a PDU session, which can be implemented in a CN node of a VPLMN;

[0029] Fig. 12 is a flow diagram of an example method for processing a request to establish a PDU session, which can be implemented in a CN node of a HPLMN; and

[0030] Fig. 13 is a flow diagram of an example method for processing an indication that the RAN does not support PDU Set handling, which can be implemented in a CN node.DETAILED DESCRIPTION OF THE DRAWINGS

[0031] In at least some of the scenarios discussed below, a UE and a CN support PDU Set based handling (or simply “PDU Set handling”) of data, where a PDU Set includes one or more PDUs carrying the payload of one unit of information. A device can generate a PDU Set at the application level. An application can transmit the PDUs of a PDU Set within the same QoS Flow and can use such PDU Set parameters as a PDU Set Delay Budget (PSDB), a PDU Set Error Rate (PSER), and a PDU Set Integrated Handling Information (PSIHI). For example, a PDU Set can correspond to a frame or video slice for XR Services and Media services, collectively referred to as “XRM services.” In some cases, the application generates and transmits multiple PDUs within a relatively short period of time as a data burst, which can include one or several PDU Sets.

[0032] The RAN in some cases supports PDU Set handling, but in other cases does not support PDU Set handling. The techniques discussed with reference to Figs. 1-13 allow the cellular system to provision QoS flows based on the PDU Set handling capability of the RAN.

[0033] To consider for example XRM services, during the registration procedure, the AMF can determine whether the UE is authorized to use XRM services based on the XRM Service Capability and the XRM Service Authorization, which the Unified Data Management (UDM) provides to the AMF as a part of the subscription data for the UE. The UE of the examples below supports XRM services capabilities for PDU Set handling.

[0034] Referring first to Fig. 1, an example wireless communication system 100 can implement one or more of the techniques of this disclosure for handling PDU sessions that require PDU Set handling. A roaming UE 102 can access a VPLMN 101 via a serving RAN 105 associated with the VPLMN 101. An HPLMN 103 holds subscriber data for the UE 102, i.e., operates as the home PLMN for the UE 102.

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

[0036] The VPLMN 101 includes an AMF 164, an SMF 166A, and a UPF 170A, operating as a V-AMF, a V-SMF, and a V-UPF, respectively. The HPLMN 103 includes an SMF 166B, and a UPF 170A, a UDM 153, and a Policy Control Function (PCF) 360, operating as an H-SMF, H- UPF, an H-UDM, and H-PCF, respectively. Example implementations of the VPLMN 101 and the HPLMN 103 are discussed in more detail with reference to Figs. 3 and 4.

[0037] While not depicted in Fig. 1 to avoid clutter, the VPLMN 101 and the HPLMN 103 can include processing hardware such as one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general- purpose processors execute. Additionally or alternatively, the processing hardware can include special-purpose processing units. The processing hardware can be configured to implement the techniques of this disclosure for supporting PDU sessions.

[0038] Each of the base stations 104 and 106 can be equipped with processing hardware that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer- readable memory 134 storing instructions that the one or more general-purpose processors execute (none shown to avoid clutter). Additionally or alternatively, the processing hardwarecan include special-purpose processing units. The base stations 104 and 105 also include transceivers to communicate with UEs such as the UE 102 over a radio interface.

[0039] The UE 102 is equipped with processing hardware 130A that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The UE 102 also includes a transceiver 132A to communicate with the RAN 105 over a radio interface.

[0040] Further, the VPLMN 101 can implement a PDU Set controller 180A (e.g., in the V- AMF 164 and / or the V-SMF 166A), the HPLMN 103 can implement a PDU Set controller 180B (e.g., in the V-H-SMF 166B), and the UE 102 can implement a PDU Set controller 180A.

[0041] Fig. 2 illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB / ng-eNB 230 or a gNB 232 (e.g., one or more of the base stations 104, 106). In the example stack 200, a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to a EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2). The UE 102A, 102B, or 102C, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2, to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2, the UE 102 A or 102B can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

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

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

[0044] Next, Fig. 3 illustrates a service-based representation 300 of an example CN architecture, which the VPLMN 101 and / or the HPLMN 103 of Fig. 1 can implement. In the representation 300, the overall non-roaming reference architecture of the policy and charging control (PCC) framework for the 5GS includes components illustrated using solid lines, and the other components are illustrated using dashed lines. According to this representation, network functions enable other authorized network functions to access their services. The components that are outside the PCC framework include a Network Slicing Selection Function (NSSF) 302, a Network Repository Function (NRF) 306, a UDM 353, an Edge Application Server Discovery Function (EASDF) 310, a Network Slice Specific Authentication and Authorization Function (NSSAAF) 312, an Authentication Server Function (AUSF) 314, a Service Communication Proxy (SCP) 316, and a Network Slice Admission Control Function (NSACF) 318. The non- PCC architecture further includes the UE 102 and access networks such as the RAN 105.

[0045] The PCC framework in the architecture 300 includes a Unified Data Repository (UDR) 352, a Network Exposure Function (NEF) 354, a network data analytics function (NWDAF) 356, an Application Function (AF) 358, a PCF 360, a Charging Function (CHF) 362, an AMF 364, an SMF 366, and a UPF 370.

[0046] The AMF 364 is generally configured to manage registration, connection, and mobility of a UE (such as the UE 102A or 102B) and provide transport for session management (SM) messages between the UE 102A or 102B and the SMF 366. In some implementations, the AMF 364 is configured to generate logical interface IDs. The SMF 366 is generally configured tomanage sessions, allocate IP addresses for UEs, and provides downlink (DL) notifications. In some implementations, the SMF 366 also includes following functionalities for PIN service: providing per-QoS flow non-3GPP QoS assistance information to the UE (e.g. PEGC), and supporting IP address allocation to UE and PDR configuration with packet filter set for PIN to UPF for framed routing based on PIN group information from the UDM 353.

[0047] The UDM 353 is generally configured to handle user identification, access authorization based on subscription data, and subscription management. In some implementations, the UDM 308 is configured to generate or change logical interface IDs, as will be described below in detail. In some implementations, the UDM 353 supports the functionality of PIN group management handling. The UDR 352 is generally configured to store subscription- related information, such as subscription data, policy data, structured data for exposure, and application data.

[0048] The UPF 370 is generally configured to handle packet routing and forwarding. Further, the NEF 354 is configured to expose the capabilities and services of the network to authorized third-party applications. As illustrated in Fig. 3, the UPF 370 can provide UEs with access to a data network 330 and, conversely, allow one or more application servers in the data network 330 to establish PDU sessions with the UE 102.

[0049] The AF 358 in some deployment operates in a trusted domain or outside the trusted domain, i.e., in a non-trusted domain. The trusted domain is generally internal to the CN and includes such components as the UDM 353, the UDR 352, the PCF 360, the AMF 364, the SMF 366, and the UPF 370. Generally speaking, an AF operating outside the trusted domain (such as operated by an authorized third-party entity) can access the network functions of the CN only via the NEF 354, whereas an AF operating within the trusted domain can access at least some of the network functions of the CN directly, or may access these functions via the NEF 354 in some deployments.

[0050] Fig. 4 is a reference-point based representation 400 of an example CN architecture. In Fig. 4, the non-roaming reference architecture of the PCC framework is illustrated as blocks and connections with solid lines, and components and connections outside the PCC framework are illustrated using dashed lines.

[0051] The communication system shown Figs. 1-4 in may include additional, fewer, and / or alternative devices or functionalities, and may be configured to perform additional, fewer, or alternate actions, including functionalities / actions described herein.

[0052] Next, Fig. 5 illustrates a reference scenario 500 in which a UE establishes and modifies a PDU session, which can be implemented in the system of Fig. 1. During the registration procedure, the AMF can determines 502 whether the UE 102 is authorized to use XRM services based on the XRM Service Capability of the UE and the XRM Service Authorization included in the subscription data received from UDM as specified in TS 23.501 clause 5.7, for example.After successful registration, the UE 102 requests 504 for PDU Session Establishment procedure, and the RAN 105 capable of XRM services can perform PDU Set handling for the QoS flows in a PDU Session based on the XRM service authorization and information received from the SMF 366 via N2 message and GTP-U header via N3 interface from the UPF 370. The PDU Session Establishment Procedure can be implemented as described in TS 23.502 clause 4.3.2.2, for example. The UE 102 may repeat 504 the PDU Session Establishment procedure for multiple PDU Sessions associated with the same or different data network name (DNN) and single network slice selection assistance information (S-NSSAI). The UE 102 or the network can initiate 506 a PDU Session Modification Procedure for the existing PDU Session. The PDU Session Modification Procedure can be implemented as described in TS 23.502 clause 4.3.3.2 and 4.3.3.3, for example.

[0053] When the PLMN provides homogeneous RAN support of PDU Set handling, the reference 500 procedure can include the modifications briefly discussed next, in order to support PDU Set based QoS. The PCF 360 can provide PCC rules for an application service flow as defined in TS 23.503 clause 6.1.3.27.4, for example. The application service flow can include PDU Set QoS parameters (e.g., PSER, PSDB and PSIHI) and the Protocol Description. The SMF 366 can determine a QoS Profile for a QoS flow, based on the received PCC rules or a pre-configuration. The PSA UPF 360 can identify PDUs that belong to a PDU Set using the Protocol Description and the received Packet Detection Rule (PDR). Further, the PSA UPF 360 can mark the GTP-U header for PDU Set information as described in TS 23.501 clause 5.37.5.2. Still further, the PSA UPF 360 can generate PDU Set based parameters based on the QoS Enforcement Rule (QER).

[0054] Next, several approaches to non-roaming and local breakout cases are considered in connection with Figs. 6A-C, followed by a discussion of roaming cases with reference to Figs. 7A-C. Generally speaking, similar events in Figs. 6-C and 7A-C are labeled with similar reference numbers that share two least significant digits, with differences discussed below where appropriate. For example, event 602 is similar to event 702, event 620 is similar to event 720, and event 692 is similar to event 792.

[0055] According to the approach illustrated in Fig. 6A, the RAN 105 indicates support or lack of support of PDU Set handling. In particular, the RAN 105 provides, to the SMF 366 via the AMF 364, an appropriate cause value for the rejected QFIs. The SMF 366 determines whether to enable PDU Set handling at the RAN 105 (when supported) by requesting PDU Set QoS parameters for the one of more QOS flows of the PDU Session.

[0056] The UE 102 first transmits 602, to the AMF 364, a PDU Session Establishment Request message including a PDU Session ID, a DNN, and an S-NSSAI. The DNN and the S- NSSAI can be associated with a certain XRM service.

[0057] The AMF 364 then performs 604 SMF selection based on the DNN and S-NSSAI. If the DNN and S-NSSAI are associated with an application that requires a PDU Set based QoS, the AMF 364 can select a specific SMF capable of PDU Set handling, e.g., the SMF 366. Next, the AMF 364 transmits 610, to the selected SMF 366, an Nsmf_PDU Session_CreateSMContext Request message including the PDU session ID, the DNN, and the S-NSSAI.

[0058] The SMF 366 can retrieve 612, for the UE 102 and based on the DNN and the S- NSSAI, subscription data related to XRM. The SMF 366 transmits 614, to the AMF 364, an Nsmf_PDU Session_CreateSMContext Response message in response to receiving 610 the Nsmf_PDU Session_CreateSMContext Request message. The SMF 366 then performs 620 a PDU Session authentication / authorization procedure with the DN 330, using the user credential information the UE 102 provided for the connection to the DN 330.

[0059] Further, the SMF 366 performs 644 a UPF selection and determines, based on the PCC policy information from PCF 360, whether to activate PDU Set identification and marking at the PSA UPF 370 for the PDU session associated with the DNN and the S-NSSAI. To this end and when necessary, the SMF 366 queries 645 the PCF 360 to retrieve and / or update the PCCpolicies. Although Fig. 6A illustrates the event 645 occurring the event 644, it will be understood that the events 644 can overlap in time at least partially. When the SMF 366 determines that the PCC policies require PDU Set handling, the SMF 366 instructs the PSA UPF 360 to activate PDU Set identification and marking for the PDU session corresponding to the DNN and the S-NSSAI.

[0060] With continued reference to Fig. 6A, if the SMF 366 determines to activate PDU Set handling for the PDU Session of the UE 102, the SMF 366 transmits 647, to the AMF 364, a Namf_Communication_NlN2MessageTransfer message including PDU Set QoS parameters, so as to enable (or activate) the PDU Set handling at the RAN 105. The AMF 364 forwards 650, to the RAN 105, the NAS message in a N2 PDU Session request message.

[0061] The RAN 105 then performs 652 an RRC Reconfiguration procedure of the UE 102. In particular, the RAN 105 transmits 652 a PDU Session Establishment Accept message for an AN-specific resource setup at the UE 102. The RAN 105 also indicates 654 to the AMF 364 whether the RAN 105 accepted or rejected the PDU Set based QoS parameters for the QoS flows of the PDU Session. More particularly, the RAN 105 transmits 654, to the AMF 364, an N2 PDU Session Response including the PDU Session ID, a cause, a list of accepted and / or rejected QFl(s)) message. Each QF1 is a QoS flow identifier of a respective QoS flow. The RAN 105 can include 654 the appropriate cause value for a rejected QFI(s), which can be non-support of PDU Set handling at the RAN 105 (due to the S-NSSAI, the DNN, lack of radio resources, etc.).

[0062] The AMF 364 next transmits 656, to the SMF 366, a Nsmf_PDUSession_Update_SMContext Request message including the PDU session ID, he cause, the list of accepted and / or rejected QFI(s)). The SMF 366 can modify 680 the N4 session for the accepted and / or rejected QoS flows of the PDU Session. The modification 680 can apply to the UPF 370. For example, based on the cause value, the SMF 366 can determine to deactivate the PDU Set handling for the PDU Session at the UPF 370, or deactivate PDU Set identification and marking only for the rejected QoS flows. If the RAN 105 rejects QoS flows, the SMF 366 can instruct the UPF 370 to release the rejected QoS flows but maintain PDU Set handling for the accepted QoS flows. Requesting QoS parameters without PDU Set handling at the RAN 105 can require an additional signaling overhead.

[0063] The SMF 366 transmits 690 an Nsmf_PDUSession_UpdateSMContext Response message to the AMF 364, which then transmits 692 a PDU SessionEstablishment Response message to the UE 102.

[0064] Next, Fig. 6B is illustrates an example scenario 600B in which the RAN 105 provides, to the SMF 366 via the AMF 158, an indication of support or lack of support of PDU Set handling prior to the SMF performing the UPF selection and configuration. This approach also applies to non-roaming and local breakout cases.

[0065] Here, the SMF 366 requests PDU Set QoS parameters for the one or more QoS flow(s) of the PDU Session and uses the PCC policies and the support indication to determine whether to request activation of PDU Set handling at the RAN 105. The AMF 364 obtains information related to the support of PDU Set handling at the RAN 105 using a non-UE-specific N2 procedure. The AMF 364 then stores the RAN 105 capabilities related to supporting PDU Set handling.

[0066] In the scenario 600B, the RAN 105 also provides a support indication to the SMF 366 via the AMF 364. In particular, during the PDU Session Establishment Request procedure, the AMF 364 provides an indication of supporting PDU Set handling at the RAN 105, as discussed below. During the PDU Session Modification Request procedure, the AMF 364 can transmit, to the SMF 366, an indication of supporting PDU Set handling at the RAN 105. The SMF 366 can determine whether to activate or deactivate PDU Set handling at the UPF 370 based on the indication of support (or non-support) of PDU Set handling at the RAN 105.

[0067] More specifically, the RAN 105 and the AMF 364 can exchange 601 RAN configuration information, and the RAN 105 provides 601, to the AMF 364, an indication of support or non-support of PDU Set handling at the RAN 105. The AMF 364 can store the RAN 105 capabilities of supporting PDU Set handling. The message exchange 601 can be implemented as a message exchange 801, 901, or 1001 discussed below with reference to Figs. 8-10.

[0068] The UE 102 then transmits 602, to the AMF 364, a PDU Session Establishment Request message including a PDU Session ID, a DNN, and an S-NSSAI, as discussed above with reference to Fig. 6A. The AMF 364 then performs 606 SMF selection based on the DNN and S-NSSAI, also as in the scenario 600A.

[0069] The AMF 364 transmits 611, to the to the SMF 366, an Nsmf_PDU Session_CreateSMContext Request message including a PDU session ID, the DNN, the S- NSSAI, and also an indication whether the RAN 105 supports PDU Set handling (unlike the transmission 610 in Fig. 6A). In some implementations, the AMF 364 provides 611, to the SMF 366, an indication of whether the RAN 105 supports PDU Set handling only if the DNN and S- NSSAI are associated with an application that requires a PDU Set based QoS. Further, the AMF 364 can store the indication of support (or non-support) of PDU Set handling at the RAN 105, which can have a certain RAN ID, such as the Global RAN Node ID associated with the N2 interface.

[0070] Events 612, 614, and 620 can proceed as discussed above with reference to Fig. 6A. The SMF 366 then performs 646 a UPF selection and determines, based on the PCC policy information from PCF 360, whether to activate PDU Set identification and marking at the PSA UPF 370 for the PDU session associated with the DNN and the S-NSSAI. To this end and when necessary, the SMF 366 queries 645 the PCF 360 to retrieve and / or update the PCC policies. In addition to considering the PCC policies, the SMF 366 can consider 646 the indication of whether the RAN 105 supports PDU Set handling, received 611 from the AMF 364. Using the indication of whether the RAN 105 supports PDU Set handling, the SMF 366 reduces the chances the RAN 105 will reject one or more QoS flows due to the PDU Set based handling requirement, which would result in additional signaling overhead associated with requesting QoS parameters.

[0071] Events 645, 647, 650, 652, 654, 656, 690, and 692 can proceed as discussed with reference to Fig. 6A. Also similar to Fig. 6A, the SMF 366 can modify 680 the N4 session for the accepted and / or rejected QoS flows of the PDU Session. In some implementations, the SMF 366 activates PDU Set identification and marking for the accepted PDU Set based QoS flows.

[0072] Fig. 6C illustrates example scenario 600C in which the RAN provides, to the SMF, an indication of support or lack of support of PDU Set handling in an N2 PDU session response message. The RAN 105, the AMF 364, and the SMF 366 performed an enhanced PDU session establishment or modification procedure that includes the RAN 105 indicating support or nonsupport of PDU Set handling. In particular, the SMF 366 can determine whether to enable PDUSet handling for the PDU Session of the UE 102 based on the conditions discussed above with reference to Fig. 6B. If the SMF 366 determines to enable the PDU Set handling, the SMF 366 requests PDU Set QoS parameters for the one or more QoS flow(s) of the PDU Session.

[0073] The RAN 105 in the scenario 600C provides an indication of support or non- support of PDU Set handling to the SMF 366 via the AMF 364. During the PDU session establishment request procedure, and after the RAN 105 transmits, to the AMF 364, an N2 PDU Session response including an indication of whether the RAN 105 supports PDU Set handling, the AMF 364 further transmits, to the SMF 366, an Nsmf_PDU Session_CreateSMContext Request including the indication of whether the RAN 105 supports PDU Set handling. During the PDU session modification request procedure, and after the RAN 105 transmits, to the AMF 364, an N2 PDU Session response message including an indication of whether the RAN 105 supports PDU Set handling, the AMF 364 further transmits, to the SMF 366, an Nsmf_PDU Session_UpdateSMContext Request message including the indication of whether the RAN 105 supports PDU Set handling. The SMF 366 further can determine whether to modify the N4 session for activating or deactivating PDU Set handling after receiving the indication of whether the RAN 105 supports PDU Set handling, and receiving the accepted and / or rejected QoS flows.

[0074] Referring specifically to Fig. 6C, events 602 and 604 proceed as discussed with reference to Fig. 6B; event 610 proceeds as discussed with reference to Fig. 6A; events 612, 614, and 620 proceed as discussed with reference to Fig. 6B; and events 644, 645, 647, 650, and 652 proceed as discussed with reference to Fig. 6A.

[0075] The RAN 105 indicates 655 whether the RAN 105 accepts or rejects the PDU Set based QoS parameters for the QoS flows of the PDU Session. In particular, the RAN 105 can transmit 655, to the AMF 364, an N2 PDU Session Response message including a PDU Session ID, a cause, a list of accepted and / or rejected QFI(s), and an indication of whether the RAN 105 supports PDU Set handling. Similar to the examples above, a QFI identifies a particular QoS Flow.

[0076] When the RAN 105 activates PDU Set handling for the accepted QFI(s), the RAN 105 includes an indication of supporting PDU Set handling in the response message include the RAN 105 transmits to the SMF 366 via the AMF 364. Further, the RAN 105 can include a suitablecause value for the rejected QFI(s) (if any), e.g., lack of support of PDU Set handling due to the S-NSSAI, the DNN, lack of radio resources, etc.

[0077] The AMF 364 transmits 657 an Nsmf_PDUSession_Update_SMContext Request message to the SMF 366. The PDUSession_Update_SMContext Request message can include the PDU session ID, the cause, the list of accepted and / or rejected QFI(s), and the indication of whether the RAN 105 supports PDU Set handling.

[0078] The SMF 366 then modifies 681 the N4 session for the accepted and / or rejected QoS flows of the PDU Session. For example, if the SMF 366 previously activated 644 PDU Set handling at the UPF 370, and the RAN 105 does not provide an indication of support of PDU Set handling (or provides an indication of non-support of PDU Set handling), the SMF 366 can instruct the UPF 370 to deactivate the PDU Set identification and marking for the accepted QoS flows. In this case, the RAN 105 does not activate PDU Set handling at the RAN 105, and the accepted QoS flows can ignore the PDU Set based QoS parameters. As another example, if the SMF 366 previously activated 644 PDU Set handling at the UPF 370, and the RAN 105 provides an indication of support of PDU Set handling (or does not provide an indication of non-support of PDU Set handling), the SMF 366 can instruct the UPF 370 to modify the N4 session to release resources for the rejected QFl(s) only. Events 690 and 692 can proceed as discussed with reference to Fig. 6A or Fig. 6B.

[0079] Now referring to an example home-routed scenario 700A, here the H-SMF 166B (which can be implemented similar to the SMF 366) performs PDU Set identification and marking, and the V-SMF 166a (which also can be implemented similar to the SMF 366) notifies the H-SMF 166B of a reason for rejecting certain QFIs.

[0080] The RAN 105 indicates, to the V-SMF 166A via the AMF 158, the appropriate cause value for the rejected QFIs. The V-SMF 166A determines whether to enable PDU Set handling at the RAN 105, when supported, by requesting PDU Set QoS parameters for the QoS flow(s) in the PDU Session. For the PDU session establishment or modification request procedure, the AMF 164 transmits, to the V-SMF 166A, an Nsmf_PDU Session_CreateSMContext Request message, and the V-SMF 166A in turn transmits the Nsmf_PDUSession_Create Request message to the H-SMF 166B. For the PDU session Modification Request procedure, the AMF164 transmits, to the V-SMF 166A, a Nsmf_PDU Session_UpdateSMContext Request message, and the V-SMF 166A transmits a Nsmf_PDUSession_Update Request message to the H-SMF 166B. After the RAN 105 transmits a N2 PDU Session response message to the AMF 164, the AMF 164 further transmits an Nsmf_PDU Session_UpdateSMContext Request message to the V-SMF 166A.

[0081] As illustrated in Fig. 7A, the V-SMF 166A can notify the H-SMF 166B in a manner that allows the H-SMF 166B to modify the N4 session to activate or deactivate PDU Set handling for the accepted PDU Set QoS flows at the H-UPF170B. To this end, the V-SMF 166A can transmit a Nsmf_PDUSession_Update Request message with a PDU session ID, a list of accepted and / or rejected QFI(s), a cause value, and the H-UPF 170B can activate or deactivate PDU Set handling based on the received cause value for the rejected QoS flows of the PDU session.

[0082] According to this approach, the H-UPF 170B performs the PDU Set identification and marking for a home-routed UE. Thus, the V-PCF in the VPLMN 101 does not provide PDU Set based QoS in the PCC policies to the V-SMF 166A, and the V-SMF 166A does not instruct the V-UPF 170A via N4 session control (e.g., by including a Protocol Description in the PDR and PDU Set based QoS in the QER).

[0083] In particular, as illustrated in Fig. 7A, the UE 102 transmits 702, to the AMF 164, a PDU Session Establishment Request message including a PDU Session ID, a DNN, and an S- NSSAI. The DNN and the S-NSSAI can be associated with a certain XRM service.

[0084] The AMF 164 then performs 704 performs SMF selection based on the DNN and S- NSSAI. If the DNN and S-NSSAI are associated with applications that require PDU Set based QoS, based on the Service Level Agreement (SLA) between the VPLMN 101 and the HPLMN 103, the AMF 164 selects 704 a specific SMF capable of PDU Set handling.

[0085] The AMF 164 then transmits 710 an Nsmf_PDU Session_CreateSMContext Request message to V-SMF 166A. The V-SMF 166A transmits 714, to the AMF 164, an Nsmf_PDU Session_CreateSMContext Response message in response to receiving 710 the Nsmf_PDU Session_CreateSMContext Request message.

[0086] The V-SMF 166 A performs 730 V-UPF selection based on the local PCC configuration for roaming users or PCC polies from the V-PCF in the VPLMN 101. The SMF 166A configures 730 the V-UPF 170A with a PDR, to detect a certain QoS, and a QER, via an N4 session control for handling user plane traffic. For a home routed roaming UE, such as the UE 102, it is the H-UPF 170B that performs PDU Set identification and marking. As discussed above, the V-PCF does not provide PDU Set based QoS in the PCC policies to the V-SMF 166 A, and the V-SMF 166A does not instruct the V-UPF via the N4 session control.

[0087] The V-SMF 166A performs 712 PDU Session authentication and / or authorization with the DN 330, using the user credential information the UE 102 provided for the DN 330.

[0088] The V-SMF 166A transmits 731, to the H-SMF 166B, an Nsmf_PDUSession_Create Request message. The H-SMF 166B may retrieve 732, from the H-UDM 153, for the UE 102 and based on the received DNN and S-NSSAI, subscription information related to the XRM. If the DNN and the S-NSSAI are associated with applications that require PDU Set based QoS, the V-SMF 166A selects a specific H-SMF capable of PDU Set handling, based on SLA between the VPLMN 101 and the HPLMN 103.

[0089] The H-SMF 166B performs 734 H-UPF selection and determines whether to activate PDU Set identification and marking at the selected PSA H-UPF 170B for the PDU session, based on the PCC policies from the H-PCF 160B. When needed, the H-SMF 166B can contact 735 the H-PCF 160B to retrieve and / or update the PCC policies. If the PCC policies indicate a need for PDU Set handling, the H-SMF 166B instructs the PSA UPF 170B to activate PDU Set identification and marking for the PDU session corresponding to the DNN and the S-NSSAI. The H-SMF 166B transmits 736, to the V-SMF 166A, an Nsmf_PDUScssion_Crcatc Response message in response to receiving 731 the Nsmf_PDUSession_Create Request message.

[0090] If the V-SMF 166A determines to enable PDU Set handling for the PDU Session of theUE 102, the V-SMF 166A transmits 747, to the AMF 164, an Namf_Communication_NlN2MessageTransfer message with PDU Set QoS parameters, to enable the PDU Set handling at RAN 105. The AMF 164 forwards 750, to the RAN 105, a NAS message in an N2 PDU Session request.

[0091] The RAN 105 then performs 752 an RRC Reconfiguration procedure of the UE 102. In particular, the RAN 105 transmits 752 a PDU Session Establishment Accept message for an AN-specific resource setup at the UE 102. The RAN 105 also indicates 754 to the AMF 364 whether the RAN 105 accepted and / or rejected the PDU Set based QoS parameters for the QoS flows of the PDU Session. More particularly, the RAN 105 transmits 754, to the AMF 164, an N2 PDU Session Response including a PDU session ID, a cause, and a list of accepted and / or rejected QFI(s)) message. The RAN 105 can include 754 the appropriate cause value for a rejected QFI(s), which can be non-support of PDU Set handling at the RAN 105 (due to the S- NSSAI, the DNN, lack of radio resources, etc.).

[0092] The AMF 358 next transmits 756, to the V-SMF 166A, an Nsmf_PDUSession_Update_SMContext Request message including the PDU session ID, the cause, and the list of accepted and / or rejected QFI(s)). The cause value may indicate the reason why the RAN 105 rejected the corresponding QFI(s).

[0093] The V-SMF 166A transmits 760, to the H-SMF 166B, an Nsmf_PDUSession_Update Request including the PDU session ID, the cause, and the list of accepted and / or rejected QFI(s). The Nsmf_PDUSession_Update Request can also include the N2 SM Context. The H-SMF 166B may retrieve 762 the UE subscription information for the XRM using the DNN and the S- NSSAI , and respond 764 with an Nsmf_PDUSession_Update Response message to V-SMF 166A.

[0094] With continued reference to Fig. 7A, the V-SMF 166A may modify 780, at the V-UPF 170A, the N4 session for the accepted and / or rejected QoS flows of the PDU session. The V- SMF 166A then transmits 790, to the AMF 164, an Nsmf_PDUScssion_UpdatcSMContcxt Response, which then transmits 792 a PDU SessionEstablishment Response message to the UE 102.

[0095] Fig. 7B is a messaging diagram 700B of an example home-routed scenario in which the serving RAN 105 provides, to the V-SMF 166A, an indication of support or lack of support of PDU Set handling prior to the V-SMF 166A performing the UPF selection and configuration. Unlike the scenario 700A, here the technique does not rely on the cause value.

[0096] Rather, the AMF 164 obtains information related to the support of PDU Set handling at the RAN 105 using a non-UE-specific N2 procedure. The AMF 164 can store the RAN 105 capabilities related to supporting PDU Set handling.

[0097] During the PDU session establishment or modification request procedure, the AMF 164 indicated to the V-SMF 166A whether the RAN 105 supports PDU Set handling. The V- SMF 166A transmits, to the H-SMF 166B, an indication of whether the RAN 105 supports PDU Set handling. During a PDU session modification request procedure, the AMF 164 transmits an indication of whether the RAN 105 supports PDU Set handling to the V-SMF 166 A, which then transmits an the indication of whether the RAN 105 supports PDU Set handling message to the H-SMF 166B. After the RAN 105 transmits an N2 PDU Session response message to the AMF 164, the AMF 164 transmits an Nsmf_PDU Session_UpdateSMContext Request message to the V-SMF 166A.

[0098] The V-SMF 166A further transmits a message to the H-SMF 166B, so as to allow the H-SMF 166B to modify the N4 session to activate or deactivate PDU Set handling for the accepted PDU Set QoS flows at the H-UPF 170B. The message can be an Nsmf_PDUSession_Update Request for example.

[0099] Similar to the scenario 700A discussed above, the H-UPF 170B performs PDU Set identification and marking for the home routed roaming UE 102, and the V-PCF does not provide PDU Set based QoS in the PCC policies to the V-SMF 166A, nor does the V-SMF 166A instruct the V-UPF via the N4 session control.

[0100] As illustrated in Fig. 7B, the RAN 105 and the AMF 164 can exchange 701 RAN configuration information, and the RAN 105 provides 701, to the AMF 164, an indication of support or non- support of PDU Set handling at the RAN 105. The AMF 164 can store the RAN 105 capabilities of supporting PDU Set handling. The message exchange 701 can be implemented as a message exchange 801 , 901 , or 1001 discussed below with reference to Figs. 8-10.

[0101] Events 702 and 704 proceed as discussed above with reference to Fig. 7A. The AMF 164 then transmits 711 an Nsmf_PDU Session_CreateSMContext Request message including a PDU session ID, a DNN, an S-NSSAI, and an indication of whether the RAN 105 supports PDUSet handling (or “PDU Set Support Indication”). Events 730 and 721 proceed as discussed above with reference to Fig. 7A.

[0102] The V-SMF 166A transmits 733, to the H-SMF 166B, an Nsmf_PDUSession_Create Request message including a PDU session ID, a DNN, an S-NSSAI, and an indication of whether the RAN 105 supports PDU Set handling. Event 732 can proceed as discussed above with reference to Fig. 7A. Further, if the DNN and the S-NSSAI are associated with applications that require PDU Set based QoS, the V-SMF 166A selects a specific H-SMF capable of PDU Set handling, based on SLA between the VPLMN 101 and the HPLMN 103.

[0103] The SMF 166B performs 737 H-UPF selection and determines whether to activate PDU Set identification and marking at the selected PSA H-UPF 170B for the PDU session, based on the PCC policies from the H-PCF 160B and the indication of whether the RAN 105 supports PDU Set handling. When needed, the H-SMF 166B can contact 735 the H-PCF 160B to retrieve and / or update the PCC policies. If the PCC policies indicate a need for PDU Set handling, the H-SMF 166B instructs the PSA UPF 170B to activate PDU Set identification and marking for the PDU session corresponding to the DNN and the S-NSSAI.

[0104] For example, the H-SMF 166B can activate 737 PDU Set handling at the H-UPF 170B if the H-SMF 166B received an indication that the RAN 105 supports PDU Set handling, and the PCC policies includes PDU Set based QoS parameters for the corresponding QoS flows. Using the indication of whether the RAN 105 supports PDU Set handling, the H-SMF 166B reduces the chances the RAN 105 will reject one or more QoS flows due to the PDU Set based handling requirement, which would result in additional signaling overhead associated with requesting QoS parameters. The H-SMF 166B then transmits 736, to the V-SMF 166A, an Nsmf_PDUSession_Create Response message in response to receiving 733 the Nsmf_PDUSession_Create Request message.

[0105] If the PCC policies indicate PDU Set based QoS provisioning, and the V-SMF 166A receives an indication that the RAN 105 supports PDU Set handling, the V-SMF 166A transmits 747, to the AMF 164, an Namf_Communication_NlN2MessageTransfer message with PDU Set QoS parameters, so to enable the PDU Set handling at the RAN 105. The AMF 164 forwards 650 the NAS message to the RAN 104 in an N2 PDU session request.

[0106] Events 752, 754, and 756 proceed as discussed above with reference to Fig. 7A. The V-SMF 166A transmits 761, to the H-SMF 166B, an Nsmf_PDUSession_Update Request message including the PDU session ID, the cause, and the list of accepted / rejected QFI(s). The H-SMF 166B may retrieve UE subscription for the XRM based on the DNN and the S-NSSAI and respond 764 with an Nsmf_PDUSession_Update Response message to the V-SMF 166A. The cause value may indicate the reason why the VPLMN 101 rejected the QFI(s).

[0107] The H-SMF 166B may modify 762 the N4 session for the accepted and / or rejected QoS flows of the PDU Session at the UPF 170B. For example, the H-SMF 166B can activate PDU Set identification and marking for the accepted PDU Set based QoS flows. Events 780, 790, and 792 proceed as discussed above with reference to Fig. 7A.

[0108] Next, Fig. 7C illustrates an example home -routed scenario 700C in which the serving RAN 105 provides, to the V-SMF 166A, an indication of support or lack of support of PDU Set handling in an N2 PDU session response message. More specifically, during the PDU Session Establishment / Modification Request procedure, the AMF 165 transmits an Nsmf_PDU Session_CreateSMContext Request message to V-SMF166A, which transmits an Nsmf_PDUSession_Create Request message to the H-SMF 166B. During the PDU Session Modification Request procedure, the AMF 164 transmits an Nsmf_PDU Session_UpdateSMContext Request message to the V-SMF 166A, which transmits an Nsmf_PDUSession_Update Request message to the H-SMF 166B. After the RAN 104 transmits an indication of support (or non- support) of PDU Set handling to the AMF 164, the AMF 164 transmits an Nsmf_PDU Session_UpdateSMContext Request message, including the indication of whether the RAN 105 supports PDU Set handling, to the V-SMF 166B.

[0109] Further, the V-SMF 166 A can transmit, to the H-SMF 166B, an Nsmf_PDUSession_Update Request message with an indication of whether the RAN 105 supports PDU Set handling, to allow the H-SMF 166B to modify the N4 session to activate or deactivate PDU Set handling for the accepted PDU Set QoS flows at the H-UPF 170B, based on the received indication of support or non- support of PDU Set handling at the RAN 105, for the accepted QoS flows of the PDU Session. Similar to the scenarios 700A and 700B discussedabove, the H-UPF 170B here performs PDU Set identification and marking for the home routed roaming UE 102.

[0100] Events 702 and 704 proceed as discussed above with reference to Fig. 7B, and event 710 proceed as discussed above with reference to Fig. 7A, followed by events 714, 730, and 721 again proceed as discussed above with reference to Fig. 7B. The V-SMF 166A then transmits, to the H-SMF 166B, an Nsmf_PDUSession_Create Request message, and the H-SMF 166B may retrieve UE subscription for the XRM based on the DNN and the S-NSSAI. If the DNN and the S-NSSAI are associated with applications that require PDU Set based QoS, the V-SMF 166A selects a specific H-SMF capable of PDU Set handling, based on SLA between the VPLMN 101 and the HPLMN 103. The H-SMF 166B performs 734 H-UPF selection and determines whether to activate PDU Set Identification and marking at the PSA H-UPF 170B for the PDU Session based on the PCC policies from H-PCF 160B. When need, the H-SMF 166B can retrieve and / or update 735 the PCC policies via the H- PCF 160B.

[0110] If the PCC policies indicate PDU Set based QoS provisioning, the V-SMF 166A includes PDU Set QoS parameters in an Namf_Communication_NlN2MessageTransfer message and transmits 747, to the AMF 164, the Namf_Communication_NlN2MessageTransfer message to enable the PDU Set handling at the RAN 105. The AMF forwards 750 the NAS message in an N2 PDU Session request to the to the RAN 105.

[0111] The RAN 105 then transmits 752 a PDU Session Establishment Accept message for an AN-specific resource setup at the UE 102, to performs an RRC Reconfiguration procedure. The RAN 105 indicates 755, to the AMF 164, whether the RAN 105 accepted or rejects the PDU Set based QoS parameters for the QoS flows of the PDU Session in an N2 PDU Session Response message including an indication of support or non-support of PDU Set handling at the RAN 105. The N2 PDU Session Response message also can include a cause (e.g., non-support of PDU Set handling due to the S-NSSAI, the DNN, lack of radio resources, etc.) and a list of list of accepted and / or rejected QFI(s).

[0112] The AMF 164 transmits 757, to the V-SMF 166A, aNsmf_PDUSession_Update_SMContext Request message including the PDU Session ID, the cause, the indication of whether the RAN 105 supports PDU Set handling, and the list ofaccepted and / or rejected QoS flows. Similar to the examples above, the cause value may indicate the reason why the RAN 105 or the AMF 164 rejected certain QFI(s).

[0113] The V-SMF 166A transmits 763, to the H-SMF 166B, an Nsmf_PDUSession_Update Request message including the PDU session ID, the cause, the indication of whether the RAN 105 supports PDU Set handling, and the list of accepted and / or rejected QFIs. The H-SMF 166B may retrieve UE subscription for the XRM based on the DNN and the S-NSSAI and respond 765 with an Nsmf_PDUSession_Update Response message. Events 780, 790, and 792 proceed as discussed above with reference to Fig. 7B.

[0114] Fig. 8 is a messaging of an example scenario 801 in which a RAN node, such as the base station 104, notifies the AMF 164 of support or lack of support of PDU Set handling in a RAN Configuration Update message. Here, the RAN 105 reports the XRM Service Capability for PDU Set handling to the AMF 164 using a non-UE associated N2 procedure, to indicate to the AMF 164 whether the XRM service capabilities are activated at the RAN 105. More particularly, in the scenario of Fig. 8, the non-UE associated N2 procedure is the RAN configuration update procedure as defined in TS 38.413 for example. The RAN node 104 transmits 805 a RAN Configuration Update message to the AMF 164 and includes an indication of support or non- support of PDU Set handling at the RAN 105 (in the form of a certain information element (IE), flag, etc.). The AMF 164 responds 806 with a RAN Configuration Update Acknowledge message.

[0115] Fig. 9 illustrates an example scenario 901 in which the RAN node 104 notifies the AMF 164 of support or lack of support of PDU Set handling using a dedicated non-UE associated N2 procedure, specifically defined for reporting the RAN capabilities of supporting XRM services. The AMF 164 can transmit 907 a dedicated message, the NG-RAN XRM Service Capabilities Request message, which can be defined specifically for requesting XRM Service capabilities. The RAN node 104 can respond 908, to the AMF 164, with an NG-RAN XRM Service Capabilities Response message, which can include an indication of supported XRM services or information regarding supported Traffic Categories of the XRM services such as streaming audio, video, etc.

[0116] In the scenario 1001 depicted in Fig. 10, the RAN node 104 notifies 1009 the AMF 164 of support or lack of support of PDU Set handling using a dedicated message. The dedicated message can be a non-UE associated N2 message such as XRM Service Capabilities Configuration, defined specifically for the RAN 105 to indicate its capabilities of supporting XRM services. This message can indicate supported XRM services or information regarding supported Traffic Categories of the XRM services such as streaming audio, video, etc.

[0117] For further clarity, several example methods which a CN node can implement to support PDU sessions are discussed with reference to Figs. 11-13.

[0118] Referring first to Fig. 11, a CN node in a VPLMN (e.g., the V-SMF 166A operating in the VPLMN 101) can implement the method 1100 to a processing a request to establish a PDU session. At block 1102, the CN node receives, from a roaming UE via a serving RAN a request to establish a PDU session (see, e.g., event 702). At block 1111, the CN node determines whether the serving RAN supports PDU Set handling (see, e.g., events 754, 756, 711, 755, 757). At block 1133, the CN node provides an indication to the home CN (e.g., the SMF 166B) of the roaming UE, an indication of whether the serving RAN supports PDU Set handling (see, e.g., events 760, 733, 763).

[0119] Fig. 12 is a flow diagram of an example method 1200 for processing a request to establish a PDU session, which a CN node (e.g., the H-SMF 166B operating in the HPLMN 103) can implement. At block 1233A, the CN node receives, from the visited network, a request to create a PDU session for a roaming UE associated with the home network (see, e.g., events 731, 733, 730). Next, at block 1233B, the CN node receives, from the visited network, an indication of whether the serving RAN supports PDU Set handling (sec, e.g., events 760, 733, 763).

[0120] Finally, Fig. 13 illustrates an example method 1300 for processing an indication that the RAN does not support PDU Set handling, which can be implemented in a CN node. At block 1302, the CN nodes receives, from a UE, a request to establish a PDU session (see, e.g., event 602 or 702). At block 1305, the CN node receives, from the RAN, an indication of that the RAN does not support PDU Set handling and a list of rejected QFIs (see, e.g., events 654, 655, 754, 755, 805, 907, 1009). At block 1380, the CN node releases resources for the rejected QFIs only (see, e.g., event 680, 780).

[0121] Thus, the techniques above support PDU Set based handling in the PDU session establishment or modification procedure enable PDU Set based handling in a cellular communication network and reduce signaling overhead. In the systems discussed above, the RAN can provide the AMF with an indication of whether the NG-RAN node supports PDU Set based handling; the AMF can store the information of support of PDU Set handling by the RAN; and during the PDU session establishment modification procedure, the AMF can provide, to the SMF, an indication of support (or non-support) of PDU Set handling at the RAN in the Nsmf_PDU Session_CreateSMContext Request message or the Nsmf_PDUSession_UpdateSMContext Request message.

[0122] The procedure the RAN can use to provide the AMF with an indication of supporting PDU Set based handling at the RAN can be based on TS 38.413. If the SMF receives an indication of support of PDU Set based handling at the RAN in an Nsmf_PDUSession_CreateSMContext Request or Nsmf_PDUSession_UpdateSMContext Request message during a UE-requested PDU session establishment procedure for non-roaming and roaming with local breakout, and the PCF provisions PCC rules including PDU set based QoS parameters and Protocol Description for PDU Set handling during an SMF-initiated SM policy association modification, the SMF may determine to enable PDU Set based handling for the PDU Session of the UE based on TS 23.501 clause 5.37.5. If the SMF decides to activate PDU Set identification and marking for the PDU session, the SMF can include the protocol description in PDR and the PDU Set QoS parameters in QER based on TS 23.501 clause 5.37.5.2.

[0123] The N2 SM can include information the AMF forwards to the RAN, including one or multiple QoS profiles and the corresponding QFIs. The SMF may indicate, for each QoS flow, whether redundant transmission shall be performed by a corresponding redundant transmission indicator. For each QoS flow, the QoS profile may also include the PDU Set QoS parameters (e.g., described in TS 23.501 clause 5.7.7) to enable PDU Set based QoS handling at the RAN, when supported.

[0124] With the information of NG-RAN's support for PDU Set handling, the SMF can determine whether to activate / deactivate the PDU Set based handling, e.g. request PDU Set based QoS parameters and instruct UPF to activate PDU Set Identification and marking.

[0125] Further, when a UE initiates the PDU Session Modification procedure, the AMF can invoke a Nsmf_PDUSession_UpdateSMContext procedure with an SM Context ID, an N1 SM container including a PDU Session modification request, and an indication of support of PDU Set based handling at the RAN. The AMF later can provide, to the SMF, the stored indication of support of PDU Set based handling at the RAN to inform the SMF whether the RAN node supports PDU Set based handling. The procedure the RAN can use to provide the AMF with the indication of support of PDU Set based handling can be based on TS 38.413. If the SMF receives the indication of support of PDU Set based handling at the RAN, and the PCF provisions a PCC rule including PDU Set based QoS parameters and Protocol Description for PDU Set handling, the SMF may decide to enable PDU Set based handling for the PDU session of the UE based on TS 23.501 clause 5.37.5. Further, if the SMF determines to enable PDU Set handling for the PDU session, the SMF instructs the UPF to enable PDU Set handling by including the protocol description in PDR and the PDU Set QoS parameters in QER as described in TS 23.501 clause 5.37.5.2. If the SMF determines to enable PDU Set based handling at the RAN, the SMF includes a QoS profile with PDU Set based QoS parameters for each QoS flow as defined in TS 23.501 clause 5.7.7.

[0126] Further, it is considered that for a non-homogenous support of PDU set based handling in the RAN, the SMF may activate the PDU Set identification and marking in the PSA UPF in the following scenario: (i) 5GS registration, (ii) when the UE access type is 3GPP access, (ii) PDU Session Request type indicates as initial registration or existing registration, (iii) IP PDU Session Type, (iv) non-roaming and local breakout, and (v) a UE state transition, e.g. from CM- IDLE / CM-IDLE with Suspend to CM- CONNECTED states, and from RRC-INACTVE with CM-CONNECTED to RRC- CONNECTED with CM- CONNECTED states. For the handover procedures that result in the change of the PDU Set based handling capability in a registered access network, e.g. at NG-RAN Xn handover, N2 handover, handover of a PDU Session between 3GPP and non-3GPP access, handover between 5GS and EPS, the target NG-RANprovides, to the SMF, an indication of whether the target RAN node supports PDU Set based handling, which can be based on TS 38.413.

[0127] The N2 SM, which can include information the AMF forwards to the RAN, for each QoS flow can include PDU Set based QoS Parameters if the SMF decides to enable PDU Set based QoS Handling in RAN for the scenarios described in TS 23.501 clause 5.37.5.3. In several scenarios, if the N2 SM information includes the PDU Set Based Handling Support Indication (i.e. , an indication of support of PDU Set handling at the RAN), the SMF configures the PSA UPF to activate PDU set identification and marking for the QoS flow for the scenarios as described in TS 23.501 clause 5.37.5.3. Further, upon completion of the handover procedure, and based on the PDU Set Based Handling Support Indication and the scenarios described in TS 23.501 clause 5.37.5.3, the SMF may initiate the PDU Session modification procedure to provide PDU Set QoS parameters to the RAN and configure the PSA UPF to activate or deactivate the PDU Set identification and marking.Additional considerations

[0128] The following additional considerations apply to the foregoing discussion.

[0129] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming 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 smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0130] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code stored on non- transitory machine-readable medium) or hardware modules. A hardware module is a tangibleunit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application- specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0131] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

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

Claims

What is claimed is:

1. A method implemented in a node of a core network (CN) associated with a serving radio access network (RAN), the method comprising: receiving, from a roaming user equipment (UE) via the serving RAN, a request to establish a protocol data unit (PDU) session; determining whether the serving RAN supports PDU Set handling; and providing an indication of whether the serving RAN supports the PDU Set handling to a home CN of the roaming UE.

2. The method of claim 1 implemented in a visited Access & Mobility Management Function (V-AMF), wherein the determining includes: receiving the indication of whether the serving RAN supports the PDU Set handling from the RAN in an N2 PDU Session Response message.

3. The method of claim 2, wherein: the providing of the indication of whether the serving RAN supports the PDU Set handling to the home CN includes transmitting an Nsmf_PDUSession_Update_SMContext Request message to a visited Session Management Function (V-SMF).

4. The method of claim 1 implemented in a V-SMF, wherein the determining includes: receiving the indication of whether the serving RAN supports the PDU Set handling from a V-AMF RAN in an Nsmf_PDUSession_Update_SMContext Request message.

5. The method of claim 4, wherein: the providing of the indication of whether the serving RAN supports the PDU Set handling to the home CN includes transmitting an Nsmf_PDUSession_Update Request to a home SMF (H-SMF) of the home CN.

6. The method of claim 4 or 5, further comprising: including a list of accepted and / or rejected qualify-of-service (QoS) flow identifiers(QFIs) in the Nsmf_PDUSession_Update Request message.

7. The method of any of the preceding claims, further comprising: determining that the home CN performs PDU Set Identification and marking for the PDU session to support home routed roaming.

8. A method implemented in a node of a home core network (CN), the method comprising: receiving, from a visited CN, a request to create a protocol data unit (PDU) session for a roaming UE associated with the home CN; receiving, from the visited CN, an indication whether a serving radio access network (RAN) associated with the visited CN supports PDU Set handling; and activating or deactivating the PDU Set handling at the home CN in accordance with the indication.

9. The method of claim 8, wherein the activating or deactivating includes: in response to determining that the serving RAN supports the PDU Set handling, performingPDU Set Identification and marking for the PDU session to support home routed roaming.

10. The method of claim 8, further comprising: in response to determining that the serving RAN does not support the PDU Set handling, deactivating PDU Set Identification and marking for the PDU session for at least one quality -of- scrvicc (QoS) flow.

11. The method of any of claims 8-10, further comprising: receiving, from the CN, a list of accepted and / or rejected qualify-of-service (QoS) flow identifiers (QFIs).

12. The method of any of claims 8-11, wherein the indication from the visited CN is received in an Nsmf_PDUSession_Update Request message.

13. The method of claim 12, further comprising: transmitting, in response to the Nsmf_PDUSession_Update Request message, an Nsmf_PDUSession_Update Response message.

14. The method of any of claims 8-12, further comprising: obtaining, based on Policy and Charging Control (PCC) policies at the home CN, QoS parameters for one or more QoS flows of the PDU session.

15. A node in a core network (CN) comprising processing hardware and configured to implement a method of any of the preceding claims.

Images