Method of user equipment (UE) and ue
Patent Information
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- NEC CORP
- Filing Date
- 2024-07-12
- Publication Date
- 2026-05-20
AI Technical Summary
The 5G system lacks a mechanism for user equipment (UE) to discover and utilize Dual Steer Access Traffic Steering, Switching, Splitting (DSATSSS) services across multiple 3GPP access networks, leading to inefficiencies in traffic management and quality of experience (QoE).
A method for User Equipment (UE) to receive information related to service discovery when a DSATSSS service becomes available, and to display this information to the user. Additionally, the UE measures Round-Trip Time (RTT) and receives system information related to congestion or bit rate via multiple Uu interfaces, enabling informed decision-making for traffic steering and switching.
Enables efficient discovery and utilization of DSATSSS services, improving traffic management and QoE by allowing the UE to make informed decisions based on real-time network conditions.
Smart Images

Figure JP2024025199_23012025_PF_FP_ABST
Abstract
Description
METHOD OF USER EQUIPMENT (UE) AND UE
[0001] The present disclosure relates to a method of a User Equipment (UE) and a UE etc.
[0002] In NPL 2, the following service requirement is described. This requirement is important to improve access and network resources utilization, capacity, coverage, reliability and QoE (Quality of Experience). ・ 5G system (5GS) supports traffic steering, splitting and switching of UE's user data (pertaining to the same data session), across two 3GPP access networks.
[0003] NPL 1: 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". V17.1.0 (2021-12) NPL 2: 3GPP TS 22.841: " Study on Upper layer traffic steer, switch and split over dual 3GPP access". V1.0.0 (2023-03) NPL 3: 3GPP TS 23.501: "System architecture for the 5G System (5GS)". V18.1.0 (2023-03) NPL 4: 3GPP TS 23.502: "Procedures for the 5G System (5GS)". V18.1.1 (2023-04) NPL 5: 3GPP TS 23.503: "Policy and charging control framework for the 5G System (5GS) Stage 2". V18.1.0 (2023-03) NPL 6: 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS) Stage 3". V18.2.1 (2023-03) NPL 7: 3GPP TS 23.003: "Numbering, addressing and identification". V18.1.0 (2023-03) NPL 8: 3GPP TS 29.212: "Policy and Charging Control (PCC); Reference points". V17.2.0 (2022-03) NPL 9: 3GPP TS 33.501: "Security architecture and procedures for 5G system". V18.1.0 (2023-03) NPL 10: IETF RFC 5580: "Carrying Location Objects in RADIUS and Diameter". (2009-08) NPL 11: IETF RFC 792: "Internet Control Message Protocol". (1981-09) NPL 12: IETF RFC 4443: "Internet Control Message Protocol (ICMPv6)". (2006-03). NPL 13: 3GPP TS 23.548: "5G System Enhancements for Edge Computing". V18.1.1 (2023-04).
[0004] The following service requirement has not been supported by the 5GS yet. For example, there is no mechanism in the 3GPP specification(s) for achieving the following service requirement. ・ The 5G system supports traffic steering, splitting and switching of UE's user data (pertaining to the same data session), across two 3GPP access networks.
[0005] A method of a User Equipment (UE) according to an aspect of the present disclosure includes: receiving information related to service discovery when a Dual Steer Access Traffic Steering, Switching, Splitting service (DSATSSS service) becomes available; and displaying information related to discovered service.
[0006] A method of a User Equipment (UE) according to an aspect of the present disclosure includes: receiving first system information related to congestion or bit rate via a first Uu interface; and receiving second system information related to congestion or bit rate via a second Uu interface.
[0007] A method of a User Equipment (UE) according to an aspect of the present disclosure includes: measuring Round-Trip Time (RTT) related information by sending a first message to a network, receiving a second message from the network and using a measurement timer.
[0008] A User Equipment (UE) according to an aspect of the present disclosure includes: means for receiving information related to service discovery when a Dual Steer Access Traffic Steering, Switching, Splitting service (DSATSSS service) becomes available; and means for displaying information related to discovered service.
[0009] A User Equipment (UE) according to an aspect of the present disclosure includes: means for receiving first system information related to congestion or bit rate via a first Uu interface; and means for receiving second system information related to congestion or bit rate via a second Uu interface.
[0010] A User Equipment (UE) according to an aspect of the present disclosure includes: means for measuring Round-Trip Time (RTT) related information by sending a first message to a network, receiving a second message from the network and using a measurement timer.
[0011] Fig. 1 is a Network connection model of a First example of a First Aspect.Fig. 2 is an example of the Service profile in a First example of a First Aspect.Fig. 3 is a Signaling diagram of a First example of a First Aspect.Fig. 4 is a block diagram of a First scenario in Second example of the First Aspect.Fig. 5 is a Signaling diagram of a First scenario in Second example of the First Aspect.Fig. 6 is a Signaling diagram of a First scenario in Second example of the First Aspect.Fig. 7 is a Signaling diagram of a First scenario in Second example of the First Aspect.Fig. 8 is a Signaling diagram of a First scenario in Second example of the First Aspect.Fig. 9 is a Signaling diagram of a First scenario in Second example of the First Aspect.Fig. 10 is a Signaling diagram of a First scenario in Second example of the First Aspect.Fig. 11 is a Signaling diagram of a First scenario in Second example of the First Aspect.Fig. 12 is an implementation example of a Second scenario in Second example of the First Aspect.Fig. 13 is an implementation example of a Second scenario in Second example of the First Aspect.Fig. 14 is an implementation example of a Second scenario in Second example of the First Aspect.Fig. 15 is an implementation example of a Second scenario in Second example of the First Aspect.Fig. 16 is a Network connection model of a First example of a Second Aspect.Fig. 17 is a Signaling diagram of a First scenario in Second example of the Second Aspect.Fig. 18 is a Signaling diagram of a Variant 1 of First Scenario, Second Example, Second AspectFig. 19 is a Signaling diagram of a Second scenario in Second example of the Second Aspect.Fig. 20 is a block diagram of a Second scenario in Second example of the Second Aspect.Fig. 21 is a Signaling diagram of a Third scenario in Second example of the Second Aspect.Fig. 22 is a Signaling diagram of a Fourth scenario in Second example of the Second Aspect.Fig. 23 is a Signaling diagram of a Fifth scenario in Second example of the Second Aspect.Fig. 24 is a Signaling diagram of a First scenario in Third example of the Second Aspect.Fig. 25 is a Signaling diagram of a Second scenario in Third example of the Second Aspect.Fig. 26 is a Signaling diagram of a Third scenario in Third example of the Second Aspect.Fig. 27 is a Signaling diagram of a Fourth scenario in Third example of the Second Aspect.Fig. 28 is a Signaling diagram of a First scenario in Fourth example of the Second Aspect.Fig. 29 is a Signaling diagram of a First scenario in Fifth example of the Second Aspect.Fig. 30 is a Signaling diagram of a First scenario in Sixth example of the Second Aspect.Fig. 31 is a block diagram of a Second scenario in Sixth example of the Second Aspect.Fig. 32 is a Signaling diagram of a Third scenario in Sixth example of the Second Aspect.Fig. 33 is a Signaling diagram of a Fourth scenario in Sixth example of the Second Aspect.Fig. 34 is a Signaling diagram of a Fifth scenario in Sixth example of the Second Aspect.Fig. 35 is a Network connection model of a First scenario in Seventh example of the Second Aspect.Fig. 36 is a Signaling diagram of a Second scenario in Seventh example of the Second Aspect.Fig. 37 is a Signaling diagram of a Third scenario in Seventh example of the Second Aspect.Fig. 38 is a Signaling diagram of a Fourth scenario in Seventh example of the Second Aspect.Fig. 39 is a Network connection model of a First example of a Third Aspect.Fig. 40 is a Signaling diagram of a First scenario in Second example of the Third Aspect.Fig. 41 is a Signaling diagram of a Second scenario in Second example of the Third Aspect.Fig. 42 is a Signaling diagram of a First scenario in Third example of the Third Aspect.Fig. 43 is a Signaling diagram of a Second scenario in Third example of the Third Aspect.Fig. 44 is a Signaling diagram of a Third scenario in Third example of the Third Aspect.Fig. 45 is a Signaling diagram of a Fourth scenario in Third example of the Third Aspect.Fig. 46 is a Signaling diagram of a First scenario in Fourth example of the Third Aspect.Fig. 47 is a Signaling diagram of a Second scenario in Fourth example of the Third Aspect.Fig. 48 is a Signaling diagram of a First scenario in Fifth example of the Third Aspect.Fig. 49 is a Signaling diagram of a First scenario in Sixth example of the Third Aspect.Fig. 50 is a Signaling diagram of a Second scenario in Sixth example of the Third Aspect.Fig. 51 is a block diagram of a Third scenario in Sixth example of the Third Aspect.Fig. 52 is a Signaling diagram of a Third scenario in Sixth example of the Third Aspect.Fig. 53 is a Network connection model of a First scenario in Seventh example of the Third Aspect.Fig. 54 is a Signaling diagram of a Third scenario in Seventh example of the Third Aspect.Fig. 55 is a diagram illustrating a system overview.Fig. 56 is a block diagram illustrating a UE.Fig. 57 is a block diagram illustrating an (R)AN node.Fig. 58 is a diagram illustrating System overview of (R)AN node based on O-RAN architecture.Fig. 59 is a block diagram illustrating an RU.Fig. 60 is a block diagram illustrating a DU.Fig. 61 is a block diagram illustrating a CU.Fig. 62 is a block diagram illustrating an AMF.Fig. 63 is a block diagram illustrating an SMF.Fig. 64 is a block diagram illustrating a UPF.Fig. 65 is a block diagram illustrating a PCF.Fig. 66 is a block diagram illustrating an NWDAF.Fig. 67 is a block diagram illustrating a UDM.Fig. 68 is a block diagram illustrating an NSSF.Fig. 69 is a block diagram illustrating an NSACF.Fig. 70 is a block diagram illustrating an AUSF.Fig. 71 is a block diagram illustrating an AF.
[0012] Abbreviations For the purposes of the present document, the abbreviations given in NPL 1 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in NPL 1. 4G-GUTI 4G Globally Unique Temporary UE Identity 5GC 5G Core Network 5GLAN 5G Local Area Network 5G HE AV 5G Home Environment Authentication Vector 5G SE AV 5G Serving Environment Authentication Vector 5GS 5G System 5G-AN 5G Access Network 5G-AN PDB 5G Access Network Packet Delay Budget 5G-EIR 5G-Equipment Identity Register 5G-GUTI 5G Globally Unique Temporary Identifier 5G-BRG 5G Broadband Residential Gateway 5G-CRG 5G Cable Residential Gateway 5G GM 5G Grand Master 5G-RG 5G Residential Gateway 5G-S-TMSI 5G S-Temporary Mobile Subscription Identifier 5G VN 5G Virtual Network 5QI 5G QoS Identifier ABBA Anti-Bidding down Between Architectures AF Application Function AMF Access and Mobility Management Function AMF-G Geographically selected Access and Mobility Management Function AMF-NG Non-Geographically selected Access and Mobility Management Function ANDSF Access Network Discovery and Selection Function ARFCN Absolute radio-frequency channel number AS Access Stratum ASN Abstract Syntax Notation ATSSS Access Traffic Steering, Switching, Splitting ATSSS-LL ATSSS Low-Layer AuC Authentication Centre AUSF Authentication Server Function AUTN Authentication token BCCH Broadcast Control Channel BMCA Best Master Clock Algorithm BSF Binding Support Function CAG Closed Access Group CAPIF Common API Framework for 3GPP northbound APIs CHF Charging Function CN PDB Core Network Packet Delay Budget CP Control Plane DAPS Dual Active Protocol Stacks DL Downlink DN Data Network DNAI DN Access Identifier DNN Data Network Name DRX Discontinuous Reception DSATSSS Dual Steer Access Traffic Steering, Switching, Splitting DSATSSS-LL Dual Steer Access Traffic Steering, Switching, Splitting- Low-Layer DSMA Dual Steer Multi Access DS-TT Device-side TSN translator ePDG evolved Packet Data Gateway EBI EPS Bearer Identity ECGI E-UTRAN Cell Global Identifier EPS Evolved Packet System EUI Extended Unique Identifier FAR Forwarding Action Rule FN-BRG Fixed Network Broadband RG FN-CRG Fixed Network Cable RG FN-RG Fixed Network RG FQDN Fully Qualified Domain Name GCI Global Cable Identifier GEO Geostationary Earth Orbit GFBR Guaranteed Flow Bit Rate GMLC Gateway Mobile Location Centre G-PDU GTP encapsulated user Plane Data Unit GPS Global Positioning System GPSI Generic Public Subscription Identifier GSO Geosynchronous Orbit GUAMI Globally Unique AMF Identifier GUTI Globally Unique Temporary UE Identity HPLMN Home Public Land Mobile Network HR Home Routed (roaming) HSS Home Subscriber Server IAB Integrated access and backhaul IPsec Internet Protocol Security IMEI / TAC IMEI Type Allocation Code IMSI International Mobile Subscriber Identity IPUPS Inter PLMN UP Security I-SMF Intermediate SMF I-UPF Intermediate UPF LADN Local Area Data Network LBO Local Break Out (roaming) LCS Location Service LEO Low Earth Orbit LMF Location Management Function LoA Level of Automation LPP LTE Positioning Protocol LRF Location Retrieval Function MA Multi Access MCC Mobile country code MCX Mission Critical Service MDBV Maximum Data Burst Volume ME Mobile Equipment MFBR Maximum Flow Bit Rate MICO Mobile Initiated Connection Only MINT Minimization of service interruption MITM Man In the Middle MME Mobility Management Entity MN Master Node MNC Mobile Network Code MNO Mobile Network Operator MOCN Multiple Operator Core Network MPS Multimedia Priority Service MPTCP Multi-Path TCP Protocol MT Mobile Termination, Mobile Terminating, Mobile terminated N3IWF Non-3GPP InterWorking Function N3GPP Non-3GPP access N5CW Non-5G-Capable over WLAN NAI Network Access Identifier NAS Non-Access-Stratum NCGI NR Cell Global Identity NCI NR Cell Identity NEF Network Exposure Function NF Network Function NGAP Next Generation Application Protocol NGSO Non-Geosynchronous Orbit NID Network identifier NMEA National Marine Electronics Association NPN Non-Public Network NR New Radio NSAG Network Slice Access Stratum Group NRF Network Repository Function NSAC Network Slice Admission Control NSACF Network Slice Admission Control Function NSI ID Network Slice Instance Identifier NSSAA Network Slice-Specific Authentication and Authorization NSSAAF Network Slice-Specific Authentication and Authorization Function NSSAI Network Slice Selection Assistance Information NSSF Network Slice Selection Function NSSP Network Slice Selection Policy NSSRG Network Slice Simultaneous Registration Group NW-TT Network-side TSN translator NWDAF Network Data Analytics Function PCF Policy Control Function PCO Protocol Configuration Options PCRF Policy and Charging Rules Function PDB Packet Delay Budget PDR Packet Detection Rule PDU Protocol Data Unit PEI Permanent Equipment Identifier PER Packet Error Rate PFD Packet Flow Description PLMN Public Land Mobile Network PNI-NPN Public Network Integrated Non-Public Network PPD Paging Policy Differentiation PPF Paging Proceed Flag PPI Paging Policy Indicator ProSe Proximity based Services PSA PDU Session Anchor PTP Precision Time Protocol QFI QoS Flow Identifier QoE Quality of Experience RACS Radio Capabilities Signalling optimisation (R)AN (Radio) Access Network RAT Radio Access Technology RG Residential Gateway RIM Remote Interference Management RQA Reflective QoS Attribute RQI Reflective QoS Indication RRC Radio Resource Control RSC Relay Service Code RSD Route Selection Descriptor RSN Redundancy Sequence Number RSRP Reference Signal Received Power RSRQ Reference Signal Received Quality RTT Round-Trip Time RVAS Roaming Value Added Service SA NR Standalone New Radio SBA Service Based Architecture SBI Service Based Interface SCP Service Communication Proxy SD Slice Differentiator SEAF Security Anchor Functionality SENSE Signal Level Enhanced Network Selection SEPP Security Edge Protection Proxy SGW Serving Gateway SIB System Information Block SINR Signal to Interference plus Noise Ratio SLA Service Level Agreement SMF Session Management Function SMS Short Message Service SMSF Short Message Service Function SN Sequence Number SN Secondary Node SN name Serving Network Name. SNPN Stand-alone Non-Public Network S-NSSAI Single Network Slice Selection Assistance Information SOR Steering of Roaming SSC Session and Service Continuity SSCMSP Session and Service Continuity Mode Selection Policy SST Slice / Service Type SUCI Subscription Concealed Identifier SUPI Subscription Permanent Identifier SV Software Version TAI Tracking Area Identity TAU Tracking Area Update TEID Tunnel Endpoint Identifier TMSI Temporary Mobile Subscriber Identity TNAN Trusted Non-3GPP Access Network TNAP Trusted Non-3GPP Access Point TNGF Trusted Non-3GPP Gateway Function TNL Transport Network Layer TNLA Transport Network Layer Association TSC Time Sensitive Communication TSCAI TSC Assistance Information TSN Time Sensitive Networking TSN GM TSN Grand Master TSP Traffic Steering Policy TT TSN Translator TWIF Trusted WLAN Interworking Function UCMF UE radio Capability Management Function UCU UE Configuration Update UDM Unified Data Management UDR Unified Data Repository UDSF Unstructured Data Storage Function UE User Equipment UL Uplink UL CL Uplink Classifier UPF User Plane Function UPSI UE Policy Section Identifier URLLC Ultra Reliable Low Latency Communication URRP-AMF UE Reachability Request Parameter for AMF URSP UE Route Selection Policy USIM User Services Identity Module VID VLAN Identifier VLAN Virtual Local Area Network VPLMN Visited Public Land Mobile Network W-5GAN Wireline 5G Access Network W-5GBAN Wireline BBF Access Network W-5GCAN Wireline 5G Cable Access Network W-AGF Wireline Access Gateway Function
[0013] Definitions For the purposes of the present document, the terms and definitions given in NPL 1 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in NPL 1.
[0014] General Those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the Aspects of the present disclosure so as not to obscure the figures with details that will be readily apparent to those skilled in the art having the benefit of the description herein.
[0015] For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the Aspect illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as would normally occur to those skilled in the art are to be construed as being within the scope of the present disclosure.
[0016] The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or method. Similarly, one or more devices or entities or sub-systems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, sub-systems, elements, structures, components, additional devices, additional sub-systems, additional elements, additional structures or additional components. Appearances of the phrase "in an Aspect", "in another Aspect" and similar language throughout this specification may, but not necessarily do, all refer to the same Aspect.
[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are only illustrative and not intended to be limiting.
[0018] In the following specification and the claims, reference will be made to a number of terms, which may be defined to have the following meanings. The singular forms "a", "an", and "the" include plural references unless the context clearly dictates otherwise.
[0019] As used herein, information is associated with data and knowledge, as data is meaningful information and represents the values attributed to parameters. Further knowledge signifies understanding of an abstract or concrete concept. Note that this example system is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the Aspects disclosed herein in addition to, or instead of, a system, and all such Aspects are contemplated as within the scope of the present disclosure.
[0020] Each of Aspects and elements included in the each of Aspects described below may be implemented independently or in combination with any other. These Aspects include novel characteristics different from one another. Accordingly, these Aspects contribute to achieving objects or solving problems different from one another and contribute to obtaining advantages different from one another.
[0021] Any lists described in following aspects include at least one parameter or multiple parameters.
[0022] An example object of this disclosure is to provide a method and apparatus that can solve the above-mentioned problem.
[0023] Although this disclosure discloses a mechanism to establish multiple data plane connections in the 5GS, all mechanisms in this disclosure can equally apply to the EPS and / or any other system as well. In case all mechanisms in this disclosure are to apply to the EPS, the following terminology conversions apply: ・ gNB → eNodeB ・ AMF → MME ・ SMF → SGW or PGW or combined SGW and PGW or SMF + PGW-C in the case of interworking with EPS ・ UPF → SGW-U or PGW-U or combined SGW-U and PGW-U or UPF + PGW-U in the case of interworking with EPS ・ NGAP → S1AP ・ XnAP → X2AP ・ Any NGAP messages → Respective S1AP messages ・ Any XnAP messages → Respective X2AP messages ・ Registration Request message → Attach Request message or TAU Request message ・ Any AMF service-related messages (ex. Namf_Communication_NonUeN2InfoNotify) → GTP-C messages ・ Any UDM service-related messages (ex. Nudm_SDM_Notification) → DIAMETER messages ・ 5G-GUTI → GUTI ・ 5G-S-TMSI → S-TMSI
[0024] In this disclosure, the above-mentioned service requirement or a service achieved by the above mentioned service requirement can be expressed as Dual Steer (DS) service, Access Traffic Steering, Switching, Splitting (ATSSS) service, Access Traffic Steering, Switching, Splitting (ATSSS) service with 3GPP Access networks (3G-RAT ATSSS) service, Dual Steer Access Traffic Steering, Switching, Splitting (DSATSSS) service, Multiple Access with 3GPP Access networks (3G-RAT MA) service, Dual Steer Multiple Access Steering, Switching, Splitting (DSMASSS) service and etc.
[0025] In this disclosure, one data connection over 3GPP access network between the UE and the PDU Session anchor UPF can be expressed as a single connection, data connection, data path, single data connection, single data path and etc.
[0026] In this disclosure, multiple data connections over multiple 3GPP accesses (or over multiple 3GPP access networks) between the UE and the PDU Session anchor UPF can be expressed as multiple data connections, multiple data paths, multiple data legs, Multiple Access (MA) PDU Session, MA PDU Connection, Dual Steer MA (DSMA) PDU Session, Dual Steer MA (DSMA) PDU Connection and etc. The multiple data connections over multiple 3GPP accesses (or over multiple 3GPP access networks) between the UE and the PDU Session anchor UPF in single PLMN or in multiple PLMNs may be expressed as multiple data connections, multiple data paths, multiple data legs, MA PDU Session, MA PDU Connection, Dual Steer MA (DSMA) PDU Session, Dual Steer MA (DSMA) PDU Connection and etc.
[0027] Each Aspects and elements may relate to one of following descriptions, combination of following descriptions, or all of following descriptions, but the each Aspects and the elements are not limited to following descriptions.
[0028] Each Aspects and elements may provide solution related to one of following descriptions, combination of following descriptions, or all of following descriptions, but the each Aspects and the elements may provide solution other than the following descriptions.
[0029] For example, there is no mechanism in 3GPP standards for the UE to know which 3GPP access can be used to configure MA PDU Session for a particular DSATSSS service.
[0030] For example, when the UE wishes to establish the MA PDU Session for Mobile broadband (MBB) access while the UE can listen to an NR signal over Geostationary Earth Orbit (GEO) by PLMN-A, an NR signal over Low Earth Orbit (LEO) by PLMN-B and E-UTRA signal over terrestrial base station by PLMN-C, there is no way for the UE to understand which 3GPP access can support to provide MBB service and which 3GPP access can be a part of single data path that configures the MA PDU Session. Without clear service discovery mechanisms, the DSATSSS service does not work.
[0031] For example, the following problems need to be solved. ・ The UE needs to know in advance for each 3GPP access what DSATSSS services can be provided so that the UE accesses to the correct 3GPP access. ・ Other potential issues with regard to the DSATSSS service discovery.
[0032] For example, there is no mechanism for end users to know which 3GPP access can be used to configure MA PDU Session for a particular DSATSSS service. For example, when end users wish to establish an MA PDU Session for Mobile broadband (MBB) access while the UE can listen to a NR signal over Geostationary Earth Orbit (GEO) by PLMN-A, a NR signal over Low Earth Orbit (LEO) by PLMN-B and E-UTRA over terrestrial base station by PLMN-C, there is no way for the UE to understand which 3GPP access can support to provide MBB service and which 3GPP access can be a part of a single data path that configures the MA PDU Session. Without clear service notifications to end users, the DSATSSS service does not work. For example, the following problems need to be solved. ・ End user needs to know in advance for each 3GPP access what DSATSSS services can be provided so that the end user will request a MA PDU Session with that 3GPP access. ・ End user needs to know in advance how much improvement on QoE point of view by structuring MA PDU Session rather than single PDU Session. ・ End user needs to know in advance what is a charging rate to apply if an MA PDU Session to be established. ・ Other potential issues with regard to the DSATSSS service notification (e.g., signaling enhancement for the above problems).
[0033] For example, in a case where one 3GPP access is provided by the terrestrial gNB while another 3GPP access is provided via the satellite as Non-Terrestrial Network (NTN) access, each 3GPP access may have its own associated AMF, as the AMF is basically allocated based on a geographical coverage where associated base stations provide coverage.
[0034] In this case, there is no mechanism in 3GPP standards about how multiple AMFs can be handled for a single subscription in 3GPP access. Without clear access and mobility management mechanism with multiple AMFs in 3GPP access, the DSATSSS service does not work. For example, the following problems need to be solved. ・ How the UE registers to multiple AMFs for 3GPP access in single PLMN. ・ How UE configuration is updated with multiple AMFs in single PLMN. ・ How UE policy is updated with multiple AMFs in single PLMN. ・ Other potential issues with regard to the access and mobility management with multiple AMFs in single PLMN.
[0035] For example, in a case where one 3GPP access is provided by the terrestrial gNB while another 3GPP access is provided via the satellite as Non-Terrestrial Network (NTN) access, each 3GPP access may have its own associated AMF as the AMF is basically allocated based on a geographical coverage where associated base stations provide coverage. In this case, there is no mechanism in 3GPP standard about how Dual Steer Multiple Access (DSMA) PDU Session is established with multiple AMFs for single subscription in 3GPP access. Without a clear session management mechanism with multiple AMFs in 3GPP access, the DSATSSS service does not work. For example, the following problems need to be solved. ・ How the DSMA PDU Session can be established when each data connection is managed with different AMF in single PLMN. ・ How each data connection, managed by different AMFs in single PLMN, can be established with the same SMF and the same UPF at the PDU Session Anchor to structure the DSMA PDU Session. ・ How the MT (Mobile Terminating) procedure works, for example if the UE is in idle state, or if there are multiple data connections. ・ Other potential issues with regard to the session mobility management with multiple AMFs.
[0036] For example, in a case where one 3GPP access is provided by the terrestrial gNB while another 3GPP access is provided via the satellite as Non-Terrestrial Network (NTN) access, each 3GPP access may have its own associated AMF, as the AMF is basically allocated based on a geographical coverage where associated base stations provide coverage. In addition, there is a case where one 3GPP access is provided by different Mobile Network Operator (MNO). In this case, there is no mechanism in 3GPP standards about how multiple AMFs from different PLMNs can be handled for single subscription in 3GPP access. Without clear access and mobility management mechanism with multiple AMFs in 3GPP access, the DSATSSS service does not work. For example, the following problems need to be solved. ・ How the UE registers to multiple AMFs from different PLMNs for 3GPP access. ・ How UE configuration is updated with multiple AMFs from different PLMNs. ・ How UE policy is updated with multiple AMFs with different PLMNs. ・ Other potential issues with regard to the access and mobility management with multiple AMFs from different PLMNs.
[0037] For example, in a case where one 3GPP access is provided by the terrestrial gNB while another 3GPP access is provided via the satellite as NTN (Non-Terrestrial Network) access, each 3GPP access may have its own AMF associated, as the AMF is basically allocated based on a geographical coverage where associated base stations provide coverage. In addition, there is a case where one 3GPP access is provided by different MNO (Mobile Network Operator). In this case, there is no mechanism in 3GPP standards about how DSMA PDU Session is established with multiple AMFs for single subscription in 3GPP access. Without clear session management mechanism with multiple AMFs in 3GPP access, the DSATSSS service does not work. For example, the following problems need to be solved. ・ How the DSMA PDU Session can be established when each data connection is managed with different AMFs from different PLMNs. ・ How each data connection, managed by different AMFs from different PLMNs can be established with the same SMF and the same UPF at the PDU Session Anchor to structure the DSMA PDU Session. ・ How the Mobile Terminating (MT) procedure works, especially if the UE is in idle state, if there are multiple data connections spanned to different PLMNs. ・ Other potential issues with regard to the session mobility management with multiple AMFs from different PLMNs.
[0038] For example, in a case where one 3GPP access is provided by the terrestrial gNB while another 3GPP access is provided via the satellite as Non-Terrestrial Network (NTN) access, each 3GPP access may have its own associated AMF, as the AMF is basically allocated based on a geographical coverage where associated base stations provide coverage. In this case, there is no mechanism in 3GPP standards about how 3GPP Security framework works for DSMA PDU Session with multiple AMFs for single subscription in 3GPP access. Without clear security mechanism with multiple AMFs in 3GPP access, the DSATSSS service does not work. For example, the following problems need to be solved. ・ How the authentication procedure works when multiple AMFs are associated to single subscription in 3GPP access. ・ How the Security key derivation works when multiple AMFs are associated to single subscription in 3GPP access. ・ How Non-Access-Stratum (NAS) security and Access Stratum (AS) security work when multiple AMFs are associated to single subscription in 3GPP access. ・ Other potential issues with regard to the 3GPP security with multiple AMFs.
[0039] A method of a User Equipment (UE) according to example aspect of this disclosure includes receiving information related to service discovery when a Dual Steer Access Traffic Steering, Switching, Splitting service (DSATSSS service) becomes available, and displaying information related to discovered service.
[0040] A method of a User Equipment (UE) according to example aspect of this disclosure includes receiving first system information related to congestion or bit rate via a first Uu interface, and receiving second system information related to congestion or bit rate via a second Uu interface.
[0041] A method of a User Equipment (UE) according to example aspect of this disclosure includes measuring Round-Trip Time (RTT) related information by sending a first message to a network, receiving a second message from the network and using a measurement timer.
[0042] A User Equipment (UE) according to example aspect of this disclosure includes receiving information related to service discovery when a Dual Steer Access Traffic Steering, Switching, Splitting service (DSATSSS service) becomes available, and displaying information related to discovered service.
[0043] A User Equipment (UE) according to example aspect of this disclosure includes receiving first system information related to congestion or bit rate via a first Uu interface, and receiving second system information related to congestion or bit rate via a second Uu interface.
[0044] A User Equipment (UE) according to example aspect of this disclosure includes measuring Round-Trip Time (RTT) related information by sending a first message to a network, receiving a second message from the network and using a measurement timer.
[0045] <First Example Embodiment (First Aspect)> This aspect includes mechanisms for UEs to discover the DSATSSS services that are available in 3GPP access networks. The DSATSSS services can be provided by a combination of two 3GPP access networks. The two 3GPP access networks may use same or different RATs, i.e., NR plus NR or NR plus E-UTRA, where NR RAT can be terrestrial or satellite NR access (including different satellite orbits, e.g., Geostationary Earth Orbit (GEO) / Medium Earth Orbit (MEO) / Low Earth Orbit (LEO)). Note that GEO is categorized as Geosynchronous Orbit (GSO), while MEO and LEO are categorized as Non-Geosynchronous Orbit (NGSO). In a case where two 3GPP access networks are provided by different PLMNs, the two 3GPP access networks can be managed by the same operator or by different operators (assumed to have a business agreement among them). In one example, Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN) may be used to establish the DSMA PDU Session. Possible combinations of two 3GPP access networks are listed below as examples. ・ Two 3GPP RATs (2 NR RATs (two NR RATs), 1 NR RAT (one NR RAT) + 1 E-UTRA RAT (one E-UTRA RAT) and 2 E-UTRA RATs (two E-UTRA RATs)) are provided by single PLMN. ・ Two 3GPP RATs (2 NR RATs, 1 NR RAT + 1 E-UTRA RAT and 2 E-UTRA RATs) are provided by single SNPN. ・ Two 3GPP RATs (2 NR RATs, 1 NR RAT + 1 E-UTRA RAT and 2 E-UTRA RATs) are provided by single PNI-NPN. ・ Each connection with 3GPP RAT (NR RAT or E-UTRA) is provided by different PLMN / SNPN / PNI-NPN (A combination of two different PLMN / SNPN / PNI-NPNs).
[0046] First example of the First Aspect: Fig. 1 illustrates an example of a user plane connection model of the DSMA PDU session.
[0047] To establish the DSMA PDU Session, the UE 3 establishes two separate connections with the same UPF 72, one connection using the RAN 501 and another connection using the RAN 502. An Application Function (AF) 201 in the data network 20 provides a service using the DSMA PDU Session. In a case where the UE 3 roams to a visited PLMN (VPLMN), the UPF 72 may be in the Home PLMN (HPLMN) while at least either the RAN 501 or the RAN 502 may be provided by the VPLMN. As the DSATSSS service may be provided by the Home PLMN (HPLMN) to those of subscribers which are outside of HPLMN (i.e., Outbound roamers), the DSATSSS service provided by the HPLMN may be discovered by the outbound roamers.
[0048] The DSATSSS Service profile can be expressed also in another way, for example, Dual Steering (DS) Service profile, Service profile, List of Service profile, Network slice, DNN, APN, Network slice and DNN combination etc.
[0049] Fig. 2 illustrates examples of the DSATSSS Service profile(s) that can be discovered by the UE 3.
[0050] The following list indicates a detail of the DSATSSS Service profile. The DSATSSS Service profile may include at least one of following information: ・ Service: The Service is referred as the service that end users are provided. For example, the Service may be referred as the service that is provided to end user(s). For example, the Service may indicate a provided DSATSSS service. For example, the Service can be expressed as the following information: > Network Slice: The Network Slice can be expressed as S-NSSAI as defined in NPL 3. The Network Slice may be expressed by only a Slice / Service type (SST) part of S-NSSAI. For example, the Service may indicate S-NSSAI which a service is provided. "S-NSSAI#1(MBB)" may indicate S-NSSAI#1 provides or supports MBB. "S-NSSAI#1(MBB)" may indicate that MBB is provided on S-NSSAI#1 or a network slice indicated by S-NSSAI#1. > DNN: The DNN may indicate a DNN which a service is provided. > APN: The APN may indicate a DNN which a service is provided. "DNN or APN(IMS)" may indicate DNN or APN which IMS is provided. > A combination of S-NSSAI and DNN. > A combination of S-NSSAI and APN. > SMS (Short Message Service) > LCS (Location Service) ・ PLMN: This information may be associated with the Service. The PLMN is referred as the service provider for the Service. The PLMN may be coded as a PLMN ID. The PLMN may be indicated by the PLMN ID. For example, the PLMN is used by outbound roamers when outbound roamers discover Services that are provided by the home network. In this case, the PLMN is equal to HPLMN of the outbound roamers. For example, the PLMN may indicate a PLMN which the above-mentioned "Service" is provided. For example, the PLMN may indicate a PLMN which a service indicated by the above-mentioned "Service" is provided. For example, if the service is a generic and provided by any of the PLMNs (Ex. Internet access service), the PLMN may be set as PLMN independent and it could be a subject for a local-break connection. For example, the PLMN may indicate a PLMN which can provide the DSATSSS service. ・ Partner PLMN: This information may be associated with the Service. The Partner PLMN or any other notation for a PLMN which is referred as a PLMN where such PLMN can provide DSMA PDU Session together with existing PLMN where the UE 3 has registered. The Partner PLMN may be coded as a PLMN ID. The Partner PLMN may be indicated by the PLMN ID. The Partner PLMN may be the Non-Public Network (NPN) including a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN). For example, the Partner PLMN may indicate a PLMN which can provide DSMA PDU Session (or the DSATSSS service) together with existing PLMN where the UE 3 has registered or together with a PLMN indicated by the above-mentioned "PLMN". For example, the Partner PLMN may indicate a PLMN which can provide the above-mentioned "Service" or a service indicated by the above-mentioned "Service" together with existing PLMN where the UE 3 has registered or together with a PLMN indicated by the above-mentioned "PLMN". In a case where the Partner PLMN is a Stand-alone Non-Public Network (SNPN), the Partner PLMN may include a Network identifier (NID) or Group IDs for Network Selection (GIN). In a case where the Partner PLMN is a Public Network Integrated NPN (PNI-NPN), the Partner PLMN may include a Closed Access Group (CAG) Identifier. ・ Location: This information may be associated with the Service. The Location is referred as a geographical location where the Service is available. For example, Location can be a Tracking Area Identity (TAI), NR Cell Global Identity (NCGI) as defined in NPL 7, NR Cell Identity (NCI) as defined in NPL 7, E-UTRAN Cell Global Identifier (ECGI) as defined in NPL 7, Global Cable Identifier (GCI) as defined in NPL 7, a general City name, zip-code, formed with GPS location or a location expressed with civic and geospatial location formats as defined in NPL 10. For example, the Location may indicate a location where the above-mentioned "Service" or a service indicated by the above-mentioned "Service" is provided. ・ Radio type: This information may be associated with the Service. The Radio type may be referred as Radio Access Technology (RAT) type. The Radio type may indicate a radio type providing the above-mentioned "Service" or a service indicated by the above-mentioned "Service". If there are multiple Radio types (or RAT types) associated with the Service, Radio type may have a priority among Radio types. For example, the Radio types are listed in order of decreasing priority with the first Radio type being the highest priority in a list of Radio type. Radio type may be at least one of the following types. The following Radio type may be defined as the RAT type in NPL 8: > WLAN > VIRTUAL > TRUSTED-N3GA > HSPA_EVOLUTION > EUTRA > EUTRA-NB-IoT > NR > LTE-M > NR-U > EUTRA(LEO) > EUTRA(MEO) > EUTRA(GEO) > EUTRA(OTHERSAT) > EUTRA-NB-IoT(LEO) > EUTRA-NB-IoT(MEO) > EUTRA-NB-IoT(GEO) > EUTRA-NB-IoT(OTHERSAT) > LTE-M(LEO) > LTE-M(MEO) > LTE-M(GEO) > LTE-M(OTHERSAT) > NR(LEO) > NR(MEO) > NR(GEO) > NR(OTHERSAT) > CDMA2000_1X > HRPD > UMB > EHRPD ・ Frequency Band: This information may be associated with the Radio type. The Frequency Band is referred as a frequency band where the Service is available or a cell supporting the Service is available. The Frequency Band may be expressed by ARFCN. If there are multiple Frequency Bands associated with the Radio type, Frequency Band may have a priority among Frequency Bands. For example, the Frequency Bands are listed in order of decreasing priority with the first Frequency Band being the highest priority in a list of Frequency Band, or in the opposite order. ・ Charging rate: This information may be associated with the Radio type. The Charging rate is referred as a charging rate if the UE 3 uses the associated Radio type for the Service. ・ Prohibited Partner PLMN: This information may be associated with the Service. The Prohibited Partner PLMN is referred as a PLMN where such PLMN is not allowed to provide DSMA PDU Session together with existing PLMN where the UE 3 has registered. The Prohibited Partner PLMN may be the Non-Public Network (NPN) including a Stand-alone Non-Public Network (SNPN) and a Public Network Integrated NPN (PNI-NPN). For example, the Prohibited Partner PLMN may indicate a PLMN which cannot provide DSMA PDU Session together with existing PLMN where the UE 3 has registered or together with a PLMN indicated by the above-mentioned "PLMN". For example, the Prohibited Partner PLMN may indicate a PLMN which cannot provide the above-mentioned "Service" or a service indicated by the above-mentioned "Service" together with existing PLMN where the UE 3 has registered or together with a PLMN indicated by the above-mentioned "PLMN". The Prohibited Partner PLMN may be indicated by a PLMN ID, NID, or GIN. ・ Allowed Services type: This information element indicates a set of network slices for which dual registration is allowed in two different PLMNs to get the service. For example, in a case where eMBB network slice(s) and mIoT network slice(s) are sent as a compatible network slice or Allowed Service type, the UE 3 can perform registration for the mIoT network slice(s)to a second PLMN while the UE 3 is registered for the eMBB network slice(s) in the first PLMN. Note that the compatible network slice is referred as a network slice that can be provided together with the other network slice. In one example, the Allowed Service type could be indicated as {eMBB (VPLMN 1, VPLMN 2), mIoT(VPLMN 3)}. This implies that when the UE 3 is registered to eMBB network slice in VPLMN 1 or VPLMN 2 the UE 3 can access service of mIoT network slice in the VPLMN 3. The UE 3 can't perform registration procedure to register for the mIoT network slice in a PLMN other than the VPLMN 3 when the UE 3 is registered for the eMBB network slice in a VPLMN 1 or VPLMN 2. In another example, a certain service (e.g., service on S-NSSAI 1) may be isolated for better 5G security and privacy. For example, a service on S-NSSAI 1 is available on PLMN 1 only and while a service on S-NSSAI 1 is active, no service on the other Radio Access is allowed. In this case, Allowed Service type may be indicated as {S-NSSAI#1 (PLMN#1), NULL (PLMN#2)}. In another example, only a particular slice / service type (SST) (e.g., eMBB) is supported by specific RATs. For example, terrestrial NR and E-UTRA support eMBB and URLLC SSTs and NTN NRs support eMBB and mIoT SSTs. ・ Alternative Service Source: Some services may be allowed from different sources, e.g. S-NSSAIs. For example, service(s) related to a particular company in Tokyo may be available via a S-NSSAI 33 related to the particular company while outside of Tokyo a smaller set of service(s) related to the particular company may be available via S-NSSAI 3 which provides service for multiple brand of cars. In such cases the Alternative Service Source information element may indicate the main S-NSSAI for a certain service (e.g. S-NSSAI 33) and also the Alternative S-NSSAI (e.g. S-NSSAI 3) for when the main service source is not available. ・ Validity time: This information may be associated with the Service. The Validity time is referred as a time duration which the Service is available. For example, the Validity time may indicate a time duration which the above-mentioned "Service" or a service indicated by the above-mentioned "Service" is available. The Validity time may take at least one of the following expressions: > Periodic service time indicator: it identifies whether the service time (e.g., duration or interval or time when the above-mentioned "Service" or a service indicated by the "Service" is provided) is updated periodically or not, for example, only on demand. The Periodic service time indicator may indicate whether the service time is periodically provided or not. > Service duration time: Duration interval time of Periodic service. The Service duration time may indicate duration or interval or time when the above-mentioned "Service" or a service indicated by the "Service" is provided or when the service time is updated. This information may be used together with Periodic service time indicator. Example: 8 hours. > Periodic time: Interval Time of Periodic service. This information may be used together with Periodic service time indicator. The Periodic time may indicate timing when the service time is updated or may indicate periodicity of the above-mentioned "Service" or a service indicated by the "Service". Example: every hour. > Scheduled service time: Time zone and Day of the week when the service (e.g., the above-mentioned "Service" or a service indicated by the "Service") is available. Example: Time: 12:00-22:00, Day: Sunday. ・ Incompatible service: This information may be associated with the Service. The incompatible service is referred as a service that cannot be provided together with the Service. ・ Prohibited area: This information may be associated with the Service. The Prohibited area is referred as a geographical location where the Service is prohibited to provide or cannot be provided. For example, Prohibited area can be a Tracking Area Identity (TAI), NR Cell Global Identity (NCGI) as defined in NPL 7, NR Cell Identity (NCI) as defined in NPL 7, E-UTRAN Cell Global Identifier (ECGI) as defined in NPL 7, Global Cable Identifier (GCI) as defined in NPL 7, a general City name, zip-code, formed with GPS location or a location expressed with civic and geospatial location formats as defined in NPL 10. ・ Paging policy: This information may be associated with the Service. The Paging policy includes a priority list for paging if the Service is available in multiple Radio types. For example, the Radio types are listed in order of decreasing priority with the first Radio type being the highest priority in a list of Radio type for paging, or in the opposite order. This list is referred by the UE 3, an AMF (e.g., an AMF 7001) and an SMF (e.g., an SMF 7101) for paging UE 3 when the UE 3 has DSMA PDU Session established and the UE 3 is in idle mode (e.g. CM-IDLE state or RRC Idle) or inactive state (e.g. RRC Inactive). It may be listed in Priority order. In addition, this information may also include a prohibited Radio type for paging. For example, LTE-M(GEO) (e.g., LTE-M provided under GEO condition or environment) is restricted for paging, as a huge paging resource consumption is expected. Hence, in a case where the Paging policy includes "LTE-M(GEO)" as the prohibited Radio type for paging, it may mean that the paging in LTE-M(GEO) is restricted. In this disclosure, the expression "Radio Type(AAA)" may mean that the Radio Type provided under "AAA" condition or environment. For example, "NR(GEO)" may mean that NR provided under GEO condition or environment. ・ Registration Trigger Criteria: This information may be associated with the Service. The UE 3 uses the Registration Trigger Criteria to trigger the registration procedure to a same PLMN or different PLMN when the UE 3 meets one of the following criteria. For example, the Registration Trigger Criteria may include the one of the following criteria. For example, the UE 3 may trigger or perform the registration procedure or re-registration procedure to a same PLMN or different PLMN in a case where one of the following criteria meets. > When the registration procedure with a VPLMN fails with some pre-defined reject cause. > When the registration to a network slice associated with an application in the UE 3 failed. > When the DSMA PDU session establishment procedure fails. > When the user plane establishment failed for an established DSMA PDU session. > When the UE 3 enters out of coverage for a specific Radio Access for a specific time, the UE 3 may trigger re-registration via the same Radio access or via different Radio Access. ・ Data path addition Triger Criteria: This information may be associated with the Service. The UE 3 uses Data path addition Triger Criteria to trigger to add a new data path to the established DSMA PDU Session when the UE 3 meets one of the following criteria. For example, the Data path addition Triger Criteria may include the one of the following criteria. For example, the UE 3 may add new data path to the established DSMA PDU Session in a case where one of the following criteria meets. > Whenever the UE 3 has a chance to add. > When the DSMA PDU Session becomes unstable. Example, radio link failure starts encountering. > When an upper layer, i.e., application in the UE 3 requires more bandwidth for data flow in the DSMA PDU Session. > When an access network (e.g. (R)AN) is congested or coverage of the access network is not stable. > When network detects that there is no policy which allows only a single access for a UE.
[0051] Each row in the DSATSSS Service profile(s) may be expressed as entry. For example, the first entry of Fig. 2 (i.e., the second row in the DSATSSS Service profile of Fig. 2) includes "Service" which is set to "S-NSSAI#1(MBB)", "Service provider" which is set to "PLMN independent", "Partner PLMN" which is set to at least one of "PLMN#2" and "PLMN#3", "Location" which is set to "Japan", "Radio Type" which is set to at least one of "NR", "EUTRA" and "NR(GEO)", and "Dual Steer conditions" which is set to parameter(s) as shown in Fig. 2 etc. The DSATSSS Service profile(s) may be expressed as information for multiple data connections over multiple 3GPP accesses or information for the DSMA PDU Session.
[0052] The DSATSSS Service may be discovered by the UE 3 before and / or after the UE 3 performs the Registration procedure. For example, the UE 3 may discover the DSATSSS service based on the DSATSSS Service profile(s). For example, in a case where the Service is provided by single PLMN, the Partner PLMN may not be included in the DSATSSS Service profile(s). The expression "A and / or B" in this disclosure may mean "at least one of A and B". Several DSATSSS Service discovery mechanisms are disclosed in Fig. 3.
[0053] The UE 3 can perform step 1 (e.g., step 1-1) and / or step 2 (e.g., step 2-1) for the DSATSSS service discovery without registering to any 3GPP system. I.e., the UE 3 initiates the Registration procedure to a target 3GPP access after the UE 3 confirms that the desired service is available over the target 3GPP access. For example, the UE 3 may initiate the Registration procedure to or on the target 3GPP access in a case where the UE 3 confirms that the desired service is available on the target 3GPP access based on the DSATSSS Service profile(s). On the other hand, the UE 3 has to register to any of 3GPP accesses to perform step 3 (including at least one of steps 3-1 and 3-2) and / or step 4 (including at least one of steps 4-1, 4-2 and 4-3) for the DSATSSS service discovery. While steps 1 and 2 provide general DSATSSS service discovery information to all UEs 3, steps 3 and 4 can provide a specific DSATSSS service discovery information to the UE 3.
[0054] Example 1 (Service profile broadcasted over own system information) This example includes a mechanism where system information over the Broadcast Control Channel (BCCH) advertises DSATSSS Services available with this 3GPP access (i.e., a target 3GPP access). The detailed processes of the DSATSSS service discovery in Example 1 are described below with reference to Fig. 3.
[0055] Step 1-1. The RAN 502 in VPLMN#2 broadcasts in the system information the DSATSSS Service profile(s) that the Uu interface 2 can provide by the RAN 502. For example, the RAN 502 may transmit the DSATSSS Service profile(s) in the system information (e.g. System Information Block 1 (SIB1) or other SIBx). The DSATSSS Service profile(s) transmitted by the RAN 502 may be related to the RAN 502 or VPLMN#2 where the RAN 502 is included. This system information is a service advertisement of the RAN 502. In order to obtain DSATSSS Services available with the Uu interface 2 with the RAN 502, the UE 3 may have to receive this system information of the RAN 502. The RAN in this disclosure may mean (R)AN node. The system information may include PLMN ID(s). The system information may include PLMN ID which is set to VPLMN#2 or PLMN#2. The RAN 502 may have the DSATSSS Service profile(s) in advance or may receive the DSATSSS Service profile(s) from other network nodes or may generate the DSATSSS Service profile(s) based on operator's policy. VPLMN#2 may be PLMN#2. The RAN 502 may broadcast in the system information the DSATSSS Service profile(s) per PLMN. The DSATSSS Service profile(s) per PLMN may be provided for the purpose of RAN sharing or roaming. The UE 3 may apply or follow the DSATSSS Service profile of a PLMN that the UE 3 is allowed to initiate registration procedure or the UE 3 had registered before.
[0056] Example 2 (Service profile broadcasted for other 3GPP access) This example includes a mechanism where system information over the BCCH advertises DSATSSS Services available with other 3GPP access(s). The detailed processes of the DSATSSS service discovery in Example 2 are described below with reference to Fig. 3.
[0057] Step 2-1. The RAN 501 in VPLMN#1 broadcasts in the system information over the BCCH the DSATSSS Service profile(s) that the Uu interface 1 can provide by the RAN 501. For example, the RAN 501 may transmit the DSATSSS Service profile(s) in the system information (e.g. SIB1 or other SIBx). The DSATSSS Service profile(s) transmitted by the RAN 501 may be related to other 3GPP access. This system information is a service advertisement of other 3GPP access. The RAN 501 may have a relation or coordination that may be done directly or indirectly via a core network node (e.g. AMF) connected with the RAN 501. In order to obtain DSATSSS Services available with the Uu interface 1 with the RAN 501, the UE 3 may have to receive the system information of the RAN 501. The system information may include PLMN ID(s). The system information may include PLMN ID which is set to VPLMN#1 or PLMN#1. The RAN 501 may have the DSATSSS Service profile(s) for another 3GPP access in advance or may receive the DSATSSS Service profile(s) for other 3GPP access from other network nodes or may generate the DSATSSS Service profile(s) for other 3GPP access based on operator's policy. VPLMN#1 may be PLMN#1. The RAN 501 may broadcast in the system information the DSATSSS Service profile(s) for other 3GPP access per PLMN. The UE 3 may store or use the DSATSSS Service profile for other 3GPP access of a PLMN that the UE 3 has registered or the UE 3 is allowed to register or access.
[0058] Example 3 (Service profile downloaded from the subscriber data) This example includes a mechanism that the UE 3 obtains the DSATSSS Services available from the subscriber data in the UDM 75. The detailed processes of the DSATSSS service discovery in Example 3 are described below with reference to Fig. 3.
[0059] Step 3-1. The UDM 75 in HPLMN sends an Nudm service message to the AMF 7001 in VPLMN#1 including the List of the DSATSSS Service profiles available in visited PLMN and UE location where the UE 3 roams to. The UDM 75 generates the List of the DSATSSS Service profiles for the UE 3 based on at least one of a visited PLMN information and location information that are provided by the AMF 7001 to the UDM 75 in advance. The List of the DSATSSS Service profiles sent by the UDM 75 may include at least one of the DSATSSS Service profile(s) described in step 1-1 and the DSATSSS Service profile(s) described in step 2-1.
[0060] Step 3-2. Upon reception of the Nudm service message from the UDM 75, the AMF 7001 sends a NAS message (e.g., a Registration Accept message or a UE Configuration Update message or any other existing or new NAS message) to the UE 3 including the received List of the DSATSSS Service profiles.
[0061] Example 4 (Service profile in the URSP rule) This example includes a mechanism that the UE 3 obtains the DSATSSS Services available from the URSP rule in the PCF 7303 in HPLMN. The PCF7303 determines the DSATSSS Services based on a subscription information (e.g., Network Slice subscription, roaming subscription etc.) of the UE 3, current condition in the HPLMN or VPLMN etc. The detailed processes of the DSATSSS service discovery in Example 4 are described below with reference to Fig. 3.
[0062] Step 4-1. The PCF 7303 sends an Npcf service message to the PCF 7301 in VPLMN#1 including the URSP rule that includes the List of the DSATSSS Service profiles available in visited PLMN and UE location where the UE 3 roams to. The PCF 7303 generates the List of the DSATSSS Service profiles for the UE 3 based on a visited PLMN information and location information that are provided to the PCF 7303 by the AMF 7001 via the PCF 7301 in advance. The PCF7303 may generate the List of the DSATSSS Services profiles based on a subscription information (e.g., Network Slice subscription, roaming subscription etc.) of the UE 3, current condition in the HPLMN or VPLMN etc. The List of the DSATSSS Service profiles sent by the PCF 7303 may include at least one of the DSATSSS Service profile(s) described in step 1-1 and the DSATSSS Service profile(s) described in step 2-1.
[0063] Step 4-2. Upon reception of the Npcf service message from the PCF 7303, the PCF 7301 sends an Npcf service message to the AMF 7001 including the received URSP rule that includes List of the DSATSSS Service profiles from the PCF 7303. The URSP rule including the List of the DSATSSS Service profiles may also be delivered directly to the UE 3 (i.e., transparent to the AMF 7001) within the UE Policy Update procedure triggered by the PCF 7301, as per NPL 5.
[0064] Step 4-3. Upon reception of the Npcf service message from the PCF 7301, the AMF 7001 sends a NAS message to the UE 3 including the received URSP rule that includes List of Service profiles.
[0065] Instead of the List of the DSATSSS Service profiles, the node (e.g., the UDM 75, the AMF 7001, the PCF 7303, or the PCF 7301) may send the DSATSSS Service profile(s). For example, the node may generate the DSATSSS Service profile(s) based on the above-mentioned information for generating the List of the DSATSSS Service profiles. The DSATSSS Service profile(s) sent by the node may include at least one of the DSATSSS Service profile(s) described in step 1-1 and the DSATSSS Service profile(s) described in step 2-1.
[0066] Variant 1 of First example of the First Aspect: In some cases, the available service profiles are stored in the AMFs 7001, 7002 and thus they are sent / broadcast to the UE(s) 3 as NAS messages through the RANs 501, 502.
[0067] Variant 2 of First example of the First Aspect: The UE 3 may register with VPLMN or SNPN partner networks to get the available service profiles in Registration Accept message by indicating the Registration type as PLMN or SNPN Onboarding Registration and giving request to send service profiles in Registration Request message.
[0068] First scenario in Second example of the First Aspect: The First scenario in the Second example of the First Aspect includes a Service Discovery Notification to users when a DSATSSS service becomes available. Fig. 4 explains an example of a Service Discovery Notification process that UE 3 may follow.
[0069] The detailed processes of the Service Discovery Notification are described below with reference to Fig. 4.
[0070] Step 1. The DSATSSS Service profile is installed in the UE 3. The DSATSSS Service profile may be installed by the procedure as disclosed in First example of the First Aspect or pre-installed in the UE 3. For example, in a case where the UE 3 receives the DSATSSS Service profile(s) or the List of the DSATSSS Service profiles, the UE 3 may install the DSATSSS Service profile(s) or the List of the DSATSSS Service profiles. The installing the List of the DSATSSS Service profiles may have same meaning installing the DSATSSS Service profile(s).
[0071] Step 2. The UE 3 may detect a 3GPP access that can provide a DSATSSS service by receiving system information at surrounding area with referencing the installed DSATSSS Service profile(s) at step 1. For example, the UE 3 may detect the 3GPP access (e.g., availability of the 3GPP access, at least one of a Uu interface 1 and a Uu interface 2 in Fig. 1, or availability of at least one of the Uu interface 1 and the Uu interface 2 in Fig. 1) based on the system information and the DSATSSS Service profile(s). For example, in a case where the UE 3 receives the system information including PLMN ID which is set to PLMN#2 and the installed DSATSSS Service profile includes an entry related to PLMN#2 (e.g., the entry including "Service provider" which is set to PLMN#2. For example, the example entry of the fifth row in Fig. 2), the UE 3 may detect the 3GPP access related to PLMN#2 that can provide the DSATSSS service or may determine that the 3GPP access related to PLMN#2 that can provide the DSATSSS service is available. In the same manner as the above, the UE may detect the 3GPP access related to PLMN#1 that can provide the DSATSSS service or may determine that the 3GPP access related to PLMN#1 that can provide the DSATSSS service is available.
[0072] Step 3. The UE 3 may collect the following useful information for end user(s) of the UE 3 with regard to the detected 3GPP access that can provide the DSATSSS service.
[0073] ・ Congestion level: The RAN 501 and RAN 502 may broadcast congestion related information in the existing system information (e.g. SIB1) or in a new system information (e.g. SIBx). Fig. 5 illustrates that RAN 501 and RAN 502 broadcast congestion related information in the system information over the BCCH. The congestion related information may be per RAN basis, per cell basis, per network slice basis, or combination of these granularities. The congestion information may be Uplink congestion level for user data transmission and / or Downlink congestion level for user data transmission. For example, if the congestion information is per RAN basis, the RAN 501 and RAN 502 obtain the congestion level in RAN by measuring the Uplink packet scheduler, Downlink packet scheduler, CPU occupation level and so on. For example, if the congestion information is per cell basis, the RAN 501 and RAN 502 sends the list of cells with associated the General Congestion level, Uplink congestion level and Downlink congestion level. For example, the congestion level in each cell may be provided to the RAN 501 and RAN 502 via O&M interface. For example, if the congestion information is per network slice basis, the RAN 501 and RAN 502 may obtain the network slice congestion information from the AMF. The congestion related information may indicate or imply a congestion level. The congestion level may have a certain (predefined) range (e.g. integer values). Alternatively, the congestion related information may indicate or imply a congestion status. The congestion status may be binary information (e.g. congested or non-congested). The RAN 501 and RAN 502 may broadcast congestion related information per PLMN. The congestion related information (e.g., the Congestion level) can be mapped to a percentage numeric value (ex. 20%) by the UE 3. For example, the Congestion level may be provided to the UE 3 in the form of the percentage numeric value (ex. 20%).
[0074] ・ Bit rate: The RAN 501 and RAN 502 may broadcast bit rate related information in the existing system information or in a new system information. Fig. 6 illustrates that RAN 501 and RAN 502 broadcast bit rate related information in the system information over the BCCH. The bit rate related information may be per RAN basis and / or per cell basis. The bit rate information may be current bit rate, expected bit rate, guaranteed bit rate or maximum bit rate or all of them. The bit rate related information may be current Uplink bit rate for user data transmission and / or current Downlink bit rate for user data transmission. The RAN 501 and RAN 502 may broadcast bit rate related information per PLMN. For example, the Bit rate may be provided to the RAN 501 and RAN 502 via O&M interface. For example, the Bit rate may be measured by the RAN 501 and RAN 502. For example, the Bit rate may be provided to the RAN 501 and RAN 502 via other network node(s).
[0075] ・ RTT (Round Trip Time): The RTT related information may be measured by UE 3. Fig. 7, Fig. 8 and Fig. 9 illustrate the RTT measurement process at AS level, NAS level and Application level respectively.
[0076] RTT measurement at AS level The detailed processes of the RTT measurement at AS level are described below with reference to Fig. 7.
[0077] Step 1: The Application in the UE 3 requests to the AS layer of the UE 3 for RTT measurement at AS level. For example, the UE 3 may request the RTT measurement.
[0078] Step 2: After the Application in the UE 3 requests the measurement at step 1, the UE 3 starts the timer awaiting a response to come.
[0079] Step 3: The AS layer in the UE 3 sends an UL RRC message to the RAN 501. The RRC message may indicate that this message is for bit rate measurement purpose and that the AS layer expects RAN 501 to response as soon as the RAN 501 receives this RRC message. The RRC message may be an RRC Setup Request message, UL Information Transfer message, UL Dedicated Message Segment message, Measurement Report App Layer message or another existing RRC message or new RRC message.
[0080] Step 4: After the RAN 501 receives the RRC message that is sent at step 3, the RAN 501 replies to the UE 3 by sending a DL RRC message. The DL RRC message may be a kind of reply message to the UL RRC message at Step 3. The DL RRC message may be RRC Setup message, DL Information Transfer message, DL Dedicated Message Segment message or another existing RRC message or new RRC message. The DL RRC message may be expressed as an RRC response message. For example, in a case where the RAN 501 receives the UL RRC message, the RAN 501 may measure the bit rate. For example, the RAN 501 may send the DL RRC message including the measured bit rate.
[0081] Step 5: After the AS layer in the UE 3 receives the RRC reply message from the RAN 501, the AS layer in the UE 3 reports to the Application. For example, the AS layer in the UE 3 may send the measurement report including the measured bit rate or notification that the AS layer receives the RRC reply message to the Application.
[0082] Step 6. Once the Application receives the measurement report or the notification from the AS layer, the Application stops the timer started at step 2, and measures an RTT between UE 3 and RAN 501. For example, the RTT in this disclosure may indicate duration or interval between the time when the timer starts and the timer ends or stops. In the same manner as the above, the UE 3 may measure the RTT for VPLMN#2.
[0083] In addition to or alternatively to the above example, the UE3 may measure the propagation delay based on the DL window (e.g. DL received timing of a reference signal or synchronization signal) and the UL transmission timing (e.g. timing advance informed from the RAN 501). The UE 3 may take the propagation delay into account for the RTT measurements or use the propagation delay as the RTT.
[0084] RTT measurement at NAS level The detailed processes of the RTT measurement at NAS level are described below with reference to Fig. 8.
[0085] Step 1: The Application in the UE 3 requests to the NAS layer of the UE 3 for RTT measurement at NAS level for the DSATSSS Service. For example, the UE 3 may request the RTT measurement.
[0086] Step 2: After the Application in the UE 3 requests the measurement at step 1, the UE 3 starts the timer awaiting a response to come.
[0087] Step 3: The AS layer in the UE 3 sends an UL RRC message to the RAN 501 including at least one of the indication that this message is for RTT measurement purpose, NAS RTT and RB identifier. The NAS RTT indicates that this measurement request is for an RTT measurement between the UE 3 and the UPF 7201 in VPLMN#1. The RB identifier identifies the Radio Bearer over the Uu interface. The UL RRC message may be an RRC Setup Request message, UL Information Transfer message, UL Dedicated Message Segment message, Measurement Report App Layer message or another existing RRC message or new RRC message.
[0088] Step 4: When the UL RRC message in step 3 includes the NAS RTT, the RAN 501 converts the received RB identifier to a PDU Session ID for the DSMA PDU Session and finds the associated UPF 7201. For example, the RAN 501 may store information for the converting and information for the finding. The RAN 501 sends the GTP Echo Request message to the UPF 7201. The RAN 501 may start a timer waiting for the GTP Echo response message to come from the UPF 7201. In a case where the received RB identifier is mapped with SRB (Signalling Radio Bearer) in the RAN 501, the RAN 501 sends an NGAP message, instead of the GTP Echo Request message, to the AMF 7001 and may start a timer waiting for the NGAP response message to the NGAP message to come from the AMF 7001. The NGAP message may be existing NGAP message or new NGAP message. For example, in a case where the received RB identifier is mapped with RB other than the SRB, the RAN 501 may send the GTP Echo Request message to the UPF 7201.
[0089] Step 5. Upon reception of the GTP Echo message from the RAN 501, the UPF 7201 sends the GTP Echo response message to the RAN 501. If the timer started at step 4 is running and the RAN 501 receives the GTP Echo response message, then the RAN 501 stops the timer and measure an RTT between the RAN 501 and the UPF 7201 over the N3 interface. This RTT may be expressed as N3 RTT.
[0090] In a case where the AMF 7001 receives the NGAP message, the AMF 7001 sends the NGAP response message to the RAN 501. The NGAP response message may be existing NGAP message or new NGAP message. If the timer started at step 4 is running and the RAN 501 receives the NGAP response message, then the RAN 501 stops the timer and measure an RTT between the RAN 501 and the AMF 7001 over the N2 interface. This RTT may be expressed as N2 RTT.
[0091] Step 6. After the RAN 501 receives the GTP Echo Response message from the UPF 7201 or the NGAP response message from the AMF 7001 at step 5, the RAN 501 replies to the UE 3 by sending a DL RRC message. The DL RRC message may include the N3 RTT or N2 RTT that is measured at the step 5. The DL RRC message may be an RRC Setup message, DL Information Transfer message, DL Dedicated Message Segment message or another existing RRC message or new RRC message. The DL RRC message may be a kind of response message to the UL RRC message at step 3.
[0092] Step 7: After the AS layer in the UE 3 receives the DL RRC message from the RAN 501, the AS layer in the UE 3 reports to the Application. The measurement report may include the N3 RTT or N2 RTT. For example, the AS layer may send the N3 RTT or N2 RTT to the Application.
[0093] Step 8. Once the Application receives the measurement report from the AS layer, the Application stops the timer started at step 2, and measures the RTT between UE 3 and RAN 501. The Application may consider the received N3 RTT or N2 RTT as a delay time generated between the RAN 5 and the UPF 7201 or between the RAN 5 and AMF 7001.
[0094] In the same manner as the above, the UE 3 may measure the RTT for VPLMN#2
[0095] RTT measurement at Application level The detailed processes of the RTT measurement at Application level are described below with reference to Fig. 9.
[0096] Step 1: The Application in the UE 3 sends a RTT measurement request message to the AF 201 in data network to measure an RTT between UE 3 and AF 201 for the DSATSSS Service. For example, the Application may send the RTT measurement request message to the AF 201 via Uu interface 1 shown in Fig. 1 (e.g., via the RAN 501 and UPF 72). The RTT measurement request message may be a specific message to the DSATSSS Service or generic message. In one example, the RTT measurement request message may be based on the Internet Control Message Protocol (ICMP) as defined in NPL 11 or NPL 12. For example, the UE 3 may request the measurement.
[0097] Step 2: After the Application in the UE 3 requests the measurement at step 1, the UE 3 starts the timer waiting for a response to come.
[0098] Step 3: Upon reception of the RTT measurement request message from the UE 3, the AF 201 sends the RTT measurement response message to the UE 3. The RTT measurement response message may be a specific message to the DSATSSS Service or generic message. In one example, the RTT measurement response message may be based on the Internet Control Message Protocol (ICMP) as defined in NPL 11 or NPL 12.
[0099] Step 4. Once the Application receives the RTT measurement response message from the AF 201, the Application stops the timer started at step 2, and measures the RTT (Round Trip Time) between the UE 3 and the AF 201.
[0100] Back to the explanation of the following useful information.
[0101] ・ Charging rate: The Charging rate information helps end users when the end user adds one data connection to established DSATSSS service. The Charging rate information may be obtained by UE 3 via the System information or interrogating to the AF 201 as illustrated in Fig. 10 and Fig. 11 respectively.
[0102] Charging rate broadcasted in system information over BCCH Fig. 10 illustrates that RAN 501 and RAN 502 broadcast the Charging rate information in a system information over the BCCH. The Charging rate information may be per RAN basis and / or per cell basis. The Charging rate information may be Charging rate information for home subscriber and another Charging rate information for inbound roamer. Further the Charging rate information for inbound roamer may be per PLMN basis where inbound roamer comes from. For example, the RAN 501 and the RAN 502 may configure or generate the Charging rate information based on operator's policy or may have the Charging rate information in advance, or receive the Charging rate information from other network node(s). The Charging rate information may indicate charge for using the DSATSSS service. The Charging rate information may indicate charge for using the DSATSSS service per unit time.
[0103] Charging rate provided by AF Fig. 11 illustrates that Charing rate information is obtained from the AF.
[0104] The detailed processes of the Charging rate information interrogation to the AF are described below with reference to Fig. 11.
[0105] Step 1: The Application in the UE 3 sends a Charging rate query message to the AF 201 including at least one of DSATSSS Service (e.g., "Service" in Fig. 2), PLMN and Radio Type. The PLMN indicates a PLMN that provides the 3GPP access for the DSATSSS Service. The Radio Type indicates a Radio Type of the 3GPP access. For example, the Radio Type may indicate "Radio Type" in Fig. 2.
[0106] Step 2: Upon reception of the Charging rate query message from the UE 3, the AF 201 sends the Charging rate reply message to the UE 3 including the Charging rate information for the UE 3. For example, in a case where the UE 3 uses the 3GPP access for the DSATSSS Service with indicated PLMN and indicated Radio Type in the Charging rate query message in step 1, the AF 201 may send the Charging rate information for the indicated DSATSSS Service corresponding to the indicated PLMN and indicated Radio Type.
[0107] ・ SNPN (Stand-alone Non-Public Network) related information: If a 3GPP access is provided by the SNPN, the information may be collected by the UE 3. The SNPN related information may include at least one of the followings. > PLMN ID > List of Network identifier (NID) > A human-readable network name (HRNN) > List of supported Group IDs for Network Selection (GINs)
[0108] ・ PNI-NPN (Public Network Integrated NPN) related information: If a 3GPP access is provided by the PNI-NPN, the information may be collected by the UE 3. The PNI-NPN related information may include at least one of the followings. > PLMN ID > Closed Access Group (CAG) identifier > A human-readable network name (HRNN)
[0109] It refers again to Fig. 4. Step 4. After the UE 3 collects the useful information for end user(s) at step 3, the AS layer of the UE 3 reports all relevant information to the upper layer of the UE 3.
[0110] Step 5. The upper layer of the UE 3 indicates the reported information in step 4 to end user(s) by easy-to-understand ways. For example, the upper layer of the UE 3 may display icons for candidate 3GPP access for the DSATSSS Service. For example, the upper layer of the UE 3 may display icons for candidate 3GPP access for the DSATSSS Service based on the useful information.
[0111] The Second scenario in Second example of the First Aspect discloses examples how the UE 3 displays access information (e.g., the icon(s)) available to the DSATSSS Service.
[0112] Second scenario in Second example of the First Aspect: The Second scenario in the Second example of the First Aspect discloses examples about how the UE 3 displays access information available to the DSATSSS Service. Some relevant information to be displayed are obtained by the process as disclosed by the first scenario in the Second example of the First Aspect.
[0113] There are basically two types of information to be notified to end user(s) by easy-to-understand ways. One type is 3GPP access related information available to the UE and the other type is 3GPP access related information available to specific Service including DSATSSS Services.
[0114] 3GPP access related information available to the UE Fig. 12 illustrates examples to display 3GPP access availability information by relevant Icons. Some information is equally applicable to non-3GPP access as well. (e.g., Wi-Fi access)
[0115] ・ Congestion level: Congestion level can be expressed by putting colour to access network Icon. For example, if there is no congestion with an access network (for example congestion level is less than 20%.), the Icon to such access network has green colour. For example, if there is a little congestion with an access network (for example congestion level is between 20% to 80%.), the Icon to such access network has yellow colour. For example, if there is a heavy congestion with an access network (for example congestion level is above 80%.), the Icon to such access network has red colour. Alternatively, congestion level may be indicated as L for low, M for medium, and H for high. One another way to indicate congestion level is representing in terms of percentage (e.g., 40%). For example, in a case where the Congestion level of a 3GPP access 1 indicates 19% and the UE 3 has registered by using the 3GPP access 1, the UE 3 may display the leftmost icon in Fig. 12.
[0116] ・ Candidate 3GPP access: If the UE 3 has discovered 3GPP access network available but not yet registered, the Icon for that 3GPP access network has an associated text. For example, an associated text can be "Available", "Standby", "Ready", "Ready to use", "Backup access", "Alternative access" or "emergency access". The following bullets explains their meaning as example: > Available: indicated access is available and activated. > Standby: indicated access is available and ready to use. > Ready: indicated access is available and ready to use. > Ready to use: indicated access is available and ready to use. > Backup access: indicated access is available and ready to use as a backup access. > Alternative access: indicated access is available and ready to use. > emergency access: indicated access is available and ready to use only for emergency purpose. In a case where the Icon for that 3GPP access network without the associated text may mean that the UE 3 has discovered 3GPP access network available and has registered to the 3GPP access network. The 3GPP access may be expressed as the 3GPP access network. For example, in a case where the UE 3 recognizes that the Non terrestrial access is available (e.g., in a case where the UE 3 receives the Service profile provided by the RAN 502 (e.g., the RAN 502 related to the Non terrestrial access or NTN) as shown in step 1-1 of Fig. 3), the UE 3 may display the second icon in the right in Fig. 12. For example, in a case where the UE 3 recognizes that the Non terrestrial access is available (e.g., in a case where the UE 3 receives the Service profile provided by the RAN 502 (e.g., the RAN 502 related to the Non terrestrial access or NTN) as shown in step 1-1 of Fig. 3) and the UE 3 has not registered by using the Non terrestrial access, the UE 3 may display the second icon in the right in Fig. 12.
[0117] ・ RAT Type: If 3GPP access is provided via the satellite, the Icon for such access network has a unique Icon that can be easy-to-understand for end users.
[0118] ・ NPN: If 3GPP access is provided by the SNPN or PNI-NPN, the Icon to such access network has a unique Icon that can be easy-to-understand for end users. An Icon of 3GPP access is provided by the SNPN or PNI-NPN can be customized by the UE 3 based on the collected information. For example, based on the Network Identifier (NID), Group IDs for Network Selection (GIN), Closed Access Group (CAG) or human-readable network name, the Icon can be generated to unique Icon reflecting that information. If the human-readable network name has a name of Company A, the Icon for that 3GPP access has a Company name A in the Icon.
[0119] Fig. 13 illustrates an example how the UE 3 selects a 3GPP access network more automatic way by utilizing the 3GPP access network related information collected by the process as disclosed by the first scenario in the second example of the First Aspect.
[0120] The Connection Setting menu has the following setting in the UE 3. Some of them are not illustrated in Fig. 13.
[0121] RAT selection criteria: It is used to specify how a RAT to be selected. See the following bullet as example criteria for RAT selection: ・ Always 3GPP RAT. 3GPP RAT may be further sub-categorized into TN and NTN. ・ RAT selection priority whenever accesses are available. For example, Wi-Fi has a highest priority while 3GPP access is second priority. ・ RAT selection priority taking data rate into account. For example, move to Wi-Fi if 3GPP access has less than 100 Mbps for DL packet transmission. ・ RAT selection priority taking congestion into account. For example, move to Wi-Fi if 3GPP access has heavily congested.
[0122] Dual Steer indication: It is used to activate the DSATSSS Service. Connection setting per Application: The RAT selection criteria and Dual Steer indication as listed above can apply per Application basis.
[0123] For example, if a user or a mobile system (e.g., UE system) selects "ON" for "3GPP RAT only" in Fig. 13, 3GPP RAT is selected. For example, if a user or a mobile system (e.g., UE system) selects "ON" for "High Speed RAT" in Fig. 13, high speed RAT will be selected. For example, a RAT type that is less congested will be selected. For example, a RAT type which provides high speed communication will be selected. For example, if a user or a mobile system (e.g., UE system) selects "ON" for "Cheapest RAN" in Fig. 13, the RAN with low communication charges will be selected. For example, a user or its mobile system (e.g., UE system) selects "ON" for "Dual Steer Connection" in Fig. 13, DSATSSS Service will be activated. For example, if a user or a mobile system (e.g., UE system) selects the "Customized Setting" per Application setting, the RAT type or RAN can be selected per Application basis.
[0124] Fig. 14 illustrates an example how end user(s) monitors a current status of access networks available to the UE 3.
[0125] The Connection Status menu provides the following access network information available to the UE 3. Some of them are not illustrated in Fig. 14. Note that the MNO as Mobile Network Operator in Fig. 14 corresponds to the PLMN. For example, the UE 3 may know in advance or receive from other network node(s) correspondence between the MNO and the PLMN. For example, the UE 3 may display the MNO based on the correspondence and the received PLMN ID. The MNO may be a well-known operator name in the market. For example, "ABC Mobile".
[0126] Data rate (e.g., "Speed" in Fig. 14): It indicates the current data rate, one for Uplink data transmission and the other one for Downlink data transmission. For example, the UE 3 may display the Data rate based on the information received in Fig. 6. For example, the UE 3 may display the received bit rate related information of Fig. 6. Charging rate: It indicates the charging rate if UE 3 uses that 3GPP access network. It can be charging rate in local currency per packet, flat rate in local currency or Free of charge. For example, the UE 3 may display the Charging rate based on the information received in at least one of Fig. 10 and Fig. 11. For example, the UE 3 may display the received Charging rate information of at least one of Fig. 10 and Fig. 11. Signal Strength: It indicates a Signal Strength of current access network. Congestion level: It indicates a congestion level of current access network. For example, the UE 3 may display the Congestion level based on the information received in at least one of Fig. 5, Fig. 7, Fig. 8 and Fig. 9. For example, the UE 3 may display the received congestion related information of Fig. 5.
[0127] 3GPP access related information available to specific Service Fig. 15 illustrates examples to indicate 3GPP access availability information to specific service. This indication may be equally applicable to non-3GPP access as well. (e.g., Wi-Fi access)
[0128] ・ Congestion level: Congestion level can be expressed by putting specific colour to the Application Icon. For example, if there is no congestion with an access network for the application (for example congestion level is less than 20%.), the Application Icon has a green colour. For example, if there is a little congestion with an access network for the application (for example congestion level is between 20% to 80%.), the Application Icon has a yellow colour. For example, if there is a heavy congestion with an access network for the application (for example congestion level is above 80%.), the Application Icon has a red colour. The Congestion level may be provided to the UE 3 (e.g. the Application in the UE 3) by the AF 201. The Congestion level may be provided per Application in the UE 3 to the UE 3 (e.g. the Application in the UE 3) by the AF 201. The AF 201 may measure the Congestion level. The congestion related information (e.g., the Congestion level) can be mapped to a percentage numeric value (ex. 20%) by the UE 3. For example, the Congestion level may be provided to the UE 3 in the form of the percentage numeric value (ex. 20%). For example, the UE 3 may display the Congestion level. For example, in a case where the Congestion level of an Application 1 (APL 1) in the UE 3 indicates 19%, the UE 3 may display the "APL 1" icon by putting green colour as shown in Fig. 15.
[0129] According to at least one of disclosure(s) in First Aspect, it can solve at least one of the above-mentioned problem(s). For example, at least one of disclosure(s) in First Aspect can solve the problem that the above-mentioned service requirement has not been supported by the 5GS yet. For example, at least one of disclosure(s) in First Aspect can solve the problem that the DSATSSS service does not work.
[0130] For example, according to at least one of disclosure(s) in First Aspect, at least one of the RAN and the AMF may send the Service profile(s) to the UE. Therefore, it can solve at least one of the above-mentioned problem(s). For example, according to at least one of disclosure(s) in First Aspect, the UE may collect the useful information (e.g., measurement information) and display at least one of the useful information and information based on the useful information. Therefore, it can solve at least one of the above-mentioned problem(s).
[0131] In this all First Aspect, enumerated parameter or information in a message may be expressed as information for multiple data connections over multiple 3GPP accesses, information for multiple data connections over multiple 3GPP access networks or information for the DSMA PDU Session.
[0132] <Second Example Embodiment (Second Aspect)> This aspect includes mechanisms to provide the Dual Steering ATSSS (DSATSSS) service in single PLMN or spanning to multiple PLMNs. In a case where the DSATSSS service spans to multiple PLMNs, each PLMN provides a single connection and two single connections configure the DSMA PDU Session. The DSATSSS service may have more than two single connections. I.e., the DSMA PDU Session may have three or more single connections spanning multiple PLMNs. All examples in this aspect are fundamentally applicable to the case where the DSMA PDU Session has three or more single connections spanning multiple PLMNs.
[0133] First example of the Second Aspect: Fig. 16 illustrates an example of the architecture that provides the DSATSSS service in single PLMN or in multiple PLMNs.
[0134] Fig. 16 illustrates a case where two single connections are established, one is over the VPLMN#1 and the other one is over the VPLMN#2 and DSMA PDU Session is anchored in the HPLMN as a home routed DSMA PDU Session. The basic principle of this architecture is listed below. ・ The UE 3 has single USIM and corresponding single subscriber data in the UDM 75. ・ Each single connection has its own temporary user identifier (i.e., 5G-GUTI) and corresponding UE contexts in 5GC. ・ Registration management and Session management for each single connection are independent.
[0135] The V-PCF may be expressed as PCF. The H-PCF may be expressed as PCF.
[0136] First scenario in Second example of the Second Aspect: Fig. 17 illustrates an example of the Registration procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0137] The detailed processes of the First scenario in Second example of the Second Aspect are described below with reference to Fig. 17.
[0138] Step 0. The UDM 75 in HPLMN maintains Service profiles for subscribed DSATSSS services (e.g., the DSATSSS Service profile(s)) in subscriber data for the UE 3. In this disclosure, the Service profile(s) may be expressed as DSATSSS Service profile(s).
[0139] Step 1. The UE 3 sends a Registration Request message to an AMF 7001 in VPLMN#1 including at least one of User ID, Dual Reg support, Reg Id set to 1 and Extended UE radio capability. For example, the UE 3 may send the Registration Request message for the DSMA PDU Session. For example, the UE 3 may perform a Registration procedure for the DSMA PDU Session by sending the Registration Request message. The following bullets explain each parameter in detail. ・ User ID (e.g., the User ID may be expressed as User Identity) may be a 5G-GUTI, SUCI or SUPI. ・ Dual Reg support indicates a capability of the UE 3 for managing two or more temporary user identifiers (i.e., 5G-GUTIs) in 3GPP access to support DSATSSS service. The Dual Reg support also indicates an ability or a capability of the UE 3 to support DSMA PDU Session. The Dual Reg support may indicate a capability of the UE 3 for managing two or more temporary user identifiers (i.e., 5G-GUTIs) in 3GPP accesses to support DSATSSS service. The Dual Reg support may have another name, for example, Dual Steer support, Dual Steer capability, DSMA PDU Session capability, DSMA PDU Session support and etc. ・ Reg Id identifies a temporary user identifier (i.e., 5G-GUTI) assigned to the UE 3. Reg Id may be a normalized value. For example, Reg Id which is set to 1 means that numeric value 1 corresponds to a 5G-GUTI that the AMF 7001 is going to assign to the UE 3 after successful Registration procedure. For example, Reg Id may indicate or identify the Registration procedure. ・ Extended UE radio capability includes an extended UE radio capability that supports DSATSSS service, for example, a support of new frequency band and / or new radio access technology dedicatedly designed to the DSATSSS service. For example, the Extended UE radio capability or the extended UE radio capability may indicate that the UE 3 has dual radio capability to support one terrestrial network (TN) RAT (e.g., NR, E-UTRA) and one NTN RAT (e.g., LEO, MEO, GEO), or two TN RATs (e.g., NR+NR, NR+E-UTRA, E-UTRA+E-UTRA), or two NTN RATs (e.g., LEO+GEO, LEO+MEO, MEO+GEO). The Extended UE radio capability may indicate that the UE 3 can listen to only one Paging channel at a time.
[0140] In this disclosure, a symbol "=" may mean "set to". For example, "Reg Id=1" may mean "Reg Id set to 1" or "Reg Id which is set to 1". In this disclosure, enumerated parameter or information in a message may be parameter or information indicating the enumerated parameter or information. For example, "Dual Reg support" parameter or information in the Registration Request message may be information or parameter indicating "Dual Reg support", or information or parameter indicating a capability of the UE 3 for managing two or more temporary user identifier (i.e., 5G-GUTI) in 3GPP access to support DSATSSS service. In this disclosure, enumerated parameter or information in a message may be expressed as information for multiple data connections over multiple 3GPP accesses, information for multiple data connections over multiple 3GPP access networks or information for the DSMA PDU Session. For example, the UE 3 may select the VPLMN#1 based on the Service profile(s) in the UE 3, and send the Registration Request message.
[0141] Step 2. Upon reception of the Registration Request message in step 1, the AMF 7001 sends an Nudm_UECM_Registration Request message to a UDM 75 including at least one of the Dual Reg support, the Reg Id set to 1, the Extended UE radio capability, UE cell location and Radio Type. For Dual Reg support, the Reg Id and the Extended UE radio capability refer to step 1 for parameter details. The following bullets explain each parameter in detail. ・ The UE cell location indicates a UE location, where the UE cell location is provided by the RAN 501 in the Initial UE message when the Initial UE message carries the Registration Request message to the AMF 7001. ・ The Radio Type indicates the Radio Type as defined in the First example of the First Aspect. The Radio Type is also provided by the RAN 501 in the Initial UE message when the Initial UE Message carries the Registration message to the AMF 7001. For example, the Radio Type may indicate the Radio Type supported by the RAN 501 or VPLMN#1.
[0142] For example, in step 1, the RAN 501 may receive the Registration Request message within an RRC message from the UE 3 and the RAN 501 may send the Initial UE message including the Registration Request message to the AMF 7001. The AMF 7001 may receive, from the RAN 501, the Initial UE message including the Registration Request message. The Initial UE message may include the UE cell location. In this case, the UE cell location may indicate the UE location (e.g., the UE 3's location) where the RAN 501 provides or sends the Initial UE message. The UE cell location may indicate the UE location (e.g., the UE 3's location) where the UE 3 sends the Registration Request message. Then the AMF 7001 may send the Nudm_UECM_Registration Request message to a UDM 75 including at least one of the Dual Reg support, the Reg Id set to 1, the Extended UE radio capability, the UE cell location and the Radio Type. For example, the AMF 7001 may send the Nudm_UECM_Registration Request message for the DSMA PDU Session. For example, the AMF 7001 may perform a Registration procedure for the DSMA PDU Session by sending the Nudm_UECM_Registration Request message. In this disclosure, each node or function may store at least one of information sent in the message and information included in the received message. In this disclosure, the UE 3 may be in at least one of VPLMN#1 and VPLMN#2. In this disclosure, the UE 3 may be in at least one of HPLMN, VPLMN#1 and VPLMN#2.
[0143] Step 3. Upon reception of the Nudm_UECM_Registration Request message in step 2, the UDM 75 sends an Nudm_UECM_Registration Response message to the AMF 7001. In one example, the Nudm_UECM_Registration Response message may contain at least one of Dual Reg Allowed and the DSATSSS Service profile for Reg Id set to 1 which the AMF 7001 may store in the UE 3 context within the AMF 7001. In this case (e.g., in a case where the Nudm_UECM_Registration Response message contains at least one of the Dual Reg Allowed and the DSATSSS Service profile for Reg Id set to 1), the AMF 7001 may not execute step 4. The UDM 75 may remember that the AMF 7001 is associated with the Reg Id set to 1.
[0144] Step 4. After the completion of the Nudm_UECM_Registration service in steps 2 and 3, the AMF 7001 sends an Nudm_SDM_Get Request message to the UDM 75 including at least one of the Dual Reg support, the Reg Id set to 1, the Extended UE radio capability, the UE cell location and the Radio Type. Refer to step 2 for parameter details. For example, the AMF 7001 may send the Nudm_SDM_Get Request message for the DSMA PDU Session. For example, the AMF 7001 may perform a Registration procedure for the DSMA PDU Session by sending the Nudm_SDM_Get Request message.
[0145] Step 5. The UDM 75 finds Subscriber data for the UE 3 and sends an Nudm_SDM_Get Response message to the AMF 7001 including the Subscriber data for the UE 3. The Subscriber data includes at least one of the Service profile(s) for DSATSSS services (e.g., DSATSSS Service profile(s)) that are applicable to Reg Id set to 1 (or that are for Reg Id set to 1 or that are related to Reg Id set to 1) and Dual Reg Allowed. The Service profile may be chosen by the UDM 75 based on at least one of the UE cell location, Radio type and roamed AMF. The Service profile of DSATSSS service is defined in the First example of the First Aspect. For example, in this disclosure, the UDM 75 may store the DSATSSS Service profile(s) per at least one of Reg Id (e.g., 5G-GUTI), UE and PLMN. The following bullets explain each parameter in detail. ・ Dual Reg Allowed indicates that the UE 3 is allowed to have multiple registrations in 3GPP access and allowed to establish DSMA PDU Session. Optionally, the Dual Reg Allowed may include the maximum number of single data connection that the DSMA PDU Session can configure. For example, if the Dual Reg Allowed has a numeric value three, the DSMA PDU Session can have up to three single data connection within 3GPP access for the DSMA PDU Session.
[0146] For example, in a case where the UDM 75 receives at least one of the Dual Reg support and the Extended UE radio capability, the UDM 75 may include at least one of the Dual Reg Allowed and the Service profile(s) in the Nudm_UECM_Registration Response message or the Nudm_SDM_Get Response message.
[0147] For example, in a case where the UDM 75 receives the UE cell location, the UDM 75 may find the Service profile(s) which includes an entry (or entries) corresponding to the UE cell location. For example, in a case where the UE cell location indicates location(s) of cell(s) in Japan or location(s) in Japan, the UDM 75 may find at least one of the first entry, the third entry and the fourth entry in Fig. 2, and may include at least one of the first entry, the third entry and the fourth entry in the Nudm_SDM_Get Response message as the Service profile(s).
[0148] For example, in a case where the UDM 75 receives the Radio Type, the UDM 75 may find the Service profile(s) which includes an entry (or entries) corresponding to the Radio Type. For example, in a case where the Radio Type indicates NR(GEO), the UDM 75 may find at least one of the first entry and the fourth entry in Fig. 2, and may include at least one of the first entry and the fourth entry in the Nudm_SDM_Get Response message as the Service profile(s).
[0149] As the UDM 75 receives Reg Id which is set to 1 and finds the Service profile(s), the UDM 75 may know that the found Service profile(s) corresponds to or related to Reg Id which is set to 1. In addition, the UDM 75 may store information indicating that the found Service profile(s) corresponds to or related to Reg Id which is set to 1. For example, in a case where the UDM 75 sends the Service profile(s), the UDM 75 may indicate that the Service profile(s) is for or is related the received Reg Id (e.g., Reg Id which is set to 1). For example, in a case where the UDM 75 receives the message in step 2 or step 4, the UDM 75 may understand that the AMF 7001 is associated with or linked with Reg Id which is set to 1. For example, in a case where the UDM 75 receives the message in step 2 or step 4, the UDM 75 may store information indicating that the AMF 7001 is associated with or linked with Reg Id which is set to 1.
[0150] The same or similar way to find the Subscriber data may be applied to other aspect(s).
[0151] Step 6. After the AMF 7001 obtains the Subscriber data for the UE 3 from the UDM 75 in step 5 and if the UE 3 indicated support for Dual Registration in step 1 (e.g., in a case where the UE 3 sends at least one of the Dual Reg support and the Extended UE radio capability to the AMF 7001 in step 1), the AMF 7001 sends a Registration Accept message to the UE 3 including at least one of 5G-GUTI (e.g., 5G-GUTI1), the Dual Reg Allowed and the Service profile for the Reg Id set to 1. For Dual Reg Allowed, refer to step 5 for parameter details. When the UE 3 receives the Service profile(s) for the Reg Id set to 1, the UE 3 stores received Service profile(s) by linking with the Reg Id set to 1. For example, the UE 3 stores the Service profile(S) for the Reg Id set to 1 in non-volatile memory in the UE 3 by linking with the Reg Id set to 1. For example, the UE 3 may store the received Service profile(s) and associates or links the stored Service profile(s) with the Reg Id set to 1. The VPLMN#1 (e.g., the AMF 7001) may also provide, to the UE 3, its network capability indicating whether it supports dual steer feature (e.g., the DS service) or not. When the UE 3 gets the network capability which indicates that the VPLMN#1 supports the dual steer feature, the UE 3 can initiate Dual Registration to other PLMN while the UE 3 is registered to the VPLMN#1.
[0152] For example, as the AMF 7001 receives the Reg Id which is set to 1 from the UE 3 and sends 5G-GUTI1 to the UE 3, the AMF 7001 may know that Reg Id which is set to 1 corresponds to or related to 5G-GUTI1. In addition, the AMF 7001 may store information indicating that Reg Id which is set to 1 corresponds to or related to 5G-GUTI1. This information may be included in the UE Context(s) for the UE 3.
[0153] For example, as the UE 3 sends the Reg Id which is set to 1 to the AMF 7001 and receives 5G-GUTI1 from the AMF 7001, the UE 3 may know that Reg Id which is set to 1 corresponds to or related to 5G-GUTI1. In addition, the UE 3 may store information indicating that Reg Id which is set to 1 corresponds to or related to 5G-GUTI1.
[0154] The above process(es) may be applied to not only VPLMN#1 but also VPLMN#2. For example, the UE 3 may send the Registration Request message to the AMF 7002 in VPLMN#2, and the AMF 7002 may perform the above-mentioned process(es) in the same manner as the AMF 7001.
[0155] For example, the Registration procedure in Fig. 17 may be expressed as a Registration procedure for the DSMA PDU Session, or a Registration procedure for multiple data connections over multiple 3GPP access networks, or a Registration procedure for multiple data connections over multiple 3GPP access networks in multiple PLMNs, or a Registration procedure for multiple data connections over multiple 3GPP access networks in PLMN(s).
[0156] Variant 1 of First Scenario, Second Example, Second Aspect In one example, all or some of the subscription Service profile elements for UE 3 may be provided or updated in the UDM 75 and the UE 3 by the Service provider (e.g., an Application Function (AF) 201) via NEF 79, as shown in Fig. 18.
[0157] Step 1. The AF 201 (the Application server of the Service provider) triggers updates to the Service profile of one or a group of UEs.
[0158] Step 2. The AF 201 sends, to a NEF 79 in HPLMN, an Nnef_ServiceParameter_Update Request message which includes at least one of:
[0159] - Global UE Identity - the Global UE Identity for which the Service profile is updated. It also could be a group identity for multiple UEs like Internal Group Identifier. The Global UE Identity in this disclosure may be expressed as UE global identity.
[0160] - Service profile -it contains the updated elements of the Service profile. It may contain the updated Service profile.
[0161] - Location - the AF 201 may also include the location for which the Service profile is applicable. Location can be a Tracking Area Identity (TAI), NR Cell Global Identity (NCGI), NR Cell Identity (NCI), E-UTRAN Cell Global Identifier (ECGI) or Global Cable Identifier (GCI) as defined in NPL 7, GPS location or a location expressed with civic and geospatial location formats as defined in NPL 10.
[0162] - Validity - it is referred as a time or duration where the Service is available. The Validity may take at least one of the following expressions: * Periodic service time indicator: Identifies whether the service time is periodically or not, for example, only on demand. The definition of the "Periodic service time indicator" in First example of the First Aspect may be applied to this Variant 1. * Service duration time: Duration interval time of Periodic service. This information may be used together with Periodic service time indicator. Example: 8 hours. The definition of the "Service duration time" in First example of the First Aspect may be applied to this Variant 1. * Periodic time: Interval Time of Periodic service. This information may be used together with Periodic service time indicator. Example: every hour. The definition of the "Periodic time" in First example of the First Aspect may be applied to this Variant 1. * Scheduled service time: Time zone and Day of the week when the service is available. Example: Time: 12:00-22:00, Day: Sunday. The definition of the "Scheduled service time" in First example of the First Aspect may be applied to this Variant 1.
[0163] Step 3. If the AF201 provided the UE global identity, the NEF 79 may interact with the UDM 75 to translate the UE global identity to 3GPP identity for example SUPI or any User ID that can be identified in 3GPP system.
[0164] Step 4. The NEF 79 updates the UE 3's Service profile in the UDM 75 within the UE 3's subscription information. For example, the NEF 79 may update the UE 3's Service profile based on the received information in step 2. For example, the NEF 79 may update the UE 3's Service profile in the UDM 75 based on the received information in step 2, by communicating with the UDM 75 (e.g., by sending the received information in step 2 to the UDM 75 to update the UE 3's Service profile in the UDM 75). For example, in a case where the UDM 75 receives the information from the NEF 79, the UDM may update the UE 3's Service profile in the UDM 75 based on the information received from the UDM 75. The NEF 79 may also check with the UDM 75 whether the AF 201 is authorized for UE Service profile update.
[0165] Step 5. The NEF 79 returns an Nnef_ServiceParameter_Update Response message to the AF 201 to confirm successful UE Service profile update. For example, the UDM 75 may send, to the NEF 79, notification indicating that the update of the UE 3's Service profile is finished. In a case where the NEF 79 receives the notification from the UDM 75, the NEF 79 may send the Nnef_ServiceParameter_Update Response message to the AF 201.
[0166] Step 6. If the UE 3's Service profile is updated in the UDM 75, the UDM 75 triggers notification to the AMF with which the UE 3 is registered (e.g., AMF 7001) to notify a change in the UE 3's Service profile. If the UE 3 is registered with multiple AMFs and one of them is in connected mode with the UE 3, the UDM 75 sends the notification for Service profile change to the AMF with which the UE 3 has an already establish connection. Otherwise, the UDM 75 chooses any of the AMFs that the UE 3 is registered with. In addition, the UDM 75 may update the UE 3's Service profile internally. For example, the updating of the UE 3's Service profile internally may be triggered by O&M.
[0167] Step 7. The UDM 75 sends an Namf_SDM_Notification message to the AMF 7001 which includes the UE Id or UE group Id (e.g., an identity of the UE 3, a group identity of UE(s) which includes the UE 3), the updated Service profile for that UE 3 or element(s) from the updated Service profile (e.g., the updated Service profile(s)). The Namf_SDM_Notification message may include the above-mentioned Location and the above-mentioned Validity.
[0168] Step 8. Upon reception of the Namf_SDM_Notification message in step 7, the AMF 7001 stores at least one of the updated Service profile, the Location and the Validity parameters in the UE 3 context within the AMF 7001. If the UE 3 is in idle mode and when the UE 3 enters connected mode, the AMF 7001 triggers the UE Configuration Update message to the UE 3.
[0169] Step 9. The AMF 7001 sends a UE Configuration Update Command message to the UE 3 including the updated Service profile for the UE 3. The UE Configuration Update Command message may include the Location and Validity parameters. Alternatively, if the UE 3 is in idle mode for the AMF 7001, the AMF 7001 may wait for the UE 3 to get connected and then provide the updated Service profile to the UE 3 either with the UE Configuration Update Command massage or within the Registration Accept message.
[0170] Step 10. The UE 3 stores or updates at least one of the new Service profile, Location and Validity parameters and considers the new Service profile in its further interactions with the network until they are updated again. For example, the UE 3 stores or updates at least one of the new Service profile, Location and Validity parameters in a non-volatile memory and considers the new Service profile in its further interactions with the network until they are updated again. For example, the UE 3 may store at least one of the received Service profile, Location and Validity. For example, the UE 3 may update at least one of the stored Service profile, Location and Validity by using the at least one of the received Service profile, Location and Validity. For example, the UE 3 may replace at least one of the stored Service profile, Location and Validity with the at least one of the received Service profile, Location and Validity.
[0171] In this disclosure, the process(es) which are applied to one PLMN may be applied also to another PLMN, and vice versa. For example, in this disclosure, the process(es) which are applied to VPLMN#1 may be applied also to VPLMN#2, and vice versa.
[0172] Second scenario in Second example of the Second Aspect: Fig. 19 illustrates an example of the Additional Registration procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs. The additional Registration procedure may be initiated by the UE 3 when the UE 3 finds a 3GPP access network that can provide a single connection to configure the DSMA PDU Session in addition to an existing single connection established over the registered PLMN.
[0173] The detailed processes of the Second scenario in Second example of the Second Aspect are described below with reference to Fig. 19.
[0174] Step 0. The UDM 75 maintains Service profile(s) for subscribed DSATSSS services in subscriber data for the UE 3.
[0175] Step 1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 has been assigned to the UE 3. The 5G-GUTI1 or the UE 3 may be associated with the Reg Id which is set to 1. At least one of the UE 3 and the AMF 7001 may know that 5G-GUTI1 is assigned to the UE 3 and that the 5G-GUTI1 or the UE 3 is associated with the Reg Id which is set to 1. For example, the process(es) in Fig. 17 may be performed in step 1.
[0176] Step 2. The UE 3 sends an RRC Setup Request message to the RAN 502 in VPLMN#2 in order to initiate the RRC connection establishment procedure. For example, NAS layer of the UE 3 may select the VPLMN#2 based on the Service profile(s) in the UE 3 and inform the selected PLMN (i.e. VPLMN#2) to AS layer of the UE 3. The AS layer of the UE3 may find a cell supporting the VPLMN#2, e.g., cell of the RAN 502. Then, the UE 3 may send the RRC Setup Request message to the RAN 502.
[0177] Step 3. The RAN 502 sends an RRC Setup message to the UE 3.
[0178] Step 4 Upon reception of the RRC Setup message in step 3, the UE 3 sends an RRC Setup Complete message to the RAN 502 including at least one of Linked 5G-GUTI which is set to 5G-GUTI1 and Dedicated NAS. The Linked 5G-GUTI indicates the assigned 5G-GUTI to the UE 3. The Dedicated NAS includes the Registration Request message. Further, the Registration Request message includes at least one of User ID, Dual Reg support, Registration type which is set to "Add", Reg Id which is set to 2, Linked 5G-GUTI which is set to 5G-GUTI1, Linked Reg ID which is set to 1 and Extended UE radio capability. For User ID, Dual Reg support, Reg Id and Extended UE radio capability, refer to step 1 in the First scenario in Second example of the Second Aspect for details. The following bullets explain each parameter in detail. ・ The Registration type which is set to "Add" indicates that this is an additional registration procedure and additional temporary user identifier (i.e., 5G-GUTI) and corresponding UE contexts are being requested. ・ The Linked 5G-GUTI set to 5G-GUTI1 indicates the 5G-GUTI1 that has been assigned to the UE 3 for 3GPP access. In order to identify the UE 3 uniquely from any PLMN, the Linked 5G-GUTI may be a SUCI or SUPI. The UE 3 may use the 5G-GUTI as the Linked 5G-GUTI only when the UE 3 sends an N1 message to the PLMN where the 5G-GUTI is assigned. ・ The Linked Reg ID set to 1 indicates that the Link ID (e.g., Reg Id 1) that has been assigned to the Linked 5G-GUTI which is set to 1.
[0179] For example, the UE 3 may send the RRC Setup Complete message for the DSMA PDU Session. For example, the UE 3 may perform a Registration procedure for the DSMA PDU Session by sending the RRC Setup Complete message. For example, the UE 3 may send the Registration Request message for the DSMA PDU Session. For example, the UE 3 may perform a Registration procedure for the DSMA PDU Session by sending the Registration Request message.
[0180] Step 5. Upon reception of the RRC Setup Complete message from the UE 3, the RAN 502 examines, based on the GUAMI part of the Linked 5G-GUTI, i.e., MCC, MNC and AMF Identifier, if an AMF as indicated in the GUAMI part of Linked 5G-GUTI is routable by the RAN 502 or not. The RAN 502 may perform the UE Cell Location mapping based on a configuration of the Uu interface, for example connected via Non terrestrial interface.
[0181] Step 6. If the AMF 7002, as indicated in the GUAMI part of 5G-GUTI, is routable by the RAN 502 (e.g., in a case where the RAN 502 select the AMF 7002), the RAN 502 sends a UE Initial message to the AMF 7002 including at least one of UE cell location, Radio Type and NAS PDU. Otherwise, the RAN 502 selects an AMF based on internal logic in the RAN 502 and sends the UE Initial message to that AMF (e.g., AMF 7002). For UE cell location and Radio Type, refer to the step 2 in the First scenario in Second example of the Second Aspect for details. The NAS PDU may include the Registration Request message received from the UE 3. For example, the Registration Request message includes at least one of the User ID, the Dual Reg support, the Registration type set to "Add", the Reg Id set to 2, the Linked 5G-GUTI set to 5G-GUTI1, the Linked Reg ID set to 1, and the Extended UE radio capability. Note that assigning the same AMF to two UE temporary user identifiers (i.e., 5G-GUTI) may bring some benefits by reducing the number of messages for handling of the DSMA PDU Session. The UE Initial message in this disclosure may be expressed as Initial UE message. For example, the RAN 502 may send the UE Initial message for the DSMA PDU Session. For example, the RAN 502 may perform a Registration procedure for the DSMA PDU Session by sending the UE Initial message.
[0182] Step 7. Upon reception of the Registration Request message in step 6 (or upon reception of the UE initial message including the NAS PDU which includes the Registration Request message), the AMF 7002 sends an Nudm_UECM_Registration Request message to a UDM 75 including at least one of the Dual Reg support, the Registration type which is set to "Add", the Reg Id which is set to 2, the Extended UE radio capability, the UE cell location and the Radio Type. For Dual Reg support, Reg Id and Extended UE radio capability, refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details. For UE cell location and Radio Type, refer to step 2 in the First scenario in Second example of the Second Aspect for parameter details. For example, the AMF 7002 may send the Nudm_UECM_Registration Request message for the DSMA PDU Session. For example, the AMF 7002 may perform a Registration procedure for the DSMA PDU Session by sending the Nudm_UECM_Registration Request message.
[0183] Step 8. Upon reception of the Nudm_UECM_Registration Request message in step 7, the UDM 75 sends the Nudm_UECM_Registration Response message to the AMF 7002. If the Registration type is set to "Add", the UDM 75 stores the AMF 7002 as a visited AMF in addition to the AMF 7001 as another visited AMF. The UDM 75 stores the received Reg Id, the Extended UE radio capability, the UE cell location and the Radio Type associating with the AMF 7002 in addition to those of data that are associated with the AMF 7001. In one example, the Nudm_UECM_Registration Response message may contain at least one of Dual Reg Allowed and the DSATSSS Service profile for Reg Id set to 2 which the AMF 7002 may store in the UE 3 context within the AMF 7002. In this case (e.g., in a case where the Nudm_UECM_Registration Response message contains the Dual Reg Allowed and the DSATSSS Service profile for Reg Id set to 2), the AMF 7002 may not execute step 9.
[0184] Step 9. After the completion of the Nudm_UECM_Registration service in steps 7 and 8, the AMF 7002 sends an Nudm_SDM_Get Request message to the UDM 75 including at least one of the Dual Reg support, the Registration type which is set to "Add", the Reg Id which is set to 2, the Extended UE radio capability, the UE cell location and the Radio Type. Refer to step 7 for parameter details. For example, the AMF 7002 may send the Nudm_SDM_Get Request message for the DSMA PDU Session. For example, the AMF 7002 may perform a Registration procedure for the DSMA PDU Session by sending the Nudm_SDM_Get Request message.
[0185] Step 10. The UDM 75 finds Subscriber data for the UE 3 and sends an Nudm_SDM_Get Response message to the AMF 7002 including the Subscriber data for the UE 3. The Subscriber data includes Dual Reg Allowed. For Dual Reg Allowed, refer to step 5 in First scenario in Second example of the Second Aspect for parameter details. If the UE 3 indicated support for Dual Registration (e.g., in a case where the UE 3 sends at least one of the Dual Reg support and the Extended UE radio capability to the AMF 7001 in step 1), the Subscriber data includes the Service profile(s) for DSATSSS services that are applicable to Reg Id which is set to 2 (or that are for Reg Id which is set to 2 or that are related to Reg Id which is set to 2). The Service profile may be chosen by the UDM 75 based on the UE cell location, Radio type and roamed AMF. The Service profile for DSATSSS service is defined in the First example of the First Aspect. For example, the UDM 75 may find the Subscriber data in the same manner as First scenario in Second example of the Second Aspect. For example, in a case where the UDM 75 receives the message in step 7 or step 9, the UDM 75 may understand that the AMF 7002 is associated with or linked with Reg Id which is set to 2. For example, in a case where the UDM 75 receives the message in step 7 or step 9, the UDM 75 may store information indicating that the AMF 7002 is associated with or linked with Reg Id which is set to 2.
[0186] Step 11. After the AMF 7002 obtains the Subscriber data for the UE 3 from the UDM 75 in step 10, the AMF 7002 sends a Registration Accept message to the UE 3 including at least one of 5G-GUTI (e.g., 5G-GUTI2) and the Service profile(s) for Reg Id which is set to 2 and Dual Reg Allowed. For Dual Reg Allowed, refer to step 5 in First scenario in Second example of the Second Aspect for parameter details. When the UE 3 receives the Service profile(s) for Reg Id which is set to 2, the UE 3 stores received Service profile(s) by linking with Reg Id which is set to 2. For example, the UE 3 may store received Service profile(s) in a non-volatile memory in the UE 3 by linking with Reg Id which is set to 2. For example, the UE 3 may store the received Service profile(s) and associates or links the stored Service profile(s) with the Reg Id set to 2. For example, as the AMF 7002 receives the Linked 5G-GUTI which is set to 5G-GUTI1 and the Linked Reg ID which is set to 1, the AMF 7002 may know or understand that the assigned 5G-GUTI2 is associated with or linked to the 5G-GUTI1, and that the Reg Id which is set to 2 is associated with or linked to the Reg Id which is set to 1. The AMF 7002 may know, understand, or detect that the ongoing Registration procedure is Additional Registration procedure. The AMF 7002 may know, understand or detect that the received Reg Id in the Registration Request message is associated with Reg Id which has a value indicated by the Linked Reg ID. The AMF 7002 may know, understand or detect that the assigned 5G-GUTI in this Registration procedure (i.e., the Additional Registration procedure) is associated with 5G-GUTI indicated by the Linked 5G-GUTI. The Linked Reg ID may indicate Reg Id which is associated with or linked to the Reg Id in the Registration Request message. The Linked 5G-GUTI may indicate 5G-GUTI which is associated with or linked to a 5G-GUTI assigned in this Registration procedure or the ongoing Registration procedure or the Additional Registration procedure. For example, the 5G-GUTI1 which is assigned in step 1 and is indicated by the Linked 5G-GUTI is associated with or linked to 5G-GUTI2 which is assigned or sent to step 11.
[0187] For example, as the AMF 7002 receives the Reg Id which is set to 2, the Linked 5G-GUTI which is set to 5G-GUTI1, Linked Reg ID which is set to 1, and sends 5G-GUTI2 to the UE 3, the AMF 7002 may know that Reg Id which is set to 1, Reg Id which is set to 2, 5G-GUTI1 and 5G-GUTI2 are related each other. In addition, the AMF 7002 may store information indicating that Reg Id which is set to 1, Reg Id which is set to 2, 5G-GUTI1 and 5G-GUTI2 are related each other. This information may be included in the UE Context(s) for the UE 3.
[0188] For example, as the UE 3 sends the Reg Id which is set to 2, the Linked 5G-GUTI which is set to 5G-GUTI1, Linked Reg ID which is set to 1, and receives 5G-GUTI2 from the AMF 7002, the UE 3 may know that Reg Id which is set to 1, Reg Id which is set to 2, 5G-GUTI1 and 5G-GUTI2 are related each other. In addition, the UE 3 may store information indicating that Reg Id which is set to 1, Reg Id which is set to 2, 5G-GUTI1 and 5G-GUTI2 are related each other.
[0189] For example, the Registration procedure in Fig. 19 may be expressed as a Registration procedure for the DSMA PDU Session, or a Registration procedure for multiple data connections over multiple 3GPP access networks, or a Registration procedure for multiple data connections over multiple 3GPP access networks in multiple PLMNs, or a Registration procedure for multiple data connections over multiple 3GPP access networks in PLMN(s).
[0190] After successful Additional Registration procedure, the UE 3 has two 5G-GUTIs and associated two UE contexts (including e.g., at least two Service profiles, one is received in the process(es) of Fig. 17, another one is received in the process(es) of Fig. 19). Fig. 20 illustrates the UE context management in the UE 3.
[0191] The UE 3 maintains one UE Context (including e.g., Service profile(s) received in the process(es) of Fig. 17) that is associated to 5G-GUTI1 (or Reg Id which is set to 1) and the other UE Context (including e.g., Service profile(s) received in the process(es) of Fig. 19) that is associated to 5G-GUTI2 (or Reg Id which is set to 2) independently. In addition, the UE 3 may have an additional 5G-GUTI and associated UE Context for non-3GPP access. In one example, the 5G-GUTI for non-3GPP access may have or may be related to a Reg Id in the UE 3 in order to commonly manage all 5G-GUTIs internally in the UE 3.
[0192] Variant 1 of Second Scenario, Second Example, Second Aspect If the UE 3 receives the Network Slice Simultaneous Registration Group (NSSRG) information from the UDM 75 (via the AMF 7001 and / or AMF 7002), one for the 5G-GUTI1 and the other one for the 5G-GUTI2, the UE 3 can request S-NSSAI(s) in the Requested NSSAI which share a common NSSRG with the S-NSSAIs in the Allowed NSSAI / Requested NSSAI / Partially Allowed NSSAI / Pending NSSAI for the 5G-GUTI1 and with the S-NSSAI(s) in the Allowed NSSAI / Requested NSSAI / Partially Allowed NSSAI / Pending NSSAI for the 5G-GUTI2. In addition, if the UE 3 has registered in both 3GPP access and non-3GPP access, then the UE 3 can request S-NSSAI(s) in the Requested NSSAI which share a common NSSRG with the S-NSSAI(s) in the Allowed NSSAI / Requested NSSAI / Partially Allowed NSSAI / Pending NSSAI for the 5G-GUTI1 over both 3GPP access and non-3GPP access and with the S-NSSAI(s) in the Allowed NSSAI / Requested NSSAI / Partially Allowed NSSAI / Pending NSSAI for the 5G-GUTI2 over both 3GPP access and non-3GPP access.
[0193] Third scenario in Second example of the Second Aspect: Fig. 21 illustrates an example of the Context transfer procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs. The context transfer procedure may be initiated by the AMF 7001, as new AMF, if the UE 3 indicates 5G-GUTI as the UE identifier in the Registration Request message.
[0194] The detailed processes of the Third scenario in Second example of the Second Aspect are described below with reference to Fig. 21.
[0195] Step 0. The UE 3 has been registered to the AMF 7003 in the VPLMN#3 and 5G-GUTI3 has been assigned to the Reg Id which is set to 1. For example, 5G-GUTI3 is assigned to the UE 3, and is associated with the Reg Id which is set to 1. For example, in a case where the UE 3 sends the Reg Id which is set to 1 in the Registration procedure and 5G-GUTI3 is assigned to the UE 3 in the Registration procedure, 5G-GUTI3 is assigned to or associated with the Reg Id which is set to 1. In addition, in this case, after completion of the Registration procedure, the UE 3 and the AMF (e.g., the AMF 7003) which performs the Registration procedure with the UE 3 know that 5G-GUTI3 is assigned to or associated with the Reg Id which is set to 1. In a case where the UE 3 sends Reg Id in the Registration procedure, 5G-GUTI assigned in the Registration procedure is assigned to or associated with the Reg Id. After completion of the Registration procedure, at least one of the UE 3 and the AMF which performs the Registration procedure or which assigns the 5G-GUTI know that the 5G-GUTI assigned in the Registration procedure is assigned to or associated with the Reg Id. For example, the UE 3 may perform the process(es) in Fig. 17 for PLMN#3 (e.g., the AMF 7003). In this case, the UE 3 may include, in the Registration Request message, at least one of the User ID, the Dual Reg support, the Reg Id set to 1 and the Extended UE radio capability. Then the UE 3 may receive, from the AMF 7003, the Registration Accept message including at least one of 5G-GUTI3, the Dual Reg Allowed and the Service profile for the Reg Id set to 1. In addition, the AMF 7003 may receive the Subscriber data for the UE 3 from the UDM 75, and store the Subscriber data in the UE Context for the UE 3. The UE Context for the UE 3 is stored in the AMF 7003. The Subscriber data includes at least one of the DSATSSS Service profile(s) that are applicable to or for Reg Id set to 1 and Dual Reg Allowed.
[0196] Step 1. The UE 3 sends a Registration Request message to an AMF 7001 including at least one of User ID, Dual Reg support, Reg Id set to 1, Extended UE radio capability. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details. The 5G-GUTI set to 5G-GUTI3 is included as the User ID. For example, the UE 3 may send 5G-GUTI3 as the User ID. For example, the UE 3 may send Reg Id which is same to Reg Id used in the registration in step 0.
[0197] Step 2 Upon reception of the Registration Request message, the AMF 7001, as new AMF, sends an Namf_Communication_UEContextTransfer message to the AMF 7003 including 5G-GUTI set to 5G-GUTI3. For example, the AMF 7001 may send the Namf_Communication_UEContextTransfer message to the AMF 7003 including User ID set to 5G-GUTI3.
[0198] Step 3. The AMF 7003 finds the UE Context based on the received 5G-GUTI in the Namf_Communication_UEContextTransfer message in step 2. Then the AMF 7003 sends an Namf_Communication_UEContextTransfer response message to the AMF 7001 including at least one of UE Context and Reg Id set to 1. For example, as the AMF 7003 knows that 5G-GUTI3 is associated with Reg Id which is set to 1 in step 0, the AMF 7003 sends at least one of the UE Context (e.g., UE Context for the UE 3 or UE Context for 5G-GUTI3, UE Context for Reg Id which is set to 1) and the Reg Id which is set to 1. The UE Context may include the Service profile(s) for Reg Id set to 1.
[0199] Step 4. Upon reception of the Namf_Communication_UEContextTransfer response message from the AMF 7003, the AMF 7001 confirms that the Reg Id in the received Namf_Communication_UEContextTransfer response message is equal to the Reg Id that is received in the Registration Request message from the UE 3 in step 1. After successful confirmation (e.g., in a case where the AMF 7001 confirms that the Reg Id in the received Namf_Communication_UEContextTransfer response message is equal to the Reg Id that is received in the Registration Request message from the UE 3 in step 1), the AMF 7001 stores the received UE Context and assigns new 5G-GUTI set to 5G-GUTI1 to the UE 3 and sends the Registration Accept message to the UE 3 including 5G-GUTI (e.g., 5G-GUTI1) and the Service profile(s) for Reg Id which is set to 1. When the UE 3 receives the Service profile(s) for Reg Id which is set to 1, the UE 3 updates the received Service profile(s) in non-volatile memory in the UE 3 by linking with 5G-GUTI1 and Reg Id which is set to 1. For example, the UE 3 may store the received Service profile(s) and associate or link the stored Service profile(s) with 5G-GUTI1 and the Reg Id set to 1. The VPLMN#1 (e.g., the AMF 7001) may also provide, to the UE 3, its network capability indicating whether it supports dual steer feature (e.g., the DS service) or not. When the UE 3 gets the network capability which indicates that the VPLMN#1 supports the dual steer feature, the UE 3 can initiate Dual Registration to other PLMN while the UE is registered to the VPLMN#1.
[0200] For example, the Registration procedure in Fig. 21 may be expressed as a Registration procedure for the DSMA PDU Session, or a Registration procedure for multiple data connections over multiple 3GPP access networks, or a Registration procedure for multiple data connections over multiple 3GPP access networks in multiple PLMNs, or a Registration procedure for multiple data connections over multiple 3GPP access networks in PLMN(s).
[0201] Fourth scenario in Second example of the Second Aspect: Fig. 22 illustrates an example of the UE Policy related procedure (or URSP Rule downloading procedure) commonly applicable to both single PLMN case and a case spanning to multiple PLMNs. The UE Policy related procedure may take place during the Registration Procedure.
[0202] The detailed processes of the Fourth scenario in Second example of the Second Aspect are described below with reference to Fig. 22.
[0203] Step 1. Steps 0 to 10 in the Second scenario in Second example of the Second Aspect in Fig. 19 take place.
[0204] Step 2 After the UE Policy Association Establishment is successfully completed among the AMF 7002, PCF 7302 in VPLMN#2 and PCF 7303 in HPLMN (e.g., in a case where steps 0 to 10 in the Second scenario in Second example of the Second Aspect in Fig. 19 completes and the AMF 7002, PCF 7302 and the PCF 7303 can communicate each other), the AMF 7002 sends an Npcf_AMPolicyControl_Create message to the PCF 7302 including at least one of Registration type which is set to "Add", Reg Id which is set to 2, Linked 5G-GUTI which is set to 5G-GUTI1, Extended UE radio capability, UE Cell Location and Radio type. Refer to step 4 in the Second scenario in Second example of the Second Aspect for parameter details.
[0205] Step 3 Upon reception of the Npcf_AMPolicyControl_Create message from the AMF 7002, the PCF 7302 sends an Npcf_AMPolicyControl_Create message to the PCF 7303 including parameter(s) that are received in the Npcf_AMPolicyControl_Create message from the PCF 7302.
[0206] Step 4. The PCF 7303 generates the Service profile in the URSP rule for the UE 3 taking at least one of the received Extended UE radio capability, UE Cell Location and Radio type into account. For example, the PCF 7303 may generate the Service profile(s) as shown in Fig. 2, based on at least one of the received Extended UE radio capability, UE Cell Location and Radio type. For example, the PCF 7303 may generate the Service profile(s) as shown in Fig. 2, based on operator's policy. For example, the PCF 7303 may generate the Service profile(s) for the Reg Id which is set to 2.
[0207] Step 5 The PCF 7303 sends an Npcf_AMPolicyControl_Create Response message to the PCF 7302 including the URSP rule generated at step 4. For example, the URSP rule includes Service profile(s) for the Reg Id which is set to 2.
[0208] Step 6 Upon reception of the Npcf_AMPolicyControl_Create Response message from the PCF 7303, the PCF 7302 sends an Npcf_AMPolicyControl_Create Response message to the AMF 7002 including parameter(s) that are received in the Npcf_AMPolicyControl_Create Response message from the PCF 7303. For example, the URSP rule includes Service profile(s) for the Reg Id which is set to 2.
[0209] Step 7. After the AMF 7002 obtains the URSP rule for the UE 3 from the PCF 7302 in step 6, the AMF 7002 sends a Registration Accept message to the UE 3 including at least one of 5G-GUTI and the URSP rule that contains the Service profile for Reg Id which is set to 2. The 5G-GUTI may be 5G-GUTI2. When the UE 3 receives the Service profile for Reg Id which is set to 2 in the URSP rule, the UE 3 stores the received Service profile in non-volatile memory in the UE 3 by linking with Reg Id which is set to 2. For example, the UE 3 may store the received Service profile(s) and associates or links the stored Service profile(s) with the Reg Id set to 2.
[0210] Fifth scenario in Second example of the Second Aspect: Fig. 23 illustrates an example of the Network Slice Admission Control Function (NSACF) procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs. The NSACF procedure may take place during the Registration Procedure (e.g., the Registration procedure in Fig. 17 or 19 or 21 or 22).
[0211] The detailed processes of the Fifth scenario in Second example of the Second Aspect are described below with reference to Fig. 23.
[0212] Step 1. Steps 0 to 10 in the Second scenario in Second example of the Second Aspect in Fig. 19 take place.
[0213] Step 2 The AMF 7002 sends an Nnsacf_NSAC_NumOfUEsUpdate message to an NSACF 7702 in VPLMN#2 including at least one of S-NSSAI, Update flag which is set to "increase", Registration type which is set to "DS", Reg Id which is set to 2 and Linked 5G-GUTI set to 5G-GUTI1. Refer to step 4 in the Second scenario in Second example of the Second Aspect for parameter details. In addition, the S-NSSAI indicates the Network Slice that the UE 3 is registering to. The Update flag set to "increase" indicates that this update request is for incrementing the number of registered UE for network slice. The Registration type set to "DS" indicates that this registration is related to Dual steer or DSMA PDU Session. For example, the AMF 7002 may send the Nnsacf_NSAC_NumOfUEsUpdate message for NSAC or for the Number of UEs per network slice availability check and update procedure for the S-NSSAI. For example, the AMF 7002 may perform the Number of UEs per network slice availability check and update procedure for the S-NSSAI by sending the Nnsacf_NSAC_NumOfUEsUpdate message. For example, the Nnsacf_NSAC_NumOfUEsUpdate message may be a message for the Number of UEs per network slice availability check and update procedure for the S-NSSAI.
[0214] Step 3 Upon reception of the Nnsacf_NSAC_NumOfUEsUpdate message from the AMF 7002, the NSACF 7702 performs the local UE Quota control for the S-NSSAI (e.g., the Number of UEs per network slice availability check and update procedure for the S-NSSAI in NPL 4), and sends the Nnsacf_NSAC_NumOfUEsUpdate message to an NSACF 7703 in HPLMN including parameters that are received in the Nnsacf_NSAC_NumOfUEsUpdate message from the NSACF 7702. For example, in a case where the Nnsacf_NSAC_NumOfUEsUpdate message includes at least one of S-NSSAI, Update flag which is set to "increase", Registration type which is set to "DS", Reg Id which is set to 2 and Linked 5G-GUTI set to 5G-GUTI1, the NSACF 7702 may perform the local UE Quota control for the S-NSSAI, and send the Nnsacf_NSAC_NumOfUEsUpdate message to an NSACF 7703. For example, the NSACF 7702 may send the Nnsacf_NSAC_NumOfUEsUpdate message for NSAC or for the Number of UEs per network slice availability check and update procedure for the S-NSSAI. For example, the NSACF 7702 may perform the Number of UEs per network slice availability check and update procedure for the S-NSSAI by sending the Nnsacf_NSAC_NumOfUEsUpdate message. For example, the Nnsacf_NSAC_NumOfUEsUpdate message may be a message for the Number of UEs per network slice availability check and update procedure for the S-NSSAI.
[0215] Step 4. The NSACF 7703 performs the UE Quota control for the S-NSSAI (e.g., the Number of UEs per network slice availability check and update procedure for the S-NSSAI in NPL 4) taking at least one of the received S-NSSAI, Update flag, Registration type, Reg Id and Linked 5G-GUTI into account. For example, the NSACF 7703 does not increase the number of UE in case that the Registration type is set to "DS" based on the SLA (Service Level Agreement) with the 3rd party. For example, in a case where the Nnsacf_NSAC_NumOfUEsUpdate message includes at least one of S-NSSAI, Update flag which is set to "increase", Registration type which is set to "DS", Reg Id which is set to 2 and Linked 5G-GUTI set to 5G-GUTI1, the NSACF 7702 may perform the UE Quota control for the S-NSSAI.
[0216] Step 5 The NSACF 7703 sends an Nnsacf_NSAC_NumOfUEsUpdate Response message to the NSACF 7702 including Result. The Result indicates a result for UE Quota control. The Result may indicate a result of the Number of UEs per network slice availability check and update procedure for the S-NSSAI). The Result may be either 'maximum number of UEs registered with the network slice reached' or 'maximum number of UEs registered with the network slice not reached'.
[0217] Step 6 Upon reception of the Nnsacf_NSAC_NumOfUEsUpdate Response message from the NSACF 7703, the NSACF 7702 sends an Nnsacf_NSAC_NumOfUEsUpdate Response message to the AMF 7002 including parameter(s) that are received in the Nnsacf_NSAC_NumOfUEsUpdate Response message from the NSACF 7703.
[0218] Step 7. After the AMF 7002 performs the NSACF procedure in steps 2 to 6, the AMF 7002 sends a Registration Accept message to the UE 3 including 5G-GUTI set to 5G-GUTI2 and the cause. The cause may indicate the result for UE Quota control in step 5. The cause may indicate the Result in step 5. The cause may include information related to the Result in step 5. When the UE 3 receives the cause that reflects the result for UE Quota control in step 5, the UE 3 updates the Allowed NSSAI, Rejected NSSAI, Pending NSSAI, Partially Allowed NSSAI and Partially Reject NSSAI in the storage for 5G-GUTI2 (5G-GUTI2 may be related to Reg Id which is set to 2) in the UE 3 for reflecting the result for UE Quota control in step 5. For example, if the UE 3 receives the cause indicating that 'maximum number of UEs registered with the network slice reached' for S-NSSAI, the UE 3 stores the S-NSSAI to the Rejected NSSAI for 5G-GUTI2 and removes the S-NSSAI from the Allowed NSSAI for 5G-GUTI2 if the S-NSSAI is in the Allowed NSSAI for 5G-GUTI2. As far as the S-NSSAI is stored in the Rejected NSSAI for 5G-GUTI2, the UE 3 may not request this S-NSSAI in the Registration procedure using Registration type which is set to "Add" as far as the UE stays the assigned RA (Registration Area). However, this does not influence to a status of the S-NSSAI that is associated with other 5G-GUTI (for example, 5G-GUTI1 that is assigned by VPLMN#1). In a case where the AMF 7002 receives the cause indicating that 'maximum number of UEs registered with the network slice reached' from the NSACF 7702, the AMF 7002 may send a Registration Reject message including the cause.
[0219] For example, the process(es) in Fig. 23 may be applied to First scenario in Second example of the Second Aspect. For example, after steps 1 to 5 in First scenario in Second example of the Second Aspect, the AMF 7001, an NSACF in VPLMN#1 and the NSACF 7703 may perform same or similar process(es) to one in Fig. 23.
[0220] Variant 1 of Fifth scenario in Second example of the Second Aspect: In one example, the Service Level Agreement (SLA) quota for maximum number of registered UEs per network slice may be controlled by the roaming partners of the Home PLMN, i.e., the maximum number of the registered UEs per network slice is controlled by the VPLMN. Then, the global SLA quota for the Home PLMN would be distributed between the roaming partners of the HPLMN i.e., each VPLMN would have its own local quota for maximum number of registered UEs per network slice which is a part of the global SLA agreed quota by the HPLMN. In this case, after step 2 in Fig. 23 the NSACF 7702 in the VPLMN#2 may perform the quota check and update for maximum number of registered UEs per S-NSSAI (as per the description in step 4) against the local quota for maximum number of registered UEs per S-NSSAI within the VPLMN. It is noted that the method of global SLA quota for the maximum number of UEs registered with an S-NSSAI share distribution between the roaming partners may lead to UE being rejected when the local quota is reached. To avoid UE registrations failures when the UE registers for the same S-NSSAI with multiple PLMNs, the HPLMN may regularly re-adjust the local quota shared with the roaming VPLMN partners. Alternatively, the UE may be allowed to exceed the maximum number of UEs registered with an S-NSSAI when the UE registers with multiple PLMNs at the same time.
[0221] Variant 2 of Fifth scenario in Second example of the Second Aspect: In another example, at step 3 in Fig. 23 the NSACF 7702 of the VPLMN#2 may also include the PLMN Identity in the Nnsacf_NSAC_NumOfUEsUpdate message to the NSACF 7703 of the HPLMN. In this case the NSACF 7703 of the HPLMN may allow for two modes of UEs registrations with S-NSSAI counting, Single counting in multiple PLMN registrations and Multiple counting in multiple PLMN registrations, depending on the operator policies or configuration in the NSACF 7703. Alternatively, a new parameter (e.g., 'counting mode' or any other notation for a parameter which indicates whether the UE registrations with S-NSSAI is counted once or multiple times with each registration) may be added to the Nnsacf_NSAC_NumOfUEsUpdate message to the NSACF 7703 to indicate the counting modes, i.e., Single counting in multiple PLMN registrations mode or Multiple counting in multiple PLMN registrations mode: - Single counting in multiple PLMN registrations - For single counting in multiple PLMN registrations the UE registrations with a certain S-NSSAI is counted once. When the UE registers for the same S-NSSAI with multiple PLMNs the UE registration with that S-NSSAI is counted once. For example, the NSACF 7703 may check the Reg_Id parameter in the Nnsacf_NSAC_NumOfUEsUpdate message to see whether the UE 3 registration with an S-NSSAI is the first one or not. If the UE 3 has already registered with another PLMN, i.e., the Reg_Id parameter in the Nnsacf_NSAC_NumOfUEsUpdate message is higher than 1 which indicates that the UE 3 has already registered with another PLMN, the UE 3 registration is not counted by the NSACF 7703. Alternatively, to the check of the Reg_Id parameter in the Nnsacf_NSAC_NumOfUEsUpdate message, the NSACF 7703 may maintain a database with the UE registrations with the roaming VPLMN partners and the NSACF 7703 may check for UE 3 previous registration from this database. In this case the NSACF 7703 maintains the UE 3 registrations (including with the partner VPLMNs) data base with each UE 3 registration and deregistration for each supported S-NSSAI. - Multiple counting in multiple PLMN registrations - For multiple counting in multiple PLMN registrations the UE registrations with a certain S-NSSAI are counted for each registration. To avoid UE registrations failures when the UE registers for the same S-NSSAI with multiple PLMNs, the UE may be allowed to exceed the maximum number of UEs registered with an S-NSSAI when the UE registers with multiple PLMNs at the same time.
[0222] Variant 3 of Fifth scenario in Second example of the Second Aspect: Yet in another example, when EPS counting is required for a network slice and the NSACF is configured with maximum number of registered UEs with at least one PDU Session / PDN Connection, the NSACF keeps track of the current number of UEs with at least one PDU session / PDN connection established on a network slice to ensure it does not exceed the maximum configured number of registered UEs with a network slice. In this case, in step 2 of Fig. 23, the Nnsacf_NSAC_NumOfUEsUpdate message is triggered by the SMF+PGW-C (instead of the AMF 7002) when the UE 3 establishes first PDU Session / PDN connection associated with the network slice or when the last PDU Session / PDN connection associated with the network slice is released. The UE Registration counting then follows one of the standardised options (option 1 or option 2) in NPL 4.
[0223] Variant 4 of Fifth scenario in Second example of the Second Aspect: If the UE 3 has three 5G-GUTIs, 5G-GUTI1 for 3GPP access and 5G-GUTI2 for 3GPP access and 5G-GUTI3 for non-3GPP access, and each 5G-GUTI may have or may be associated with a different Configured NSSAI as the Configured NSSAI depends on the UE location and roamed VPLMN. Thus, NSSRG that is associated with the Configured NSSAI may be also different. In this case, the UE 3 takes all NSSRGs, one for 5G-GUTI1 the another one for 5G-GUTI2 and another one for 5G-GUTI3, into account when the UE 3 requests S-NSSAI (e.g., in a case where the UE 3 performs the Registration procedure for the S-NSSAI) using either 5G-GUTI because applications in the UE 3 is common to all 5G-GUTIs.
[0224] Variant 5 of Fifth scenario in Second example of the Second Aspect: In another example, local DN and central DN with Edge Computing based 5G network architecture is considered for a single PLMN case as specified in NPL 13. In this case, the UE 3 is simultaneously connected to both local DN in edge network through one 3GPP access network and central DN via core network through another 3GPP access network within the HPLMN using two AMFs. The AMFs may be connected to the same SMF, or I-SMF may be used to connect with AMF in edge network. In this scenario, a hierarchical NSACF architecture with local NSACF in edge network and primary NSACF in core network is considered. For the number of UE registrations per network slice which is subject to NSAC, the AMF in edge network triggers for number of UEs per network slice availability check and update procedure to local NSACF and the AMF in core network triggers the same procedure to primary NSACF. AMFs also share the access type as dual access or dual 3GPP access or 3GPP access 1 and 3GPP access 2 in the Nnsacf_NSAC_NumOfUEsUpdate_Request message. Periodically, primary NSACF in core network syncs with local NSACF in edge network and shares a local max value with local NSACF for taking decisions locally. Primary NSACF maintains the final number of UEs registered list and if the defined global quota for maximum number of UEs has reached, primary NSACF notifies to local NSACF immediately. UE ID is stored with the access type as dual 3GPP access if the UE registers using two 3GPP access networks. If the primary NSACF shared local max value has reached in local NSACF, then local NSACF checks with the primary NSACF for registered UEs global quota limit. A local max value may vary at every time, when the primary NSACF syncs with local NSCAF in a periodic manner. While syncing with local NSACF, the primary NSACF decides whether the same UE is counted once or twice for the dual access registration based on the network operator's policy.
[0225] Variant 6 of Fifth scenario in Second example of the Second Aspect: In the case of EPS interworking with 5GS, for network slices with an attribute of number of UEs with at least one PDU Session or PDN Connection and it is subject to NSAC, instead of AMF, SMF or SMF+PGW-C triggers the number of UEs per network slice availability check and update procedure to NSACF. In some scenario, a single NSACF may be used for both UE counting and PDU Session counting. In this case, AMF may be configured to not trigger the UE counting procedure towards NSACF and SMF or SMF+PGW-C triggers only the PDU Session counting procedure to NSACF, but NSACF is internally configured to check both UE counting and PDU Session counting upon receiving the request for PDU Session counting from SMF. If two separate NSACFs are used for UE counting and PDU Session counting, then SMF or SMF+PGW-C triggers both UE counting procedure through the message Nnsacf_NSAC_NumOfUEsUpdate_Request and PDU Session counting procedure through Nnsacf_NSAC_NumOfPDUsUpdate_Request message accordingly to NSACFs. SMF or SMF+PGW-C may also share the access type as dual access or dual 3GPP access or 3GPP access 1 and 3GPP access 2 when triggers for the number of UEs counting and PDU Session counting.
[0226] First scenario in Third example of the Second Aspect: Fig. 24 illustrates an example of the Deregistration procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0227] The detailed processes of the First scenario in Third example of the Second Aspect are described below with reference to Fig. 24.
[0228] Step 0-1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. In the same manner as step 0 in Fig. 21, for example, the UE 3 may send the Registration Request message including the Reg Id which is set to 1, and 5G-GUTI1 may be assigned to the UE 3.
[0229] Step 0-2. The UE 3 has been registered to the AMF 7002 in the VPLMN#2 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. In the same manner as step 0 in Fig. 21, for example, the UE 3 may send the Registration Request message including the Reg Id which is set to 2, and 5G-GUTI2 may be assigned to the UE 3.
[0230] Step 1. The UE 3 decides to deregister only 5G-GUTI1. For example, the UE 3 changes its configuration to perform a deregistration. For example, the UE 3 may perform a Deregistration procedure to deregister from the registered VPLMN#1. For example, the UE 3 may use a Deregistration procedure to deregister from the registered VPLMN#1.
[0231] Step 2. The UE 3 sends a Deregistration Request message to the AMF 7001 including at least one of User ID set to 5G-GUTI1, Deregistration type which is set to Single deregistration and Reg Id which is set to 1. Refer to step 4 in the Second scenario in Second example of the Second Aspect for parameter details. In addition, the Deregistration type which is set to Single deregistration indicates that this is a request to deregister for only the specified User ID (e.g., 5G-GUTI1). For example, the Deregistration Request message is sent to the AMF 7001 triggered by configuration change of the UE 3. For example, the UE 3 may send the Deregistration Request message for the DSMA PDU Session. For example, the UE 3 may perform a Deregistration procedure for the DSMA PDU Session by sending the Deregistration Request message.
[0232] Step 3. Upon reception of the Deregistration Request message in step 2, the AMF 7001 sends an Nsmf_PDUSession_ReleaseSMContext message to the SMF 7102 in HPLMN including at least one of SM Context ID, Release type which is set to Single connection release. The SM Context ID identifies the SM Context in the SMF 7102. The Release type which is set to Single connection release indicates to the SMF 7102 that this is a request to release the single connection of the DSMA PDU Session. I.e., if the SMF 7102 has another single connection that configures the DSMA PDU Session, the DSMA PDU Session remains. Otherwise, this message trigger to release the DSMA PDU Session. If the DSMA PDU Session has not established yet, the step 3 may not be performed.
[0233] Note that there is an SMF in the VPLMN#2 as this is a home routed DSMA PDU Session scenario. The Nsmf_PDUSession_ReleaseSMContext message is sent to the SMF in the VPLMN#2 and forwarded this message to the SMF 7102. For example, the AMF 7001 may send the Nsmf_PDUSession_ReleaseSMContext message for the DSMA PDU Session. For example, the AMF 7001 may perform a Deregistration procedure for the DSMA PDU Session by sending the Nsmf_PDUSession_ReleaseSMContext message. For example, the AMF 7001 may perform a Deregistration procedure for VPLMN#1 by sending the Nsmf_PDUSession_ReleaseSMContext message.
[0234] Step 4. Upon reception of the Nsmf_PDUSession_ReleaseSMContext message from the AMF 7001, the SMF 7102 contacts to the UPF 7202 in HPLMN to update a DSATSSS rule in the UPF 7202 by releasing the single connection from the DSMA PDU Session. The DSATSSS rule is explained in detail later in First scenario in Seventh example of the Second Aspect. For example, the SMF 7102 or the UPF 7202 may release the single connection from the DSMA PDU Session. For example, the UPF 7202 may update the DSATSSS rule so that the released connection from the DSMA PDU Session is not considered in the DSATSSS service. For example, the UPF 7202 may update the DSATSSS rule so that the traffic is not steered to or switched to or split to the released connection from the DSMA PDU Session. For example, the UPF 7202 may update the DSATSSS rule so that the traffic is not communicated via the released connection from the DSMA PDU Session. For example, the UPF 7202 may inform, to the SMF 7102, the successful DSATSSS rule update in the UPF 7202.
[0235] Step 5. After the SMF 7102 confirms the successful DSATSSS rule update in the UPF 7202, the SMF 7102 sends an Nsmf_PDUSession_ReleaseSMContext response message to the AMF 7001. For example, the SMF 7102 may perform a Deregistration procedure for the DSMA PDU Session by performing at least one of step 4 and step 5.
[0236] Step 6. The AMF 7001 sends an Nudm_UECM_Deregistration request message to the UDM 75 including at least one of UE User ID set to SUPI (e.g., the UE 3's SUPI), Deregistration type set to Single deregistration, Reg Id which is set to 1. Refer to step 2 for parameter details. For example, the AMF 7001 may obtain or store the UE 3's SUPI in advance.
[0237] Step 7. Upon reception of the Nudm_UECM_Deregistration request message from the AMF 7001, the UDM 75 removes the AMF 7001 as the registered AMF that is linked with Red Id which is set to 1. For example, the UDM 75 may store information which AMF is linked to or associated with the Reg Id. This removal of the registered AMF does not influence to another AMF entries if the UDM 75 holds. The UDM 75 sends an Nudm_UECM_Deregistration response message to the AMF 7001.
[0238] Step 8. The AMF 7001 sends a Deregistration Accept message to the UE 3. When the UE 3 receives the Deregistration Accept message, the UE 3 updates the DSATSSS rule in the UE 3. For example, the UE 3 may update the DSATSSS rule so that the released connection from the DSMA PDU Session is not considered in the DSATSSS service. For example, the UE 3 may update the DSATSSS rule so that the traffic is not steered to or switched to or split to the released connection from the DSMA PDU Session. For example, the UE 3 may update the DSATSSS rule so that the traffic is not communicated via the released connection from the DSMA PDU Session.
[0239] For example, the UE 3 may use the Deregistration procedure to deregister from at least one of the registered PLMNs. For example, the UE 3 may use the Deregistration procedure to deregister from the registered VPLMN#2. For example, the UE 3 may use the Deregistration procedure to deregister from one of the registered VPLMN#1 and the registered VPLMN#2.
[0240] Variant 1 of First scenario in third example of the Second Aspect: After step 7, if there is any association with the PCF 7301 for this UE 3 and the UE 3 is not registered to the AMF 7001 for non-3GPP access, the AMF 7001 performs the AMF-initiated AM Policy Association Termination procedure with the PCF 7301
[0241] Variant 2 of First scenario in third example of the Second Aspect: If the UE 3 is in CM-Idle mode over 3GPP access via VPLMN#1 and the UE 3 is in CM-Connected mode over another 3GPP access via VPLMN#2, then the UE 3 may initiate a Deregistration procedure over the 3GPP access via VPLMN#2 through the AMF 7002.
[0242] Second scenario in Third example of the Second Aspect: Fig. 25 illustrates an example of the Deregistration procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0243] The detailed processes of the Second scenario in Third example of the Second Aspect are described below with reference to Fig. 25.
[0244] Step 0-1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. This step may be same to step 0-1 in Fig. 24.
[0245] Step 0-2. The UE 3 has been registered to the AMF 7002 in the VPLMN#2 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. This step may be same to step 0-2 in Fig. 24.
[0246] Step 1. The UE 3 decides to deregister all 5G-GUTIs. For example, the UE 3 decides to power off. For example, the UE 3 is powered off. For example, in a case where the user of the UE 3 wants to deregister all 5G-GUTIs (e.g., in a case where the user of the UE 3 wants to deregister from the VPLMN#1 and VPLMN#2 (the user may do this deregistration via GUI of the UE 3)), the UE 3 may decide to deregister all 5G-GUTIs. For example, the UE 3 changes its configuration to perform a deregistration.
[0247] Step 2. The UE 3 sends a Deregistration Request message to an AMF 7001 including at least one of the User ID set to 5G-GUTI1, the Deregistration type which is set to "Deregistration all" and Reg Id which is set to 1. Refer to step 4 in the Second scenario in Second example of the Second Aspect for parameter details. In addition, the Deregistration type which is set to "Deregistration all" indicates that this is a request to deregister all associated 5G-GUTIs (in this case, deregistering both 5G-GUTI1 and 5G-GUTI2 (or both VPLMN#1 and VPLMN#2)). For example, the Deregistration Request message is sent to the AMF 7001 triggered by configuration change of the UE 3. For example, the UE 3 may send the Deregistration Request message for the DSMA PDU Session. For example, the UE 3 may perform a Deregistration procedure for the DSMA PDU Session by sending the Deregistration Request message.
[0248] Step 3. Upon reception of the Deregistration Request message in step 2, the AMF 7001 sends an Nsmf_PDUSession_ReleaseSMContext message to the SMF 7102 in HPLMN including at least one of SM Context ID, and Release type which is set to "Release all". The SM Context ID identifies the SM Context in the SMF 7102. The Release type which is set to "Release all" indicates to the SMF 7102 that this is a request to release all single connections of the DSMA PDU Session, I.e., the Release type which is set to Release all may indicate that DSMA PDU Session is released.
[0249] Note that there is an SMF in the VPLMN#2 as this is a home routed DSMA PDU Session scenario. The Nsmf_PDUSession_ReleaseSMContext message is sent to the SMF in the VPLMN#2 and forwarded this message to the SMF 7102.
[0250] For example, the AMF 7001 may send the Nsmf_PDUSession_ReleaseSMContext message for the DSMA PDU Session. For example, the AMF 7001 may perform a Deregistration procedure for the DSMA PDU Session by sending the Nsmf_PDUSession_ReleaseSMContext message. For example, the AMF 7001 may perform a Deregistration procedure for VPLMN#1 and VPLMN#2 by sending the Nsmf_PDUSession_ReleaseSMContext message.
[0251] Step 4. Upon reception of the Nsmf_PDUSession_ReleaseSMContext message from the AMF 7001, the SMF 7102 contacts to the UPF 7202 to release the DSMA PDU Session. For example, the SMF 7102 or the UPF 7202 may release the DSMA PDU Session. For example, the UPF 7202 may update the DSATSSS rule so that the released DSMA PDU Session is not considered in the DSATSSS service. For example, the UPF 7202 may update the DSATSSS rule so that the traffic is not steered to or switched to or split to the DSMA PDU Session. For example, the UPF 7202 may update the DSATSSS rule so that the traffic is not communicated via the DSMA PDU Session. For example, the UPF 7202 may inform, to the SMF 7102, that the successful DSATSSS rule update in the UPF 7202.
[0252] Step 5. The SMF 7102 sends an Nsmf_PDUSession_ReleaseSMContext response message to the AMF 7001. For example, after the SMF 7102 confirms the successful DSATSSS rule update in the UPF 7202, the SMF 7102 sends the Nsmf_PDUSession_ReleaseSMContext response message to the AMF 7001.
[0253] Step 6. The AMF 7001 sends an Nudm_UECM_Deregistration request message to the UDM 75 including at least one of UE User ID set to SUPI (e.g., the UE 3's SUPI), Deregistration type set to Deregistration all, Reg Id which is set to 1. Refer to step 2 for parameter details. For example, the AMF 7001 may obtain or store the UE 3's SUPI in advance.
[0254] Step 7. Upon reception of the Nudm_UECM_Deregistration request message from the AMF 7001, the UDM 75 removes all registered AMFs. The UDM 75 sends an Nudm_UECM_Deregistration response message to the AMF 7001.
[0255] Step 8. The UDM 75 sends an Nudm_UECM_DeregistrationNotification message to the AMF 7002 including at least one of the User ID set to SUPI, Removal Reason which is set to " Deregistration all" and Reg Id which is set to 2. Refer to step 2 for parameter details. The AMF 7002 is chosen by the UDM 75 based on the registered AMF in the storage of the UDM 75 for the UE 3 with the Reg Id which is set to 2.
[0256] Step 9. Upon reception of the Nudm_UECM_DeregistrationNotification message from the UDM 75, the AMF 7002 removes the UE Context for the UE 3. The AMF 7002 sends an Nudm_UECM_DeregistrationNotification response message to the UDM 75.
[0257] Step 10. The AMF 7001 sends a Deregistration Accept message to the UE 3. When the UE 3 receives the Deregistration Accept message, the UE 3 removes the DSATSSS rule in the UE 3. For example, the UE 3 may update the DSATSSS rule so that the released DSMA PDU Session is not considered in the DSATSSS service. For example, the UE 3 may update the DSATSSS rule so that the traffic is not steered to or switched to or split to the DSMA PDU Session. For example, the UE 3 may update the DSATSSS rule so that the traffic is not communicated via the DSMA PDU Session.
[0258] For example, the UE 3 may use the Deregistration procedure to deregister from at least one of the registered PLMNs. For example, the UE 3 may use the Deregistration procedure to deregister from the registered VPLMN#1 and the registered VPLMN#2.
[0259] Variant 1 of Second scenario in third example of the Second Aspect: After step 7, if there is any association with the PCF 7301 for this UE 3 and the UE 3 is not registered to the AMF 7001 for non-3GPP access, the AMF 7001 performs the AMF-initiated AM Policy Association Termination procedure with the PCF 7301.
[0260] Variant 2 of Second scenario in third example of the Second Aspect: After step 9, if there is any association with a PCF for this UE 3 and the UE 3 is not registered to the AMF 7002 for non-3GPP access, the AMF 7002 performs the AMF-initiated AM Policy Association Termination procedure with the PCF.
[0261] Variant 3 of Second scenario in third example of the Second Aspect: If the UE 3 is in CM-Idle mode over 3GPP access via VPLMN#1 and the UE 3 is in CM-Connected mode over another 3GPP access via VPLMN#2, then the UE 3 may initiate a Deregistration procedure over the 3GPP access via VPLMN#2 through the AMF 7002.
[0262] Third scenario in Third example of the Second Aspect: Fig. 26 illustrates an example of the Deregistration procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0263] The detailed processes of the Third scenario in Third example of the Second Aspect are described below with reference to Fig. 26.
[0264] Step 0-1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. This step may be same to step 0-1 in Fig. 24.
[0265] Step 0-2. The UE 3 has been registered to the AMF 7002 in the VPLMN#2 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. This step may be same to step 0-2 in Fig. 24.
[0266] Step 1. The UDM 75 decides to deregister only Reg Id which is set to 1 that is associated with 5G-GUTI1. For example, in a case where the Dual Steer capability is removed from a subscriber data in the UDM 75, the UDM 75 may decide to deregister. For example, the UDM 75 changes its configuration to perform a deregistration.
[0267] Step 2. The UDM 75 sends an Nudm_UECM_DeregistrationNotification message to the AMF 7001 including at least one of User ID set to SUPI (e.g., the UE 3's SUPI), Removal Reason which is set to Single deregistration and Reg Id which is set to 1. Refer to step 2 in First scenario in Third example of the Second Aspect for parameter details. For example, the Nudm_UECM_DeregistrationNotification message is sent to the AMF 7001 triggered by configuration change of the UDM 75. For example, the UDM 75 may send the Nudm_UECM_DeregistrationNotification message for the DSMA PDU Session. For example, the UDM 75 may perform a Deregistration procedure for the DSMA PDU Session by sending the Nudm_UECM_DeregistrationNotification message.
[0268] Step 2a. In the case of explicit Deregistration, the AMF 7001 may send a Deregistration Request message to the UE 3.
[0269] Step 2b. The UE 3 may send a Deregistration Accept message if it receives a message in step 2a. This step may be performed later point in time after step 6 as well.
[0270] Step 3. Upon reception of the Nudm_UECM_DeregistrationNotification message from the UDM 75, the AMF 7001 removes the UE Context for the UE 3. The AMF 7001 sends an Nudm_UECM_DeregistrationNotification response message to the UDM 75.
[0271] Step 4. Steps 3 to 5 in the First scenario in Third example of the Second Aspect may take place.
[0272] Variant 1 of Third scenario in third example of the Second Aspect: In the case of explicit Deregistration, if the UE 3 is in CM-Idle mode over 3GPP access via VPLMN#1 and the UE 3 is in CM-Connected mode over another 3GPP access via VPLMN#2, then network may initiate a Deregistration procedure over the 3GPP access via VPLMN#2 through the AMF 7002 or the AMF 7001 may send a paging message to the UE 3.
[0273] Fourth scenario in Third example of the Second Aspect: Fig. 27 illustrates an example of the Deregistration procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0274] The detailed processes of the Fourth scenario in Third example of the Second Aspect are described below with reference to Fig. 27.
[0275] Step 0-1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. This step may be same to step 0-1 in Fig. 24.
[0276] Step 0-2. The UE 3 has been registered to the AMF 7002 in the VPLMN#2 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. This step may be same to step 0-2 in Fig. 24.
[0277] Step 1. The UDM 75 decides to deregister. For example, in case of the Subscriber withdrawal due to lack of payment (e.g., lack of payment for charge for the DSATSSS service), the UDM 75 may decide to deregister. For example, the UDM 75 changes its configuration to perform a deregistration.
[0278] Step 2. The UDM 75 sends an Nudm_UECM_DeregistrationNotification message to the AMF 7001 including at least one of User ID set to SUPI (e.g., the UE 3's SUPI), Removal Reason which is set to Deregistration all and Reg Id which is set to 1. Refer to step 2 in Second scenario in Third example of the Second Aspect for parameter details. For example, the Nudm_UECM_DeregistrationNotification message is sent to the AMF 7001 triggered by configuration change of the UDM 75. For example, the UDM 75 may send the Nudm_UECM_DeregistrationNotification message for the DSMA PDU Session. For example, the UDM 75 may perform a Deregistration procedure for the DSMA PDU Session by sending the Nudm_UECM_DeregistrationNotification message. For example, the AMF 7001 may send a Deregistration Request message to the UE 3. For example, the UE 3 may send a Deregistration Accept message to the AMF 7001.
[0279] Step 2a. In the case of explicit Deregistration, the AMF 7001 may send a Deregistration Request message to the UE 3.
[0280] Step 2b. The UE 3 may send a Deregistration Accept message if it receives a message in step 2a. This step may be performed later point in time after step 6 as well.
[0281] Step 3. Upon reception of the Nudm_UECM_DeregistrationNotification message from the UDM 75, the AMF 7001 removes the UE Context for the UE 3. The AMF 7001 sends an Nudm_UECM_DeregistrationNotification response message to the UDM 75.
[0282] Step 4. Steps 3 to 5 in the Second scenario in Third example of the Second Aspect may take place.
[0283] Step 5. The UDM 75 sends an Nudm_UECM_DeregistrationNotification message to the AMF 7002 including at least one of User ID set to SUPI (e.g., the UE 3's SUPI), Removal Reason which is set to Deregistration all and Reg Id which is set to 1 and No SM handling. Refer to step 2 in Second scenario in Third example of the Second Aspect for parameter details. In addition, the No SM handling indicates to the AMF 7002 that associated PDU Session release (including associated DSMA PDU Session release) procedure is not required. One example, the UDM 75 may not include No SM handling parameter. In this case, the AMF 7002 performs the Steps 3 to 5 in the Second scenario in Third example of the Second Aspect.
[0284] Step 6. Upon reception of the Nudm_UECM_DeregistrationNotification message from the UDM 75, the AMF 7002 removes the UE Context for the UE 3. The AMF 7002 sends an Nudm_UECM_DeregistrationNotification response message to the UDM 75.
[0285] Variant 1 of Fourth scenario in third example of the Second Aspect: In the case of explicit Deregistration, if the UE 3 is in CM-Idle mode over 3GPP access via VPLMN#1 and the UE 3 is in CM-Connected mode over another 3GPP access via VPLMN#2, then network may initiate a Deregistration procedure over the 3GPP access via VPLMN#2 through the AMF 7002 or the AMF 7001 may send a paging message to the UE 3.
[0286] First scenario in Fourth example of the Second Aspect: Fig. 28 illustrates an example of the UE Configuration Update procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0287] The detailed processes of the First scenario in Fourth example of the Second Aspect are described below with reference to Fig. 28.
[0288] Step 0-1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. This step may be same to step 0-1 in Fig. 24.
[0289] Step 0-2. The UE 3 has been registered to the AMF 7002 in the VPLMN#2 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. This step may be same to step 0-2 in Fig. 24.
[0290] Step 1. The UDM 75 updates the subscriber data for the UE 3.
[0291] Step 2. At this point, there are two AMFs, the AMF 7001 and the AMF 7002, registered to the UDM 75. The UDM 75 selects the AMF 7001 for performing UE Configuration Update procedure (UCU procedure). For example, a UDM selects an AMF to perform a UCU procedure to UE if there two registrations. For example, the UDM 75 may select the AMF based on operator's policy. For example, the UDM 75 may select the AMF randomly.
[0292] Step 3. The UDM 75 sends an Nudm_SDM_Notification message to the AMF 7002 including at least one of Subscriber data and UCU not needed. The Subscriber data is an updated Subscriber data for the UE 3. The UCU not needed indicates that the UE Configuration Update procedure is not needed to take place as another associated AMF does the UE Configuration Update procedure. The UCU not needed may indicate that the UE Configuration Update procedure is not needed to take place. The UCU not needed may indicate that the UE Configuration Update procedure is not needed.
[0293] Step 4. Upon reception of the Nudm_SDM_Notification message from the UDM 75, the AMF 7002 updates the UE Contexts for the UE 3 in the storage of the AMF 7002 and sends an Nudm_SDM_Notification response message to the UDM 75. As the AMF 7002 receives the UCU not needed, the AMF 7002 does not perform the UE Configuration Update procedure with the UE 3.
[0294] Step 5. The UDM 75 sends an Nudm_SDM_Notification message to the AMF 7001 including at least one of Subscriber data and an Update all 5G-GUTI. The Update all 5G-GUTI is an indication that this Subscriber data needs to apply all associated 5G-GUTI in the UE 3. The Update all 5G-GUTI may be information indicating that update for all 5G-GUTI is needed. The Update all 5G-GUTI may indicate that the UE Configuration Update procedure is needed to take place. The Update all 5G-GUTI may indicate that the UE Configuration Update procedure is needed. The Update all 5G-GUTI may indicate that the UE Configuration Update procedure is needed based on the Subscriber data included in the Nudm_SDM_Notification message. The Update all 5G-GUTI may indicate that update of UE Context(s) is needed. The Update all 5G-GUTI may indicate that update of UE Context(s) is needed based on the Subscriber data included in the Nudm_SDM_Notification message.
[0295] Step 6. Upon reception of the Nudm_SDM_Notification message from the UDM 75, the AMF 7001 updates the UE Contexts for the UE 3 in the storage of the AMF 7001 and sends the UE Configuration Update Command message to the UE 3 including at least one of the Subscriber data and the Update all 5G-GUTI. The Subscriber data is one received in the Nudm_SDM_Notification message at step 5. For example, the AMF 7001 may update, based on the received Subscriber data, the UE Context(s) for the UE 3 which is stored in the AMF 7001.
[0296] Step 7. Upon reception of the UE Configuration Update Command message from the AMF 7001 including at least one of the Subscriber data and the Update all 5G-GUTI, the UE 3 updates the UE Contexts in the storage of the UE 3 for all associated 5G-GUTIs (i.e., 5G-GUTI1 and 5G-GUTI2) and sends the UE Configuration Update Complete message to the AMF 7001. For example, the UE 3 may update, based on the received Subscriber data, the UE Context(s) for the UE 3 which is stored in the UE 3. For example, the UE 3 may update, based on the received Subscriber data, the UE Context(s) for the UE 3 which is stored in the UE 3 and is associated with all 5G-GUTIs (e.g., 5G-GUTI1 and 5G-GUTI2).
[0297] Step 8. Upon reception of the UE Configuration Update Complete message from the UE 3, the AMF 7001 updates the UE Contexts for the UE 3 in the storage of the AMF 7001 and sends an Nudm_SDM_Notification response message to the UDM 75.
[0298] Step 9. Upon reception of the Nudm_SDM_Notification response message from the AMF 7001, the UDM 75 sends an Nudm_SDM_Notification message to the AMF 7002 including the UCU completed. The UCU completed indicates to the AMF 7002 that the updated Subscriber data has properly installed in the UE 3. I.e., the updated Subscriber data is ready to use by the AMF 7002. For example, the UCU completed may indicate that the updated Subscriber data is ready to use by the AMF 7002. For example, the UCU completed may indicate that the UE Configuration Update procedure is completed. For example, the UCU completed may indicate that the UE Configuration Update procedure is successfully completed.
[0299] For example, in step 2, the UDM 75 may select the AMF 7002. In this case, the AMF 7002 in the above-mentioned description and the process(es) related to or performed by the AMF 7002 may be replaced with the AMF 7001 and the process(es) related to or performed by the AMF 7001 respectively, and the AMF 7001 in the above-mentioned description and the process(es) related to or performed by the AMF 7001 may be replaced with the AMF 7002 and the process(es) related to or performed by the AMF 7002 respectively.
[0300] Variant 1 of First scenario in Fourth example of the Second Aspect: In step 3, the UDM 75 may not include the UCU not needed in the Nudm_SDM_Notification message to the AMF 7002. For example, the AMF 7001 and the AMF 7002 may send the UE Configuration Update Command message in including the updated Subscriber data to the UE 3 respectively.In this case, the UE 3 receives the UE Configuration Update Command messages, one from the AMF 7001 and the other one from the AMF 7002. The UE 3 updates the UE contexts for the 5G-GUTI1 based on the received Subscriber data from the AMF 7001. The UE 3 updates the UE contexts for the 5G-GUTI2 based on the received Subscriber data from the AMF 7002. In this case, the UDM 75 does not send the Nudm_SDM_Notification message to the AMF 7002 in step 9.
[0301] First scenario in Fifth example of the Second Aspect: Fig. 29 illustrates an example of the UE Policy update procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0302] The detailed processes of the First scenario in Fifth example of the Second Aspect are described below with reference to Fig. 29.
[0303] Step 0-1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. This step may be same to step 0-1 in Fig. 24.
[0304] Step 0-2. The UE 3 has been registered to the AMF 7002 in the VPLMN#2 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. This step may be same to step 0-2 in Fig. 24.
[0305] Step 1. The PCF 7303 updates the UE Policy for the UE 3.
[0306] Step 2. At this point, there are two PCFs, PCF 7301 in VPLMN#1 and PCF 7302 in VPLMN#2, which are associated with the PCF 7303 in HPLMN. The PCF 7303 selects the PCF 7301 for performing UE Policy Update procedure.
[0307] Note that if the PCF 7301 and PCF 7302 are located in different PLMN, it is unlikely to happen that the PCF 7303 selects only one PCF for performing UE Policy Update procedure as the UE Policy for the UE 3 may reflects a local UE Policy in a VPLMN.
[0308] Note that this step is likely to be taken place in a case where the UE 3 is in home PLMN, i.e., HPLMN, and two 5G-GUTIs are assigned to the UE 3 for DSATSSS service. In this case, the PCF 7301 and PCF 7302 are disappeared from Fig. 29 and steps 3, 4, 5 and 10 are also not needed. As the result, steps 6, 7, 8 and 9 are executed on the assumption that the PCF 7301 is considered as the PCF 7303 as common PCF for both 5G-GUTIs (5G-GUTI1 and 5G-GUTI2) located in HPLMN.
[0309] Step 3. The PCF 7303 sends an Npcf_AMPolicyControl_UpdateNotify message to the PCF 7302 including at least one of UE Policy and UE policy delivery not needed. The UE Policy is an updated UE Policy for the UE 3. The UE policy delivery not needed indicates that the UE Policy Update procedure is not needed to take place as another associated PCF does the UE Policy procedure. The UE policy delivery not needed may indicate that the UE Policy Update procedure is not needed to take place. The UE policy delivery not needed may indicate that the UE Policy Update procedure is not needed. The UE policy delivery not needed may indicate that delivery of the UE Policy or update of the UE Policy is not needed.
[0310] Step 4. Upon reception of the Npcf_AMPolicyControl_UpdateNotify message from the PCF 7303, the PCF 7302 updates the UE Policy for the UE 3 in the storage of the PCF 7302 and sends an Npcf_AMPolicyControl_UpdateNotify response message to the PCF 7303. As the PCF 7302 receives the UE policy delivery not needed, the PCF 7302 does not perform the UE Policy Update procedure with the UE 3.
[0311] Step 5. The UDM 75 sends an Npcf_AMPolicyControl_UpdateNotify message to the PCF 7301 including at least one of UE Policy and Update all 5G-GUTI. The UE Policy is an updated UE Policy for the UE 3. The Update all 5G-GUTI is an indication that this update UE Policy needs to apply any associated 5G-GUTI in the UE 3. The Update all 5G-GUTI may indicate that the UE Policy Update procedure is needed to take place. The Update all 5G-GUTI may indicate that the UE Policy Update procedure is needed. The Update all 5G-GUTI may indicate that delivery of the UE Policy is needed or that update of the UE Policy is needed. The Update all 5G-GUTI may indicate that delivery of the UE Policy included in this message is needed or that update of the UE Policy based on the UE Policy in this message is needed.
[0312] Step 6. Upon reception of the Npcf_AMPolicyControl_UpdateNotify message from the PCF 7303, the PCF 7301 updates the UE Policy for the UE 3 in the storage of the PCF 7301 and sends an Namf_Communication_N1N2MessageTransfer message to the AMF 7001 including at least one of UE Policy and Update all 5G-GUTI. The UE Policy is an updated UE Policy reflecting local UE Policy in the VPLMN#1. The Update all 5G-GUTI is an indication that this update UE Policy needs to apply any associated 5G-GUTI in the UE 3. The Update all 5G-GUTI may be same one in step 5. For example, the PCF 7301 may update, based on the received UE Policy, the UE Policy for the UE 3 which is stored in the PCF 7301.
[0313] Step 7. Upon reception of the Namf_Communication_N1N2MessageTransfer message from the PCF 7301, the AMF 7001 sends a Manage UE Policy Command message to the UE 3 including at least one of the UE Policy and Update all 5G-GUTI.
[0314] Step 8. Upon reception of the Manage UE Policy Command message from the AMF 7001 including at least one of the UE Policy and the Update all 5G-GUTI, the UE 3 updates the UE Policy in the storage of the UE 3 for all associated 5G-GUTIs (i.e., 5G-GUTI1 and 5G-GUTI2) and sends a Manage UE Policy Complete message to the AMF 7001. For example, the UE 3 may update, based on the received UE Policy, the UE Policy which is stored in the UE 3. For example, the UE 3 may update, based on the received UE Policy, the UE Policy which is stored in the UE 3 and is associated with all 5G-GUTIs (e.g., 5G-GUTI1 and 5G-GUTI2).
[0315] Step 9. Upon reception of the Manage UE Policy Complete message from the UE 3, the AMF 7001 sends an Namf_Communication_N1N2MessageTransfer response message to the PCF 7301.
[0316] Step 10. Upon reception of the Namf_Communication_N1N2MessageTransfer response message from the AMF 7001, the PCF 7301 sends an Npcf_AMPolicyControl_UpdateNotify response message to the PCF 7303.
[0317] Step 11. Upon reception of the Npcf_AMPolicyControl_UpdateNotify response message from the PCF 7301, the PCF 7303 sends an Npcf_AMPolicyControl_UpdateNotify message to the PCF 7302 including the UE Policy delivery completed. The UE Policy delivery completed indicates to the PCF 7302 that the updated UE Policy has properly installed in the UE 3. I.e., the updated UE Policy is ready to use by the PCF 7302. The UE Policy delivery completed may indicate that the updated UE Policy is ready to use by the PCF 7302. For example, the UE Policy delivery completed may indicate that the UE Policy Update procedure is completed. For example, the UE Policy delivery completed may indicate that the UE Policy Update procedure is successfully completed. For example, the UE Policy delivery completed may indicate that delivery of the UE Policy is completed or that update of the UE Policy is completed. For example, the UE Policy delivery completed may indicate that delivery of the UE Policy is successfully completed or that update of the UE Policy is successfully completed.
[0318] For example, in step 2, the PCF 7303 may select the PCF 7302. In this case, the PCF 7302 in the above-mentioned description and the process(es) related to or performed by the PCF 7302 may be replaced with the PCF 7301 and the process(es) related to or performed by the PCF 7301 respectively, and the PCF 7301 in the above-mentioned description and the process(es) related to or performed by the PCF 7301 may be replaced with the PCF 7302 and the process(es) related to or performed by the PCF 7302 respectively.
[0319] Variant 1 of First scenario in Fifth example of the Second Aspect: In step 3, the PCF 7302 may not include the UE policy delivery not needed in the Npcf_AMPolicyControl_UpdateNotify message to the PCF 7302. For example, the AMF 7001 and the AMF 7002 may send the Manage UE Policy Command message in including the updated UE Policy to the UE 3 respectively. In this case, the UE 3 receives the Manage UE Policy Command message one from the AMF 7001 and the other one from the AMF 7002. The UE 3 updates the UE Policy for the 5G-GUTI1 based on the received UE Policy from the AMF 7001. The UE 3 updates the UE Policy for the 5G-GUTI2 based on the received UE Policy from the AMF 7002. In this case, the UDM 75 does not send the message to the PCF 7302 in step 11. For example, the UE policy delivery not needed indicates that the UE Policy Update procedure is not needed to take place as another associated PCF does the UE Policy procedure. The UE policy delivery not needed may indicate that the UE Policy Update procedure is not needed to take place.
[0320] First scenario in Sixth example of the Second Aspect: Fig. 30 illustrates an example of the Authentication procedure for 5G Authentication and Key Agreement (AKA) commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0321] The detailed processes of the First scenario in Sixth example of the Second Aspect are described below with reference to Fig. 30.
[0322] Step 1. The UE 3 sends an N1 message to the AMF 7001 including at least one of User ID, Dual Reg support and Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0323] Step 2. The AMF 7001 sends an Nausf_UEAuthentication_Authenticate Request message to the AUSF 78 in HPLMN including at least one of User ID, Dual Reg support, and Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0324] Step 3. Upon reception of the Nausf_UEAuthentication_Authenticate Request message from the AMF 7001, the AUSF 78 sends an Nudm_UEAuthentication_Get Request message to the UDM 75 including at least one of User ID, Dual Reg support, and Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0325] Step 4. Upon reception of the Nudm_UEAuthentication_Get Request message from the AUSF 78 in step 3, the UDM 75 generates a 5G HE AV for the UE 3. The 5G HE AV is a Home Environment Authentication Vector for the UE 3.
[0326] Step 5. The UDM 75 sends an Nudm_UEAuthentication_Get Response message to the AUSF 78 including at least one of 5G HE AV, Dual Reg support and Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0327] Step 6. The AUSF 78 generates a 5G SE AV based on the 5G HE AV that is received from the UDM 75 in the Nudm_UEAuthentication_Get Response message. The 5G SE AV is a Serving Environment Authentication Vector for the UE 3.
[0328] Step 7. After the AUSF 78 generates the 5G SE AV, the AUSF 78 sends an Nausf_UEAuthentication_Authenticate Response message including at least one of the 5G SE AV, Dual Reg support and Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0329] Step 8. Upon reception of the Nausf_UEAuthentication_Authenticate Response message from the AUSF 78, the AMF 7001 sends an Authentication Request message to the UE 3 including at least one of RAND, AUTN, ngKSI, ABBA, Dual Reg support and Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details. In addition, the following bullets explain each parameter in detail. ・ RAND is a random number as a part of 5G Authentication Vector. ・ AUTN is an Authentication token as a part of 5G Authentication Vector. ・ ngKSI is a Key Set Identifier in 5G. The ngKSI is used by the UE and AMF to identify the partial native security context. ・ ABBA is a parameter that provides antibidding down protection of security features against security features introduced in higher release to a lower release and indicates the security features that are enabled in the current network.
[0330] Step 9. Steps 7 and following steps in Section 6.1.3.2.0 of NPL 9 are executed. After successful Authentication procedure for 5G AKA, the UE 3 manages the generated NAS security context with linking to the Reg Id (Reg Id which is set to 1) and associated 5G-GUTI (5G-GUTI1).
[0331] Variant 1 of First scenario in Sixth example of the Second Aspect: In a case where the Authentication procedure for EAP-AKA' is used for the authentication, the following replacements are needed. ・ In step 5, the Nudm_UEAuthentication_Get Response message to the AUSF 78 does not include the 5G HE AV. ・ Step 6 is omitted. ・ In step 7, the Nausf_UEAuthentication_Authenticate Response message to the AMF 7001 does not include the 5G SE AV. ・ Step 9 is replaced with the following texts. > "Steps 5 and following steps in Section 6.1.3.1 of NPL 9 are executed. After successful Authentication procedure for EAP-AKA', the UE 3 manages the generated NAS security context with linking to the Reg Id (Reg Id which is set to 1) and associated 5G-GUTI (5G-GUTI1)."
[0332] The process(es) in Fig. 30 may be applied to VPLMN#2. In this case, instead of Reg Id which is set to 1, Reg Id which is set to 2 may be used in the process(es), and each node (e.g., the UE 3, the AMF 7002, the AUSF 78 and the UDM 75) may perform same or similar process(es) to the process(es) in Fig. 30.
[0333] Second scenario in Sixth example of the Second Aspect: When the Authentication, either the Authentication procedure for 5G AKA or the Authentication procedure for EAP-AKA', has performed successfully for multiple UE contexts in 3GPP access, the UE 3 holds multiple Security contexts in the UE 3. The UE 3 manages each Security contexts separately for corresponding NAS security. Fig. 31 illustrates an example for the NAS security contexts management between UE 3 and associated AMFs (i.e., AMF 7001 and AMF 7002.).
[0334] As Fig. 31 illustrates, an NAS Security context for Reg Id which is set to 1 has an association with the AMF 7001 where the 5G-GUTI1 is assigned (or with the AMF 7001 (or a MN AMF 7001 described later) which assigns the 5G-GUTI1) while an NAS Security context for Reg Id which is set to 2 has an association with the AMF 7002 where the 5G-GUTI2 is assigned (or with the AMF 7002 (or SN AMF 7002 described later) which assigns the 5G-GUTI2). In addition, the UE 3 may have another NAS Security context for non-3GPP access. In this case, the UE 3 manages the NAS security context separately from the NAS Security context for Reg Id which is set to 1 and the NAS Security context for Reg Id which is set to 2. In this disclosure, 5G-GUTI1 may be expressed as 5G-GUTI#1, and 5G-GUTI2 may be expressed as 5G-GUTI#2. On top of the above-mentioned NAS security handling, the UE 3 may apply AS security handling. If the UE 3 selects the NAS Security context for Reg Id set to 1, the UE derives an AS Security context from that NAS Security context.
[0335] Third scenario in Sixth example of the Second Aspect: Fig. 32 illustrates an example of the Authentication procedure in a case where two Authentication procedures are initiated (e.g., in a case where two Authentication procedures are initiated at the same time or sequentially). This procedure is commonly applicable to both single PLMN case and a case spanning to multiple PLMNs. This disclosure discloses the AUSF based mechanism.
[0336] The detailed processes of the Third scenario in Sixth example of the Second Aspect are described below with reference to Fig. 32.
[0337] Step 1. The UE 3 sends an N1 message to the AMF 7001 including at least one of User ID, Dual Reg support and Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0338] Step 2. The AMF 7001 sends an Nausf_UEAuthentication_Authenticate Request message to the AUSF 78 including at least one of the User ID, Dual Reg support, Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0339] Step 3. Upon reception of the Nausf_UEAuthentication_Authenticate Request message from the AMF 7001, the AUSF 78 marks the User ID in the Nausf_UEAuthentication_Authenticate Request message as "Auth Activated" when the SUPI is used as the User ID. The AUSF 78 may store the User ID (e.g., the SUPI). The AUSF 78 may store the User ID marked as "Auth Activated". For example, in a case where the AUSF 78 determines that the AUSF 78 does not store the received User ID marked as "Auth Activated", the AUSF 78 may store the received User ID, or may mark the received User ID as "Auth Activated" and store the marked User ID. By marking the User ID as "Auth Activated", the AUSF 78 may understand or remember that the Authentication procedure for the UE 3 (e.g., for the SUPI or for the Reg Id which is set to 1) is activated.
[0340] Step 4. The AUSF 78 sends an Nudm_UEAuthentication_Get Request message to the UDM 75 including at least one of the User ID, Dual Reg support, Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details. The AUSF 78 may perform the Authentication procedure for Reg Id which is set to 1. The AUSF 78 may perform the Authentication procedure triggered by the Nausf_UEAuthentication_Authenticate Request message from the AMF 7001.
[0341] Step 5. The UE 3 sends an N1 message to the AMF 7002 including User ID, Dual Reg support and Reg Id set to 2. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details. Step 5 may be performed at the time when the step 1 performed (e.g., the UE 3 may send the N1 message in step 1 and the N1 message in step 5 at the same time). As shown in Fig. 32, step 5 may be performed after step 1.
[0342] Step 6. The AMF 7002 sends an Nausf_UEAuthentication_Authenticate Request message to the AUSF 78 including at least one of the User ID, Dual Reg support, Reg Id set to 2. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0343] Step 7. Upon reception of the Nausf_UEAuthentication_Authenticate Request message from the AMF 7002, the AUSF 78 checks if the SUPI is used as the User ID in the Nausf_UEAuthentication_Authenticate Request message from the AMF 7002 and that the SUPI is marked as "Auth Activated". If the SUPI is marked as "Auth Activated", the AUSF 78 sends an Nausf_UEAuthentication_Authenticate response message to the AMF 7002 including at least one of Cause set to "Authentication ongoing", and BOT timer (e.g., the BOT timer may be set to 10 seconds). The following bullets explain each parameter in detail. ・ Cause indicates a reason of rejection. Cause "Authentication ongoing" indicates that the Authenticate Request is rejected because another Authentication for the SUPI is ongoing. ・ BOT timer indicates the time value as the backed-off period how long the AMF 7002 has to wait for resending the Nausf_UEAuthentication_Authenticate Request message to the AUSF 78.
[0344] For example, the AUSF 78 may check if the SUPI received from the AMF 7002 is same to or corresponds to the SUPI received from the AMF 7001. In a case where the AUSF 78 determines or confirms that the SUPI received from the AMF 7002 is same to or corresponds to the SUPI received from the AMF 7001, the AUSF 78 may check if the SUPI received from the AMF 7001 is marked as "Auth Activated". In a case where the AUSF 78 determines that the SUPI received from the AMF 7001 is marked as "Auth Activated", the AUSF 78 may determine that the SUPI received from the AMF 7002 is also marked as "Auth Activated". In this case, the AUSF 78 may send the Nausf_UEAuthentication_Authenticate response message to the AMF 7002 including at least one of the Cause set to "Authentication ongoing", and the BOT timer. For example, in a case where the AUSF 78 determines that the SUPI received from the AMF 7002 is same to or corresponds to the SUPI received from the AMF 7001 and that the SUPI received from the AMF 7001 is marked as "Auth Activated", the AUSF 78 may send the Nausf_UEAuthentication_Authenticate response message to the AMF 7002 including at least one of the Cause set to "Authentication ongoing", and the BOT timer. For example, in step 3, the AUSF 78 may store the User ID marked as "Auth Activated" only. In this case, in step 7, the AUSF 78 may check if the User ID stored in step 3 is same to or corresponds to the User ID received in step 6. In a case where the AUSF 78 determines that the User ID stored in step 3 is same to or corresponds to the User ID received in step 6, the AUSF 78 may send the Nausf_UEAuthentication_Authenticate response message to the AMF 7002 including at least one of the Cause set to "Authentication ongoing", and the BOT timer.
[0345] Step 8. The AMF 7002 starts a timer in a case where the AMF 7002 receives the Nausf_UEAuthentication_Authenticate response message including the Cause set to "Authentication ongoing". For example, in a case where the AMF 7002 receives the Nausf_UEAuthentication_Authenticate response message including the Cause set to "Authentication ongoing" and the BOT timer, the AMF 7002 may start the timer which has the value indicated by the BOT timer (e.g., 10 seconds).
[0346] Step 9. The timer that is started at the step 8 expires. For example, 10 seconds elapse after the timer is started.
[0347] Step 10. After the timer expires, the AMF 7002 sends an Nausf_UEAuthentication_Authenticate Request message to the AUSF 78 including at least one of the User ID, Dual Reg support, Reg Id set to 2. At the time when the AUSF 78 receives the Nausf_UEAuthentication_Authenticate Request message from the AMF 7002 in step 10, it is assumed that the Authentication procedure for Reg Id which is set to 1 has been completed and the Authentication procedure for Reg Id which is set to 2 can continue. For example, the BOT timer may be set to a value corresponding to the time taking for the Authentication procedure. For example, the AUSF 78 may check whether the Authentication procedure for Reg Id which is set to 1 has been completed. In a case where the AUSF 78 confirms that the Authentication procedure for Reg Id which is set to 1 has been completed, the AUSF 78 may perform or continue the Authentication procedure for Reg Id which is set to 2.
[0348] For example, step 5 may be performed before step 1. In this case, the AUSF 78 may mark the User ID in the Nausf_UEAuthentication_Authenticate Request message from the AMF 7002 as "Auth Activated" when the SUPI is used as the User ID. In addition, in this case, the AMF 7002 in the above-mentioned description and the process(es) related to or performed by the AMF 7002 may be replaced with the AMF 7001 and the process(es) related to or performed by the AMF 7001 respectively, and the AMF 7001 in the above-mentioned description and the process(es) related to or performed by the AMF 7001 may be replaced with the AMF 7002 and the process(es) related to or performed by the AMF 7002 respectively.
[0349] Fourth scenario in Sixth example of the Second Aspect: Fig. 33 illustrates an example of the Authentication procedure in a case where two Authentication procedures are initiated (e.g., in a case where two Authentication procedures are initiated at the same time or sequentially). This procedure is commonly applicable to both single PLMN case and a case spanning to multiple PLMNs. This disclosure discloses the UDM based mechanism.
[0350] The detailed processes of the Fourth scenario in Sixth example of the Second Aspect are described below with reference to Fig. 33.
[0351] Step 1. The UE 3 sends an N1 message to the AMF 7001 including at least one of User ID, Dual Reg support and Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0352] Step 2. The AMF 7001 sends an Nausf_UEAuthentication_Authenticate Request message to the AUSF 78 including at least one of the User ID, Dual Reg support, Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0353] Step 3. The AUSF 78 sends an Nudm_UEAuthentication_Get Request message to the UDM 75 including at least one of the User ID, Dual Reg support, Reg Id set to 1. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0354] Step 4. Upon reception of the Nudm_UEAuthentication_Get Request message from the AUSF 78, the UDM 75 marks the User ID (e.g., SUPI) in the Nudm_UEAuthentication_Get Request message as "Auth Activated". If the SUCI is received in the Nudm_UEAuthentication_Get Request message from the AUSF 78, the UDM 75 de-conceals the received SUCI and converts it to the SUPI. Then the UDM 75 may mark the SUPI as "Auth Activated". The AUSF 78 may perform the Authentication procedure for Reg Id which is set to 1. The AUSF 78 may perform the Authentication procedure triggered by the Nausf_UEAuthentication_Authenticate Request message from the AMF 7001. The UDM 75 may store the User ID (e.g., the SUPI). The UDM 75 may store the User ID marked as "Auth Activated". For example, in a case where the UDM 75 determines that the UDM 75 does not store the received User ID marked as "Auth Activated", the UDM 75 may store the received User ID, or may mark the received User ID as "Auth Activated" and store the marked User ID.
[0355] Step 5. The UE 3 sends an N1 message to the AMF 7002 including at least one of User ID, Dual Reg support and Reg Id set to 2. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details. Step 5 may be performed at the time when the step 1 performed (e.g., the UE 3 may send the N1 message in step 1 and the N1 message in step 5 at the same time). As shown in Fig. 32, step 5 may be performed after step 1.
[0356] Step 6. The AMF 7002 sends an Nausf_UEAuthentication_Authenticate Request message to the AUSF 78 including at least one of the User ID, Dual Reg support, Reg Id set to 2. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details.
[0357] Step 7. Upon reception of the Nausf_UEAuthentication_Authenticate Request message from the AMF 7002, the AUSF 78 sends an Nudm_UEAuthentication_Get Request message to the UDM 75 including at least one of the User ID, Dual Reg support, Reg Id set to 2. Refer to step 1 in the First scenario in Second example of the Second Aspect for parameter details. In step 7, if the SUCI is received in the Nudm_UEAuthentication_Get Request message from the AUSF 78, the UDM 75 de-conceals the received SUCI and converts it to the SUPI.
[0358] Step 8. Upon reception of the Nudm_UEAuthentication_Get Request message from the AUSF 78, the UDM 75 checks if the SUPI is marked as "Auth Activated". If the SUPI is marked as "Auth Activated", the UDM 75 sends an Nudm_UEAuthentication_Get response message to the AUSF 78 including at least one of Cause set to "Authentication ongoing" and BOT timer (e.g., the BOT timer may be set to 10 seconds). Refer to step 7 in the Third scenario in Sixth example of the Second Aspect for parameter details. For example, the Cause is information indicate that the Authentication is ongoing or not finished. The BOT timer can be set for various duration, period, or time.
[0359] For example, the UDM 75 may check if the SUPI stored in step 4 is same to or corresponds to the SUPI received or de-concealed in step 7. In a case where the UDM 75 determines or confirms that the SUPI stored in step 4 is same to or corresponds to the SUPI received or de-concealed in step 7, the UDM 75 may check if the SUPI stored in step 4 is marked as "Auth Activated". In a case where the UDM 75 determines that the SUPI stored in step 4 is marked as "Auth Activated", the UDM 75 may determine that the SUPI received or de-concealed in step 7 is also marked as "Auth Activated". In this case, the UDM 75 may send the Nudm_UEAuthentication_Get response message to the AUSF 78 including at least one of the Cause set to "Authentication ongoing", and the BOT timer. For example, in a case where the UDM 75 determines that the SUPI stored in step 4 is same to or corresponds to the SUPI received or de-concealed in step 7 and that the SUPI stored in step 4 is marked as "Auth Activated", the UDM 75 may send the Nudm_UEAuthentication_Get response message to the AUSF 78 including at least one of the Cause set to "Authentication ongoing", and the BOT timer. For example, in step 4, the UDM 75 may store the SUPI marked as "Auth Activated" only. In this case, in step 8, the UDM 75 may check if the SUPI stored in step 4 is same to or corresponds to the SUPI received or de-concealed in step 7. In a case where the UDM 75 determines that the SUPI stored in step 4 is same to or corresponds to the SUPI received or de-concealed in step 7, the UDM 75 may send the Nudm_UEAuthentication_Get response message to the AUSF 78 including at least one of the Cause set to "Authentication ongoing", and the BOT timer.
[0360] Step 9. Upon reception of the Nudm_UEAuthentication_Get response message from the UDM 75, the AUSF 78 sends an Nausf_UEAuthentication_Authenticate response message (or an Nausf_UEAuthentication response message) to the AMF 7002 including at least one of the received Cause and BOT timer from the UDM 75 in step 8. The BOT timer can be set for various duration, period, or time.
[0361] Step 10. The AMF 7002 starts a timer when the AMF 7002 receives the Nausf_UEAuthentication_Authenticate response message including the Cause. For example, in a case where the AMF 7002 receives the Nausf_UEAuthentication_Authenticate response message including the Cause set to "Authentication ongoing" and the BOT timer, the AMF 7002 may start the timer which has the value indicated by the BOT timer (e.g., 10 seconds).
[0362] Step 11. The timer that is started at the step 10 expires. For example, 10 seconds elapse after the timer is started.
[0363] Step 12. After the timer expires, the AMF 7002 sends an Nausf_UEAuthentication_Authenticate Request message to the AUSF 78 including at least one of the User ID, Dual Reg support, Reg Id set to 2. At the time when the AUSF 78 receives the Nausf_UEAuthentication_Authenticate Request message from the AMF 7002 in step 12, it is assumed that the Authentication procedure for Reg Id which is set to 1 has been completed and the Authentication procedure for Reg Id which is set to 2 can continue. For example, the BOT timer may be set to a value corresponding to the time taking for the Authentication procedure. For example, the AUSF 78 may check whether the Authentication procedure for Reg Id which is set to 1 has been completed. In a case where the AUSF 78 confirms that the Authentication procedure for Reg Id which is set to 1 has been completed, the AUSF 78 may perform or continue the Authentication procedure for Reg Id which is set to 2.
[0364] For example, step 5 may be performed before step 1. In this case, the UDM 75 may mark, as "Auth Activated", the User ID in the Nudm_UEAuthentication_Get Request message received from the AUSF 78 and including Reg Id set to 2. In addition, in this case, the UDM 75 may perform process(es) in the same manner as step 7. For example, in a case where the marked User ID is same to or corresponds to the User ID in the Nudm_UEAuthentication_Get Request message received from the AUSF 78 and including Reg Id set to 1, the UDM 75 may send the Nudm_UEAuthentication_Get response message to the AUSF 78 including at least one of the Cause set to "Authentication ongoing", and the BOT timer, and the AUSF 78 may send the Nausf_UEAuthentication_Authenticate response message to the AMF 7001 including at least one of the received Cause and BOT timer. Then the AMF 7001 may perform process(es) in the same manner as the AMF 7002 in step 10.
[0365] Variant 1 of Fourth scenario in Sixth example of the Second Aspect: When the AUSF 78 receives the Nudm_UEAuthentication_Get response message from the UDM 75, the AUSF 78 starts the timer handling steps 10 and 11 instead of AMF 7002 (e.g., the AUSF 78 may start the timer which has the value indicated by the BOT timer). In this case, when the BOT timer expires in the AUSF 78 (e.g., in a case where the timer which have the value indicated by the BOT timer expires), the AUSF 78 may send the Nudm_UEAuthentication_Get Request message to the UDM 75 including at least one of the User ID, Dual Reg support, Reg Id set to 2.
[0366] Fifth scenario in Sixth example of the Second Aspect: Fig. 34 illustrates an example of the NAS count handling in a case where the UE 3 has two or more 5G-GUTIs associated with multiple AMFs. This procedure is commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0367] The detailed processes of the Fifth scenario in Sixth example of the Second Aspect are described below with reference to Fig. 34.
[0368] The UE 3 manages the UL NAS count value and DL NAS count value per Reg Id basis for 3GPP access in a case where the UE 3 has multiple associated 5G-GUTIs within the 3GPP access. The following steps illustrate an example of a NAS count management in the UE 3 in a case where the UE 3 has two associated 5G-GUTIs, e.g., 5G-GUTI1 and 5G-GUTI2, within the 3GPP access.
[0369] Step 0-1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. This step may be same to step 0-1 in Fig. 24.
[0370] Step 0-2. The UE 3 has been registered to the AMF 7002 in the VPLMN#2 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. This step may be same to step 0-2 in Fig. 24.
[0371] Step 1. The UE 3 sends a NAS message to the AMF 7001 using UL NAS count value "a" for 5G-GUTI1. The UE 3 manages the UL NAS count value "a" for Reg Id basis (e.g., the UE 3 may manage the UL NAS count value for at least one of Reg Id which is set to 1 and 5G-GUTI1).
[0372] Step 2. The AMF 7001 sends a NAS message to the UE 3 using DL NAS count value "b" for 5G-GUTI1. The UE 3 manages the DL NAS count value "b" for Reg Id basis (e.g., the UE 3 may manage the DL NAS count value for at least one of Reg Id which is set to 1 and 5G-GUTI1).
[0373] Step 3. The UE 3 sends a NAS message to the AMF 7002 using UL NAS count value "c" for 5G-GUTI2. The UE 3 manages the UL NAS count value "c" for Reg Id basis (e.g., the UE 3 may manage the UL NAS count value for at least one of Reg Id which is set to 2 and 5G-GUTI2).
[0374] Step 4. The AMF 7002 sends a NAS message to the UE 3 using DL NAS count value "d" for 5G-GUTI2. The UE 3 manages the DL NAS count value "d" for Reg Id basis (e.g., the UE 3 may manage the DL NAS count value for at least one of Reg Id which is set to 2 and 5G-GUTI2).
[0375] Step 5. The UE 3 sends a NAS message to the AMF 7001 using UL NAS count value "a+1" for 5G-GUTI1. The UE 3 manages the UL NAS count value "a+1" for Reg Id basis (e.g., the UE 3 may manage the UL NAS count value for at least one of Reg Id which is set to 1 and 5G-GUTI1).
[0376] Step 6. The AMF 7001 sends a NAS message to the UE 3 using DL NAS count value "b+1" for 5G-GUTI1. The UE 3 manages the DL NAS count value "b+1" for Reg Id basis (e.g., the UE 3 may manage the DL NAS count value for at least one of Reg Id which is set to 1 and 5G-GUTI1).
[0377] Step 7. The UE 3 sends a NAS message to the AMF 7002 using UL NAS count value "c+1" for 5G-GUTI2. The UE 3 manages the UL NAS count value "c+1" for Reg Id basis (e.g., the UE 3 may manage the UL NAS count value for at least one of Reg Id which is set to 2 and 5G-GUTI2).
[0378] Step 8. The AMF 7002 sends a NAS message to the UE 3 using DL NAS count value "d+1" for 5G-GUTI2. The UE 3 manages the DL NAS count value "d+1" for Reg Id basis (e.g., the UE 3 may manage the DL NAS count value for at least one of Reg Id which is set to 2 and 5G-GUTI2).
[0379] First scenario in Seventh example of the Second Aspect: Fig. 35 illustrates an example of the user plane connection model for the DSATSSS service. In order to steer user data traffic among established single connections, both the UE 3 and the UPF 7203 (as the PDU Session anchor UPF) have a DSATSSS functionality. While Fig. 35 illustrates the home routed DSMA PDU Session spanning to multiple service PLMNs, this user plane connection model is commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0380] This aspect includes and defines the DSMA PDU Session, the Dual Steer Access Traffic Steering, Switching, Splitting (DSATSSS) functionality, the Dual Steer Access Traffic Steering, Switching, Splitting- Low-Layer (DSATSSS-LL) functionality and the DSATSSS rule. In case that the traffic Steering is performed above the IP layer, the UE 3, UPF 7203 may support a Dual Steer MPTCP functionality (DSMPTCP functionality) and / or Dual Steer MPQUIC (DSMPQUIC) Functionality.
[0381] DSMA PDU Session A Multi Access-PDU (MA PDU) Session is defined in NPL 3. While MA PDU Session provides one user plane connections between the UE 3 and UPF 7203 over 3GPP access and another user plane connections between the UE 3 and UPF 7203 over non-3GPP access, Dual Steer Multi Access (DSMA) PDU Session provides two or more user plane connections between the UE 3 and UPF 7203 over 3GPP accesses in order to provide the DSATSSS service.
[0382] DSATSSS functionality The Dual Steer Access Traffic Steering, Switching, Splitting (DSATSSS) functionality includes at least one of an enhanced ATSSS-LL (Access Traffic Steering, Switching, Splitting- Low-Layer) functionality, an enhanced MPTCP functionality and an enhanced MPQUIC functionality to support the DSATSSS service.
[0383] DSATSSS-LL functionality The ATSSS-LL functionality is defined in section 5.32 of NPL 3. The UE 3 and the UPF 7203 support the DSATSSS-LL functionality. In addition to the ATSSS-LL functionality, the DSATSSS-LL functionality provides the following functionalities. ・ The DSATSSS-LL functionality in the UE does not apply a specific protocol. It is a data switching function, which decides how to steer, switch and split the uplink traffic among multiple 3GPP accesses based on the provisioned DSATSSS rules and local conditions (e.g., signal loss conditions). The DSATSSS-LL functionality in the UE may be applied to steer, switch and split all types of traffic, including TCP traffic (Transmission Control Protocol traffic), UDP traffic (User Datagram protocol traffic), Ethernet traffic, etc. ・ The DSATSSS-LL functionality may be enabled in the UE when the UE provides a "Dual Reg support" during the Registration procedure and / or the PDU Session establishment procedure.
[0384] The Dual Steer Access Traffic Steering, Switching, Splitting functionality may be called by other ways, for example, DSATSSS functionality, enhanced ATSSS-LL functionality for Dual Steer, Dual Steer ATSSS functionality and etc.
[0385] In addition to the DSATSSS-LL functionality, the UE 3 and UPF 7203 may support Multi-Path TCP Protocol (MPTCP) functionality and Multi-Path QUIC Protocol (MPQUIC) functionality. All these three steering functionalities may support traffic steering, switching, and splitting across two or more 3GPP access networks at both UE 3 side and UPF 7203 side. SMF along with PCF creates and shares the DSATSSS rules and N4 rules for UE and UPF to execute and / or apply at their ends, respectively.
[0386] DSMPTCP functionality The Dual Steer MPTCP (DSMPTCP) functionality is an enhanced MPTCP functionality to support the DSATSSS service. The MPTCP functionality is defined in section 5.32.6.2.1 of NPL 3. The UE 3 and the UPF 7203 may support the DSMPTCP functionality. Although the MPTCP functionality defined in section 5.32.6.2.1 of NPL 3 works between 3GPP access and non-3GPP access, DSMPTCP functionality works MPTCP functionality as defined in section 5.32.6.2.1 of NPL 3 between two 3GPP accesses.
[0387] The DSMPTCP functionality in the UE 3 applies the MPTCP protocol (IETF RFC 8684) and the provisioned DSATSSS rule(s) for performing access traffic steering, switching and splitting. The DSMPTCP functionality in the UE 3 may communicate with the MPTCP Proxy functionality in the UPF 7203 using the user plane of the 3GPP access, or the other 3GPP access, or both. The DSMPTCP functionality may be enabled in the UE 3 when the UE 3 provides a Dual Reg Support For example, DSMPTCP functionality supports the following functionalities. ・ An associated MPTCP Proxy functionality is enabled in the UPF 7203 for the MA PDU Session by MPTCP functionality indication received in the Multi-Access Rules (MAR). ・ The network allocates to the UE 3 one IP address / prefix for the MA PDU Session and two additional IP addresses / prefixes, called "MPTCP link-specific multipath" addresses / prefixes; one associated with 3GPP access and another associated with the another 3GPP access. In the UE 3, these two IP addresses / prefixes are used only by the DSMPTCP functionality. Each "MPTCP link-specific multipath" address / prefix assigned to UE 3 may not be routable via N6. The DSMPTCP functionality in the UE 3 and the DSMPTCP Proxy functionality in the UPF 7203 may use the "MPTCP link-specific multipath" addresses / prefixes for subflows over 3GPP access and over another 3GPP access and MPTCP Proxy functionality may use the IP address / prefix of the DSMA PDU session for the communication with the final destination. ・ The 5GC may send MPTCP proxy information to the UE 3, i.e., the IP address, a port number and the type of the MPTCP proxy. The following type of MPTCP proxy may be supported: > Type 1: Transport Converter, as defined in IETF RFC 8803. The MPTCP proxy information is retrieved by the SMF 7103 from the UPF 7203 during N4 session establishment. The UE 3 may support the client extensions specified in IETF RFC 8803. ・ The 5GC may indicate to UE 3 the list of applications for which the DSMPTCP functionality should be applied. This is achieved by using the Steering Functionality component of an DSATSSS rule. ・ When the UE 3 indicates it is capable of supporting the DSMPTCP functionality with any steering mode and the DSATSSS-LL functionality with only the Active-Standby steering mode and these functionalities are enabled for the DSMA PDU Session, then the UE 3 may route via the DSMA PDU Session the TCP traffic of applications for which the DSMPTCP functionality should be applied (i.e., the MPTCP traffic). The UE 3 may route all other traffic (i.e., the non-MPTCP traffic) via the DSMA PDU Session, but this type of traffic may be routed on one of 3GPP access or another 3GPP access, based on the received DSATSSS rule for non-MPTCP traffic. The UPF 7203 may route all other traffic (i.e., non-MPTCP traffic) based on the N4 rules provided by the SMF 7103. This may include N4 rules for DSATSSS-LL, using any steering mode as instructed by the N4 rules.
[0388] DSMPQUIC functionality The Dual Steer MPQUIC (DSMPQUIC) functionality is an enhanced MPQUIC functionality to support the DSATSSS service. The MPQUIC functionality is defined in section 5.32.6.2.2 of NPL 3. The UE 3 and the UPF 7203 may support the DSMPQUIC functionality. Although the MPQUIC functionality defined in section 5.32.6.2.2 of NPL 3 works between 3GPP access and non-3GPP access, DSMPQUIC functionality works MPQUIC functionality as defined in section 5.32.6.2.2 of NPL 3 between two 3GPP accesses.
[0389] The DSMPQUIC functionality enables steering, switching, and splitting of UDP traffic between the UE 3 and UPF 7203, in accordance with the DSATSSS policy created by the network. The operation of the DSMPQUIC functionality is based on RFC 9298 "proxying UDP in HTTP", which specifies how UDP traffic can be transferred between a client (UE 3) and a proxy (UPF 7203) using the RFC 9114 HTTP / 3 protocol. The HTTP / 3 protocol operates on top of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002), which supports simultaneous communication over multiple paths, as defined in draft-ietf-quic-multipath. The DSMPQUIC functionality in the UE 3 communicates with the MPQUIC Proxy functionality in the UPF 7203 using the user plane of the 3GPP access, or the another 3GPP access, or both. The DSMPQUIC functionality may be enabled for a DSMA PDU Session with type IPv4, Ipv6 or Ipv4v6, when both the UE 3 and the network support this functionality. The DSMPQUIC functionality may not be enabled when the type of the DSMA PDU Session is Ethernet. The MPQUIC functionality is composed of three components: ・ QoS flow selection & Steering mode selection: This component in the UE 3 initiates the establishment of one or more multipath QUIC connections, after the establishment of the MA PDU Session and, for each uplink UDP flow, it selects a QoS flow (based on the QoS rules), a steering mode and a transport mode (based on the ATSSS rules or DSATSSS rule). This component in the UPF 7203 selects, for each downlink UDP flow, a QoS flow (based on the N4 rules), a steering mode and a transport mode (based on the N4 rules). The supported transport modes are defined below. In the UE 3, this component may be only used in the uplink direction, while, in the UPF 7203, this component may be only used in the downlink direction. ・ HTTP / 3 layer: Supports the HTTP / 3 protocol defined in RFC 9114
[0171] and the extensions defined in: > RFC 9298 for supporting UDP proxying over HTTP > RFC 9297 for supporting HTTP datagrams > RFC 9220 for supporting Extended CONNECT The HTTP / 3 layer selects a multipath QUIC connection to be used for each UDP flow and allocates a new QUIC stream on this connection that is associated with the UDP flow. It also configures this QUIC stream to apply a specific steering mode. In the UE 3, the HTTP / 3 layer implements an HTTP / 3 client, while, in the UPF 7203, it implements an HTTP / 3 proxy. ・ QUIC layer: Supports the QUIC protocol as defined in the applicable IETF specifications (RFC 9000, RFC 9001, RFC 9002) and the extensions defined in: > RFC 9221 for supporting unreliable datagram transport with QUIC > draft-ietf-quic-multipath for supporting QUIC connections using multiple paths simultaneously
[0390] DSATSSS rule In order to steer, switch and split user data in DSMA PDU Session, the UE 3 and the UPF 7203 may maintain an DSATSSS rule. The DSATSSS rule is referred or used by the UE 3 and UPF 7203 to execute the DSATSSS functionality. The ATSSS rule is defined in section 5.32 of NPL 3. The DSATSSS rule is generated by the SMF 71 (ex. SMF 7103) by contacting to the PCF 73 (ex. H-PCF 7303) and sent to the UE 3 and UPF 7203. The DSATSSS rule for the UPF 7203 can be included in N4 rule or independent from the N4 rule. In addition to the ATSSS Rule, the DSATSSS rule includes the following information. ・ Multi-Active-Standby: It is used to steer a Service Data Flow (SDF) on multiple 3GPP accesses (the Active accesses), when multiple accesses are available within 3GPP access, and to switch the SDF to the available other Active access when the Active access becomes unavailable. When the Active access becomes available again, the SDF is switched back to this access. ・ Smallest Delay: It is used to steer an SDF to the access that is determined to have the smallest Round-Trip Time (RTT). The measurements may be obtained by the UE 3 and the UPF 7203 to determine the RTT over multiple 3GPP accesses. In addition, if one access becomes unavailable, all SDF traffic is switched to the other available 3GPP access. It can only be used for the Non-GBR (Guaranteed Bitrate) SDF. For example, the RTT time over multiple 3GPP accesses may be measured by at least one of the UE 3 and the UPF 7203, and the Smallest Delay may be calculated based on the RTT. ・ Load-Balancing: It is used to split an SDF across multiple 3GPP accesses if multiple 3GPP accesses are available. It contains the percentage of the SDF traffic that is sent over each 3GPP accesses. Load-Balancing may be only applicable to Non-GBR SDF. In addition, if one access becomes unavailable, all SDF traffic is switched to the other available access. ・ Priority-based: It is used to steer all the traffic of an SDF to the high priority access, until this access is determined to be congested. In this case, the traffic of the SDF is sent also to the low priority access, i.e., the SDF traffic is split over multiple 3GPP accesses. In addition, when the high priority access becomes unavailable, all SDF traffic is switched to the low priority access. It can only be used for the Non-GBR SDF. ・ Redundant: It is used to duplicate traffic of an SDF on both 3GPP accesses if both accesses are available. Any 3GPP access may act as a primary access. It may be possible to route the same SDF traffic on two or more redundant paths via two or more 3GPP accesses. It may be also called multi-redundant steering mode.
[0391] The DSATSSS rule may be called by other ways, for example, DSMATSSS rule, enhanced ATSSS Rule for Dual Steer, Dual Steer ATSSS Rule and etc.
[0392] Second scenario in Seventh example of the Second Aspect: Fig. 36 illustrates an example of the DSMA PDU Session establishment procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0393] The detailed processes of the Second scenario in Seventh example of the Second Aspect are described below with reference to Fig. 36.
[0394] Step 0. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. This step may be same to step 0-1 in Fig. 24.
[0395] Step 1. The UE 3 sends a UL NAS Transport message to the AMF 7001 including at least one of PDU Session ID, Dual Reg support, Request Type set to DSMA PDU request, Reg Id set to 1, DS Request, DNN, S-NSSAI and NAS container that includes PDU Session Establishment Request message, Service Request message or any other NAS message with the purpose of establishing a DSMA PDU Session or with the purpose to re-use an already established DSMA PDU Session or modify the already established DSMA PDU Session. The following bullets explain each parameter in detail. ・ PDU Session ID is an identifier that corresponds to an Association between the UE 3 and a Data Network 20 that provides a PDU connectivity service. ・ Dual Reg Support is explained in step 1 of the First scenario in Second example of the Second Aspect. Refer to the First scenario in Second example of the Second Aspect for parameter details. ・ Request Type which is set to DSMA PDU request indicates that the UE 3 requests to establish the DSMA PDU session. ・ Reg Id is explained in step 1 of the First scenario in Second example of the Second Aspect. Refer to the First scenario in Second example of the Second Aspect for parameter details. ・ DS Request indicates that the UE 3 requests network to establish another one or more single data connections in addition to the single data connection being requested by this PDU Session Establishment request. ・ DNN is a Data Network Name that is equivalent to an APN in EPS. The DNN is a reference to a data network. ・ S-NSSAI is a Single NSSAI that indicates a network slice.
[0396] In one example, the PDU Session Establishment Request message, Service Request message or any other NAS message embedded in the UL NAS Transport message may include the Request Type set to DSMA PDU request.
[0397] The UL NAS Transport message may include the Extended UE radio capability.
[0398] Step 2. Upon reception of the UL NAS Transport message from the UE 3, the AMF 7001 performs the SMF selection based on at least one of the received Request Type which is set to DSMA PDU request, Reg Id set to 1, DS Support, DS Request, S-NSSAI and DNN from the UE 3. The AMF 7001 chooses both the SMF 7101 in the VPLMN#1 and another SMF 7103 in the HPLMN. The SMF 7101 or the SMF 7103 chosen by the AMF 7001 may have the DSATSSS functionally. Once both the SMF 7101 and the SMF 7103 are chosen, the AMF 7001 sends an Nsmf_PDUSession_CreateSMContext Request message to the SMF 7101 including at least one of the PDU Session ID, Request Type which is set to DSMA PDU request, the Reg Id set to 1, the DS Request and the NAS message containing the PDU Session Establishment Request. The Nsmf_PDUSession_CreateSMContext Request message may include User ID. For example, the AMF 7001 may store information indicating which SMF(s) have the DSATSSS functionality. In a case where the AMF 7001 receives the UL NAS Transport message from the UE 3 (e.g., in a case where the UL NAS Transport message includes at least the Request Type which is set to DSMA PDU request, the DS Support and the DS Request), the AMF 7001 may determine that SMF(s) which have the DSATSSS functionality is needed to be selected. In this case, based on the stored information, the AMF 7001 may select or choose the SMF(s) (e.g., the SMF 7101 and the SMF 7103) which have the DSATSSS functionality.
[0399] The Nsmf_PDUSession_CreateSMContext Request message may include the Extended UE radio capability.
[0400] Step 3. Upon reception of the Nsmf_PDUSession_CreateSMContext Request message, the SMF 7101 sends an Nsmf_PDUSession_CreateSMContext Response message to the AMF 7001.
[0401] Step 4. The SMF 7101 sends an N4 Session Establishment Request message to the UPF 7201 including at least one of the PDU Session ID, and the Request Type which is set to DSMA PDU request. The Request Type which is set to DSMA PDU request may be expressed as Request Type which is set to DSMA PDU initial request.
[0402] Step 5. Upon reception of the N4 Session Establishment Request message, the UPF 7201 reserves resource(s) for the DSMA PDU Session. After successful resource reservation for the DSMA PDU Session, the UPF 7201 sends an N4 Session Establishment Response message to the SMF 7101.
[0403] Step 6. The SMF 7101 sends an Nsmf_PDUSession_Create Request message (an Nsmf_PDUSession_Create message) to the SMF 7103 including at least one of PDU Session ID, Request Type which is set to DSMA PDU request, Reg Id set to 1 and DS Request, S-NSSAI or DNN. For example, in step 2, the SMF 7101 may receive, from the AMF 7001, information related to the selected SMF 7103 (e.g., information for communicating with the SMF 7103 (e.g., IP address of the SMF 7103)). Based on this information, the SMF 7001 may specify or determine the SMF 7103, and send the Nsmf_PDUSession_CreateSMContext Request message to the SMF 7103. The Nsmf_PDUSession_CreateSMContext Request message may include User ID.
[0404] Step 7. In a case where the SMF 7103 does not hold the Session Management Subscriber data for the UE 3, the SMF 7103 sends an Nudm_SDM_Get message to the UDM 75 including at least one of the User ID, DNN, S-NSSAI, Request Type which is set to DSMA PDU request. A SUPI of UE 3 is set to the User ID. For DNN, S-NSSAI, Request Type which is set to DSMA PDU request, see step 1 for parameter details.
[0405] Step 8. Upon reception of the Nudm_SDM_Get message, the UDM 75 sends an Nudm_SDM_Get Response message to the SMF 7103 including the Session Management Subscriber data. The Session Management Subscriber data may include Dual Reg allowed. For Dual Reg Allowed, refer to step 5 in First scenario in Second example of the Second Aspect for parameter details. The Session Management Subscriber data may include the Service profile(s). For example, the UDM 75 may include at least one of the Dual Reg allowed and the Service profile(s) in a case where the UDM 75 receives the Nudm_SDM_Get message including at least one of the User ID, DNN, S-NSSAI, Request Type which is set to DSMA PDU request.
[0406] Step 9. If the SMF 7103 does not have a PCF association, the SMF 7103 establishes the PCF association with the H-PCF 7303. Then the SMF 7103 sends an Npcf_SMPolicyControl_Create message to the H-PCF 7303 including at least one of the User ID, DNN, S-NSSAI, Request Type which is set to DSMA PDU request and Reg Id set to 1. A SUPI of UE 3 is set to the User ID. For detail of DNN, S-NSSAI, Request Type which is set to DSMA PDU request and Reg Id, refer to step 1 for parameter details.
[0407] Step 10. Upon reception of the Npcf_SMPolicyControl_Create message from the SMF 7103, the H-PCF 7303 generates a PCC Rule for the UE 3 and sends an Npcf_SMPolicyControl_Create Response message to the SMF 7103 including the generated PCC Rule. The PCC Rule includes the DSMA PDU Session control information. For example, the PCC Rule includes the DSATSSS policy. The SMF 7103 derives the DSATSSS rule from the received PCC Rule. For example, the SMF 7103 may derive the DSATSSS rule based on operator's policy. For example, the SMF 7103 may derive the DSATSSS rule based on the DSATSSS policy. The DSATSSS policy may be or may include information for deriving the DSATSSS rule.
[0408] Step 11. The SMF 7103 sends an N4 Session Establishment Request message to the UPF 7203 including at least one of the PDU Session ID, Request Type which is set to DSMA PDU request, DSMATSSS rule, Reg Id set to 1, the S-NSSAI or DNN. The DSMATSSS rule may include the N4 rule. Alternatively, the N4 rule includes the DSMATSSS rule. Upon reception of the N4 Session Establishment Request message, the UPF 7203 may install the DSMATSSS rule. Upon reception of the N4 Session Establishment Request message, the UPF 7203 may reserve resource(s) for the DSMA PDU Session.
[0409] Step 12. After successful resource reservation for the DSMA PDU Session and successful installation of the DSATSSS rule in step 11, the UPF 7203 sends an N4 Session Establishment Response message to the SMF 7103.
[0410] Step 13. The UPF 7203 installs the received DSATSSS rule in the N4 Session Establishment Request message from the SMF 7103 in step 12. The DSATSSS rule is used by the UPF 7203 for controlling the traffic steering, switching and splitting in the downlink direction.
[0411] Step 14. The SMF 7103 sends an Nsmf_PDUSession_Create Response message to the SMF 7101 including the DSMATSSS rule, DS SMF name and DS UPF name. The following bullets explain each parameter in detail. ・ DSMATSSS rule is a part of PCC rule that is used for the DSMA PDU Session. ・ DS SMF name is a name of the SMF (i.e., SMF 7103) as the PDU Session Anchor SMF for the DSMA PDU Session. The DS SMF name may be an IPv4 address of the SMF, IPv6 address of the SMF or Fully Qualified Domain Name (FQDN) of the SMF. The FQDN may be used in a case where a single connection for the DSMA PDU Session is allocated another PLMN than the PLMN where the SMF is located. ・ DS UPF name is a name of the UPF (i.e., UPF 7203) as the PDU Session Anchor UPF for the DSMA PDU Session. The DS UPF name may be and IPv4 address of the UPF, IPv6 address of the UPF or FQDN of the UPF. The FQDN may be used in case where a single connection for the DSMA PDU Session is allocated another PLMN than the PLMN where the UPF is located.
[0412] Step 15. Upon reception of the Nsmf_PDUSession_Create Response message from the SMF 7103, the SMF 7101 may initiate an N4 Session Modification procedure with the UPF 7201. The SMF 7101 may provide the DSATSSS rule and / or the N4 rule to the UPF 7201 for the DSMA PDU Session.
[0413] Step 16. The SMF 7101 sends an Namf_Communication_N1N2MessageTransfer message to the AMF 7001 including at least one of PDU Session ID and N1 SM container. The N1 SM container contains a PDU Session Establishment Accept message including DSMA PDU status, DSMATSSS rule, SMF name (e.g., DS SMF name) and UPF name (e.g., DS UPF name). The following bullets explain each parameter in detail. ・ DSMATSSS rule is defined in step 14. Refer to step 14 for parameter details. ・ DS SMF name is defined in step 14. Refer to step 14 for parameter details. ・ DS UPF name is defined in step 14. Refer to step 14 for parameter details. ・ DSMA PDU status indicates a status of the DSMA PDU Session. It indicates either the requested DSMA PDU Session is successfully established or not. For example, the DSMA PDU status may indicate the requested DSMA PDU Session is successfully established. One example, although DSMA PDU Session is not established due to lack of support DSATSSS functionality in the 5GC, the PDU Session without DSATSSS functionality may be established. Optionally, the DSMA PDU status includes the maximum number of single data connections that the DSMA PDU Session can configure. This optional data is configured based on the Dual Reg Allowed in the UDM 75 and local configuration in the network. For example, if the DSMA PDU status has a numeric value three, the DSMA PDU Session can have up to three single data connection within 3GPP access for the DSMA PDU Session.
[0414] For example, in a case where the DSMA PDU Session is not successfully established, the SMF 7101 may send a PDU Session Establishment Reject message including DSMA PDU status which indicates the requested DSMA PDU Session is not successfully established.
[0415] Step 17. Upon reception of the Namf_Communication_N1N2MessageTransfer message from the SMF 7101, the AMF 7001 sends a DL NAS Transport message to the UE 3 including PDU Session Establishment Accept message, Service Accept message or any other NAS message. The PDU Session Establishment Accept message, the Service Accept message, the any other NAS message, or other SM message includes at least one of the DSMA PDU status, DSMATSSS rule, DS SMF name and DS UPF name. Refer to step 16 for parameter details.
[0416] Step 18. Upon reception of the PDU Session Establishment Accept message, Service Accept message or any other NAS message, the UE 3 installs received DSATSSS rule for the DSMA PDU Session. The DSATSSS rule is used by the UE 3 for controlling the traffic steering, switching and splitting in the uplink direction. If the DSMA PDU status indicates the maximum number of single data connection that the DSMA PDU Session can configure, the UE 3 refers this indication when the UE 3 initiates the Additional DSMA PDU Session establishment procedure as disclosed in Third scenario in Seventh example of the Second Aspect in order not to exceed the maximum number of single data connection.
[0417] Step 19. If the SMF 7103 receives the DS request in the Nsmf_PDUSession_CreateSMContext Request message in step 6 and the SMF 7103 has any N4 associations with other AMFs, the SMF 7103 initiates the establishment of user-plane resources with all other AMFs by sending a Namf_Communication_N1N2MessageTransfer including N2 SM Information.
[0418] Variant 1 of Second scenario in Seventh example of the Second Aspect: If the SMF 7101 does not hold the Session Management Subscriber data when the SMF 7101 receives the Nsmf_PDUSession_CreateSMContext Request message from the AMF 7001 in step 2, the SMF 7101 sends an Nudm_SDM_Get message to the UDM 75 including at least one of User ID, DNN, S-NSSAI, Request Type which is set to DSMA PDU request. A SUPI of UE 3 is set to the User ID. For DNN, S-NSSAI, Request Type which is set to DSMA PDU request, see step 1 for parameter details.
[0419] Upon reception of the Nudm_SDM_Get message from the SMF 7101, the UDM 75 sends the Nudm_SDM_Get Response message to the SMF 7101 including Session Management Subscriber data. The Session Management Subscriber data may include Dual Reg allowed. For Dual Reg Allowed, refer to step 5 in First scenario in Second example of the Second Aspect for parameter details.
[0420] Variant 2 of Second scenario in Seventh example of the Second Aspect: At step 6, if the SMF 7101 does not have a PCF association, the SMF 7101 establishes the PCF association with the PCF 7301. Then the SMF 7101 sends an Npcf_SMPolicyControl_Create message to the PCF 7301 including at least one of User ID, DNN, S-NSSAI, Request Type which is set to DSMA PDU request and Reg Id set to 1. A SUPI of UE 3 is set to the User ID. For detail of DNN, S-NSSAI, Request Type which is set to DSMA PDU request and Reg Id, refer to step 1 for parameter details.
[0421] Upon reception of the Npcf_SMPolicyControl_Create message from the SMF 7101, the PCF 7301 generates a PCC Rule for the UE 3 and sends an Npcf_SMPolicyControl_Create Response message to the SMF 7101 including generated PCC Rule. The PCC rule in the SMF 7101 may not require any specific policy to manage the DSMA PDU Session.
[0422] Third scenario in Seventh example of the Second Aspect: Fig. 37 illustrates an example of the Additional DSMA PDU Session establishment procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs.
[0423] The detailed processes of the Third scenario in Seventh example of the Second Aspect are described below with reference to Fig. 37.
[0424] Step 0-1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 and Reg Id which is set to 1 have been assigned. This step may be same to step 0-1 in Fig. 24. In addition, the DSMA PDU Session has been established between UE 3 and UPF 7203 over the VPLMN#1. For example, the DSMA PDU Session may have been established between UE 3 and UPF 7203 over the VPLMN#1 based on the process(es) in Fig. 36.
[0425] Step 0-2. The UE 3 has been registered to the AMF 7002 in the VPLMN#2 and 5G-GUTI2 and Reg Id which is set to 2 have been assigned. This step may be same to step 0-2 in Fig. 24.
[0426] Step 1. The UE 3 sends a UL NAS Transport message to the AMF 7002 including at least one of PDU Session ID, Dual Reg support, Request Type set to DSMA PDU request, Reg Id set to 2, DS Request, DNN, S-NSSAI, DSMA PDU session information and NAS container that includes PDU Session Establishment Request message, Service Request message or any other NAS message with the purpose of establishing a DSMA PDU Session or with the purpose to re-use an already established DSMA PDU Session or modify the already established DSMA PDU Session. The DSMA PDU session information may include at least one of DS SMF name, DS UPF name, Linked 5G-GUTI, and Linked PDU session ID. The following bullets explain each parameter in detail. ・ PDU Session ID is explained in step 1 of the Second scenario in Seventh example of the Second Aspect. Refer to the Second scenario in Seventh example of the Second Aspect. In addition, when the UE 3 initiates the Additional DSMA PDU Session establishment procedure, the UE 3 may use the same value with the PDU Session ID that is used for the DSMA PDU Session with another 5G-GUTI (i.e., 5G-GUTI1). In this case, the PDU Session ID is considered as a unique among all registered 5G-GUTIs within 3GPP access. With this option, a combination of the SUPI derived from the 5G-GUTI and PDU Session ID can uniquely identify the DSMA PDU Session from any PLMN. If the UE 3 uses any value for the PDU Session ID for the 5G-GUTI (i.e., 5G-GUTI2). In this case, the PDU Session ID is considered as a unique for the 5G-GUTI. I.e., a value for the PDU Session may be duplicated among registered 5G-GUTIs within 3GPP access. With this option, a combination of the Reg Id, SUPI derived from the 5G-GUTI and PDU Session ID can uniquely identify the DSMA PDU Session from any PLMN. ・ Request Type which is set to DSMA PDU request is explained in step 1 of the Second scenario in Seventh example of the Second Aspect. Refer to the Second scenario in Seventh example of the Second Aspect. ・ Reg Id is explained in step 1 of the First scenario in Second example of the Second Aspect. Refer to the First scenario in Second example of the Second Aspect. ・ DS Request is explained in step 1 of the Second scenario in Seventh example of the Second Aspect. Refer to the Second scenario in Seventh example of the Second Aspect. ・ DNN is explained in step 1 of the Second scenario in Seventh example of the Second Aspect. Refer to the Second scenario in Seventh example of the Second Aspect. ・ S-NSSAI is explained in step 1 of the Second scenario in Seventh example of the Second Aspect. Refer to the Second scenario in Seventh example of the Second Aspect. ・ DSMA PDU session information indicates a status of MA PDU Session if the DSMA PDU Session has been established with the PDU Session ID. The DSMA PDU Session information may be a part of the MA PDU Session information that is defined in NPL 6. The DSMA PDU Session information includes following information: > DS SMF name is explained in step 14 of the Second scenario in Seventh example of the Second Aspect. Refer to the Second scenario in Seventh example of the Second Aspect. > DS UPF name is explained in step 14 of the Second scenario in Seventh example of the Second Aspect. Refer to the Second scenario in Seventh example of the Second Aspect. > Linked 5G-GUTI is explained in step 4 of the Second scenario in Second example of the Second Aspect. Refer to the Second scenario in Second example of the Second Aspect. > Linked PDU Session ID indicates a PDU Session ID that the Linked 5G-GUTI assigned for the DSMA PDU Session. For example, in a case where PDU Session ID which is set to 1 is used in the DSMA PDU Session established in step 0-1 (e.g., the DSMA PDU Session established in step 0-1 may be related to at least one of Linked 5G-GUTI which is set to 5G-GUTI1 and Reg Id which is set to 1), the Linked PDU Session ID may be set to 1.
[0427] In one example, the PDU Session Establishment Request message, Service Request message or any other NAS message embedded in the UL NAS Transport message may include the Request Type set to DSMA PDU request.
[0428] Step 2. Upon reception of the UL NAS Transport message from the UE 3, the AMF 7002 performs the SMF selection. An SMF in the VPLMN#2 (i.e., SMF 7102) is selected based on the received Request Type which is set to DSMA PDU request, the Reg Id set to 2, the DS Support, the S-NSSAI, the DNN from the UE 3. For example, the AMF 7002 may store information indicating which SMF(s) have the DSATSSS functionality. In a case where the AMF 7002 receives the UL NAS Transport message from the UE 3 (e.g., in a case where the UL NAS Transport message includes at least the Request Type which is set to DSMA PDU request, the DS Support and the DS Request), the AMF 7002 may determine that SMF(s) which have the DSATSSS functionality is needed to be selected. In this case, based on the stored information, the AMF 7002 may select or choose the SMF(s) (e.g., the SMF 7102) which have the DSATSSS functionality.
[0429] An SMF in the HPLMN (i.e., SMF 7103) is selected based on the received DS SMF name in the DSMA PDU session information in step 1. Note that the SMF 7103, as the PDU Session Anchor SMF for the established DSMA PDU Session, can be uniquely identified by using the received DS SMF name.
[0430] Step 3. Once both the SMF 7102 and the SMF 7103 are selected, the AMF 7002 sends an Nsmf_PDUSession_CreateSMContext Request message to the SMF 7102 including at least one of PDU Session ID, Request Type which is set to DSMA PDU request, Reg Id set to 2, DS Request and NAS message containing PDU Session Establishment Request, Service Request message or any other NAS message with the purpose of establishing a DSMA PDU Session or with the purpose to re-use an already established DSMA PDU Session or modify the already established DSMA PDU Session. The Nsmf_PDUSession_CreateSMContext Request message may include User ID.
[0431] Step 4. Steps 3 to 5 in the Second scenario in Seventh example of the Second Aspect take place. For example, upon reception of the Nsmf_PDUSession_CreateSMContext Request message, the SMF 7102 may send an Nsmf_PDUSession_CreateSMContext Response message to the AMF 7002. For example, the SMF 7102 sends an N4 Session Establishment Request message to the UPF 7202 including at least one of the PDU Session ID, and the Request Type which is set to DSMA PDU request. For example, upon reception of the N4 Session Establishment Request message, the UPF 7202 reserves resource(s) for the DSMA PDU Session. After successful resource reservation for the DSMA PDU Session, the UPF 7202 sends an N4 Session Establishment Response message to the SMF 7102.
[0432] Step 5. The SMF 7102 sends an Nsmf_PDUSession_Create Request message (an Nsmf_PDUSession_Create message) to the SMF 7103 including at least one of PDU Session ID, Request Type which is set to DSMA PDU request, Reg Id set to 2, DS Request, DS SMF name, DS UPF name, Linked 5G-GUTI and Linked PDU Session ID. Refer to step 1 for parameter details. The Nsmf_PDUSession_Create Request may include User ID.
[0433] Step 6. The SMF 7103 sends an N4 Session Modification Request message including at least one of PDU Session ID, Request Type which is set to DSMA PDU request, DSMATSSS rule and Reg Id which is set to 2. Refer to step 1 for parameter details. The DSMATSSS rule may include the N4 rule. Alternatively, the N4 rule includes the DSMATSSS rule. Upon reception of the N4 Session Establishment Request message, the UPF 7203 may install the DSMATSSS rule or update the stored DSMATSSS rule based on the received DSMATSSS rule. Upon reception of the N4 Session Establishment Request message, the UPF 7203 may reserve resource(s) for the DSMA PDU Session. The DSMATSSS rule may be same one in the step 11 of Fig. 36.
[0434] Step 7. After successful resource reservation update for the DSMA PDU Session and successful installation or updating the DSATSSS rule in step 6, the UPF 7203 sends an N4 Session Modification Response message to the SMF 7103.
[0435] Step 8. The UPF 7203 installs the received DSATSSS rule in the N4 Session Modification Request message from the SMF 7103 in step 6. For example, the UPF 7203 may update DSATSSS rule in the N4 Session Modification Request message from the SMF 7103 in step 6. For example, the UPF 7203 may update the stored DSATSSS rule based on the DSATSSS rule in the N4 Session Modification Request message from the SMF 7103 in step 6. The DSATSSS rule is used by the UPF 7203 for controlling the traffic steering, switching and splitting in the downlink direction.
[0436] Step 9. Steps 14 to 18 in the Second scenario in Seventh example of the Second Aspect take place. For example, the SMF 7103 may send an Nsmf_PDUSession_Create Response message to the SMF 7102 including the DSMATSSS rule, DS SMF name and DS UPF name. For example, upon reception of the Nsmf_PDUSession_Create Response message from the SMF 7103, the SMF 7102 may initiate an N4 Session Modification procedure with the UPF 7202. The SMF 7102 may provide the DSATSSS rule and / or the N4 rule to the UPF 7202 for the DSMA PDU Session. For example, the SMF 7102 may send an Namf_Communication_N1N2MessageTransfer message to the AMF 7002 including at least one of PDU Session ID and N1 SM container. The N1 SM container contains a PDU Session Establishment Accept message including DSMA PDU status, DSMATSSS rule, SMF name (e.g., DS SMF name) and UPF name (e.g., DS UPF name). Refer to step 16 in Fig. 36 for parameter details. For example, upon reception of the Namf_Communication_N1N2MessageTransfer message from the SMF 7102, the AMF 7002 may send a DL NAS Transport message to the UE 3 including PDU Session Establishment Accept message, Service Accept message or any other NAS message. The PDU Session Establishment Accept message, the Service Accept message, the any other NAS message, or other SM message includes at least one of the DSMA PDU status, DSMATSSS rule, DS SMF name and DS UPF name. For example, upon reception of the PDU Session Establishment Accept message, Service Accept message or any other NAS message, the UE 3 may install received DSATSSS rule for the DSMA PDU Session or may update the stored DSATSSS rule based on the received DSATSSS rule. The DSATSSS rule is used by the UE 3 for controlling the traffic steering, switching and splitting in the uplink direction.
[0437] Step 10. Upon success additional PDU Session Establishment procedure in this disclosure, the UE 3 establishes the DSMA PDU Session configuring one single data connection using a 3GPP access over VPLMN#1 and another single data connection using a 3GPP access over VPLMN#2.
[0438] Fourth scenario in Seventh example of the Second Aspect: Fig. 38 illustrates an example of the Network Triggered Service Request procedure commonly applicable to both single PLMN case and a case spanning to multiple PLMNs. The disclosed procedure in this scenario may be effective only if two or more single data connections are established in the same PLMN.
[0439] The detailed processes of the Fourth scenario in Seventh example of the Second Aspect are described below with reference to Fig. 38.
[0440] Step 0-1. The UE 3 has been registered to the AMF 7001 in the VPLMN#1 and 5G-GUTI1 and Reg Id which is set to 1 have been assigned. This step may be same to step 0-1 in Fig. 24.
[0441] Step 0-2. The UE 3 has been registered to the AMF 7003 in the VPLMN#1 and 5G-GUTI3 and Reg Id which is set to 3 have been assigned. For example, the UE 3 may perform same or similar process to step 0-1 in Fig. 24, by using Reg Id set to 3, and 5G-GUTI3 may be assigned to the UE 3.
[0442] Step 0-3. The DSMA PDU Session has been established between the UE 3 and UPF 7203 over the VPLMN#1 with one single data connection with 5G-GUTI1 and another single data connection with 5G-GUTI3. For example, the UE 3 may perform process(es) in Fig. 36 and Fig. 37 to establish the DSMA PDU Session. For example, the UE 3 may perform process(es) in Fig. 36 for 5G-GUTI1 and process(es) in Fig. 37 for 5G-GUTI3 to establish the DSMA PDU Session. For example, the UE 3 may perform similar or same process(es) in Fig. 37 for the AMF 7003 in the VPLMN#1 by using Reg Id set to 3.
[0443] Step 1. Downlink Data arrives to UPF 7201 from the AF 201 via the UPF 7203.
[0444] Step 2. The UPF 7201 sends a Data Notification message to the SMF 7101.
[0445] Step 3. The SMF 7101 sends a Data Notification Ack message to the UPF 7201.
[0446] Step 4. The SMF 7101 decides how the SMF 7101 triggers UE 3 to initiate the Service request procedure. See the following bullets as examples of decision-making criteria in the SMF 7101. ・ If the UE 3 is in CM-IDLE state and the Paging policy in the URSP rule indicates the priority order for paging, the SMF 7101 finds a single data connection with a Radio Type ranked as highest priority and sends an Namf_Communication_N1N2Message Transfer message to the associated AMF with or by using the single data connection to page the UE 3. The Radio Type may indicate a RAT Type. The Radio Type may be defined as the RAT type in NPL 8 as mentioned in First example of the First Aspect. Definition of the Radio Type in First scenario in Second example of the Second Aspect may be applied to the Radio Type in this Aspect or other aspect. For example, the SMF 7101 may know or understand which Radio Type the single data connection is associated with. If the page response is not received from the UE 3 with the Radio Type ranked as highest priority, the SMF 7101 sends another Namf_Communication_N1N2Message Transfer message with or by using a Radio Type ranked as next higher priority. ・ If the UE 3 is in CM-IDLE state and the URSP rule for the UE 3 indicates that a Radio type used for the single data connection is restricted for paging, the SMF 7101 does not send an Namf_Communication_N1N2Message Transfer message to the associated AMF with the single data connection to page the UE 3. ・ If the UE 3 is in CM-IDLE state and the Extended UE radio capability of the UE 3 indicates that the UE 3 can listen to only one Paging channel (or Paging message) at a time, the SMF 7101 bi-casts or send Namf_Communication_N1N2Message Transfer message(s) to all associated AMFs with the single data connection to page the UE 3 over all associated Radio types.
[0447] If the UE 3 is in CM-CONNECTED state, the SMF 7101 may bi-cast or send Namf_Communication_N1N2Message Transfer message(s) to all associated AMFs, or send Namf_Communication_N1N2Message Transfer message(s) to one of AMFs.
[0448] Step 5-1. The SMF 7101 sends an Namf_Communication_N1N2Message Transfer message to the AMF 7001 if the bi-casting or sending is decided in step 4.
[0449] Step 5-2. The SMF 7101 sends an Namf_Communication_N1N2Message Transfer message to the AMF 7003 if the bi-casting or sending is decided in step 4.
[0450] For example, the SMF 7101 may sends an Namf_Communication_N1N2Message Transfer message to the AMF 7001 or the AMF 7003 if the SMF 7101 decides to send the Namf_Communication_N1N2Message Transfer message to the associated AMF in step 4. For example, the SMF 7101 may sends an Namf_Communication_N1N2Message Transfer message to at least one of the AMF 7001 and the AMF 7003 if the SMF 7101 may bi-cast or send Namf_Communication_N1N2Message Transfer message(s) to all associated AMFs, or send Namf_Communication_N1N2Message Transfer message(s) to one of AMFs in step 4.
[0451] Step 6-1. Upon reception of the Namf_Communication_N1N2Message Transfer message, the AMF 7001 sends an Namf_Communication_N1N2Message Transfer Response message to the SMF 7101.
[0452] Step 6-2. Upon reception of the Namf_Communication_N1N2Message Transfer message, the AMF 7003 sends an Namf_Communication_N1N2Message Transfer Response message to the SMF 7101.
[0453] Step 7-1. Upon reception of the Namf_Communication_N1N2Message Transfer message from the SMF 7101, the AMF 7001 performs paging if the UE 3 is in CM-IDLE state or sending a NAS Notification message to the UE 3 if the UE 3 is in CM-CONNECTED state.
[0454] Step 7-2. Upon reception of the Namf_Communication_N1N2Message Transfer message from the SMF 7101, the AMF 7003 performs paging if the UE 3 is in CM-IDLE state or sending a NAS Notification message to the UE 3 if the UE 3 is in CM-CONNECTED state.
[0455] Step 8. The UE 3 sends a Service Request message to the AMF 7001 as the page response. For example, the UE 3 may send the Service Request message to the AMF 7001 as a response to the NAS Notification message.
[0456] Step 9. Upon reception of the Service Request message from the UE 3, the AMF 7001 sends an Nsmf_PDUSession_UpdateSMContext Request message to the SMF 7101 including PDU Session ID. The PDU Session ID may be a PDU Session ID which is used in the establishment of the DSMA PDU Session in step 0-3. The SMF 7101 continues the Service Request procedure with the AMF 7001.
[0457] Step 10. The SMF 7101 sends the Namf_Communication_NonUeN2InfoNotify message to the AMF 7003 including Page stop indication. The Page stop indication requests the AMF 7003 to stop paging process to the UE 3. The Page stop indication may request the AMF 7003 to stop sending the NAS Notification message to the UE 3.
[0458] Step 11. Upon reception of the Namf_Communication_NonUeN2InfoNotify message including Page stop indication, the AMF 7003 terminates any Paging processes to the UE 3. For example, upon reception of the Namf_Communication_NonUeN2InfoNotify message including Page stop indication, the AMF 7003 may stop sending the NAS Notification message to the UE 3.
[0459] In the above description, while it assumes that the UE 3 receives the paging or the NAS Notification message from the AMF 7001 before receiving the paging or the NAS Notification message from the AMF 7003, there is a case where the UE 3 receives the paging or the NAS Notification message from the AMF 7003 before receiving the paging or the NAS Notification message from the AMF 7001. In this case, the UE 3 may send the Service Request message to the AMF 7003. Then the AMF 7003 may perform the same or similar process(es) that the AMF 7001 does in the above description.
[0460] Variant 1 of Fourth scenario in Seventh example of the Second Aspect: In one example, the assumption is that the UE 3 is registered with multiple AMFs (for example AMF 7001 and AMF 7003 in single VPLMN#1) as per Fig. 38. It is also assumed that the UE 3 is registered for different S-NSSAIs via the two AMFs. For example, the UE 3 is registered for an IMS designated S-NSSAI via the AMF 7001 and for CIoT designated S-NSSAI via the AMF 7003. Then, when the SMF 7101 receives the downlink data packet (e.g., the Data Notification message) at step 2 in Fig. 38, the SMF 7101 analyzes the Paging Policy Indicator in the downlink data from the IP header of the received downlink data packet to identify the type of the downlink service (e.g., IMS or CIoT or any other type of service). Based on at least one of the service type of the downlink data packet and the AMF 7001's or AMF 7003's service designation information retrieved from the UDM or from the AMFs itself, the SMF 7101 makes decision about which AMF, e.g., AMF 7001 or AMF 7003, to notify for the downlink data. For example, if the downlink data is of CIoT type and the UE 3 is registered for the CIoT designated S-NSSAI via the AMF 7003, the SMF 7101 chooses the AMF 7003 and sends the Namf_Communication_N1N2Message Transfer message to AMF 7003. Then AMF 7003 proceeds with paging the UE 3 as per the Paging procedure in NPL 4 and the UE 3 and the network exchange data via the CIoT designated S-NSSAI.
[0461] According to at least one of disclosure(s) in Second Aspect, it can solve at least one of the above-mentioned problem(s). For example, at least one of disclosure(s) in Second Aspect can solve the problem that the above-mentioned service requirement has not been supported by the 5GS yet. For example, at least one of disclosure(s) in Second Aspect can solve the problem that the DSATSSS service does not work.
[0462] For example, according to at least one of disclosure(s) in Second Aspect, it proposes various procedures for the DSATSSS service. Therefore, it can solve at least one of the above-mentioned problem(s).
[0463] In this all Second Aspect, enumerated parameter or information in a message may be expressed as information for multiple data connections over multiple 3GPP accesses, information for multiple data connections over multiple 3GPP access networks or information for the DSMA PDU Session.
[0464] <Third Example Embodiment (Third Aspect)> This aspect includes mechanisms to provide the Dual Steering ATSSS (DSATSSS) service in single PLMN. The DSATSSS service may have more than two single connections. I.e., the DSMA PDU Session may have three or more single connections in single PLMN.
[0465] First example of the Third Aspect: Fig. 39 illustrates an example of the architecture that provides the DSATSSS service in single PLMN for home-routed roaming.
[0466] Fig. 39 illustrates a case where two single connections are established in one PLMN. The basic principle of this architecture is listed below. ・ The UE 3 has single USIM and corresponding single subscriber data in the UDM 75. ・ Each single connection has its own temporary user identifier (i.e., 5G-GUTI) and corresponding UE contexts in 5GC. ・ An MN AMF 7001 as Master Node AMF is introduced. The MN AMF 7001 represents an AMF to external 3GPP nodes including SMF 71, PCF 73, UDM 75 and etc. ・ An SN AMF 7002 as Secondary Node AMF is introduced. The SN AMF 7002 is not visible from external 3GPP nodes including SMF 71, PCF 73, UDM 75 and etc. ・ The MN AMF 7001 has the proxy function for any signalling between external nodes and SN AMF 7002. ・ The SN AMF 7002 has the proxy function for any signalling between RAN 502 and MN AMF 7001. ・ The MN AMF 7001 and the SN AMF 7002 may be combined but the UE 3 has separate 5G-GUTIs. ・ The MN AMF 7001 and the SN AMF 7002 may be combined and the UE 3 has single 5G-GUTI.
[0467] When Fig. 39 applies to the non-roaming or roaming with Local breakout cases, the SMF 7101 and the SMF 7103 are combined into one SMF residing in the VPLMN#1 and the UPF 7201 and the UPF 7203 are combined into one UPF residing in the VPLMN#1. The data network 20 is connected with the combined UPF at the VPLMN#1.
[0468] First scenario in Second example of the Third Aspect: Fig. 40 illustrates an example of the Registration procedure in single PLMN.
[0469] The detailed processes of the First scenario in Second example of the Third Aspect are described below with reference to Fig. 40.
[0470] Step 0. The UDM 75 maintains Service profile(s) for subscribed DSATSSS services (e.g., the DSATSSS Service profile(s)) in subscriber data for the UE 3.
[0471] Step 1. The UE 3 sends a Registration Request message to an MN AMF 7001 including at least one of User ID, Dual Reg support, Reg Id set to 1, Extended UE radio capability. Refer to step 1 in First scenario in Second example of the Second Aspect for parameter details. For example, the UE 3 may perform the same or similar process(es) to one by the UE 3 in step 1 of Fig. 17 for the MN AMF 7001. The UE 3 may be in the single PLMN. For example, the UE 3 may send the Registration Request message for the DSMA PDU Session. For example, the UE 3 may perform a Registration procedure for the DSMA PDU Session by sending the Registration Request message. For example, the UE 3 may select the PLMN (e.g., the single PLMN) based on the Service profile(s) in the UE 3, and send the Registration Request message.
[0472] Step 2. Upon reception of the Registration Request message in step 1, the MN AMF 7001 sends an Nudm_UECM_Registration Request message to a UDM 75 including at least one of Dual Reg support, Reg Id which is set to 1, Extended UE radio capability, UE cell location and Radio Type. Refer to step 1 and step 2 in First scenario in Second example of the Second Aspect for parameter details. For example, the MN AMF 7001 may perform the same or similar process(es) to one by the AMF 7001 in step 2 of Fig. 17. For example, the MN AMF 7001 may send the Nudm_UECM_Registration Request message for the DSMA PDU Session. For example, the MN AMF 7001 may perform a Registration procedure for the DSMA PDU Session by sending the Nudm_UECM_Registration Request message.
[0473] Step 3. The UDM 75 sends an Nudm_UECM_Registration Response message to the MN AMF 7001. For example, the UDM 75 may perform the same or similar process(es) to one by the UDM 75 in step 3 of Fig. 17.
[0474] Step 4. After the completion of the Nudm_UECM_Registration service in steps 2 and 3, the MN AMF 7001 sends an Nudm_SDM_Get Request message to the UDM 75 including Dual Reg support, Reg Id which is set to 1, Extended UE radio capability, UE cell location and Radio Type. Refer to Step 2 in First scenario in Second example of the Second Aspect for parameter details. For example, the MN AMF 7001 may perform the same or similar process(es) to one by the AMF 7001 in step 4 of Fig. 17. For example, the MN AMF 7001 may send the Nudm_SDM_Get Request message for the DSMA PDU Session. For example, the MN AMF 7001 may perform a Registration procedure for the DSMA PDU Session by sending the Nudm_SDM_Get Request message.
[0475] Step 5. The UDM 75 finds Subscriber data for the UE 3 and sends an Nudm_SDM_Get Response message to the MN AMF 7001 including the Subscriber data for the UE 3. The Subscriber data includes the Service profiles for DSATSSS services that are applicable to Reg Id which is set to 1 and Dual Reg Allowed. The Service profile may be chosen by the UDM 75 based on the UE cell location, Radio type and roamed AMF. The Service profile of DSATSSS service is defined in the First example of the First Aspect. The following bullets explain each parameter in detail. ・ Dual Reg Allowed is explained in step 5 of the First scenario in Second example of the Second Aspect. Refer to the First scenario in Second example of the Second Aspect. For example, the UDM 75 may perform the same or similar process(es) to one by the UDM 75 in step 5 of Fig. 17.
[0476] Step 6. After the MN AMF 7001 obtains the Subscriber data for the UE 3 from the UDM 75 in step 5, the MN AMF 7001 sends a Registration Accept message to the UE 3 including at least one of 5G-GUTI (e.g., 5G-GUTI1), Dual Reg Allowed and the Service profile for Reg Id which is set to 1. For Dual Reg Allowed, refer to step 5 for parameter details. When the UE 3 receives the Service profile for Reg Id which is set to 1, the UE 3 stores received Service profile in non-volatile memory in the UE 3 by linking with Reg Id which is set to 1. For example, the MN AMF 7001 may perform the same or similar process(es) to one by the AMF 7001 in step 6 of Fig. 17. For example, the UE 3 may perform the same or similar process(es) to one by the UE 3 in step 6 of Fig. 17.
[0477] For example, the Registration procedure in Fig. 40 may be expressed as a Registration procedure for the DSMA PDU Session, or a Registration procedure for multiple data connections over multiple 3GPP access networks, or a Registration procedure for multiple data connections over multiple 3GPP access networks in single PLMN, or a Registration procedure for multiple data connections over multiple 3GPP access networks in PLMN(s).
[0478] Second scenario in Second example of the Third Aspect: Fig. 41 illustrates an example of the Additional Registration procedure commonly applicable to single PLMN. The additional Registration procedure may be initiated by the UE 3 when the UE 3 finds a 3GPP access network that can provide a single connection to configure the DSMA PDU Session in addition to an existing single connection established over the same PLMN.
[0479] The detailed processes of the Second scenario in Second example of the Third Aspect are described below with reference to Fig. 41.
[0480] Step 1. Steps 1 to 5 in the Second scenario in Second example of the Second Aspect take place. For example, the UE 3 may perform the same or similar process(es) to one by the UE 3 in step 1 of Fig. 19. For example, the UE 3 may perform the same or similar process(es) to one by the UE 3 in step 2 of Fig. 19. For example, the UE 3 may select VPLMN#1 or the single PLMN based on the Service profile(s) in the UE 3, and send the RRC Setup Request message to the RAN 502 in VPLMN#1 or the single PLMN. For example, the RAN 502 may perform the same or similar process(es) to one by the RAN 502 in step 3 of Fig. 19. For example, the UE 3 may perform the same or similar process(es) to one by the UE 3 in step 4 of Fig. 19. For example, the UE 3 may send the RRC Setup Complete message to the RAN 502. For example, the RAN 502 may perform the same or similar process(es) to one by the RAN 502 in step 5 of Fig. 19. For example, the UE 3 may send the RRC Setup Complete message for the DSMA PDU Session. For example, the UE 3 may perform a Registration procedure for the DSMA PDU Session by sending the RRC Setup Complete message. For example, the UE 3 may send the Registration Request message for the DSMA PDU Session. For example, the UE 3 may perform a Registration procedure for the DSMA PDU Session by sending the Registration Request message.
[0481] Step 2 The RAN 502 sends the UE Initial message to the SN AMF 7002 including at least one of UE cell location, Radio Type, NAS PDU. For UE cell location and Radio Type, refer to the step 2 in the First scenario in Second example of the Second Aspect for details. If the RAN 502 finds that the MN AMF 7001 is routable based on the received Linked 5G-GUTI which is set to 5G-GUTI1 in the RRC Setup Complete message, the RAN 502 sends the UE Initial message to the MN AMF 7001. In this case, the steps 3 and 7 are omitted and done by internal processing in the MN AMF 7001 and the Registration Accept message in step 8 is sent from the MN AMF 7001. If the RAN 502 finds that the SN AMF 7002 is routable based on the received Linked 5G-GUTI which is set to 5G-GUTI1 in the RRC Setup Complete message, the RAN 502 may send the UE Initial message to the SN AMF 7002. The contents of the UE Initial message in step 2 may be same or similar to the contents of the UE Initial message in step 6 of Fig. 19.
[0482] Step 3. Upon reception of the Registration Request message in step 2 (or upon reception of the UE initial message including the NAS PDU which includes the Registration Request message), the SN AMF 7002 sends an Namf_Communication_UEContextTransfer message to the MN AMF 7001 including at least one of MN 5G-GUTI which is set to 5G-GUTI1, SN 5G-GUTI which is set to 5G-GUTI2, Reg Id which is set to 2, UE Cell Location and Radio type. The following bullets explain each parameter in detail. ・ MN 5G-GUTI indicates the 5G-GUTI that the MN AMF 7001 assigned to the UE 3. ・ SN 5G-GUTI indicates the 5G-GUTI that the SN AMF 7002 has assigned to the UE 3 or going to assign to the UE 3. ・ Reg Id is explained in step 1 of First scenario in Second example of the Second Aspect. Refer to the First scenario in Second example of the Second Aspect. ・ UE Cell Location is explained in step 2 of First scenario in Second example of the Second Aspect. Refer to First scenario in Second example of the Second Aspect. ・ Radio Type is explained in step 2 of First scenario in Second example of the Second Aspect. Refer to First scenario in Second example of the Second Aspect.
[0483] For example, the SN AMF 7002 may send the Namf_Communication_UEContextTransfer message for the DSMA PDU Session. For example, the SN AMF 7002 may perform a Registration procedure for the DSMA PDU Session by sending the Namf_Communication_UEContextTransfer message.
[0484] Step 4. Upon reception of the Namf_Communication_UEContextTransfer message in step 3, the MN AMF 7001 sends an Nudm_SDM_Get Request message to the UDM 75 including at least one of Dual Reg support, Reg Id which is set to 2, Extended UE radio capability, UE cell location and Radio Type. Refer to step 2 in First scenario in Second example of the Second Aspect for parameter details.
[0485] Step 5. The UDM 75 finds Subscriber data for the UE 3 and sends an Nudm_SDM_Get Response message to the MN AMF 7001 including the Subscriber data for the UE 3. The Subscriber data includes the Service profiles for DSATSSS services that are applicable to Reg Id which is set to 2 and Dual Reg Allowed. The Service profile may be chosen by the UDM 75 based on the UE cell location, Radio type and roamed AMF. The Service profile for DSATSSS service (e.g., the Service profile(s)) is defined in the First example of the First Aspect. The following bullets explain each parameter in detail. ・ Dual Reg Allowed is explained in Step 5 of the First scenario in Second example of the Second Aspect. Refer to the First scenario in Second example of the Second Aspect. For example, the UDM 75 may perform the same or similar process(es) to one by the UDM 75 in step 10 of Fig. 19.
[0486] Step 6. After the MN AMF 7001 obtains the Subscriber data for the UE 3 from the UDM 75 in step 5, the MN AMF 7001 stores the SN 5G-GUTI and Reg Id which is set to 2 for the SN 5G-GUTI in the UE context.
[0487] Step 7. The MN AMF 7001 sends an Namf_Communication_UEContextTransfer response message to the SN AMF 7002 including the UE Context. The UE context may include at least one of the MN 5G-GUTI and Reg Id which is set to 1
[0488] Step 8. The SN AMF 7002 stores the received UE context including MN 5G-GUTI and Reg Id which is set to 1 for the MN 5G-GUTI in the UE context.
[0489] Step 9. The SN AMF 7002 sends a Registration Accept message to the UE 3 including at least one of the 5G-GUTI2, Dual Reg Allowed and the Service profile for Reg Id which is set to 2. For Dual Reg Allowed, refer to step 5 for parameter details.
[0490] For example, the Registration procedure in Fig. 41 may be expressed as a Registration procedure for the DSMA PDU Session, or a Registration procedure for multiple data connections over multiple 3GPP access networks, or a Registration procedure for multiple data connections over multiple 3GPP access networks in single PLMN, or a Registration procedure for multiple data connections over multiple 3GPP access networks in PLMN(s).
[0491] Variant 1 of Second scenario in Second example of the Third Aspect: If the UE 3 request to add third or more registrations with another SN AMFs, this procedure can be repeated as many as registrations that the UE 3 wishes to have. In this case, the MN AMF 7001 manages associations with multiple SN AMFs by linking with Reg Id.
[0492] First scenario in Third example of the Third Aspect: Fig. 42 illustrates some examples of the message handling procedures between the MN AMF and the SN AMF after successful Additional Registration procedure in single PLMN. This scenario includes the procedure that the SN AMF 7002 forwards the signalling message to the MN AMF 7001. As the message handling procedures in the scenario are generic, the message handling procedures in the scenario are referred and used by other procedures in this disclosure.
[0493] The following bullets list some example of use cases: ・ The SN AMF 7002 receives the Service Request message (N1 message) from the UE 3. ・ The SN AMF 7002 receives the Location Report message (N2 message) from the RAN 5. ・ The SN AMF 7002 purges the UE 3 (SN AMF 7002 initiated procedure).
[0494] The detailed processes of the First scenario in Third example of the Third Aspect are described below with reference to Fig. 42.
[0495] Step 0-1. The UE 3 has been registered to the MN AMF 7001 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. In the same manner as step 0 in Fig. 40, for example, the UE 3 may send the Registration Request message including the Reg Id which is set to 1, and 5G-GUTI1 may be assigned to the UE 3.
[0496] Step 0-2. The UE 3 has been registered to the SN AMF 7002 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. In the same manner as step 0 in Fig. 41, for example, the UE 3 may send the Registration Request message including the Reg Id which is set to 2, and 5G-GUTI2 may be assigned to the UE 3.
[0497] Step 1. An event happens in the SN AMF 7002. For example, the SN AMF 7002 receives an NAS message from the UE 3.
[0498] Step 2. The SN AMF 7002 decides whether the received message needs to be forwarded to the MN AMF 7001 or not. For example, if the SN AMF 7002 receives a message targeting to or related to the 5G-GUTI1 that is assigned by the MN AMF 7001, the SN AMF 7002 may decide that the received message needs to be forwarded to the MN AMF 7001. For example, if the SN AMF 7002 receives a message targeting to or related to 5G-GUTI other than the 5G-GUTI1 that is assigned by the MN AMF 7001 (e.g., a message targeting to or related to 5G-GUTI that is assigned by the AMF which is not associated with the SN AMF 7002), the SN AMF 7002 may decide that the received message does not need to be forwarded to the MN AMF 7001. In a case where the SN AMF 7002 decides that the received message does not need to be forwarded to the MN AMF 7001, the SN AMF 7002 may not perform the process(es) in step 3.
[0499] Step 3. The SN AMF 7002 sends an Namf_Communication_N1MessageNotify message including at least one of Request type, MN 5G-GUTI which is set to 5G-GUTI1, SN 5G-GUTI which is set to 5G-GUTI2, Reg Id which is set to 2, AS message Container and Service message container. For example, the N1MessageNotify message includes NAS container (e.g., N1 message). For example, the N1MessageNotify message may include NAS container which includes e.g., N1 message. The following bullets explain each parameter in detail. ・ MN 5G-GUTI is explained in step 3 of the Second scenario in Second example of the Third Aspect. Refer to the Second scenario in Second example of the Third Aspect. ・ SN 5G-GUTI is explained in step 3 of the Second scenario in Second example of the Third Aspect. Refer to the Second scenario in Second example of the Third Aspect. ・ Reg Id is explained in step 1 of First scenario in Second example of the Second Aspect. Refer to the First scenario in Second example of the Second Aspect. The Reg Id is the Reg Id associated to the 5G-GUTI in the AMF in which this message is sent. For example, as the Namf_Communication_N1MessageNotify message is sent by the SN AMF 7002 and the SN AMF 7002 is related to Reg Id which is set to 2, the Reg Id in the Namf_Communication_N1MessageNotify message may be set to 2. ・ AS message Container contains an N2 message that the SN AMF 7002 received. If the AS message contains the NAS message, the embedded NAS message is also forwarded by this container. ・ Service message Container contains the Service message that the SN AMF 7002 generated.
[0500] For example, in a case where the SN AMF 7002 decides that the received message needs to be forwarded to the MN AMF 7001, the SN AMF 7002 may send the Namf_Communication_N1MessageNotify message.
[0501] Step 4. Upon reception of the Namf_Communication_N1MessageNotify message in step 3, the MN AMF 7001 takes action according to the received message Containers. For example, if the AS message Container contains the SM related N1 message, the MN AMF 7001 forwards the message(s) to the SMF 7101. For example, if the Service message Container contains the Policy related service message, the MN AMF 7001 forwards the message(s) to the H-PCF 7303. For example, if the Service message Container contains the Subscriber data related service message, the MN AMF 7001 forwards the message(s) to the UDM 75.
[0502] For example, in a case where the MN AMF 7001 receives the message in step 1, the MN AMF 7001 may send the received message to the SN AMF 7002 in the same manner as steps 2 and 3 in Fig. 43. Then the SN AMF 7002 may send the received message to at least one of the SMF 7101, the H-PCF 7303 and the UDM 75.
[0503] Second scenario in Third example of the Third Aspect: Fig. 43 illustrates some examples of the message handling procedures between the MN AMF and the SN AMF after successful Additional Registration procedure in single PLMN. This scenario includes the procedure that the MN AMF 7001 forwards the signalling message to the SN AMF 7002. As the message handling procedures in the scenario are generic, the message handling procedures in the scenario are referred and used by other procedures in this disclosure.
[0504] The following bullets list some example of use cases: ・ The MN AMF 7001 receives a Subscriber data update message (an AMF Service message) for the UE 3. ・ The MN AMF 7001 receives a UE Policy update message (a PCF Service message) for the UE 3.
[0505] The detailed processes of the Second scenario in Third example of the Third Aspect are described below with reference to Fig. 43.
[0506] Step 0-1. The UE 3 has been registered to the MN AMF 7001 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. This step may be same to step 0-1 in Fig. 42.
[0507] Step 0-2. The UE 3 has been registered to the SN AMF 7002 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. This step may be same to step 0-2 in Fig. 42.
[0508] Step 1. An event happens in the MN AMF 7001. For example, the MN AMF 7001 receives a Service message for the UE 3. For example, in step 1-1, the UE 3 receives the Service message from the SMF 7101. For example, in step 1-2, the UE 3 receives the Service message from the H-PCF 73. For example, in step 1-3, the UE 3 receives the Service message from the UDM 75.
[0509] Step 2. The MN AMF 7001 decides whether the received message needs to be forwarded to the SN AMF 7002 or not. For example, if the MN AMF 7001 receives a Service message targeting to or related to the 5G-GUTI2 that is assigned by the SN AMF 7002, the MN AMF 7001 may decide that the received message needs to be forwarded to the SN AMF 7002. For example, if the MN AMF 7001 receives a Service message targeting to or related to 5G-GUTI other than the 5G-GUTI2 that is assigned by the SN AMF 7002 (e.g., a Service message targeting to or related to 5G-GUTI that is assigned by the AMF which is not associated with the MN AMF 7001), the MN AMF 7001 may decide that the received message does not need to be forwarded to the SN AMF 7002. In a case where the MN AMF 7001 decides that the received message does not need to be forwarded to the SN AMF 7002, the MN AMF 7001 may not perform the process(es) in step 3.
[0510] Step 3. The MN AMF 7001 sends an Namf_Communication_N1MessageNotify message including at least one of Request type, MN 5G-GUTI which is set to 5G-GUTI1, SN 5G-GUTI which is set to 5G-GUTI2, Reg Id which is set to 2, AS message Container and Service message container. Refer to the step 3 in the First scenario in Third example of the Third Aspect for parameter details. For example, in a case where the MN AMF 7001 decides that the received message needs to be forwarded to the SN AMF 7002, the MN AMF 7001 may send the Namf_Communication_N1MessageNotify message.
[0511] Step 4. Upon reception of the Namf_Communication_N1MessageNotify message in step 3, the SN AMF 7002 takes action according to the received message Containers. For example, if the Service message Container contains the Policy related service message, the SN AMF 7002 performs necessary actions in the SN AMF 7002 and may send the N1 message to the UE 3 and / or send the N2 message to the RAN 5 (e.g., the RAN 502).
[0512] For example, in a case where the SN AMF 7002 receives the Service message(s) in step 1, the SN AMF 7002 may send the received Service message(s) to the MN AMF 7001 in the same manner as steps 2 and 3 in Fig. 43. Then the MN AMF 7001 may send the received message(s) to at least one of the UE 3 and the RAN 5 (e.g., the RAN 501).
[0513] Third scenario in Third example of the Third Aspect: Fig. 44 illustrates some examples of the UE Context management procedures between the MN AMF 7001 and the SN AMF 7002 after successful Additional Registration procedure in single PLMN. This scenario includes the procedure that the MN AMF 7001 request to update the UE context in the SN AMF 7002. As the message handling procedures in the scenario are generic, the message handling procedures in the scenario are referred and used by other procedures in this disclosure.
[0514] The following bullets list some example of use cases: ・ The MN AMF 7001 updates an 5G-GUTI of the UE 3 by initiating the Generic UE configuration update procedure as described in NPL 6. ・ The Authentication procedure takes place in MN AMF 7001. ・ The Deregistration procedure takes place between UE 3 and MN AMF 7001.
[0515] The detailed processes of the Third scenario in Third example of the Third Aspect are described below with reference to Fig. 44.
[0516] Step 0-1. The UE 3 has been registered to the MN AMF 7001 and 5G-GUTI1 has been assigned to the Reg Id which is set to 1. This step may be same to step 0-1 in Fig. 42.
[0517] Step 0-2. The UE 3 has been registered to the SN AMF 7002 and 5G-GUTI2 has been assigned to the Reg Id which is set to 2. This step may be same to step 0-2 in Fig. 42.
[0518] Step 1. An event happens in the MN AMF 7001. For example, the 5G-GUTI is updated in the MN AMF 7001. For example, the UE Context is updated in the MN AMF 7001.
[0519] Step 2. The MN AMF 7001 decides whether the UE Context in the SN AMF 7002 needs to be updated or not. For example, as mentioned in Fig. 41 (e.g., step 8 of Fig. 41), the SN AMF 7002 may also store the UE Context including the MN 5G-GUTI and Reg Id which is set to 1 after successful Additional Registration procedure. Hence, in a case where at least one of the UE Context in the MN AMF 7001 and the MN 5G-GUTI are updated, the MN AMF 7001 may decide that the UE Context in the SN AMF 7002 needs to be updated. For example, in a case where at least one of the UE Context in the MN AMF 7001 and the MN 5G-GUTI are not updated (e.g., in a case where there is no change between at least one of the previous UE Context in the MN AMF 7001 and the previous MN 5G-GUTI and at least one of the updated UE Context in the MN AMF 7001 and the updated MN 5G-GUTI after step 1), the MN AMF 7001 may decide that the UE Context in the SN AMF 7002 does not need to be updated. In a case where the MN AMF 7001 decides that the UE Context in the SN AMF 7002 does not need to be updated, the MN AMF 7001 may not perform the process(es) in step 3.
[0520] Step 3. The MN AMF 7001 sends an Namf_Communication_UEContextTransfer message to the SN AMF 7002 including at least one of Request type, MN 5G-GUTI which is set to 5G-GUTI1, SN 5G-GUTI which is set to 5G-GUTI2, Reg Id which is set to 1, UE Context, new 5G-GUTI. The following bullets explain each parameter in detail. ・ Request type indicates a type of request. See the following bullets for the Request type: > Update: Update indicates to update the UE Context for the UE 3 in the AMF in which this message is received (e.g., the SN AMF 7002). New 5G-GUTI may be included in this message (e.g., the Namf_Communication_UEContextTransfer message) if the 5G-GUTI in the AMF in which this message is sent is updated. For example, New 5G-GUTI may be included in this message in a case where the 5G-GUTI in the AMF that sends this message is updated. For example, the Update information indicates that the UE Context for the UE 3 in the AMF is updated where this Update information is received. > Delete: Delete indicates to delete the UE Context for the UE 3 in the AMF in which this message is received. For example, the Delete information indicates that the UE context for the UE 3 in the AMF is deleted where this Delete information is received. > Dissociation: Dissociation indicates to remove the established association between the MN AMF 7001 and SN AMF 7002. This Request type (e.g., Dissociation) may be only set by the SN AMF 7002 as the SN AMF 7002 cannot exist alone without MN AMF 7001. For example, if the Purge procedure is completed by the SN AMF 7002, this Request type may be used by the SN AMF 7002. ・ MN 5G-GUTI is explained in step 3 of the Second scenario in Second example of the Third Aspect. Refer to the Second scenario in Second example of the Third Aspect. ・ SN 5G-GUTI is explained in step 3 of the Second scenario in Second example of the Third Aspect. Refer to the Second scenario in Second example of the Third Aspect. ・ Reg Id is explained in step 1 of First scenario in Second example of the Second Aspect. Refer to the First scenario in Second example of the Second Aspect. The Reg Id is the Reg Id associated to the 5G-GUTI in the AMF in which this message is sent. For example, the Reg Id is the Reg Id associated to the 5G-GUTI in the AMF that sends this message (e.g., Reg Id which is set to 1). ・ UE Context is a set of information that are used to manage the UE 3 in the AMF. The UE Context in the AMF is defined in Section 5.2.2.2.2 in NPL 4. The UE Context may be UE Context(s) which is updated. ・ New 5G-GUTI is a 5G-GUTI which is updated. For example, new 5G-GUTI is a 5G-GUTI which is updated by the AMF that sends this message. For example, new 5G-GUTI is a 5G-GUTI in the AMF sending this message which is updated by the AMF. New 5G-GUTI may be included in this message in a case where the Request type which is set to Update is included in this message.
[0521] For example, in a case where the MN AMF 7001 decides that the UE Context in the SN AMF 7002 needs to be updated, the MN AMF 7001 may send the Namf_Communication_UEContextTransfer message.
[0522] Step 4. Upon reception of the Namf_Communication_UEContextTransfer message in step 3, the SN AMF 7002 takes action according to the Request type. If the Request type indicates Update, the SN AMF 7002 updates the UE Context(s) for the UE 3. For example, the SN AMF 7002 may update UE Context(s) in the SN AMF 7002 based on the received UE Context. If the Request type indicates Update and new 5G-GUTI is received, the SN AMF 7002 updates the 5G-GUTI associated with the UE Context(s) for the UE 3. For example, the SN AMF 7002 may update the 5G-GUTI in the SN AMF 7002 (e.g., 5G-GUTI regarding the MN AMF 7001 (e.g., 5G-GUTI1)) based on the new 5G-GUTI, and may update UE Context(s) (e.g., UE Context(s) associated with 5G-GUTI1 or the new 5G-GUTI) in the SN AMF 7002 based on the received UE Context. If the Request type indicates Delete, the SN AMF 7002 deletes the UE Contexts for the UE 3. For example, the SN AMF 7002 may delete the UE Context(s) including the MN 5G-GUTI and the Reg Id which is set to 1. For example, the SN AMF 7002 may delete the UE Context(s) for the MN AMF 7001 (e.g., UE Context(s) associated with at least one of the MN 5G-GUTI and the Reg Id which is set to 1).
[0523] Step 5. The SN AMF 7002 sends an Namf_Communication_UEContextT...
Claims
1. A method of a User Equipment (UE) comprising: receiving information related to service discovery when a Dual Steer Access Traffic Steering, Switching, Splitting service (DSATSSS service) becomes available; and displaying information related to discovered service.
2. A method of a User Equipment (UE) comprising: receiving first system information related to congestion or bit rate via a first Uu interface; and receiving second system information related to congestion or bit rate via a second Uu interface.
3. A method of a User Equipment (UE) comprising: measuring Round-Trip Time (RTT) related information by sending a first message to a network, receiving a second message from the network and using a measurement timer.
4. A User Equipment (UE) comprising: means for receiving information related to service discovery when a Dual Steer Access Traffic Steering, Switching, Splitting service (DSATSSS service) becomes available; and means for displaying information related to discovered service.
5. A User Equipment (UE) comprising: means for receiving first system information related to congestion or bit rate via a first Uu interface; and means for receiving second system information related to congestion or bit rate via a second Uu interface.
6. A User Equipment (UE) comprising: means for measuring Round-Trip Time (RTT) related information by sending a first message to a network, receiving a second message from the network and using a measurement timer.