PDU session with RAN support in 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; determining (1111) whether the serving RAN supports PDU set handling; and providing (1131), to the home CN of the roaming UE, an indication of whether the serving RAN supports PDU set handling.

Description

PDU sessions with RAN support in communication systems

[0001] Cross-reference to related applications

[0002] This application claims priority and benefit to U.S. Provisional Patent Application No. 63 / 519,227, filed August 11, 2023, entitled "PDU Session with NG-RAN Support for XR and Media Services in a communication System," and U.S. Provisional Patent Application No. 63 / 541,458, filed September 29, 2023, entitled "PDU Session with NG-RAN Support for XR and Media Services in a communication System." The entire contents of the two provisional applications are hereby expressly incorporated by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and more specifically to user consent for managing analytics and event monitoring operations in cellular communication networks. Background Technology

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

[0005] Generally, base stations operating a cellular radio access network (RAN) use a radio access technology (RAT) and multiple layers of a protocol stack to communicate with user equipment (UE). For example, the physical layer (PHY) of the RAT provides a transport channel to the Media Access Control (MAC) sublayer, which in turn provides a logical channel to the Radio Link Control (RLC) sublayer, which in turn provides data delivery services to the Packet Data Convergence Protocol (PDCP) sublayer. The Radio Resource Control (RRC) sublayer sits above the PDCP sublayer. The Serving Data Adaptation Protocol (SDAP) layer, situated above the PDCP layer, supports Packet Data Unit (PDU) sessions comprising one or more Quality of Service (QoS) streams. The core network (CN) uses multiple layers of the protocol stack to transmit data to the UE via the RAN.

[0006] Some services of the fifth-generation system (5GS) require high data rates and low latency transmission. An example of such services is extended reality (XR), which includes augmented reality (AR), virtual reality (VR), and mixed reality (MR). In virtual reality applications, users are typically fully immersed in a virtual environment that completely replaces the real physical environment by wearing a headset. In augmented reality, applications enhance the perception of the real environment by overlaying virtual elements onto it. Augmented reality has recently become the basis for a popular game where players find and interact with virtual creatures superimposed on a live video stream of the real world. Finally, mixed reality is an extension of AR where real and virtual elements can interact in real time.

[0007] XR games and other applications typically run on cloud platforms that include remote servers and generally do not require game consoles, high-spec CPUs, or high-spec GPUs. Cloud gaming involves streaming games similar to streaming video, with the game responding to player commands and controls in real time.

[0008] To better support high data rate, low latency services such as XR, the 3rd Generation Partnership Project (3GPP) recently proposed grouping certain Packet Data Units (PDUs) into sets of multiple PDUs. These PDUs carry the payload of a single information unit (e.g., a frame or video slice) generated at the application level. PDUs within a set can be equally important to the application level. 3GPP further proposed supporting Quality of Service (QoS) requirements based on PDU sets.

[0009] The RAN can process PDU sets based on the PDU set QoS parameters and PDU set information in the header of the General Packet Radio Service (GPRS) Tunneling Protocol (GTP)-U packets dedicated to GTP user data. This PDU set information is provided by the PDU Session Anchor (PSA) User Plane Function (UPF) operating in the core network. In the CN, the Session Management Function (SMF) performs QoS flow binding based on the service data flow, configures the UPF via the GTP-U header using rules for PDU set identification and labeling, and provides the RAN with a QoS profile including the PDU set QoS parameters through the N2 interface. More specifically, the SMF can provide the UPF with a protocol description indicating the service data flow header (e.g., RTP / SRTP) and payload type (e.g., H.264) of the media flow originating from the application server.

[0010] The PSA UPF can receive downlink (DL) PDUs from the data network (DN) via the N6 interface. When PDU set processing is applied, rules for PDU set identification are applied, and PDU set information is provided to the RAN in the GTP-U header. If the RAN receives PDU set QoS parameters and supports such parameters, the RAN enables PDU set-based QoS processing and applies the PDU set QoS parameters.

[0011] Generally, PDU set identification and marking are resource- and time-intensive operations at the UPF. However, it is unclear how the SMF can determine whether there is support or lack thereof for PDU set-based processing at the RAN, and when the SMF should instruct the UPF whether to perform PDU set identification and marking. Furthermore, when a UE roams with a Home Public Land Mobile Network (HPLMN) to a Visited Public Land Mobile Network (VPLMN), it is unclear how the Home SMF (H-SMF) should handle home-route roaming situations where the serving RAN may not always support PDU set-based processing. As a result, the CN may perform unnecessary PDU set identification and marking, which is a resource- and time-intensive operation. Summary of the Invention

[0012] An example embodiment of the technology disclosed herein is a method implemented in a node of a CN associated with a serving RAN. The method includes: receiving a request to establish a PDU session from a roaming UE via the serving RAN; determining whether the serving RAN supports PDU set processing; and providing an indication to the roaming UE's home CN of whether the serving RAN supports PDU set processing.

[0013] Another example embodiment of these technologies is a method implemented in a node of a home CN. The method includes: 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 of whether the serving RAN associated with the visited CN supports PDU set processing; and activating or deactivating the PDU set processing at the home CN according to the indication.

[0014] Another example embodiment of these technologies is a method implemented in a node of the CN. The method includes: receiving a request to establish a PDU session from the UE via the RAN; receiving from the RAN (i) an indication that the RAN does not support the handling of PDU sets and (ii) a list of rejected Quality of Service (QoS) Flow Identifiers (QFIs); and releasing resources only for the rejected QFIs.

[0015] Another example embodiment of these technologies is a node in CN that includes processing hardware and is configured to implement one of the methods described above. Attached Figure Description

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

[0017] Figure 2 is a block diagram of an example protocol stack that the UE in Figure 1 can use to communicate with the RAN in Figure 1;

[0018] Figure 3 is a service-based representation of the CN architecture, including the overall non-roaming reference architecture of the cellular communication system's policy and charging control framework;

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

[0020] Figure 5 illustrates a reference procedure for establishing and modifying PDU sessions that can be implemented in the system of Figure 1;

[0021] Figure 6A is a message passing diagram of an example scenario in which the SMF determines whether to activate PDU set processing based on the reason value provided by the RAN when accepting or rejecting a QoS flow.

[0022] Figure 6B is a message passing diagram of an example scenario in which the RAN provides the SMF with an indication of support or lack of support for PDU set disposal before the SMF performs UPF selection and configuration;

[0023] Figure 6C is a message passing diagram of an example scenario in which the RAN provides the SMF with an indication of support or lack of support for PDU set processing in the N2 PDU session response message;

[0024] Figure 7A is a message passing diagram of an example home routing scenario in which the H-SMF performs PDU set identification and marking and the V-SMF notifies the H-SMF of the reason for rejecting certain QFIs;

[0025] Figure 7B is a message passing diagram of an example home routing scenario in which the serving RAN provides the V-SMF with an indication of support or lack of support for PDU set handling before the V-SMF performs UPF selection and configuration;

[0026] Figure 7C is a message passing diagram of an example home routing scenario in which the serving RAN provides the V-SMF with an indication of support or lack of support for PDU set handling in the N2 PDU session response message;

[0027] Figure 8 is a message passing diagram of an example scenario in which the RAN node notifies the Access and Mobility Management Function (AMF) of support or lack of support for PDU set handling in the RAN configuration update message;

[0028] Figure 9 is a message passing diagram of an example scenario in which the RAN node uses a dedicated process to notify the AMF of support or lack of support for PDU set processing.

[0029] Figure 10 is a message passing diagram of an example scenario in which the RAN node uses a dedicated message to notify the AMF of support or lack of support for PDU set processing.

[0030] Figure 11 is a flowchart of an example method for handling requests to establish a PDU session, which can be implemented in the CN node of a VPLMN.

[0031] Figure 12 is a flowchart of an example method for handling requests to establish PDU sessions, which can be implemented in the CN node of HPLMMN; and

[0032] Figure 13 is a flowchart of an example method that can be implemented in a CN node for handling instructions on PDU set disposal that the RAN does not support. Detailed Implementation

[0033] In at least some of the scenarios discussed below, the UE and CN support PDU set-based data processing (or simply "PDU set processing"), where a PDU set comprises one or more PDUs carrying a payload of one information element. The apparatus can generate PDU sets at the application level. Applications can transmit PDUs of a PDU set within the same QoS stream and can use PDU set parameters such as PDU set delay budget (PSDB), PDU set error rate (PSER), and PDU set integrated processing information (PSIHI). For example, a PDU set may correspond to a frame or video slice of an XR service and a media service (collectively, "XRM service"). In some cases, the application generates and transmits multiple PDUs as a data burst within a relatively short time period, which may include one or more PDU sets.

[0034] The RAN supports PDU set processing in some cases, but not in others. The techniques discussed with reference to Figures 1 through 13 allow cellular systems to provision QoS flows based on the RAN's PDU set processing capabilities.

[0035] To consider services such as XRM, during the registration process, the AMF can determine whether a UE is authorized to use the XRM service based on XRM service capabilities and XRM service authorization. The Unified Data Management (UDM) provides this XRM service capability and XRM service authorization to the AMF as part of the UE's subscription data. The UE in the example below supports XRM service capabilities for PDU set processing.

[0036] Referring first to Figure 1, the example wireless communication system 100 can implement one or more of the techniques disclosed herein for handling PDU sessions requiring PDU set processing. Roaming UE 102 can access VPLMN 101 via the serving RAN 105 associated with VPLMN 101. HPLMN 103 maintains the subscriber data of UE 102, i.e., as the home PLMN of UE 102.

[0037] Serving RAN 105 includes base station 104 providing service in cell 124 and base station 106 providing service in cell 126. When base station 104 is implemented as a gNB, cell 124 is an NR cell. When base station 124 is implemented as an ng-eNB, cell 124 is an Evolved Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, when base station 106 is implemented as a gNB, cell 126 is an NR cell, and when base station 126 is implemented as 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 different RNAs. Cells 124 and 126 may partially overlap, allowing UE 102 to select, reselect, or switch from one cell to another. Generally, RAN 105 may include any number of base stations, and each base station may cover one, two, three, or any other suitable number of cells. UE 102 may support at least a 5G NR (or simply "NR") air interface to communicate with base stations 104 and 106. Each of base stations 104 and 106 may be connected to CN 110 of VPLMN 101 via a suitable 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).

[0038] VPLMN 101 includes AMF 164, SMF 166A, and UPF170A, which operate as V-AMF, V-SMF, and V-UPF, respectively. HPLMN 103 includes SMF 166B, and UPF170A, UDM 153, and Policy Control Function (PCF) 360, which operate as H-SMF, H-UPF, H-UDM, and H-PCF, respectively. Example implementations of VPLMN 101 and HPLMN 103 are discussed in more detail with reference to Figures 3 and 4.

[0039] Although not depicted in Figure 1 to avoid clutter, VPLMN 101 and HPLMN 103 may include processing hardware, such as one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable storage for instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include dedicated processing units. The processing hardware may be configured to implement the techniques disclosed herein for supporting PDU sessions.

[0040] Each of base stations 104 and 106 may be equipped with processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable storage 134 (not shown to avoid confusion) storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware may include dedicated processing units. Base stations 104 and 105 also include transceivers for communicating with a UE, such as UE 102, via a radio interface.

[0041] UE 102 is equipped with processing hardware 130A, which may include one or more general-purpose processors such as a CPU and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or dedicated processing units. UE 102 also includes a transceiver 132A for communicating with RAN 105 via a radio interface.

[0042] In addition, VPLMN 101 can implement PDU set controller 180A (e.g., in V-AMF 164 and / or V-SMF166A), HPLMN 103 can implement PDU set controller 180B (e.g., in VH-SMF 166B), and UE 102 can implement PDU set controller 180A.

[0043] Figure 2 illustrates a simplified example protocol stack 200, which UE 102 can use to communicate with an eNB / ng-eNB 230 or gNB 232 (e.g., one or more of base stations 104 and 106). In the example stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data delivery services to the Serving Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer (not shown in Figure 2). In some implementations, UE102A, 102B, or 102C supports both the EUTRA and NR stacks as shown in Figure 2 to support handover between EUTRA and NR base stations and / or support DC over the EUTRA and NR interfaces. Further, as shown in Figure 2, UE102A or 102B can support layering of NR PDCP 210 over EUTRA RLC 206A, and layering of SDAP sublayer 212 over NR PDCP sublayer 210.

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

[0045] For example, on the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide Signal Transmission Radio Bearer (SRB) or RRC sublayer (not shown in Figure 2) to exchange RRC messages or Non-Access Stratum (NAS) messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide Data Radio Bearer (DRB) to support data exchange. The data exchanged on NRPDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

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

[0047] The PCC framework in Architecture 300 includes Unified Data Repository (UDR) 352, Network Open Function (NEF) 354, Network Data Analysis Function (NWDAF) 356, Application Function (AF) 358, PCF 360, Charging Function (CHF) 362, AMF 364, SMF 366, and UPF 370.

[0048] The AMF 364 is typically configured to manage the registration, connectivity, and mobility of UEs (such as UE 102A or 102B) and to provide the transmission of session management (SM) messages between 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 typically configured to manage sessions, assign IP addresses to UEs, and provide downlink (DL) notifications. In some implementations, the SMF 366 also includes the following functionalities for PIN services: providing non-3GPP QoS assistance information per QoS flow to UEs (e.g., PEGCs), and supporting IP address allocation for UEs and PDR configuration with a packet filter set for PIN to UPF for frame routing based on PIN group information from the UDM 353.

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

[0050] UPF 370 is typically configured to handle packet routing and forwarding. Additionally, NEF 354 is configured to open network capabilities and services to authorized third-party applications. As shown in Figure 3, UPF 370 can provide the UE with access to data network 330, and conversely, allow one or more application servers in data network 330 to establish PDU sessions with UE 102.

[0051] In some deployments, the AF 358 operates either within a trusted domain or outside a trusted domain—that is, in an untrusted domain. A trusted domain is typically located within a CN and includes components such as UDM 353, UDR 352, PCF 360, AMF 364, SMF 366, and UPF 370. Generally, an AF operating outside a trusted domain (such as by an authorized third-party entity) can only access the CN's network functions via NEF 354, while an AF operating within a trusted domain can directly access at least some of the CN's network functions, or in some deployments, can access these functions via NEF 354.

[0052] Figure 4 is a reference-point-based representation of the example CN architecture 400. In Figure 4, the non-roaming reference architecture of the PCC framework is shown as blocks and connections with solid lines, while components and connections outside the PCC framework are shown with dashed lines.

[0053] The communication systems shown in Figures 1 to 4 may include additional, fewer, and / or alternative means or functions, and may be configured to perform additional, fewer, or alternative actions, including the functions / actions described herein.

[0054] Next, Figure 5 illustrates a reference scenario 500 in which a UE establishes and modifies a PDU session, which can be implemented in the system of Figure 1. During the registration process, the AMF can determine 502 whether the UE is authorized to use XRM services based on the XRM service capabilities of UE 102 and the XRM service authorization included in the subscription data received from the UDM (e.g., as specified in Clause 5.7 of TS 23.501). After successful registration, UE 102 requests 504 the PDU session establishment procedure, and the RAN 105, capable of XRM services, can perform PDU set processing on the QoS flow in the PDU session based on the XRM service authorization and information received from SMF 366 via the N2 message and the GTP-U header received from UPF 370 via the N3 interface. The PDU session establishment procedure can be implemented, for example, as described in Clause 4.3.2.2 of TS 23.502. UE 102 can repeat the 504 PDU session establishment procedure for multiple PDU sessions associated with the same or different Data Network Names (DNNs) and Single Network Slice Selection Auxiliary Information (S-NSSAI). UE 102 or the network can initiate the 506 PDU session modification procedure for existing PDU sessions. For example, the PDU session modification procedure can be implemented as described in Clauses 4.3.3.2 and 4.3.3.3 of TS23.502.

[0055] When the PLMN provides homogeneous RAN support for PDU set processing, the Reference 500 procedure may include modifications briefly discussed below to support PDU set-based QoS. For example, the PCF 360 may provide PCC rules for application service flows as defined in Clause 6.1.3.27.4 of TS 23.503. Application service flows may include PDU set QoS parameters (e.g., PSER, PSDB, and PSIHI) and a protocol description. The SMF 366 may determine the QoS profile for the QoS flow based on the received PCC rules or pre-configuration. The PSA UPF 360 may use the protocol description and the received Packet Detection Rules (PDR) to identify PDUs belonging to the PDU set. Furthermore, the PSA UPF 360 may use a GTP-U header that tags PDU set information as described in Clause 5.37.5.2 of TS 23.501. Additionally, the PSA UPF 360 may generate PDU set-based parameters based on QoS Enforcement Rules (QER).

[0056] Next, several methods for non-roaming and local breakout scenarios are considered in conjunction with Figures 6A to 6C, followed by a discussion of roaming scenarios with reference to Figures 7A to 7C. Generally, similar events in Figures 6A to 6C and Figures 7A to 7C are labeled with similar reference numerals sharing two least significant figures, 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.

[0057] As shown in Figure 6A, RAN 105 indicates whether or not PDU set processing is supported. Specifically, RAN 105 provides the appropriate reason value for the rejected QFI to SMF 366 via AMF 364. SMF 366 determines whether PDU set processing is enabled at RAN 105 (if supported) by requesting the PDU set QoS parameters for one or more QoS flows used for the PDU session.

[0058] UE 102 first sends a 602 PDU session establishment request message to AMF 364, which includes the PDU session ID, DNN, and S-NSSAI. The DNN and S-NSSAI can be associated with a specific XRM service.

[0059] AMF 364 then performs a 604 SMF selection based on the DNN and S-NSSAI. If the DNN and S-NSSAI are associated with an application that requires QoS based on the PDU set, AMF 364 can select a specific SMF capable of PDU set processing, such as SMF366. Next, AMF 364 sends a 610 Nsmf_PDU Session_CreateSMContext request message to the selected SMF 366, including the PDU session ID, DNN, and S-NSSAI.

[0060] SMF 366 can retrieve subscription data related to XRM (612) for UE 102 based on DNN and S-NSSAI. In response to receiving a 610 Nsmf_PDU Session_CreateSMContext request message, SMF 366 sends a 614 Nsmf_PDU Session_CreateSMContext response message to AMF 364. Then, SMF 366 uses the user credentials provided by UE 102 for the connection to DN330 to perform the PDU session authentication / authorization process (620) between DN330 and DN330.

[0061] Furthermore, SMF 366 performs UPF selection at 644 and determines, based on PCC policy information from PCF 360, whether to activate PDU set identifiers and tags at PSA UPF 370 for the PDU sessions associated with DNN and S-NSSAI. To this end, and if necessary, SMF 366 queries PCF 360 at 645 to retrieve and / or update the PCC policy. Although Figure 6A shows event 645 occurring after event 644, it should be understood that events 644 may overlap at least partially in time. When SMF 366 determines that the PCC policy requires PDU set disposal, SMF 366 instructs PSA UPF 360 to activate PDU set identifiers and tags for the PDU sessions corresponding to DNN and S-NSSAI.

[0062] Referring again to Figure 6A, if SMF 366 determines that PDU set processing should be activated for the PDU session of UE 102, SMF 366 sends a 647 Namf_Communication_N1N2MessageTransfer message containing PDU set QoS parameters to AMF 364 to enable (or activate) PDU set processing at RAN 105. AMF 364 forwards a 650 NAS message to RAN 105 in the N2 PDU session request message.

[0063] RAN 105 then performs the RRC reconfiguration procedure for UE 102 (652). Specifically, RAN 105 sends a PDU session establishment accept message (652) for AN-specific resource settings at UE 102. RAN 105 also instructs AMF 364 (654) whether RAN 105 accepts or rejects QoS parameters based on the PDU set for the PDU session. More specifically, RAN 105 sends an N2 PDU session response (654) to AMF 364, including the PDU session ID, reason, and a list of accepted and / or rejected QFI messages. Each QFI is a QoS flow identifier for the corresponding QoS flow. RAN 105 may include appropriate reason values ​​for the rejected QFIs (654), which may be due to lack of support for the PDU set handling at RAN 105 (due to S-NSSAI, DNN, lack of radio resources, etc.).

[0064] AMF 364 then sends an Nsmf_PDUSession_Update_SMContext request message (656) to SMF 366, which includes the PDU session ID, reason, and a list of accepted and / or rejected QFIs. SMF 366 can modify (680) the N4 session for accepted and / or rejected QoS flows within the PDU session. Modification (680) can be applied to UPF 370. For example, based on the reason value, SMF 366 can determine whether to deactivate PDU set processing for the PDU session at UPF 370, or only deactivate the PDU set identifier and tag for rejected QoS flows. If RAN 105 rejects a QoS flow, SMF 366 can instruct UPF 370 to release the rejected QoS flow, but maintain PDU set processing for accepted QoS flows. Requesting QoS parameters at RAN 105 without PDU set processing may incur additional signaling overhead.

[0065] SMF 366 sends a 690 Nsmf_PDUSession_UpdateSMContext response message to AMF 364, which then sends a 692 PDU session establishment response message to UE 102.

[0066] Next, Figure 6B illustrates an example scenario 600B in which RAN 105 provides an indication of support or lack of support for PDU set handling to SMF 366 via AMF 158 before SMF performs UPF selection and configuration. This approach is also applicable to non-roaming and localized scenarios.

[0067] Here, the SMF 366 requests the PDU set QoS parameters for one or more QoS flows used in the PDU session and uses the PCC policy and support indication to determine whether to request activation of PDU set disposition at RAN 105. The AMF 364 uses a non-UE-specific N2 procedure to obtain information related to support for PDU set disposition at RAN 105. The AMF 364 then stores the RAN 105 capabilities related to supporting PDU set disposition.

[0068] In scenario 600B, RAN 105 also provides support indications to SMF 366 via AMF 364. Specifically, during the PDU session establishment request process, AMF 364 provides indications for supporting PDU set processing at RAN 105, as discussed below. During the PDU session modification request process, AMF 364 may send indications for supporting PDU set processing at RAN 105 to SMF 366. SMF 366 can determine whether to activate or deactivate PDU set processing at UPF 370 based on the indications of support (or non-support) for PDU set processing at RAN 105.

[0069] More specifically, RAN 105 and AMF 364 can exchange RAN configuration information 601, and RAN 105 provides AMF 364 with an indication 601 of whether it supports or does not support PDU set processing at RAN 105. AMF 364 can store the capability of RAN 105 to support PDU set processing. Message exchange 601 can be implemented as message exchange 801, 901, or 1001 discussed below with reference to Figures 8A through 10.

[0070] Then, UE 102 sends a 602 PDU session establishment request message to AMF 364, which includes the PDU session ID, DNN, and S-NSSAI, as discussed above with reference to Figure 6A. AMF 364 then performs a 606 SMF selection based on the DNN and S-NSSAI, as in scenario 600A.

[0071] The AMF 364 sends an Nsmf_PDU Session_CreateSMContext request message (different from transmission 610 in Figure 6A) to the SMF 366, which includes the PDU session ID, DNN, S-NSSAI, and an indication of whether RAN 105 supports PDU set handling. In some implementations, the AMF 364 only provides the 611 indication of whether RAN 105 supports PDU set handling if the DNN and S-NSSAI are associated with an application requiring PDU set-based QoS. Furthermore, the AMF 364 may store an indication of support (or lack thereof) for PDU set handling at RAN 105, which may have a RAN ID, such as the global RAN node ID associated with the N2 interface.

[0072] Events 612, 614, and 620 can be performed as discussed above with reference to Figure 6A. Then, SMF 366 performs 646 UPF selection and determines, based on PCC policy information from PCF 360, whether to activate the PDU set identifier and tag at PSA UPF 370 for the PDU session associated with DNN and S-NSSAI. For this purpose, and if necessary, SMF 366 queries PCF 360 at 645 to retrieve and / or update the PCC policy. In addition to considering the PCC policy, SMF 366 may also consider 646 the indication received from AMF 364 at 611 regarding whether RAN 105 supports PDU set disposal. Using the indication of whether RAN 105 supports PDU set disposal, SMF 366 reduces the likelihood that RAN 105 will reject one or more QoS flows due to PDU set-based disposal requirements, which would result in additional signaling overhead associated with requested QoS parameters.

[0073] Events 645, 647, 650, 652, 654, 656, 690, and 692 can be performed as discussed with reference to Figure 6A. Similarly to Figure 6A, the SMF 366 can modify session 680 (N4) for accepted and / or rejected QoS flows of the PDU session. In some implementations, the SMF 366 activates PDU set identification and tagging for accepted PDU-based QoS flows.

[0074] Figure 6C illustrates an example scenario 600C where the RAN provides an indication to the SMF in the N2 PDU session response message regarding support for or lack of support for PDU set handling. RAN 105, AMF 364, and SMF 366 perform an enhanced PDU session establishment or modification procedure, which includes RAN 105 indicating support for or lack thereof for PDU set handling. Specifically, SMF 366 may determine whether to enable PDU set handling for the UE 102's PDU session based on the conditions discussed above with reference to Figure 6B. If SMF 366 determines that PDU set handling is enabled, SMF 366 requests PDU set QoS parameters for one or more QoS flows used in the PDU session.

[0075] In scenario 600C, RAN 105 provides an indication of whether or not it supports PDU set processing to SMF 366 via AMF 364. During the PDU session establishment request process, and after RAN 105 sends an N2 PDU session response to AMF 364 including an indication of whether RAN 105 supports PDU set processing, AMF 364 further sends an Nsmf_PDU Session_CreateSMContext request to SMF 366 including an indication of whether RAN 105 supports PDU set processing. During the PDU session modification request process, and after RAN 105 sends an N2 PDU session response message to AMF 364 including an indication of whether RAN 105 supports PDU set processing, AMF 364 further sends an Nsmf_PDU Session_UpdateSMContext request message to SMF 366 including an indication of whether RAN 105 supports PDU set processing. SMF 366 can further determine whether to modify the N4 session to activate or deactivate PDU set processing after receiving an indication of whether RAN 105 supports PDU set processing and after receiving accepted and / or rejected QoS flows.

[0076] Specifically referring to Figure 6C, events 602 and 604 proceed as discussed with reference to Figure 6B; event 610 proceeds as discussed with reference to Figure 6A; events 612, 614 and 620 proceed as discussed with reference to Figure 6B; and events 644, 645, 647, 650 and 652 proceed as discussed with reference to Figure 6A.

[0077] RAN 105 indicates whether it accepts or rejects QoS parameters based on the PDU set for a QoS flow used in a PDU session. Specifically, RAN 105 may send a 655 N2 PDU session response message to AMF 364, which includes the PDU session ID, reason, a list of accepted and / or rejected QFIs, and an indication of whether RAN 105 supports PDU set handling. Similar to the example above, the QFI identifies a specific QoS flow.

[0078] When RAN 105 activates PDU set processing for an accepted QFI, RAN 105 includes an indication of support for PDU set processing in its response message, which RAN 105 sends to SMF 366 via AMF 364. Additionally, RAN 105 may include an appropriate reason value (if any) for the rejected QFI, such as a lack of support for PDU set processing due to S-NSSAI, DNN, lack of radio resources, etc.

[0079] AMF 364 sends a 657 Nsmf_PDUSession_Update_SMContext request message to SMF 366. The PDUSession_Update_SMContext request message may include the PDU session ID, the reason, a list of accepted and / or rejected QFIs, and an indication of whether RAN 105 supports PDU set handling.

[0080] Then, SMF 366 modifies session 681 N4 for accepted and / or rejected QoS flows of the PDU session. For example, if SMF 366 previously activated PDU set processing at UPF 370, and RAN 105 does not provide an indication of support for PDU set processing (or provides an indication of non-support for PDU set processing), SMF 366 can instruct UPF 370 to deactivate the PDU set identifier and tag for accepted QoS flows. In this case, RAN 105 does not activate PDU set processing at RAN 105, and accepted QoS flows can ignore QoS parameters based on the PDU set. As another example, if SMF 366 previously activated PDU set processing at UPF 370, and RAN 105 provides an indication of support for PDU set processing (or does not provide an indication of non-support for PDU set processing), SMF 366 can instruct UPF 370 to modify the N4 session to release resources only for rejected QFIs. Events 690 and 692 can proceed as discussed with reference to Figure 6A or Figure 6B.

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

[0082] RAN 105, via AMF 158, indicates the appropriate reason value for the rejected QFI to V-SMF 166A. V-SMF 166A determines whether to enable PDU set handling at RAN 105 (if supported) by requesting the PDU set QoS parameters for the QoS flows in the PDU session. For PDU session establishment or modification request procedures, AMF 164 sends an Nsmf_PDUSession_CreateSMContext request message to V-SMF 166A, and V-SMF 166A subsequently sends an Nsmf_PDUSession_Create request message to H-SMF 166B. For PDU session modification request procedures, AMF 164 sends an Nsmf_PDU Session_UpdateSMContext request message to V-SMF 166A, and V-SMF 166A sends an Nsmf_PDUSession_Update request message to H-SMF 166B. After RAN 105 sends an N2 PDU session response message to AMF 164, AMF164 further sends an Nsmf_PDU Session_UpdateSMContext request message to V-SMF 166A.

[0083] As shown in Figure 7A, V-SMF 166A can notify H-SMF 166B in a manner that allows H-SMF 166B to modify the N4 session to activate or deactivate PDU set handling for accepted PDU set QoS flows at H-UPF 170B. To this end, V-SMF 166A can send an Nsmf_PDUSession_Update request message with the PDU session ID, a list of accepted and / or rejected QFIs, and a reason value, and H-UPF 170B can activate or deactivate PDU set handling based on the reason value of the rejected QoS flows in the received PDU session.

[0084] According to this method, H-UPF 170B performs PDU set identification and marking for the home route UE. Therefore, V-PCF in VPLMN101 does not provide PDU set-based QoS in the PCC policy to V-SMF 166A, and V-SMF 166A does not instruct V-UPF 170A via N4 session control (e.g., by including protocol description in PDR and PDU set-based QoS in QER).

[0085] Specifically, as shown in Figure 7A, UE 102 sends a 702 PDU session establishment request message to AMF 164, which includes the PDU session ID, DNN, and S-NSSAI. The DNN and S-NSSAI can be associated with a specific XRM service.

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

[0087] AMF 164 then sends a 710 Nsmf_PDU Session_CreateSMContext request message to V-SMF 166A. In response to receiving the 710 Nsmf_PDU Session_CreateSMContext request message, V-SMF 166A sends a 714 Nsmf_PDU Session_CreateSMContext response message to AMF164.

[0088] The V-SMF 166A performs the 730 V-UPF selection based on the local PCC configuration for roaming users or the PCC policy from the V-PCF in VPLMN 101. The V-SMF 166A configures the 730 PDR and QER for the V-UPF 170A via N4 session control for handling user plane traffic, where the PDR is used to detect specific QoS. For home-roaming UEs such as UE 102, the H-UPF 170B performs PDU set identification and labeling. As discussed above, the V-PCF does not provide the V-SMF 166A with PDU set-based QoS in the PCC policy, and the V-SMF 166A does not instruct the V-UPF via N4 session control.

[0089] V-SMF 166A uses the user credential information provided by UE 102 for DN 330 to perform PDU session authentication and / or authorization between 712 and DN 330.

[0090] V-SMF 166A sends a 731 Nsmf_PDUSession_Create request message to H-SMF 166B. H-SMF 166B can retrieve 732 XRM-related subscription information for UE 102 from H-UDM 153 based on the received DNN and S-NSSAI. If the DNN and S-NSSAI are associated with an application requiring QoS based on PDU sets, V-SMF 166A selects a specific H-SMF capable of PDU set processing based on the SLA between VPLMN 101 and HPLMMN 103.

[0091] The H-SMF 166B performs 734 H-UPF selection and, based on the PCC policy from the H-PCF 160B, determines whether to activate the PDU set identifier and tag at the selected PSA H-UPF 170B for the PDU session. When needed, the H-SMF 166B can contact 735 H-PCF 160B to retrieve and / or update the PCC policy. If the PCC policy indicates that PDU set disposal is required, the H-SMF 166B instructs the PSA UPF 170B to activate the PDU set identifier and tag for the PDU sessions corresponding to the DNN and S-NSSAI. In response to receiving the 731 Nsmf_PDUSession_Create request message, the H-SMF 166B sends a 736 Nsmf_PDUSession_Create response message to the V-SMF 166A.

[0092] If V-SMF 166A determines that PDU set processing for the PDU session of UE 102 is enabled, V-SMF 166A sends a 747 Namf_Communication_N1N2MessageTransfer message with PDU set QoS parameters to AMF 164 to enable PDU set processing at RAN 105. AMF 164 forwards a 750 NAS message to RAN 105 in the N2 PDU session request.

[0093] RAN 105 then performs the 752 RRC reconfiguration procedure for UE 102. Specifically, RAN 105 sends a 752 PDU session establishment accept message for AN-specific resource settings at UE 102. RAN 105 also indicates to AMF 364 754 the QoS parameters based on the PDU set for accepting and / or rejecting QoS flows used for the PDU session. More specifically, RAN 105 sends an N2 PDU session response to AMF 164 including the PDU session ID, reason, and a list of accepted and / or rejected QFI messages. RAN 105 may include the appropriate reason value for the rejected QFI, which could be a lack of support for PDU set handling at RAN 105 (due to S-NSSAI, DNN, lack of radio resources, etc.).

[0094] AMF 358 then sends an Nsmf_PDUSession_Update_SMContext request message (value 756) to V-SMF 166A, including the PDU session ID, reason, and a list of accepted and / or rejected QFIs. The reason value indicates the reason why RAN 105 rejected the corresponding QFI.

[0095] The V-SMF 166A sends an Nsmf_PDUSession_Update request (760) to the H-SMF 166B, including the PDU session ID, reason, and a list of accepted and / or rejected QFIs. The Nsmf_PDUSession_Update request may also include the N2 SM context. The H-SMF 166B can use the DNN and S-NSSAI to retrieve the UE subscription information of the XRM (762) and respond to the V-SMF 166A with an Nsmf_PDUSession_Update response message (764).

[0096] Referring again to Figure 7A, V-SMF 166A can modify the 780 N4 session at V-UPF 170A for accepted and / or rejected QoS flows of the PDU session. Then, V-SMF 166A sends a 790 Nsmf_PDUSession_UpdateSMContext response to AMF 164, which then sends a 792 PDU session establishment response message to UE 102.

[0097] Figure 7B is a message passing diagram 700B of an example home routing scenario where the serving RAN 105 provides V-SMF 166A with an indication of support or lack thereof for PDU set disposal before V-SMF 166A performs UPF selection and configuration. Unlike scenario 700A, this technique does not rely on cause values.

[0098] Instead, AMF 164 uses a non-UE-specific N2 procedure to obtain information related to support for PDU set disposal at RAN 105. AMF 164 can store RAN 105 capabilities related to supporting PDU set disposal.

[0099] During the PDU session establishment or modification request process, AMF 164 indicates to V-SMF 166A whether RAN 105 supports PDU set processing. V-SMF 166A sends this indication to H-SMF 166B. During the PDU session modification request process, AMF 164 sends this indication to V-SMF 166A, which then sends an indication to H-SMF 166B regarding whether RAN 105 supports PDU set processing. After RAN 105 sends an N2 PDU session response message to AMF 164, AMF 164 sends an Nsmf_PDU Session_UpdateSMContext request message to V-SMF 166A.

[0100] V-SMF 166A further sends a message to H-SMF 166B to allow H-SMF 166B to modify the N4 session to activate or deactivate the PDU set disposal for the accepted PDU set QoS flow at H-UPF 170B. This message may be, for example, an Nsmf_PDUSession_Update request.

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

[0102] As shown in Figure 7B, RAN 105 and AMF 164 can exchange RAN configuration information, and RAN 105 provides AMF 164 with an indication of whether it supports or does not support PDU set processing at RAN 105. AMF 164 can store the capability of RAN 105 to support PDU set processing. Message exchange 701 can be implemented as message exchange 801, 901, or 1001 discussed below with reference to Figures 8A through 10.

[0103] Events 702 and 704 proceed as discussed above with reference to Figure 7A. AMF 164 then sends an Nsmf_PDU Session_CreateSMContext request message 711, including the PDU session ID, DNN, S-NSSAI, and an indication (or "PDU set support indication") of whether RAN 105 supports PDU set processing. Events 730 and 721 proceed as discussed above with reference to Figure 7A.

[0104] V-SMF 166A sends an Nsmf_PDUSession_Create request message (733) to H-SMF 166B, including the PDU session ID, DNN, S-NSSAI, and an indication of whether RAN 105 supports PDU set processing. Event 732 can proceed as discussed above with reference to Figure 7A. Further, if the DNN and S-NSSAI are associated with an application requiring PDU set-based QoS, V-SMF 166A selects the specific H-SMF capable of PDU set processing based on the SLA between VPLMN 101 and HPLMMN 103.

[0105] The SMF 166B performs the 737 H-UPF selection and, based on the PCC policy from the H-PCF 160B and the indication to RAN 105 regarding whether PDU set handling is supported, determines whether to activate the PDU set identifier and tag at the selected PSA H-UPF 170B for the PDU session. When necessary, the H-SMF 166B can contact the 735 H-PCF 160B to retrieve and / or update the PCC policy. If the PCC policy indicates that PDU set handling is required, the H-SMF 166B instructs the PSA UPF 170B to activate the PDU set identifier and tag for the PDU session corresponding to the DNN and S-NSSAI.

[0106] For example, if H-SMF 166B receives an indication from RAN 105 that it supports PDU set handling, and the PCC policy includes PDU set-based QoS parameters for the corresponding QoS flow, H-SMF 166B can activate PDU set handling at 737 H-UPF 170B. By indicating whether RAN 105 supports PDU set handling, H-SMF 166B reduces the likelihood that RAN 105 will reject one or more QoS flows due to PDU set-based handling requirements, which would result in additional signaling overhead associated with the requested QoS parameters. H-SMF 166B then sends a 736 Nsmf_PDUSession_Create response message to V-SMF166A in response to receiving a 733 Nsmf_PDUSession_Create request message.

[0107] If the PCC policy indicates QoS provisioning based on PDU sets, and V-SMF 166A receives an indication from RAN 105 that it supports PDU set handling, then V-SMF 166A sends a 747 Namf_Communication_N1N2MessageTransfer message with PDU set QoS parameters to AMF 164 to enable PDU set handling at RAN 105. AMF 164 forwards the NAS message 650 to RAN 104 in the N2 PDU session request.

[0108] Events 752, 754, and 756 proceed as discussed above with reference to Figure 7A. V-SMF 166A sends an Nsmf_PDUSession_Update request message 761 to H-SMF 166B, including the PDU session ID, reason, and a list of accepted / rejected QFIs. H-SMF 166B can retrieve the UE subscriptions for the XRM based on the DNN and S-NSSAI, and responds to V-SMF 166A with an Nsmf_PDUSession_Update response message 764. The reason value indicates the reason why VPLMN 101 rejected the QFI.

[0109] The H-SMF 166B can modify the 762 N4 session for accepted and / or rejected QoS flows of the PDU session at the UPF 170B. For example, the H-SMF 166B can activate the PDU set identifier and tag for accepted PDU set-based QoS flows. Events 780, 790, and 792 are performed as discussed above with reference to Figure 7A.

[0110] Next, Figure 7C illustrates an example home routing scenario 700C in which the serving RAN 105 provides an indication to V-SMF 166A in the N2 PDU session response message that it supports or lacks support for PDU set handling. More specifically, during the PDU session establishment / modification request process, AMF 165 sends an Nsmf_PDU Session_CreateSMContext request message to V-SMF 166A, which in turn sends an Nsmf_PDUSession_Create request message to H-SMF 166B. During the PDU session modification request process, AMF 164 sends an Nsmf_PDU Session_UpdateSMContext request message to V-SMF 166A, which in turn sends an Nsmf_PDUSession_Update request message to H-SMF 166B. After RAN 104 sends an indication to AMF 164 regarding support (or lack thereof) for PDU set processing, AMF 164 sends an Nsmf_PDU Session_UpdateSMContext request message to V-SMF 166B, which includes an indication of whether RAN 105 supports PDU set processing.

[0111] Furthermore, V-SMF 166A can send an Nsmf_PDUSession_Update request message to H-SMF 166B, indicating whether RAN 105 supports PDU set handling. This allows H-SMF 166B to modify the N4 session to activate or deactivate PDU set handling for accepted QoS flows at H-UPF 170B, based on the received indication of support or non-support for PDU set handling at RAN 105. Similar to scenarios 700A and 700B discussed above, H-UPF 170B here performs PDU set identification and marking for home route roaming UE 102.

[0112] Events 702 and 704 proceed as discussed above with reference to Figure 7B, and event 710 proceeds as discussed above with reference to Figure 7A. Subsequently, events 714, 730, and 721 again proceed as discussed above with reference to Figure 7B. Then, V-SMF 166A sends an Nsmf_PDUSession_Create request message to H-SMF 166B, and H-SMF 166B can retrieve UE subscriptions for XRM based on DNN and S-NSSAI. If DNN and S-NSSAI are associated with applications requiring QoS based on PDU sets, V-SMF 166A selects a specific H-SMF capable of PDU set processing based on the SLA between VPLMN 101 and HPLMN 103. The H-SMF 166B performs the 734 H-UPF selection and determines whether to activate the PDU set identifier and tag at the PSA H-UPF 170B for the PDU session based on the PCC policy from the H-PCF 160B. When needed, the H-SMF 166B can retrieve and / or update the 735 PCC policy via the H-PCF 160B.

[0113] If the PCC policy indicates QoS provisioning based on PDU sets, the V-SMF 166A includes the PDU set QoS parameters in the Namf_Communication_N1N2MessageTransfer message and sends a 747 Namf_Communication_N1N2MessageTransfer message to AMF 164 to enable PDU set processing at RAN 105. AMF forwards the NAS message 750 to RAN 105 in the N2 PDU session request.

[0114] RAN 105 then sends a 752 PDU session establishment accept message for AN-specific resource settings at UE 102 to perform the RRC reconfiguration procedure. In the N2 PDU session response message, RAN 105 indicates to AMF 164 whether it accepts or rejects QoS parameters based on the PDU set for the QoS flow used in the PDU session. This N2 PDU session response message includes an indication of support or non-support for PDU set handling at RAN 105. The N2 PDU session response message may also include a reason (e.g., PDU set handling is not supported due to S-NSSAI, DNN, lack of radio resources, etc.) and a list of accepted / rejected QFIs.

[0115] AMF 164 sends an Nsmf_PDUSession_Update_SMContext request message (757) to V-SMF 166A, which includes the PDU session ID, reason, indication of whether RAN 105 supports PDU set handling, and a list of accepted and / or rejected QoS flows. Similar to the example above, the reason value can indicate why RAN 105 or AMF 164 rejected certain QFIs.

[0116] V-SMF 166A sends an Nsmf_PDUSession_Update request message 763 to H-SMF 166B, including the PDU session ID, reason, indication of whether RAN 105 supports PDU set handling, and a list of accepted and / or rejected QFIs. H-SMF 166B can retrieve the UE subscription of XRM based on DNN and S-NSSAI, and respond with an Nsmf_PDUSession_Update response message 765. Events 780, 790, and 792 proceed as discussed above with reference to Figure 7B.

[0117] Figure 8 illustrates a sample scenario 801 in which a RAN node, such as base station 104, notifies AMF 164 of support or lack thereof for PDU set handling in a RAN configuration update message. Here, RAN 105 uses a non-UE-associated N2 procedure to report XRM service capabilities for PDU set handling to AMF 164, indicating to AMF 164 whether XRM service capabilities are activated at RAN 105. More specifically, in the scenario of Figure 8, the non-UE-associated N2 procedure is, for example, the RAN configuration update procedure defined in TS 38.413. RAN node 104 sends an 805 RAN configuration update message to AMF 164, including an indication of support or lack thereof for PDU set handling at RAN 105 (in the form of a specific information element (IE), flags, etc.). AMF 164 responds with a RAN configuration update confirmation message 806.

[0118] Figure 9 illustrates example scenario 901, where RAN node 104 uses a dedicated non-UE associated N2 procedure to notify AMF 164 of support or lack thereof for PDU set disposal. This dedicated non-UE associated N2 procedure is specifically defined to report RAN capabilities supporting XRM services. AMF 164 can send a dedicated message 907—an NG-RAN XRM service capability request message—which can be specifically defined to request XRM service capabilities. RAN node 104 can respond to AMF 164 908 using an NG-RAN XRM service capability response message, which may include indications of supported XRM services or information about the service category of the supported XRM services—such as streaming audio, video, etc.

[0119] In scenario 1001 depicted in Figure 10, RAN node 104 uses a dedicated message to notify AMF 164 1009 of support or lack thereof for PDU set processing. The dedicated message can be a non-UE-associated N2 message, such as an XRM service capability configuration message, specifically defined for RAN 105 to indicate the RAN's ability to support XRM services. This message can indicate the supported XRM services or information about the service categories of the supported XRM services—such as streaming audio, video, etc.

[0120] For further clarity, refer to Figures 11 through 13 to discuss several example methods that a CN node can implement to support PDU sessions.

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

[0122] Figure 12 is a flowchart of an example method 1200 that a CN node (e.g., an H-SMF 166B operating in HPLMN 103) can implement for processing a request to establish a PDU session. 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, for example, 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 processing (see, for example, events 760, 733, 763).

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

[0124] Therefore, the above-mentioned technology supports PDU set-based processing during PDU session establishment or modification, enabling PDU set-based processing in cellular communication networks and reducing signal transmission overhead. In the system discussed above, the RAN can provide the AMF with an indication of whether the NG-RAN node supports PDU set-based processing; the AMF can store information on RAN support for PDU set processing; and during the PDU session establishment or modification process, the AMF can provide the SMF with an indication of support (or lack thereof) for PDU set processing at the RAN in the Nsmf_PDU Session_CreateSMContext request message or the Nsmf_PDUSession_UpdateSMContext request message.

[0125] The process by which the RAN can provide the AMF with an indication of support for PDU set-based handling at the RAN can be based on TS 38.413. If the SMF receives an indication of support for PDU set-based handling at the RAN in an Nsmf_PDUSession_CreateSMContext request or Nsmf_PDUSession_UpdateSMContext request message during the UE-requested PDU session establishment process for non-roaming and roaming with local guidance, and the PCF prepares PCC rules including PDU set-based QoS parameters and a protocol description for PDU set handling during an SMF-initiated SM policy association modification, then the SMF can determine to enable PDU set-based handling for the UE's PDU session based on TS 23.501 Clause 5.37.5. If the SMF decides to activate the PDU set identifier and tag for the PDU session, then the SMF can include the protocol description in the PDR and the PDU set QoS parameters in the QER based on TS 23.501 Clause 5.37.5.2.

[0126] The N2 SM may include information forwarded by the AMF to the RAN, including one or more QoS profiles and corresponding QFIs. For each QoS flow, the SMF may indicate whether redundant transmission should be performed via a corresponding redundancy transmission indicator. For each QoS flow, the QoS profile may also include PDU set QoS parameters (e.g., as described in Clause 5.7.7 of TS 23.501) to enable PDU set-based QoS handling at the RAN when supported.

[0127] Using information about NG-RAN's support for PDU set processing, the SMF can determine whether to activate / deactivate PDU set-based processing, for example, requesting QoS parameters based on PDU sets and instructing the UPF to activate PDU set identifiers and tags.

[0128] Furthermore, when a UE initiates a PDU session modification procedure, the AMF can invoke the Nsmf_PDUSession_UpdateSMContext procedure, which contains an SM context ID, an N1 SM container including the PDU session modification request, and an indication of support for PDU set-based processing at the RAN. The AMF can later provide the SMF with the stored indication of support for PDU set-based processing at the RAN to inform the SMF whether the RAN node supports PDU set-based processing. The procedure by which the RAN provides the AMF with the indication of support for PDU set-based processing can be based on TS 38.413. If the SMF receives the indication of support for PDU set-based processing at the RAN, and the PCF prepares PCC rules including PDU set-based QoS parameters and a protocol description for PDU set processing, the SMF can decide to enable PDU set-based processing for the UE's PDU session based on Clause 5.37.5 of TS 23.501. Furthermore, if the SMF determines that PDU set-based processing for PDU sessions is enabled, the SMF instructs the UPF to enable PDU set processing by including a protocol description in the PDR and PDU set QoS parameters in the QER, as described in Clause 5.37.5.2 of TS 23.501. If the SMF determines that PDU set-based processing is enabled at the RAN, the SMF includes a QoS profile with PDU set-based QoS parameters for each QoS flow, as defined in Clause 5.7.7 of TS 23.501.

[0129] Furthermore, considering the non-homogeneous support for PDU set-based processing in the RAN, the SMF can activate the PDU set identifier and tag in the PSA UPF in the following scenarios: (i) 5GS registration, (ii) when the UE access type is 3GPP access, (ii) when the PDU session request type indicates initial registration or existing registration, (iii) IP PDU session type, (iv) non-roaming and local routing, and (v) UE state transitions, such as from CM-IDLE / CM-IDLE with pause to CM-CONNECTED state, and from RRC-INACTVE with CM-CONNECTED to RRC-CONNECTED with CM-CONNECTED state. For handover processes that result in changes to the PDU set-based handling capabilities in the registered access network, such as NG-RAN Xn handover, N2 handover, PDU session handover between 3GPP and non-3GPP access, and handover between 5GS and EPS, the target NG-RAN provides the SMF with an indication of whether the target RAN node supports PDU set-based handling, which may be based on TS 38.413.

[0130] If the SMF decides to enable PDU set-based QoS handling in the RAN for the scenario described in Clause 5.37.5.3 of TS 23.501, the N2 SM information, which includes information forwarded by the AMF to the RAN, may include PDU set-based QoS parameters for each QoS flow. In some scenarios, if the N2 SM information includes a PDU set-based handling support indication (i.e., an indication of support for PDU set handling at the RAN), the SMF configures the PSA UPF to activate the PDU set identifier and tag for the QoS flow for the scenario described in Clause 5.37.5.3 of TS 23.501. Furthermore, upon completion of the handover process, and based on the PDU set-based handling support indication and the scenario described in Clause 5.37.5.3 of TS 23.501, the SMF may initiate a PDU session modification procedure to provide the RAN with the PDU set QoS parameters and configure the PSA UPF to activate or deactivate the PDU set identifier and tag.

[0131] Additional considerations

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

[0133] User devices that implement the technologies disclosed herein (e.g., UE 102) can be any suitable device capable of wireless communication, such as smartphones, tablets, laptops, mobile game consoles, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media streaming dongles or other personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, or broadband routers. Furthermore, in some cases, the user device can be embedded in electronic systems such as a vehicle's main unit or an advanced driver assistance system (ADAS). Even 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, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

[0134] Some embodiments described in this disclosure include logic or multiple components or modules. A module can 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 capable of performing certain operations and can be configured or arranged in a certain manner. A hardware module may include a dedicated circuit system or logic that is persistently configured (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuit systems (e.g., as 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 with a dedicated and permanently configured circuit system or with a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

[0135] As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof are intended to cover non-exclusive inclusion. For example, a process, method, article of manufacture, or apparatus that includes a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article of manufacture, or apparatus. Furthermore, unless expressly stated otherwise to the contrary, “or” means inclusive or rather than exclusive or. For example, condition A or B is satisfied by either: A is true (or exists) and B is false (or does not exist); A is false (or does not exist) and B is true (or exists); and both A and B are true (or exist).

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

Claims

1. A method implemented in a node of a core network (CN) associated with a serving radio access network (RAN), the method comprising: The serving RAN receives a request to establish a Protocol Data Unit (PDU) session from the roaming user equipment (UE). Determine whether the service RAN supports PDU set processing; And provide the home CN of the roaming UE with an indication of whether the serving RAN supports the processing of the PDU set.

2. The method of claim 1, implemented in the Visited Access and Mobility Management Function (V-AMF), wherein, The determination includes receiving, in an N2 PDU session response message, an indication from the RAN as to whether the serving RAN supports the processing of the PDU set.

3. The method of claim 2, wherein: Providing the home CN with an indication of whether the serving RAN supports the handling of the PDU set includes sending an Nsmf_PDUSession_Update_SMContext request message to the visited session management function V-SMF.

4. The method as described in claim 1, implemented in V-SMF, wherein, The determination includes receiving, in an Nsmf_PDUSession_Update_SMContext request message, an indication from the V-AMF RAN as to whether the serving RAN supports the processing of the PDU set.

5. The method of claim 4, wherein: Providing the home CN with an indication of whether the serving RAN supports the processing of the PDU set includes sending an Nsmf_PDUSession_Update request to the home SMF H-SMF of the home CN.

6. The method of claim 4 or 5, further comprising: The Nsmf_PDUSession_Update request message includes a list of accepted and / or rejected Quality of Service (QoS) Flow Identifiers (QFIs).

7. The method as described in any one of the preceding claims, further comprising: The home CN is determined to perform PDU set identification and marking on the PDU session to support home route roaming.

8. A method implemented in a node belonging to a core network (CN), the method comprising: Receive a request from the visited CN to create a Protocol Data Unit (PDU) session for the roaming UE associated with the home CN; Receive from the visited CN an indication of whether the serving radio access network (RAN) associated with the visited CN supports PDU set processing; and activate or deactivate the PDU set processing at the home CN according to the indication.

9. The method of claim 8, wherein, The activation or deactivation includes: in response to determining that the serving RAN supports the PDU set handling, performing PDU set identification and marking on the PDU session to support home route roaming.

10. The method of claim 8, further comprising: In response to determining that the serving RAN does not support the PDU set processing, the PDU set identifier and tag used for the PDU session are deactivated for at least one Quality of Service (QoS) flow.

11. The method of any one of claims 8 to 10, further comprising: Receive from the CN a list of accepted and / or rejected Quality of Service (QoS) Flow Identifiers (QFIs).

12. The method according to any one of claims 8 to 11, wherein, The instruction from the visited CN is received in the Nsmf_PDUSession_Update request message.

13. The method of claim 12, further comprising: In response to the Nsmf_PDUSession_Update request message, an Nsmf_PDUSession_Update response message is sent.

14. The method of any one of claims 8 to 12, further comprising: Based on the policies and charging control (PCC) policies at the home CN, QoS parameters for one or more QoS flows used in the PDU session are obtained.

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

Images