Method of user equipment (UE) and UE

Abstract

One aspect of the present disclosure includes a method of a user equipment (UE). The method includes receiving information related to service discovery when dual steering access traffic steering, handover, split services (DSATSSS services) become available. The method includes displaying information related to the discovered service.

Description

[0001] This disclosure relates to methods for user equipment (UE) and UEs, etc. Background Technology

[0002] Non-patent document 2 describes the following service requirements. These requirements are important for improving access and network resource utilization, capacity, coverage, reliability, and QoE (Quality of Experience). - The 5G system (5GS) supports traffic routing, splitting, and handover of user data (belonging to the same data session) of the UE across two 3GPP access networks. Reference List Non-patent literature

[0003] Non-patent literature 1: 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".V17.1.0 (2021-12) Non-patent document 2: 3GPP TS 22.841: "Study on Upper layer traffic steer,switch and split over dual 3GPP access". V1.0.0 (2023-03) Non-patent document 3: 3GPP TS 23.501: "System architecture for the 5G System (5GS)". V18.1.0 (2023-03) Non-patent document 4: 3GPP TS 23.502: "Procedures for the 5G System (5GS)". V18.1.1 (2023-04) Non-patent document 5: 3GPP TS 23.503: "Policy and charging control framework for the 5G System (5GS) Stage 2". V18.1.0 (2023-03) Non-Patent Document 6: 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5GSystem (5GS) Stage 3". V18.2.1 (2023-03) Non-patent document 7: 3GPP TS 23.003: "Numbering, addressing and identification". V18.1.0 (2023-03) Non-patent literature 8: 3GPP TS 29.212: "Policy and Charging Control (PCC); Reference points". V17.2.0 (2022-03) Non-patent document 9: 3GPP TS 33.501: "Security architecture and procedures for 5G system". V18.1.0 (2023-03) Non-patent literature 10: IETF RFC 5580: "Carrying Location Objects in RADIUS and Diameter". (2009-08) Non-patent document 11: IETF RFC 792: "Internet Control Message Protocol" (1981-09) Non-patent literature 12: IETF RFC 4443: "Internet Control Message Protocol (ICMPv6)". (March 2006) Non-patent document 13: 3GPP TS 23.548: "5G System Enhancements for EdgeComputing". V18.1.1 (2023-04) Summary of the Invention Technical issues

[0004] The following service requirements are not yet supported by 5GS. For example, there is no mechanism in (one or more) 3GPP specifications to implement the following service requirements. - The 5G system supports traffic routing, splitting, and handover of UE user data (belonging to the same data session) across two 3GPP access networks. Solution to the problem

[0005] A method for a user equipment (UE) according to one aspect of this disclosure includes: When dual-boot access traffic bootstrapping, switching, and service splitting (i.e., when the DSATSSS service becomes available), receive service discovery-related information; and Displays information related to the discovered services.

[0006] A method for a user equipment (UE) according to one aspect of this disclosure includes: Receive first system information related to congestion or bit rate via the first Uu interface; and Second system information related to congestion or bit rate is received via the second Uu interface.

[0007] A method for a user equipment (UE) according to one aspect of this disclosure includes: The round-trip time (RTT) related information is measured by sending a first message to the network, receiving a second message from the network, and using a measurement timer.

[0008] According to one aspect of this disclosure, a user equipment, or UE, includes: A component used to receive service discovery-related information when dual-boot access traffic is bootstrapping, switching, or splitting services (i.e., when the DSATSSS service becomes available); and A component used to display information related to the discovered services.

[0009] According to one aspect of this disclosure, a user equipment, or UE, includes: Components for receiving first system information related to congestion or bit rate via a first Uu interface; and A component for receiving second system information related to congestion or bit rate via a second Uu interface.

[0010] According to one aspect of this disclosure, a user equipment, or UE, includes: A component for measuring round-trip time (RTT) related information by sending a first message to the network, receiving a second message from the network, and using a measurement timer. Attached Figure Description

[0011] Figure 1 This is the first example of a network connection model in the first aspect. Figure 2 This is an example of a service configuration file from the first example of the first aspect. Figure 3 This is the signaling diagram of the first example of the first aspect. Figure 4 This is a block diagram of the first scene in the second example of the first aspect. Figure 5 This is the signaling diagram for the first scenario in the second example of the first aspect. Figure 6 This is the signaling diagram for the first scenario in the second example of the first aspect. Figure 7 This is the signaling diagram for the first scenario in the second example of the first aspect. Figure 8 This is the signaling diagram for the first scenario in the second example of the first aspect. Figure 9 This is the signaling diagram for the first scenario in the second example of the first aspect. Figure 10 This is the signaling diagram for the first scenario in the second example of the first aspect. Figure 11 This is the signaling diagram for the first scenario in the second example of the first aspect. Figure 12 This is an implementation example of the second scenario in the second example of the first aspect. Figure 13 This is an implementation example of the second scenario in the second example of the first aspect. Figure 14 This is an implementation example of the second scenario in the second example of the first aspect. Figure 15 This is an implementation example of the second scenario in the second example of the first aspect. Figure 16 This is the first example of a network connection model in the second aspect. Figure 17 This is the signaling diagram of the first scenario in the second example of the second aspect. Figure 18 It is the signaling diagram of variant 1 of the first scenario in the second example of the second aspect. Figure 19 This is the signaling diagram for the second scenario in the second example of the second aspect. Figure 20 This is a block diagram of the second scenario in the second example of the second aspect. Figure 21 This is the signaling diagram for the third scenario in the second example of the second aspect. Figure 22 This is the signaling diagram for the fourth scenario in the second example of the second aspect. Figure 23 This is the signaling diagram for the fifth scenario in the second example of the second aspect. Figure 24 This is the signaling diagram for the first scenario in the third example of the second aspect. Figure 25 This is the signaling diagram for the second scenario in the third example of the second aspect. Figure 26 This is the signaling diagram for the third scenario in the third example of the second aspect. Figure 27 This is the signaling diagram for the fourth scenario in the third example of the second aspect. Figure 28 This is the signaling diagram for the first scenario in the fourth example of the second aspect. Figure 29 This is the signaling diagram for the first scenario in the fifth example of the second aspect. Figure 30This is the signaling diagram for the first scenario in the sixth example of the second aspect. Figure 31 This is a block diagram of the second scenario in the sixth example of the second aspect. Figure 32 This is the signaling diagram for the third scenario in the sixth example of the second aspect. Figure 33 This is the signaling diagram for the fourth scenario in the sixth example of the second aspect. Figure 34 This is the signaling diagram for the fifth scenario in the sixth example of the second aspect. Figure 35 This is the network connection model for the first scenario in the seventh example of the second aspect. Figure 36 This is the signaling diagram for the second scenario in the seventh example of the second aspect. Figure 37 This is the signaling diagram for the third scenario in the seventh example of the second aspect. Figure 38 This is the signaling diagram for the fourth scenario in the seventh example of the second aspect. Figure 39 This is the first example of a network connectivity model in the third aspect. Figure 40 This is the signaling diagram for the first scenario in the second example of the third aspect. Figure 41 This is the signaling diagram for the second scenario in the second example of the third aspect. Figure 42 This is the signaling diagram for the first scenario in the third example of the third aspect. Figure 43 This is the signaling diagram for the second scenario in the third example of the third aspect. Figure 44 This is the signaling diagram for the third scenario in the third example of the third aspect. Figure 45 This is the signaling diagram for the fourth scenario in the third example of the third aspect. Figure 46 This is the signaling diagram for the first scenario in the fourth example of the third aspect. Figure 47 This is the signaling diagram for the second scenario in the fourth example of the third aspect. Figure 48 This is the signaling diagram for the first scenario in the fifth example of the third aspect. Figure 49 This is the signaling diagram for the first scenario in the sixth example of the third aspect. Figure 50 This is the signaling diagram for the second scenario in the sixth example of the third aspect. Figure 51This is a block diagram of the third scenario in the sixth example of the third aspect. Figure 52 This is the signaling diagram for the third scenario in the sixth example of the third aspect. Figure 53 This is the network connectivity model for the first scenario in the seventh example of the third aspect. Figure 54 This is the signaling diagram for the third scenario in the seventh example of the third aspect. Figure 55 This is a diagram illustrating an overview of the system. Figure 56 This is a block diagram illustrating a UE. Figure 57 This is a block diagram illustrating an (R)AN node. Figure 58 This is a diagram illustrating a system overview of (R)AN nodes based on an O-RAN architecture. Figure 59 This is a block diagram illustrating RU. Figure 60 This is a block diagram illustrating DU. Figure 61 This is a block diagram illustrating a CU. Figure 62 This is a block diagram illustrating AMF. Figure 63 This is a block diagram illustrating SMF. Figure 64 This is a block diagram illustrating UPF. Figure 65 This is a block diagram illustrating PCF. Figure 66 This is a block diagram illustrating NWDAF. Figure 67 This is a block diagram illustrating a UDM. Figure 68 This is a block diagram illustrating NSSF. Figure 69 This is a block diagram illustrating NSACF. Figure 70 This is a block diagram illustrating AUSF. Figure 71 This is a block diagram illustrating AF. Detailed Implementation

[0012] abbreviation For the purposes of this document, the abbreviations given in Non-Patent Document 1 and below shall apply. The abbreviations defined in this document take precedence over the definitions of the same abbreviations (if any) in Non-Patent Document 1. 4G-GUTI (Globally Unique Temporary UE Identifier) 5GC 5G Core Network 5G LAN 5G Local Area Network 5G HE AV 5G Home Environment Authentication Vector 5G SE AV 5G service environment authentication vector 5GS 5G system 5G-AN 5G Access Network 5G-AN PDB 5G Access Network Packet Delay Budget 5G-EIR 5G Device Identifier Register 5G-GUTI (Globally Unique Temporary Identifier) 5G-BRG 5G Broadband Home Gateway 5G-CRG 5G Wired Home Gateway 5G GM 5G Master Clock 5G-RG 5G Home Gateway 5G-S-TMSI 5G-S-Temporary Mobile Subscription Identifier 5G VN (5G Virtual Network) 5QI 5G QoS identifier ABBA architecture-level degradation protection mechanism AF Application Functions AMF Access and Mobility Management Functions AMF-G geographic selection access and mobility management functions AMF-NG Non-Geographically Selected Access and Mobility Management Functions ANDSF Access Network Discovery and Selection Function ARFCN Absolute Radio Frequency Channel Number AS Access Layer ASN Abstract Syntax Notation ATSSS access traffic redirection, switching, and splitting ATSSS-LL ATSSS Low Level AuC Certification Center AUSF Authentication Server Functionality AUTN Authentication Token BCCH Broadcast Control Channel BMCA Best Master Clock Algorithm BSF Binding Support Functionality CAG Closed Access Group CAPIF, a general API framework for 3GPP northbound APIs. CHF Billing Function CN PDB Core Network Packet Delay Budget CP control plane DAPS Dual Activity Protocol Stack DL downlink DN Data Network DNAI DN Access Identifier DNN Data Network Name DRX Discontinuous Reception DSATSSS Dual-Boot Access Traffic Booting, Switching, and Splitting DSATSSS-LL Dual-Boot Access Traffic Booting, Switching, and Splitting - Lower Layer DSMA Dual-Boot Multi-Access DS-TT device-side TSN converter ePDG (Evolved Packet Data Gateway) EBI EPS Carrying Marker ECGI E-UTRAN Cell Global Identifier EPS Evolution Grouping System EUI Extended Unique Identifier FAR forwarding action rules FN-BRG Fixed Network Broadband RG FN-CRG Fixed Network Wired RG FN-RG Fixed Network RG Fully Qualified Domain Name (FQDN) GCI Global Cable Identifier GEO (Geostationary Orbit) GFBR guarantees stream bit rate GMLC Gateway Mobile Location Center User plane data unit in G-PDU GTP package GPS Global Positioning System GPSI General Public Subscription Identifier GSO (Geosynchronous Orbit) GUAMI's globally unique AMF identifier GUTI Globally Unique Temporary UE Identifier HPLMN Home Public Land Mobile Network HR Home Route (Roaming) HSS (Host Subscriber Server) IAB Integration Access and Backhaul IPsec Internet Protocol Security IMEI / TAC IMEI type allocation code IMSI International Mobile Subscriber Identity IPUPS PLMN Inter-UP Security I-SMF Intermediate SMF I-UPF Intermediate UPF LADN Local Area Data Network LBO Local Offloading (Roaming) LCS Location Services LEO (Low Earth Orbit) LMF location management function LoA Automation Level LPP LTE positioning protocol LRF location retrieval function MA Multi-access MCC Mobile Country Code MCX Mission-Critical Services MDBV Maximum Data Burst ME mobile devices MFBR Maximum Stream Bit Rate MICO only allows mobile devices to initiate connections. MINT Service Interruption Minimization MITM middleman MME (Mobility Management Entity) MN master node MNC Mobile Network Code MNO mobile network operator MOCN Multi-Carrier Core Network MPS Multimedia Priority Service MPTCP Multipath TCP Protocol MT (Movement Termination), Movement Termination in Progress, Movement Termination N3IWF Non-3GPP Interoperability Function N3GPP Non-3GPP Access Non-5G capabilities on N5CW WLAN NAI Network Access Identifier NAS Non-Access Layer NCGI NR cell global identifier NCI NR cell identifier NEF Network Open Functions NF Network Functions 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 Slicing Access Layer Group NRF Network Repository Functionality 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 Slicing Specific Authentication and Authorization Functions NSSAI Network Slice Selection Auxiliary Information NSSF Network Slice Selection Function NSSP Network Slice Selection Strategy NSSRG Network Slice Simultaneous Registration Group NW-TT Network-Side TSN Converter NWDAF Network Data Analysis Function PCF policy control function PCO Protocol Configuration Options PCRF policy and charging rules functionality PDB Packet Delay Budget PDR Group Detection Rules PDU Protocol Data Unit PEI Permanent Device Identifier PER grouping error rate PFD Packet Flow Description PLMN Public Land Mobile Network PNI-NPN public network integration of non-public networks PPD Paging Strategy Differential PPF Paging Process Marking PPI Paging Policy Indicator ProSe Proxies based on proximity services PSA PDU Session Anchor PTP (Precision Time Protocol) QFI QoS Flow Identifier QoE (Quality of Experience) RACS Radio Capability Signaling Optimization (R)AN (Radio) Access Network RAT Radio Access Technology RG Home Gateway RIM Remote Interference Management RQA Reflection QoS Attributes RQI Reflection QoS Indicator RRC Radio Resource Control RSC Relay Service Code RSD route selection descriptor RSN Redundant Serial Number RSRP reference signal received power RSRQ reference signal reception quality RTT round trip time RVAS roaming value-added services SA NR Independent New Radio SBA Service-Based Architecture SBI Service-Based Interface SCP Service Communication Agent SD slice delimiter SEAF Safety Anchor Functionality SENSE signal level enhancement network selection SEPP Secure Edge Protection Agent SGW Service 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 serial number SN auxiliary node SN name Service network name SNPN Independent Non-Public Network S-NSSAI Single Network Slice Selection Auxiliary Information SOR Roaming Guide SSC Session and Service Continuity SSCMSP Session and Service Continuity Mode Selection Strategy SST slices / service types SUCI subscription hidden identifier SUPI subscription permanent identifier SV software version TAI Tracking Area Identifier 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 Auxiliary Information Time-Sensitive Networking (TSN) TSN GM TSN Master Clock TSP Traffic Redirection Strategy TT TSN Converter TWIF Trusted WLAN Interoperability 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 Face Functions UPSI UE Policy Part Identifier URLLC Ultra-Reliable Low-Latency Communication UE reachability request parameters for URRP-AMF AMF URSP UE routing policy USIM User Service Identification Module VID VLAN identifier VLAN Virtual Local Area Network VPLMN surveyed public terrestrial mobile networks W-5GAN Wired 5G Access Network W-5GBAN Wired BBF Access Network W-5GCAN Wired 5G Cable Access Network W-AGF wired access gateway function

[0013] definition For the purposes of this document, the terms and definitions given in Non-Patent Document 1 and below shall apply. The terms defined in this document take precedence over the definitions of the same terms (if any) in Non-Patent Document 1.

[0014] overall Those skilled in the art will understand that the elements in the accompanying drawings are illustrated for simplicity and may not necessarily be drawn to scale. Furthermore, in relation to the construction of the apparatus, one or more components of the apparatus may be represented by conventional symbols in the drawings, and the drawings may only show those specific details relevant to understanding aspects of this disclosure, so as not to obscure the drawings with details that would be readily apparent to those skilled in the art benefiting from the description herein.

[0015] For the purpose of facilitating an understanding of the principles of this disclosure, reference will now be made to the aspects illustrated in the accompanying drawings, and these aspects will be described using specific language. However, it will be understood that this is not intended to limit the scope of this disclosure. Such modifications and further alterations to the illustrated systems, as well as such further applications of the principles of this disclosure that would normally occur to those skilled in the art, will be construed as being within the scope of this disclosure.

[0016] The terms “comprises,” “comprising,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a process or method comprising a series of steps does not include only those steps, but may include other steps not expressly listed or inherent to such process or method. Similarly, the prefix “comprises…a” does not exclude the presence of other devices, subsystems, elements, structures, components, additional devices, additional subsystems, additional elements, additional structures, or additional components unless further constraints are imposed. The phrases “in one aspect,” “in another aspect,” and similar language appearing throughout this specification may, but not necessarily 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 one of ordinary skill in the art to which this disclosure pertains. The systems, methods, and examples provided herein are illustrative only and not intended to be limiting.

[0018] In the following specification and claims, numerous terms will be referenced, which may be defined as having the following meanings. Unless the context clearly specifies otherwise, the singular forms “a,” “an,” and “the” include plural references.

[0019] As used herein, information is associated with data and knowledge because data is meaningful information and represents values ​​attributed to parameters. Further knowledge represents an understanding of abstract or concrete concepts. Note that this example system is simplified for the purpose of describing the disclosed subject matter and is not intended to limit the scope of this disclosure. Other means, systems, and configurations may be used in addition to or in place of the system to implement the aspects disclosed herein, and all such aspects are considered to be within the scope of this disclosure.

[0020] The various aspects described below, and the elements included in each aspect, can be implemented independently or in combination with each other. These aspects include novel features that differ from one another. Therefore, these aspects contribute to achieving objectives or solving different problems, and contribute to obtaining different advantages.

[0021] Any list described in the following aspects includes at least one parameter or more parameters.

[0022] The purpose of this disclosure is to provide methods and apparatus that can solve the above-mentioned problems.

[0023] Although this disclosure discloses mechanisms for establishing multiple data plane connections in 5GS, all mechanisms in this disclosure are equally applicable to EPS and / or any other system. Where all mechanisms in this disclosure are applicable to EPS, the following terminology conversions apply: - gNB→eNodeB - AMF→MME - SMF → SGW or PGW or a combination of SGW and PGW or SMF+PGW-C in the case of interoperability with EPS - UPF → SGW-U or PGW-U or a combination of SGW-U and PGW-U, or UPF+PGW-U in the case of interoperability with EPS. - NGAP→S1AP - XnAP→X2AP - Any NGAP message → corresponding S1AP message - Any XnAP message → corresponding X2AP message - Registration request message → Attachment request message or TAU request message - Any AMF service-related message (example: Namf_Communication_NonUeN2InfoNotify) → GTP-C message - Any UDM service related messages (example: Nudm_SDM_Notification) → DIAMETER message - 5G-GUTI→GUTI - 5G-S-TMSI→S-TMSI

[0024] In this disclosure, the above-mentioned service requirements or the services implemented by the above-mentioned service requirements can be represented as Dual-Directed (DS) service, Access Traffic Directed, Handover, Split (ATSSS) service, Access Traffic Directed, Handover, Split (ATSSS) service using 3GPP access network (3G-RAT ATSSS) service, Dual-Directed Access Traffic Directed, Handover, Split (DSATSSS) service, Multi-Access (3G-RAT MA) service using 3GPP access network, Dual-Directed Multi-Access Directed, Handover, Split (DSMASSS) service, etc.

[0025] In this disclosure, a data connection on the 3GPP access network between the UE and the PDU session anchor UPF can be represented as a single connection, a data connection, a data path, a single data connection, a single data path, etc.

[0026] In this disclosure, multiple data connections on multiple 3GPP access networks (or multiple 3GPP access networks) between the UE and the PDU session anchor UPF can be represented as multiple data connections, multiple data paths, multiple data tributaries, multiple access (MA) PDU sessions, MA PDU connections, dual-guided MA (DSMA) PDU sessions, dual-guided MA (DSMA) PDU connections, etc. Similarly, multiple data connections on multiple 3GPP access networks (or multiple 3GPP access networks) between the UE and the PDU session anchor UPF in a single PLMN or multiple PLMNs can be represented as multiple data connections, multiple data paths, multiple data tributaries, MA PDU sessions, MA PDU connections, dual-guided MA (DSMA) PDU sessions, dual-guided MA (DSMA) PDU connections, etc.

[0027] Aspects and elements may involve one, a combination or all of the following descriptions, but are not limited to the following descriptions.

[0028] The aspects and elements may provide solutions relating to one, a combination or all of the following descriptions, but may provide solutions other than those described below.

[0029] For example, there is no mechanism in the 3GPP standard for the UE to know which 3GPP access can be used to configure an MA PDU session for a specific DSATSSS service.

[0030] For example, when a UE can simultaneously listen to NR signals from PLMN-A in geostationary orbit (GEO), NR signals from PLMN-B in low Earth orbit (LEO), and E-UTRA signals from PLMN-C at a terrestrial base station, and the UE wants to establish a MA PDU session for mobile broadband (MBB) access, the UE cannot understand which 3GPP access point can support providing MBB services and which 3GPP access point can be part of a single data path configured for the MA PDU session. Without an explicit service discovery mechanism, the DSATSSS service does not function.

[0031] For example, the following problems need to be solved. - The UE needs to know in advance what DSATSSS services are available for each 3GPP access so that the UE can access the correct 3GPP access. - Other potential issues discovered regarding the DSATSSS service.

[0032] For example, there is no mechanism for end users to know which 3GPP access can be used to configure an MA PDU session for a specific DSATSSS service. For example, when an end user wants to establish a MA PDU session for mobile broadband (MBB) access while the UE can listen to NR signals of PLMN-A in geostationary orbit (GEO), NR signals of PLMN-B in low Earth orbit (LEO), and E-UTRA signals of PLMN-C at a terrestrial base station, the UE cannot understand which 3GPP access can support providing MBB services and which 3GPP access can be part of a single data path configuring the MA PDU session. Without explicit service notification to the end user, the DSATSSS service does not function. For example, the following problems need to be solved. - End users need to know in advance what DSATSSS services are available for each 3GPP access so that they can use that 3GPP access to request MA PDU sessions. - End users need to know in advance how much improvement there is from a QoE perspective by constructing an MA PDU session instead of a single PDU session. - End users need to know in advance what billing rate will be applied if an MA PDU session is to be established. - Other potential issues regarding DSATSSS service notifications (e.g., signaling enhancements for the issues mentioned above).

[0033] For example, in the case where a 3GPP access is provided by a terrestrial gNB and another 3GPP access is provided via satellite as an non-terrestrial network (NTN) access, each 3GPP access can have its own associated AMF, because the AMF is basically allocated based on the geographic coverage provided by the associated base station.

[0034] In this situation, the 3GPP standard lacks a mechanism for handling multiple AMFs for a single subscription in 3GPP access. Without an explicit access and mobility management mechanism for multiple AMFs in 3GPP access, the DSATSSS service does not function. For example, the following problems need to be solved. - How a UE registers with multiple AMFs for 3GPP access within a single PLMN. - How to update UE configuration with multiple AMFs in a single PLMN. - How to update UE policies with multiple AMFs in a single PLMN. - Other potential issues regarding access and mobility management in a single PLMN with multiple AMFs.

[0035] For example, in the case where a 3GPP access is provided by a terrestrial gNB and another 3GPP access is provided via satellite as an non-terrestrial network (NTN) access, each 3GPP access can have its own associated AMF, because the AMF is basically allocated based on the geographic coverage provided by the associated base station. In this scenario, the 3GPP standard lacks a mechanism for establishing a Dual-Booted Multiple Access (DSMA) PDU session for a single subscription with multiple AMFs in 3GPP access. Without an explicit session management mechanism for multiple AMFs in 3GPP access, the DSATSSS service does not function. For example, the following problems need to be solved. - How can a DSMA PDU session be established when different AMFs in a single PLMN are used to manage various data connections? - How can I establish separate data connections managed by different AMFs in a single PLMN at the PDU session anchor with the same SMF and the same UPF to construct a DSMA PDU session? - For example, how does the MT (Mobile Termination in Progress) procedure work if the UE is idle, or if multiple data connections exist? - Other potential issues regarding session mobility management with multiple AMFs.

[0036] For example, in a scenario where a 3GPP access is provided by a terrestrial gNB and another 3GPP access is provided via satellite as a non-terrestrial network (NTN) access, each 3GPP access can have its own associated AMF, as the AMF is essentially allocated based on the geographical coverage provided by the associated base station. Additionally, there are cases where a 3GPP access is provided by different mobile network operators (MNOs). In this scenario, the 3GPP standard lacks a mechanism for handling multiple AMFs from different PLMNs for a single subscription in 3GPP access. Without an explicit access and mobility management mechanism for multiple AMFs in 3GPP access, the DSATSSS service does not function. For example, the following problems need to be solved. - How a UE registers with multiple AMFs from different PLMNs for 3GPP access. - How to update UE configuration using multiple AMFs from different PLMNs. - How to update UE policies using multiple AMFs with different PLMNs. - Other potential issues regarding access and mobility management with multiple AMFs from different PLMNs.

[0037] For example, in a scenario where a 3GPP access is provided by a terrestrial gNB and another 3GPP access is provided via satellite as an NTN (non-terrestrial network) access, each 3GPP access can have its own associated AMF (Advanced Feature Class), because the AMF is essentially allocated based on the geographical coverage provided by the associated base station. Additionally, there are cases where a 3GPP access is provided by different MNOs (Mobile Network Operators). In this scenario, the 3GPP standard lacks a mechanism for establishing DSMA PDU sessions for a single subscription with multiple AMFs in 3GPP access. Without an explicit session management mechanism for multiple AMFs in 3GPP access, the DSATSSS service does not function. For example, the following problems need to be solved. - How can a DSMA PDU session be established when managing data connections using different AMFs from different PLMNs? - How can I establish separate data connections managed by different AMFs from different PLMNs at the PDU session anchor to construct a DSMA PDU session with the same SMF and the same UPF? - In particular, how the Mobile Termination (MT) process works if the UE is in an idle state and if there are multiple data connections spanning different PLMNs. - Other potential issues regarding session mobility management with multiple AMFs from different PLMNs.

[0038] For example, in the case where a 3GPP access is provided by a terrestrial gNB and another 3GPP access is provided via satellite as an non-terrestrial network (NTN) access, each 3GPP access can have its own associated AMF, because the AMF is basically allocated based on the geographic coverage provided by the associated base station. In this scenario, there is no mechanism in the 3GPP standard relating to how the 3GPP security framework works for DSMA PDU sessions with multiple AMFs for a single subscription in 3GPP access. Without an explicit security mechanism for multiple AMFs in 3GPP access, the DSATSSS service does not function. For example, the following problems need to be solved. - How does the authentication process work when multiple AMFs are associated with a single subscription in a 3GPP access? - How security key derivation works when multiple AMFs are associated with a single subscription in a 3GPP access. - How do Non-Access Stratum (NAS) security and Access Stratum (AS) security work when multiple AMFs are associated with a single subscription in a 3GPP access? - Other potential issues regarding 3GPP security with multiple AMFs.

[0039] A user equipment (UE) method according to an example aspect of this disclosure includes: receiving service discovery-related information and displaying information related to the discovered service when dual-boot access traffic bootstrapping, handover, split service (DSATSSS service) becomes available.

[0040] A method for a user equipment (UE) according to an 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] The user equipment (UE) method according to the example aspect of this disclosure includes: measuring round-trip time (RTT) related information by sending a first message to the network, receiving a second message from the network, and using a measurement timer.

[0042] The user equipment (UE) according to an example aspect of this disclosure includes: receiving information related to service discovery and displaying information related to the discovered service when dual-boot access traffic bootstrapping, handover, split service (DSATSSS service) becomes available.

[0043] The user equipment (UE) according to an 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] According to an example aspect of this disclosure, a user equipment (UE) includes: measuring round-trip time (RTT) related information by sending a first message to the network, receiving a second message from the network, and using a measurement timer.

[0045] <First Example Implementation (First Aspect)> This aspect includes the mechanism used by the UE to discover DSATSSS services available in the 3GPP access network. DSATSSS services can be provided by a combination of two 3GPP access networks. The two 3GPP access networks can use the same or different RATs, i.e., NR plus NR or NR plus E-UTRA, where the NR RAT can be terrestrial or satellite NR access (including different satellite orbits, e.g., geostationary orbit (GEO) / medium Earth orbit (MEO) / low Earth orbit (LEO)). Note that GEO is classified as geosynchronous orbit (GSO), while MEO and LEO are classified as non-geosynchronous orbit (NGSO). When two 3GPP access networks are provided by different PLMNs, the two 3GPP access networks can be managed by the same operator or different operators (assuming they have a service agreement). In one example, a standalone non-public network (SNPN) or a public network integrated NPN (PNI-NPN) can be used to establish a DSMA PDU session. The following lists possible combinations of two 3GPP access networks as examples. - Two 3GPP RATs (two NR RATs, one NR RAT, one E-UTRA RAT, and two E-UTRA RATs) are provided by a single PLMN. - Two 3GPP RATs (2 NR RATs, 1 NR RAT + 1 E-UTRA RAT, and 2 E-UTRA RATs) are provided by a single SNPN. - Two 3GPP RATs (2 NR RATs, 1 NR RAT + 1 E-UTRA RAT, and 2 E-UTRA RATs) are provided by a single PNI-NPN. - Each connection to the 3GPP RAT (NR RAT or E-UTRA) is provided by a different PLMN / SNPN / PNI-NPN (a combination of two different PLMN / SNPN / PNI-NPN).

[0046] The first example of the first aspect: Figure 1 An example of the user plane connection model for a DSMA PDU session is shown.

[0047] To establish a DSMA PDU session, UE 3 establishes two separate connections with the same UPF 72, one using RAN 501 and the other using RAN 502. Application Function (AF) 201 in data network 20 uses the DSMA PDU session to provide services. In the case of UE 3 roaming to the visited PLMN (VPLMN), UPF 72 can be in the home PLMN (HPLMN), and at least RAN 501 or RAN 502 can be provided by the VPLMN. Since DSATSSS services can be provided by the home PLMN (HPLMN) to subscribers outside the HPLMN (i.e., outbound roamers), outbound roamers can discover DSATSSS services provided by the HPLMN.

[0048] The DSATSSS service configuration file can also be represented in other ways, such as dual boot (DS) service configuration file, service configuration file, service list configuration file, network slice, DNN, APN, network slice and DNN combination, etc.

[0049] Figure 2 Examples of DSATSSS service profiles (one or more) that can be discovered by UE 3 are shown.

[0050] The following list indicates details of the DSATSSS service configuration file. The DSATSSS service configuration file may include at least one of the following information: - Service: A service is referred to as a service provided to an end user. For example, a service can be referred to as a service provided to (one or more) end users. For example, a service can indicate the DSATSSS service provided. For example, a service can be represented as the following information: Network slices: Network slices can be represented as S-NSSAI as defined in Non-Patent Document 3. A network slice can be represented solely by the Slice / Service Type (SST) portion of the S-NSSAI. For example, "Service" can indicate the S-NSSAI providing the service. "S-NSSAI#1 (MBB)" can indicate that S-NSSAI#1 provides or supports MBB. "S-NSSAI#1 (MBB)" can indicate that MBB is provided on S-NSSAI#1 or on the network slice indicated by S-NSSAI#1. >DNN: A DNN can indicate the DNN that provides the service. >APN: APN can indicate the DNN that provides the service. "DNN or APN (IMS)" can indicate either the DNN or the APN that provides the IMS. >A combination of S-NSSAI and DNN. >A combination of S-NSSAI and APN. SMS (Short Message Service) LCS (Location-Based Services) - PLMN: This information can be associated with a service. The PLMN is referred to as the service provider. A PLMN can be encoded as a PLMN ID. A PLMN can be indicated by its PLMN ID. For example, when an outbound roaming person discovers a service provided by their home network, the outbound roaming person uses their PLMN. In this case, the PLMN is equal to the outbound roaming person's HPLMN. For example, a PLMN can indicate the PLMN that provides the aforementioned "service". For example, a PLMN can indicate the PLMN that provides the service indicated by the aforementioned "service". For example, if the service is generic and provided by any PLMN (e.g., Internet access service), the PLMN can be set to PLMN-agnostic, and the PLMN can be the object of local offloading connections. For example, the PLMN can indicate a PLMN that can provide the DSATSSS service. - Partner PLMN: This information can be associated with a service. A partner PLMN is any notation for a PLMN that is referred to as a PLMN, where such a PLMN can provide DSMA PDU sessions together with an existing PLMN already registered with UE 3. A partner PLMN can be encoded as a PLMN ID. A partner PLMN can be indicated by a PLMN ID. A partner PLMN can be a non-public network (NPN) that includes a standalone non-public network (SNPN) or a public network integrated NPN (PNI-NPN). For example, a partner PLMN can indicate a PLMN that can provide DSMA PDU sessions (or DSATSSS services) together with an existing PLMN already registered with UE 3 or with a PLMN indicated by the aforementioned "PLMN". For example, a partner PLMN can indicate a PLMN that can provide the aforementioned "service" together with an existing PLMN already registered with UE 3 or with a PLMN indicated by the aforementioned "PLMN" or the service indicated by the aforementioned "service". When the partner PLMN is a standalone non-public network (SNPN), the partner PLMN may include a network identifier (NID) or a network selection group ID (GIN). When 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 a service. This location is referred to as the geographic location where the service is available. For example, a location may be a Tracking Area Identifier (TAI), such as the NR Cell Global Identifier (NCGI) as defined in Non-Patent Document 7, the NR Cell Identifier (NCI) as defined in Non-Patent Document 7, the E-UTRAN Cell Global Identifier (ECGI) as defined in Non-Patent Document 7, the Global Cable Identifier (GCI) as defined in Non-Patent Document 7, a common city name, a postal code, a location formed using GPS, or a location expressed in an administrative and geospatial location format as defined in Non-Patent Document 10. For example, a location may indicate the location where the aforementioned "Service" is provided or the service indicated by the aforementioned "Service". - Radio Type: This information may be associated with a service. The radio type may be referred to as a Radio Access Technology (RAT) type. The radio type may indicate the radio type providing the aforementioned "Service" or the service indicated by the aforementioned "Service". If multiple radio types (or RAT types) are associated with a service, the radio types may have a priority among them. For example, radio types may be listed in descending order of priority, where the first radio type in the list has the highest priority. The radio type may be at least one of the following types. The following radio types may be defined as RAT types in Non-Patent Document 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 can be associated with the radio type. The frequency band is referred to as the band where service is available or the band available for the cell supporting the service. The frequency band can be represented by an ARFCN. If multiple frequency bands exist associated with a radio type, the frequency bands can have priorities within the bands. For example, the frequency bands can be listed in descending order of priority (where the first frequency band in the frequency band list has the highest priority), or in reverse order. - Billing Rate: This information can be associated with the radio type. If UE 3 uses the associated radio type for service, this billing rate is referred to as the billing rate. - Prohibited Partner PLMN: This information can be associated with a service. A prohibited partner PLMN is referred to as a PLMN, where such a PLMN is not permitted to provide DSMA PDU sessions with an existing PLMN already registered with UE 3. Prohibited partner PLMNs can be non-public networks (NPNs) including standalone non-public networks (SNPNs) and public network integrated NPNs (PNI-NPNs). For example, a prohibited partner PLMN may indicate a PLMN that cannot provide DSMA PDU sessions with an existing PLMN already registered with UE 3 or with a PLMN indicated by the aforementioned "PLMN". For example, a prohibited partner PLMN may indicate a PLMN that cannot provide the aforementioned "service" or the service indicated by the aforementioned "service" with an existing PLMN already registered with UE 3 or with a PLMN indicated by the aforementioned "PLMN". Prohibited partner PLMNs can be indicated by PLMN ID, NID, or GIN. - Permitted Service Types: This information element indicates a set of network slices for which dual registration is permitted in two different PLMNs to obtain services. For example, if (one or more) eMBB network slices and (one or more) mIoT network slices are sent as compatible network slices or permitted service types, UE 3 can register with a second PLMN for (one or more) mIoT network slices while UE 3 is registered for (one or more) eMBB network slices in the first PLMN. Note that compatible network slices are referred to as network slices that can be provided together with other network slices. In one example, the allowed service types can be indicated as {eMBB (VPLMN 1, VPLMN 2), mIoT (VPLMN 3)}. This means that when UE 3 is registered to an eMBB network slice in VPLMN 1 or VPLMN 2, UE 3 can access services in the mIoT network slice in VPLMN 3. When UE 3 is registered for an eMBB network slice in VPLMN 1 or VPLMN 2, UE 3 cannot perform the registration process to register for an mIoT network slice in a PLMN other than VPLMN 3. In another example, for better 5G security and privacy, a service (e.g., a service on S-NSSAI 1) can be isolated. For instance, a service on S-NSSAI 1 may only be available on PLMN 1, and services on other radio accesses may not be allowed when a service on S-NSSAI 1 is active. In this case, the allowed service type could be indicated as {S-NSSAI#1(PLMN#1), NULL(empty)(PLMN#2)}. In another example, only specific slice / service type (SST) (e.g., eMBB) is supported by a specific RAT. For example, terrestrial NR and E-UTRA support eMBB and URLLC SST, while NTN NR supports eMBB and mIoT SST. - Alternative Service Sources: Services can be permitted from different sources, such as S-NSSAI. For example, one or more services related to a specific company in Tokyo may be available via S-NSSAI 33 related to that specific company, while a smaller set of services related to that specific company outside Tokyo may be available via S-NSSAI 3, which provides services for multiple car brands. In such cases, the Alternative Service Source information element may indicate the primary S-NSSAI (e.g., S-NSSAI 33) for a particular service, and also indicate the alternative S-NSSAI (e.g., S-NSSAI 3) when the primary service source is unavailable. - Validity Period: This information can be associated with a service. The validity period is referred to as the duration for which the service is available. For example, the validity period can indicate the duration for which the service indicated by the aforementioned "service" is available. The validity period can take at least one of the following forms: > Periodic Service Hour Indicator: This identifies whether service hours are updated periodically or, for example, only on demand (e.g., during the duration or intervals of providing the aforementioned "Service" or the service indicated by "Service"). The periodic service hour indicator can indicate whether service hours are provided periodically. Service Duration: The duration of a periodic service. Service duration indicates the duration, interval, or time during which the service or update service described above, or indicated by the "Service," is provided. This information can be used in conjunction with a periodic service time indicator. Example: 8 hours. Periodicity Time: The interval between periodic services. This information can be used in conjunction with the periodic service time indicator. Periodicity time can indicate the timing at which the service time is updated, or it can indicate the periodicity of the service mentioned above or indicated by "Service". Example: Hourly. > Scheduled service hours: The time zone and day of the week when the service (e.g., the "Service" above or the service indicated by "Service") is available. Example: Time: 12:00-22:00, Date: Sunday. - Incompatible Services: This information can be associated with a service. Incompatible services are those that cannot be provided with the specified service. - Prohibited Areas: This information can be associated with a service. A prohibited area is a geographical location where the service is prohibited or cannot be provided. For example, a prohibited area can be a Tracking Area Identifier (TAI), such as the NR Cell Global Identifier (NCGI) as defined in Non-Patent Document 7, the NR Cell Identifier (NCI) as defined in Non-Patent Document 7, the E-UTRAN Cell Global Identifier (ECGI) as defined in Non-Patent Document 7, the Global Cable Identifier (GCI) as defined in Non-Patent Document 7, a common city name, a postal code, a location formed using GPS, or a location represented in an administrative and geospatial location format as defined in Non-Patent Document 10. - Paging Policy: This information can be associated with a service. If the service is available across multiple radio types, the paging policy includes a priority list for paging. For example, radio types are listed in descending order of priority (where the first radio type in the list of radio types used for paging has the highest priority), or in reverse order. When UE3 establishes a DSMA PDU session and UE3 is in idle mode (e.g., CM-IDLE (CM Idle) state or RRC Idle) or inactive state (e.g., RRC Inactive), this list is referenced by UE3, the AMF (e.g., AMF 7001), and the SMF (e.g., SMF7101) to paging UE3. This list can be listed in priority order. Additionally, this information can also include prohibited radio types for paging. For example, LTE-M (GEO) (e.g., LTE-M provided under GEO conditions or environments) is restricted for paging because significant paging resource consumption is expected. Therefore, if a paging strategy includes "LTE-M (GEO)" as a prohibited radio type for paging, this may mean that paging in LTE-M (GEO) is restricted. In this disclosure, the expression "Radio Type (AAA)" can mean a radio type provided under "AAA" conditions or environments. For example, "NR (GEO)" can mean NR provided under GEO conditions or environments. - Registration Trigger Criteria: This information can be associated with a service. UE3 uses the registration trigger criteria to trigger a registration process to the same or a different PLMN when one of the following criteria is met. For example, the registration trigger criteria may include one of the following criteria. For example, UE3 may trigger or perform a registration process or re-registration process to the same or a different PLMN if one of the following criteria is met. When the registration process with VPLMN fails due to some predefined rejection reason. > When registration with the network slice associated with the application in UE 3 fails. When the DSMA PDU session establishment process fails. When user plane setup for an established DSMA PDU session fails. When UE 3 goes outside the coverage of a specific radio access for a specific period of time, UE 3 can trigger re-registration via the same radio access or via a different radio access. - Data Path Addition Trigger Criteria: This information can be associated with a service. UE 3 uses the data path addition trigger criteria to trigger the addition of a new data path to an established DSMA PDU session when one of the following criteria is met. For example, the data path addition trigger criteria may include one of the following criteria. For example, UE 3 may add a new data path to an established DSMA PDU session if one of the following criteria is met. Whenever UE 3 has the opportunity to add something. When a DSMA PDU session becomes unstable. Example: Radio link failure begins. When the upper layer (i.e., the application in UE 3) requires more bandwidth for data flow in the DSMA PDU session. When the access network (e.g., (R)AN) is congested or the coverage of the access network is unstable. When the network detects that there is no policy that allows only a single access for a UE.

[0051] Each line in a (one or more) DSATSSS service configuration file can be represented as an entry. For example, Figure 2 The first entry (i.e., Figure 2 The second line of the DSATSSS service configuration file includes "Service" set to "S-NSSAI#1(MBB)", "Service Provider" set to "PLMN Independent", "Partner PLMN" set to at least one of "PLMN#2" and "PLMN#3", "Location" set to "Japan", "Radio Type" set to at least one of "NR", "EUTRA" and "NR(GEO)", and "Radio Type" set to... Figure 2 The "dual-guided condition" (with one or more parameters) shown. (One or more) DSATSSS service profiles can be represented as information for multiple data connections over multiple 3GPP accesses or as information for DSMA PDU sessions.

[0052] The DSATSSS service can be discovered by UE 3 before and / or after the UE 3 registration process. For example, UE 3 can discover the DSATSSS service based on (one or more) DSATSSS service profiles. For example, in the case where the service is provided by a single PLMN, the partner PLMN may not be included in (one or more) DSATSSS service profiles. The expression “A and / or B” in this disclosure may mean “at least one of A and B”. exist Figure 3 Several DSATSSS service discovery mechanisms have been disclosed in China.

[0053] UE 3 can perform Step 1 (e.g., Step 1-1) and / or Step 2 (e.g., Step 2-1) for DSATSSS service discovery without registering with any 3GPP system. That is, after UE 3 confirms that the desired service is available on the target 3GPP access, UE 3 initiates a registration procedure with the target 3GPP access. For example, if UE 3 confirms that the desired service is available on the target 3GPP access based on (one or more) DSATSSS service profiles, UE 3 can initiate a registration procedure with the target 3GPP access or on the target 3GPP access. On the other hand, UE 3 must register with any 3GPP access 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 DSATSSS service discovery. While steps 1 and 2 provide general DSATSSS service discovery information to all UE 3, steps 3 and 4 can provide specific DSATSSS service discovery information to UE 3.

[0054] Example 1 (Service configuration file broadcast on its own system information) This example includes a mechanism in which system information announcements on the Broadcast Control Channel (BCCH) utilize the DSATSSS service available on the 3GPP access (i.e., the target 3GPP access). The following is for reference. Figure 3 Describes the detailed processing of DSATSSS service discovery in Example 1.

[0055] Step 1-1. RAN 502 in VPLMN#2 broadcasts in its system information that Uu interface 2 may have one or more DSATSSS service profiles provided by RAN 502. For example, RAN 502 may transmit one or more DSATSSS service profiles in its system information (e.g., System Information Block 1 (SIB1) or other SIBx). The one or more DSATSSS service profiles transmitted by RAN 502 may be associated with RAN 502 or VPLMN#2, which includes RAN 502. This system information is a service advertisement from RAN 502. In order to obtain access to the DSATSSS service available with Uu interface 2 of RAN 502, UE 3 may have to receive this system information from RAN 502. In this disclosure, RAN can mean (R)AN node. System information may include one or more PLMNIDs. System information may include a PLMN ID set to VPLMN#2 or PLMN#2. RAN 502 may have one or more DSATSSS service profiles pre-installed, or may receive one or more DSATSSS service profiles from other network nodes, or may generate one or more DSATSSS service profiles based on operator policies. VPLMN#2 may be PLMN#2. RAN 502 can broadcast one or more DSATSSS service profiles per PLMN in the system information. These DSATSSS service profiles per PLMN can be provided for RAN sharing or roaming purposes. UE 3 can apply or follow the DSATSSS service profiles of PLMNs that UE 3 is allowed to initiate registration procedures with or that UE 3 has previously registered with.

[0056] Example 2 (Service configuration file for other 3GPP access broadcasts) This example includes a mechanism in which system information announcements on the BCCH utilize the DSATSSS service available from other (one or more) 3GPP access points. The following is for reference. Figure 3 Describe the detailed processing of DSATSSS service discovery in Example 2.

[0057] Step 2-1. RAN 501 in VPLMN#1 broadcasts in the BCCH system information one or more DSATSSS service profiles that Uu interface 1 can provide. For example, RAN 501 can transmit one or more DSATSSS service profiles in system information (e.g., SIB1 or other SIBx). The one or more DSATSSS service profiles transmitted by RAN 501 can be associated with other 3GPP accesses. This system information is a service advertisement for other 3GPP accesses. RAN 501 may have relationships or coordination that can be completed directly or indirectly via core network nodes (e.g., AMF) connected to RAN 501. In order to obtain the DSATSSS service available with Uu interface 1 of RAN 501, UE 3 may have to receive the system information from RAN 501. System information may include one or more PLMN IDs. System information may include a PLMN ID set to VPLMN#1 or PLMN#1. RAN 501 may have one or more DSATSSS service profiles pre-installed for another 3GPP access, or may receive one or more DSATSSS service profiles for other 3GPP access from other network nodes, or may generate one or more DSATSSS service profiles for other 3GPP access based on operator policies. VPLMN#1 may be PLMN#1. RAN 501 can broadcast (one or more) DSATSSS service profiles for other 3GPP accesses per PLMN in the system information. UE 3 can store or use DSATSSS service profiles for other 3GPP accesses of PLMNs for which UE 3 has registered or is permitted to register or access.

[0058] Example 3 (Service configuration file downloaded from subscriber data) This example includes a mechanism by which UE 3 obtains available DSATSSS services from subscriber data in UDM 75. The following is for reference. Figure 3 Describe the detailed processing of DSATSSS service discovery in Example 3.

[0059] Step 3-1. UDM 75 in HPLMN sends a Nudm service message to AMF 7001 in VPLMN#1. This Nudm service message includes a list of DSATSSS service profiles available in the visited PLMN and the UE location to which UE 3 is roaming. UDM 75 generates a list of DSATSSS service profiles for UE 3 based on at least one of the visited PLMN information and location information provided in advance by AMF 7001 to UDM 75. The list of DSATSSS service profiles sent by UDM 75 may include at least one of the DSATSSS service profiles described in Step 1-1 (one or more) and the DSATSSS service profiles described in Step 2-1 (one or more).

[0060] Step 3-2. Upon receiving a Nudm service message from UDM 75, AMF 7001 sends a NAS message (e.g., a registration acceptance message, a UE configuration update message, or any other existing or new NAS message) to UE 3. This NAS message includes a list of received DSATSSS service profiles.

[0061] Example 4 (Service configuration file in URSP rules) This example illustrates a mechanism by which UE 3 obtains available DSATSSS services from URSP rules in PCF 7303 within the HPLMN. PCF 7303 determines the DSATSSS service based on UE 3's subscription information (e.g., network slice subscription, roaming subscription, etc.), current conditions in the HPLMN or VPLMN, and so on. The following is for reference. Figure 3 Describe the detailed processing of DSATSSS service discovery in Example 4.

[0062] Step 4-1. PCF 7303 sends an NPCF service message to PCF 7301 in VPLMN#1. This NPCF service message includes URSP rules, which include a list of DSATSSS service profiles available in the visited PLMN and the UE location to which UE 3 is roaming. PCF 7303 generates the list of DSATSSS service profiles for UE 3 based on the visited PLMN information and location information provided to PCF 7303 by AMF 7001 in advance via PCF 7301. PCF 7303 can generate the list of DSATSSS service profiles based on UE 3's subscription information (e.g., network slice subscription, roaming subscription, etc.), current conditions in HPLMN or VPLMN, etc. The list of DSATSSS service profiles sent by PCF 7303 may include at least one of the DSATSSS service profiles described in step 1-1 (one or more) and the DSATSSS service profiles described in step 2-1 (one or more).

[0063] Step 4-2. Upon receiving an NPCF service message from PCF 7303, PCF 7301 sends an NPCF service message to AMF 7001 that includes the received URSP rules, which include a list of DSATSSS service profiles from PCF 7303. According to Non-Patent Document 5, the URSP rules including the list of DSATSSS service profiles can also be directly delivered to UE 3 within the UE policy update process triggered by PCF 7301 (i.e., transparent to AMF 7001).

[0064] Step 4-3. Upon receiving an NPCF service message from PCF 7301, AMF 7001 sends a NAS message to UE 3 including the received URSP rules, which include a list of service profiles.

[0065] Instead of a list of DSATSSS service profiles, nodes (e.g., UDM 75, AMF 7001, PCF 7303, or PCF7301) can send (one or more) DSATSSS service profiles. For example, a node can generate (one or more) DSATSSS service profiles based on the information above, which is used to generate a list of DSATSSS service profiles. The service profiles sent by the node (one or more) may include at least one of the DSATSSS service profiles described in step 1-1 and the DSATSSS service profiles described in step 2-1.

[0066] Variant 1 of the first example of the first aspect: In some cases, the available service profiles are stored in AMF 7001, 7002, and thus they are sent / broadcast as NAS messages to (one or more) UE 3 via RAN 501, 502.

[0067] Variant 2 of the first example of the first aspect: UE 3 can register with a VPLMN or SNPN partner network to obtain an available service profile in the registration acceptance message by indicating the registration type as PLMN or SNPN network access registration and providing a request to send a service profile in the registration request message.

[0068] The first scenario in the second example of the first aspect: The first scenario in the second example of the first aspect includes a service discovery notification to the user when the DSATSSS service becomes available. Figure 4 An example of the service discovery notification processing that UE 3 can follow is explained.

[0069] The following is for reference. Figure 4 Describe the detailed handling of service discovery notifications.

[0070] Step 1. The DSATSSS service profile is installed in UE 3. The DSATSSS service profile can be installed via the procedure disclosed in the first example of the first aspect, or it can be pre-installed in UE 3. For example, if UE 3 receives (one or more) DSATSSS service profiles or a list of DSATSSS service profiles, UE 3 can install (one or more) DSATSSS service profiles or the list of DSATSSS service profiles. Installing the list of DSATSSS service profiles can have the same meaning as installing (one or more) DSATSSS service profiles.

[0071] Step 2. UE 3 can detect 3GPP access that can provide DSATSSS services by receiving system information in the surrounding area with the (one or more) DSATSSS service profiles installed at reference step 1. For example, UE 3 can detect 3GPP access (e.g., 3GPP access availability) based on system information and (one or more) DSATSSS service profiles. Figure 1 At least one of Uu interface 1 and Uu interface 2 in the middle, or Figure 1 (Availability of at least one of Uu interface 1 and Uu interface 2 in the system). For example, when UE 3 receives system information including a PLMN ID set to PLMN#2 and the installed DSATSSS service profile includes an entry related to PLMN#2 (e.g., an entry for "Service Provider" set to PLMN#2), for example, Figure 2 In the case of the example entry in the fifth line, UE 3 can detect 3GPP access associated with PLMN#2 that can provide DSATSSS services, or can determine that 3GPP access associated with PLMN#2 that can provide DSATSSS services is available. In the same manner as described above, the UE can detect 3GPP access associated with PLMN #1 that can provide DSATSSSS services, or can determine that 3GPP access associated with PLMN #1 that can provide DSATSSSS services is available.

[0072] Step 3. UE 3 may collect the following useful information about (one or more) end users of UE 3 regarding the detected 3GPP access that can provide DSATSSS services.

[0073] - Congestion level: RAN 501 and RAN 502 can broadcast congestion-related information in existing system information (e.g., SIB1) or in new system information (e.g., SIBx). Figure 5 This example illustrates how RAN 501 and RAN 502 broadcast congestion-related information in the system information on the BCCH. This congestion-related information can be categorized by RAN, cell, network slice, or a combination of these granularities. The congestion information can be the uplink congestion level for user data transmission and / or the downlink congestion level for user data transmission. For example, if congestion information is in units of RAN, then RAN 501 and RAN 502 obtain the congestion level in the RAN by measuring the uplink packet scheduler, downlink packet scheduler, CPU utilization level, etc. For example, if congestion information is on a cell-by-cell basis, RAN 501 and RAN 502 send a list of cells with associated general congestion levels, uplink congestion levels, and downlink congestion levels. For instance, the congestion levels in each cell can be provided to RAN 501 and RAN 502 via the O&M interface. For example, if congestion information is provided on a per-network-slice basis, RAN 501 and RAN 502 can obtain network-slice congestion information from the AMF. Congestion-related information can indicate or imply a congestion level. The congestion level can have a (predefined) range (e.g., an integer value). Alternatively, congestion-related information can indicate or imply a congestion condition. The congestion condition can be binary information (e.g., congested or non-congested). RAN 501 and RAN 502 can broadcast congestion-related information per PLMN. Congestion-related information (e.g., congestion level) can be mapped by UE 3 to a percentage value (e.g., 20%). For example, the congestion level can be provided to UE 3 in the form of a percentage value (e.g., 20%).

[0074] - Bit rate: RAN 501 and RAN 502 can broadcast bit rate-related information in existing system information or new system information. Figure 6 This example illustrates RAN 501 and RAN 502 broadcasting bit rate-related information in the system information on the BCCH. The bit rate-related information can be RAN-based and / or cell-based. The bit rate information can be the current bit rate, expected bit rate, guaranteed bit rate, or maximum bit rate, or all of these. The bit rate-related information can be the current uplink bit rate and / or the current downlink bit rate for user data transmission. RAN 501 and RAN 502 can broadcast bit rate-related information per PLMN. For example, the bit rate can be provided to RAN 501 and RAN 502 via the O&M interface. For example, the bit rate can be measured by RAN 501 and RAN 502. For example, the bit rate can be provided to RAN 501 and RAN 502 via (one or more) other network nodes.

[0075] - RTT (Round Trip Time): RTT-related information can be measured by UE 3. Figure 7 , Figure 8 and Figure 9 RTT measurement processing at the AS level, NAS level, and application level is illustrated respectively.

[0076] AS-level RTT measurement The following is for reference. Figure 7 Describes the detailed processing of AS-level RTT measurements.

[0077] Step 1: The application in UE 3 requests an AS-level RTT measurement from the AS layer of UE 3. For example, UE 3 can request an RTT measurement.

[0078] Step 2: After the application in UE 3 requests a measurement in step 1, UE 3 starts a timer to wait for a response.

[0079] Step 3: The AS layer in UE 3 sends a UL RRC message to RAN 501. The RRC message indicates that it is for bit rate measurement purposes, and once RAN 501 receives the RRC message, the AS layer expects a response from RAN 501. The RRC message can be an RRC setup request message, a UL information transmission message, a UL dedicated message segment message, a measurement report App layer message, or another existing or new RRC message.

[0080] Step 4: After RAN 501 receives the RRC message sent in step 3, RAN 501 replies to UE 3 by sending a DL RRC message. The DL RRC message can be a reply message to the UL RRC message in step 3. The DL RRC message can be an RRC setting message, a DL information transmission message, a DL dedicated message segment message, or another existing RRC message or a new RRC message. A DL RRC message can be represented as an RRC response message. For example, when RAN 501 receives a UL RRC message, RAN 501 can measure the bit rate. For example, RAN 501 can send a DL RRC message that includes the measured bit rate.

[0081] Step 5: After the AS layer in UE 3 receives the RRC reply message from RAN 501, the AS layer in UE 3 reports to the application. For example, the AS layer in UE 3 can send a measurement report, including the measured bit rate, to the application or notify the AS layer that it has received an RRC reply message.

[0082] Step 6. Once the application receives a measurement report or notification from the AS layer, the application stops the timer started in step 2 and measures the RTT between UE 3 and RAN 501. For example, RTT in this disclosure can indicate the duration or interval between the timer starts and the timer ends or stops. In the same manner as described above, UE 3 can measure the RTT of VPLMN#2.

[0083] In addition to or as an alternative to the examples above, UE 3 may measure the propagation delay based on the DL window (e.g., the timing of the reference signal or synchronization signal received by the DL) and the UL transmission timing (e.g., timing advance informed from RAN 501). UE 3 may take the propagation delay into account for RTT measurement, or use the propagation delay as RTT.

[0084] NAS-level RTT measurement The following is for reference. Figure 8 Describes the detailed processing of NAS-level RTT measurements.

[0085] Step 1: The application in UE 3 requests NAS-level RTT measurements for DSATSSS services from the NAS layer of UE 3. For example, UE 3 can request RTT measurements.

[0086] Step 2: After the application in UE 3 requests a measurement in step 1, UE 3 starts a timer to wait for a response.

[0087] Step 3: The AS layer in UE 3 sends a UL RRC message to RAN 501. This UL RRC message includes at least one of the following: an indication that the message is for RTT measurement purposes, a NAS RTT, and an RB identifier. The NAS RTT indicates that the measurement request is for RTT measurement between UE 3 and UPF 7201 in VPLMN#1. The RB identifier identifies the radio bearer on the Uu interface. The UL RRC message can be an RRC setup request message, a UL information transmission message, a UL dedicated message segment message, a measurement report App layer message, or another existing or new RRC message.

[0088] Step 4: When the UL RRC message in Step 3 includes a NAS RTT, RAN 501 converts the received RB identifier into a PDU session ID for the DSMA PDU session and looks up the associated UPF 7201. For example, RAN 501 can store the conversion information and the lookup information. RAN 501 sends a GTP echo request message to UPF 7201. RAN 501 can start a timer to wait for a GTP echo response message from UPF 7201. If the received RB identifier is mapped to an SRB (Signaling Radio Bearer) in RAN 501, RAN 501 sends an NGAP message to AMF 7001 instead of a GTP echo request message, and can start a timer to wait for an NGAP response message from AMF 7001. The NGAP message can be an existing NGAP message or a new NGAP message. For example, if the received RB identifier is mapped to an RB other than an SRB, RAN 501 can send a GTP echo request message to UPF7201.

[0089] Step 5. Upon receiving a GTP echo message from RAN 501, UPF 7201 sends a GTP echo response message to RAN 501. If the timer started in step 4 is running and RAN 501 receives a GTP echo response message, then RAN 501 stops the timer and measures the RTT between RAN 501 and UPF 7201 on the N3 interface. This RTT can be referred to as N3RTT.

[0090] Upon receiving an NGAP message, AMF 7001 sends an NGAP response message to RAN 501. The NGAP response message can be an existing NGAP message or a new NGAP message. If the timer started in step 4 is running and RAN 501 receives the NGAP response message, RAN 501 stops the timer and measures the RTT between RAN 501 and AMF 7001 on the N2 interface. This RTT can be denoted as N2RTT.

[0091] Step 6. After RAN 501 receives a GTP echo response message from UPF 7201 or an NGAP response message from AMF7001 at step 5, RAN 501 responds to UE 3 by sending a DL RRC message. The DL RRC message may include the N3 RTT or N2 RTT measured at step 5. A DL RRC message can be an RRC setup message, a DL information transmission message, a DL dedicated message segment message, or another existing RRC message or a new RRC message. A DL RRC message can also be a response message to the UL RRC message in step 3.

[0092] Step 7: After the AS layer in UE 3 receives the DL RRC message from RAN 501, the AS layer in UE 3 reports to the application. The measurement report may include N3 RTT or N2 RTT. For example, the AS layer can send N3 RTT or N2 RTT to the application.

[0093] Step 8. Once the application receives the measurement report from the AS layer, it stops the timer started in step 2 and measures the RTT between UE 3 and RAN 501. The application can consider the received N3 RTT or N2 RTT as the delay time generated between RAN 5 and UPF 7201 or between RAN 5 and AMF 7001.

[0094] In the same manner as described above, UE 3 can measure the RTT of VPLMN#2.

[0095] Application-level RTT measurement The following is for reference. Figure 9 Describes the detailed processing of application-level RTT measurements.

[0096] Step 1: The application in UE 3 sends an RTT measurement request message to AF 201 in the data network to measure the RTT between UE 3 and AF 201 for use in DSATSSS service. For example, the application can be accessed via Figure 1 The Uu interface 1 shown (e.g., via RAN 501 and UPF 72) sends an RTT measurement request message to AF 201. The RTT measurement request message can be a specific message to the DSATSSS service or a general message. In one example, the RTT measurement request message can be based on the Internet Control Message Protocol (ICMP) as defined in Non-Patent Document 11 or Non-Patent Document 12. For example, UE 3 can request a measurement.

[0097] Step 2: After the application in UE 3 requests a measurement in step 1, UE 3 starts a timer to wait for a response.

[0098] Step 3: Upon receiving an RTT measurement request message from UE 3, AF 201 sends an RTT measurement response message to UE 3. The RTT measurement response message can be a specific message to the DSATSSS service or a general message. In one example, the RTT measurement response message can be based on the Internet Control Message Protocol (ICMP) as defined in Non-Patent Document 11 or Non-Patent Document 12.

[0099] Step 4. Once the application receives the RTT measurement response message from AF 201, the application stops the timer started in step 2 and measures the RTT (round trip time) between UE 3 and AF 201.

[0100] Let's return to the explanation of the following useful information.

[0101] - Billing Rate: Billing rate information helps end users when they add a data connection to the established DSATSSS service. Examples include... Figure 10 and Figure 11 As illustrated, the billing rate information can be obtained by UE 3 via system information or by querying AF 201.

[0102] Billing rates broadcast in system information on BCCH Figure 10This example illustrates RAN 501 and RAN 502 broadcasting billing rate information in the system information on the BCCH. The billing rate information can be per RAN and / or per cell. The billing rate information can be the billing rate information for home subscribers and another billing rate information for inbound roamers. Furthermore, the billing rate information for inbound roamers can be per PLMN from which the inbound roamer originates. For example, RAN 501 and RAN 502 can configure or generate the billing rate information based on operator policies, or they can have the billing rate information pre-existing, or they can receive the billing rate information from (one or more) other network nodes. Billing rate information can indicate the cost of using DSATSSS services. Billing rate information indicates the cost per unit of time used for the DSATSSS service.

[0103] Billing rates provided by AF Figure 11 This example illustrates how to obtain billing rate information from AF.

[0104] The following is for reference. Figure 11 Describe the detailed handling of challenges to AF's billing rate information.

[0105] Step 1: The application in UE 3 sends a rate query message to AF 201, which includes the DSATSSS service (e.g., Figure 2 The term "service" refers to at least one of the following: PLMN and radio type. PLMN indicates the PLMN providing 3GPP access for the DSATSSS service. Radio type indicates the radio type for 3GPP access. For example, radio type could indicate... Figure 2 "Radio type" in the text.

[0106] Step 2: Upon receiving a rate query message from UE 3, AF 201 sends a rate reply message to UE 3, including UE 3's rate information. For example, if UE 3 specifies 3GPP access for DSATSSS services with an indicated PLMN and indicated radio type in the rate query message in Step 1, AF 201 may send rate information for the indicated DSATSSS services corresponding to the indicated PLMN and indicated radio type.

[0107] - SNPN (Standalone Non-Public Network) related information: If 3GPP access is provided by SNPN, this information can be collected by UE 3. SNPN related information may include at least one of the following. PLMN ID List of Network Identifiers (NIDs) Human-readable network names (HRNN) List of supported network selection group IDs (GINs)

[0108] - PNI-NPN (Public Network Integration NPN) related information: If 3GPP access is provided by PNI-NPN, this information can be collected by UE 3. PNI-NPN related information may include at least one of the following. PLMN ID Closed Access Group (CAG) Identifier Human-readable network names (HRNN)

[0109] Refer again Figure 4 . Step 4. After UE 3 has collected useful information from one or more end users in step 3, the AS layer of UE 3 reports all relevant information to the upper layer of UE 3.

[0110] Step 5. The upper layer of UE 3 instructs (one or more) end users, in an easily understandable manner, on the information reported in Step 4. For example, the upper layer of UE 3 may display an icon for candidate 3GPP access for DSATSSS services. For example, the upper layer of UE 3 may display an icon for candidate 3GPP access for DSATSSS services based on useful information.

[0111] The second scenario in the second example of the first aspect discloses an example of how UE 3 displays access information (e.g., (one or more) icons) available for the DSATSSS service.

[0112] The second scenario in the second example of the first aspect: The second scenario in the second example of the first aspect discloses an example relating to how UE 3 displays access information available for the DSATSSS service. Some relevant information to be displayed is obtained through processing as disclosed in the first scenario of the second example of the first aspect.

[0113] Basically, there are two types of information that need to be communicated to (one or more) end users in an easily understandable manner. One type is 3GPP access-related information available to the UE, and the other type is 3GPP access-related information available to specific services, including DSATSSS services.

[0114] 3GPP access-related information available to the UE Figure 12 This example illustrates how 3GPP access availability information is displayed using relevant icons. Some of this information also applies to non-3GPP access (e.g., Wi-Fi access).

[0115] - Congestion Level: Congestion level can be indicated by adding color to the access network icon. For example, if the access network has no congestion (e.g., congestion level less than 20%), the icon for this access network is green. For example, if the access network has little congestion (e.g., congestion level between 20% and 80%), the icon for this access network is yellow. For example, if the access network has severe congestion (e.g., congestion level greater than 80%), the icon for this access network is red. Alternatively, congestion level can be indicated as L (low), M (medium), and H (high). Another way to indicate congestion level is by percentage (e.g., 40%). For example, if the congestion level of 3GPP Access 1 indicates 19% and UE 3 has registered using 3GPP Access 1, UE 3 can display... Figure 12 The leftmost icon.

[0116] - Candidate 3GPP Access: If UE 3 has discovered an available 3GPP access network but has not yet registered, the icon for that 3GPP access network will have associated text. For example, the associated text could be "Available," "Standby," "Ready to Use," "Backup Access," "Alternative Access," or "Emergency Access." The following points explain their meaning as examples: > Available: Indicates that access is available and activated. Standby: Indicates that access is available and ready for use. Ready: Indicates that access is available and ready for use. Ready to use: Indicates that access is available and ready to use. Alternate Access: The indicated access is available and ready to be used as a backup access. Alternative access: Indicates that the access is available and ready for use. Emergency Access: Indicates that access is available and ready for emergency purposes only. In the absence of an icon for the 3GPP access network in the context of no associated text, this may mean that UE 3 has discovered the 3GPP access network is available and has registered with it. 3GPP access can be represented as a 3GPP access network. For example, if UE 3 identifies a non-terrestrial access network as available (e.g., in situations like...). Figure 3 As shown in step 1-1, if UE 3 receives a service profile provided by RAN 502 (e.g., RAN 502 associated with non-terrestrial access or NTN), UE 3 can display... Figure 12 The second icon on the right. For example, in cases where UE 3 identifies non-terrestrial access as available (e.g., in situations like...). Figure 3As shown in step 1-1, if UE 3 receives a service profile provided by RAN 502 (e.g., RAN 502 associated with non-terrestrial access or NTN) and UE 3 has not yet registered using non-terrestrial access, UE 3 can display... Figure 12 The second icon on the right in the middle.

[0117] - RAT type: If 3GPP access is provided via satellite, the icon used for such an access network has a unique icon that is easy for the end user to understand.

[0118] - NPN: If 3GPP access is provided by SNPN or PNI-NPN, the icon for such an access network will be a unique icon that is easily understood by the end user. The icon for 3GPP access provided by SNPN or PNI-NPN can be customized by UE 3 based on the information collected. For example, based on the Network Identifier (NID), Network Selection Group ID (GIN), Closed Access Group (CAG), or human-readable network name, the icon can be generated as a unique icon reflecting that information. If the human-readable network name contains the name of company A, then the icon for that 3GPP access will include the company name A in the icon.

[0119] Figure 13 An example is given of how UE 3 can select a 3GPP access network in a more automatic manner by utilizing 3GPP access network-related information collected through processing as disclosed in the first scenario of the second example of the first aspect.

[0120] The connection settings menu in UE 3 has the following settings. Some of them are not in... Figure 13 Example in.

[0121] RAT Selection Criteria: These criteria specify how to select a RAT. See the following points as example criteria for RAT selection: - Always 3GPP RAT. 3GPP RAT can be further subdivided into TN and NTN. - RAT selects priority whenever access is available. For example, Wi-Fi has the highest priority, while 3GPP access is the second highest priority. - RAT selection prioritizes data rate. For example, if 3GPP access has less than 100Mbps for DL ​​packet transmission, it is moved to Wi-Fi. - RAT selection prioritizes congestion. For example, if 3GPP access is severely congested, it will be moved to Wi-Fi.

[0122] Dual-boot instruction: It is used to activate the DSATSSS service. Connection settings per application: The RAT selection criteria and dual-boot instructions listed above can be applied on an application-by-application basis.

[0123] For example, if in Figure 13 If a user or mobile system (e.g., a UE system) selects "ON" for "3GPP RAT only", then 3GPP RAT will be selected. For example, if in Figure 13 If a user or mobile system (e.g., a UE system) selects "Enable" for "High-speed RAT," then a high-speed RAT will be selected. For example, a less congested RAT type will be selected. Or, a RAT type that provides high-speed communication will be selected. For example, if in Figure 13 If a user or mobile system (e.g., a UE system) selects "Enable" for "Cheapest RAN", then the RAN with low communication costs will be selected. For example, in Figure 13 When a user or their mobile system (e.g., UE system) selects "Enable" for "Dual Boot Connection", the DSATSSS service will be activated. For example, if a user or mobile system (e.g., a UE system) selects "Custom Settings" by application settings, then the RAT type or RAN can be selected on an application-by-application basis.

[0124] Figure 14 Examples are shown of how (one or more) end users can monitor the current status of the access network available to UE 3.

[0125] The connectivity status menu provides the following access network information available to UE 3. Some of these are not listed in the menu. Figure 14 Example in. Notice, Figure 14 In this context, the Mobile Network Operator (MNO) corresponds to the PLMN. For example, UE 3 can know the correspondence between the MNO and PLMN in advance or receive it from (one or more) other network nodes. For example, UE 3 can display the MNO based on the correspondence and the received PLMN ID. The MNO can be a well-known operator name in the market. For example, "ABC Mobile".

[0126] Data rate (e.g., Figure 14 The "speed" parameter indicates the current data rate, with one rate used for uplink data transmission and the other for downlink data transmission. For example, UE 3 can be based on... Figure 6 The information received is used to display the data rate. For example, UE 3 can display... Figure 6 The received bit rate information. Billing Rate: This indicates the billing rate applicable to UE 3 using the 3GPP access network. It can be a local currency rate per packet, a flat rate in local currency, or a no-charge rate. For example, UE 3 could be based on... Figure 10 and Figure 11 The billing rate is displayed by receiving information from at least one of the components. For example, UE 3 can display... Figure 10 and Figure 11 The billing rate information received by at least one of them. Signal strength: It indicates the signal strength of the current access network. Congestion level: This indicates the current congestion level of the access network. For example, UE 3 can be based on... Figure 5 , Figure 7 , Figure 8 and Figure 9 The congestion level is displayed by receiving information from at least one of the following: UE 3. For example, UE 3 can display... Figure 5 The congestion-related information received.

[0127] 3GPP access information available for specific services Figure 15 This example illustrates 3GPP access availability information for a specific service. The same indication can also be applied to non-3GPP access (e.g., Wi-Fi access).

[0128] - Congestion Level: Congestion level can be represented by adding a specific color to the application icon. For example, if the access network used for the application is not congested (e.g., congestion level less than 20%), the application icon is green. For example, if the access network used for the application has little congestion (e.g., congestion level between 20% and 80%), the application icon is yellow. For example, if the access network used for the application is severely congested (e.g., congestion level greater than 80%), the application icon is red. The congestion level can be provided to UE 3 (e.g., applications in UE 3) by AF 201. The congestion level can be provided to UE 3 (e.g., applications in UE 3) for each application in UE 3 by AF 201. AF 201 can measure the congestion level. Congestion-related information (e.g., congestion level) can be mapped by UE 3 to a percentage value (e.g., 20%). For example, the congestion level can be provided to UE 3 in the form of a percentage value (e.g., 20%). For example, UE 3 can display the congestion level. For example, in UE 3, if the congestion level indication for Application 1 (APL 1) is 19%, then... Figure 15 As shown, UE 3 can display the "APL 1" icon by adding green.

[0129] Based on at least one of the disclosures in the first aspect (one or more), it can resolve at least one of the aforementioned problems (one or more). For example, at least one of the disclosures (one or more) in the first aspect can address the issue that the aforementioned service requirements are not yet supported by 5GS. For example, at least one of the disclosures in the first aspect (one or more) can resolve the problem of the DSATSSS service not working.

[0130] For example, according to at least one of the disclosures in the first aspect, at least one of the RAN and AMF can send one or more service profiles to the UE. Therefore, it can resolve at least one of the aforementioned problems. For example, according to at least one of the first aspects (one or more disclosures), the UE can collect 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 aforementioned problems (one or more).

[0131] In all of these first aspects, the enumerated parameters or information in the message can be represented as information about multiple data connections on multiple 3GPP access networks, information about multiple data connections on multiple 3GPP access networks, or information about a DSMA PDU session.

[0132] <Second Example Implementation (Second Aspect)> This aspect includes a mechanism for providing dual-booted ATSSS (DSATSSS) services within a single PLMN or across multiple PLMNs. In the case where the DSATSSS service spans multiple PLMNs, each PLMN provides a single connection, and the two single connections configure a DSMA PDU session. The DSATSS service can have more than two individual connections. That is, a DSMA PDU session can have three or more individual connections spanning multiple PLMNs. All examples in this section are essentially applicable to DSMA PDU sessions with three or more individual connections spanning multiple PLMNs.

[0133] The first example of the second aspect: Figure 16 Examples of architectures for providing DSATSSS services in a single PLMN or in multiple PLMNs are shown.

[0134] Figure 16The example illustrates the establishment of two single connections, one on VPLMN#1 and the other on VPLMN#2, with the DSMA PDU session anchored in the HPLMN as the home route DSMA PDU session. The basic principles of this architecture are listed below. - UE 3 has a single USIM and corresponding single subscriber data in UDM 75. - Each individual connection has its own temporary user identifier (i.e., 5G-GUTI) and the corresponding UE context in 5GC. Registration and session management are independent for each individual connection.

[0135] V-PCF can be represented as PCF. H-PCF can be represented as PCF.

[0136] The first scenario in the second example of the second aspect: Figure 17 Examples of the registration process are shown for both the case of a single PLMN and the case of spanning multiple PLMNs.

[0137] The following is for reference. Figure 17 The detailed processing of the first scenario in the second example of the second aspect is described.

[0138] Step 0. UDM 75 in HPLMN maintains service profiles (e.g., (one or more) DSATSSS service profiles) for the subscribed DSATSSS service in the subscriber data of UE 3. In this disclosure, (one or more) service profiles can be represented as (one or more) DSATSSS service profiles.

[0139] Step 1. UE 3 sends a registration request message to AMF 7001 in VPLMN#1. This registration request message includes at least one of the following: User ID, Dual Reg support, Reg Id set to 1, and extended UE radio capabilities. For example, UE 3 can send a registration request message for a DSMA PDU session. For example, UE 3 can initiate the registration process for a DSMA PDU session by sending a registration request message. The following points explain each parameter in detail. - The user ID (for example, the user ID can be represented as a user identifier) ​​can be 5G-GUTI, SUCI, or SUPI. - Dual Reg support indicates the UE 3's ability to manage two or more temporary user identifiers (i.e., 5G-GUTIs) in 3GPP access to support DSATSSS services. Dual Reg support also indicates the UE 3's capability or ability to support DSMA PDU sessions. Dual Reg support can indicate the UE 3's ability to manage two or more temporary user identifiers (i.e., 5G-GUTIs) in 3GPP access to support DSATSSS services. Dual Reg support can have another name, such as dual boot support, dual boot capability, DSMA PDU session capability, DSMA PDU session support, etc. - The Reg Id identifies the temporary user identifier (i.e., 5G-GUTI) assigned to UE 3. The Reg Id can be a normalized value. For example, a Reg Id set to 1 means that the value 1 corresponds to the 5G-GUTI that AMF 7001 will assign to UE 3 after a successful registration process. For example, the Reg Id can indicate or identify the registration process. - Extended UE radio capabilities include extended UE radio capabilities that support DSATSSS services, such as support for new frequency bands and / or new radio access technologies specifically designed for DSATSSS services. For example, extended UE radio capabilities may indicate that UE 3 has dual radio capabilities supporting 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). Extended UE radio capabilities may also indicate that UE 3 can listen to only one paging channel at a time.

[0140] In this disclosure, the symbol “=" can mean “set to”. For example, “Reg Id=1” can mean “Reg Id set to 1” or “Reg Id that is set to 1”. In this disclosure, the enumeration parameters or information in the message can be parameters or information used to indicate enumeration parameters or information. For example, the "dual Reg support" parameter or information in the registration request message can be information or parameters used to indicate "dual Reg support," or information or parameters used to indicate the UE 3's ability to manage two or more temporary user identifiers (i.e., 5G-GUTI) in 3GPP access to support DSATSSS services. In this disclosure, the enumeration parameters or information in the message can be represented as information about multiple data connections on multiple 3GPP access networks, information about multiple data connections on multiple 3GPP access networks, or information about a DSMA PDU session. For example, UE 3 can select VPLMN#1 based on one or more service profiles in UE 3 and send a registration request message.

[0141] Step 2. Upon receiving the registration request message in Step 1, AMF 7001 sends a Nudm_UECM_Registration request message to UDM 75. This Nudm_UECM_Registration request message includes at least one of the following: dual Reg support, Reg Id set to 1, extended UE radio capabilities, UE cell location, and radio type. For details regarding the parameters of dual Reg support, Reg Id, and extended UE radio capabilities, refer to Step 1. The following points explain each parameter in detail. - UE cell location indicates the UE location, where the UE cell location is provided by RAN 501 in the initial UE message when the initial UE message carries the registration request message to AMF 7001. - The radio type indicates the radio type as defined in the first example of the first aspect. When the initial UE message carries the registration message to AMF 7001, the radio type is also provided by RAN 501 in the initial UE message. For example, the radio type may indicate the radio type supported by RAN 501 or VPLMN#1.

[0142] For example, in step 1, RAN 501 can receive a registration request message within an RRC message from UE 3, and RAN 501 can send an initial UE message including the registration request message to AMF 7001. AMF 7001 can receive the initial UE message including the registration request message from RAN 501. 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 location of UE 3) where RAN 501 provides or sends the initial UE message. The UE cell location may indicate the UE location (e.g., the location of UE 3) where UE 3 sends the registration request message. Then, AMF 7001 can send a Nudm_UECM_Registration request message to UDM 75, which includes at least one of dual Reg support, a Reg Id set to 1, extended UE radio capabilities, UE cell location, and radio type. For example, the AMF 7001 can send a Nudm_UECM_Registration request message for a DSMA PDU session. For instance, the AMF 7001 can perform the registration process for a DSMA PDU session by sending a Nudm_UECM_Registration request message. In this disclosure, each node or function may be stored in at least one of the information sent in the message and the information included in the received message. In this disclosure, UE 3 may be in at least one of VPLMN#1 and VPLMN#2. In this disclosure, UE 3 may be at least one of HPLMN, VPLMN#1, and VPLMN#2.

[0143] Step 3. Upon receiving the Nudm_UECM_Registration request message in Step 2, UDM 75 sends a Nudm_UECM_Registration response message to AMF 7001. In one example, the Nudm_UECM_Registration response message may contain at least one of the following: dual Reg permission and a DSATSSS service profile for a Reg Id set to 1, wherein AMF 7001 may store the DSATSSS service profile in the UE 3 context within AMF 7001. In this case (e.g., where the Nudm_UECM_Registration response message contains at least one of dual Reg permission and a DSATSSS service profile for a Reg Id set to 1), AMF 7001 may not perform Step 4. UDM 75 can remember that AMF 7001 is associated with a Reg Id set to 1.

[0144] Step 4. After the Nudm_UECM_Registration service in steps 2 and 3 is completed, the AMF 7001 sends a Nudm_SDM_Get request message to the UDM75. This Nudm_SDM_Get request message includes at least one of the following: dual Reg support, RegId set to 1, extended UE radio capabilities, UE cell location, and radio type. For parameter details, refer to step 2. For example, the AMF 7001 can send a Nudm_SDM_Get request message for a DSMA PDU session. For instance, the AMF 7001 can perform the registration process for a DSMA PDU session by sending a Nudm_SDM_Get request message.

[0145] Step 5. UDM 75 locates the subscriber data for UE 3 and sends a Nudm_SDM_Get response message containing the subscriber data for UE 3 to AMF 7001. The subscriber data includes one or more service profiles (e.g., one or more DSATSSS service profiles) for the DSATSSS service applicable to Reg Id set to 1 (or for or related to Reg Id set to 1) and at least one of dual Reg permission. The service profile can be selected by UDM 75 based on at least one of UE cell location, radio type, and the AMF to which it is roaming. The service profile for the DSATSSS service is defined in the first example of the first aspect. For example, in this disclosure, UDM 75 may store one or more DSATSSS service profiles for each Reg Id (e.g., 5G-GUTI), UE, and PLMN. The following points explain each parameter in detail. - Dual Reg Allow indicates that UE 3 is permitted to have multiple registrations in 3GPP access and is allowed to establish DSMA PDU sessions. Optionally, Dual Reg Allow may include the maximum number of single data connections that a DSMA PDU session can be configured with. For example, if Dual Reg Allow has a value of three, then a DSMA PDU session can have up to three single data connections for use within 3GPP access.

[0146] For example, if the UDM 75 receives at least one of dual Reg support and extended UE radio capabilities, the UDM 75 may include dual Reg permission and at least one of (one or more) service profiles in the Nudm_UECM_Registration response message or the Nudm_SDM_Get response message.

[0147] For example, when the UDM 75 receives the UE cell location, the UDM 75 can look up one or more service profiles that include one or more entries corresponding to the UE cell location. For example, if the UE cell location indicates one or more cell locations in Japan or one or more locations in Japan, the UDM 75 can look up... Figure 2 At least one of the first, third, and fourth entries, and may be included in the Nudm_SDM_Get response message as (one or more) service profiles.

[0148] For example, if the UDM 75 receives a radio type, the UDM 75 can look up one or more service profiles that include one or more entries corresponding to the radio type. For example, if the radio type indicates NR (GEO), the UDM 75 can look up... Figure 2 At least one of the first and fourth entries in the Nudm_SDM_Get response message, and at least one of the first and fourth entries may be included as (one or more) service profiles in the Nudm_SDM_Get response message.

[0149] When UDM 75 receives a Reg Id set to 1 and searches for (one or more) service profiles, UDM 75 can determine that the found service profiles correspond to or are associated with the Reg Id set to 1. Additionally, UDM 75 can store information indicating that the found service profiles correspond to or are associated with the Reg Id set to 1. For example, when UDM 75 sends (one or more) service profiles, UDM 75 can indicate that the service profiles are for or associated with the received Reg Id (e.g., the Reg Id set to 1). For example, if UDM 75 receives a message in step 2 or step 4, UDM 75 can understand that AMF7001 is associated with or linked to a Reg Id that is set to 1. For example, if UDM 75 receives a message in step 2 or step 4, UDM 75 may store information indicating that AMF7001 is associated with or linked to a Reg Id that is set to 1.

[0150] The same or similar methods for finding subscriber data can be applied to (one or more) other aspects.

[0151] Step 6. After AMF 7001 obtains the subscriber data of UE 3 from UDM 75 in Step 5, and if UE 3 indicated support for dual registration in Step 1 (e.g., if UE 3 sent at least one of dual Reg support and extended UE radio capabilities to AMF 7001 in Step 1), AMF 7001 sends a registration acceptance message to UE 3, which includes at least one of 5G-GUTI (e.g., 5G-GUTI1), dual Reg permission, and a service profile for a Reg Id set to 1. For dual Reg permission, parameter details are described in Step 5. When UE 3 receives one or more service profiles for a Reg Id set to 1, UE 3 stores the received service profiles by linking them to the Reg Id set to 1. For example, UE 3 stores one or more service profiles for a Reg Id set to 1 in its non-volatile memory by linking them to the Reg Id set to 1. Alternatively, UE 3 can store the received service profiles and associate or link the stored service profiles with the Reg Id set to 1. VPLMN#1 (e.g., AMF 7001) can also provide UE 3 with its network capabilities, which indicate whether it supports dual-booting features (e.g., DS service). When UE 3 obtains network capabilities indicating that VPLMN#1 supports dual-booting features, UE 3 can initiate dual registration to other PLMNs while UE 3 is registered to VPLMN#1.

[0152] For example, when AMF 7001 receives a Reg Id set to 1 from UE 3 and sends 5G-GUTI1 to UE 3, AMF 7001 can know that the Reg Id set to 1 corresponds to or is associated with 5G-GUTI1. Additionally, AMF 7001 can store information indicating that the Reg Id set to 1 corresponds to or is associated with 5G-GUTI1. This information can be included in one or more UE contexts of UE 3.

[0153] For example, when UE 3 sends a Reg Id set to 1 to AMF 7001 and receives 5G-GUTI1 from AMF 7001, UE 3 can know that the Reg Id set to 1 corresponds to or is associated with 5G-GUTI1. Additionally, UE 3 can store information indicating that the Reg Id set to 1 corresponds to or is associated with 5G-GUTI1.

[0154] The above-described (one or more) processing can be applied not only to VPLMN#1 but also to VPLMN#2. For example, UE 3 can send a registration request message to AMF 7002 in VPLMN#2, and AMF 7002 can perform the above-described (one or more) processing in the same manner as AMF7001.

[0155] For example, Figure 17The registration process can be represented as a registration process for a DSMA PDU session, or a registration process for multiple data connections on multiple 3GPP access networks, or a registration process for multiple data connections on multiple 3GPP access networks in multiple PLMNs, or a registration process for multiple data connections on multiple 3GPP access networks in (one or more) PLMNs.

[0156] Variant 1 of the first scenario in the second example of the second aspect In one example, such as Figure 18 As shown, all or some of the elements in the subscription service profile of UE 3 may be provided or updated by the service provider (e.g., Application Function (AF) 201) via NEF 79 in UDM 75 and UE 3.

[0157] Step 1. AF 201 (the service provider's application server) triggers an update to the service profile of one or a group of UEs.

[0158] Step 2. AF 201 sends an Nnef_ServiceParameter_Update request message to NEF 79 in the HPLMMN. The Nnef_ServiceParameter_Update request message includes at least one of the following:

[0159] - Global UE Identifier - A global UE identifier specific to its update service profile. It can also be a group identifier for multiple UEs, such as an internal group identifier. The global UE identifier in this disclosure can be represented as a UE global identifier.

[0160] - Service Configuration File - It contains updated elements of the service configuration file. It can contain updated service configuration files.

[0161] - Location - AF 201 may also include the location to which the service profile applies. The location may be a Tracking Area Identifier (TAI), NR Cell Global Identifier (NCGI), NR Cell Identifier (NCI), E-UTRAN Cell Global Identifier (ECGI), or Global Cable Identifier (GCI) as defined in Non-Patent Document 7, a GPS location, or a location expressed in an administrative and geospatial location format as defined in Non-Patent Document 10.

[0162] -Validity- It refers to the time or duration of service availability. Validity can be expressed as at least one of the following: * Periodic Service Time Indicator: Identifies whether service time is periodic (e.g., on-demand only). The definition of "periodic service time indicator" in the first example of the first aspect can be applied to this variant 1. * Service Duration: The duration of the periodic service. This information can be used in conjunction with the periodic service time indicator. Example: 8 hours. The definition of "service duration" in the first example of the first aspect can be applied to this variant 1. * Periodicity Time: The interval between periodic services. This information can be used in conjunction with a periodic service time indicator. Example: per hour. The definition of "periodicity time" in the first example of the first aspect can be applied to this variant 1. * Scheduled service time: The time zone and day of the week when the service is available. Example: Time: 12:00-22:00, Date: Sunday. The definition of "scheduled service time" in the first example of the first aspect can be applied to this variant 1.

[0163] Step 3. If AF 201 provides the UE global identifier, NEF 79 can interact with UDM 75 to convert the UE global identifier into a 3GPP identifier (e.g., SUPI or any user ID that can be identified in the 3GPP system).

[0164] Step 4. NEF 79 updates the service profile of UE 3 in UDM 75 within the subscription information of UE 3. For example, NEF 79 can update the service profile of UE 3 based on the information received in Step 2. For example, NEF 79 can update the service profile of UE 3 in UDM 75 based on the information received in Step 2 by communicating with UDM 75 (e.g., by sending the information received in Step 2 to UDM 75 to update the service profile of UE 3 in UDM 75). For example, if UDM 75 receives information from NEF 79, UDM 75 can update the service profile of UE 3 in UDM 75 based on the information received from UDM 75. NEF 79 can also verify with UDM 75 whether AF 201 is authorized for UE service profile updates.

[0165] Step 5. NEF 79 returns an Nnef_ServiceParameter_Update response message to AF 201 to confirm the successful UE service profile update. For example, UDM 75 can send a notification to NEF 79 indicating that the update of UE 3's service profile is complete. Upon receiving the notification from UDM 75, NEF 79 can send an Nnef_ServiceParameter_Update response message to AF 201.

[0166] Step 6. If the service profile of UE 3 is updated in UDM 75, UDM 75 triggers a notification to the AMFs to which UE 3 has registered (e.g., AMF 7001) to inform UE 3 of the service profile change. If UE 3 has registered with multiple AMFs and one of them is in connected mode with UE 3, UDM 75 sends a notification of the service profile change to the AMFs with which UE 3 has already established a connection. Otherwise, UDM 75 selects any AMF to which UE 3 has registered. Additionally, UDM 75 can internally update the UE 3 service profile. For example, an internal update to the UE 3 service profile can be triggered by O&M.

[0167] Step 7. UDM 75 sends a Namf_SDM_Notification message to AMF 7001. This Namf_SDM_Notification message includes the UE Id or UE group Id (e.g., the identifier of UE 3, the group identifier of one or more UEs including UE 3), the updated service profile of UE 3, or one or more elements from the updated service profile (e.g., one or more updated service profiles). The Namf_SDM_Notification message may include the aforementioned location and validity.

[0168] Step 8. Upon receiving the Namf_SDM_Notification message in Step 7, the AMF 7001 stores at least one of the updated service profile, location, and validity parameters in the UE 3 context within the AMF 7001. If UE 3 is in idle mode and enters connected mode, the AMF 7001 triggers a UE configuration update message to UE 3.

[0169] Step 9. AMF 7001 sends a UE configuration update command message to UE 3, including UE 3's updated service profile. The UE configuration update command message may include location and validity parameters. Alternatively, if UE 3 is in idle mode for AMF 7001, AMF 7001 may wait for UE 3 to connect and then provide the updated service profile to UE 3 using the UE configuration update command message or within a registration acceptance message.

[0170] Step 10. 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, UE 3 stores or updates at least one of the new service profile, location, and validity parameters in non-volatile memory, and considers the new service profile in its further interactions with the network until they are updated again. For example, UE 3 can store at least one of the received service profile, location, and validity. For example, UE 3 can update at least one of the stored service profile, location, and validity by using at least one of the received service profile, location, and validity. For example, UE 3 can replace at least one of the stored service profile, location, and validity with at least one of the received service profile, location, and validity.

[0171] In this disclosure, one or more processes applied to one PLMN can also be applied to another PLMN, and vice versa. For example, in this disclosure, one or more processes applied to VPLMN#1 can also be applied to VPLMN#2, and vice versa.

[0172] The second scenario in the second example of the second aspect: Figure 19 Examples of additional registration procedures are illustrated for both single PLMN scenarios and scenarios spanning multiple PLMNs. When UE 3 looks for a 3GPP access network that can provide a single connection to configure a DSMA PDU session in addition to the existing single connection established on the registered PLMN, UE 3 can initiate an additional registration procedure.

[0173] The following is for reference. Figure 19 The detailed processing of the second scenario in the second example of the second aspect is described.

[0174] Step 0. UDM 75 maintains (one or more) service profiles for the DSATSSS service used for subscription in the subscriber data of UE 3.

[0175] Step 1. UE 3 has been registered with AMF 7001 in VPLMN#1, and 5G-GUTI1 has been assigned to UE 3. 5G-GUTI1 or UE 3 can be associated with a Reg Id set to 1. At least one of UE 3 and AMF 7001 can know that 5G-GUTI1 has been assigned to UE 3, and that 5G-GUTI1 or UE 3 is associated with a Reg Id set to 1. For example, Figure 17 One or more of the processes can be performed in step 1.

[0176] Step 2. UE 3 sends an RRC setup request message to RAN 502 in VPLMN#2 to initiate the RRC connection establishment procedure. For example, UE 3's NAS layer can select VPLMN#2 based on one or more service profiles in UE 3 and inform UE 3's AS layer of the selected PLMN (i.e., VPLMN#2). UE 3's AS layer can look up cells that support VPLMN#2, such as cells in RAN 502. Then, UE 3 sends an RRC setup request message to RAN 502.

[0177] Step 3. RAN 502 sends an RRC setting message to UE 3.

[0178] Step 4. Upon receiving the RRC setup message in Step 3, UE 3 sends an RRC setup complete message to RAN 502. This RRC setup complete message includes at least one of the linked 5G-GUTI set to 5G-GUTI1 and the dedicated NAS. The linked 5G-GUTI indicates the assigned 5G-GUTI to UE 3. The dedicated NAS includes a registration request message. In addition, the registration request message includes at least one of the following: user ID, dual Reg support, registration type set to "add", Reg Id set to 2, 5G-GUTI of the link set to 5G-GUTI1, Reg ID of the link set to 1, and extended UE radio capabilities. For details regarding user ID, dual Reg support, Reg Id, and extended UE radio capabilities, refer to step 1 in the first scenario of the second example in the second aspect. The following points explain each parameter in detail. - A registration type set to "Add" indicates that this is an additional registration process and that an additional temporary user identifier (i.e., 5G-GUTI) and the corresponding UE context are being requested. - The 5G-GUTI indicator for the link, set as 5G-GUTI1, has been assigned to UE 3 for 3GPP access. To uniquely identify UE 3 from any PLMN, the link's 5G-GUTI can be either SUCI or SUPI. UE 3 can only use the 5G-GUTI as the link's 5G-GUTI when it sends an N1 message to the PLMN that assigned the 5G-GUTI. - The Reg ID of a link set to 1 indicates the link ID that has been assigned to the 5G-GUTI of the link set to 1 (e.g., Reg Id 1).

[0179] For example, UE 3 can send an RRC setup complete message for a DSMA PDU session. For example, UE 3 can initiate the registration process for a DSMA PDU session by sending an RRC setup complete message. For example, UE 3 can send a registration request message for a DSMA PDU session. For example, UE 3 can initiate the registration process for a DSMA PDU session by sending a registration request message.

[0180] Step 5. Upon receiving the RRC setup complete message from UE 3, RAN 502 checks whether the AMF indicated in the GUAMI portion of the linked 5G-GUTI can be routed by RAN 502, based on the GUAMI portion of the linked 5G-GUTI (i.e., MCC, MNC, and AMF identifiers). RAN 502 can perform UE cell location mapping based on, for example, the configuration of the Uu interface connected via a non-terrestrial interface.

[0181] Step 6. If AMF 7002 can be routed by RAN 502 as indicated in the GUAMI section of 5G-GUTI (e.g., if RAN 502 selects AMF 7002), then RAN 502 sends a UE Initialization message to AMF 7002 including at least one of the following: UE cell location, radio type, and NAS PDU. Otherwise, RAN 502 selects an AMF based on its internal logic and sends the UE Initialization message to that AMF (e.g., AMF 7002). For details regarding the UE cell location and radio type, refer to step 2 in the first scenario of the second example in the second aspect. The NAS PDU may include a registration request message received from UE 3. For example, the registration request message includes at least one of the following: user ID, dual Reg support, registration type set to "Add", Reg Id set to 2, 5G-GUTI set to 5G-GUTI1 for the link, Reg ID set to 1 for the link, and extended UE radio capabilities. Note that assigning the same AMF to two UE temporary user identifiers (i.e., 5G-GUTI) can provide some benefits by reducing the number of messages used for processing in DSMA PDU sessions. The UE initial message in this disclosure can be represented as the initial UE message. For example, RAN 502 can send a UE initialization message for a DSMA PDU session. For example, RAN 502 can perform the registration process for a DSMA PDU session by sending the UE initialization message.

[0182] Step 7. Upon receiving the registration request message in step 6 (or upon receiving the UE initialization message including the NAS PDU, which includes the registration request message), the AMF 7002 sends a Nudm_UECM_Registration request message to the UDM 75. The Nudm_UECM_Registration request message includes at least one of the following: dual Reg support, registration type set to "add", Reg Id set to 2, extended UE radio capabilities, UE cell location, and radio type. For details on dual Reg support, Reg Id, and extended UE radio capabilities, refer to step 1 in the first scenario of the second example of the second aspect. For details regarding the UE cell location and radio type, refer to step 2 in the first scenario of the second example in the second aspect. For example, the AMF 7002 can send a Nudm_UECM_Registration request message for a DSMA PDU session. For example, the AMF 7002 can perform the registration process for a DSMA PDU session by sending a Nudm_UECM_Registration request message.

[0183] Step 8. Upon receiving the Nudm_UECM_Registration request message in Step 7, UDM 75 sends a Nudm_UECM_Registration response message to AMF7002. If the registration type is set to "Add", UDM 75 also stores AMF 7002 as a visited AMF, in addition to AMF7001 as another visited AMF. Besides the received Reg Id, extended UE radio capabilities, UE cell location, and radio type associated with AMF 7001, UDM 75 also stores the received Reg Id, extended UE radio capabilities, UE cell location, and radio type associated with AMF 7002. In one example, the Nudm_UECM_Registration response message may contain at least one of the following: dual Reg permission and a DSATSSS service profile for a Reg Id set to 2, which AMF 7002 may store in the UE 3 context within AMF 7002. In this case (for example, if the Nudm_UECM_Registration response message contains double Reg permission and a DSATSSS service profile for a Reg Id set to 2), the AMF7002 may not need to perform step 9.

[0184] Step 9. After the Nudm_UECM_Registration service in steps 7 and 8 is completed, the AMF 7002 sends a Nudm_SDM_Get request message to the UDM75. This Nudm_SDM_Get request message includes at least one of the following: dual Reg support, registration type set to "Add", Reg Id set to 2, extended UE radio capabilities, UE cell location, and radio type. For parameter details, refer to step 7. For example, the AMF 7002 can send a Nudm_SDM_Get request message for a DSMA PDU session. For instance, the AMF 7002 can perform the registration process for a DSMA PDU session by sending a Nudm_SDM_Get request message.

[0185] Step 10. UDM 75 retrieves the subscriber data for UE 3 and sends a Nudm_SDM_Get response message containing the subscriber data for UE 3 to AMF 7002. The subscriber data includes dual Reg permissions. For double Reg permission, refer to step 5 in the first scenario of the second example in the second aspect for parameter details. If UE 3 indicates support for dual registration (e.g., in the case where UE 3 sends at least one of dual Reg support and extended UE radio capabilities to AMF 7001 in step 1), the subscriber data includes one or more service profiles for the DSATSSS service applicable to (or for or related to) a Reg Id set to 2. The service profile can be selected by UDM 75 based on the UE cell location, radio type, and the AMF to which it is roaming. The service profile for the DSATSSS service is defined in the first example of the first aspect. For example, UDM 75 can look up subscriber data in the same way as the first scenario in the second example of the second aspect. For example, if UDM 75 receives a message in step 7 or step 9, UDM 75 can understand that AMF7002 is associated with or linked to Reg Id which is set to 2. For example, if UDM 75 receives a message in step 7 or step 9, UDM 75 may store information indicating that AMF7002 is associated with or linked to Reg Id set to 2.

[0186] Step 11. After AMF 7002 obtains the subscriber data of UE 3 from UDM 75 in step 10, AMF 7002 sends a registration acceptance message to UE 3, which includes 5G-GUTI (e.g., 5G-GUTI2) and at least one of a service profile (one or more) for a Reg Id set to 2 and a dual Reg permission. For double Reg permission, refer to step 5 in the first scenario of the second example in the second aspect for parameter details. When UE 3 receives one or more service profiles for a Reg Id set to 2, UE 3 stores the received service profiles by linking them to the Reg Id set to 2. For example, UE 3 can store the received service profiles in its non-volatile memory by linking them to the Reg Id set to 2. Alternatively, UE 3 can store the received service profiles and associate or link the stored service profiles with the Reg Id set to 2. For example, when AMF 7002 receives a 5G-GUTI set to 5G-GUTI1 and a Reg ID set to 1, AMF 7002 can know or understand that the assigned 5G-GUTI2 is associated with or linked to 5G-GUTI1, and that a Reg ID set to 2 is associated with or linked to a Reg ID set to 1. AMF 7002 can know, understand, or detect that the ongoing registration process is an additional registration process. AMF 7002 can know, understand, or detect that a Reg ID received in a registration request message is associated with a Reg ID having a value indicated by the linked Reg ID. AMF 7002 can know, understand, or detect that a 5G-GUTI assigned in this registration process (i.e., the additional registration process) is associated with a 5G-GUTI indicated by the linked 5G-GUTI. The linked Reg ID can indicate a Reg ID that is associated with or linked to the Reg ID in the registration request message. A linked 5G-GUTI can indicate or be linked to a 5G-GUTI that is assigned in the registration process, the ongoing registration process, or the supplementary registration process. For example, 5G-GUTI1, assigned in step 1 and indicated by a linked 5G-GUTI, is associated with or linked to 5G-GUTI2 assigned or sent to step 11.

[0187] For example, when AMF 7002 receives a Reg Id set to 2, a 5G-GUTI set to 5G-GUTI1, and a Reg ID set to 1, and sends 5G-GUTI2 to UE 3, AMF 7002 can know that the Reg Id set to 1, the Reg Id set to 2, 5G-GUTI1, and 5G-GUTI2 are related to each other. Additionally, AMF 7002 can store information indicating the relationship between Reg Id set to 1, Reg Id set to 2, 5G-GUTI1, and 5G-GUTI2. This information can be included in one or more UE contexts of UE 3.

[0188] For example, when UE 3 sends a Reg Id set to 2, a 5G-GUTI set to 5G-GUTI1, a Reg ID set to 1, and receives 5G-GUTI2 from AMF 7002, UE 3 can know that the Reg Id set to 1, the Reg Id set to 2, 5G-GUTI1, and 5G-GUTI2 are related to each other. Additionally, UE 3 can store information indicating the relationship between Reg Id set to 1, Reg Id set to 2, 5G-GUTI1, and 5G-GUTI2.

[0189] For example, Figure 19 The registration process can be represented as a registration process for a DSMA PDU session, or a registration process for multiple data connections on multiple 3GPP access networks, or a registration process for multiple data connections on multiple 3GPP access networks in multiple PLMNs, or a registration process for multiple data connections on multiple 3GPP access networks in (one or more) PLMNs.

[0190] Following a successful additional registration process, UE 3 has two 5G-GUTIs and two associated UE contexts (including, for example, at least two service profiles, one in...). Figure 17 Received in one or more processes, another in Figure 19 Received in (one or more) processes. Figure 20 This example illustrates UE context management in UE 3.

[0191] UE 3 independently maintains a UE context associated with 5G-GUTI1 (or a Reg Id set to 1), including, for example, in Figure 17 The (one or more) service profiles received in one or more processes and another UE context associated with 5G-GUTI2 (or a Reg Id set to 2) (including, for example, in Figure 19 (One or more service configuration files received in one or more processes). Additionally, UE 3 may have an additional 5G-GUTI and associated UE context for non-3GPP access. In one example, a 5G-GUTI used for non-3GPP access can have a Reg Id in UE 3 or can be associated with a Reg Id in UE 3 to jointly manage all 5G-GUTIs within UE 3.

[0192] Variant 1 of the second scenario in the second example of the second aspect If UE 3 (via AMF 7001 and / or AMF 7002 (one for 5G-GUTI1 and the other for 5G-GUTI2)) receives Network Slice Simultaneous Registration Group (NSSRG) information from UDM 75, then UE 3 may request one or more S-NSSAIs from the requested NSSAIs, which share a common NSSG with the S-NSSAIs in the allowed NSSAIs / requested NSSAIs / partially allowed NSSAIs / pending NSSAIs for 5G-GUTI1 and the S-NSSAIs in the allowed NSSAIs / requested NSSAIs / partially allowed NSSAIs / pending NSSAIs for 5G-GUTI2. Additionally, if UE 3 is already registered in both 3GPP access and non-3GPP access, UE 3 may request one or more S-NSSAIs in the requested NSSAIs that share a common NSSRG with one or more S-NSSAIs in the allowed NSSAIs / requested NSSAIs / partially allowed NSSAIs / pending NSSAIs for 5G-GUTI1 on both 3GPP access and non-3GPP access, and share a common NSSRG with one or more S-NSSAIs in the allowed NSSAIs / requested NSSAIs / partially allowed NSSAIs / pending NSSAIs for 5G-GUTI2 on both 3GPP access and non-3GPP access.

[0193] The third scenario in the second example of the second aspect: Figure 21 Examples of context transfer procedures are illustrated for both single PLMN scenarios and scenarios spanning multiple PLMNs. If UE 3 indicates 5G-GUTI as the UE identifier in the registration request message, the context transfer procedure can be initiated by AMF 7001 as the new AMF.

[0194] The following is for reference. Figure 21 The detailed processing of the third scenario in the second example of the second aspect is described.

[0195] Step 0. UE 3 has been registered to AMF 7003 in VPLMN#3, and 5G-GUTI3 has been assigned to Reg Id set to 1. For example, 5G-GUTI3 is assigned to UE 3 and associated with a Reg Id set to 1. For example, if UE 3 sends a Reg Id set to 1 during the registration process and 5G-GUTI3 is assigned to UE 3 during the registration process, 5G-GUTI3 is assigned to or associated with a Reg Id set to 1. Furthermore, in this case, after the registration process is completed, UE 3 and the AMF (e.g., AMF 7003) that performed the registration process with UE 3 are informed that 5G-GUTI3 has been assigned to or associated with a Reg Id set to 1. When UE 3 sends a Reg Id during the registration process, the 5G-GUTI assigned during the registration process is assigned to or associated with the Reg Id. After the registration process is completed, at least one of UE 3, which performed the registration process, or assigned the 5G-GUTI, and the AMF are informed that the 5G-GUTI assigned during the registration process was assigned to or associated with the Reg Id. For example, UE 3 can be configured for PLMN#3 (e.g., AMF 7003). Figure 17 The process involves (one or more) processing steps. In this case, UE 3 may include at least one of the following in the registration request message: user ID, dual Reg support, Reg Id set to 1, and extended UE radio capabilities. UE 3 can then receive a registration acceptance message from AMF 7003, which includes at least one of 5G-GUTI3, dual Reg permission, and a service profile for Reg Id set to 1. Additionally, AMF 7003 can receive subscriber data from UDM 75 and store the subscriber data in the UE context for UE 3. The UE context for UE 3 is stored in AMF 7003. The subscriber data includes at least one of the following: applicable to or for Reg Id set to 1 and (one or more) DSATSSS service profiles with dual Reg permission.

[0196] Step 1. UE 3 sends a registration request message to AMF 7001, which includes at least one of the following: user ID, dual Reg support, Reg Id set to 1, and extended UE radio capabilities. For parameter details, refer to step 1 in the first scenario of the second example in the second aspect. The 5G-GUTI, set to 5G-GUTI3, is included as the user ID. For example, UE 3 can send 5G-GUTI3 as the user ID. For example, UE 3 can send the same Reg Id used in the registration in step 0.

[0197] Step 2. Upon receiving the registration request message, AMF 7001, acting as the new AMF, sends a Namf_Communication_UEContextTransfer message to AMF 7003, including the 5G-GUTI set to 5G-GUTI3. For example, AMF 7001 can send a Namf_Communication_UEContextTransfer message to AMF 7003 including the user ID set to 5G-GUTI3.

[0198] Step 3. AMF 7003 locates the UE context based on the 5G-GUTI received in the Namf_Communication_UEContextTransfer message in Step 2. Then, AMF 7003 sends a Namf_Communication_UEContextTransfer response message to AMF 7001, including at least one of the UE context and a Reg Id set to 1. For example, since AMF 7003 knows that 5G-GUTI3 is associated with a Reg Id set to 1 in Step 0, AMF 7003 sends the UE context (e.g., the UE context of UE 3 or the UE context of 5G-GUTI3, the UE context of the Reg Id set to 1) and at least one of the Reg Id set to 1. The UE context may include one or more service profiles for a Reg Id that is set to 1.

[0199] Step 4. Upon receiving the Namf_Communication_UEContextTransfer response message from AMF 7003, AMF 7001 confirms that the RegId in the received Namf_Communication_UEContextTransfer response message is equal to the RegId received in the registration request message from UE 3 in step 1. After successful confirmation (e.g., if AMF 7001 confirms that the RegId in the received Namf_Communication_UEContextTransfer response message is equal to the RegId received in the registration request message from UE 3 in step 1), AMF 7001 stores the received UE context and assigns a new 5G-GUTI set to 5G-GUTI1 to UE 3, and sends a registration acceptance message to UE 3, which includes the 5G-GUTI (e.g., 5G-GUTI1) and (one or more) service profiles for the RegId set to 1. When UE 3 receives one or more service profiles for a Reg Id set to 1, UE 3 updates the received service profile in its non-volatile memory by linking it to 5G-GUTI1 and the Reg Id set to 1. For example, UE 3 may store the received service profiles and associate or link the stored service profiles with 5G-GUTI1 and the Reg Id set to 1. VPLMN#1 (e.g., AMF 7001) can also provide UE 3 with its network capabilities, which indicate whether it supports dual-booting features (e.g., DS service). When UE 3 obtains network capabilities indicating that VPLMN#1 supports dual-booting features, UE 3 can initiate dual registration to other PLMNs while the UE is registered to VPLMN#1.

[0200] For example, Figure 21 The registration process can be represented as a registration process for a DSMA PDU session, or a registration process for multiple data connections on multiple 3GPP access networks, or a registration process for multiple data connections on multiple 3GPP access networks in multiple PLMNs, or a registration process for multiple data connections on multiple 3GPP access networks in (one or more) PLMNs.

[0201] The fourth scenario in the second example of the second aspect: Figure 22 Examples of UE policy-related procedures (or URSP rule download procedures) are illustrated for both single PLMN scenarios and scenarios spanning multiple PLMNs. UE policy-related procedures can occur during the registration process.

[0202] The following is for reference. Figure 22 The detailed processing of the fourth scenario in the second example of the second aspect is described.

[0203] Step 1. Figure 19 Steps 0 to 10 occur in the second scenario of the second example of the second aspect.

[0204] Step 2. After the UE policy association is successfully established between AMF 7002, PCF 7302 in VPLMN#2, and PCF 7303 in HPLMN (e.g., in...), Figure 19In the second scenario of the second example of the second aspect, after steps 0 to 10 are completed and AMF 7002, PCF 7302, and PCF 7303 can communicate with each other, AMF 7002 sends an Npcf_AMPolicyControl_Create message to PCF 7302. This Npcf_AMPolicyControl_Create message includes at least one of the following: a registration type set to "Add", a Reg Id set to 2, a linked 5G-GUTI set to 5G-GUTI1, extended UE radio capabilities, UE cell location, and radio type. For parameter details, refer to step 4 of the second scenario of the second example of the second aspect.

[0205] Step 3. Upon receiving the Npcf_AMPolicyControl_Create message from AMF 7002, PCF 7302 sends an Npcf_AMPolicyControl_Create message to PCF 7303, which includes (one or more) parameters received in the Npcf_AMPolicyControl_Create message from PCF 7302.

[0206] Step 4. Taking into account at least one of the received extended UE radio capabilities, UE cell location, and radio type, PCF 7303 generates a service profile in the URSP rules for UE 3. For example, PCF 7303 can generate a profile based on at least one of the received extended UE radio capabilities, UE cell location, and radio type, such as... Figure 2 The example shows one or more service profiles. For instance, PCF 7303 can generate profiles based on operator policies, such as... Figure 2 The example shows one or more service profiles. For example, PCF 7303 can generate one or more service profiles for a Reg Id set to 2.

[0207] Step 5. PCF 7303 sends an Npcf_AMPolicyControl_Create response message to PCF 7302, which includes the URSP rules generated in step 4. For example, the URSP rules include one or more service profiles with Reg IDs set to 2.

[0208] Step 6. Upon receiving the Npcf_AMPolicyControl_Create response message from PCF 7303, PCF 7302 sends an Npcf_AMPolicyControl_Create response message to AMF 7002. This Npcf_AMPolicyControl_Create response message includes (one or more) parameters received in the Npcf_AMPolicyControl_Create response message from PCF 7303. For example, the URSP rule includes (one or more) service profiles with a Reg Id set to 2.

[0209] Step 7. After AMF 7002 obtains the URSP rules for UE 3 from PCF 7302 in step 6, AMF 7002 sends a registration acceptance message to UE 3. This registration acceptance message includes at least one of 5G-GUTI and a URSP rule containing a service profile for a RegId set to 2. 5G-GUTI can be 5G-GUTI2. When UE 3 receives a service profile for a Reg Id set to 2 in the URSP rule, UE 3 stores the received service profile in its non-volatile memory by linking it to the Reg Id set to 2. For example, UE 3 can store one or more received service profiles and associate or link the stored service profiles with the Reg Id set to 2.

[0210] The fifth scenario in the second example of the second aspect: Figure 23 Examples of the Network Slice Admission Control Function (NSACF) process are illustrated for both single PLMN scenarios and scenarios spanning multiple PLMNs. The NSACF process can be implemented during the registration process (e.g., Figure 17 This may occur during the registration process (either in 19, 21, or 22).

[0211] The following is for reference. Figure 23 The detailed processing of the fifth scenario in the second example of the second aspect is described.

[0212] Step 1. Figure 19 Steps 0 to 10 occur in the second scenario of the second example of the second aspect.

[0213] Step 2. AMF 7002 sends an Nnsacf_NSAC_NumOfUEsUpdate message to NSACF 7702 in VPLMN#2. This Nnsacf_NSAC_NumOfUEsUpdate message includes at least one of the following: S-NSSAI, an update flag set to "Increment", a registration type set to "DS", a Reg Id set to 2, and a 5G-GUTI for the link set to 5G-GUTI1. For parameter details, refer to step 4 in the second scenario of the second example of the second aspect. Additionally, S-NSSAI indicates the network slice to which UE 3 is registering. The update flag set to "Increment" indicates that the update request is used to increment the number of registered UEs in the network slice. The registration type set to "DS" indicates that the registration is associated with a dual-boot or DSMA PDU session. For example, the AMF 7002 can send the Nnsacf_NSAC_NumOfUEsUpdate message for NSAC or for the per-network-slice UE availability check and update process for S-NSSAI. For example, the AMF 7002 can perform the per-network-slice UE availability check and update process for S-NSSAI by sending the Nnsacf_NSAC_NumOfUEsUpdate message. For example, the Nnsacf_NSAC_NumOfUEsUpdate message can be a message for the per-network-slice UE availability check and update process for S-NSSAI.

[0214] Step 3. Upon receiving the Nnsacf_NSAC_NumOfUEsUpdate message from AMF 7002, NSACF 7702 performs local UE quota control for S-NSSAI (e.g., the per-network-slice UE availability check and update process for S-NSSAI as described in Non-Patent Document 4), and sends the Nnsacf_NSAC_NumOfUEsUpdate message to NSACF 7703 in HPLMN, which includes the parameters received in the Nnsacf_NSAC_NumOfUEsUpdate message from NSACF 7702. For example, if the Nnsacf_NSAC_NumOfUEsUpdate message includes at least one of S-NSSAI, an update flag set to "increase", a registration type set to "DS", a Reg Id set to 2, and a 5G-GUTI linked to 5G-GUTI1, NSACF 7702 can perform local UE quota control on S-NSSAI and send the Nnsacf_NSAC_NumOfUEsUpdate message to NSACF 7703. For example, NSACF 7702 can send the Nnsacf_NSAC_NumOfUEsUpdate message for NSAC or for the per-network-slice UE availability check and update process for S-NSSAI. For example, NSACF 7702 can perform the per-network-slice UE availability check and update process for S-NSSAI by sending the Nnsacf_NSAC_NumOfUEsUpdate message. For example, the Nnsacf_NSAC_NumOfUEsUpdate message can be a message for the per-network-slice UE availability check and update process for S-NSSAI.

[0215] Step 4. NSACF 7703 considers at least one of the received S-NSSAI, update flag, registration type, Reg Id, and linked 5G-GUTI to perform UE quota control for S-NSSAI (e.g., the per-network-slice UE availability check and update process for S-NSSAI in Non-Patent Document 4). For example, if the registration type is set to "DS" based on an SLA (Service Level Agreement) with a third party, NSACF 7703 does not increase the number of UEs. For example, if the Nnsacf_NSAC_NumOfUEsUpdate message includes at least one of S-NSSAI, an update flag set to "increase", a registration type set to "DS", a Reg Id set to 2, and a 5G-GUTI linked to 5G-GUTI1, NSACF 7702 can perform UE quota control on S-NSSAI.

[0216] Step 5. NSACF 7703 sends an Nnsacf_NSAC_NumOfUEsUpdate response message, including the result, to NSACF 7702. The result indicates the outcome of UE quota control. The result can indicate the outcome of the per-network-slice UE availability check and update process for S-NSSAI. The result can be "Maximum number of UEs registered to the network slice reached" or "Maximum number of UEs registered to the network slice not reached".

[0217] Step 6. Upon receiving the Nnsacf_NSAC_NumOfUEsUpdate response message from NSACF 7703, NSACF 7702 sends the Nnsacf_NSAC_NumOfUEsUpdate response message to AMF 7002. This Nnsacf_NSAC_NumOfUEsUpdate response message includes (one or more) parameters received in the Nnsacf_NSAC_NumOfUEsUpdate response message from NSACF 7703.

[0218] Step 7. After the NSACF procedure is performed by AMF 7002 in steps 2 to 6, AMF 7002 sends a registration acceptance message to UE 3, including the 5G-GUTI set to 5G-GUTI2 and a reason. The reason may indicate the result of UE quota control in step 5. The reason may include information related to the result in step 5. When UE 3 receives a reason reflecting the result of UE quota control in step 5, UE 3 updates the allowed NSSAI, rejected NSSAI, pending NSSAI, partially allowed NSSAI, and partially rejected NSSAI in the storage for 5G-GUTI2 (5G-GUTI2 can be associated with a Reg Id set to 2) in UE 3 to reflect the result of UE quota control in step 5. For example, if UE 3 receives an indication for S-NSSAI that "the maximum number of UEs registered to the network slice has been reached," then UE 3 stores the S-NSSAI in the rejected NSSAIs for 5G-GUTI2, and if the S-NSSAI is in the allowed NSSAIs for 5G-GUTI2, then removes the S-NSSAI from the allowed NSSAIs for 5G-GUTI2. As long as the S-NSSAI is stored in the rejected NSSAIs for 5G-GUTI2, UE 3 can request the S-NSSAI during the registration process without using the registration type set to "Add," as long as the UE maintains its assigned RA (Registration Area). However, this will not affect the status of S-NSSAI associated with other 5G-GUTIs (e.g., 5G-GUTI1 assigned by VPLMN#1). If the AMF 7002 receives an indication from the NSACF 7702 that "the maximum number of UEs to register with the network slice has been reached," the AMF 7002 may send a registration rejection message that includes that reason.

[0219] For example, Figure 23 One or more of the processing steps can be applied to the first scenario in the second example of the second aspect. For example, after steps 1 to 5 in the first scenario of the second example of the second aspect, AMF 7001, NSACF in VPLMN#1, and NSACF 7703 can perform processing with... Figure 23 One or more of the same or similar processing (one or more of the same processing).

[0220] Variant 1 of the fifth scenario in the second example of the second aspect: In one example, the Service Level Agreement (SLA) quota for the maximum number of registered UEs per network slice can be controlled by the roaming partner of the home PLMN; that is, the maximum number of registered UEs per network slice is controlled by the VPLMN. Then, the global SLA quota of the home PLMN is distributed among the roaming partners of the HPLMN; that is, each VPLMN will have its own local quota for the maximum number of registered UEs per network slice, which is part of the globally agreed SLA quota of the HPLMN. In this case, Figure 23 Following step 2, the NSACF 7702 in VPLMN #2 can perform a local quota check and update for the maximum number of registered UEs per S-NSSAI (as described in step 4). Note that the method of sharing and allocating the global SLA quota for the maximum number of UEs registered to an S-NSSAI among roaming partners may result in UE rejection when the local quota is reached. To avoid UE registration failures when a UE registers to multiple PLMNs for the same S-NSSAI, the HPLMN can periodically readjust the local quotas shared with roaming VPLMN partners. Alternatively, when a UE registers to multiple PLMNs simultaneously, it may be allowed to exceed the maximum number of UEs registered to an S-NSSAI.

[0221] Variant 2 of the fifth scenario in the second example of the second aspect: In another example, Figure 23At step 3, the NSACF 7702 of VPLMN#2 can also include the PLMN identifier in the Nnsacf_NSAC_NumOfUEsUpdate message to the NSACF 7703 of HPLMN. In this case, the NSACF 7703 of HPLMN can allow two modes of UE registration with S-NSSAI counting (single counting in multiple PLMN registrations and multiple counting in multiple PLMN registrations), depending on the operator policy or the configuration in NSACF 7703. Alternatively, a new parameter (e.g., "counting mode" or any other notation indicating whether a UE registration with S-NSSAI is counted once or multiple times in each registration) can be added to the Nnsacf_NSAC_NumOfUEsUpdate message to NSACF 7703 to indicate the counting mode, i.e., single counting in multiple PLMN registration mode or multiple counting in multiple PLMN registration mode: - Single Count in Multiple PLMN Registrations - For single counts in multiple PLMN registrations, a UE registration with a specific S-NSSAI is counted once. When a UE registers with multiple PLMNs for the same S-NSSAI, the UE's registration to that S-NSSAI is counted once. For example, NSACF 7703 can check the Reg_Id parameter in the Nnsacf_NSAC_NumOfUEsUpdate message to see if UE 3's registration to the S-NSSAI is the first. If UE 3 has already registered with another PLMN, i.e., the Reg_Id parameter in the Nnsacf_NSAC_NumOfUEsUpdate message is higher than 1 (indicating that UE 3 has already registered with another PLMN), then UE 3's registration is not counted by NSACF 7703. Alternatively, to check the Reg_Id parameter in the Nnsacf_NSAC_NumOfUEsUpdate message, the NSACF 7703 can maintain a database containing UE registrations with roaming VPLMN partners, and the NSACF 7703 can check previous UE 3 registrations from this database. In this case, the NSACF 7703 maintains a database of UE 3 registrations (including those with partner VPLMNs) for each supported S-NSSAI, showing UE 3 registrations and deregistrations. - Multiple Counts in Multiple PLMN Registrations - For multiple counts in multiple PLMN registrations, a count is performed for each registration pair of UEs with a specific S-NSSAI. To avoid UE registration failures when a UE registers with multiple PLMNs for the same S-NSSAI, the maximum number of UEs allowed to register with multiple PLMNs simultaneously can exceed the maximum number of UEs registered with the S-NSSAI.

[0222] Variant 3 of the fifth scene in the second example of the second aspect: In another example, when network slicing requires EPS counting and the NSACF is configured with a 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 the network slice to ensure that it does not exceed the maximum configured number of registered UEs with network slices. In this case, Figure 23 In step 2, when UE 3 establishes the first PDU session / PDN connection associated with the network slice or when it releases the last PDU session / PDN connection associated with the network slice, the Nnsacf_NSAC_NumOfUEsUpdate message is triggered by SMF+PGW-C (instead of AMF7002). Then, the UE registration count follows one of the standardized options (Option 1 or Option 2) in Non-Patent Document 4.

[0223] Variant 4 of the fifth scenario in the second example of the second aspect: If UE 3 has three 5G-GUTIs (5G-GUTI1 for 3GPP access, 5G-GUTI2 for 3GPP access, and 5G-GUTI3 for non-3GPP access), and each 5G-GUTI can have a different configured NSSAI or can be associated with a different configured NSSAI, since the configured NSSAI depends on the UE location and the roaming VPLMN, then the NSSRGs associated with the configured NSSAIs can also be different. In this case, when UE 3 requests an S-NSSAI using any of the 5G-GUTIs (e.g., during the S-NSSAI registration process of UE 3), UE 3 considers all NSSRGs: one for 5G-GUTI1, another for 5G-GUTI2, and another for 5G-GUTI3, because the application in UE 3 is common to all 5G-GUTIs.

[0224] Variant 5 of the fifth scenario in the second example of the second aspect: In another example, for a single PLMN as specified in non-Patent Document 13, consider a local DN and a central DN with an edge computing-based 5G network architecture. In this case, UE 3 uses two AMFs to simultaneously connect to the local DN in the edge network via one 3GPP access network within the HPLMN, and to the central DN via the core network via another 3GPP access network. The AMFs can connect to the same SMF, or an I-SMF can be used to connect to the AMF in the edge network. In this scenario, consider a hierarchical NSACF architecture with a local NSACF in the edge network and a primary NSACF in the core network. For the number of UE registrations per network slice subject to NSAC, the AMF in the edge network triggers a per-network-slice UE availability check and update procedure to the local NSACF, and the AMF in the core network triggers the same procedure to the primary NSACF. The 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, the primary NSACF in the core network synchronizes with the local NSACF in the edge network and shares local maximum values ​​with the local NSACF to make decisions locally. The primary NSACF maintains the final number of UE registrations and immediately notifies the local NSACF if the defined global quota for the maximum number of UEs has been reached. If a UE registers using two 3GPP access networks, the UE ID is stored as dual 3GPP access along with the access type. If the shared local maximum value in the local NSACF has been reached, the local NSACF checks the global quota limit for registered UEs with the primary NSACF. The local maximum value can vary at different times as the primary NSACF synchronizes with the local NSACF periodically. Although synchronized with the local NSACF, the primary NSACF determines whether to count the same UE once or twice for dual access registrations based on the network operator's policy.

[0225] Variant 6 of the fifth scenario in the second example of the second aspect: In scenarios where EPS and 5GS are interoperable, for network slices with the attribute of having at least one PDU session or PDN connection and subject to NSAC, the AMF, SMF, or SMF+PGW-C triggers a per-network-slice UE count availability check and update procedure to the NSACF instead of the AMF, SMF, or SMF+PGW-C. In some scenarios, a single NSACF can be used for both UE counting and PDU session counting. In this case, the AMF can be configured not to trigger a UE counting procedure to the NSACF, and the SMF or SMF+PGW-C only triggers a PDU session counting procedure to the NSACF; however, the NSACF is internally configured to check both UE counting and PDU session counting when it receives a request for PDU session counting from the SMF. If two separate NSACFs are used for UE counting and PDU session counting, the SMF or SMF+PGW-C accordingly triggers both a UE counting procedure via the message Nnsacf_NSAC_NumOfUEsUpdate_Request and a PDU session counting procedure via the message Nnsacf_NSAC_NumOfPDUsUpdate_Request to the NSACF. When triggering UE count and PDU session count, SMF or SMF+PGW-C can also share the access type as dual access or dual 3GPP access or 3GPP access 1 and 3GPP access 2.

[0226] The first scenario in the third example of the second aspect: Figure 24 Examples of deregistration processes are shown for both the case of a single PLMN and the case of crossing to multiple PLMNs.

[0227] The following is for reference. Figure 24 The detailed processing of the first scenario in the third example of the second aspect is described.

[0228] Step 0-1. UE 3 has been registered to AMF 7001 in VPLMN#1, and 5G-GUTI1 has been assigned to Reg Id set to 1. (This is in contrast to the previous step.) Figure 21 In the same manner as step 0, for example, UE 3 can send a registration request message including a Reg Id set to 1, and 5G-GUTI1 can be assigned to UE 3.

[0229] Step 0-2. UE 3 has been registered to AMF 7002 in VPLMN#2, and 5G-GUTI2 has been assigned to Reg Id set to 2. Figure 21 In the same manner as step 0, for example, UE 3 can send a registration request message including a Reg Id set to 2, and 5G-GUTI2 can be assigned to UE 3.

[0230] Step 1. UE 3 decides to deregister only 5G-GUTI1. For example, UE 3 changes its configuration to perform deregistration. For example, UE 3 can perform a deregistration process to deregister from the registered VPLMN#1. For example, UE 3 can use a deregistration process to deregister from the registered VPLMN#1.

[0231] Step 2. UE 3 sends a deregistration request message to AMF 7001. This deregistration request message includes at least one of the following: User ID set to 5G-GUTI1, Deregistration type set to single deregistration, and Reg Id set to 1. For parameter details, refer to step 4 in the second scenario of the second example of the second aspect. Additionally, the Deregistration type set to single deregistration indicates that this is a deregistration request only for the specified User ID (e.g., 5G-GUTI1). For example, the deregistration request message is sent to AMF 7001 triggered by a configuration change of UE 3. For example, UE 3 can send a deregistration request message for a DSMA PDU session. For example, UE 3 can perform the deregistration process for a DSMA PDU session by sending a deregistration request message.

[0232] Step 3. Upon receiving the deregistration request message in Step 2, AMF 7001 sends an Nsmf_PDUSession_ReleaseSMContext message to SMF 7102 in the HPLMN. This Nsmf_PDUSession_ReleaseSMContext message includes at least one of the following: SM context ID and release type set to single connection release. The SM context ID identifies the SM context in SMF 7102. The release type set to single connection release indicates to SMF 7102 that this is a request to release a single connection of the DSMA PDU session. That is, if SMF 7102 has another single connection configured for the DSMA PDU session, the DSMA PDU session is retained. Otherwise, this message triggers the release of the DSMA PDU session. If the DSMA PDU session has not yet been established, step 3 can be skipped.

[0233] Note that an SMF exists in VPLMN#2 because this is a DSMA PDU session scenario for home routes. The Nsmf_PDUSession_ReleaseSMContext message is sent to the SMF in VPLMN#2 and forwarded to SMF7102. For example, the AMF 7001 can send the Nsmf_PDUSession_ReleaseSMContext message for a DSMA PDU session. For example, the AMF 7001 can perform a deregistration process for a DSMA PDU session by sending the Nsmf_PDUSession_ReleaseSMContext message. For example, the AMF 7001 can perform a deregistration process for VPLMN#1 by sending the Nsmf_PDUSession_ReleaseSMContext message.

[0234] Step 4. Upon receiving the Nsmf_PDUSession_ReleaseSMContext message from AMF 7001, SMF 7102 contacts UPF 7202 in the HPLMN to update the DSATSSS rules in UPF 7202 by releasing a single connection from the DSMA PDU session. The DSATSSS rules will be explained in detail later in the first scenario of the seventh example in the second aspect. For example, the SMF 7102 or UPF 7202 can release a single connection from a DSMA PDU session. For example, UPF 7202 can update DSATSSS rules so that connections released from DSMA PDU sessions are not considered in the DSATSSS service. For example, UPF 7202 can update DSATSSS rules so that traffic is not redirected to, switched to, or split to connections released from DSMA PDU sessions. For example, UPF 7202 can update DSATSSS rules to prevent connection communication traffic from being released from the DSMA PDU session. For example, UPF 7202 can inform SMF 7102 of a successful DSATSSS rule update in UPF 7202.

[0235] Step 5. After SMF 7102 confirms the successful DSATSSS rule update in UPF 7202, SMF 7102 sends an Nsmf_PDUSession_ReleaseSMContext response message to AMF 7001. For example, the SMF 7102 can perform the deregistration process for a DSMA PDU session by performing at least one of steps 4 and 5.

[0236] Step 6. AMF 7001 sends a Nudm_UECM_Deregistration request message to UDM 75. This Nudm_UECM_Deregistration request message includes at least one of the following: UE User ID set to SUPI (e.g., SUPI for UE 3), deregistration type set to single deregistration, and Reg Id set to 1. For parameter details, refer to Step 2. For example, AMF 7001 may obtain or store UE 3's SUPI in advance.

[0237] Step 7. Upon receiving the Nudm_UECM_Deregistration request message from AMF 7001, UDM 75 removes AMF 7001 as a registered AMF linked to a Reg Id set to 1. For example, UDM 75 may store information about which AMF is linked to or associated with a Reg Id. If UDM 75 persists, this removal of a registered AMF will not affect other AMF entries. UDM 75 sends a Nudm_UECM_Deregistration response message to AMF 7001.

[0238] Step 8. AMF 7001 sends a deregistration acceptance message to UE 3. When UE 3 receives the deregistration acceptance message, UE 3 updates the DSATSSS rules in UE 3. For example, UE 3 can update the DSATSSS rules so that connections released from DSMA PDU sessions are not considered in the DSATSSS service. For example, UE 3 can update DSATSSS rules so that traffic is not redirected to, switched to, or split to connections released from DSMAPDU sessions. For example, UE 3 can update DSATSSS rules to prevent connection communication traffic from being released from the DSMA PDU session.

[0239] For example, UE 3 can use the deregistration procedure to deregister from at least one of the registered PLMNs. For example, UE 3 can use the deregistration procedure to deregister from registered VPLMN #2. For example, UE 3 can use the deregistration procedure to deregister from either registered VPLMN #1 or registered VPLMN #2.

[0240] Variation 1 of the first scenario in the third example of the second aspect: After step 7, if there is any association between UE 3 and PCF 7301, and UE 3 is not registered with AMF 7001 for non-3GPP access, then AMF 7001 and PCF 7301 will perform an AM policy association termination process initiated by AMF.

[0241] Variation 2 of the first scenario in the third example of the second aspect: If UE 3 is in CM idle mode on a 3GPP access via VPLMN#1 and UE 3 is in CM connected mode on another 3GPP access via VPLMN#2, then UE 3 can initiate a deregistration process on the 3GPP access via VPLMN#2 through AMF 7002.

[0242] The second scenario in the third example of the second aspect: Figure 25 Examples of deregistration processes are shown for both the case of a single PLMN and the case of crossing to multiple PLMNs.

[0243] The following is for reference. Figure 25 The detailed processing of the second scenario in the third example of the second aspect is described.

[0244] Step 0-1. UE 3 has been registered to AMF 7001 in VPLMN#1, and 5G-GUTI1 has been assigned to the Reg Id set to 1. This step can be combined with... Figure 24 The steps 0-1 are the same.

[0245] Step 0-2. UE 3 has been registered to AMF 7002 in VPLMN#2, and 5G-GUTI2 has been assigned to Reg Id set to 2. This step can be combined with... Figure 24 Steps 0-2 are the same.

[0246] Step 1. UE 3 decides to deregister all 5G-GUTIs. For example, UE 3 decides to power off. For example, UE 3 is powered off. For example, if a user of UE 3 wants to deregister all 5G-GUTIs (e.g., if a user of UE 3 wants to deregister from VPLMN#1 and VPLMN#2 (the user can perform this deregistration via the UE 3 GUI)), UE 3 can decide to deregister all 5G-GUTIs. For example, UE 3 changes its configuration to perform the deregistration.

[0247] Step 2. UE 3 sends a deregistration request message to AMF 7001. This deregistration request message includes at least one of the following: User ID set to 5G-GUTI1, Deregistration type set to "Deregister All", and Reg Id set to 1. For parameter details, refer to step 4 in the second scenario of the second example of the second aspect. Additionally, the Deregistration type set to "Deregister All" indicates that this is a request to deregister all associated 5G-GUTIs (in this case, both 5G-GUTI1 and 5G-GUTI2 (or both VPLMN#1 and VPLMN#2)). For example, a deregistration request message is sent to AMF 7001 triggered by a configuration change in UE 3. For example, UE 3 can send a deregistration request message for a DSMA PDU session. For example, UE 3 can perform the deregistration process for a DSMA PDU session by sending a deregistration request message.

[0248] Step 3. Upon receiving the deregistration request message in Step 2, AMF 7001 sends an Nsmf_PDUSession_ReleaseSMContext message to SMF 7102 in the HPLMN. This Nsmf_PDUSession_ReleaseSMContext message includes at least one of the following: SM context ID and release type set to "Release All". The SM context ID identifies the SM context in SMF 7102. The release type set to "Release All" indicates to SMF 7102 that this is a request to release all single connections of the DSMA PDU session; that is, a release type set to "Release All" can indicate that the DSMA PDU session is being released.

[0249] Note that an SMF exists in VPLMN#2 because this is a DSMA PDU session scenario for home routes. The Nsmf_PDUSession_ReleaseSMContext message is sent to the SMF in VPLMN#2 and forwarded to SMF7102.

[0250] For example, the AMF 7001 can send the Nsmf_PDUSession_ReleaseSMContext message for a DSMA PDU session. For example, the AMF 7001 can perform a deregistration process for a DSMA PDU session by sending the Nsmf_PDUSession_ReleaseSMContext message. For example, the AMF 7001 can perform a deregistration process for VPLMN#1 and VPLMN#2 by sending the Nsmf_PDUSession_ReleaseSMContext message.

[0251] Step 4. Upon receiving the Nsmf_PDUSession_ReleaseSMContext message from AMF 7001, SMF7102 contacts UPF 7202 to release the DSMA PDU session. For example, the SMF 7102 or UPF 7202 can release a DSMA PDU session. For example, UPF 7202 can update DSATSSS rules so that released DSMAPDU sessions are not considered in the DSATSSS service. For example, UPF 7202 can update DSATSSS rules so that traffic is not redirected to, switched to, or split into DSMA PDU sessions. For example, UPF 7202 can update DSATSSS rules to allow traffic to communicate without going through the DSMA PDU session. For example, UPF 7202 can inform SMF 7102 of a successful DSATSSS rule update in UPF 7202.

[0252] Step 5. SMF 7102 sends an Nsmf_PDUSession_ReleaseSMContext response message to AMF 7001. For example, after SMF 7102 confirms the successful DSATSSS rule update in UPF 7202, SMF 7102 sends an Nsmf_PDUSession_ReleaseSMContext response message to AMF 7001.

[0253] Step 6. AMF 7001 sends a Nudm_UECM_Deregistration request message to UDM 75. This Nudm_UECM_Deregistration request message includes at least one of the following: UE User ID set to SUPI (e.g., SUPI for UE 3), all deregistration types set to deregister, and Reg Id set to 1. For parameter details, refer to Step 2. For example, AMF 7001 may obtain or store UE 3's SUPI in advance.

[0254] Step 7. Upon receiving the Nudm_UECM_Deregistration request message from AMF 7001, UDM 75 removes all registered AMFs. UDM 75 sends a Nudm_UECM_Deregistration response message to AMF 7001.

[0255] Step 8. UDM 75 sends a Nudm_UECM_DeregistrationNotification message to AMF 7002. This Nudm_UECM_DeregistrationNotification message includes at least one of the following: the user ID set to SUPI, the removal reason set to "Unregister All", and the Reg ID set to 2. For parameter details, refer to Step 2. AMF 7002 is selected by UDM 75 based on the registered AMFs for UE3 with a Reg ID set to 2 in UDM 75's storage.

[0256] Step 9. Upon receiving the Nudm_UECM_DeregistrationNotification message from UDM 75, AMF7002 removes the UE context of UE 3. AMF 7002 sends a Nudm_UECM_DeregistrationNotification response message to UDM 75.

[0257] Step 10. AMF 7001 sends a deregistration acceptance message to UE 3. When UE 3 receives the deregistration acceptance message, UE 3 removes the DSATSSS rule from UE 3. For example, UE 3 can update the DSATSSS rules so that released DSMA PDU sessions are not considered in the DSATSSS service. For example, UE 3 can update DSATSSS rules so that traffic is not redirected to, switched to, or split into DSMAPDU sessions. For example, UE 3 can update the DSATSSS rules to prevent traffic from being transmitted through the DSMA PDU session.

[0258] For example, UE 3 can use the deregistration procedure to deregister from at least one of the registered PLMNs. For example, UE 3 can use the deregistration procedure to deregister from both registered VPLMN #1 and registered VPLMN #2.

[0259] Variation 1 of the second scenario in the third example of the second aspect: After step 7, if there is any association between UE 3 and PCF 7301, and UE 3 is not registered with AMF 7001 for non-3GPP access, then AMF 7001 and PCF 7301 will perform an AM policy association termination process initiated by AMF.

[0260] Variation 2 of the second scenario in the third example of the second aspect: After step 9, if there is any association between UE 3 and PCF and UE 3 is not registered with AMF7002 for non-3GPP access, then AMF7002 and PCF will perform the AM policy association termination process initiated by AMF.

[0261] Variation 3 of the second scenario in the third example of the second aspect: If UE 3 is in CM idle mode on a 3GPP access via VPLMN#1 and UE 3 is in CM connected mode on another 3GPP access via VPLMN#2, then UE 3 can initiate a deregistration process on the 3GPP access via VPLMN#2 through AMF 7002.

[0262] The third scenario in the third example of the second aspect: Figure 26 Examples of deregistration processes are shown for both the case of a single PLMN and the case of crossing to multiple PLMNs.

[0263] The following is for reference. Figure 26 The detailed processing of the third scenario in the third example of the second aspect is described.

[0264] Step 0-1. UE 3 has been registered to AMF 7001 in VPLMN#1, and 5G-GUTI1 has been assigned to the Reg Id set to 1. This step can be combined with... Figure 24 The steps 0-1 are the same.

[0265] Step 0-2. UE 3 has been registered to AMF 7002 in VPLMN#2, and 5G-GUTI2 has been assigned to Reg Id set to 2. This step can be combined with... Figure 24 Steps 0-2 are the same.

[0266] Step 1. UDM 75 decides to deregister only the Reg Id associated with 5G-GUTI1 that is set to 1. For example, UDM 75 may decide to deregister if dual boot capability is removed from subscriber data in UDM 75. For example, UDM 75 may change its configuration to perform deregistration.

[0267] Step 2. UDM 75 sends a Nudm_UECM_DeregistrationNotification message to AMF 7001. This Nudm_UECM_DeregistrationNotification message includes at least one of the following: the user ID set to SUPI (e.g., SUPI for UE 3), the removal reason set to a single deregistration, and the Reg Id set to 1. For parameter details, refer to step 2 in the first scenario of the third example of the second aspect. For example, the Nudm_UECM_DeregistrationNotification message is sent to AMF 7001 triggered by a configuration change of UDM 75. For example, UDM 75 can send a Nudm_UECM_DeregistrationNotification message for a DSMA PDU session. For instance, UDM 75 can perform a deregistration process for a DSMA PDU session by sending the Nudm_UECM_DeregistrationNotification message.

[0268] Step 2a. In the case of explicit deregistration, AMF 7001 can send a deregistration request message to UE 3.

[0269] Step 2b. If UE 3 receives the message in step 2a, UE 3 may send a deregistration acceptance message. This step may also be performed at a later time after step 6.

[0270] Step 3. Upon receiving the Nudm_UECM_DeregistrationNotification message from UDM 75, AMF7001 removes the UE context of UE 3. AMF 7001 sends a Nudm_UECM_DeregistrationNotification response message to UDM 75.

[0271] Step 4. Steps 3 to 5 in the first scenario of the third example of the second aspect can occur.

[0272] Variant 1 of the third scenario in the third example of the second aspect: In the case of explicit deregistration, if UE 3 is in CM idle mode on a 3GPP access via VPLMN#1 and UE 3 is in CM connected mode on another 3GPP access via VPLMN#2, the network can initiate the deregistration process on the 3GPP access via AMF 7002 via VPLMN#2, or AMF 7001 can send a paging message to UE 3.

[0273] The fourth scenario in the third example of the second aspect: Figure 27 Examples of deregistration processes are shown for both the case of a single PLMN and the case of crossing to multiple PLMNs.

[0274] The following is for reference. Figure 27 The detailed processing of the fourth scenario in the third example of the second aspect is described.

[0275] Step 0-1. UE 3 has been registered to AMF 7001 in VPLMN#1, and 5G-GUTI1 has been assigned to the Reg Id set to 1. This step can be combined with... Figure 24 The steps 0-1 are the same.

[0276] Step 0-2. UE 3 has been registered to AMF 7002 in VPLMN#2, and 5G-GUTI2 has been assigned to Reg Id set to 2. This step can be combined with... Figure 24 Steps 0-2 are the same.

[0277] Step 1. UDM 75 decides to cancel the registration. For example, UDM 75 may decide to cancel the registration in the event of subscriber cancellation due to non-payment (e.g., non-payment of fees for DSATSSS services). For example, UDM 75 may change its configuration to enable registration cancellation.

[0278] Step 2. UDM 75 sends a Nudm_UECM_DeregistrationNotification message to AMF 7001. This Nudm_UECM_DeregistrationNotification message includes at least one of the following: the user ID set to SUPI (e.g., SUPI for UE 3), the removal reason set to deregister all removal reasons, and the Reg Id set to 1. For parameter details, refer to step 2 in the second scenario of the third example of the second aspect. For example, the Nudm_UECM_DeregistrationNotification message is sent to AMF 7001 triggered by a configuration change of UDM 75. For example, UDM 75 can send a Nudm_UECM_DeregistrationNotification message for a DSMA PDU session. For instance, UDM 75 can perform a deregistration process for a DSMA PDU session by sending the Nudm_UECM_DeregistrationNotification message. For example, AMF 7001 can send a deregistration request message to UE 3. For example, UE 3 can send a deregistration acceptance message to AMF 7001.

[0279] Step 2a. In the case of explicit deregistration, AMF 7001 can send a deregistration request message to UE 3.

[0280] Step 2b. If UE 3 receives the message in step 2a, UE 3 may send a deregistration acceptance message. This step may also be performed at a later time after step 6.

[0281] Step 3. Upon receiving the Nudm_UECM_DeregistrationNotification message from UDM 75, AMF7001 removes the UE context of UE 3. AMF 7001 sends a Nudm_UECM_DeregistrationNotification response message to UDM 75.

[0282] Step 4. Steps 3 to 5 in the second scenario of the third example of the second aspect can occur.

[0283] Step 5. UDM 75 sends a Nudm_UECM_DeregistrationNotification message to AMF 7002. This Nudm_UECM_DeregistrationNotification message includes at least one of the following: the user ID set to SUPI (e.g., SUPI for UE 3), the Reg ID set to all removal reasons for deregistration and set to 1, and the No SM procedure. For parameter details, refer to step 2 in the second scenario of the third example of the second aspect. Additionally, the No SM procedure indicates to AMF 7002 that the associated PDU session release (including the associated DSMA PDU session release) procedure is not required. As an example, UDM 75 may not include the no-SM disposal parameter. In this case, AMF 7002 performs steps 3 to 5 in the second scenario of the third example of the second aspect.

[0284] Step 6. Upon receiving the Nudm_UECM_DeregistrationNotification message from UDM 75, AMF7002 removes the UE context of UE 3. AMF 7002 sends a Nudm_UECM_DeregistrationNotification response message to UDM 75.

[0285] Variation 1 of the fourth scenario in the third example of the second aspect: In the case of explicit deregistration, if UE 3 is in CM idle mode on a 3GPP access via VPLMN#1 and UE 3 is in CM connected mode on another 3GPP access via VPLMN#2, the network can initiate the deregistration process on the 3GPP access via AMF 7002 via VPLMN#2, or AMF 7001 can send a paging message to UE 3.

[0286] The first scenario in the fourth example of the second aspect: Figure 28 Examples of UE configuration update processes are illustrated for both the case of a single PLMN and the case of spanning multiple PLMNs.

[0287] The following is for reference. Figure 28 The detailed processing of the first scenario in the fourth example of the second aspect is described.

[0288] Step 0-1. UE 3 has been registered to AMF 7001 in VPLMN#1, and 5G-GUTI1 has been assigned to the Reg Id set to 1. This step can be combined with... Figure 24 The steps 0-1 are the same.

[0289] Step 0-2. UE 3 has been registered to AMF 7002 in VPLMN#2, and 5G-GUTI2 has been assigned to Reg Id set to 2. This step can be combined with... Figure 24 Steps 0-2 are the same.

[0290] Step 1. UDM 75 updates UE 3 subscriber data.

[0291] Step 2. At this point, there are two AMFs (AMF 7001 and AMF 7002) registered with UDM 75. UDM 75 selects AMF 7001 to perform the UE configuration update procedure (UCU procedure). For example, if there are two registrations, UDM selects AMF to perform the UCU procedure for the UE. For example, UDM 75 can select the AMF based on the operator's policy. For example, UDM 75 can randomly select AMF.

[0292] Step 3. UDM 75 sends a Nudm_SDM_Notification message to AMF 7002, including subscriber data and at least one of the required UCUs. The subscriber data is the updated subscriber data for UE 3. The required UCU indicates that a UE configuration update process is not required because another associated AMF is performing the UE configuration update process.

[0293] Step 4. Upon receiving the Nudm_SDM_Notification message from UDM 75, AMF 7002 updates the UE context of UE 3 in its storage and sends a Nudm_SDM_Notification response message to UDM 75. If AMF 7002 receives a message indicating that UCU is not required, AMF 7002 does not perform a UE configuration update process with UE 3.

[0294] Step 5. UDM 75 sends a Nudm_SDM_Notification message to AMF 7001, including subscriber data and an update of at least one of the 5G-GUTIs. Updating all 5G-GUTIs is an indication that the subscriber data needs to apply all associated 5G-GUTIs in UE 3. Updating all 5G-GUTIs can also indicate that all 5G-GUTIs need to be updated. Updating all 5G-GUTIs can indicate that a UE configuration update procedure needs to occur. Updating all 5G-GUTIs can indicate that a UE configuration update procedure needs to be performed. Updating all 5G-GUTIs can indicate that a UE configuration update procedure needs to be performed based on the subscriber data included in the Nudm_SDM_Notification message. Updating all 5G-GUTIs can indicate that an update of (one or more) UE context needs to be performed. Updating all 5G-GUTIs can indicate that an update of (one or more) UE context needs to be performed based on the subscriber data included in the Nudm_SDM_Notification message.

[0295] Step 6. Upon receiving the Nudm_SDM_Notification message from UDM 75, AMF 7001 updates the UE context of UE 3 in its storage and sends a UE configuration update command message to UE 3, including subscriber data and updating at least one of all 5G-GUTIs. The subscriber data is the subscriber data received in the Nudm_SDM_Notification message in step 5. For example, AMF 7001 may update one or more UE contexts of UE 3 stored in AMF 7001 based on the received subscriber data.

[0296] Step 7. Upon receiving a UE configuration update command message from AMF 7001, which includes subscriber data and updates at least one of all 5G-GUTIs, UE 3 updates the UE context in UE 3's storage for all associated 5G-GUTIs (i.e., 5G-GUTI1 and 5G-GUTI2) and sends a UE configuration update complete message to AMF 7001. For example, UE 3 may update one or more UE contexts of UE 3 stored in UE 3 based on the received subscriber data. For example, UE 3 may update one or more UE contexts of UE 3 stored in UE 3 and associated with all 5G-GUTIs (e.g., 5G-GUTI1 and 5G-GUTI2) based on the received subscriber data.

[0297] Step 8. Upon receiving the UE configuration update complete message from UE 3, AMF 7001 updates the UE context of UE 3 in AMF 7001's storage and sends a Nudm_SDM_Notification response message to UDM 75.

[0298] Step 9. Upon receiving the Nudm_SDM_Notification response message from AMF 7001, UDM 75 sends a Nudm_SDM_Notification message including UCU completion to AMF 7002. UCU completion indicates to AMF 7002 that the updated subscriber data has been properly installed in UE 3. That is, the updated subscriber data is ready for use by AMF 7002. For example, UCU completion could indicate that the updated subscriber data is ready for use by AMF 7002. For example, UCU completion could indicate that the UE configuration update process is complete. For example, UCU completion could indicate that the UE configuration update process has successfully completed.

[0299] For example, in step 2, UDM 75 may select AMF 7002. In this case, AMF 7002 and the processes associated with or performed by AMF 7002 (one or more) described above may be replaced by AMF 7001 and the processes associated with or performed by AMF 7001 (one or more), respectively, and AMF 7001 and the processes associated with or performed by AMF 7001 (one or more) described above may be replaced by AMF 7002 and the processes associated with or performed by AMF 7002 (one or more).

[0300] Variation 1 of the first scenario in the fourth example of the second aspect: In step 3, UDM 75 may omit the unnecessary UCU from the Nudm_SDM_Notification message sent to AMF 7002. For example, AMF 7001 and AMF 7002 may each send a UE configuration update command message to UE 3, including updated subscriber data. In this case, UE 3 receives UE configuration update command messages, one from AMF 7001 and the other from AMF 7002. UE 3 updates the UE context of 5G-GUTI1 based on the subscriber data received from AMF 7001. UE 3 updates the UE context of 5G-GUTI2 based on the subscriber data received from AMF 7002. In this case, in step 9, UDM 75 does not send a Nudm_SDM_Notification message to AMF 7002.

[0301] The first scenario in the fifth example of the second aspect: Figure 29 Examples of UE policy update processes are illustrated for both the case of a single PLMN and the case of spanning multiple PLMNs.

[0302] The following is for reference. Figure 29 The detailed processing of the first scenario in the fifth example of the second aspect is described.

[0303] Step 0-1. UE 3 has been registered to AMF 7001 in VPLMN#1, and 5G-GUTI1 has been assigned to the Reg Id set to 1. This step can be combined with... Figure 24 The steps 0-1 are the same.

[0304] Step 0-2. UE 3 has been registered to AMF 7002 in VPLMN#2, and 5G-GUTI2 has been assigned to Reg Id set to 2. This step can be combined with... Figure 24 Steps 0-2 are the same.

[0305] Step 1. Update the UE policy of UE 3 using PCF 7303.

[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 PCF 7303 in HPLMN. PCF 7303 selects PCF 7301 to perform the UE policy update process.

[0307] Note that if PCF 7301 and PCF 7302 are located in different PLMNs, it is unlikely that PCF 7303 will select only one PCF for the UE policy update process, because the UE policy of UE 3 can reflect the local UE policy in the VPLMN.

[0308] Note that this step may occur if UE 3 is in its home PLMN (i.e., HPLMMN) and two 5G-GUTIs are assigned to UE 3 for DSATSSS service. In this case, PCF 7301 and PCF 7302 from Figure 29 The steps 3, 4, 5, and 10 are eliminated. As a result, steps 6, 7, 8, and 9 are performed under the assumption that PCF 7301 is considered to be PCF 7303 of a common PCF for two 5G-GUTIs (5G-GUTI1 and 5G-GUTI2) located in HPLMN.

[0309] Step 3. PCF 7303 sends an Npcf_AMPolicyControl_UpdateNotify message to PCF 7302. This Npcf_AMPolicyControl_UpdateNotify message includes at least one of the following: UE policy and "UE policy delivery not required". The UE policy is the updated UE policy for UE 3. "UE policy delivery not required" indicates that a UE policy update process is not required because another associated PCF is performing the UE policy process. "UE policy delivery not required" can indicate that a UE policy update process is not required. "UE policy delivery not required" can indicate that either UE policy delivery or UE policy update is not required.

[0310] Step 4. Upon receiving the Npcf_AMPolicyControl_UpdateNotify message from PCF 7303, PCF 7302 updates the UE policy of UE 3 in its storage and sends an Npcf_AMPolicyControl_UpdateNotify response message to PCF 7303. Since PCF 7302 receives a message indicating that UE policy delivery is not required, PCF 7302 does not perform a UE policy update process with UE 3.

[0311] Step 5. UDM 75 sends an Npcf_AMPolicyControl_UpdateNotify message to PCF 7301. This Npcf_AMPolicyControl_UpdateNotify message includes the UE policy and at least one of updating all 5G-GUTIs. The UE policy is the updated UE policy for UE 3. Updating all 5G-GUTIs is an indication that the updated UE policy needs to apply any associated 5G-GUTIs in UE 3. Updating all 5G-GUTIs may indicate that a UE policy update process is required. Updating all 5G-GUTIs may indicate that a UE policy update process is required. Updating all 5G-GUTIs may indicate that the delivery of the UE policy or the update of the UE policy is required. Updating all 5G-GUTIs may indicate that the delivery of the UE policy included in this message is required, or that the update of the UE policy based on the UE policy in this message is required.

[0312] Step 6. Upon receiving the Npcf_AMPolicyControl_UpdateNotify message from PCF 7303, PCF 7301 updates the UE policy of UE 3 in its storage and sends a Namf_Communication_N1N2MessageTransfer message to AMF 7001, including the UE policy and at least one of the updated 5G-GUTIs. The UE policy is the updated UE policy reflecting the local UE policy in VPLMN#1. Updating all 5G-GUTIs is an indication that the updated UE policy needs to apply any associated 5G-GUTIs in UE 3. Updating all 5G-GUTIs can be the same as the update all 5G-GUTI in Step 5. For example, PCF 7301 can update the UE policy of UE 3 stored in PCF 7301 based on the received UE policy.

[0313] Step 7. Upon receiving the Namf_Communication_N1N2MessageTransfer message from PCF 7301, AMF 7001 sends a management UE policy command message to UE 3, which includes the UE policy and updates at least one of the 5G-GUTIs.

[0314] Step 8. Upon receiving a management UE policy command message from AMF 7001, which includes the UE policy and an update command message for at least one of the 5G-GUTIs, UE 3 updates the UE policy in its storage for all associated 5G-GUTIs (i.e., 5G-GUTI1 and 5G-GUTI2) and sends a management UE policy completion message to AMF 7001. For example, UE 3 may update the UE policy stored in UE 3 based on the received UE policy. For example, UE 3 may update the UE policy stored in UE 3 and associated with all 5G-GUTIs (e.g., 5G-GUTI1 and 5G-GUTI2) based on the received UE policy.

[0315] Step 9. Upon receiving the UE policy completion message from UE 3, AMF 7001 sends a Namf_Communication_N1N2MessageTransfer response message to PCF 7301.

[0316] Step 10. Upon receiving the Namf_Communication_N1N2MessageTransfer response message from AMF 7001, PCF 7301 sends the Npcf_AMPolicyControl_UpdateNotify response message to PCF 7303.

[0317] Step 11. Upon receiving the Npcf_AMPolicyControl_UpdateNotify response message from PCF 7301, PCF 7303 sends an Npcf_AMPolicyControl_UpdateNotify message to PCF 7302 indicating that UE policy delivery is complete. UE policy delivery completion indicates to PCF 7302 that the updated UE policy has been properly installed in UE3. That is, the updated UE policy is ready for use by PCF 7302. UE policy delivery completion can indicate that the updated UE policy is ready for use by PCF 7302. For example, UE policy delivery completion can indicate that the UE policy update process is complete. For example, UE policy delivery completion can indicate that the UE policy update process has been successfully completed. For example, UE policy delivery completion can indicate either the completion of UE policy delivery or the completion of UE policy update. For example, UE policy delivery completion can indicate either the successful completion of UE policy delivery or the successful completion of UE policy update.

[0318] For example, in step 2, PCF 7303 can be selected as PCF 7302. In this case, PCF 7302 and the processes associated with or performed by PCF 7302 (one or more) described above can be replaced by PCF 7301 and the processes associated with or performed by PCF 7301 (one or more), respectively, and PCF 7301 and the processes associated with or performed by PCF 7301 (one or more) described above can be replaced by PCF 7302 and the processes associated with or performed by PCF 7302 (one or more).

[0319] Variant 1 of the first scene in the fifth example of the second aspect: In step 3, PCF 7302 may omit the "UE policy delivery not required" message from its Npcf_AMPolicyControl_UpdateNotify message. For example, AMF 7001 and AMF 7002 may each send a management UE policy command message to UE 3, including the updated UE policy. In this case, UE 3 receives management UE policy command messages, one from AMF 7001 and the other from AMF 7002. UE 3 updates the UE policy for 5G-GUTI1 based on the UE policy received from AMF 7001. UE 3 updates the UE policy for 5G-GUTI2 based on the UE policy received from AMF 7002. In this case, UDM 75 does not send a message to PCF 7302 in step 11. For example, "UE policy delivery not required" indicates that a UE policy update process is not required because another associated PCF is performing the UE policy process. "UE policy delivery not required" can indicate that a UE policy update process is not required.

[0320] The first scenario in the sixth example of the second aspect: Figure 30 Examples of 5G authentication and key negotiation (AKA) authentication processes are illustrated for both single PLMN scenarios and scenarios spanning multiple PLMNs.

[0321] The following is for reference. Figure 30 The detailed processing of the first scenario in the sixth example of the second aspect is described.

[0322] Step 1. UE 3 sends an N1 message to AMF 7001, which includes at least one of the following: User ID, Dual Reg Support, and Reg Id set to 1. For parameter details, refer to Step 1 in the first scenario of the second example of the second aspect.

[0323] Step 2. AMF 7001 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 78 in HPLMN. This Nausf_UEAuthentication_Authenticate request message includes at least one of the following: user ID, dual Reg support, and Reg Id set to 1. For parameter details, refer to step 1 in the first scenario of the second example in the second aspect.

[0324] Step 3. Upon receiving the Nausf_UEAuthentication_Authenticate request message from AMF 7001, AMF 78 sends a Nudm_UEAuthentication_Get request message to UDM 75. This Nudm_UEAuthentication_Get request message includes at least one of the following: user ID, dual Reg support, and Reg Id set to 1. For parameter details, refer to step 1 in the first scenario of the second example of the second aspect.

[0325] Step 4. Upon receiving the Nudm_UEAuthentication_Get request message from AUSF 78 in Step 3, UDM 75 generates a 5G HE AV for UE 3. The 5G HE AV is the home environment authentication vector for UE 3.

[0326] Step 5. UDM 75 sends a Nudm_UEAuthentication_Get response message to AUSF 78. This Nudm_UEAuthentication_Get response message includes at least one of 5G HE AV, dual Reg support, and a Reg Id set to 1. For parameter details, refer to step 1 in the first scenario of the second example of the second aspect.

[0327] Step 6. AUSF 78 generates a 5G SE AV based on the 5G HE AV received from UDM 75 in the Nudm_UEAuthentication_Get response message. The 5G SE AV is the service environment authentication vector of UE 3.

[0328] Step 7. After AUSF 78 generates the 5G SE AV, AUSF 78 sends a Nausf_UEAuthentication_Authenticate response message, which includes at least one of 5G SEAV, dual Reg support, and a Reg Id set to 1. For parameter details, refer to step 1 in the first scenario of the second example of the second aspect.

[0329] Step 8. Upon receiving the Nausf_UEAuthentication_Authenticate response message from AMF 78, AMF 7001 sends an authentication request message to UE 3. This authentication request message includes at least one of RAND, AUTN, ngKSI, ABBA, dual Reg support, and a Reg Id set to 1. For parameter details, refer to step 1 in the first scenario of the second example in the second aspect. Furthermore, the following points explain each parameter in detail. - RAND is a random number used as part of the 5G authentication vector. - AUTN is an authentication token that is part of the 5G authentication vector. - ngKSI is a key set identifier in 5G. ngKSI is used by the UE and AMF to identify portions of the native security context. - ABBA is a parameter used to provide downgrade protection against security features introduced in a higher version being downgraded to security features in a lower version, and to indicate the security features that are possible in the current network.

[0330] Step 9. Perform step 7 and the following steps as described in section 6.1.3.2.0 of Non-Patent Document 9. Following a successful authentication process for 5G AKA, UE 3 manages the generated NAS security context by linking to the Reg Id (the Reg Id set to 1) and the associated 5G-GUTI (5G-GUTI1).

[0331] Variation 1 of the first scenario in the sixth example of the second aspect: When using the authentication process for EAP-AKA' for authentication, the following replacements are required. - In step 5, the Nudm_UEAuthentication_Get response message to AUSF 78 does not include 5G HEAV. Step 6 is omitted. - In step 7, the Nausf_UEAuthentication_Authenticate response message to AMF 7001 does not include 5G SE AV. - Replace step 9 with the following text. > Perform step 5 and the following steps as described in section 6.1.3.1 of Non-Patent Document 9. After a successful authentication process against EAP-AKA', UE 3 manages the generated NAS security context by linking to the Reg Id (the Reg Id set to 1) and the associated 5G-GUTI (5G-GUTI1).

[0332] Figure 30One or more processes can be applied to VPLMN#2. In this case, instead of a Reg Id set to 1, a Reg Id set to 2 can be used in one or more processes, and each node (e.g., UE 3, AMF 7002, AUSF 78, and UDM 75) can communicate with... Figure 30 One or more of the same or similar processing (one or more of the same processing).

[0333] The second scenario in the sixth example of the second aspect: When authentication (either for 5G AKA or EAP-AKA) has been successfully performed for multiple UE contexts in 3GPP access, UE 3 maintains multiple security contexts within UE 3. UE 3 manages each security context separately for its corresponding NAS security. Figure 31 An example of NAS security context management between UE 3 and the associated AMFs (i.e., AMF 7001 and AMF 7002) is illustrated.

[0334] like Figure 31 As illustrated, the NAS security context of a Reg Id set to 1 is associated with the AMF7001 assigned to 5G-GUTI1 (or the AMF 7001 assigned to 5G-GUTI1 (or the MN AMF 7001 described later)), while the NAS security context of a Reg Id set to 2 is associated with the AMF 7002 assigned to 5G-GUTI2 (or the AMF 7002 assigned to 5G-GUTI2 (or the SN AMF 7002 described later)). Additionally, UE 3 can have a separate NAS security context for non-3GPP access. In this case, UE 3 manages the NAS security context separately from the NAS security context with Reg Id set to 1 and the NAS security context with Reg Id set to 2. In this disclosure, 5G-GUTI1 can be represented as 5G-GUTI#1, and 5G-GUTI2 can be represented as 5G-GUTI#2. In addition to the NAS security measures described above, UE 3 can apply AS security measures. If UE 3 selects a NAS security context with a Reg Id set to 1, the UE derives an AS security context from that NAS security context.

[0335] The third scenario in the sixth example of the second aspect: Figure 32An example of an authentication process is illustrated when two authentication processes are initiated (e.g., simultaneously or sequentially). This process is typically applicable to both single PLMN scenarios and scenarios spanning multiple PLMNs. This disclosure discloses a mechanism based on AUSF.

[0336] The following is for reference. Figure 32 The detailed processing of the third scenario in the sixth example of the second aspect is described.

[0337] Step 1. UE 3 sends an N1 message to AMF 7001, which includes at least one of the following: User ID, Dual Reg Support, and Reg Id set to 1. For parameter details, refer to Step 1 in the first scenario of the second example of the second aspect.

[0338] Step 2. AMF 7001 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 78. This Nausf_UEAuthentication_Authenticate request message includes at least one of the following: user ID, dual Reg support, and Reg Id set to 1. For parameter details, refer to step 1 in the first scenario of the second example in the second aspect.

[0339] Step 3. Upon receiving a Nausf_UEAuthentication_Authenticate request message from AMF 7001, when SUPI is used as the user ID, AUSF 78 marks the user ID in the Nausf_UEAuthentication_Authenticate request message as "Auth Activated". AUSF 78 may store the user ID (e.g., SUPI). AUSF 78 may store the user ID marked as "Auth Activated". For example, if AUSF 78 determines that it has not stored a received user ID marked as "Auth Activated", AUSF 78 may store the received user ID, or it may mark the received user ID as "Auth Activated" and store the marked user ID. By marking the user ID as “authentication activated”, AUSF 78 can understand or remember that the authentication process for UE 3 (e.g., for SUPI or for Reg Id set to 1) is activated.

[0340] Step 4. AUSF 78 sends a Nudm_UEAuthentication_Get request message to UDM 75. This Nudm_UEAuthentication_Get request message includes at least one of the following: user ID, dual Reg support, and Reg Id set to 1. For parameter details, refer to Step 1 in the first scenario of the second example of the second aspect. AUSF 78 can perform the authentication process for the Reg Id set to 1. AUSF 78 can perform the authentication process triggered by the Nausf_UEAuthentication_Authenticate request message from AMF 7001.

[0341] Step 5. UE 3 sends an N1 message to AMF 7002, including the user ID, dual Reg support, and a Reg Id set to 2. For parameter details, refer to step 1 in the first scenario of the second example of the second aspect. Step 5 can be performed while performing step 1 (e.g., UE 3 can send the N1 message in step 1 and the N1 message in step 5 simultaneously). Figure 32 As shown, step 5 can be performed after step 1.

[0342] Step 6. AMF 7002 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 78. This Nausf_UEAuthentication_Authenticate request message includes at least one of the following: user ID, dual Reg support, and Reg Id set to 2. For parameter details, refer to step 1 in the first scenario of the second example in the second aspect.

[0343] Step 7. Upon receiving the Nausf_UEAuthentication_Authenticate request message from AMF 7002, AMF 78 checks whether the SUPI is used as the user ID in the Nausf_UEAuthentication_Authenticate request message from AMF 7002 and whether the SUPI is marked as "Authentication Active". If the SUPI is marked as "Authentication Active", AMF 78 sends a Nausf_UEAuthentication_Authenticate response message to AMF 7002, which includes at least one of the following: a reason set to "Authentication in Progress" and a BOT timer (e.g., the BOT timer can be set to 10 seconds). The following points explain each parameter in detail. - The reason indicates the reason for the rejection. The reason "Certification in Progress" indicates that the certification request was rejected because another certification for SUPI is in progress. - The BOT timer indicates the time value for how long AMF 7002 must wait before resending the Nausf_UEAuthentication_Authenticate request message to the AUSF 78 backoff period.

[0344] For example, AUSF 78 can check whether the SUPI received from AMF 7002 is the same as or corresponds to the SUPI received from AMF 7001. If AUSF 78 determines or confirms that the SUPI received from AMF 7002 is the same as or corresponds to the SUPI received from AMF 7001, AUSF 78 can check whether the SUPI received from AMF 7001 is marked as "Authentication Active". If AUSF 78 determines that the SUPI received from AMF 7001 is marked as "Authentication Active", AUSF 78 can also determine that the SUPI received from AMF 7002 is also marked as "Authentication Active". In this case, AUSF 78 can send a Nausf_UEAuthentication_Authenticate response message to AMF 7002, which includes at least one of the following: a reason set to "Authentication in progress" and a BOT timer. For example, if AUSF 78 determines that the SUPI received from AMF 7002 is the same as or corresponds to the SUPI received from AMF 7001 and the SUPI received from AMF 7001 is marked as "authentication activated", AUSF 78 may send a Nausf_UEAuthentication_Authenticate response message to AMF 7002, which includes at least one of the following: a reason set to "authentication in progress" and a BOT timer. For example, in step 3, AUSF 78 may only store user IDs marked as "authentication activated". In this case, in step 7, AUSF 78 may check whether the user ID stored in step 3 is the same as or corresponds to the user ID received in step 6. If AUSF 78 determines that the user ID stored in step 3 is the same as or corresponds to the user ID received in step 6, AUSF 78 may send a Nausf_UEAuthentication_Authenticate response message to AMF 7002, which includes at least one of the following: a reason set to "authentication in progress" and a BOT timer.

[0345] Step 8. When the AMF 7002 receives a Nausf_UEAuthentication_Authenticate response message with the reason set to "Authentication in progress", the AMF 7002 starts a timer. For example, if the AMF 7002 receives a Nausf_UEAuthentication_Authenticate response message that includes the reason set to "authentication in progress" and a BOT timer, the AMF 7002 can start a timer with a value indicated by the BOT timer (e.g., 10 seconds).

[0346] Step 9. The timer started in step 8 expires. For example, 10 seconds after the timer was started.

[0347] Step 10. After the timer expires, AMF 7002 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 78. This Nausf_UEAuthentication_Authenticate request message includes at least one of the following: user ID, dual Reg support, and Reg ID set to 2. When AUSF 78 receives the Nausf_UEAuthentication_Authenticate request message from AMF 7002 in step 10, it is assumed that the authentication process for the Reg ID set to 1 has been completed, and the authentication process for the Reg ID set to 2 can continue. For example, the BOT timer can be set to a value corresponding to the time spent in the authentication process. For example, AUSF 78 can check whether the authentication process for a Reg Id set to 1 has been completed. If AUSF 78 confirms that the authentication process for a Reg Id set to 1 has been completed, AUSF 78 can proceed with or continue the authentication process for a Reg Id set to 2.

[0348] For example, step 5 can be performed before step 1. In this case, when SUPI is used as the user ID, AUSF 78 can mark the user ID in the Nausf_UEAuthentication_Authenticate request message from AMF 7002 as "authentication activated". Additionally, in this case, AMF 7002 and the processes associated with or performed by AMF 7002 (one or more) described above can be replaced by AMF 7001 and the processes associated with or performed by AMF 7001 (one or more), respectively, and the processes associated with or performed by AMF 7001 and the processes associated with or performed by AMF 7001 can be replaced by AMF 7002 and the processes associated with or performed by AMF 7002 (one or more).

[0349] The fourth scenario in the sixth example of the second aspect: Figure 33 An example of an authentication process is illustrated when two authentication processes are initiated (e.g., simultaneously or sequentially). This process is typically applicable to both single PLMN scenarios and scenarios spanning multiple PLMNs. This disclosure discloses a mechanism based on UDM.

[0350] The following is for reference. Figure 33 The detailed processing of the fourth scenario in the sixth example of the second aspect is described.

[0351] Step 1. UE 3 sends an N1 message to AMF 7001, which includes at least one of the following: User ID, Dual Reg Support, and Reg Id set to 1. For parameter details, refer to Step 1 in the first scenario of the second example of the second aspect.

[0352] Step 2. AMF 7001 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 78. This Nausf_UEAuthentication_Authenticate request message includes at least one of the following: user ID, dual Reg support, and Reg Id set to 1. For parameter details, refer to step 1 in the first scenario of the second example in the second aspect.

[0353] Step 3. AUSF 78 sends a Nudm_UEAuthentication_Get request message to UDM 75. This Nudm_UEAuthentication_Get request message includes at least one of the following: user ID, dual Reg support, and Reg Id set to 1. For parameter details, refer to step 1 in the first scenario of the second example in the second aspect.

[0354] Step 4. Upon receiving a Nudm_UEAuthentication_Get request message from AUSF 78, UDM 75 marks the user ID (e.g., SUPI) in the Nudm_UEAuthentication_Get request message as "authentication activated". If a SUCI is received in the Nudm_UEAuthentication_Get request message from AUSF 78, UDM 75 dehides the received SUCI and converts it to a SUPI. UDM 75 can then mark the SUPI as "authentication activated". AUSF 78 can perform the authentication process for a Reg ID set to 1. AUSF 78 can perform the authentication process triggered by a Nausf_UEAuthentication_Authenticate request message from AMF 7001. UDM 75 may store user IDs (e.g., SUPI). UDM 75 may store user IDs marked as "authentication activated". For example, if UDM 75 determines that it has not stored a received user ID marked as "authentication activated", UDM 75 may store the received user ID, or it may mark the received user ID as "authentication activated" and store the marked user ID.

[0355] Step 5. UE 3 sends an N1 message to AMF 7002. This N1 message includes at least one of the following: User ID, Dual Reg Support, and Reg Id set to 2. For parameter details, refer to Step 1 in the first scenario of the second example of the second aspect. Step 5 can be performed while performing Step 1 (e.g., UE 3 can send the N1 message in Step 1 and the N1 message in Step 5 simultaneously). Figure 32 As shown, step 5 can be performed after step 1.

[0356] Step 6. AMF 7002 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 78. This Nausf_UEAuthentication_Authenticate request message includes at least one of the following: user ID, dual Reg support, and Reg Id set to 2. For parameter details, refer to step 1 in the first scenario of the second example in the second aspect.

[0357] Step 7. Upon receiving the Nausf_UEAuthentication_Authenticate request message from AMF 7002, AMF 78 sends a Nudm_UEAuthentication_Get request message to UDM 75. This Nudm_UEAuthentication_Get request message includes at least one of the following: user ID, dual Reg support, and Reg Id set to 2. For parameter details, refer to step 1 in the first scenario of the second example of the second aspect. In step 7, if a SUCI is received in the Nudm_UEAuthentication_Get request message from AUSF 78, UDM 75 will dehide the received SUCI and convert it into a SUPI.

[0358] Step 8. Upon receiving the Nudm_UEAuthentication_Get request message from AUSF 78, UDM 75 checks whether the SUPI is marked as "Authentication Active". If the SUPI is marked as "Authentication Active", UDM 75 sends a Nudm_UEAuthentication_Get response message to AUSF 78, which includes at least one of a reason set to "Authentication in Progress" and a BOT timer (e.g., the BOT timer can be set to 10 seconds). For parameter details, refer to step 7 in the third scenario of the sixth example in the second aspect. For example, the reason is information indicating whether authentication is in progress or not yet completed. The BOT timer can be set for various durations, periods, or times.

[0359] For example, UDM 75 can check whether the SUPI stored in step 4 is the same as or corresponds to the SUPI received or dehidden in step 7. If UDM 75 determines or confirms that the SUPI stored in step 4 is the same as or corresponds to the SUPI received or dehidden in step 7, UDM 75 can check whether the SUPI stored in step 4 is marked as "authentication activated". If UDM 75 determines that the SUPI stored in step 4 is marked as "authentication activated", UDM 75 can also determine that the SUPI received or dehidden in step 7 is also marked as "authentication activated". In this case, UDM 75 can send a Nudm_UEAuthentication_Get response message to AUSF 78, which includes at least one of the following: a reason set to "authentication in progress" and a BOT timer. For example, if UDM 75 determines that the SUPI stored in step 4 is the same as or corresponds to the SUPI received or dehidden in step 7 and the SUPI stored in step 4 is marked as "authentication activated", UDM 75 may send a Nudm_UEAuthentication_Get response message to AUSF 78, which includes at least one of the following: a reason set to "authentication in progress" and a BOT timer. For example, in step 4, UDM 75 may only store SUPIs marked as "Authentication Active". In this case, in step 8, UDM 75 may check whether the SUPI stored in step 4 is the same as or corresponds to the SUPI received or dehidden in step 7. If UDM 75 determines that the SUPI stored in step 4 is the same as or corresponds to the SUPI received or dehidden in step 7, UDM 75 may send a Nudm_UEAuthentication_Get response message to AUSF 78, which includes at least one of the following: a reason set to "Authentication in Progress" and a BOT timer.

[0360] Step 9. Upon receiving the Nudm_UEAuthentication_Get response message from UDM 75, AUSF 78 sends a Nausf_UEAuthentication_Authenticate response message (or Nausf_UEAuthentication response message) to AMF 7002. This Nausf_UEAuthentication_Authenticate response message (or Nausf_UEAuthentication response message) includes at least one of the reason received from UDM 75 in Step 8 and a BOT timer. The BOT timer can be set for various durations, time periods, or times.

[0361] Step 10. When the AMF 7002 receives a Nausf_UEAuthentication_Authenticate response message including the reason, the AMF 7002 starts a timer. For example, if the AMF 7002 receives a Nausf_UEAuthentication_Authenticate response message that includes the reason set to "authentication in progress" and a BOT timer, the AMF 7002 can start a timer with a value indicated by the BOT timer (e.g., 10 seconds).

[0362] Step 11. The timer started in step 10 expires. For example, 10 seconds after the timer was started.

[0363] Step 12. After the timer expires, AMF 7002 sends a Nausf_UEAuthentication_Authenticate request message to AUSF 78. This Nausf_UEAuthentication_Authenticate request message includes at least one of the following: user ID, dual Reg support, and Reg ID set to 2. When AUSF 78 receives the Nausf_UEAuthentication_Authenticate request message from AMF 7002 in step 12, it is assumed that the authentication process for the Reg ID set to 1 has been completed, and the authentication process for the Reg ID set to 2 can continue. For example, the BOT timer can be set to a value corresponding to the time spent in the authentication process. For example, AUSF 78 can check whether the authentication process for a Reg Id set to 1 has been completed. If AUSF 78 confirms that the authentication process for a Reg Id set to 1 has been completed, AUSF 78 can proceed with or continue the authentication process for a Reg Id set to 2.

[0364] For example, step 5 can be performed before step 1. In this case, UDM 75 can mark the user ID in the Nudm_UEAuthentication_Get request message received from AUSF 78 and including a Reg Id set to 2 as "authentication activated". Alternatively, in this case, UDM 75 can perform the process in the same manner as step 7 (one or more). For example, if the marked user ID is the same as or corresponds to the user ID in the Nudm_UEAuthentication_Get request message received from AUSF 78 and including a Reg Id set to 1, UDM 75 can send a Nudm_UEAuthentication_Get response message to AUSF 78, which includes at least one of a reason set to "authentication in progress" and a BOT timer, and AUSF 78 can send a Nausf_UEAuthentication_Authenticate response message to AMF 7001, which includes at least one of a reason received and a BOT timer. Then, AMF 7001 can be processed in the same way as AMF 7002 in step 10 (one or more).

[0365] Variation 1 of the fourth scenario in the sixth example of the second aspect: When AUSF 78 receives a Nudm_UEAuthentication_Get response message from UDM 75, AUSF 78 initiates timer handling steps 10 and 11 in place of AMF 7002 (e.g., AUSF 78 may initiate a timer with a value indicated by a BOT timer). In this case, when the BOT timer expires in AUSF 78 (e.g., in the case of a timer with a value indicated by a BOT timer expiring), AUSF 78 may send a Nudm_UEAuthentication_Get request message to UDM 75, which includes at least one of the following: user ID, dual Reg support, and Reg Id set to 2.

[0366] The fifth scenario in the sixth example of the second aspect: Figure 34 An example of NAS counting handling is illustrated in a case where a UE 3 has two or more 5G-GUTIs associated with multiple AMFs. This procedure is generally applicable to both single PLMN cases and cases spanning multiple PLMNs.

[0367] The following is for reference. Figure 34 The detailed processing of the fifth scenario in the sixth example of the second aspect is described.

[0368] In cases where UE 3 has multiple associated 5G-GUTIs within 3GPP access, UE 3 manages UL NAS counts and DL NAS counts for 3GPP access in units of RegId. The following steps illustrate an example of NAS count management in UE 3 when UE 3 has two associated 5G-GUTIs (e.g., 5G-GUTI1 and 5G-GUTI2) within 3GPP access.

[0369] Step 0-1. UE 3 has been registered to AMF 7001 in VPLMN#1, and 5G-GUTI1 has been assigned to the Reg Id set to 1. This step can be combined with... Figure 24 The steps 0-1 are the same.

[0370] Step 0-2. UE 3 has been registered to AMF 7002 in VPLMN#2, and 5G-GUTI2 has been assigned to Reg Id set to 2. This step can be combined with... Figure 24 Steps 0-2 are the same.

[0371] Step 1. UE 3 sends a NAS message to AMF 7001 using the UL NAS count value "a" for 5G-GUTI1. UE 3 manages the UL NAS count value "a" in units of Reg Id (e.g., UE 3 can manage the UL NAS count value for at least one of Reg Id set to 1 and 5G-GUTI1).

[0372] Step 2. AMF 7001 sends a NAS message to UE 3 using the DL NAS count value "b" for 5G-GUTI1. UE 3 manages the DL NAS count value "b" in units of Reg Id (e.g., UE 3 can manage the DL NAS count value for at least one of Reg Id set to 1 and 5G-GUTI1).

[0373] Step 3. UE 3 sends a NAS message to AMF 7002 using the UL NAS count value "c" for 5G-GUTI2. UE 3 manages the UL NAS count value "c" in units of Reg Id (e.g., UE 3 can manage the UL NAS count value for at least one of Reg Id set to 2 and 5G-GUTI2).

[0374] Step 4. AMF 7002 sends a NAS message to UE 3 using the DL NAS count value “d” for 5G-GUTI2. UE 3 manages the DL NAS count value “d” in units of Reg Id (e.g., UE 3 can manage the DL NAS count value for at least one of Reg Id set to 2 and 5G-GUTI2).

[0375] Step 5. UE 3 sends a NAS message to AMF 7001 using the UL NAS count value “a+1” for 5G-GUTI1. UE 3 manages the UL NAS count value “a+1” in units of Reg Id (e.g., UE 3 can manage the UL NAS count value for at least one of Reg Id set to 1 and 5G-GUTI1).

[0376] Step 6. AMF 7001 sends a NAS message to UE 3 using the DL NAS count value "b+1" for 5G-GUTI1. UE 3 manages the DL NAS count value "b+1" in units of Reg Id (e.g., UE 3 can manage the DL NAS count value for at least one of Reg Id set to 1 and 5G-GUTI1).

[0377] Step 7. UE 3 sends a NAS message to AMF 7002 using the UL NAS count value “c+1” for 5G-GUTI2. UE 3 manages the UL NAS count value “c+1” in units of Reg Id (e.g., UE 3 can manage the UL NAS count value for at least one of Reg Id set to 2 and 5G-GUTI2).

[0378] Step 8. AMF 7002 sends a NAS message to UE 3 using the DL NAS count value “d+1” for 5G-GUTI2. UE 3 manages the DL NAS count value “d+1” in units of Reg Id (e.g., UE 3 can manage the DL NAS count value for at least one of Reg Id set to 2 and 5G-GUTI2).

[0379] The first scenario in the seventh example of the second aspect: Figure 35 An example of a user plane connection model for DSATSSS service is illustrated. To route user data traffic between established single connections, both UE 3 and UPF 7203 (as the PDU session anchor UPF) have DSATSSS functionality. Although Figure 35 The example illustrates a home-routed DSMA PDU session that spans multiple service PLMNs, but this user plane connectivity model is generally applicable to both single PLMN scenarios and scenarios spanning multiple PLMNs.

[0380] This aspect includes and defines DSMA PDU sessions, dual-boot access traffic bootstrapping, switching, splitting (DSATSSS) functionality, dual-boot access traffic bootstrapping, switching, splitting-lower layer (DSATSSS-LL) functionality, and DSATSSS rules. When traffic routing is performed above the IP layer, UE 3 and UPF 7203 can support dual-boot MPTCP functionality (DSMPTCP functionality) and / or dual-boot MPQUIC functionality (DSMPQUIC functionality).

[0381] DSMA PDU Session Non-Patent Document 3 defines a Multi-Access PDU (MA PDU) session. While an MA PDU session provides one user plane connection between UE 3 and UPF 7203 on 3GPP access and another user plane connection between UE 3 and UPF 7203 on non-3GPP access, a Dual-Booted Multi-Access (DSMA) PDU session provides two or more user plane connections between UE 3 and UPF 7203 on 3GPP access to provide DSATSSS service.

[0382] DSATSSS Functionality The Dual-Boot Access Traffic Booting, Switching, Splitting (DSATSSS) functionality includes at least one of the following: Enhanced ATSSS-LL (Access Traffic Booting, Switching, Splitting - Lower Layer) functionality, Enhanced MPTCP functionality, and Enhanced MPQUIC functionality to support the DSATSSS service.

[0383] DSATSSS-LL Functionality The functionality of ATSSS-LL is defined in section 5.32 of Non-Patent Document 3. UE 3 and UPF 7203 support DSATSSS-LL functionality. In addition to ATSSS-LL functionality, DSATSSS-LL functionality also provides the following features. - The DSATSSS-LL functionality in the UE does not apply a specific protocol. It is a data handover function that determines how to bootstrap, handover, and split uplink traffic between multiple 3GPP access points based on the provided DSATSSS rules and local conditions (e.g., signal loss conditions). The DSATSSS-LL functionality in the UE can be applied to bootstrap, handover, and split all types of traffic, including TCP traffic (Transmission Control Protocol traffic), UDP traffic (User Datagram Protocol traffic), Ethernet traffic, etc. - When the UE provides "dual Reg support" during the registration process and / or PDU session establishment process, DSATSSS-LL functionality can be enabled in the UE.

[0384] Dual-boot access traffic booting, switching, and splitting functions can be invoked in other ways, such as DSATSSS functionality, enhanced ATSSS-LL functionality for dual booting, dual-boot ATSSS functionality, etc.

[0385] In addition to DSATSSS-LL functionality, UE 3 and UPF 7203 also support Multipath TCP Protocol (MPTCP) and Multipath QUIC Protocol (MPQUIC) functionality. All three bootstrapping functionalities support traffic bootstrapping, handover, and splitting across two or more 3GPP access networks on both the UE 3 and UPF 7203 sides. The SMF, together with the PCF, creates and shares DSATSSS rules and N4 rules for the UE and UPF to execute and / or apply at their respective ends.

[0386] DSMPTCP functionality Dual-boot MPTCP (DSMPTCP) functionality is an enhanced MPTCP functionality that supports DSATSSS services. MPTCP functionality is defined in section 5.32.6.2.1 of non-patent literature 3. UE 3 and UPF 7203 can support DSMPTCP functionality. Although the MPTCP functionality defined in Section 5.32.6.2.1 of Non-Patent Document 3 operates between 3GPP access and non-3GPP access, the DSMPTCP functionality operates between two 3GPP accesses as the MPTCP functionality defined in Section 5.32.6.2.1 of Non-Patent Document 3.

[0387] The DSMPTCP functionality in UE 3 uses the MPTCP protocol (IETF RFC 8684) and one or more DSATSSS rules to perform access traffic steering, handover, and splitting. The DSMPTCP functionality in UE 3 can communicate with the MPTCP proxy functionality in UPF 7203 using the user plane of 3GPP access or other 3GPP access or both. When UE 3 provides dual-reg support, DSMPTCP functionality can be enabled in UE 3. For example, DSMPTCP functionality supports the following features. - By receiving the MPTCP functionality indication in the Multi-Access Rule (MAR), the associated MPTCP proxy functionality is enabled for the MAPDU session in UPF 7203. - The network assigns UE 3 an IP address / prefix for an MA PDU session and two additional IP addresses / prefixes (referred to as "MPTCP link-specific multipath" addresses / prefixes); one associated with a 3GPP access and the other with another 3GPP access. In UE 3, these two IP addresses / prefixes are used only by the DSMPTCP functionality. The "MPTCP link-specific multipath" addresses / prefixes assigned to UE 3 may not be routed via N6. The DSMPTCP functionality in UE 3 and the DSMPTCP proxy functionality in UPF 7203 can use the "MPTCP link-specific multipath" addresses / prefixes for sub-flows on both the 3GPP access and another 3GPP access, and the MPTCP proxy functionality can use the IP address / prefix of the DSMA PDU session for communication with the final destination. - 5GC can send MPTCP proxy information to UE 3, namely, the IP address, port number, and MPTCP proxy type. The following MPTCP proxy types are supported: Type 1: Transport converter as defined in IETF RFC 8803. During N4 session establishment, SMF 7103 retrieves MPTCP proxy information from UPF 7203. UE 3 may support client extensions specified in IETF RFC 8803. - 5GC can indicate a list of applications to UE 3, for which DSMPTCP functionality should be applied. This is achieved using the bootstrap functionality component of DSATSSS rules. - When UE 3 indicates that it can support DSMPTCP functionality with any boot mode and DSATSSS-LL functionality with only active standby boot mode, and enables these functionalities for a DSMA PDU session, then UE 3 can route TCP traffic (i.e., MPTCP traffic) for which DSMPTCP functionality should be applied via the DSMA PDU session. UE 3 can route all other traffic (i.e., non-MPTCP traffic) via the DSMA PDU session, but this type of traffic can be routed on either a 3GPP access or another 3GPP access based on the received DSATSSS rules for non-MPTCP traffic. UPF 7203 can route all other traffic (i.e., non-MPTCP traffic) based on the N4 rules provided by SMF 7103. This can include N4 rules for DSATSSS-LL using any boot mode indicated by the N4 rules.

[0388] DSMPQUIC functionality Dual-boot MPQUIC (DSMPQUIC) functionality is an enhanced MPQUIC functionality that supports DSATSSS services. The functionality of MPQUIC is defined in section 5.32.6.2.2 of Non-Patent Document 3. UE 3 and UPF 7203 can support DSMPQUIC functionality. Although the MPQUIC functionality defined in Section 5.32.6.2.2 of Non-Patent Document 3 operates between 3GPP access and non-3GPP access, the DSMPQUIC functionality operates between two 3GPP accesses as the MPQUIC functionality defined in Section 5.32.6.2.2 of Non-Patent Document 3.

[0389] The DSMPQUIC functionality enables the routing, switching, and splitting of UDP traffic between UE 3 and UPF 7203 based on the DSATSSS policy created by the network. The operation of the DSMPQUIC functionality is based on RFC 9298 "Proxying UDP over HTTP," which specifies how UDP traffic can be transferred between the client (UE 3) and the proxy (UPF 7203) using the HTTP / 3 protocol (RFC 9114). The HTTP / 3 protocol operates on top of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002), which supports simultaneous communication on multiple paths as defined in draft-ietf-quic-multipath. The DSMPQUIC functionality in UE 3 communicates with the MPQUIC proxy functionality in UPF7203 using the user plane of 3GPP access or another 3GPP access or both. When both the UE 3 and the network support DSMPQUIC functionality, this functionality can be enabled for DSMA PDU sessions of type IPv4, IPv6, or IPv4v6. When the DSMA PDU session is of type Ethernet, DSMPQUIC functionality may not be enabled. MPQUIC functionality consists of three components: - QoS Flow Selection & Guiding Mode Selection: In UE 3, this component initiates the establishment of one or more multipath QUIC connections after the establishment of the MA PDU session, and selects the QoS flow (based on QoS rules), guiding mode, and transport mode (based on ATSSS or DSATSSS rules) for each uplink UDP flow. In UPF 7203, this component selects the QoS flow (based on N4 rules), guiding mode, and transport mode (based on N4 rules) for each downlink UDP flow. The supported transport modes are defined below. In UE 3, this component can be used only in the uplink direction, while in UPF 7203, this component can be used only in the downlink direction. - HTTP / 3 layer: Supports the HTTP / 3 protocol as defined in RFC 9114

[171] and the extensions defined below: RFC 9298 for supporting UDP proxies over HTTP RFC 9297 for supporting HTTP datagrams RFC 9220 for supporting extended CONNECT connections The HTTP / 3 layer selects the multipath QUIC connection to be used for each UDP stream and allocates a new QUIC stream associated with the UDP stream on that connection. The HTTP / 3 layer also configures the QUIC stream to apply a specific bootstrapping mode. In UE 3, the HTTP / 3 layer implements the HTTP / 3 client, while in UPF 7203, the HTTP / 3 layer implements the HTTP / 3 proxy. - QUIC Layer: Supports the QUIC protocol as defined in the applicable IETF specifications (RFC 9000, RFC 9001, RFC 9002) and its extensions as defined below: RFC 9221 for supporting unreliable datagram transmission using QUIC draft-ietf-quic-multipath is used to support QUIC connections using multiple paths simultaneously.

[0390] DSATSSS Rules To bootstrap, switch, and split user data in a DSMA PDU session, UE 3 and UPF 7203 can maintain DSATSSS rules. DSATSSS rules are referenced or used by UE 3 and UPF 7203 to perform DSATSSS functionality. The ATSSS rule is defined in section 5.32 of non-patent document 3. The DSATSSS rule is generated by SMF 71 (example: SMF 7103) via contact with PCF 73 (example: H-PCF 7303) and sent to UE 3 and UPF 7203. The DSATSSS rule for UPF 7203 can be included in or independent of the N4 rule. In addition to the ATSSS rule, the DSATSSS rule includes the following information. - Multi-Active Standby: When multiple accesses are available within a 3GPP access network, it is used to bootstrap Service Data Flows (SDFs) over multiple 3GPP accesses (active accesses) and, when an active access becomes unavailable, to switch the SDF to another available active access. When the active access becomes available again, the SDF is switched back to that access. - Minimum Delay: This is used to route SDF traffic to an access point determined to have the minimum round-trip time (RTT). Measurements can be obtained by UE 3 and UPF 7203 to determine the RTT over multiple 3GPP accesses. Additionally, if one access becomes unavailable, all SDF traffic is switched to another available 3GPP access. It can only be used for non-GBR (Guaranteed Bit Rate) SDF. For example, the RTT over multiple 3GPP accesses can be measured by at least one of UE 3 and UPF 7203, and the minimum delay can be calculated based on the RTT. - Load balancing: If multiple 3GPP accesses are available, it is used to split SDF across multiple 3GPP accesses. It contains the percentage of SDF traffic sent on each 3GPP access. Load balancing may apply only to non-GBR SDFs. Additionally, if one access becomes unavailable, all SDF traffic is switched to another available access. - Priority-based: This is used to route all SDF traffic to a high-priority access point until that access point is determined to be congested. In this case, SDF traffic is also sent to a low-priority access point; that is, SDF traffic is split across multiple 3GPP access points. Additionally, when a high-priority access point becomes unavailable, all SDF traffic is switched to a low-priority access point. It can only be used for non-GBR SDFs. - Redundancy: If both access points are available, it is used to replicate SDF traffic on both 3GPP access points. Any 3GPP access point can act as the primary access point. The same SDF traffic can be routed on two or more redundant paths via two or more 3GPP access points. It can also be referred to as multi-redundancy bootstrapping mode.

[0391] DSATSSS rules can be invoked in other ways, such as DSATSSS rules, enhanced ATSSS rules for dual boots, dual boot ATSSS rules, etc.

[0392] The second scenario in the seventh example of the second aspect: Figure 36 Examples of the DSMAPDU session establishment process are illustrated for both the case of a single PLMN and the case of crossing multiple PLMNs.

[0393] The following is for reference. Figure 36 The detailed processing of the second scenario in the seventh example of the second aspect is described.

[0394] Step 0. UE 3 has been registered to AMF 7001 in VPLMN#1, and 5G-GUTI1 has been assigned to Reg Id set to 1. This step can be combined with... Figure 24 The steps 0-1 are the same.

[0395] Step 1. UE 3 sends a UL NAS transport message to AMF 7001. The UL NAS transport message includes at least one of the following: 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. The NAS container includes a PDU session establishment request message, service request message, or any other NAS message that is intended to establish a DSMA PDU session or to reuse or modify an established DSMA PDU session. The following points explain each parameter in detail. - The PDU session ID is an identifier corresponding to the association between UE 3 and the data network 20 that provides PDU connectivity services. - Dual Reg support is explained in step 1 of the first scenario in the second example of the second aspect. For parameter details, refer to the first scenario in the second example of the second aspect. - The request type set to DSMA PDU request indicates that UE 3 requests to establish a DSMA PDU session. - Reg Id is explained in step 1 of the first scenario in the second example of the second aspect. For parameter details, refer to the first scenario in the second example of the second aspect. - The DS request indicates that, in addition to requesting a single data connection through the PDU session establishment request, UE 3 also requests the network to establish one or more additional single data connections. - DNN is the data network name equivalent to APN in EPS. DNN is a reference to a data network. - S-NSSAI is a single NSSAI that indicates a network slice.

[0396] In one example, a PDU session establishment request message, a service request message, or any other NAS message embedded in a UL NAS transport message may include a request type set as a DSMA PDU request.

[0397] UL NAS transmission messages can include extended UE radio capabilities.

[0398] Step 2. Upon receiving a UL NAS transmission message from UE 3, AMF 7001 performs SMF selection based on at least one of the following: the request type set to DSMA PDU request received from UE 3, the Reg Id set to 1, DS support, DS request, S-NSSAI, and DNN. AMF 7001 selects either SMF 7101 in VPLMN#1 or another SMF 7103 in HPLMN. The SMF 7101 or SMF 7103 selected by AMF 7001 can have DSATSSS functionality. Once SMF 7101 and SMF 7103 are selected, AMF 7001 sends an Nsmf_PDUSession_CreateSMContext request message to SMF 7101. This message includes at least one of the following: PDU session ID, request type set to DSMA PDU request, Reg ID set to 1, DS request, and NAS message containing a PDU session establishment request. The Nsmf_PDUSession_CreateSMContext request message may also include a user ID. For example, AMF 7001 can store information indicating which SMF(s) have DSATSSS functionality. When AMF 7001 receives a UL NAS transport message from UE 3 (e.g., if the UL NAS transport message includes at least a request type set to DSMA PDU request, DS support, and DS request), AMF 7001 can determine that it is necessary to select one or more SMFs with DSATSSS functionality. In this case, based on the stored information, AMF 7001 can select or choose one or more SMFs with DSATSSS functionality (e.g., SMF 7101 and SMF 7103).

[0399] The Nsmf_PDUSession_CreateSMContext request message may include extended UE radio capabilities.

[0400] Step 3. Upon receiving the Nsmf_PDUSession_CreateSMContext request message, SMF 7101 sends an Nsmf_PDUSession_CreateSMContext response message to AMF 7001.

[0401] Step 4. SMF 7101 sends an N4 session establishment request message to UPF 7201. This N4 session establishment request message includes at least one of the following: PDU session ID and request type set as a DSMA PDU request. The request type set as a DSMA PDU request can be represented as the request type set as a DSMA PDU initiation request.

[0402] Step 5. Upon receiving the N4 session establishment request message, the UPF 7201 reserves (one or more) resources 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. SMF 7101 sends an Nsmf_PDUSession_Create request message (Nsmf_PDUSession_Create message) to SMF 7103. This Nsmf_PDUSession_Create request message includes at least one of the following: PDU session ID, request type set to DSMA PDU request, Reg ID set to 1, DS request, S-NSSAI, and DNN. For example, in step 2, SMF 7101 can receive information related to the selected SMF 7103 from AMF 7001 (e.g., information for communicating with SMF 7103 (e.g., the IP address of SMF 7103)). Based on this information, SMF 7001 can specify or determine SMF 7103 and send an Nsmf_PDUSession_CreateSMContext request message to SMF 7103. The Nsmf_PDUSession_CreateSMContext request message may include the user ID.

[0404] Step 7. If SMF 7103 does not maintain UE 3's session management subscriber data, SMF 7103 sends a Nudm_SDM_Get message to UDM75. This Nudm_SDM_Get message includes at least one of the following: User ID, DNN, S-NSSAI, and request type set to DSMA PDU request. UE 3's SUPI is set to User ID. For details on the parameters DNN, S-NSSAI, and request type set to DSMA PDU request, please refer to Step 1.

[0405] Step 8. Upon receiving the Nudm_SDM_Get message, UDM 75 sends a Nudm_SDM_Get response message to SMF 7103, including session management subscriber data. The session management subscriber data may include dual Reg permission. For dual Reg permission, parameter details refer to step 5 in the first scenario of the second example of the second aspect. The session management subscriber data may include (one or more) service profiles. For example, when UDM 75 receives a Nudm_SDM_Get message including at least one of the following: user ID, DNN, S-NSSAI, and request type set to DSMA PDU request, UDM 75 may include dual Reg permission and at least one of (one or more) service profiles.

[0406] Step 9. If SMF 7103 does not have a PCF association, then SMF 7103 establishes a PCF association with H-PCF 7303. Then, SMF 7103 sends an Npcf_SMPolicyControl_Create message to H-PCF 7303. This Npcf_SMPolicyControl_Create message includes at least one of the following: User ID, DNN, S-NSSAI, Request Type set to DSMA PDU Request, and Reg Id set to 1. UE 3's SUPI is set to the user ID. For details on DNN, S-NSSAI, the request type set to DSMA PDU request, and Reg Id, refer to step 1 for parameter details.

[0407] Step 10. Upon receiving the Npcf_SMPolicyControl_Create message from SMF 7103, H-PCF 7303 generates PCC rules for UE 3 and sends an Npcf_SMPolicyControl_Create response message including the generated PCC rules to SMF 7103. The PCC rules include DSMA PDU session control information. For example, the PCC rules may include a DSATSSS policy. SMF 7103 derives DSATSSS rules from the received PCC rules. For example, SMF 7103 may derive DSATSSS rules based on an operator's policy. The DSATSSS policy may be, or may include, information used to derive the DSATSSS rules.

[0408] Step 11. The SMF 7103 sends an N4 session establishment request message to the UPF 7203. This N4 session establishment request message includes the PDU session ID, the request type set to DSMA PDU request, the DSMATSSS rule, a Reg Id set to 1, at least one of S-NSSAI and DNN. The DSMATSSS rule may include the N4 rule. Alternatively, the N4 rule may include the DSMATSSS rule. Upon receiving the N4 session establishment request message, the UPF 7203 may install the DSMATSSS rule. Upon receiving the N4 session establishment request message, the UPF 7203 may reserve (one or more) resources for the DSMA PDU session.

[0409] Step 12. After the successful resource reservation for the DSMA PDU session and the successful installation of the DSATSSS rules 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 DSATSSS rule received in the N4 Session Establishment Request message from the SMF 7103 in Step 12. The DSATSSS rule is used by the UPF 7203 to control traffic routing, switching, and splitting in the downlink direction.

[0411] Step 14. SMF 7103 sends an Nsmf_PDUSession_Create response message to SMF 7101. The Nsmf_PDUSession_Create response message includes the DSMATSS rule, the DS SMF name, and the DS UPF name. The following points explain each parameter in detail. - The DSMATSSS rule is part of the PCC rule used for DSMA PDU sessions. - The DS SMF name is the name of the SMF (i.e., SMF 7103) that serves as the PDU session anchor SMF for the DSMA PDU session. The DS SMF name can be the SMF's IPv4 address, the SMF's IPv6 address, or the SMF's Fully Qualified Domain Name (FQDN). The FQDN can be used if a single connection used for the DSMA PDU session is assigned to a different PLMN than the PLMN where the SMF resides. - The DS UPF name is the name of the UPF (i.e., UPF 7203) that serves as the PDU session anchor UPF for the DSMA PDU session. The DS UPF name can be the IPv4 address of the UPF, the IPv6 address of the UPF, or the FQDN of the UPF. The FQDN can be used if a single connection used for the DSMA PDU session is assigned to a different PLMN than the PLMN where the UPF resides.

[0412] Step 15. Upon receiving the Nsmf_PDUSession_Create response message from SMF 7103, SMF 7101 can initiate an N4 session modification procedure with UPF 7201. SMF 7101 can provide UPF 7201 with DSATSSS rules and / or N4 rules for use in DSMA PDU sessions.

[0413] Step 16. SMF 7101 sends a Namf_Communication_N1N2MessageTransfer message to AMF 7001, which includes at least one of the PDU session ID and the N1 SM container. The N1 SM container contains a PDU session establishment accept message, which includes the DSMA PDU status, DSMATSSS rules, SMF name (e.g., DS SMF name), and UPF name (e.g., DS UPF name). The following points explain each parameter in detail. - Define the DSMATSSS rules in step 14. For parameter details, refer to step 14. - Define the DS SMF name in step 14. For parameter details, refer to step 14. - Define the DS UPF name in step 14. Refer to step 14 for parameter details. - The DSMA PDU status indicates the status of the DSMA PDU session. It indicates whether the requested DSMA PDU session was successfully established. For example, the DSMA PDU status can indicate that the requested DSMA PDU session was successfully established. As an example, although the DSMA PDU session was not established due to the lack of DSATSSS functionality support in 5GC, a PDU session without DSATSSS functionality can be established. Optionally, the DSMA PDU status includes the maximum number of single data connections that a DSMA PDU session can be configured with. This optional data is configured based on dual-reg permission in UDM 75 and local configuration in the network. For example, if the DSMA PDU status has a value of three, a DSMA PDU session can have up to three single data connections within 3GPP access for use in a DSMA PDU session.

[0414] For example, if a DSMA PDU session fails to be established, the SMF 7101 can send a PDU session establishment rejection message that includes an indication of the DSMA PDU status indicating that the requested DSMA PDU session has failed to be established.

[0415] Step 17. Upon receiving the Namf_Communication_N1N2MessageTransfer message from SMF 7101, AMF 7001 sends a DL NAS transfer message to UE 3. This DL NAS transfer message includes a PDU session establishment accept message, a service accept message, or any other NAS message. The PDU session establishment accept message, service accept message, any other NAS message, or other SM message includes at least one of DSMA PDU status, DSMATSSS rule, DS SMF name, and DS UPF name. For parameter details, refer to step 16.

[0416] Step 18. Upon receiving a PDU session establishment accept message, service accept message, or any other NAS message, UE 3 installs the received DSATSSS rules for the DSMA PDU session. DSATSSS rules are used by UE 3 to control traffic routing, handover, and splitting in the uplink direction. If the DSMA PDU status indicates the maximum number of single data connections that can be configured for a DSMA PDU session, then when UE 3 initiates an additional DSMA PDU session establishment procedure as disclosed in the third scenario of the seventh example in the second aspect, UE 3 refers to that indication so as not to exceed the maximum number of single data connections.

[0417] Step 19. If SMF 7103 receives the DS request in the Nsmf_PDUSession_CreateSMContext request message in step 6, and SMF 7103 has any N4 association with other AMFs, then SMF 7103 initiates the establishment of user plane resources with all other AMFs by sending Namf_Communication_N1N2MessageTransfer, which includes N2SM information.

[0418] Variant 1 of the second scenario in the seventh example of the second aspect: If SMF 7101 does not maintain session management subscriber data when it receives the Nsmf_PDUSession_CreateSMContext request message from AMF 7001 in step 2, then SMF 7101 sends a Nudm_SDM_Get message to UDM 75. This Nudm_SDM_Get message includes at least one of the following: User ID, DNN, S-NSSAI, and request type set to DSMA PDU request. UE 3's SUPI is set to User ID. For details regarding the parameters DNN, S-NSSAI, and request type set to DSMA PDU request, please refer to step 1.

[0419] Upon receiving the Nudm_SDM_Get message from SMF 7101, UDM 75 sends a Nudm_SDM_Get response message to SMF 7101, which includes session management subscriber data. The session management subscriber data may include dual Reg permission. For details regarding the parameters for dual Reg permission, refer to step 5 in the first scenario of the second example of the second aspect.

[0420] Variant 2 of the second scenario in the seventh example of the second aspect: At step 6, if SMF 7101 does not have a PCF association, then SMF 7101 establishes a PCF association with PCF 7301. Then, SMF 7101 sends an Npcf_SMPolicyControl_Create message to PCF 7301. This Npcf_SMPolicyControl_Create message includes at least one of the following: User ID, DNN, S-NSSAI, request type set to DSMA PDU request, and Reg Id set to 1. UE 3's SUPI is set to the user ID. For details on DNN, S-NSSAI, the request type set to DSMA PDU request, and Reg Id, refer to step 1 for parameter details.

[0421] Upon receiving the Npcf_SMPolicyControl_Create message from SMF 7101, PCF 7301 generates PCC rules for UE 3 and sends an Npcf_SMPolicyControl_Create response message containing the generated PCC rules to SMF 7101. The PCC rules in SMF 7101 may not require any specific policies to manage DSMA PDU sessions.

[0422] The third scenario in the seventh example of the second aspect: Figure 37 Examples of additional DSMA PDU session establishment procedures are shown for both single PLMN scenarios and scenarios spanning multiple PLMNs.

[0423] The following is for reference. Figure 37 The detailed processing of the third scenario in the seventh example of the second aspect is described.

[0424] Step 0-1. UE 3 has been registered to AMF 7001 in VPLMN#1 and has been assigned 5G-GUTI1 with a Reg Id set to 1. This step can be combined with... Figure 24 Steps 0-1 are the same. Additionally, a DSMA PDU session has already been established between UE 3 and UPF 7203 on VPLMN#1. For example, the DSMA PDU session may already be based on... Figure 36 One or more processes are established on VPLMN#1 between UE 3 and UPF 7203.

[0425] Step 0-2. UE 3 has been registered to AMF 7002 in VPLMN#2 and has been assigned 5G-GUTI2 with a Reg Id set to 2. This step can be combined with... Figure 24 Steps 0-2 are the same.

[0426] Step 1. UE 3 sends a UL NAS transport message to AMF 7002. This UL NAS transport message includes at least one of the following: 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. The NAS container includes a PDU session establishment request message, service request message, or any other NAS message that aims to establish a DSMA PDU session, reuse an existing DSMA PDU session, or modify an existing DSMA PDU session. The DSMA PDU session information may include at least one of the following: DS SMF name, DSUPF name, linked 5G-GUTI, and linked PDU session ID. The following points explain each parameter in detail. - The PDU session ID is explained in step 1 of the second scenario in the seventh example of the second aspect. Refer to the second scenario in the seventh example of the second aspect. Additionally, when UE 3 initiates an additional DSMA PDU session establishment procedure, UE 3 can use the same PDU session ID value as used for a DSMA PDU session with another 5G-GUTI (i.e., 5G-GUTI1). In this case, the PDU session ID is considered unique among all registered 5G-GUTIs within the 3GPP access. Using this option, the combination of the SUPI derived from the 5G-GUTI and the PDU session ID can uniquely identify a DSMA PDU session from any PLMN. If UE 3 uses any value of the PDU session ID for a 5G-GUTI (i.e., 5G-GUTI2), the PDU session ID is considered unique for that 5G-GUTI. That is, the PDU session value can be copied between registered 5G-GUTIs within a 3GPP access network. Using this option, a combination of the Reg Id, the SUPI derived from the 5G-GUTI, and the PDU session ID can uniquely identify a DSMA PDU session from any PLMN. - Step 1 of the second scenario in the seventh example of the second aspect explains the request type that is set as a DSMA PDU request. Refer to the second scenario in the seventh example of the second aspect. - The Reg Id is explained in step 1 of the first scenario in the second example of the second aspect. Refer to the first scenario in the second example of the second aspect. - The DS request is explained in step 1 of the second scenario in the seventh example of the second aspect. Refer to the second scenario in the seventh example of the second aspect. - The DNN is explained in step 1 of the second scenario in the seventh example of the second aspect. Refer to the second scenario in the seventh example of the second aspect. - S-NSSAI is explained in step 1 of the second scenario in the seventh example of the second aspect. Refer to the second scenario in the seventh example of the second aspect. - If a DSMA PDU session has already been established using the PDU session ID, the DSMA PDU session information indicates the status of the MA PDU session. The DSMA PDU session information may be part of the MA PDU session information defined in Non-Patent Document 6. The DSMA PDU session information includes the following information: The DS SMF name is explained in step 14 of the second scenario in the seventh example of the second aspect. Refer to the second scenario in the seventh example of the second aspect. The DS UPF name is explained in step 14 of the second scenario in the seventh example of the second aspect. Refer to the second scenario in the seventh example of the second aspect. The 5G-GUTI link is explained in step 4 of the second scenario in the second example of the second aspect. Refer to the second scenario in the second example of the second aspect. The PDU session ID of the link indicates the PDU session ID assigned to the DSMA PDU session by the 5G-GUTI of the link. For example, if the DSMA PDU session established in step 0-1 uses a PDU session ID set to 1 (e.g., the DSMA PDU session established in step 0-1 may be associated with at least one of the 5G-GUTI of the link set to 5G-GUTI1 and the Reg ID set to 1), the PDU session ID of the link can be set to 1.

[0427] In one example, a PDU session establishment request message, a service request message, or any other NAS message embedded in a UL NAS transport message may include a request type set as a DSMA PDU request.

[0428] Step 2. When the UL NAS transmission message is received from UE 3, the AMF 7002 performs SMF selection. The SMF in VPLMN#2 (i.e., SMF 7102) is selected based on the request type set to DSMA PDU request, the Reg Id set to 2, DS support, S-NSSAI, and DNN received from UE 3. For example, AMF 7002 may store information indicating which SMF(s) have DSATSSS functionality. When AMF 7002 receives a UL NAS transport message from UE 3 (e.g., if the UL NAS transport message includes at least the request type set to DSMA PDU request, DS support, and DS request), AMF 7002 may determine that it is necessary to select one or more SMFs with DSATSSS functionality. In this case, based on the stored information, AMF 7002 can select or choose one or more SMFs with DSATSSS functionality (e.g., SMF 7102).

[0429] The SMF in the HPLMMN is selected based on the DS SMF name in the DSMA PDU session information received in step 1 (i.e., SMF 7103). Note that the SMF 7103, which serves as the PDU session anchor SMF for an established DSMA PDU session, can be uniquely identified by using the received DS SMF name.

[0430] Step 3. Once SMF 7102 and SMF 7103 are selected, AMF 7002 sends an Nsmf_PDUSession_CreateSMContext request message to SMF 7102. This Nsmf_PDUSession_CreateSMContext request message includes at least one of the following: PDU session ID, request type set to DSMA PDU request, Reg ID set to 2, DS request, and NAS message. The NAS message contains a PDU session establishment request, service request message, or any other NAS message that aims to establish a DSMA PDU session or to reuse or modify an existing DSMA PDU session. The Nsmf_PDUSession_CreateSMContext request message may include a user ID.

[0431] Step 4. Steps 3 to 5 in the second scenario of the seventh example of the second aspect occur. For example, upon receiving the Nsmf_PDUSession_CreateSMContext request message, the SMF 7102 can send an Nsmf_PDUSession_CreateSMContext response message to the AMF 7002. For example, SMF 7102 sends an N4 session establishment request message to UPF 7202, which includes at least one of the PDU session ID and the request type set to DSMA PDU request. For example, upon receiving an N4 session establishment request message, the UPF 7202 reserves (one or more) resources 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. SMF 7102 sends an Nsmf_PDUSession_Create request message (Nsmf_PDUSession_Create message) to SMF 7103. This Nsmf_PDUSession_Create request message includes at least one of the following: PDU session ID, request type 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. For parameter details, refer to Step 1. The Nsmf_PDUSession_Create request may include a user ID.

[0433] Step 6. SMF 7103 sends an N4 Session Modification Request message, which includes at least one of the following: PDU Session ID, Request Type set to DSMA PDU Request, DSMATSSS rule, and Reg Id set to 2. For parameter details, refer to Step 1. DSMATSSS rules can include N4 rules. Alternatively, N4 rules can include DSMATSSS rules. Upon receiving an N4 session establishment request message, the UPF 7203 can install DSMATSS rules or update stored DSMATSS rules based on the received DSMATSS rules. Upon receiving an N4 session establishment request message, the UPF 7203 can reserve (one or more) resources for the DSMA PDU session. DSMATSSS rules can be Figure 36 The same rules as in step 11.

[0434] Step 7. After the successful resource reservation update for the DSMA PDU session and the successful installation or update of the DSATSSS rules 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 DSATSSS rules received in the N4 Session Modification Request message from the SMF 7103 in Step 6. For example, the UPF 7203 can update the DSATSSS rules in the N4 Session Modification Request message from the SMF 7103 in Step 6. For example, the UPF 7203 can update stored DSATSSS rules based on the DSATSSS rules in the N4 Session Modification Request message from the SMF 7103 in Step 6. DSATSSS rules are used by the UPF 7203 to control traffic steering, switching, and splitting in the downlink direction.

[0436] Step 9. Steps 14 to 18 occur in the second scenario of the seventh example of the second aspect. For example, SMF 7103 can send an Nsmf_PDUSession_Create response message to SMF 7102, which includes the DSMATSSS rule, the DS SMF name, and the DS UPF name. For example, upon receiving an Nsmf_PDUSession_Create response message from SMF 7103, SMF 7102 can initiate an N4 session modification procedure with UPF 7202. SMF 7102 can provide UPF 7202 with DSATSSS rules and / or N4 rules for use in DSMA PDU sessions. For example, SMF 7102 can send a Namf_Communication_N1N2MessageTransfer message to AMF 7002, which includes at least one of the PDU session ID and the N1 SM container. The N1 SM container contains a PDU session establishment accept message, which includes the DSMA PDU status, DSMATSSS rules, SMF name (e.g., DS SMF name), and UPF name (e.g., DS UPF name). For parameter details, please refer to [reference needed]. Figure 36 Step 16 in the process. For example, upon receiving the Namf_Communication_N1N2MessageTransfer message from SMF 7102, AMF 7002 may send a DL NAS transfer message to UE 3. This DL NAS transfer message includes a PDU session establishment accept message, a service accept message, or any other NAS message. The PDU session establishment accept message, service accept message, any other NAS message, or other SM message includes at least one of DSMA PDU status, DSMATSSS rule, DS SMF name, and DS UPF name. For example, upon receiving a PDU session establishment accept message, service accept message, or any other NAS message, UE 3 can install the received DSATSSS rules for the DSMA PDU session, or update the stored DSATSSS rules based on the received DSATSSS rules. DSATSSS rules are used by UE 3 to control traffic routing, switching, and splitting in the uplink direction.

[0437] Step 10. When the additional PDU session establishment procedure in this disclosure is successful, UE 3 establishes a DSMA PDU session that uses 3GPP access on VPLMN#1 to configure a single data connection and uses 3GPP access on VPLMN#2 to configure another single data connection.

[0438] The fourth scenario in the seventh example of the second aspect: Figure 38Examples of network-triggered service request procedures are illustrated for both single PLMN scenarios and scenarios spanning multiple PLMNs. The procedures disclosed in this scenario are likely to be effective only if two or more individual data connections are established within the same PLMN.

[0439] The following is for reference. Figure 38 The detailed processing of the fourth scenario in the seventh example of the second aspect is described.

[0440] Step 0-1. UE 3 has been registered to AMF 7001 in VPLMN#1 and has been assigned 5G-GUTI1 with a Reg Id set to 1. This step can be combined with... Figure 24 The steps 0-1 are the same.

[0441] Step 0-2. UE 3 has been registered with AMF 7003 in VPLMN#1 and has been assigned 5G-GUTI3 and a Reg ID set to 3. For example, UE 3 can communicate with [other devices] using a Reg ID set to 3. Figure 24 The process is the same or similar to steps 0-1 in the previous steps, and 5G-GUTI3 can be assigned to UE 3.

[0442] Steps 0-3. A DSMA PDU session has been established between UE 3 and UPF 7203 on VPLMN#1 using a single data connection with 5G-GUTI1 and another single data connection with 5G-GUTI3. For example, UE 3 can perform Figure 36 and Figure 37 One or more processes are used to establish a DSMA PDU session. For example, UE 3 can be configured for 5G-GUTI1. Figure 36 (One or more) processing in the process, and for 5G-GUTI3 Figure 37 One or more processes are involved in establishing a DSMA PDU session. For example, UE 3 can perform a process against AMF 7003 in VPLMN#1 using a Reg Id set to 3. Figure 37 Similar or identical (one or more) processing in the process.

[0443] Step 1. Downlink data arrives at UPF 7201 from AF 201 via UPF 7203.

[0444] Step 2. UPF 7201 sends a data notification message to SMF 7101.

[0445] Step 3. SMF 7101 sends a data notification acknowledgment (Ack) message to UPF 7201.

[0446] Step 4. SMF 7101 determines how SMF 7101 should trigger the UE 3 service request procedure. See the following points as examples of decision criteria in SMF 7101. If UE 3 is in a CM idle state and the paging policy in the URSP rule indicates the paging priority order, then SMF 7101 looks up a single data connection with the radio type ranked highest priority and sends a Namf_Communication_N1N2MessageTransfer message to the associated AMF using the single data connection used to page UE 3 or by using the single data connection used to page UE 3. The radio type may indicate a RAT type. The radio type may be defined as the RAT type mentioned in Non-Patent Document 8 as referred to in the first example of the first aspect. The definition of the radio type in the first scenario of the second example of the second aspect may be applied to radio types in this aspect or other aspects. For example, SMF 7101 may know or understand which radio type a single data connection is associated with. If no paging response is received from UE 3 with the highest priority radio type, SMF7101 uses or sends another Namf_Communication_N1N2MessageTransfer message by using the second highest priority radio type. - If UE 3 is in CM idle state and the URSP rule for UE 3 indicates that the radio type for a single data connection is restricted to paging, then SMF 7101 does not use a single data connection to send Namf_Communication_N1N2MessageTransfer messages to the associated AMF to paging UE 3. - If UE 3 is in CM idle state and UE 3's extended UE radio capability indicates that UE 3 can only listen to one paging channel (or paging message) at a time, then SMF 7101 uses a single data connection to double-cast or send (one or more) Namf_Communication_N1N2MessageTransfer messages to all associated AMFs to page UE 3 on all associated radio types.

[0447] If UE 3 is in the CM connected state, SMF 7101 can dualcast or send (one or more) Namf_Communication_N1N2MessageTransfer messages to all associated AMFs, or send (one or more) Namf_Communication_N1N2MessageTransfer messages to one of the AMFs.

[0448] Step 5-1. If the decision to dual-cast or transmit was made in step 4, then SMF 7101 sends a Namf_Communication_N1N2MessageTransfer message to AMF 7001.

[0449] Step 5-2. If the decision to dual-cast or transmit was made in step 4, then SMF 7101 sends a Namf_Communication_N1N2MessageTransfer message to AMF 7003.

[0450] For example, if SMF 7101 decides to send a Namf_Communication_N1N2MessageTransfer message to the associated AMF in step 4, SMF 7101 can send the Namf_Communication_N1N2MessageTransfer message to AMF 7001 or AMF 7003. For example, if SMF 7101 can double-cast or send (one or more) Namf_Communication_N1N2MessageTransfer messages to all associated AMFs or to one or more AMFs in step 4, then SMF 7101 can send Namf_Communication_N1N2MessageTransfer messages to at least one of AMF 7001 and AMF 7003.

[0451] Step 6-1. Upon receiving the Namf_Communication_N1N2MessageTransfer message, AMF7001 sends a Namf_Communication_N1N2MessageTransfer response message to SMF 7101.

[0452] Step 6-2. Upon receiving the Namf_Communication_N1N2MessageTransfer message, AMF7003 sends a Namf_Communication_N1N2MessageTransfer response message to SMF7101.

[0453] Step 7-1. When the Namf_Communication_N1N2MessageTransfer message is received from the SMF 7101, if UE 3 is in the CM idle state, the AMF 7001 will perform a paging; or if UE 3 is in the CM connected state, the AMF 7001 will send a NAS notification message to UE 3.

[0454] Step 7-2. When the Namf_Communication_N1N2MessageTransfer message is received from the SMF 7101, if UE 3 is in the CM idle state, the AMF 7003 will perform a paging; or if UE 3 is in the CM connected state, the AMF 7003 will send a NAS notification message to UE 3.

[0455] Step 8. UE 3 sends a service request message to AMF 7001 as a paging response. For example, UE 3 can send a service request message to AMF 7001 as a response to a NAS notification message.

[0456] Step 9. Upon receiving a service request message from UE 3, AMF 7001 sends an Nsmf_PDUSession_UpdateSMContext request message, including the PDU session ID, to SMF 7101. The PDU session ID can be the PDU session ID used in the establishment of the DSMAPDU session in steps 0-3. SMF 7101 continues the service request process with AMF 7001.

[0457] Step 10. SMF 7101 sends a Namf_Communication_NonUeN2InfoNotify message to AMF 7003, including a paging stop indication. The paging stop indication requests AMF 7003 to stop paging processing for UE 3. The paging stop indication may request AMF 7003 to stop sending NAS notification messages to UE 3.

[0458] Step 11. Upon receiving a Namf_Communication_NonUeN2InfoNotify message that includes a paging stop indication, the AMF 7003 terminates any paging processing to UE 3. For example, upon receiving a Namf_Communication_NonUeN2InfoNotify message that includes a paging stop indication, the AMF 7003 may stop sending NAS notification messages to UE 3.

[0459] In the above description, although it is assumed that UE 3 receives the paging or NAS notification message from AMF 7001 before receiving it from AMF 7003, there are cases where UE 3 receives the paging or NAS notification message from AMF 7003 before receiving it from AMF 7001. In this case, UE 3 can send a service request message to AMF 7003. Then, AMF 7003 can perform the same or similar (one or more) processing as AMF 7001 described above.

[0460] Variant 1 of the fourth scenario in the seventh example of the second aspect: In one example, assume UE 3 according to Figure 38 Registration is made with multiple AMFs (e.g., AMF 7001 and AMF 7003 in a single VPLMN#1). It is also assumed that UE 3 registers with two AMFs for different S-NSSAIs. For example, UE 3 is registered with AMF 7001 for the S-NSSAI specified by IMS and with AMF 7003 for the S-NSSAI specified by CIoT. Then, when SMF 7101... Figure 38When a downlink data packet (e.g., a data notification message) is received at step 2, 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 downlink service (e.g., IMS, CIoT, or any other type of service). Based on the service type of the downlink data packet and at least one of the service designation information of AMF 7001 or AMF 7003 retrieved from the UDM or from the AMF itself, SMF 7101 makes a decision regarding which AMF (e.g., AMF 7001 or AMF 7003) to notify for the downlink data. For example, if the downlink data is of type CIoT and UE 3 is registered via AMF 7003 for CIoT-specific S-NSSAI, SMF 7101 selects AMF 7003 and sends a Namf_Communication_N1N2MessageTransfer message to AMF 7003. Then, AMF 7003 continues to page UE 3 according to the paging procedure in Non-Patent Document 4, and UE 3 and the network exchange data via S-NSSAI specified by CIoT.

[0461] Based on at least one of the disclosures in the second aspect (one or more), it can resolve at least one of the aforementioned problems (one or more). For example, at least one of the disclosures in the second aspect (one or more) can address the issue that the aforementioned service requirements are not yet supported by 5GS. For example, at least one of the disclosures in the second aspect (one or more) can resolve the problem of the DSATSSS service not working.

[0462] For example, according to at least one of the disclosures in the second aspect (one or more), various procedures for DSATSSS services are proposed. Therefore, it can solve at least one of the aforementioned problems (one or more).

[0463] In all of the second aspects, the enumerated parameters or information in the message can be represented as information about multiple data connections on multiple 3GPP access networks, information about multiple data connections on multiple 3GPP access networks, or information about a DSMA PDU session.

[0464] <Third Example Implementation (Third Aspect)> This includes a mechanism for providing dual-boot ATSSS (DSATSSS) services within a single PLMN. The DSATSS service can have more than two individual connections. That is, a DSMA PDU session can have three or more individual connections in a single PLMN.

[0465] The first example of the third aspect: Figure 39 An example of an architecture for providing DSATSSS services for home route roaming within a single PLMN is illustrated.

[0466] Figure 39 This example illustrates the case of establishing two single connections within a PLMN. The basic principles of this architecture are listed below. - UE 3 has a single USIM and corresponding single subscriber data in UDM 75. - Each individual connection has its own temporary user identifier (i.e., 5G-GUTI) and the corresponding UE context in 5GC. - Introducing MN AMF 7001 as the master node AMF. MN AMF 7001 represents the AMF for external 3GPP nodes, including SMF 71, PCF 73, UDM 75, etc. - SN AMF 7002 was introduced as a secondary AMF node. SN AMF 7002 is not visible to external 3GPP nodes, including SMF 71, PCF 73, UDM 75, etc. - The MN AMF 7001 has proxy functionality for any signaling between external nodes and the SN AMF 7002. - SN AMF 7002 has proxy functionality for any signaling between RAN 502 and MN AMF 7001. - MN AMF 7001 and SN AMF 7002 can be combined, but UE 3 has a separate 5G-GUTI. - MN AMF 7001 and SN AMF 7002 can be combined, and UE 3 has a single 5G-GUTI.

[0467] when Figure 39 When used in non-roaming or roaming scenarios with local offloading, SMF 7101 and SMF 7103 are combined into one SMF residing in VPLMN#1, and UPF 7201 and UPF 7203 are combined into one UPF residing in VPLMN#1. Data network 20 is connected to the combined UPF at VPLMN#1.

[0468] The first scenario in the second example of the third aspect: Figure 40 An example of the registration process in a single PLMN is shown.

[0469] The following is for reference. Figure 40 The detailed processing of the first scenario in the second example of the third aspect is described.

[0470] Step 0. UDM 75 maintains (one or more) service profiles (e.g., (one or more) DSATSSS service profiles) for the subscribed DSATSSS service in the subscriber data of UE 3.

[0471] Step 1. UE 3 sends a registration request message to MN AMF 7001. The registration request message includes at least one of the following: user ID, dual Reg support, Reg Id set to 1, and extended UE radio capabilities. For parameter details, refer to step 1 in the first scenario of the second example in the second aspect. For example, UE 3 can be used with MN AMF 7001. Figure 17 The UE 3 in step 1 is the same as or similar to one or more other processes. UE 3 can be in a single PLMN. For example, UE 3 can send a registration request message for a DSMA PDU session. For example, UE 3 can initiate the registration process for a DSMA PDU session by sending a registration request message. For example, UE 3 can select a PLMN (e.g., a single PLMN) based on one or more service profiles in UE 3 and send a registration request message.

[0472] Step 2. Upon receiving the registration request message in Step 1, MN AMF 7001 sends a Nudm_UECM_Registration request message to UDM 75. This Nudm_UECM_Registration request message includes at least one of the following: dual Reg support, Reg Id set to 1, extended UE radio capabilities, UE cell location, and radio type. For parameter details, refer to steps 1 and 2 in the first scenario of the second example in the second aspect. For example, MN AMF 7001 can be used with Figure 17 The AMF 7001 in step 2 is the same as or similar to the AMF 7001 (one or more) process. For example, the MN AMF 7001 can send a Nudm_UECM_Registration request message for a DSMA PDU session. For instance, the MN AMF 7001 can perform the registration process for a DSMA PDU session by sending a Nudm_UECM_Registration request message.

[0473] Step 3. UDM 75 sends a Nudm_UECM_Registration response message to MN AMF 7001. For example, UDM 75 can perform with Figure 17 The UDM 75 in step 3 is the same as or similar to the UDM 75 in step 3.

[0474] Step 4. After the Nudm_UECM_Registration service in steps 2 and 3 is completed, the MN AMF 7001 sends a Nudm_SDM_Get request message to the UDM 75. This Nudm_SDM_Get request message includes dual Reg support, Reg Id set to 1, extended UE radio capabilities, UE cell location, and radio type. For parameter details, refer to step 2 in the first scenario of the second example of the second aspect. For example, MN AMF 7001 can be used with Figure 17 The AMF 7001 in step 4 is the same as or similar to the AMF 7001 in step 4. For example, the MN AMF 7001 can send a Nudm_SDM_Get request message for a DSMA PDU session. For example, the MN AMF 7001 can perform the registration process for a DSMA PDU session by sending a Nudm_SDM_Get request message.

[0475] Step 5. UDM 75 retrieves the subscriber data for UE 3 and sends a Nudm_SDM_Get response message containing the subscriber data for UE 3 to MN AMF 7001. The subscriber data includes a service profile for DSATSSS services that are enabled for Reg Id set to 1 and dual Reg. The service profile can be selected by UDM 75 based on the UE cell location, radio type, and the AMF to which it is roaming. The service profile for DSATSSS services is defined in the first example of the first aspect. The following points explain each parameter in detail. - The permission for double Reg is explained in step 5 of the first scenario in the second example of the second aspect. Refer to the first scenario in the second example of the second aspect. For example, UDM 75 can perform with Figure 17 The UDM 75 in step 5 is the same as or similar to the UDM 75 in step 5.

[0476] Step 6. After MN AMF 7001 obtains the subscriber data of UE 3 from UDM 75 in Step 5, MN AMF 7001 sends a registration acceptance message to UE 3. This registration acceptance message includes at least one of 5G-GUTI (e.g., 5G-GUTI1), dual Reg permission, and a service profile for a Reg Id set to 1. For dual Reg permission, parameter details are described in Step 5. When UE 3 receives a service profile for a Reg Id set to 1, UE 3 stores the received service profile in non-volatile memory in UE 3 by linking it to the Reg Id set to 1. For example, MN AMF 7001 can be used with Figure 17 The AMF 7001 in step 6 is the same as or similar to the AMF 7001 (one or more) process. For example, UE 3 can perform with Figure 17 The UE 3 in step 6 is the same as or similar to one or more other processes.

[0477] For example, Figure 40 The registration process can be represented as a registration process for a DSMA PDU session, or a registration process for multiple data connections on multiple 3GPP access networks, or a registration process for multiple data connections on multiple 3GPP access networks in a single PLMN, or a registration process for multiple data connections on multiple 3GPP access networks in (one or more) PLMNs.

[0478] The second scenario in the second example of the third aspect: Figure 41 An example of an additional registration process typically applicable to a single PLMN is shown. When UE 3 looks for a 3GPP access network that can provide a single connection for configuring a DSMA PDU session in addition to an existing single connection established on the same PLMN, UE 3 can initiate an additional registration procedure.

[0479] The following is for reference. Figure 41 The detailed processing of the second scenario in the second example of the third aspect is described.

[0480] Step 1. Steps 1 to 5 occur in the second scenario of the second example of the second aspect. For example, UE 3 can perform with Figure 19 The UE 3 in step 1 is the same as or similar to one or more other processes. For example, UE 3 can perform with Figure 19 The UE 3 process in step 2 is the same or similar to one or more other processes. For example, the UE 3 may select VPLMN#1 or a single PLMN based on one or more service profiles in the UE 3 and send an RRC setup request message to RAN 502 in VPLMN#1 or a single PLMN. For example, RAN 502 can be used with Figure 19 The RAN 502 process in step 3 is the same as or similar to the RAN 502 process. For example, UE 3 can perform with Figure 19 Step 4 of UE 3 involves one or more processes that are the same or similar. For example, UE 3 may send an RRC setup complete message to RAN 502. For example, RAN 502 can be used with Figure 19 The RAN 502 process in step 5 is the same as or similar to the RAN 502 process. For example, UE 3 can send an RRC setup complete message for a DSMA PDU session. For example, UE 3 can initiate the registration process for a DSMA PDU session by sending an RRC setup complete message. For example, UE 3 can send a registration request message for a DSMA PDU session. For example, UE 3 can initiate the registration process for a DSMA PDU session by sending a registration request message.

[0481] Step 2. RAN 502 sends a UE initial message to SN AMF 7002, which includes at least one of the following: UE cell location, radio type, and NAS PDU. For details regarding the UE cell location and radio type, refer to step 2 in the first scenario of the second example in the second aspect. If RAN 502 discovers that MN AMF 7001 can route based on the 5G-GUTI of the link set to 5G-GUTI1 received in the RRC setup completion message, RAN 502 sends a UE initialization message to MN AMF 7001. In this case, steps 3 and 7 are omitted and completed internally within MN AMF 7001, and the registration acceptance message in step 8 is sent from MN AMF 7001. If RAN 502 discovers that SN AMF 7002 can route based on the 5G-GUTI of the link that is set to 5G-GUTI1 as received in the RRC setup completion message, then RAN 502 can send a UE initialization message to SN AMF 7002. The content of the UE initial message in step 2 can be the same as... Figure 19 The content of the UE initial message in step 6 is the same as or similar to that in step 6.

[0482] Step 3. Upon receiving the registration request message in Step 2 (or upon receiving the UE initialization message including the NAS PDU (which includes the registration request message), SN AMF 7002 sends a Namf_Communication_UEContextTransfer message to MN AMF 7001. The Namf_Communication_UEContextTransfer message includes at least one of the following: MN 5G-GUTI set to 5G-GUTI1, SN 5G-GUTI set to 5G-GUTI2, Reg Id set to 2, UE cell location, and radio type. The following points explain each parameter in detail. - MN 5G-GUTI indicates the 5G-GUTI assigned to UE 3 by MN AMF 7001. - SN 5G-GUTI indicates the 5G-GUTI that SN AMF 7002 has assigned to UE 3 or will assign to UE 3. - The Reg Id is explained in step 1 of the first scenario in the second example of the second aspect. Refer to the first scenario in the second example of the second aspect. - The UE cell location is explained in step 2 of the first scenario in the second example of the second aspect. Refer to the first scenario in the second example of the second aspect. - The radio type is explained in step 2 of the first scenario in the second example of the second aspect. Refer to the first scenario in the second example of the second aspect.

[0483] For example, the SN AMF 7002 can send a Namf_Communication_UEContextTransfer message for a DSMA PDU session. For example, the SN AMF 7002 can perform the registration process for a DSMA PDU session by sending the Namf_Communication_UEContextTransfer message.

[0484] Step 4. Upon receiving the Namf_Communication_UEContextTransfer message in Step 3, the MNAMF 7001 sends a Nudm_SDM_Get request message to the UDM 75. This Nudm_SDM_Get request message includes at least one of the following: dual Reg support, Reg Id set to 2, extended UE radio capabilities, UE cell location, and radio type. For parameter details, refer to Step 2 in the first scenario of the second example of the second aspect.

[0485] Step 5. UDM 75 retrieves the subscriber data for UE 3 and sends a Nudm_SDM_Get response message containing the subscriber data for UE 3 to MN AMF 7001. The subscriber data includes a service profile for DSATSSS services applicable to Reg Id set to 2 and dual Reg allowed. The service profile can be selected by UDM 75 based on the UE cell location, radio type, and the AMF to which it is roaming. The service profile for DSATSSS services (e.g., (one or more) service profiles) is defined in the first example of the first aspect. The following points explain each parameter in detail. - The permission for double Reg is explained in step 5 of the first scenario in the second example of the second aspect. Refer to the first scenario in the second example of the second aspect. For example, UDM 75 can perform with Figure 19 The UDM 75 in step 10 is the same as or similar to the UDM 75 in step 10.

[0486] Step 6. After MN AMF 7001 obtains the subscriber data of UE 3 from UDM 75 in step 5, MN AMF 7001 stores SN 5G-GUTI and Reg Id set to 2 for SN 5G-GUTI in the UE context.

[0487] Step 7. MN AMF 7001 sends a Namf_Communication_UEContextTransfer response message, including the UE context, to SN AMF 7002. The UE context may include at least one of MN 5G-GUTI and a Reg Id set to 1.

[0488] Step 8. SN AMF 7002 stores the received UE context, which includes MN 5G-GUTI and Reg Id set to 1 for MN 5G-GUTI in the UE context.

[0489] Step 9. SN AMF 7002 sends a registration acceptance message to UE 3. This registration acceptance message includes at least one of 5G-GUTI2, dual Reg allow, and a service profile for a Reg Id set to 2. For dual Reg allow, refer to step 5 for parameter details.

[0490] For example, Figure 41 The registration process can be represented as a registration process for a DSMA PDU session, or a registration process for multiple data connections on multiple 3GPP access networks, or a registration process for multiple data connections on multiple 3GPP access networks in a single PLMN, or a registration process for multiple data connections on multiple 3GPP access networks in (one or more) PLMNs.

[0491] Variant 1 of the second scenario in the third aspect: If UE 3 requests to add a third or more registrations to another SN AMF, the process can be repeated as many times as UE 3 desires to have. In this case, MN AMF 7001 manages the association with multiple SN AMFs by linking with the Reg Id.

[0492] The first scenario in the third example of the third aspect: Figure 42 Examples of message handling procedures between the MN AMF and SN AMF following a successful attachment registration process in a single PLMN are provided. This scenario includes the process of SN AMF 7002 forwarding signaling messages to MN AMF 7001. Since the message handling process in this scenario is generic, it is referenced and used by other processes in this disclosure.

[0493] The following points list some examples of use cases: - SN AMF 7002 receives a service request message (N1 message) from UE 3. - SN AMF 7002 receives a location report message (N2 message) from RAN 5. - SN AMF 7002 clears UE 3 (SN AMF 7002 initiated process).

[0494] The following is for reference. Figure 42 The detailed processing of the first scenario in the third example of the third aspect is described.

[0495] Step 0-1. UE 3 has been registered to MN AMF 7001, and 5G-GUTI1 has been assigned to Reg Id set to 1. (This is in contrast to the previous step.) Figure 40 In the same manner as step 0, for example, UE 3 can send a registration request message including a Reg Id set to 1, and 5G-GUTI1 can be assigned to UE 3.

[0496] Step 0-2. UE 3 has been registered to SN AMF 7002, and 5G-GUTI2 has been assigned to Reg Id set to 2. (This is in contrast to the previous step.) Figure 41 In the same manner as step 0, for example, UE 3 can send a registration request message including a Reg Id set to 2, and 5G-GUTI2 can be assigned to UE 3.

[0497] Step 1. The event occurs in SN AMF 7002. For example, SN AMF 7002 receives a NAS message from UE 3.

[0498] Step 2. SN AMF 7002 decides whether the received message needs to be forwarded to MN AMF 7001. For example, if SN AMF 7002 receives a message that is targeted at or related to 5G-GUTI1 assigned by MN AMF 7001, SN AMF 7002 may decide that the received message needs to be forwarded to MN AMF 7001. For example, if SN AMF 7002 receives a message targeting or related to a 5G-GUTI other than the 5G-GUTI1 assigned by MN AMF 7001 (e.g., a message targeting or related to a 5G-GUTI assigned by an AMF not associated with SN AMF 7002), SN AMF 7002 may decide that the received message does not need to be forwarded to MN AMF 7001. If SN AMF 7002 decides that the received message does not need to be forwarded to MN AMF 7001, SN AMF 7002 may omit one or more of the processing steps in step 3.

[0499] Step 3. SN AMF 7002 sends a Namf_Communication_N1MessageNotify message, which includes at least one of the following: request type, MN 5G-GUTI set to 5G-GUTI1, SN 5G-GUTI set to 5G-GUTI2, Reg Id set to 2, AS message container, and service message container. For example, the N1MessageNotify message includes a NAS container (e.g., an N1 message). For example, the N1MessageNotify message may include a NAS container, which includes, for example, an N1 message. The following points explain each parameter in detail. - MN 5G-GUTI is explained in step 3 of the second scenario in the second example of the third aspect. Refer to the second scenario in the second example of the third aspect. - Step 3 of the second scenario in the second example of the third aspect explains SN 5G-GUTI. Refer to the second scenario in the second example of the third aspect. - The Reg Id is explained in step 1 of the first scenario in the second example of the second aspect. Refer to the first scenario in the second example of the second aspect. The Reg Id is the Reg Id associated with the 5G-GUTI in the AMF that sent the message. For example, since the Namf_Communication_N1MessageNotify message is sent by SN AMF 7002 and SN AMF 7002 is associated with a Reg Id set to 2, the Reg Id in the Namf_Communication_N1MessageNotify message can be set to 2. - The AS message container contains N2 messages received by SN AMF 7002. If the AS message contains NAS messages, the embedded NAS messages are also forwarded by this container. - The service message container contains service messages generated by SN AMF 7002.

[0500] For example, if the SN AMF 7002 decides that a received message needs to be forwarded to the MN AMF 7001, the SN AMF 7002 can send a Namf_Communication_N1MessageNotify message.

[0501] Step 4. When the Namf_Communication_N1MessageNotify message is received in step 3, the MN AMF7001 takes action based on the received message container. For example, if the AS message container contains SM-related N1 messages, the MN AMF 7001 will forward (one or more) messages to the SMF 7101. For example, if the service message container contains policy-related service messages, the MN AMF 7001 will forward (one or more) messages to the H-PCF 7303. For example, if the service message container contains service messages related to subscriber data, the MN AMF 7001 will forward (one or more) messages to the UDM 75.

[0502] For example, if MN AMF 7001 receives a message in step 1, MN AMF 7001 can communicate with... Figure 43 The received message is sent to the SN AMF 7002 in the same manner as steps 2 and 3. The SN AMF 7002 can then send the received message to at least one of the SMF 7101, H-PCF 7303, and UDM 75.

[0503] The second scenario in the third example of the third aspect: Figure 43 Examples of message handling procedures between the MN AMF and SN AMF following a successful attachment registration process in a single PLMN are provided. This scenario includes the process of MN AMF 7001 forwarding signaling messages to SN AMF 7002. Since the message handling process in this scenario is generic, it is referenced and used by other processes in this disclosure.

[0504] The following points list some examples of use cases: - MN AMF 7001 receives subscriber data update messages (AMF service messages) for UE 3. - MN AMF 7001 receives UE policy update messages (PCF service messages) for UE 3.

[0505] The following is for reference. Figure 43 The detailed processing of the second scenario in the third example of the third aspect is described.

[0506] Step 0-1. UE 3 has been registered to MN AMF 7001, and 5G-GUTI1 has been assigned to the Reg Id set to 1. This step can be combined with... Figure 42 The steps 0-1 are the same.

[0507] Step 0-2. UE 3 has been registered to SN AMF 7002, and 5G-GUTI2 has been assigned to Reg Id set to 2. This step can be combined with... Figure 42 Steps 0-2 are the same.

[0508] Step 1. The event occurs in MN AMF 7001. For example, MN AMF 7001 receives a service message for UE 3. For example, in step 1-1, UE 3 receives a service message from SMF 7101. For example, in step 1-2, UE 3 receives a service message from H-PCF 73. For example, in step 1-3, UE 3 receives a service message from UDM 75.

[0509] Step 2. MN AMF 7001 decides whether the received message needs to be forwarded to SN AMF 7002. For example, if MN AMF 7001 receives a service message that is targeted at or related to a 5G-GUTI2 assigned by SN AMF 7002, MN AMF 7001 may decide that the received message needs to be forwarded to SN AMF 7002. For example, if MN AMF 7001 receives a service message targeting or related to a 5G-GUTI other than the 5G-GUTI2 assigned by SN AMF 7002 (e.g., a service message targeting or related to a 5G-GUTI assigned by an AMF not associated with MN AMF 7001), then MN AMF 7001 may decide that the received message does not need to be forwarded to SN AMF 7002. If MN AMF 7001 decides that the received message does not need to be forwarded to SN AMF 7002, MN AMF 7001 may omit one or more of the processing steps in step 3.

[0510] Step 3. The MN AMF 7001 sends a Namf_Communication_N1MessageNotify message, which includes at least one of the following: request type, MN 5G-GUTI set to 5G-GUTI1, SN 5G-GUTI set to 5G-GUTI2, Reg Id set to 2, AS message container and service message container. For parameter details, refer to step 3 in the first scenario of the third example in the third aspect. For example, if the MN AMF 7001 decides that a received message needs to be forwarded to the SN AMF 7002, the MN AMF 7001 can send a Namf_Communication_N1MessageNotify message.

[0511] Step 4. When the Namf_Communication_N1MessageNotify message is received in step 3, the SN AMF7002 takes action based on the received message container. For example, if the service message container contains policy-related service messages, the SN AMF 7002 performs the necessary actions in the SN AMF 7002 and can send an N1 message to UE 3 and / or an N2 message to RAN 5 (e.g., RAN 502).

[0512] For example, if the SNAMF 7002 receives (one or more) service messages in step 1, the SNAMF 7002 can communicate with... Figure 43 The received service message (one or more) is sent to MN AMF 7001 in the same manner as steps 2 and 3. Then, MN AMF 7001 can send the received message (one or more) to at least one of UE 3 and RAN 5 (e.g., RAN 501).

[0513] The third scenario in the third example of the third aspect: Figure 44 Examples of the UE context management process between MN AMF 7001 and SN AMF 7002 following a successful additional registration process in a single PLMN are illustrated. This scenario includes the process of MN AMF 7001 requesting an update to the UE context in SN AMF 7002. Since the message handling process in this scenario is generic, it is referenced and used by other processes in this disclosure.

[0514] The following points list some examples of use cases: - MN AMF 7001 updates the 5G-GUTI of UE3 by initiating a general UE configuration update procedure as described in Non-Patent Document 6. - The certification process takes place within MN AMF 7001. - The deregistration process occurs between UE 3 and MN AMF 7001.

[0515] The following is for reference. Figure 44The detailed processing of the third scenario in the third example of the third aspect is described.

[0516] Step 0-1. UE 3 has been registered to MN AMF 7001, and 5G-GUTI1 has been assigned to the Reg Id set to 1. This step can be combined with... Figure 42 The steps 0-1 are the same.

[0517] Step 0-2. UE 3 has been registered to SN AMF 7002, and 5G-GUTI2 has been assigned to Reg Id set to 2. This step can be combined with... Figure 42 Steps 0-2 are the same.

[0518] Step 1. The event occurs in MN AMF 7001. For example, updating 5G-GUTI in MN AMF 7001. For example, updating the UE context in MN AMF 7001.

[0519] Step 2. MN AMF 7001 determines whether the UE context in SN AMF 7002 needs to be updated. For example, such as Figure 41 (For example, Figure 41 As described in step 8), SN AMF 7002 can also store the UE context, including MN 5G-GUTI and Reg Id set to 1, after a successful additional registration process. Therefore, if at least one of the UE context in MN AMF 7001 and MN 5G-GUTI is updated, MN AMF 7001 can determine that the UE context in SN AMF 7002 needs to be updated. For example, if at least one of the UE context in MN AMF 7001 and MN 5G-GUTI has not been updated (e.g., if there is no change between the previous UE context and at least one of the previous MN 5G-GUTI in MN AMF 7001 and the updated UE context and at least one of the updated MN 5G-GUTI in MN AMF 7001 after step 1), MN AMF 7001 may decide that it is not necessary to update the UE context in SN AMF 7002. If MN AMF 7001 decides that it is not necessary to update the UE context in SN AMF 7002, MN AMF 7001 may not perform one or more of the processes in step 3.

[0520] Step 3. MN AMF 7001 sends a Namf_Communication_UEContextTransfer message to SN AMF 7002. The Namf_Communication_UEContextTransfer message includes at least one of the following: request type, MN 5G-GUTI set to 5G-GUTI1, SN 5G-GUTI set to 5G-GUTI2, Reg Id set to 1, UE context, and new 5G-GUTI. The following points explain each parameter in detail. - The request type indicates the type of request. For request types, see the following key points: > Update: The update instruction indicates that the UE context of UE 3 is updated in the AMF (e.g., SN AMF 7002) that receives this message. If the 5G-GUTI in the AMF that sends this message has been updated, the new 5G-GUTI can be included in this message (e.g., Namf_Communication_UEContextTransfer message). For example, if the 5G-GUTI in the AMF that sends this message has been updated, the new 5G-GUTI can be included in this message. For example, the update information indicates that the UE context of UE 3 in the AMF that receives this update information has been updated. > Delete: Delete indicates that the UE context of UE 3 is deleted in the AMF that receives this message. For example, the delete message indicates that the UE context of UE 3 in the AMF that receives this delete message is deleted. Deassociation: Deassociation indicates the removal of the association established between MN AMF 7001 and SN AMF 7002. This request type (e.g., Deassociation) can be set by SN AMF 7002 alone, because SN AMF 7002 cannot exist independently without MN AMF 7001. For example, if the cleanup process is performed by SN AMF 7002, this request type can be used by SN AMF 7002. - MN 5G-GUTI is explained in step 3 of the second scenario in the second example of the third aspect. Refer to the second scenario in the second example of the third aspect. - Step 3 of the second scenario in the second example of the third aspect explains SN 5G-GUTI. Refer to the second scenario in the second example of the third aspect. - The Reg Id is explained in step 1 of the first scenario in the second example of the second aspect. Refer to the first scenario in the second example of the second aspect. The Reg Id is the Reg Id associated with the 5G-GUTI in the AMF that sent the message. For example, the Reg Id is the Reg Id associated with the 5G-GUTI in the AMF that sent the message (e.g., a Reg Id set to 1). - A UE context is a set of information in the AMF used to manage UE 3. The UE context in the AMF is defined in Section 5.2.2.2.2 of Non-Patent Document 4. A UE context can be an updated (one or more) UE context. - The new 5G-GUTI is the updated 5G-GUTI. For example, the new 5G-GUTI is the 5G-GUTI updated by the AMF that sent the message. For example, the new 5G-GUTI is the 5G-GUTI updated by the AMF in the AMF that sent the message. The new 5G-GUTI can be included in the message if the request type set to update is included in the message.

[0521] For example, if MN AMF 7001 determines that the UE context in SN AMF 7002 needs to be updated, MN AMF 7001 can send a Namf_Communication_UEContextTransfer message.

[0522] Step 4. When the Namf_Communication_UEContextTransfer message is received in Step 3, the SNAMF 7002 takes action based on the request type. If the request type indicates an update, the SN AMF 7002 updates one or more UE contexts of UE 3. For example, the SN AMF 7002 can update one or more UE contexts in the SN AMF 7002 based on the received UE context. If the request type indicates an update and a new 5G-GUTI is received, then SN AMF 7002 updates the 5G-GUTI associated with one or more UE contexts of UE 3. For example, SN AMF 7002 may update the 5G-GUTI in SN AMF 7002 based on the new 5G-GUTI (e.g., the 5G-GUTI associated with MN AMF 7001 (e.g., 5G-GUTI1)), and may update one or more UE contexts in SN AMF 7002 based on the received UE context (e.g., one or more UE contexts associated with 5G-GUTI1 or the new 5G-GUTI). If the request type indicates deletion, SN AMF 7002 deletes one or more UE contexts for UE 3. For example, SN AMF 7002 may delete one or more UE contexts that include MN 5G-GUTI and a Reg Id set to 1. For example, SN AMF 7002 may delete one or more UE contexts for MN AMF 7001 (e.g., one or more UE contexts associated with at least one of MN 5G-GUTI and a Reg Id set to 1).

[0523] Step 5. SN AMF 7002 sends a Namf_Communication_UEContextTransfer response message to MN AMF 7001. For example, if SN AMF 7002 performs one or more update processes or one or more deletion processes in step 4, SN AMF 7002 may send a Namf_Commu...

Claims

1. A method for a user equipment (UE), comprising: When dual-boot access traffic booting, switching, and splitting services, i.e., when the DSATSSS service becomes available, receive information related to service discovery; as well as Displays information related to the discovered services.

2. A method for a user equipment (UE), comprising: Receive first system information related to congestion or bit rate via the first Uu interface; as well as Second system information related to congestion or bit rate is received via the second Uu interface.

3. A method for a user equipment (UE), comprising: The round-trip time (RTT) related information is measured by sending a first message to the network, receiving a second message from the network, and using a measurement timer.

4. A user equipment, or UE, comprising: A component used to receive service discovery-related information when dual-boot access traffic is booted, switched, or split, i.e., when the DSATSSS service becomes available; as well as A component used to display information related to the discovered services.

5. A user equipment, or UE, comprising: A component for receiving first system information related to congestion or bit rate via a first Uu interface; as well as A component for receiving second system information related to congestion or bit rate via a second Uu interface.

6. A user equipment, or UE, comprising: A component for measuring round-trip time (RTT) related information by sending a first message to the network, receiving a second message from the network, and using a measurement timer.

Images