N14 Interface Support Indicator for Service Continuity

Abstract

A method and apparatus for an N14 interface support indicator for service continuity are provided. A Next Generation Radio Access Network (NG-RAN) node of a first network operating in a wireless communication system receives an initial UE context setup request message from an Access and Mobility Management Function (AMF) of the first network. The initial UE context setup request message includes (i) a registration acceptance message in response to a registration request message and (ii) information regarding at least one second network supported by the first network, wherein the registration acceptance message includes information regarding whether an N14 interface between the AMF of the first network and the AMF of the at least one second network is supported. Based on the information regarding the at least one second network, the NG-RAN node of the first network initiates a handover for a terminal to one of the at least one second networks.

Description

Technology Field

[0001] This specification relates to the N14 interface support indicator for service continuity. Background Technology

[0002] 3GPP (3rd generation partnership project) LTE (long-term evolution) is a technology designed to enable high-speed packet communication. Many methods have been proposed to achieve LTE goals, such as reducing costs for users and operators, improving service quality, expanding coverage, and increasing system capacity. As high-level requirements, 3GPP LTE demands reduced cost per bit, improved service availability, flexible use of frequency bands, a simple structure, open interfaces, and appropriate power consumption of terminals.

[0003] Work has begun at the ITU (International Telecommunication Union) and 3GPP to develop requirements and specifications for new radio (NR) systems. 3GPP must identify and develop the technical components necessary to successfully standardize NR in a timely manner, satisfying both urgent market demands and the longer-term requirements presented by the ITU-R (ITU Radio Communication Sector) IMT (International Mobile Telecommunications)-2020 process. Furthermore, NR must be able to utilize any spectrum band up to at least 100 GHz so that it can be used for wireless communication even in the distant future.

[0004] NR targets a single technical framework that covers all deployment scenarios, usage scenarios, and requirements, including eMBB (enhanced mobile broadband), mMTC (massive machine type communications), and URLLC (ultra-reliable and low latency communications). NR must inherently be forward compatible.

[0005] Non-public networks (NPNs) are intended for exclusive use by private entities, such as enterprises, and can be deployed in various configurations utilizing both virtual and physical elements. Specifically, they can be deployed as completely standalone networks, hosted by a public land mobile network (PLMN), or provided as part of a PLMN.

[0006] Under any deployment option, unauthorized user equipment (UEs) not associated with the enterprise are not expected to attempt to connect to the NPN, which may result in resources being used to deny access to such UEs and becoming unavailable to enterprise UEs. Additionally, enterprise UEs are not expected to attempt to connect to networks to which they do not have access rights. For example, some enterprise UEs may be restricted to connecting only to the enterprise NPN, even if PLMN coverage is available in the same geographic area. Other enterprise UEs may connect to both the NPN and PLMN if specifically permitted. The problem to be solved

[0007] A method may be required that ensures service continuity to other networks in accordance with the network configuration situation, while simultaneously not causing unnecessary delay time to terminals. means of solving the problem

[0008] In one embodiment, a method is provided that is performed by a Next Generation Radio Access Network (NG-RAN) node of a first network operating in a wireless communication system. The method includes the step of receiving an Initial UE Context Setup Request message from an Access and Mobility Management Function (AMF) of the first network. The Initial UE Context Setup Request message includes (i) a Registration Accept message which is a response to a Registration Request message and (ii) information regarding at least one second network supported by the first network, wherein the Registration Accept message includes information regarding whether an N14 interface between the AMF of the first network and the AMF of the at least one second network is supported. The method includes the step of initiating a handover to one of the at least one second networks for a terminal based on the information regarding the at least one second network.

[0009] In another aspect, a device for implementing the above method is provided. Effects of the invention

[0010] This specification may have various effects.

[0011] For example, when the NG-RAN of the source network triggers a handover to the target network, it can reduce unnecessary handover attempts by checking the existence of the N14 interface.

[0012] For example, when a terminal moves to a target network where the N14 interface does not exist, it can quickly execute subsequent operations based on information received from the source network, thereby guaranteeing service continuity to the user.

[0013] The effects obtainable through the specific examples of this specification are not limited to those listed above. For example, there may be various technical effects that a person with ordinary skill in the related art can understand or derive from this specification. Accordingly, the specific effects of this specification are not limited to those explicitly described herein, but may include various effects that can be understood or derived from the technical features of this specification. Brief explanation of the drawing

[0014] FIG. 1 shows an example of a communication system to which the implementation of the present specification is applied. FIG. 2 shows an example of a wireless device to which the implementation of the present specification applies. FIG. 3 shows an example of a wireless device to which the implementation of the present specification applies. FIG. 4 shows an example of a UE to which the implementation of the present specification applies. FIG. 5 shows an example of a 5G system architecture to which the implementation of the present specification is applied. FIGS. 6 and FIGS. 7 illustrate examples of registration procedures to which the implementation of the present specification applies. FIGS. 8 and 9 illustrate examples of PDU session establishment procedures to which the implementation of the present specification applies. FIG. 10 shows an example of a non-roaming architecture for a 5GC with an unreliable non-3GPP connection to which the implementation of the present specification applies. FIG. 11 illustrates an example of a method performed by an NG-RAN node of a first network to which the implementation of the present specification applies. FIG. 12 illustrates an example of a method performed by a terminal to which the implementation of the present specification is applied. FIG. 13 illustrates an example of a method for ensuring service continuity between a PLMN and an SNPN to which the implementation of the present specification applies. FIG. 14 illustrates an example of a situation in which a PDU establishment procedure and handover are performed through N3IWF to which the implementation of the present specification is applied. FIG. 15 illustrates another example of a situation in which a PDU establishment procedure and handover are performed through N3IWF to which the implementation of the present specification applies. FIG. 16 illustrates another example of a situation in which a PDU establishment procedure and handover are performed through N3IWF to which the implementation of the present specification applies. FIG. 17 illustrates an example of a method for ensuring service continuity between a PLMN and an SNPN based on an NG setup procedure to which the implementation of the present specification applies. FIG. 18 illustrates an example of a method for informing a terminal whether the N14 interface is supported between the V-SNPN and the home SP to which the implementation of the present specification applies. FIG. 19 illustrates an example of a method for informing a terminal during a PDU session establishment procedure whether a handover between a PLMN and an SNPN to which the implementation of the present specification applies is possible. FIG. 20 illustrates an example of a method for notifying a terminal whether a handover between a PLMN and an SNPN to which the implementation of the present specification applies is possible through a UE configuration update procedure following a PDU session establishment procedure. FIG. 21 illustrates an example of a method in which a target network informs a terminal whether a handover between a PLMN and an SNPN to which the implementation of the present specification applies is possible. Specific details for implementing the invention

[0015] The following techniques, devices, and systems may be applied to various wireless multiple access systems. Examples of multiple access systems include code division multiple access (CDMA) systems, frequency division multiple access (FDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single carrier frequency division multiple access (SC-FDMA) systems, and multicarrier frequency division multiple access (MC-FDMA) systems. CDMA may be implemented through wireless technologies such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA may be implemented through wireless technologies such as global system for mobile communications (GSM), general packet radio service (GPRS), or enhanced data rates for GSM evolution (EDGE). OFDMA can be implemented through wireless technologies such as IEEE (Institute of Electrical and Electronics Engineers) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or E-UTRA (evolved UTRA). UTRA is part of UMTS (universal mobile telecommunications system). 3GPP (3rd generation partnership project) LTE (long-term evolution) is part of E-UMTS (evolved UMTS) using E-UTRA.3GPP LTE uses OFDMA in the downlink (DL) and SC-FDMA in the uplink (UL). Evolutions of 3GPP LTE include LTE-A (advanced), LTE-A Pro, and / or 5G NR (new radio).

[0016] For convenience of explanation, the implementation of this specification is described primarily in relation to 3GPP-based wireless communication systems. However, the technical characteristics of this specification are not limited thereto. For example, the following detailed description is provided based on a mobile communication system corresponding to a 3GPP-based wireless communication system, but aspects of this specification that are not limited to 3GPP-based wireless communication systems may be applied to other mobile communication systems.

[0017] For terms and technologies used in this specification that are not specifically described, reference may be made to wireless communication standard documents published prior to this specification.

[0018] In this specification, "A or B" may mean "only A," "only B," or "both A and B." Alternatively, in this specification, "A or B" may be interpreted as "A and / or B." For example, in this specification, "A, B or C" may mean "only A," "only B," "only C," or "any combination of A, B and C."

[0019] A slash ( / ) or a comma used in this specification may mean "and / or." For example, "A / B" may mean "A and / or B." Accordingly, "A / B" may mean "only A," "only B," or "both A and B." For example, "A, B, C" may mean "A, B or C."

[0020] In this specification, "at least one of A and B" may mean "only A," "only B," or "both A and B." Additionally, in this specification, the expressions "at least one of A or B" or "at least one of A and / or B" may be interpreted as synonymous with "at least one of A and B."

[0021] Additionally, in this specification, "at least one of A, B and C" may mean "only A," "only B," "only C," or "any combination of A, B and C." Furthermore, "at least one of A, B or C" or "at least one of A, B and / or C" may mean "at least one of A, B and C."

[0022] Additionally, parentheses used in this specification may mean "for example." Specifically, when indicated as "control information (PDCCH)," "PDCCH" may be proposed as an example of "control information." In other words, "control information" in this specification is not limited to "PDCCH," and "PDCCH" may be proposed as an example of "control information." Furthermore, even when indicated as "control information (i.e., PDCCH)," "PDCCH" may be proposed as an example of "control information."

[0023] Technical features described individually within a single drawing in this specification may be implemented individually or simultaneously.

[0024] Although not limited thereto, the various descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification may be applied to various fields where wireless communication and / or connectivity between devices (e.g., 5G) is required.

[0025] The present specification will be described in more detail below with reference to the drawings. In the following drawings and / or description, the same reference numerals may refer to the same or corresponding hardware blocks, software blocks, and / or function blocks unless otherwise indicated.

[0026] FIG. 1 shows an example of a communication system to which the implementation of the present specification is applied.

[0027] The 5G usage scenario shown in FIG. 1 is merely an example, and the technical features of this specification may be applied to other 5G usage scenarios not shown in FIG. 1.

[0028] The three main requirements categories for 5G are (1) enhanced mobile broadband (eMBB) category, (2) massive machine type communication (mMTC) category, and (3) ultra-reliable and low latency communications (URLLC) category.

[0029] Referring to FIG. 1, the communication system (1) includes wireless devices (100a to 100f), a base station (BS; 200), and a network (300). FIG. 1 illustrates a 5G network as an example of the network of the communication system (1), but the implementation of the present specification is not limited to a 5G system and may be applied to future communication systems beyond a 5G system.

[0030] The base station (200) and the network (300) can be implemented as wireless devices, and a specific wireless device can operate as a base station / network node in relation to another wireless device.

[0031] Wireless devices (100a to 100f) represent devices that perform communication using radio access technology (RAT) (e.g., 5G NR or LTE) and may also be referred to as communication / wireless / 5G devices. Wireless devices (100a to 100f) may include, but are not limited to, robots (100a), vehicles (100b-1 and 100b-2), extended reality (XR) devices (100c), portable devices (100d), home appliances (100e), IoT devices (100f), and artificial intelligence (AI) devices / servers (400). For example, vehicles may include vehicles with wireless communication capabilities, autonomous vehicles, and vehicles capable of performing communication between vehicles. Vehicles may include unmanned aerial vehicles (UAVs) (e.g., drones). XR devices may include AR / VR / mixed reality (MR) devices and may be implemented in the form of head-mounted devices (HMDs) and head-up displays (HUDs) mounted on vehicles, televisions, smartphones, computers, wearable devices, home appliances, digital signs, vehicles, robots, etc. Portable devices may include smartphones, smart pads, wearable devices (e.g., smartwatches or smart glasses), and computers (e.g., laptops). Home appliances may include TVs, refrigerators, and washing machines. IoT devices may include sensors and smart meters.

[0032] In this specification, wireless devices (100a to 100f) may be referred to as user equipment (UE). The UE may include, for example, a mobile phone, a smartphone, a laptop computer, a digital broadcasting terminal, a PDA (personal digital assistant), a PMP (portable multimedia player), a navigation system, a slate PC, a tablet PC, an ultrabook, a vehicle, a vehicle with autonomous driving capabilities, a connected car, a UAV, an AI module, a robot, an AR device, a VR device, an MR device, a hologram device, a public safety device, an MTC device, an IoT device, a medical device, a fintech device (or financial device), a security device, a weather / environment device, a 5G service-related device, or a device related to the Fourth Industrial Revolution.

[0033] For example, a UAV can be an aircraft that is not on board and is navigated by radio control signals.

[0034] For example, a VR device may include a device for implementing objects or backgrounds in a virtual environment. For example, an AR device may include a device that implements objects or backgrounds in a virtual world by connecting them to objects or backgrounds in a real world. For example, an MR device may include a device that implements objects or backgrounds in a virtual world by merging them with objects or backgrounds in a real world. For example, a holographic device may include a device for implementing a 360-degree stereoscopic image by recording and playing back stereoscopic information using the phenomenon of light interference that occurs when two laser lights called holograms meet.

[0035] For example, a public safety device may include an image relay device or an image device that can be worn on a user's body.

[0036] For example, MTC devices and IoT devices may be devices that do not require direct human intervention or operation. For instance, MTC devices and IoT devices may include smart meters, vending machines, thermometers, smart light bulbs, door locks, or various sensors.

[0037] For example, a medical device may be a device used for the purpose of diagnosing, treating, alleviating, curing, or preventing a disease. For example, a medical device may be a device used to diagnose, treat, alleviate, or correct an injury or damage. For example, a medical device may be a device used for the purpose of examining, replacing, or modifying a structure or function. For example, a medical device may be a device used for the purpose of regulating pregnancy. For example, a medical device may include a therapeutic device, a driving device, a (in vitro) diagnostic device, a hearing aid, or a surgical device.

[0038] For example, a security device may be a device installed to prevent potential risks and maintain safety. For example, a security device may be a camera, closed-circuit TV (CCTV), a recorder, or a black box.

[0039] For example, a fintech device may be a device capable of providing financial services such as mobile payments. For example, a fintech device may include a payment device or a POS system.

[0040] For example, a weather / environment device may include a device for monitoring or predicting the weather / environment.

[0041] Wireless devices (100a to 100f) can be connected to a network (300) through a base station (200). AI technology may be applied to the wireless devices (100a to 100f), and the wireless devices (100a to 100f) can be connected to an AI server (400) through the network (300). The network (300) can be configured using a 3G network, a 4G (e.g., LTE) network, a 5G (e.g., NR) network, and a network after 5G. The wireless devices (100a to 100f) may communicate with each other through the base station (200) / network (300), but they may also communicate directly (e.g., sidelink communication) without going through the base station (200) / network (300). For example, vehicles (100b-1, 100b-2) can communicate directly (e.g., V2V (vehicle-to-vehicle) / V2X (vehicle-to-everything) communication). Also, IoT devices (e.g., sensors) can communicate directly with other IoT devices (e.g., sensors) or other wireless devices (100a to 100f).

[0042] Wireless communication / connections (150a, 150b, 150c) can be established between wireless devices (100a to 100f) and / or between wireless devices (100a to 100f) and base station (200) and / or between base station (200). Here, the wireless communication / connections can be established through various RATs (e.g., 5G NR), such as uplink / downlink communication (150a), sidelink communication (150b) (or D2D (device-to-device) communication), and communication between base stations (150c) (e.g., relay, IAB (integrated access and backhaul)). Through the wireless communication / connections (150a, 150b, 150c), wireless devices (100a to 100f) and base station (200) can transmit / receive wireless signals to / from each other. For example, wireless communication / connection (150a, 150b, 150c) may transmit / receive signals through various physical channels. To this end, based on various proposals in this specification, at least some of the following may be performed: a process for setting various configuration information for transmitting / receiving wireless signals, a process for various signal processing (e.g., channel encoding / decoding, modulation / demodulation, resource mapping / demapping, etc.), and a resource allocation process.

[0043] AI refers to the field of researching artificial intelligence or the methodologies to create it, while machine learning refers to the field of researching methodologies to define and solve various problems within the realm of artificial intelligence. Machine learning is also defined as an algorithm that improves performance on a task through continuous experience.

[0044] A robot can refer to a machine that automatically processes or operates given tasks based on its own capabilities. In particular, a robot equipped with the ability to perceive its environment, make independent judgments, and perform actions can be called an intelligent robot. Robots can be classified into industrial, medical, domestic, and military types depending on their purpose or field of use. Robots are equipped with drive units, including actuators or motors, to perform various physical movements, such as moving robot joints. Additionally, mobile robots include wheels, brakes, propellers, etc., in their drive units, enabling them to drive on the ground or fly in the air.

[0045] Autonomous driving refers to technology that drives itself, and an autonomous vehicle refers to a vehicle that drives without user intervention or with minimal user intervention. For example, autonomous driving can include technologies such as maintaining the driving lane, automatically adjusting speed like adaptive cruise control, driving automatically along a predetermined route, and automatically setting a route and driving once a destination is set. The term "vehicle" encompasses vehicles equipped solely with internal combustion engines, hybrid vehicles equipped with both internal combustion engines and electric motors, and electric vehicles equipped solely with electric motors; it can include not only automobiles but also trains and motorcycles. An autonomous vehicle can be viewed as a robot equipped with autonomous driving capabilities.

[0046] Augmented Reality is a collective term for VR, AR, and MR. VR technology provides real-world objects or backgrounds solely as CG images, AR technology provides virtual CG images superimposed on images of real objects, and MR technology is a CG technology that mixes and combines virtual objects with the real world. MR technology is similar to AR technology in that it displays real-world and virtual objects together. However, there is a difference in that while virtual objects in AR technology are used to complement real-world objects, virtual and real objects in MR technology are used as equal entities.

[0047] NR supports multiple numerologies or subcarrier spacings (SCS) to support various 5G services. For example, when the SCS is 15 kHz, it supports a wide area in traditional cellular bands; when the SCS is 30 kHz / 60 kHz, it supports dense-urban areas, lower latency, and wider carrier bandwidth; and when the SCS is 60 kHz or higher, it supports a bandwidth greater than 24.25 GHz to overcome phase noise.

[0048] The NR frequency band can be defined by two types of frequency ranges (FR1, FR2). The numerical values ​​of the frequency ranges may change. For example, the two types of frequency ranges (FR1, FR2) may be as shown in Table 1 below. For convenience of explanation, among the frequency ranges used in the NR system, FR1 may mean "sub 6GHz range" and FR2 may mean "above 6GHz range" and may be referred to as millimeter wave (mmW).

[0049] Frequency range definition Frequency range Subcarrier spacing FR1 450MHz - 6000MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240kHz

[0050] As described above, the numerical values ​​of the frequency range of the NR system may change. For example, FR1 may include a band of 410 MHz to 7125 MHz as shown in Table 2 below. That is, FR1 may include a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher. For example, the frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher included within FR1 may include an unlicensed band. The unlicensed band may be used for various purposes, for example, for communication for vehicles (e.g., autonomous driving).

[0051] Frequency range definition Frequency range Subcarrier spacing FR1 410MHz - 7125MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240kHz

[0052] Here, the wireless communication technology implemented in the wireless device of this specification may include LTE, NR, and 6G, as well as narrowband IoT (NB-IoT) for low-power communication. For example, NB-IoT technology may be an example of low-power wide-area network (LPWAN) technology and may be implemented according to standards such as LTE Cat NB1 and / or LTE Cat NB2, but is not limited to the names mentioned above. Additionally, or generally, the wireless communication technology implemented in the wireless device of this specification may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names such as enhanced MTC (eMTC). For example, LTE-M technology may be implemented in at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-bandwidth limited), 5) LTE-MTC, 6) LTE MTC, and / or 7) LTE M, and is not limited to the names mentioned above. Additionally or generally, wireless communication technology implemented in the wireless device of this specification may include at least one of ZigBee, Bluetooth, and / or LPWAN for low-power communication, and is not limited to the names mentioned above. For example, ZigBee technology may create personal area networks (PANs) related to small / low-power digital communication based on various standards such as IEEE 802.15.4, and may be referred to by various names.

[0053] FIG. 2 shows an example of a wireless device to which the implementation of the present specification applies.

[0054] Referring to FIG. 2, the first wireless device (100) and the second wireless device (200) can transmit and receive wireless signals to / from an external device via various RATs (e.g., LTE and NR).

[0055] In FIG. 2, {the first wireless device (100) and the second wireless device (200)} may correspond to at least one of the {wireless devices (100a~100f) and base station (200)}, {wireless devices (100a~100f) and wireless devices (100a~100f)} and / or {base station (200) and base station (200)} of FIG. 1.

[0056] The first wireless device (100) may include at least one transceiver such as a transceiver (106), at least one processing chip such as a processing chip (101), and / or one or more antennas (108).

[0057] The processing chip (101) may include at least one processor, such as a processor (102), and at least one memory, such as a memory (104). FIG. 2 is shown as an example in which the memory (104) is included in the processing chip (101). Additionally and / or generally, the memory (104) may be placed outside the processing chip (101).

[0058] The processor (102) can control the memory (104) and / or the transceiver (106) and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein. For example, the processor (102) may process information within the memory (104) to generate a first information / signal and transmit a wireless signal containing the first information / signal through the transceiver (106). The processor (102) may receive a wireless signal containing a second information / signal through the transceiver (106) and process the second information / signal to store the obtained information in the memory (104).

[0059] Memory (104) may be connected to the processor (102) so as to be operable. Memory (104) may store various types of information and / or instructions. Memory (104) may store software code (105) that implements instructions to perform descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification when executed by the processor (102). For example, software code (105) may implement instructions to perform descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification when executed by the processor (102). For example, software code (105) may control the processor (102) to perform one or more protocols. For example, software code (105) may control the processor (102) to perform one or more wireless interface protocol layers.

[0060] Here, the processor (102) and memory (104) may be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). A transceiver (106) may be connected to the processor (102) and may transmit and / or receive a wireless signal through one or more antennas (108). Each transceiver (106) may include a transmitter and / or receiver. The transceiver (106) may be interchangeably used with an RF (radio frequency) unit. In this specification, the first wireless device (100) may represent a communication modem / circuit / chip.

[0061] The second wireless device (200) may include at least one transceiver such as a transceiver (206), at least one processing chip such as a processing chip (201), and / or one or more antennas (208).

[0062] The processing chip (201) may include at least one processor, such as a processor (202), and at least one memory, such as a memory (204). FIG. 2 is shown as an example in which the memory (204) is included in the processing chip (201). Additionally and / or alternatively, the memory (204) may be placed outside the processing chip (201).

[0063] The processor (202) can control the memory (204) and / or the transceiver (206) and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein. For example, the processor (202) may process information within the memory (204) to generate a third information / signal and transmit a wireless signal containing the third information / signal through the transceiver (206). The processor (202) may receive a wireless signal containing a fourth information / signal through the transceiver (206) and process the fourth information / signal to store the obtained information in the memory (204).

[0064] Memory (204) may be connected to the processor (202) so as to be operable. Memory (204) may store various types of information and / or instructions. Memory (204) may store software code (205) that implements instructions to perform descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification when executed by the processor (202). For example, software code (205) may implement instructions to perform descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification when executed by the processor (202). For example, software code (205) may control the processor (202) to perform one or more protocols. For example, software code (205) may control the processor (202) to perform one or more wireless interface protocol layers.

[0065] Here, the processor (202) and memory (204) may be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). A transceiver (206) may be connected to the processor (202) and transmit and / or receive a wireless signal through one or more antennas (208). Each transceiver (206) may include a transmitter and / or receiver. The transceiver (206) may be interchangeably used with an RF unit. In this specification, the second wireless device (200) may represent a communication modem / circuit / chip.

[0066] Hereinafter, hardware elements of the wireless device (100, 200) will be described in more detail. Although not limited thereto, one or more protocol layers may be implemented by one or more processors (102, 202). For example, one or more processors (102, 202) may implement one or more layers (e.g., functional layers such as a PHY (physical) layer, a MAC (media access control) layer, a RLC (radio link control) layer, a PDCP (packet data convergence protocol) layer, a RRC (radio resource control) layer, and an SDAP (service data adaptation protocol) layer). One or more processors (102, 202) may generate one or more PDUs (protocol data units) and / or one or more SDUs (service data units) according to the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification. One or more processors (102, 202) may generate messages, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification. One or more processors (102, 202) may generate a signal (e.g., baseband signal) containing a PDU, SDU, message, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification and provide it to one or more transceivers (106, 206). One or more processors (102, 202) may receive a signal (e.g., baseband signal) from one or more transceivers (106, 206) and may obtain a PDU, SDU, message, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification.

[0067] One or more processors (102, 202) may be referred to as controllers, microcontrollers, microprocessors, and / or microcomputers. One or more processors (102, 202) may be implemented by hardware, firmware, software, and / or a combination thereof. For example, one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more digital signal processing devices (DSPDs), one or more programmable logic devices (PLDs), and / or one or more field programmable gate arrays (FPGAs) may be included in one or more processors (102, 202). Descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein may be implemented using firmware and / or software, and the firmware and / or software may be implemented to include modules, procedures, and functions. Firmware or software configured to perform the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification may be included in one or more processors (102, 202) or stored in one or more memories (104, 204) and driven by one or more processors (102, 202). The descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification may be implemented using firmware or software in the form of code, instructions, and / or sets of instructions.

[0068] One or more memories (104, 204) may be connected to one or more processors (102, 202) and may store various forms of data, signals, messages, information, programs, codes, instructions, and / or commands. One or more memories (104, 204) may consist of read-only memory (ROM), random access memory (RAM), erasable programmable ROM (EPROM), flash memory, hard drives, registers, cache memory, computer read storage media, and / or combinations thereof. One or more memories (104, 204) may be located inside and / or outside of one or more processors (102, 202). Additionally, one or more memories (104, 204) may be connected to one or more processors (102, 202) through various technologies such as wired or wireless connections.

[0069] One or more transceivers (106, 206) may transmit user data, control information, wireless signals / channels, etc., as described in the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification to one or more other devices. One or more transceivers (106, 206) may receive user data, control information, wireless signals / channels, etc., as described in the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification from one or more other devices. For example, one or more transceivers (106, 206) may be connected to one or more processors (102, 202) and may transmit and receive wireless signals. For example, one or more processors (102, 202) may control one or more transceivers (106, 206) to transmit user data, control information, wireless signals, etc., to one or more other devices. Additionally, one or more processors (102, 202) can control one or more transceivers (106, 206) to receive user data, control information, wireless signals, etc. from one or more other devices.

[0070] One or more transceivers (106, 206) may be connected to one or more antennas (108, 208). One or more transceivers (106, 206) may be configured to transmit and receive user data, control information, wireless signals / channels, etc., as described in the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein through one or more antennas (108, 208). In this specification, one or more antennas (108, 208) may be a plurality of physical antennas or a plurality of logical antennas (e.g., antenna ports).

[0071] One or more transceivers (106, 206) can convert received user data, control information, wireless signals / channels, etc. from RF band signals to baseband signals in order to process received user data, control information, wireless signals / channels, etc. using one or more processors (102, 202). One or more transceivers (106, 206) can convert processed user data, control information, wireless signals / channels, etc. from baseband signals to RF band signals using one or more processors (102, 202). To this end, one or more transceivers (106, 206) may include (analog) oscillators and / or filters. For example, one or more transceivers (106, 206) can up-convert an OFDM baseband signal into an OFDM signal through an (analog) oscillator and / or filter under the control of one or more processors (102, 202) and transmit the up-converted OFDM signal at a carrier frequency. One or more transceivers (106, 206) can receive an OFDM signal at a carrier frequency and down-convert the OFDM signal into an OFDM baseband signal through an (analog) oscillator and / or filter under the control of one or more processors (102, 202).

[0072] In an implementation of this specification, the UE may operate as a transmitting device in the uplink (UL; uplink) and as a receiving device in the downlink (DL; downlink). In an implementation of this specification, the base station may operate as a receiving device in the UL and as a transmitting device in the DL. For technical convenience, it is generally assumed that the first wireless device (100) operates as a UE and the second wireless device (200) operates as a base station. For example, a processor (102) connected to, mounted on, or released to the first wireless device (100) may be configured to perform UE operations according to an implementation of this specification or to control a transceiver (106) to perform UE operations according to an implementation of this specification. A processor (202) connected to, mounted on, or released to the second wireless device (200) may be configured to perform base station operations according to an implementation of this specification or to control a transceiver (206) to perform base station operations according to an implementation of this specification.

[0073] In this specification, the base station may be referred to as Node B, eNode B, or gNB.

[0074] FIG. 3 shows an example of a wireless device to which the implementation of the present specification applies.

[0075] Wireless devices can be implemented in various forms depending on the use example / service (see FIG. 1).

[0076] Referring to FIG. 3, the wireless device (100, 200) may correspond to the wireless device (100, 200) of FIG. 2 and may be composed of various components, devices / parts and / or modules. For example, each wireless device (100, 200) may include a communication device (110), a control device (120), a memory device (130), and additional components (140). The communication device (110) may include a communication circuit (112) and a transceiver (114). For example, the communication circuit (112) may include one or more processors (102, 202) of FIG. 2 and / or one or more memories (104, 204) of FIG. 2. For example, the transceiver (114) may include one or more transceivers (106, 206) of FIG. 2 and / or one or more antennas (108, 208) of FIG. 2. The control unit (120) is electrically connected to the communication device (110), the memory device (130), and the additional component (140) and controls the overall operation of each wireless device (100, 200). For example, the control unit (120) may control the electrical / mechanical operation of each wireless device (100, 200) based on a program / code / command / information stored in the memory device (130). The control device (120) can transmit information stored in the memory device (130) to an external (e.g., other communication device) via the communication device (110) through a wireless / wired interface, or store information received from an external (e.g., other communication device) via the communication device (110) through a wireless / wired interface in the memory device (130).

[0077] The additional component (140) can be configured in various ways depending on the type of wireless device (100, 200). For example, the additional component (140) may include at least one of a power device / battery, an input / output (I / O) device (e.g., audio I / O port, video I / O port), a driving device, and a computing device. The wireless device (100, 200) may be implemented in the form of, but is not limited to, a robot (100a in FIG. 1), a vehicle (100b-1 and 100b-2 in FIG. 1), an XR device (100c in FIG. 1), a portable device (100d in FIG. 1), a home appliance (100e in FIG. 1), an IoT device (100f in FIG. 1), a digital broadcasting terminal, a hologram device, a public safety device, an MTC device, a medical device, a fintech device (or financial device), a security device, a climate / environment device, an AI server / device (400 in FIG. 1), a base station (200 in FIG. 1), or a network node. The wireless device (100, 200) may be used in a mobile or fixed location depending on the use example / service.

[0078] In FIG. 3, the entirety of the various components, devices / parts and / or modules of the wireless device (100, 200) may be connected to each other via a wired interface, or at least some of them may be connected wirelessly via a communication device (110). For example, in each wireless device (100, 200), the control device (120) and the communication device (110) may be connected via a wire, and the control device (120) and the first device (e.g., 130 and 140) may be connected wirelessly via the communication device (110). Each component, device / part and / or module within the wireless device (100, 200) may further include one or more elements. For example, the control device (120) may be composed of one or more sets of processors. As an example, the control device (120) may be composed of a set of a communication control processor, an application processor (AP), an electronic control unit (ECU), a graphics processing unit, and a memory control processor. As another example, the memory device (130) may be composed of RAM, DRAM, ROM, flash memory, volatile memory, non-volatile memory and / or a combination thereof.

[0079] FIG. 4 shows an example of a UE to which the implementation of the present specification applies.

[0080] Referring to FIG. 4, the UE (100) may correspond to the first wireless device (100) of FIG. 2 and / or the wireless device (100 or 200) of FIG. 3.

[0081] The UE (100) includes a processor (102), memory (104), transceiver (106), one or more antennas (108), a power management module (110), a battery (112), a display (114), a keypad (116), a SIM (subscriber identification module) card (118), a speaker (120), and a microphone (122).

[0082] The processor (102) may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein. The processor (102) may be configured to control one or more other components of the UE (100) to implement the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed herein. Layers of a wireless interface protocol may be implemented in the processor (102). The processor (102) may include an ASIC, other chipsets, logic circuits, and / or data processing devices. The processor (102) may be an application processor. The processor (102) may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). An example of the processor (102) is the SNAPDRAGON manufactured by Qualcomm®. TM Series processor, EXYNOS made by Samsung® TM Series processors, A Series processors made by Apple®, HELIO made by MediaTek® TM Series processors, ATOM made by Intel® TM It can be found in series processors or corresponding next-generation processors.

[0083] Memory (104) is coupled to the processor (102) so as to be operable and stores various information for operating the processor (102). Memory (104) may include ROM, RAM, flash memory, memory card, storage medium and / or other storage device. When the implementation is implemented in software, the technology described herein may be implemented using modules (e.g., procedures, functions, etc.) that perform the descriptions, functions, procedures, proposals, methods and / or operation flowcharts disclosed herein. Modules may be stored in memory (104) and executed by the processor (102). Memory (104) may be implemented within the processor (102) or outside the processor (102), in which case it may be communicatively coupled to the processor (102) through various methods known in the technology.

[0084] A transceiver (106) is coupled to operate with a processor (102) and transmits and / or receives a wireless signal. The transceiver (106) includes a transmitter and a receiver. The transceiver (106) may include a baseband circuit for processing a wireless frequency signal. The transceiver (106) controls one or more antennas (108) to transmit and / or receive a wireless signal.

[0085] The power management module (110) manages the power of the processor (102) and / or the transceiver (106). The battery (112) supplies power to the power management module (110).

[0086] The display (114) outputs the result processed by the processor (102). The keypad (116) receives input to be used by the processor (102). The keypad (116) can be displayed on the display (114).

[0087] A SIM card (118) is an integrated circuit for securely storing an IMSI (international mobile subscriber identity) and associated keys, and is used to identify and authenticate a subscriber in a mobile device such as a mobile phone or computer. Additionally, contact information can be stored on many SIM cards.

[0088] The speaker (120) outputs sound-related results processed by the processor (102). The microphone (122) receives sound-related input to be used by the processor (102).

[0089] FIG. 5 shows an example of a 5G system architecture to which the implementation of the present specification is applied.

[0090] The 5G system (5GS) structure consists of the following network functions (NF).

[0091] - AUSF (Authentication Server Function)

[0092] -AMF (Access and Mobility Management Function)

[0093] - DN (Data Network), for example, operator services, internet access, or third-party services

[0094] - USDF (Unstructured Data Storage Function)

[0095] - NEF (Network Exposure Function)

[0096] - I-NEF (Intermediate NEF)

[0097] - NRF (Network Repository Function)

[0098] - NSSF (Network Slice Selection Function)

[0099] - PCF (Policy Control Function)

[0100] - SMF (Session Management Function)

[0101] - UDM (Unified Data Management)

[0102] - UDR (Unified Data Repository)

[0103] - UPF (User Plane Function)

[0104] - UCMF (UE radio Capability Management Function)

[0105] - AF (Application Function)

[0106] - UE (User Equipment)

[0107] - (R)AN ((Radio) Access Network)

[0108] - 5G-EIR (5G-Equipment Identity Register)

[0109] - NWDAF (Network Data Analytics Function)

[0110] - CHF (CHarging Function)

[0111] 또한, 다음과 같은 네트워크 기능이 고려될 수 있다.

[0112] - N3IWF (Non-3GPP InterWorking Function)

[0113] - TNGF (Trusted Non-3GPP Gateway Function)

[0114] - W-AGF (Wireline Access Gateway Function)

[0115] Figure 5 shows the 5G system structure in a non-roaming case using a reference point representation that shows how various network functions interact with each other.

[0116] In Fig. 5, for clarity of the point-to-point diagram, UDSF, NEF, and NRF are not described. However, all network functions shown can interact with UDSF, UDR, NEF, and NRF as needed.

[0117] For clarity, the connection between UDR and other NFs (e.g., PCF) is not shown in FIG. 5. For clarity, the connection between NWDAF and other NFs (e.g., PCF) is not shown in FIG. 5.

[0118] The 5G system structure includes the following reference points.

[0119] - N1: Reference point between UE and AMF.

[0120] - N2: Reference point between (R)AN and AMF.

[0121] - N3: Reference point between (R)AN and UPF.

[0122] - N4: Reference point between SMF and UPF.

[0123] - N6: Reference point between the UPF and the data network.

[0124] - N9: Reference point between two UPFs.

[0125] The following reference points show the interactions that exist between the NF services of NF.

[0126] - N5: Reference point between PCF and AF.

[0127] - N7: Reference point between SMF and PCF.

[0128] - N8: Reference point between UDM and AMF.

[0129] - N10: Reference point between UDM and SMF.

[0130] - N11: Reference point between AMF and SMF.

[0131] - N12: Reference point between AMF and AUSF.

[0132] - N13: Reference point between UDM and AUSF.

[0133] - N14: Reference point between two AMFs.

[0134] - N15: Reference point between PCF and AMF for non-roaming scenarios, reference point between PCF and AMF of the visited network for roaming scenarios.

[0135] - N16: Reference point between two SMFs (in the case of roaming, between the SMF of the visited network and the SMF of the home network)

[0136] - N22: Reference point between AMF and NSSF.

[0137] In some cases, two NFs may need to be connected to each other to service the UE.

[0138] The registration procedure is described. Refer to Section 4.2.2.2 of 3GPP TS 23.502 V16.3.0 (2019-12).

[0139] FIGS. 6 and FIGS. 7 illustrate examples of registration procedures to which the implementation of the present specification applies.

[0140] The UE must register with the network to receive services, enable mobility tracking, and enable reachability. The UE initiates the registration process using one of the following registration types.

[0141] - Initial registration for the 5GS; or

[0142] - Mobility registration update; or

[0143] - Periodic registration update; or

[0144] - Emergency registration

[0145] The general registration procedure of Figures 6 and 7 applies to all registration procedures described above, but the periodic registration update does not need to include all parameters used in other registration procedures.

[0146] The general registration procedure of Figures 6 and 7 is used when a UE is registered to a 3GPP connection when it is already registered to a non-3GPP connection, and vice versa. To register a UE to a 3GPP connection when it is already registered to a non-3GPP connection scenario, an AMF change may be required.

[0147] First, the procedure of Fig. 6 is explained.

[0148] (1) Step 1: The UE sends a Registration Request message to the (R)AN. The Registration Request message corresponds to the AN message.

[0149] A registration request message may include AN parameters. For NG-RAN, AN parameters include, for example, 5G-S-TMSI (5G SAE temporary mobile subscriber identity) or GUAMI (globally unique AMF ID), a selected PLMN (public land mobile network) ID (or PLMN ID and NID (network identifier)), and requested NSSAI (Requested network slice selection assistance information). AN parameters also include an establishment cause. The establishment cause provides the reason for requesting the establishment of an RRC connection. Whether and how the UE includes the requested NSSAI as part of the AN parameters depends on the value of the access stratum connection establishment NSSAI inclusion mode parameter.

[0150] The registration request message may include a registration type. The registration type indicates whether the UE wants to perform an initial registration (i.e., the UE is in the RM-DEREGISTERED state), or a mobility registration update (i.e., the UE is in the RM-REGISTERED state and initiates the registration process because the UE moves, or the UE wants to update capabilities or protocol parameters, or requests a change to the set of network slices allowed for the UE to use), or a periodic registration update (i.e., the UE is in the RM-REGISTERED state and initiates the registration process due to the expiration of the periodic registration update timer), or an urgent registration (i.e., the UE is in the restricted service state).

[0151] When a UE performs initial registration, the UE specifies the UE ID in the registration request message as follows, listed in order of decreasing priority.

[0152] i) If the UE has a valid EPS (evolved packet system) GUTI (globally unique temporary identifier), the 5G-GUTI mapped from the EPS GUTI;

[0153] ii) Native 5G-GUTI assigned by the PLMN for which the UE is attempting to register (if available);

[0154] iii) Native 5G-GUTI assigned by a PLMN equivalent to the PLMN for which the UE is attempting to register;

[0155] iv) Native 5G-GUTI assigned by other PLMNs (if available);

[0156] v) Otherwise, the UE includes SUCI (subscriber concealed identifier) ​​in the registration request message.

[0157] If the UE performing the initial registration has both a valid EPS GUTI and a native 5G-GUTI, the UE also marks the native 5G-GUTI as an additional GUTI. If one or more native 5G-GUTIs are available, the UE selects the 5G-GUTIs from items (ii)-(iv) in the list above in decreasing order of priority.

[0158] When the UE performs initial registration with native 5G-GUTI, the UE displays relevant GUAMI information in AN parameters. When the UE performs initial registration with SUCI, the UE does not display GUAMI information in AN parameters.

[0159] In the case of emergency registration, SUCI is included if the UE does not have a valid 5G-GUTI, and PEI is included if the UE does not have a SUPI (subscriber permanent identifier) ​​and does not have a valid 5G-GUTI. In other cases, a 5G-GUTI is included, which indicates the last serving AMF.

[0160] The registration request message may also include security parameters, PDU session status, etc. Security parameters are used for authentication and integrity protection. The PDU session status indicates a previously established PDU session in the UE. When the UE is connected to two AMFs belonging to different PLMNs via a 3GPP connection and a non-3GPP connection, the PDU session status indicates the established PDU session of the current PLMN in the UE.

[0161] (2) Step 2: (R)AN selects AMF.

[0162] If 5G-S-TMSI or GUAMI is not included, or if 5G-S-TMSI or GUAMI does not represent a valid AMF, (R)AN selects an AMF based on (R)AT and the requested NSSAI, if available.

[0163] If the UE is in the CM-CONNECTED state, (R)AN can forward a registration request message to the AMF based on the UE's N2 connection.

[0164] If (R)AN cannot select a suitable AMF, (R)AN performs AMF selection by forwarding a registration request message to the AMF configured in (R)AN.

[0165] (3) Step 3: (R)AN sends a registration request message to the new AMF. The registration request message corresponds to the N2 message.

[0166] The registration request message may include all information and / or part of the information contained in the registration request message received from the UE described in Step 1.

[0167] The registration request message may include N2 parameters. When NG-RAN is used, the N2 parameters include the selected PLMN ID (or PLMN ID and NID), location information and cell ID associated with the cell where the UE is camping, and a UE context request indicating that a UE context including security information in NG-RAN must be established. When NG-RAN is used, the N2 parameters also include the cause for establishment.

[0168] If the registration type indicated by the UE is a periodic registration update, steps 4-19 described below may be omitted.

[0169] (4) Step 4: If the UE's 5G-GUTI is included in the registration request message and the serving AMF has changed since the last registration procedure, the new AMF may call the Namf_Communication_UEContextTransfer service operation on the previous AMF, including the full registration request NAS (non-access stratum) message to request the UE's SUPI and UE context.

[0170] (5) Step 5: The previous AMF can respond to the new AMF for the Namf_Communication_UEContextTransfer call, including the UE's SUPI and UE context.

[0171] (6) Step 6: If SUCI is not provided by the UE or is not retrieved from the previous AMF, the new AMF may initiate the identity request procedure by sending an identity request message to the UE to request SUCI.

[0172] (7) Step 7: The UE may respond with an Identity Response message containing SUCI. The UE derives SUCI using the provided public key of the home PLMN (HPLMN).

[0173] (8) Step 8: The new AMF may decide to call AUSF to initiate UE authentication. In this case, the new AMF selects AUSF based on SUPI or SUCI.

[0174] (9) Step 9: Authentication / security may be established by UE, new AMF, AUSF and / or UDM.

[0175] (10) Step 10: If the AMF is changed, the new AMF may call the Namf_Communication_RegistrationCompleteNotify service operation to notify the previous AMF that UE registration is complete for the new AMF. If the authentication / security procedure fails, registration is rejected and the new AMF may call the Namf_Communication_RegistrationCompleteNotify service operation with a reject indication reason code for the previous AMF. The previous AMF may continue as if no UE context passing service operation was received.

[0176] (11) Step 11: If the PEI is not provided by the UE or has not been retrieved from the previous AMF, the new AMF may initiate an Identity Request procedure by sending an Identity Request message to the UE to retrieve the PEI. The PEI is transmitted in encryption, except in cases where the UE cannot perform emergency registration and be authenticated.

[0177] (12) Step 12: Optionally, the new AMF can call the N5g-eir_EquipmentIdentityCheck_Get service operation to start ME ID checking.

[0178] Now, the procedure of Fig. 7 following the procedure of Fig. 6 is explained.

[0179] (13) Step 13: If you perform Step 14 below, the new AMF can select a UDM based on SUPI, and the UDM can select a UDR instance.

[0180] (14) Step 14: New AMFs can be registered with UDM.

[0181] (15) Step 15: The new AMF can select PCF.

[0182] (16) Step 16: The new AMF may optionally establish / modify AM policy associations.

[0183] (17) Step 17: The new AMF can send update / release SM context messages (e.g., Nsmf_PDUSession_UpdateSMContext and / or Nsmf_PDUSession_ReleaseSMContext) to the SMF.

[0184] (18) Step 18: If the new AMF and the previous AMF are in the same PLMN, the new AMF can send a request to modify the UE context to N3IWF / TNGF / W-AGF.

[0185] (19) Step 19: N3IWF / TNGF / W-AGF can send a UE context modification response to the new AMF.

[0186] (20) Step 20: After the new AMF receives a response message from N3IWF / TNGF / W-AGF in Step 19, the new AMF can register with UDM.

[0187] (21) Step 21: The new AMF sends a Registration Accept message to the UE.

[0188] The new AMF sends a registration acceptance message to the UE indicating that the registration request has been accepted. If the new AMF assigns a new 5G-GUTI, the 5G-GUTI is included. If the UE is already in the RM-REGISTERED state via another connection on the same PLMN, the UE uses the 5G-GUTI received in the registration acceptance message for both registrations. If the registration acceptance message does not include a 5G-GUTI, the UE uses the 5G-GUTI assigned to the existing registration for the new registration as well. If the new AMF assigns a new registration area, it transmits the registration area to the UE via the registration acceptance message. If the registration acceptance message does not contain a registration area, the UE considers the previous registration area to be valid. Mobility Restrictions are included when mobility restrictions apply to the UE and the registration type is not an urgent registration. The new AMF indicates the PDU session established for the UE in the PDU session state. The UE locally removes internal resources associated with PDU sessions that are not marked as established in the received PDU session state. When a UE connects to two AMFs belonging to different PLMNs via a 3GPP connection and a non-3GPP connection, the UE locally removes internal resources associated with the PDU session of the current PLMN that are not indicated as established in the received PDU session state. If PDU session state information is present in the registration acceptance message, the new AMF instructs the UE on the PDU session state.

[0189] The Allowed NSSAI provided in the registration acceptance message is valid in the registration area and applies to all PLMNs having a tracking area included in the registration area. The Mapping of Allowed NSSAI is to map the HPLMN S-NSSAI to each S-NSSAI of the Allowed NSSAI. The Mapping of Configured NSSAI is to map the HPLMN S-NSSAI to each S-NSSAI of the Configured NSSAI for the serving PLMN.

[0190] Additionally, the new AMF optionally performs UE policy association establishment.

[0191] (22) Step 22: If the UE succeeds in updating itself, it can send a Registration Complete message to the new AMF.

[0192] The UE can send a registration completion message to the new AMF to check if a new 5G-GUTI has been assigned.

[0193] (23) Step 23: In the case of registration via a 3GPP connection, if the new AMF does not release the signaling connection, the new AMF may send RRC Inactive Assistance information to the NG-RAN. In the case of registration via a non-3GPP connection, if the UE is in a CM-CONTENED state on the 3GPP connection, the new AMF may send RRC Inactive Assistance information to the NG-RAN.

[0194] (24) Step 24: AMF can perform information updates on UDM.

[0195] (25) Step 25: The UE can execute network slice-specific authentication and authorization procedures.

[0196] The procedure for establishing a PDU session is described. Refer to Section 4.3.2 of 3GPP TS 23.502 V16.3.0 (2019-12).

[0197] FIGS. 8 and 9 illustrate examples of PDU session establishment procedures to which the implementation of the present specification applies.

[0198] PDU session establishment may fall under the following:

[0199] - Procedure for establishing a PDU session initiated by the UE

[0200] - PDU session handover between 3GPP and non-3GPP initiated by the UE

[0201] - PDU session handover from EPS initiated by UE to 5GS.

[0202] - Procedure for establishing a PDU session triggered by the network

[0203] A PDU session may (a) be associated with a single access type at any given time, namely either a 3GPP access or a non-3GPP access, or (b) be associated with multiple access types simultaneously, namely one 3GPP access and one non-3GPP access. A PDU session associated with multiple access types is called a multi-access (MA) PDU session and may be requested by an access traffic steering, switching, splitting (ATSS) enabled UE.

[0204] Figures 8 and 9 specify a procedure for establishing a PDU session associated with a single connection type at a given time.

[0205] In the procedure shown in Figures 8 and 9, since the UE is already registered with the AMF, it is assumed that the AMF has already retrieved user subscription data from the UDM unless the UE is urgently registered.

[0206] First, the procedure of Fig. 8 will be explained.

[0207] (1) Step 1: To establish a new PDU session, the UE generates a new PDU session ID.

[0208] The UE initiates the PDU session establishment procedure requested by the UE by transmitting a NAS message containing a PDU session establishment request message within an N1 SM container. The PDU session establishment request message includes a PDU session ID, a requested PDU session type, a requested session and service continuity (SSC) mode, 5G SM capabilities, Protocol Configuration Options (PCO), an SM PDU DN Request Container, and a UE Integrity Protection Maximum Data Rate.

[0209] If the PDU session establishment is a request to establish a new PDU session, the request type indicates "Initial Request". If the request refers to an existing PDU session transitioning between a 3GPP connection and a non-3GPP connection, or a PDU session handover from an existing PDN (packet data network) connection in the EPC, the request type indicates "Existing PDU Session". If the PDU session establishment is a request to establish a PDU session for an emergency service, the request type indicates "Emergency Request". If the request refers to an existing PDU session for an emergency service transitioning between a 3GPP connection and a non-3GPP connection, or a PDU session handover from an existing PDN connection for an emergency service in the EPC, the request type indicates "Existing Emergency PDU Session".

[0210] The UE includes an S-NSSAI from the allowed NSSAI of the current connection type. If a Mapping of Allowed NSSAI is provided to the UE, the UE provides both the S-NSSAI of the visited VPLMN from the allowed NSSAI and the corresponding S-NSSAI of the HPLMN from the mapping of the allowed NSSAI.

[0211] (2) Step 2: The AMF selects an SMF. If the request type indicates an "initial request" or if the request is due to a handover from a non-3GPP connection provided by an EPS or another AMF, the AMF stores the connection type of the PDU session, as well as the association of the S-NSSAI(s), the DNN (data network name), the PDU session ID, and the SMF ID.

[0212] If the request type is "Initial Request" and the message also includes a previous PDU session ID representing an existing PDU session, the AMF selects an SMF and saves the new PDU session ID, S-NSAI(s), and the association of the selected SMF ID.

[0213] If the request type indicates an "existing PDU session," the AMF selects an SMF based on the SMF-ID received from the UDM. The AMF updates the connection type stored for the PDU session.

[0214] If the request type indicates an "existing PDU session" that refers to an existing PDU session moving between a 3GPP connection and a non-3GPP connection, and the serving PLMN S-NSSAI of the PDU session exists in the allowed NSSAI of the target connection type, the PDU session establishment procedure may be performed in the following cases.

[0215] - If the SMF ID corresponding to the PDU session ID and the AMF belong to the same PLMN;

[0216] - If the SMF ID corresponding to the PDU session ID belongs to the HPLMN;

[0217] Otherwise, the AMF rejects the request to establish a PDU session with an appropriate reason for rejection.

[0218] AMF rejects requests from urgently registered UEs where the request type does not indicate "Urgent Request" or "Existing Urgent PDU Session".

[0219] (3) Step 3: If the AMF is not associated with an SMF for a PDU session ID provided by the UE (e.g., when the request type indicates "initial request"), the AMF calls the Create SMContext request procedure (e.g., Nsmf_PDUSession_CreateSMContext Request). If the AMF is already associated with an SMF for a PDU session ID provided by the UE (e.g., when the request type indicates "existing PDU session"), the AMF calls the Update SMContext request procedure (e.g., Nsmf_PDUSession_UpdateSMContext Request).

[0220] The AMF transmits the S-NSSAI of the serving PLMN from the allowed NSSAI to the SMF. For a local breakout (LBO) roaming scenario, the AMF also transmits the corresponding S-NSSAI of the HPLMN from the mapping of the allowed NSSAI to the SMF.

[0221] The AMF ID is the UE's GUAMI and uniquely identifies the AMF serving the UE. The AMF transmits the PDU Session ID along with an N1 SM container containing the PDU session establishment request message received from the UE. The generic public subscription identifier (GPSI) is included if available in the AMF.

[0222] If a UE in a restricted service state is registered for emergency services without providing a SUPI, the AMF provides a PEI instead of a SUPI. If a UE in a restricted service state is registered for emergency services while providing a SUPI but is not authenticated, the AMF indicates that the SUPI is not authenticated. If the SMF does not receive a SUPI from a UE or if the AMF indicates that the SUPI is not authenticated, the UE is determined to be unauthenticated.

[0223] AMF can include a PCF ID in Nsmf_PDUSession_CreateSMContext. This PCFID identifies the H-PCF (home PCF) in the non-roaming case and the V-PCF (visited PCF) in the LBO roaming case.

[0224] (4) Step 4: If session management subscription data for S-NSSAI of the corresponding SUPI, DNN, HPLMN is unavailable, SMF can retrieve the session management subscription data from UDM and be notified when this subscription data is modified.

[0225] (5) Step 5: SMF sends a create SM context response message (e.g., Nsmf_PDUSession_CreateSMContext Response) or an update SM context response message (e.g., Nsmf_PDUSession_UpdateSMContext Response) to AMF in accordance with the request received in Step 3.

[0226] If SMF receives the Nsmf_PDUSession_CreateSMContext Request in step 3 and can process the PDU session establishment request, SMF creates an SM context and responds to AMF by providing the SM context ID.

[0227] If the SMF decides not to accept the establishment of a PDU session, the SMF rejects the UE request via a NAS SM signal containing the relevant SM rejection cause by responding to the AMF with an Nsmf_PDUSession_CreateSMContext Response. The SMF also indicates to the AMF that the PDU session ID is considered released and that the SMF proceeds to step 20 below and the PDU session establishment procedure is stopped.

[0228] (6) Step 6: Optional secondary authentication / authorization may be performed.

[0229] (7a) Step 7a: When dynamic policy and charging control (PCC) is used in a PDU session, the SMF can perform PCF selection.

[0230] (7b) Step 7b: SMF can establish an SM policy association with PCF and obtain a basic PCC rule for the PDU session by performing the SM policy association establishment procedure.

[0231] (8) Step 8: SMF selects one or more UPFs.

[0232] (9) Step 9: SMF can provide information about the satisfied policy control request trigger conditions by performing the SM policy association modification procedure initiated by SMF.

[0233] (10) Step 10: If the request type indicates an “initial request,” the SMF may initiate an N4 Session Establishment procedure with the selected UPF. Otherwise, the SMF may initiate an N4 Session Modification procedure with the selected UPF.

[0234] In step 10a, SMF can send an N4 session establishment / modification request to UPF and provide packet detection, enforcement, and reporting rules installed in UPF for the PDU session. In step 10b, UPF can confirm by sending an N4 session establishment / modification response.

[0235] (11) Step 11: SMF sends an N1N2 message transfer message (e.g., Namf_Communication_N1N2 Message Transfer) to AMF.

[0236] The N1N2 message delivery message may include N2 SM information. The N2 SM information carries the following information that the AMF will transmit to the (R)AN.

[0237] - CN Tunnel Info: Corresponds to the core network address of the N3 tunnel corresponding to the PDU session;

[0238] - QFI (QoS flow ID) corresponding to one or more QoS (quality of service) profiles;

[0239] - PDU Session ID: Indicates to the UE the association between the RAN resource and the PDU session for the UE;

[0240] - S-NSSAI with a value for the serving PLMN (i.e., HPLMN S-NSSAI, or VPLMN S-NSSAI in the case of LBO roaming);

[0241] - User plane security enforcement information determined by SMF;

[0242] - Maximum data rate for UE integrity protection received in PDU session establishment request message: When integrity protection is indicated as "Preferred" or "Required" in user plane security enforcement information

[0243] - RSN (redundancy sequence number) parameter

[0244] The N1N2 message delivery message may include an N1 SM container. The N1 SM container includes a PDU session establishment acceptance message that the AMF will provide to the UE. The PDU session establishment acceptance message includes an S-NSSAI from an allowed NSASI. In the case of an LBO roaming scenario, the PDU session establishment acceptance message includes an S-NSSAI from an allowed NSSAI for the VPLMN, and also includes the corresponding S-NSSAI for the HPLMN from the mapping of the allowed NSSAI received by the SMF in step 3.

[0245] If necessary for QoS flows related to QoS rules and QoS profiles, multiple QoS rules, QoS flow levels, and QoS parameters may be included in the PDU session establishment acceptance message and N2 SM information within the N1 SM container.

[0246] If PDU session establishment fails between steps 5 and 11, the N1N2 message delivery message contains an N1 SM container containing a PDU session establishment rejection message, but does not contain N2 SM information. (R)AN sends a NAS message containing a PDU session establishment rejection message to the UE. In this case, steps 12-17 below are omitted.

[0247] (12) Step 12: The AMF sends a NAS message containing a PDU session ID destined for the UE, a message accepting the establishment of a PDU session, and N2 SM information received from the SMF to (R)AN within the N2 PDU session request message.

[0248] (13) Step 13: (R)AN can perform AN-specific signal exchanges with the UE regarding information received from the SMF. For example, in the case of NG-RAN, it can perform RRC connection reconfiguration with the UE to set up necessary NG-RAN resources in relation to the QoS rules for the PDU session request received by the UE in Step 12.

[0249] (R)AN forwards the NAS message (PDU session ID, N1 SM container (PDU session establishment acceptance message)) received in step 12 to the UE. (R)AN provides the NAS message to the UE only if the AN-specific signal exchange with the UE includes the addition of (R)AN resources related to the received N2 command.

[0250] If N2 SM information is not included in step 11, steps 14–16b and step 17 below are omitted.

[0251] Now, the procedure of Fig. 9 following the procedure of Fig. 8 is explained.

[0252] (14) Step 14: (R)AN sends an N2 PDU session response message to AMF. The N2 PDU session response message may include a PDU session ID, cause, N2 SM information (PDU session ID, AN tunnel information, list of accepted / rejected QFIs, user plane enforcement policy notifications), etc.

[0253] (15) Step 15: AMF sends an update SM context request message (e.g., Nsmf_PDUSession_UpdateSMContext Request) to SMF. AMF forwards the N2 SM information received from (R)AN to SMF.

[0254] (16a) Step S16a: SMF initiates the N4 session modification procedure with UPF. SMF provides AN tunnel information and the corresponding forwarding rule to UPF.

[0255] (16b) Step S16b: UPF provides the N4 session modification response to SMF.

[0256] After this step, UPF can deliver the DL packet that may have been buffered for this PDU session to the UE.

[0257] (16c) Step 16c: If the SMF is not yet registered for this PDU session, the SMF can register with the UDM for the given PDU session.

[0258] (17) Step 17: SMF sends an update SM context response message (e.g., Nsmf_PDUSession_UpdateSMContext Response) to AMF.

[0259] After this step, AMF delivers the relevant events subscribed to by SMF.

[0260] (18) Step 18: At any time after Step 5, if the establishment of the PDU session fails during the procedure, the SMF may notify the AMF by calling Nsmf_PDUSession_SMContextStatusNotify (release). The SMF may also release the created N4 session, the assigned PDU session address (e.g., IP address), and, if possible, release the association with the PCF. In this case, Step 19 below is omitted.

[0261] (19) Step 19: For PDU session type IPv6 or IPv4v6, the SMF can generate an IPv6 Router Advertisement and send it to the UE.

[0262] (20) Step 20: SMF can perform SM policy association modifications initiated by SMF.

[0263] (21) Step 21: If the establishment of a PDU session fails after Step 4, and the SMF no longer processes the UE's PDU session, the SMF may unsubscribe from the modification of the session management subscription data.

[0264] Support for non-3GPP connections is described. Refer to Section 4.2.8.1 of 3GPP TS 23.501 V16.3.0 (2019-12).

[0265] FIG. 10 shows an example of a non-roaming architecture for a 5GC with an unreliable non-3GPP connection to which the implementation of the present specification applies.

[0266] The 5G core network supports the connection of UEs through non-3GPP access networks (e.g., WLAN (wireless local area network).

[0267] The 5G core network supports both untrusted non-3GPP access networks and trusted non-3GPP access networks (TNAN).

[0268] Untrusted non-3GPP access networks are connected to the 5G core network via N3IWF, whereas trusted non-3GPP access networks are connected to the 5G core network via TNFG. Both N3IWF and TNGF access the 5G core network CP function and UP function, respectively, through the N2 and N3 interfaces.

[0269] Non-3GPP access networks can advertise PLMNs that support trusted connections and supported trusted connection types (e.g., "5G connectivity"). Therefore, UEs can discover non-3GPP access networks that can provide trusted connections to one or more PLMNs.

[0270] If the UE decides to connect to the 5G core network in the PLMN using an untrusted non-3GPP connection:

[0271] - The UE first selects and connects to a non-3GPP access network, and then;

[0272] - The UE selects a PLMN, and from this PLMN, selects an N3IWF. The selection of the PLMN / N3IWF and the selection of a non-3GPP access network are independent.

[0273] If the UE decides to connect to the 5G core network in the PLMN using a trusted non-3GPP connection:

[0274] - The UE first selects the PLMN, then;

[0275] - The UE selects a non-3GPP access network (TNAN) that supports a trusted connection to the selected PLMN. In this case, the selection of the non-3GPP access network is influenced by the PLMN selection.

[0276] A UE connecting to a 5G core network via a standalone non-3GPP connection supports NAS signaling as a 5G core network control plane function using an N1 reference point after UE registration.

[0277] When a UE is connected via a standalone non-3GPP connection through NG-RAN, multiple N1 instances exist for the UE. That is, there is one N1 instance on the NG-RAN and one N1 instance on the non-3GPP connection.

[0278] UEs that are simultaneously connected to the same 5G core network of the PLMN via 3GPP access and non-3GPP access are served by a single AMF in this 5G core network.

[0279] When a UE connects to a 3GPP connection of a PLMN, if the UE selects an N3IWF and the N3IWF is located in a different PLMN than the PLMN of the 3GPP connection (e.g., a different VPLMN or HPLMN), the UE is served separately by the two PLMNs. The UE is registered with two separate AMFs. PDU sessions on the 3GPP connection are served by a V-SMF different from the V-SMF serving PDU sessions on the non-3GPP connection. The same may apply when the UE uses a trusted non-3GPP connection. That is, the UE can select one PLMN for the 3GPP connection and another PLMN for the trusted non-3GPP connection.

[0280] PLMN selection for 3GPP access does not depend on the PLMN used for non-3GPP access. That is, if a UE is registered with a PLMN through a non-3GPP access, the UE performs PLMN selection for 3GPP access independently of this PLMN.

[0281] The UE establishes an IPsec tunnel with the N3IWF or TNGF to register with the 5G core network via a non-3GPP connection.

[0282] After all PDU sessions for the UE on the non-3GPP connection are released or handed over to the 3GPP connection, it is possible to maintain the UE NAS signaling connection with the AMF through the non-3GPP connection.

[0283] N1 NAS signals over a standalone non-3GPP connection are protected by the same security mechanisms applied to N1 over a 3GPP connection.

[0284] SNPN (standalone non-public network) is described. Refer to Section 5.30.2 of 3GPP TS 23.501 V16.3.0 (2019-12).

[0285] SNPN is operated by NPN operators without relying on network functions provided by PLMNs. On the other hand, PNI (public network integrated) NPN is a non-public network deployed with the support of PLMNs.

[0286] The SNPN 5GS deployment is based on the structure described in FIG. 5 and the structure for 5GC having untrusted non-3GPP access described in FIG. 10, for access to SNPN services via PLMN (and vice versa) and additional functions to be described below.

[0287] SNPN does not support interaction with EPS.

[0288] The combination of PLMN ID and NID (network ID) identifies the SNPN.

[0289] NID supports the following two allocation models.

[0290] - Self-assignment: NIDs are individually selected by the SNPN at placement (and therefore may not be unique), and use a different numbering space than NIDs from coordinated assignments.

[0291] - Coordinated assignment: The NID is assigned using one of the following two options.

[0292] 1) The NID is assigned to be unique globally, independently of the PLMN ID used.

[0293] 2) The combination of NID and PLMN ID is assigned to be unique overall.

[0294] Human-readable optional network names help identify SNPNs during manual SNPN selection.

[0295] When the UE is configured to operate in SNPN connection mode, the UE does not perform the normal PLMN selection procedure.

[0296] A UE operating in SNPN connection mode reads the list of available PLMN IDs and available NIDs from broadcast system information and considers them during network selection.

[0297] For automatic network selection, the UE selects an available SNPN identified by a PLMN ID and NID having a SUPI and credentials and attempts to register.

[0298] For manual network selection, a UE operating in SNPN connection mode provides the user with a list of NIDs of available SNPNs, each with a SUPI and credentials, and their associated human-readable names (if available).

[0299] When the UE performs initial registration with the SNPN, the UE informs the NG-RAN of the selected NID and the corresponding PLMN ID. The NG-RAN informs the AMF of the selected PLMN ID and NID.

[0300] To access the PLMN service, a UE in SNPN access mode that has been successfully registered with SNPN can perform a different registration with the PLMN through the SNPN user plane (using the credentials of the corresponding PLMN). At this time, it follows the same structural principles as those for the non-3GPP access described in FIG. 10 and performs the role of a non-3GPP access where the SNPN is not trusted.

[0301] To access the SNPN service, a UE that has successfully registered with the PLMN can perform a different registration with the SNPN through the PLMN user plane (using the credentials of the corresponding SNPN). At this time, it follows the same structural principles as those for the non-3GPP connection described in Fig. 10 and performs the role of a non-3GPP connection where the PLMN is not trusted.

[0302] Further improvements to NPN are being discussed. One of the goals for further improving NPN is to support data transfer between PLMN and SNPN to reduce data loss. Additionally, another goal for further improving NPN is to support service continuity for terminal mobility when credentials owned by an entity separate from SNPN are held.

[0303] For example, if the NPN supports VIAPA (video, imaging, and audio for professional applications), data transfer between the PLMN and SNPN for service continuity may be considered. In this case, the question of whether service continuity can be supported between the PLMN and NPN (SNPN or PNI-NPN) where wireless coverage areas overlap (assuming that a PDU session anchor (PSA) can reside in the PLMN or NPN) may be addressed. Data services on the NPN can provide low latency and high data rates while serving a massive number of UEs in a small area (e.g., integrated audience multicast services at large-scale live production events such as music festivals).

[0304] For example, when a terminal receiving services through a source network (PLMN or SNPN) moves toward a target network (SNPN or PLMN), the source network's NG-RAN may attempt a handover of the terminal to the target network's NG-RAN. However, if a service level agreement (SLA) has not been established between the source network and the target network, and thus no N14 interface exists between the source network's AMF and the target network's AMF, this handover attempt may fail. To ensure service continuity between the source network and the target network, the terminal must send a PDU session establishment request message indicating the "existing PDU session" back toward the target network; however, service continuity may not be guaranteed to the terminal during this process. Alternatively, it may impair the user experience by causing unnecessary delays until services are provided to the terminal again through the new network.

[0305] In the specification described below, a method and an apparatus for performing said method are presented, wherein a network ensures service continuity to another network in accordance with network configuration conditions and simultaneously does not cause unnecessary delay time to a terminal.

[0306] In the specification described below, new service operations other than conventional service operations may be defined and used for service operations between NFs. In addition, in the specification described below, new N2 messages other than conventional N2 messages may be defined and used for N2 messages exchanged between AMF and NG-RAN. In addition, in the specification described below, new RRC messages other than conventional RRC messages may be defined and used for RRC messages exchanged between NG-RAN and UE.

[0307] In the specification described below, some steps may be performed simultaneously and / or in parallel, or in an alternate order.

[0308] The following drawings are prepared to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings.

[0309] FIG. 11 illustrates an example of a method performed by an NG-RAN node of a first network to which the implementation of the present specification applies.

[0310] In step S1100, the NG-RAN node of the first network receives a registration request message from the terminal.

[0311] In some implementations, the registration request message may include preferred network list information. The preferred network list information may include at least one of the ID of a network to which the terminal can register and / or the priority of a network to which the terminal can register. Alternatively, the preferred network list information may include at least one of the ID of a network that has an SLA with the first network and / or the priority of a network that has an SLA with the first network.

[0312] In step S1110, the NG-RAN node of the first network selects an AMF of the first network and transmits the registration request message to the AMF of the first network.

[0313] In step S1120, the NG-RAN node of the first network receives an Initial UE Context Setup Request message from the AMF of the first network. The Initial UE Context Setup Request message includes (i) a registration acceptance message in response to the registration request message and (ii) information regarding at least one second network supported by the first network. Additionally, the registration acceptance message includes information regarding whether an N14 interface between the AMF of the first network and the AMF of the at least one second network is supported.

[0314] In some implementations, the at least one second network is determined by the AMF based on at least one of the preferred network list information, subscriber information obtained by the AMF from the UDM, the presence or absence of an N14 interface between the AMF of the first network and the AMF of the at least one second network, and an SLA between the first network and the at least one second network, wherein the at least one second network may be a network included in the preferred network list information.

[0315] In some implementations, the registration acceptance message may include information about at least one second network supported by the first network.

[0316] In some implementations, the initial UE context setup request message may include information about the mobility mode used when the terminal moves to the at least one second network.

[0317] In step S1130, the NG-RAN node of the first network transmits the registration acceptance message to the terminal.

[0318] In step S1140, the NG-RAN node of the first network initiates a handover for the terminal to one of the at least one second networks based on information about the at least one second network.

[0319] In some implementations, the first network may be a PLMN and at least one second network may be an SNPN. Alternatively, the first network may be an SNPN and at least one second network may be a PLMN.

[0320] Additionally, the method described in Fig. 11 in terms of the NG-RAN node of the first network can be performed by the second wireless device (200) shown in Fig. 2 and / or the wireless device (200) shown in Fig. 3.

[0321] More specifically, an NG-RAN node of the first network includes one or more transceivers, one or more processors, and one or more memories that can be connected to operate with said one or more processors. The one or more memories store instructions that cause the following operations to be performed by said one or more processors.

[0322] The above operation includes receiving a registration request message from a terminal.

[0323] The above operation includes selecting an AMF of the first network and transmitting the registration request message to the AMF of the first network.

[0324] The above operation includes receiving an initial UE context setup request message from the AMF of the first network. The initial UE context setup request message includes (i) a registration acceptance message in response to the registration request message and (ii) information regarding at least one second network supported by the first network. The registration acceptance message includes information regarding whether an N14 interface between the AMF of the first network and the AMF of the at least one second network is supported.

[0325] The above operation includes transmitting the registration acceptance message to the terminal.

[0326] The above operation includes initiating a handover to one of the at least one second network for the terminal based on information regarding the at least one second network.

[0327] FIG. 12 illustrates an example of a method performed by a terminal to which the implementation of the present specification is applied.

[0328] In step S1200, the terminal transmits a registration request message to the AMF of the first network through the NG-RAN node of the first network.

[0329] In some implementations, the registration request message may include preferred network list information. The preferred network list information may include at least one of the ID of a network to which the terminal can register and / or the priority of a network to which the terminal can register. Alternatively, the preferred network list information may include at least one of the ID of a network that has an SLA with the first network and / or the priority of a network that has an SLA with the first network.

[0330] In step S1210, the terminal receives a registration acceptance message, which is a response to the registration request message, from the AMF of the first network through the NG-RAN node of the first network. The registration acceptance message includes information on whether an N14 interface is supported between the AMF of the first network and at least one AMF of the second network supported by the first network.

[0331] In some implementations, the registration acceptance message may include information about at least one second network supported by the first network.

[0332] In some implementations, based on the information indicating that an N14 interface between the AMF of the first network and the AMF of the at least one second network is supported, the terminal can perform a handover from the first network to one of the at least one second networks.

[0333] In some implementations, based on the information indicating that the N14 interface between the AMF of the first network and the AMF of at least one second network is not supported, the terminal may establish a PDU session through the N3IWF of the first network and perform a handover of the PDU session to one of the at least one second networks. In this case, the request type for establishing the PDU session may be an "Existing PDU Session".

[0334] In some implementations, the terminal can communicate with at least one of a mobile device, a network, and / or an autonomous vehicle different from the terminal.

[0335] Additionally, the method described in terms of the terminal in FIG. 12 may be performed by the first wireless device (100) shown in FIG. 2, the wireless device (100) shown in FIG. 3, and / or the UE (100) shown in FIG. 4.

[0336] More specifically, the terminal includes one or more transceivers, one or more processors, and one or more memories that can be connected to operate with said one or more processors. said one or more memories store instructions that cause the following operation to be performed by said one or more processors.

[0337] The above operation includes transmitting a registration request message to the AMF of the first network through the NG-RAN node of the first network.

[0338] In some implementations, the registration request message may include preferred network list information. The preferred network list information may include at least one of the ID of a network to which the terminal can register and / or the priority of a network to which the terminal can register. Alternatively, the preferred network list information may include at least one of the ID of a network that has an SLA with the first network and / or the priority of a network that has an SLA with the first network.

[0339] The above operation includes receiving a registration acceptance message, which is a response to the registration request message, from the AMF of the first network through the NG-RAN node of the first network. The registration acceptance message includes information on whether an N14 interface is supported between the AMF of the first network and at least one AMF of the second network supported by the first network.

[0340] In some implementations, the registration acceptance message may include information about at least one second network supported by the first network.

[0341] In some implementations, based on the information indicating that an N14 interface between the AMF of the first network and the AMF of at least one second network is supported, the operation may further include performing a handover from the first network to one of the at least one second networks.

[0342] In some implementations, based on the information indicating that the N14 interface between the AMF of the first network and the AMF of at least one second network is not supported, the operation may further include establishing a PDU session through the N3IWF of the first network and performing a handover of the PDU session to one of the at least one second networks. In this case, the request type for establishing the PDU session may be an "Existing PDU Session".

[0343] Additionally, the method described in terms of the terminal in FIG. 12 may be performed by the control of the processor (102) included in the first wireless device (100) shown in FIG. 2, the control of the communication device (110) and / or control device (120) included in the wireless device (100) shown in FIG. 3, and / or the control of the processor (102) included in the UE (100) shown in FIG. 4.

[0344] More specifically, a device operating in a wireless communication system comprises one or more processors and one or more memories that can be connected to operate with said one or more processors. The one or more processors are configured to perform operations including generating a registration request message and obtaining a registration acceptance message that is a response to said registration request message, wherein the registration acceptance message includes information regarding whether an N14 interface between an AMF of a first network and at least one AMF of a second network supported by said first network is supported.

[0345] Additionally, the method described in Fig. 12 from the perspective of a terminal can be performed by software code (105) stored in a memory (104) included in the first wireless device (100) illustrated in Fig. 2.

[0346] The technical features of this specification may be implemented directly in hardware, in software executed by a processor, or in a combination of both. For example, a method performed by a wireless device in wireless communication may be implemented in hardware, software, firmware, or a combination thereof. For example, software may be in RAM, flash memory, ROM, EPROM, EEPROM, registers, a hard disk, a removable disk, a CD-ROM, or other storage media.

[0347] Some examples of storage media may be coupled to the processor so that the processor can read information from the storage media. Alternatively, the storage media may be integrated into the processor. The processor and storage media may exist in an ASIC. In other examples, the processor and storage media may exist as separate components.

[0348] Computer-readable media may include non-transitory computer-readable storage media of a type.

[0349] For example, non-transient computer-readable media may include RAM such as SDRAM (synchronous dynamic RAM), ROM, non-volatile NVRAM (non-volatile RAM), EEPROM, flash memory, magnetic or optical data storage media, or other media that can be used to store instructions or data structures. Non-transient computer-readable media may include combinations of the above.

[0350] Additionally, the method described herein may be realized by a computer-readable communication medium that carries or communicates code in the form of at least partially instructions or data structures and can be accessed, read, and / or executed by a computer.

[0351] According to some implementations of this specification, a non-transient computer-readable medium (CRM) stores multiple commands.

[0352] More specifically, the CRM stores instructions for an operation to be performed by one or more processors. The operation includes generating a registration request message and obtaining a registration acceptance message as a response to the registration request message, wherein the registration acceptance message includes information regarding whether an N14 interface between an AMF of a first network and at least one AMF of a second network supported by the first network is supported.

[0353] Various implementations and / or embodiments of the present specification are described below.

[0354] In the embodiments described below, it is assumed that a specific PLMN has established an SLA with another SNPN, and that an N14 interface exists between the PLMN that established the SLA and the SNPN's AMF depending on the network configuration of the operator.

[0355] The embodiments described below can support service continuity for all cases where a terminal moves from a PLMN to an SNPN, moves from an SNPN to a PLMN, or moves between SNPNs.

[0356] 1. Example 1: Guaranteeing Service Continuity Between PLMN and SNPN

[0357] Embodiment 1 of the present specification presents a method for informing a terminal whether the two networks support an N14 interface to ensure service continuity between a PLMN and an SNPN.

[0358] According to a partial implementation of Example 1 of this specification, in the process of a terminal registering with a source network or establishing a PDU session, the source network may provide the terminal with a list of target networks that have an N14 interface through the current SLA. Additionally, according to a partial implementation of Example 1 of this specification, the source network may provide the terminal with information that after the terminal moves to the target network, it must perform a PDU session establishment procedure with "existing PDU session" as the request type.

[0359] FIG. 13 illustrates an example of a method for ensuring service continuity between a PLMN and an SNPN to which the implementation of the present specification applies.

[0360] The example illustrated in Fig. 13 is an example illustrating the method described in Figs. 11 and 12 from the perspective of the whole system.

[0361] (1) Step S1302: To register with the network, the terminal sends a registration request message to the NG-RAN. This step corresponds to Step 1 of the registration procedure described in FIG. 6. Additionally, this step corresponds to Step S1100 described in FIG. 11 and / or Step S1200 described in FIG. 12.

[0362] The registration request message may include a list of preferred networks. The list of preferred networks may include the IDs of other networks that the terminal can currently register (e.g., PLMN IDs and / or combinations of PLMN IDs and NIDs) and / or priority information of those networks. If there are multiple other networks that the terminal can register to, service continuity to the network with the highest priority may be considered first.

[0363] Alternatively, the network ID and / or priority information of an SNPN that has established an SLA with a PLMN may be pre-configured in the terminal. For example, when the terminal registers with a PLMN, the preferred network list may include the SNPN ID that has established an SLA with the PLMN (e.g., a combination of the PLMN ID and NID) and / or the priority information of the SNPN. For example, when the terminal registers with an SNPN, the preferred network list may include the PLMN ID that has established an SLA with the SNPN (e.g., a combination of the PLMN ID and NID) and / or the priority information of the SNPN. If the terminal does not know whether there is an SLA between the PLMN and the SNPN, the preferred network list may include only network information that the terminal can register regardless of the SLA. In this case, the network may perform a handover prioritizing the network with an SLA among the preferred network list.

[0364] Network ID and / or priority information of the SNPN that has established an SLA with the PLMN pre-configured in the terminal can be updated through the UE Configuration Update procedure.

[0365] (2) Step S1304: NG-RAN selects AMF. This step corresponds to Step 2 of the registration procedure described in FIG. 6. Also, this step corresponds to Step S1110 described in FIG. 11.

[0366] The NG-RAN can select an AMF based on 5G-S-TMSI and / or GUAMI. 5G-S-TMSI and / or GUAMI may be received by being included in a registration request message transmitted by the terminal. If 5G-S-TMSI and / or GUAMI are not included in the registration request message transmitted by the terminal or are invalid, the NG-RAN can select an AMF based on the requested NSSAI, etc. If it is difficult to select an appropriate AMF, the NG-RAN can select a default AMF based on information configured within the NG-RAN.

[0367] (3) Step S1306: The NG-RAN transmits the registration request message received from the terminal to the selected AMF. This step corresponds to Step 3 of the registration procedure described in FIG. 6. Additionally, this step corresponds to Step S1110 described in FIG. 11 and / or Step S1200 described in FIG. 12.

[0368] (4) Step S1308: Steps 4-20 of the registration procedure described in FIGS. 6 and FIGS. 7 are performed.

[0369] (5) Step S1310: If the AMF can accept a registration request from the terminal, it can determine a list of networks that the terminal can use (or is supported) based on the preferred network list received from the terminal, subscriber information received from the UDM, the presence or absence of an N14 interface between the SNPN and the AMF, SLA, etc., and include the ID of the network in the supported network list.

[0370] The list of networks available (or supported) to the terminal, determined by the AMF, may be determined from the preferred network list received from the terminal. For example, when the terminal registers with a PLMN, the AMF may include, from the preferred network list, a network list that supports an SNPN ID for which the current PLMN can support service continuity for the terminal. For example, when the terminal registers with an SNPN, the AMF may include, from the preferred network list, a network list that supports a PLMN ID for which the current SNPN can support service continuity for the terminal.

[0371] It can be assumed that information regarding whether an N14 interface exists between the AMF of the PLMN and SNPN that have established an SLA is pre-configured in the AMF. Alternatively, information regarding whether an N14 interface exists between the AMF of the PLMN and SNPN that have established an SLA may be pre-configured in the NG-RAN, and if an SLA exists, an Xn interface may exist between the two networks.

[0372] Step S1310 can be performed immediately after the AMF retrieves subscriber information from the UDM.

[0373] The AMF can determine the mobility mode to be used when the terminal moves to another network, instead of and / or together with the list of supported networks. The mobility mode may specify any one of handover, N3IWF-based interworking, or LBO PDU session establishment.

[0374] If there are currently active PDU sessions (i.e., established PDU sessions), the AMF can determine the mobility mode for each PDU session. For example, when two PDU sessions (e.g., PDU Session A and PDU Session B) are active, the AMF can determine the mobility mode for PDU Session A to be N3IWF-based interworking and for PDU Session B to be handover.

[0375] The AMF can determine different mobility modes per terminal or per active PDU session of the terminal, depending on the target network to which the terminal can move. For example, the AMF can determine the per-terminal mobility mode based on the target network as follows.

[0376] - UE-1, PLMN-1: Xn-based or NG-based handover

[0377] - UE-1, SNPN-2: N3IWF-based interworking

[0378] - UE-2, PLMN-1: Establish LBO PDU session

[0379] - UE-2, SNPN-2: Xn-based or NG-based handover

[0380] For example, the AMF can determine the mobility mode per PDU session activated according to the target network as follows.

[0381] - UE-1, PDU Session A, PLMN-1: Xn-based or NG-based handover

[0382] - UE-1, PDU Session A, SNPN-2: N3IWF-based interworking

[0383] - UE-1, PDU Session B, PLMN-1: N3IWF-based interworking

[0384] - UE-1, PDU Session B, SNPN-2: Establish LBO PDU Session

[0385] The AMF can transmit information about the mobility mode determined according to the situation to the NG-RAN and / or terminal through procedures such as initial registration, mobility registration, PDU session establishment, and / or PDU session modification. For example, whether the generated PDU session was created as an LBO or as a home routed (HR) may be considered.

[0386] Alternatively, instead of a list of supported networks and / or mobility modes, the AMF may determine only whether handover is available when a terminal or an active PDU session moves to another network.

[0387] (6) Step S1312: The AMF sends an initial context setup request (NGAP INITIAL CONTEXT SETUP REQUEST) message to the NG-RAN to create a UE context in the NG-RAN. This step corresponds to Step 21 of the registration procedure described in FIG. 7. Additionally, this step corresponds to Step S1120 described in FIG. 11 and / or Step S1210 described in FIG. 12.

[0388] The initial context setup request message may include a list of supported networks determined by the AMF. The NG-RAN may trigger an NG handover using the N14 interface for networks included in the list of supported networks. Based on the list of supported networks, the NG-RAN may instruct / configure the terminal to perform a measurement for switching the connection mode using an RRC message.

[0389] The initial context setup request message may include a registration acceptance message as a response to the registration request message. The registration acceptance message may include a "5GS network Feature Support" indicator. The 5GS network feature support indicator may include an "N14 Interface Supported" indicator to inform the terminal whether the N14 interface is supported between the PLMN and the SNPN's AMF. The 5GS network feature support indicator and the N14 interface support indicator are merely names and may be replaced with other names.

[0390] Instead of the initial context setup request message, the DOWNLINK NAS TRANSPORT message can be used.

[0391] (7) Step S1314: The NG-RAN forwards the registration acceptance message received from the AMF to the terminal. This step corresponds to Step 21 of the registration procedure described in FIG. 7. Also, this step corresponds to Step S1130 described in FIG. 11 and / or Step S1210 described in FIG. 12.

[0392] A terminal that has received a registration acceptance message can determine, through the N14 interface support indicator, whether service continuity through the N14 interface can be guaranteed to the network that has established an SLA with the currently registered network.

[0393] Due to the operator's network configuration, the network where the terminal is currently registered may have an N14 interface with some of the networks that have established an SLA, but not with others. In this case, the AMF of the currently registered network may additionally include a list of supported networks in the registration acceptance message. In this case, the terminal can determine which network—the currently registered network or the networks with which an SLA has established an SLA—can be guaranteed service continuity through the N14 interface by considering both the N14 interface support indicator and the list of supported networks.

[0394] (8) Step S1316: Steps 22-25 of the registration procedure described in Fig. 7 are performed.

[0395] (9) Step S1318 / S1320: When a terminal moves to another network while maintaining a PDU session being serviced in the currently registered network, it may operate as follows based on the information received in Step S1312 / S1314.

[0396] - Step S1318: When a terminal moves to a network that is currently registered and has an N14 interface and is included in the list of supported networks, the NG-RAN may trigger an NG-based handover to the AMF of the source network. This corresponds to Step S1140 described in FIG. 11. Upon the handover request, the NG-RAN may include a target network ID (e.g., PLMN ID and / or a combination of PLMN ID and NID). The AMF of the source network that receives the handover request may request a handover to the AMF of the target network via the N14 interface with the UE context to ensure service continuity for the terminal.

[0397] - Step S1320: When the terminal moves from the currently registered network to a network without an N14 interface, the terminal may perform a PDU session establishment procedure via N3IWF. That is, the terminal may select the N3IWF of the network where the PDU session is anchored to perform registration, establish a PDU session, and perform a handover for the PDU session. To indicate that the PDU session is an existing PDU session while establishing the PDU session, the PDU session establishment request message may include a request type set to "existing PDU session" and the PDU session ID for which a handover is to be performed. In this process, the PDU session to be the target of the handover may be selected by considering the mobility mode received from the network. The PDU session establishment procedure via N3IWF may follow the PDU session establishment procedure described in FIGS. 8 and 9 and S4.9.2 of 3GPP TS 23.502.

[0398] FIG. 14 illustrates an example of a situation in which a PDU establishment procedure and handover are performed through N3IWF to which the implementation of the present specification is applied.

[0399] Referring to FIG. 14, when a terminal moves from a home SP (service provider) to a V-SNPN (visited SNPN) or changes the V-SNPN (e.g., V-SNPN-1 -> V-SNPN-2), a procedure to establish a PDU session can be performed through the N3IWF of the home SP for an HR PDU session anchored to the home SP.

[0400] FIG. 15 illustrates another example of a situation in which a PDU establishment procedure and handover are performed through N3IWF to which the implementation of the present specification applies.

[0401] Referring to Fig. 15, when a terminal moves from V-SNPN to a home SP, a procedure to establish a PDU session can be performed through the N3IWF of V-SNPN for an LBO PDU session anchored to V-SNPN.

[0402] FIG. 16 illustrates another example of a situation in which a PDU establishment procedure and handover are performed through N3IWF to which the implementation of the present specification applies.

[0403] Referring to Fig. 16, when the terminal changes V-SNPN (e.g., V-SNPN-1 -> V-SNPN-2), a procedure to establish a PDU session can be performed through the N3IWF of V-SNPN-1 for an LBO PDU session anchored to V-SNPN-1.

[0404] Meanwhile, although it was assumed in FIG. 13 that information regarding SNPNs that have established an SLA with a PLMN is pre-configured in the terminal, information regarding SNPNs that have established an SLA with a PLMN may be configured in the UDM instead of the terminal. In this case, the terminal may not include a preferred network list in the registration request message, and instead, the AMF that receives the registration request message from the terminal may receive information (e.g., network ID) regarding SNPNs that have established an SLA with a PLMN from the UDM and perform the operation of step S1310. Alternatively, only information about networks that the terminal can register may be stored in the UDM, and information about networks that have established an SLA may be configured in the AMF. In this case, the AMF may consider whether an SLA has been established when determining the list of supported networks. Alternatively, the AMF may determine the list of supported networks based only on information about networks that have established an SLA, regardless of subscriber information.

[0405] According to Embodiment 1 of the present specification described above, when the NG-RAN of the source network triggers a handover to the target network, it can reduce unnecessary handover attempts by referring to whether an N14 interface exists. In addition, when the terminal moves to a target network where an N14 interface does not exist, it can quickly execute a subsequent operation (e.g., a procedure to establish a PDU session with "existing PDU session" as the request type) based on information received from the source network, thereby ensuring service continuity for the user.

[0406] 2. Example 2: Guaranteeing Service Continuity Between PLMN and SNPN Based on NG Setup Procedure

[0407] Embodiment 2 of the present specification presents a method for informing a terminal whether the two networks support an N14 interface based on an NG configuration procedure to ensure service continuity between a PLMN and an SNPN.

[0408] FIG. 17 illustrates an example of a method for ensuring service continuity between a PLMN and an SNPN based on an NG setup procedure to which the implementation of the present specification applies.

[0409] (1) Step S1702: NG-RAN sends an NG Setup Request message to AMF to establish an NG interface with AMF.

[0410] (2) Step S1704: AMF sends an NG Setup Response message to NG-RAN in response to the NG Setup Request message.

[0411] The NG configuration response message may include an information element (IE) for "Network IDs with N14 interface indication." The Network IDs with N14 interface indication IE may represent a list of IDs of networks with which the AMF has established an SLA (e.g., PLMN IDs and / or combinations of PLMN IDs and NIDs). The Network IDs with N14 interface indication IE may include information regarding whether the AMF has individual networks and N14 interfaces. The Network IDs with N14 interface indication IE is merely a designation and may be replaced with another designation.

[0412] It can be assumed that information regarding whether an N14 interface exists between the AMF of the PLMN and SNPN that have established an SLA is pre-configured in the AMF. Alternatively, information regarding whether an N14 interface exists between the AMF of the PLMN and SNPN that have established an SLA may be pre-configured in the NG-RAN, and if an SLA exists, an Xn interface may exist between the two networks.

[0413] (3) Step S1706: The NG-RAN transmits the network ID and N14 interface instruction IE received from the AMF to the terminal via the system information block (SIB).

[0414] Due to the network configuration of the operator, the network to which the terminal is currently registered may have an N14 interface with some of the networks that have established an SLA, but may not have an N14 interface with other networks. In this case, the terminal can determine which network—the network to which the terminal is currently registered or the networks that have established an SLA—can be guaranteed service continuity through the N14 interface by considering the network ID and the N14 interface indication IE. Accordingly, the terminal can determine subsequent actions (e.g., NG-based handover or PDU session establishment procedure).

[0415] Additionally, the registration acceptance message transmitted in step S1716 described below may include a list of supported networks determined by the AMF. At this time, the terminal can consider the list of supported networks to determine which network—the currently registered network or the network with which an SLA has been established—can guarantee service continuity through the N14 interface. Accordingly, the terminal can determine subsequent actions (e.g., NG-based handover or PDU session establishment procedure).

[0416] (4) Step S1708: To register with the network, the terminal sends a registration request message to the NG-RAN. This step corresponds to Step 1 of the registration procedure described in FIG. 6.

[0417] The registration request message may include a preferred network list. The preferred network list may include network IDs received via the SIB and network IDs belonging to the N14 interface instruction IE, as well as the IDs of other networks currently available for registration by the terminal (e.g., PLMN ID and / or combinations of PLMN ID and NID) and / or priority information for said networks. If there are multiple other networks available for registration by the terminal, service continuity to the network with the highest priority may be considered first.

[0418] Alternatively, the network ID and / or priority information of an SNPN that has established an SLA with a PLMN may be pre-configured in the terminal. In this case, a preferred network list may be configured by considering both the information pre-configured in the terminal and the information received through the SIB. For example, when the terminal registers with a PLMN, the preferred network list may include the network ID and the SNPN ID that has established an SLA with the corresponding PLMN (e.g., a combination of PLMN ID and NID) among the network IDs belonging to the N14 interface indication IE, and / or the priority information of the corresponding SNPN. For example, when the terminal registers with an SNPN, the preferred network list may include the network ID and the PLMN ID that has established an SLA with the corresponding SNPN (e.g., a combination of PLMN ID and / or PLMN ID and NID) among the network IDs belonging to the N14 interface indication IE, and / or the priority information of the corresponding SNPN. If the terminal does not know whether there is an SLA between the PLMN and the SNPN, the preferred network list may include only network information that the terminal can register among network IDs belonging to the network ID and N14 interface indication IE, regardless of the SLA. In this case, the handover may be performed by prioritizing the network with an SLA among the preferred network list.

[0419] Network ID and / or priority information of the SNPN that has established an SLA with the PLMN pre-configured in the terminal can be updated through the UE configuration update procedure.

[0420] (5) Step S1710: NG-RAN selects AMF. This step corresponds to Step 2 of the registration procedure described in Fig. 6.

[0421] The NG-RAN can select an AMF based on 5G-S-TMSI and / or GUAMI. 5G-S-TMSI and / or GUAMI may be received and included in a registration request message transmitted by the terminal. If 5G-S-TMSI and / or GUAMI are not included in the registration request message transmitted by the terminal or are invalid, the NG-RAN can select an AMF based on the requested NSSAI, etc. If it is difficult to select an appropriate AMF, the NG-RAN can select a default AMF based on information configured within the NG-RAN.

[0422] (6) Step S1712: The NG-RAN transmits the registration request message received from the terminal to the selected AMF. This step corresponds to Step 3 of the registration procedure described in FIG. 6.

[0423] (7) Step S1714: Steps 4-20 of the registration procedure described in FIGS. 6 and FIGS. 7 are performed.

[0424] (8) Step S1716: If the AMF can accept a registration request from the terminal, it can determine a list of networks that the terminal can use (or is supported) based on the preferred network list received from the terminal, subscriber information received from the UDM, the presence or absence of an N14 interface between the SNPN and the AMF, SLA, etc., and include the ID of the network in the list of supported networks.

[0425] The list of networks available (or supported) to the terminal, determined by the AMF, may be determined from the preferred network list received from the terminal. For example, when the terminal registers with a PLMN, the AMF may include, from the preferred network list, a network list that supports an SNPN ID for which the current PLMN can support service continuity for the terminal. For example, when the terminal registers with an SNPN, the AMF may include, from the preferred network list, a network list that supports a PLMN ID for which the current SNPN can support service continuity for the terminal.

[0426] Step S1716 can be performed immediately after the AMF retrieves subscriber information from the UDM.

[0427] The AMF can determine the mobility mode to be used when the terminal moves to another network, instead of and / or with the list of supported networks. The mobility mode may specify any one of handover, N3IWF-based interworking, or LBO PDU session establishment.

[0428] If there are currently active PDU sessions (i.e., established PDU sessions), the AMF can determine the mobility mode for each PDU session. For example, when two PDU sessions (e.g., PDU Session A and PDU Session B) are active, the AMF can determine the mobility mode for PDU Session A to be N3IWF-based interworking and for PDU Session B to be handover.

[0429] The AMF can determine different mobility modes per terminal or per active PDU session of the terminal, depending on the target network to which the terminal can move. For example, the AMF can determine the per-terminal mobility mode based on the target network as follows.

[0430] - UE-1, PLMN-1: Xn-based or NG-based handover

[0431] - UE-1, SNPN-2: N3IWF-based interworking

[0432] - UE-2, PLMN-1: Establish LBO PDU session

[0433] - UE-2, SNPN-2: Xn-based or NG-based handover

[0434] For example, the AMF can determine the mobility mode per PDU session activated according to the target network as follows.

[0435] - UE-1, PDU Session A, PLMN-1: Xn-based or NG-based handover

[0436] - UE-1, PDU Session A, SNPN-2: N3IWF-based interworking

[0437] - UE-1, PDU Session B, PLMN-1: N3IWF-based interworking

[0438] - UE-1, PDU Session B, SNPN-2: Establish LBO PDU Session

[0439] The AMF can transmit information about the mobility mode determined according to the situation to the NG-RAN and / or terminal through procedures such as initial registration, mobility registration, PDU session establishment, and / or PDU session modification. For example, whether the generated PDU session was created as LBO or HR may be considered.

[0440] Alternatively, instead of a list of supported networks and / or mobility modes, the AMF may determine only whether handover is available when a terminal or an active PDU session moves to another network.

[0441] (9) Step S1718: The AMF sends an initial context setup request message to the NG-RAN to create a UE context in the NG-RAN. This step corresponds to step 21 of the registration procedure described in Fig. 7.

[0442] The initial context setup request message may include a registration acceptance message that is a response to the registration request message. The initial context setup request message may include a list of supported networks determined by the AMF. The NG-RAN may trigger an NG handover using the N14 interface for networks included in the list of supported networks. Based on the list of supported networks, the NG-RAN may instruct / configure the terminal to perform a measurement for switching the connection mode using an RRC message.

[0443] Information transmitted to the NG-RAN may be transmitted only when an update is required for the information transmitted in step S1704. For example, an update may be required when there is an N14 interface but the terminal does not have a subscription to a specific SNPN or PLMN and therefore should not perform a handover to that network, and information may be transmitted to the NG-RAN.

[0444] Instead of an initial context setup request message, a DL NAS delivery message can be used.

[0445] (10) Step S1720: NG-RAN forwards the registration acceptance message received from AMF to the terminal. This step corresponds to Step 21 of the registration procedure described in FIG. 7.

[0446] A terminal that has received a registration acceptance message can determine whether service continuity through the N14 interface can be guaranteed with the network that has established an SLA with the currently registered network.

[0447] Due to the operator's network configuration, the network where the terminal is currently registered may have an N14 interface with some of the networks that have established an SLA, but not with others. In this case, the AMF of the currently registered network may additionally include a list of supported networks in the registration acceptance message. In this case, the terminal can determine which network—the currently registered network or the networks with which an SLA has established an SLA—can be guaranteed service continuity through the N14 interface by considering both the N14 interface support indicator and the list of supported networks.

[0448] Subsequently, steps 22-25 of the registration procedure described in FIG. 7 are performed. These steps are not illustrated in FIG. 17.

[0449] Subsequently, when the terminal moves to another network while maintaining the PDU session being serviced in the currently registered network, it may operate as follows based on the information received in steps S1718 / S1720. This step is not illustrated in FIG. 17.

[0450] When a terminal moves to a network that is included in the list of supported networks and has an N14 interface with the currently registered network, the NG-RAN may trigger an NG-based handover to the AMF of the source network. When requesting a handover, the NG-RAN may include a target network ID (e.g., PLMN ID and / or a combination of PLMN ID and NID). The AMF of the source network that receives the handover request may request a handover to the AMF of the target network via the N14 interface with the UE context to ensure service continuity for the terminal.

[0451] When a terminal moves from a currently registered network to a network without an N14 interface, the terminal can perform a PDU session establishment procedure via N3IWF. That is, the terminal can select the N3IWF of the network where the PDU session is anchored to perform registration, establish a PDU session, and perform a handover for the PDU session. To indicate that the PDU session is an existing PDU session while establishing the PDU session, the PDU session establishment request message may include a request type set to "existing PDU session" and the PDU session ID for which a handover is to be performed. In this process, the PDU session to be the target of the handover can be selected by considering the mobility mode received from the network. The PDU session establishment procedure via N3IWF may follow the PDU session establishment procedure described in FIGS. 8 and 9 and S4.9.2 of 3GPP TS 23.502.

[0452] For examples of the PDU establishment procedure and handover situation through N3IWF, refer to FIGS. 14 to 16 described above.

[0453] Meanwhile, although it was assumed in FIG. 17 that information regarding SNPNs that have established an SLA with a PLMN is pre-configured in the terminal, information regarding SNPNs that have established an SLA with a PLMN may be configured in the UDM instead of the terminal. In this case, the terminal may not include a preferred network list in the registration request message, and instead, the AMF that receives the registration request message from the terminal may obtain information (e.g., network ID) regarding SNPNs that have established an SLA with a PLMN from the UDM and perform the operation of step S1716. Alternatively, only information about networks that the terminal can register may be stored in the UDM, and information about networks that have established an SLA may be configured in the AMF. In this case, the AMF may consider whether an SLA has been established when determining the list of supported networks. Alternatively, the AMF may determine the list of supported networks based solely on information about networks that have established an SLA, regardless of subscriber information.

[0454] According to Embodiment 2 of the present specification described above, the network may inform the terminal of whether it supports the N14 interface during the registration process, thereby enabling the terminal to select a method to receive support for service continuity between the PLMN and SNPN in accordance with the network configuration situation. Additionally, the NG-RAN may know the network configuration situation in advance and perform an Xn-based handover or an NG-based handover to the target network to quickly move the terminal to the target network.

[0455] 3. Example 3: Service continuity between SNPNs in a situation where an entity separated from the SNPN has credentials

[0456] Embodiment 3 of the present specification presents a method in which a network ensures service continuity to another network in accordance with the network configuration situation, while simultaneously not causing unnecessary delay time to the terminal.

[0457] FIG. 18 illustrates an example of a method for informing a terminal whether the N14 interface is supported between the V-SNPN and the home SP to which the implementation of the present specification applies.

[0458] (1) Step S1802: NG-RAN sends an NG setup request message to AMF to establish an NG interface with AMF. The NG setup request message may include a list of supported SNPNs.

[0459] (2) Step S1804: AMF sends an NG configuration response message to NG-RAN in response to the NG configuration request message.

[0460] The NG configuration response message may include a "Supported Home SP ID with N14 interface indication" IE. The Supported Home SP ID with N14 interface indication IE may represent a list of network IDs (e.g., PLMN ID and / or combinations of PLMN ID and NID) for which the AMF has an SLA. The Supported Home SP ID with N14 interface indication IE may include information on whether the AMF has individual networks and N14 interfaces. The Supported Home SP ID with N14 interface indication IE is merely a designation and may be replaced with another designation.

[0461] The NG configuration response message may also include the "Supported Roaming Group ID with N14 interface indication" IE. A roaming group is established by dividing the networks with which the V-SNPN AMF has signed an SLA into several groups, and it can be used to prevent all home SP IDs from being broadcast via the SIB. Therefore, the Supported Roaming Group ID with N14 interface indication IE may represent a list of groups of networks with which the V-SNPN AMF has signed an SLA. The Roaming Group ID with N14 interface indication IE may include information on whether the corresponding AMF has an N14 interface with a network belonging to a specific group. The Roaming Group ID with N14 interface indication IE is merely a designation and may be replaced with another designation.

[0462] It can be assumed that information regarding whether an N14 interface exists between the AMF of the PLMN and SNPN that have established an SLA is pre-configured in the AMF. Alternatively, information regarding whether an N14 interface exists between the AMF of the PLMN and SNPN that have established an SLA may be pre-configured in the NG-RAN, and if an SLA exists, an Xn interface may exist between the two networks.

[0463] (3) Step S1806: NG-RAN transmits the supported home SP ID and N14 interface instruction IE and / or roaming group ID and N14 interface instruction IE received from AMF to the terminal via SIB.

[0464] Due to the network configuration of the operator, the network to which the terminal is currently registered may have an N14 interface with some of the networks that have an SLA, but may not have an N14 interface with other networks. In this case, the terminal can determine which network—the network to which the terminal is currently registered or the networks that have an SLA—can be guaranteed service continuity through the N14 interface by considering the supported Home SP ID and N14 interface indication IE and / or Roaming Group ID and N14 interface indication IE. Accordingly, the terminal can determine subsequent actions (e.g., NG-based handover or PDU session establishment procedure).

[0465] (4) Step S1808: To register with the network, the terminal sends a registration request message to the NG-RAN. This step corresponds to Step 1 of the registration procedure described in FIG. 6.

[0466] In order for the AMF of the V-SNPN to request authentication of the terminal from the home SP for a home SP network in which the current terminal can be registered among the networks included in the supported home SP ID and N14 interface instruction IE and / or roaming group ID and N14 interface instruction IE, the registration request message may include terminal ID information for the home SP.

[0467] Home SP ID and priority information may be pre-configured in the terminal. In this case, a terminal ID for the home SP can be selected by considering both the information pre-configured in the terminal and the information received through the SIB.

[0468] (5) Step S1810: NG-RAN selects AMF. This step corresponds to Step 2 of the registration procedure described in Fig. 6.

[0469] The NG-RAN can select an AMF based on 5G-S-TMSI and / or GUAMI. 5G-S-TMSI and / or GUAMI may be received and included in a registration request message transmitted by the terminal. If 5G-S-TMSI and / or GUAMI are not included in the registration request message transmitted by the terminal or are invalid, the NG-RAN can select an AMF based on the requested NSSAI, etc. If it is difficult to select an appropriate AMF, the NG-RAN can select a default AMF based on information configured within the NG-RAN.

[0470] (6) Step S1812: The NG-RAN transmits the registration request message received from the terminal to the selected AMF. This step corresponds to Step 3 of the registration procedure described in FIG. 6.

[0471] (7) Step S1814: Steps 4-20 of the registration procedure described in FIGS. 6 and FIGS. 7 are performed.

[0472] At this stage, the AMF can select a Home SP ID based on the terminal ID for the Home SP received from the terminal. The AMF can request authentication for the terminal from the AUSF and UDM belonging to the Home SP and receive subscriber information.

[0473] The AMF can determine the mobility mode to be used when the terminal moves to another network, instead of and / or with the home SP ID. The mobility mode may specify any one of handover, N3IWF-based interworking, or LBO PDU session establishment.

[0474] If there are currently active PDU sessions (i.e., established PDU sessions), the AMF can determine the mobility mode for each PDU session. For example, when two PDU sessions (e.g., PDU Session A and PDU Session B) are active, the AMF can determine the mobility mode for PDU Session A to be N3IWF-based interworking and for PDU Session B to be handover.

[0475] The AMF can determine different mobility modes per terminal or per active PDU session of the terminal, depending on the target network to which the terminal can move. For example, the AMF can determine the per-terminal mobility mode based on the target network as follows.

[0476] - UE-1, PLMN-1: Xn-based or NG-based handover

[0477] - UE-1, SNPN-2: N3IWF-based interworking

[0478] - UE-2, PLMN-1: Establish LBO PDU session

[0479] - UE-2, SNPN-2: Xn-based or NG-based handover

[0480] For example, the AMF can determine the mobility mode per PDU session activated according to the target network as follows.

[0481] - UE-1, PDU Session A, PLMN-1: Xn-based or NG-based handover

[0482] - UE-1, PDU Session A, SNPN-2: N3IWF-based interworking

[0483] - UE-1, PDU Session B, PLMN-1: N3IWF-based interworking

[0484] - UE-1, PDU Session B, SNPN-2: Establish LBO PDU Session

[0485] The AMF can transmit information about the mobility mode determined according to the situation to the NG-RAN and / or terminal through procedures such as initial registration, mobility registration, PDU session establishment, and / or PDU session modification. For example, whether the generated PDU session was created as LBO or HR may be considered.

[0486] Alternatively, the AMF may determine only whether handover is available when a terminal or active PDU session moves to another network, instead of the home SP ID and / or mobility mode.

[0487] (8) Step S1816: The AMF sends an initial context setup request message to the NG-RAN to create a UE context in the NG-RAN. This step corresponds to step 21 of the registration procedure described in Fig. 7.

[0488] The initial context setup request message may include a registration acceptance message that is a response to the registration request message. The initial context setup request message may include a selected home SP ID. The NG-RAN of the V-SNPN may perform additional actions on the home SP (e.g., connection control, connection mode switching) based on the selected home SP ID. For example, the NG-RAN of the V-SNPN may instruct the terminal to measure the home SP network in order to switch the connection mode to the home SP.

[0489] Information transmitted to the NG-RAN may be transmitted only when an update is required for the information transmitted in step S1804. For example, an update may be required when there is an N14 interface but the terminal does not have a subscription to a specific SNPN or PLMN and therefore should not perform a handover to that network, and information may be transmitted to the NG-RAN.

[0490] Instead of an initial context setup request message, a DL NAS delivery message can be used.

[0491] (9) Step S1818: NG-RAN forwards the registration acceptance message received from AMF to the terminal. This step corresponds to Step 21 of the registration procedure described in FIG. 7.

[0492] A terminal that has received a registration acceptance message can determine whether service continuity through the N14 interface can be guaranteed to the home SP network that has established an SLA with the currently registered network.

[0493] Subsequently, steps 22-25 of the registration procedure described in FIG. 7 are performed. These steps are not illustrated in FIG. 18.

[0494] Subsequently, when the terminal moves to another network while maintaining the PDU session being serviced in the currently registered network, it may operate as follows based on the information received in steps S1816 / S1818. This step is not illustrated in FIG. 18.

[0495] When a terminal moves to a network that is included in the list of supported networks and has an N14 interface with the currently registered network, the NG-RAN may trigger an NG-based handover to the AMF of the source network. When requesting a handover, the NG-RAN may include a target network ID (e.g., PLMN ID and / or a combination of PLMN ID and NID). The AMF of the source network that receives the handover request may request a handover to the AMF of the target network via the N14 interface with the UE context to ensure service continuity for the terminal.

[0496] When a terminal moves from a currently registered network to a network without an N14 interface, the terminal can perform a PDU session establishment procedure via N3IWF. That is, the terminal can select the N3IWF of the network where the PDU session is anchored to perform registration, establish a PDU session, and perform a handover for the PDU session. To indicate that the PDU session is an existing PDU session while establishing the PDU session, the PDU session establishment request message may include a request type set to "existing PDU session" and the PDU session ID for which a handover is to be performed. In this process, the PDU session to be the target of the handover can be selected by considering the mobility mode received from the network. The PDU session establishment procedure via N3IWF may follow the PDU session establishment procedure described in FIGS. 8 and 9 and S4.9.2 of 3GPP TS 23.502.

[0497] For examples of the PDU establishment procedure and handover situation through N3IWF, refer to FIGS. 14 to 16 described above.

[0498] According to Embodiment 3 of the present specification described above, the network can inform the terminal in advance via SIB whether it supports the N14 interface, thereby enabling the terminal to select a method to receive service continuity support between the home SP and the V-SNPN in accordance with the network configuration situation. Additionally, the NG-RAN of the V-SNPN can support additional operations by considering the home SP. Furthermore, the NG-RAN can know the network configuration situation in advance and perform an Xn-based handover or an NG-based handover to the target network to quickly move the terminal to the target network.

[0499] 4. Example 4: Notifying the UD of the mobility mode during the PDU session establishment procedure

[0500] FIG. 19 illustrates an example of a method for informing a terminal during a PDU session establishment procedure whether a handover between a PLMN and an SNPN to which the implementation of the present specification applies is possible.

[0501] (0) Step S1900: The terminal is already registered with the network according to the registration procedure described in FIGS. 6 and FIGS. 7.

[0502] (1) Step S1902 / S1904: The terminal sends a PDU session establishment request message via RRC and N2 messages to receive services from the network. This step corresponds to Step 1 of the PDU session establishment procedure described in FIG. 8.

[0503] (2) Step S1906: Steps 2-10 of the PDU session establishment procedure described in FIG. 8 may be performed. This may be the case where the PDU session being established is an LBO PDU session.

[0504] If the PDU session being established is an HR PDU session, refer to S4.3.2.2.2 of 3GPP TS 23.502.

[0505] (3) Step S1908: Based on at least one of the following information, the SMF determines whether the PDU session can be handed over to another network using the handover procedure in the 3GPP connection described in S4.9.1 of 3GPP TS 23.502.

[0506] 1) Subscriber information received from UDM;

[0507] 2) Whether it is an LBO PDU session or an HR PDU session;

[0508] 3) Presence or absence of an N14 interface between the currently registered network and another network;

[0509] 4) If the N14 interface exists, whether an SLA is established between the two networks;

[0510] 5) If the terminal performs the registration procedure described in FIGS. 11 to 13, FIG. 18 and / or FIG. 19 above, a list of supported networks created during the process;

[0511] 6) Information that can be retrieved from PCF (e.g., preference information - N3IWF-based interworking or RAN-based handover, etc.)

[0512] It is assumed that information regarding whether an N14 interface exists between the AMF of the PLMN and SNPN that have established an SLA is configured in the AMF. In step S1906, the AMF can transmit this information to the SMF using a message such as Nsmf_PDUSession_CreateSMContext Request.

[0513] Step S1908 can be executed immediately after the SMF retrieves subscriber information from the UDM.

[0514] Among the information described above, 3), 4), and 5) may be provided when the AMF transmits the PDU session establishment request message to the SMF.

[0515] (4) Step S1910: The SMF generates resource information to be allocated in the NG-RAN for the PDU session and a message accepting the establishment of the PDU session, and transmits it to the AMF using the Namf_Communication_N1N2MessageTransfer message. This step corresponds to Step 11 of the PDU session establishment procedure described in Fig. 8.

[0516] The SMF can transmit the information determined in step S1908 (i.e., whether to perform a handover) to the NG-RAN and the terminal in the form of Handover Assistance Information. The Handover Assistance Information may include at least one of the following information.

[0517] - Mobility Mode: The mobility procedure to be used when the PDU session needs to move to another network (Xn-based handover, NG-based handover, N3IWF-based interworking and / or LBO PDU session establishment procedure, etc.)

[0518] - List of networks where the relevant PDU session must not be transmitted using the handover procedure

[0519] - Information on whether the relevant PDU session is an LBO PDU session or an HR PDU session

[0520] - Information about the network where the PDU session was created (e.g., PLMN ID or a combination of PLMN ID and NID)

[0521] Instead of mobility mode, it is also possible to inform the NG-RAN and the terminal of an indicator (in the form of on / off) of whether the PDU session can be handed over to another network using the handover procedure in the 3GPP connection.

[0522] In addition to handover assistance information, S-NSSAI may be utilized. That is, information such as which mobility mode a PDU session using a specific S-NSSAI should be transmitted to another network, and / or whether a handover to another network (Xn-based or NG-based) is possible, can be first configured in the NG-RAN (according to OAM (Operation administration maintenance) or NG configuration procedures). Subsequently, during the PDU session establishment process, the NG-RAN can determine the mobility mode or handover capability for the PDU session through the S-NSSAI included in the PDU session resource configuration request message. If relevant information is also configured in the terminal, similar operations can be performed using S-NSSAI.

[0523] (5) Step S1912: The AMF transmits a PDU session resource setup request message to the NG-RAN containing resource information for the PDU session received from the SMF in Step S1910. This step corresponds to Step 12 of the PDU session setup procedure described in Fig. 8.

[0524] The PDU session resource setup request message includes a PDU session setup acceptance message to be delivered to the terminal. Additionally, through the handover help information included in the PDU session resource setup request message, the NG-RAN can determine whether the PDU session is in a mobility mode or capable of handover to another network.

[0525] (6) Step S1914: The NG-RAN that has accepted the resource allocation request for the PDU session determines the NG-RAN configuration for the PDU session (e.g., SDAP configuration, DRB configuration, etc.) based on the information sent by the SMF and notifies the terminal of this through an RRC reconfiguration message. This step corresponds to Step 13 of the PDU session establishment procedure described in FIG. 8.

[0526] The RRC message delivered to the terminal includes a message accepting the establishment of a PDU session. The terminal, having received configuration information related to the PDU session from the NG-RAN, applies it and responds to the NG-RAN with an RRC reconfiguration completion message.

[0527] Through the handover help information included in the PDU session establishment acceptance message, the terminal can determine whether a mobility mode or a handover to another network is possible for the PDU session.

[0528] (7) Step S1916: Steps 14-21 of the PDU session establishment procedure described in FIG. 9 may be performed. This may be the case where the PDU session being established is an LBO PDU session.

[0529] If the PDU session being established is an HR PDU session, refer to S4.3.2.2.2 of 3GPP TS 23.502.

[0530] (8) Step S1918 / S1920: When a terminal moves to another network while maintaining the PDU session being serviced in the currently registered network, the NG-RAN and the terminal may operate as follows based on the information received in Step S1912 / S1914.

[0531] - Step S1918: If the mobility mode in the handover help information is set to Xn-based or NG-based handover, the NG-RAN may initiate an Xn-based or NG-based handover procedure to the NG-RAN of the target network. Even if an indicator is received that a handover procedure can be used instead of a mobility mode, the Xn-based or NG-based handover procedure may be initiated.

[0532] - Step S1920: If the mobility mode within the handover assistance information is set to N3IWF-based interworking, the terminal can perform the PDU session establishment procedure via the N3IWF. Even if the terminal receives an indicator that the handover procedure cannot be used instead of the mobility mode, the terminal can perform the PDU session establishment procedure via the N3IWF. That is, the terminal can select and register the N3IWF of the network where the PDU session is anchored, establish the PDU session, and perform a handover for the PDU session. To indicate that the PDU session is an existing PDU session while establishing the PDU session, the PDU session establishment request message may include a request type set to "Existing PDU Session" and the PDU session ID for which the handover is to be performed. In this process, the PDU session to be the target of the handover can be selected by considering the mobility mode received from the network. The procedure for establishing a PDU session through N3IWF may follow the procedure for establishing a PDU session described in FIGS. 8 and FIG. 9 and S4.9.2 of 3GPP TS 23.502.

[0533] For examples of the PDU establishment procedure and handover situation through N3IWF, refer to FIGS. 14 to 16 described above.

[0534] If the mobility mode within the handover assistance information is set to LBO PDU session establishment, the terminal can perform the PDU session establishment procedure described in FIGS. 8 and 9. If the terminal receives an indicator that the handover procedure cannot be used instead of the mobility mode and attempts the PDU session establishment procedure via N3IWF in step S1920 but fails, the PDU session establishment procedure described in FIGS. 8 and 9 can be performed.

[0535] According to Embodiment 4 of the present specification described above, in the PDU session establishment procedure, the network may select and inform the terminal of a method to support service continuity between the home SP and the V-SNPN. Additionally, the NG-RAN may know the network configuration status in advance and execute an Xn-based or NG-based handover to the target network to quickly move the terminal to the target network.

[0536] 5. Example 5: Notifying the UE of Mobility Mode Using a UE Configuration Update Procedure

[0537] FIG. 20 illustrates an example of a method for notifying a terminal whether a handover between a PLMN and an SNPN to which the implementation of the present specification applies is possible through a UE configuration update procedure following a PDU session establishment procedure.

[0538] (0) Step S2000 / S2002: The terminal is already registered with the network according to the registration procedure described in FIGS. 6 and FIGS. 7.

[0539] Additionally, the terminal performs the PDU session establishment procedure described in FIGS. 8 and 9 to receive services from the network. This may be the case where the PDU session is an LBO PDU session. If the PDU session being established is an HR PDU session, S4.3.2.2.2 of 3GPP TS 23.502 may be referenced.

[0540] (1) Step S2004: The AMF determines a list of networks (e.g., a list of supported networks) that can ensure service continuity for the terminal using a handover procedure based on at least one of the following information, and initiates a UE configuration update procedure to deliver this to the terminal.

[0541] - List of PDU sessions currently in use by the terminal;

[0542] - Whether the active PDU session is an LBO PDU session or an HR PDU session;

[0543] - Subscriber information received from UDM;

[0544] - Presence or absence of an N14 interface between the currently registered network and another network;

[0545] - If the N14 interface exists, whether an SLA is established between the two networks;

[0546] - When the terminal performs the registration procedure described in FIGS. 11 to 13, FIG. 18 and / or FIG. 19 above, a list of supported networks created during the process;

[0547] 6) Information that can be retrieved from PCF (e.g., preference information - N3IWF-based interworking or RAN-based handover, etc.)

[0548] It can be assumed that information regarding whether an N14 interface exists between the AMF of the PLMN and SNPN that have established an SLA is pre-configured in the AMF.

[0549] The AMF can determine the mobility mode to be used when the terminal moves to another network, instead of and / or with the list of supported networks. The mobility mode may specify any one of handover, N3IWF-based interworking, or LBO PDU session establishment.

[0550] If there are currently active PDU sessions (i.e., established PDU sessions), the AMF can determine the mobility mode for each PDU session. For example, when two PDU sessions (e.g., PDU Session A and PDU Session B) are active, the AMF can determine the mobility mode for PDU Session A to be N3IWF-based interworking and for PDU Session B to be handover.

[0551] The AMF can determine different mobility modes depending on the target network to which the terminal can move. For example, the AMF can decide to use a handover procedure when the target network is PLMN-1 for PDU session A, and N3IWF-based interworking when the target network is SNPN-2.

[0552] Alternatively, instead of a list of supported networks and / or mobility modes, the AMF may determine only whether handover is available when a terminal or an active PDU session moves to another network.

[0553] (2) Step S2006: The AMF includes the list of supported networks determined in Step S2004 in the UE configuration update command and transmits it to the terminal. In this process, the list of supported networks may also be transmitted to the NG-RAN.

[0554] If the mobility mode of the terminal or the mobility mode for an individual PDU session is determined instead of the network list supported in step S2004, the information can be transmitted to the terminal and the NG-RAN.

[0555] (3) Step S2008: After updating the information received in Step S2006, the terminal responds to the AMF using the UE configuration update complete message.

[0556] (4) Step S2010: Step 2b-4 of the UE configuration update procedure disclosed in S4.2.4.2 of 3GPP TS 23.502 is performed.

[0557] Subsequently, when the terminal moves to another network while maintaining the PDU session being serviced in the currently registered network, the NG-RAN and the terminal may operate as follows based on the information received in step S2006. This step is not illustrated in FIG. 20.

[0558] If the target network is included in the list of supported networks and / or the mobility mode is set to Xn-based or NG-based handover, the NG-RAN may initiate an Xn-based or NG-based handover procedure to the target network's NG-RAN. It may also initiate an Xn-based or NG-based handover procedure if it receives an indication that a handover procedure can be used instead of the mobility mode.

[0559] When the mobility mode is set to N3IWF-based interworking, the terminal can perform the PDU session establishment procedure through the N3IWF. Even if the terminal receives an indicator that the handover procedure cannot be used instead of the mobility mode, the terminal can still perform the PDU session establishment procedure through the N3IWF. That is, the terminal can select and register the N3IWF of the network to which the PDU session is anchored, establish the PDU session, and perform a handover for the PDU session. To indicate that the PDU session is an existing PDU session while establishing the PDU session, the PDU session establishment request message may include a request type set to "existing PDU session" and the PDU session ID for which a handover is to be performed. In this process, the PDU session to be the target of the handover can be selected by considering the mobility mode received from the network. The PDU session establishment procedure through the N3IWF may follow the PDU session establishment procedure described in FIGS. 8 and 9 and S4.9.2 of 3GPP TS 23.502.

[0560] For examples of the PDU establishment procedure and handover situation through N3IWF, refer to FIGS. 14 to 16 described above.

[0561] When the mobility mode is set to LBO PDU session establishment, the terminal can perform the PDU session establishment procedure described in FIGS. 8 and 9. When the terminal receives an indicator that the handover procedure cannot be used instead of the mobility mode and attempts the PDU session establishment procedure via N3IWF but fails, the PDU session establishment procedure described in FIGS. 8 and 9 may be performed.

[0562] According to Example 5 of the present specification described above, using the UE configuration update procedure, the network can select and notify the terminal of a method to support service continuity between the home SP and the V-SNPN in accordance with the active PDU session situation.

[0563] 6. Example 6: Notifying the UE of Mobility Mode During the Registration Process with a Target Network

[0564] FIG. 21 illustrates an example of a method in which a target network informs a terminal whether a handover between a PLMN and an SNPN to which the implementation of the present specification applies is possible.

[0565] In FIG. 21, it is assumed that the subscriptions available to the terminal in the source network and the target network are different. Therefore, the terminal must perform a registration procedure in the source network and the target network, respectively.

[0566] (0) Step S2100 / S2102: The terminal is already registered with the source network (5GC #1) according to the registration procedure described in FIGS. 6 and 7.

[0567] Additionally, the terminal performs the PDU session establishment procedure described in FIGS. 8 and 9 to receive services from the source network. This may be the case where the PDU session is an LBO PDU session. If the PDU session being established is an HR PDU session, refer to S4.3.2.2.2 of 3GPP TS 23.502.

[0568] (1) Step S2104: Since the terminal needs to connect to the target network (5GC #2) using a subscription different from the source network, the terminal initiates a registration procedure with the target network. It sends a registration request message containing a subscription for the target network to the NG-RAN of the target network.

[0569] The registration request message may include on-going serving information, which includes a source network ID, a list of services currently in use on the source network, and information on currently active (i.e., already established) PDU sessions (e.g., S-NSSAI, LBO PDU session list, HR PDU session list, home network ID in the case of an HR PDU session).

[0570] The registration request message may include a list of preferred networks described in FIGS. 11 through 13 and / or FIG. 17.

[0571] The same applies even when the terminal registers with the target network using the same subscription as the source network.

[0572] (2) Step S2106: NG-RAN selects AMF.

[0573] The NG-RAN can select an AMF based on 5G-S-TMSI and / or GUAMI. 5G-S-TMSI and / or GUAMI may be received and included in a registration request message transmitted by the terminal. If 5G-S-TMSI and / or GUAMI are not included in the registration request message transmitted by the terminal or are invalid, the NG-RAN can select an AMF based on the requested NSSAI, etc. If it is difficult to select an appropriate AMF, the NG-RAN can select a default AMF based on information configured within the NG-RAN.

[0574] (3) Step S2108: NG-RAN transmits the registration request message received from the terminal to the selected AMF.

[0575] (4) Step S2110: Steps 4-20 of the registration procedure described in FIGS. 6 and FIGS. 7 are performed.

[0576] During the registration process with the target network, the terminal may transmit to the target network the 5G-GUTI assigned by the source network, or the SUCI and NID used during the registration process with the source network. If the target network can locate the source network using this information, it may refer to it when receiving the UE context based on this, or when determining the mobility mode for the terminal based on subscriber information obtained from the UDM (e.g., information about an existing PDU session). Information about an existing PDU session may include the SMF address or ID responsible for the PDU session, and since the SMF address or ID contains the PLMN / SNPN ID, the target network can determine which PLMN / SNPN created the PDU session based on this.

[0577] (5) Step S2112: If the AMF of the target network can accept the registration request of the terminal, it determines the mobility mode that the terminal can use (e.g., handover, N3IWF-based interworking, LBO PDU session establishment, etc.) based on the service information currently in operation received from the terminal, subscriber information received from the UDM, the presence or absence of an N14 interface between the SNPN's AMF and the AMF, SLA, etc.

[0578] It can be assumed that information regarding whether an N14 interface exists between the AMF of the PLMN and SNPN that have established an SLA is pre-configured in the AMF.

[0579] Step S2112 can be performed immediately after the AMF retrieves subscriber information from the UDM.

[0580] The AMF of the target network can determine the mobility mode for each PDU session if there are currently active PDU sessions (i.e., established PDU sessions) in the source network. For example, when two PDU sessions (e.g., PDU Session A and PDU Session B) are active, the AMF can determine the mobility mode for PDU Session A to N3IWF-based interworking and for PDU Session B to handover.

[0581] Alternatively, the AMF may determine only whether a handover is available when the terminal or active PDU session moves to the target network, instead of the mobility mode.

[0582] If a registration request message is transmitted in step S2104 including a preferred network list, the AMF of the target network can determine a list of supported networks that the terminal can use based on the preferred network list received from the terminal, subscriber information received from the UDM, the presence or absence of an N14 interface between the SNPN's AMF and the terminal, SLA, etc. Network IDs included in the list of supported networks can be determined within the preferred network list.

[0583] (6) Step S2114: The AMF of the target network sends a DL NAS forwarding message to the NG-RAN of the target network to create a UE context in the NG-RAN.

[0584] The DL NAS forwarding message may include a registration acceptance message. The DL NAS forwarding message and the registration acceptance message may include the mobility mode determined in step S2112.

[0585] Instead of the DL NAS delivery message, an initial context setup request message can be used.

[0586] (7) Step S2116: The NG-RAN of the target network transmits the registration acceptance message received from the AMF of the target network in Step S2114 to the terminal. When the terminal receives the registration acceptance message including the mobility mode, it can determine which mobility mode to use when moving from the source network to the target network.

[0587] Subsequently, steps 22-25 of the registration procedure described in FIG. 7 are performed. These steps are not illustrated in FIG. 21.

[0588] Subsequently, when the terminal moves to the target network while maintaining the PDU session being serviced in the source network, it may operate as follows based on the information received in step S2116. This step is not illustrated in FIG. 21.

[0589] When the mobility mode is set to Xn-based or NG-based handover, the terminal can notify the NG-RAN of the source network that the handover procedure can be used when the terminal moves to the target network. Therefore, the NG-RAN of the source network can subsequently initiate an Xn-based or NG-based handover to the NG-RAN of the target network. An Xn-based or NG-based handover can also be initiated if an indicator is received that the handover procedure can be used instead of the mobility mode.

[0590] When the mobility mode is set to N3IWF-based interworking, the terminal can perform the PDU session establishment procedure through the N3IWF. Even if the terminal receives an indicator that the handover procedure cannot be used instead of the mobility mode, the terminal can still perform the PDU session establishment procedure through the N3IWF. That is, the terminal can select and register the N3IWF of the network to which the PDU session is anchored, establish the PDU session, and perform a handover for the PDU session. To indicate that the PDU session is an existing PDU session while establishing the PDU session, the PDU session establishment request message may include a request type set to "existing PDU session" and the PDU session ID for which a handover is to be performed. In this process, the PDU session to be the target of the handover can be selected by considering the mobility mode received from the network. The PDU session establishment procedure through the N3IWF may follow the PDU session establishment procedure described in FIGS. 8 and 9 and S4.9.2 of 3GPP TS 23.502.

[0591] For examples of the PDU establishment procedure and handover situation through N3IWF, refer to FIGS. 14 to 16 described above.

[0592] When the mobility mode is set to LBO PDU session establishment, the terminal can perform the PDU session establishment procedure described in FIGS. 8 and 9. When the terminal receives an indicator that the handover procedure cannot be used instead of the mobility mode and attempts the PDU session establishment procedure via N3IWF but fails, the PDU session establishment procedure described in FIGS. 8 and 9 may be performed.

[0593] When a terminal notifies the source network that a handover procedure is available, it may also transmit a list of PDU sessions with the mobility mode set to Xn-based or NG-based handover. In this case, the NG-RAN of the source network may transmit only the PDU sessions to the target network.

[0594] Alternatively, the terminal may not transmit any information to the source network regarding whether a handover procedure is possible. In this case, the NG-RAN of the source network will attempt to transmit all PDU sessions to the target network, and the target network may accept only PDU sessions for which a handover is possible. For PDU sessions for which a handover is rejected, the terminal may attempt an N3IWF-based interworking or LBO PDU session establishment procedure based on the mobility mode.

[0595] The terminal may not include a preferred network list in the registration request message, and instead, the AMF that receives the registration request message from the terminal may receive information (e.g., network ID) about the SNPN that has established an SLA with the PLMN from the UDM and determine the preferred network list in step S2112. Alternatively, the UDM may store only information about networks that the terminal can register, and information about networks with established SLAs may be configured in the AMF. In this case, the AMF may consider whether an SLA has been established when determining the list of supported networks.

[0596] According to 6 of the embodiment of the present specification described above, during the process of a terminal registering with a target network, the AMF of the target network may select and provide a method to support service continuity with the source network.

[0597] According to Example 1 of the present specification described above, it is as follows.

[0598] During the mobility scenario, the target network may notify the terminal of a mobility instruction to instruct the terminal to hand over the HR PDU session using an existing PDU session indicator during the registration process.

[0599] During the scenario of movement from Home SP to SNPN #1, the target network may notify the terminal of a mobility instruction to instruct how to hand over the LBO PDU session (i.e., non-roaming PDU session) anchored to the Home SP during the registration process to the target network.

[0600] Mobility instructions are based on the interworking situation between the source network and the target network (e.g., interworking such as roaming, N3IWF-based interworking, or no interworking support). Depending on the mobility instructions, the terminal can hand over an LBO PDU session to the target network using an existing PDU session indicator or an initial request indicator.

[0601] Alternatively, the source network may provide mobility indicators during the registration process. For example, if the terminal selects a target SNPN based on manual selection, the terminal may select an SNPN that supports PDU session handover. Additionally, the terminal may use information from the target network to hand over an LBO PDU session using an existing PDU session indicator or an initial request indicator.

[0602] If no mobility instruction is received, the terminal may perform a handover of the LBO PDU session in the following order.

[0603] - Procedure using existing PDU session indicators

[0604] - Procedure using initial request indicators

[0605] Each embodiment described above with reference to the drawings in this specification may be performed individually, or some features of each embodiment may be performed in combination with each other.

[0606] The claims described in this specification may be combined in various ways. For example, the technical features of the method claims in this specification may be combined to be implemented as a device, and the technical features of the device claims in this specification may be combined to be implemented as a method. Furthermore, the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a device, and the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a method. Other implementations are within the scope of the following claims.

Claims

Claim 1 delete Claim 2 delete Claim 3 delete Claim 4 delete Claim 5 delete Claim 6 delete Claim 7 delete Claim 8 delete Claim 9 delete Claim 10 A method performed by a terminal (UE; User Equipment), comprising: a step of registering with a source SNPN (Stand-alone Non-Public Network) through a Next Generation Radio Access Network (NG-RAN) node of the source SNPN; a step of establishing a Protocol Data Unit (PDU) session with the source SNPN through an NG-RAN node of the source SNPN; a step of transmitting a Registration Request message to an Access and Mobility Management Function (AMF) of the target SNPN through an NG-RAN node of the target SNPN, wherein the Registration Request message includes i) a 5G Globally Unique Temporary Identifier (5G-GUTI) assigned by the source SNPN, and ii) a Network ID (NID) of the source SNPN; and a step of receiving a Registration Accept message, which is a response to the Registration Request message, from the AMF of the target SNPN through an NG-RAN node of the target SNPN. Claim 11 delete Claim 12 delete Claim 13 A method according to claim 10, wherein the registration request message further comprises at least one of a list of services currently used in the source SNPN and / or information about established PDU sessions. Claim 14 A method according to claim 10, wherein the terminal communicates with at least one of a mobile device, a network, and / or an autonomous vehicle other than the terminal. Claim 15 One or more processors; and one or more memories capable of storing instructions and being connected to operate with said one or more processors, wherein the operation performed based on said instructions being executed by said at least one processor comprises: a step of registering with said source SNPN (Stand-alone Non-Public Network) through an NG-RAN (Next Generation Radio Access Network) node of said source SNPN; a step of establishing a PDU (Protocol Data Unit) session with said source SNPN through an NG-RAN node of said source SNPN; a step of transmitting a Registration Request message to an AMF (Access and Mobility Management Function) of said target SNPN through an NG-RAN node of said target SNPN, said registration request message comprising i) a 5G-GUTI (5G Globally Unique Temporary Identifier) ​​assigned by said source SNPN, and ii) a NID (Network ID) of said source SNPN; A UE comprising the step of receiving a Registration Accept message, which is a response to the registration request message, from the AMF of the target SNPN through the NG-RAN node of the target SNPN. Claim 16 delete Claim 17 delete Claim 18 delete Claim 19 A method performed by an Access and Mobility Management Function (AMF) of a target Stand-alone Non-Public Network (SNPN), comprising the steps of: receiving a Registration Request message from a User Equipment (UE) through a Next Generation Radio Access Network (NG-RAN) node of the target SNPN; wherein the Registration Request message includes i) a 5G-GUTI (5G Globally Unique Temporary Identifier) ​​assigned by a source SNPN, and ii) a Network ID (NID) of the source SNPN; determining the source SNPN based on i) the 5G-GUTI assigned by the source SNPN, and ii) the NID of the source SNPN; receiving a UE context from the source SNPN; and transmitting a Registration Accept message, which is a response to the Registration Request message, to the UE through an NG-RAN node of the target SNPN. Claim 20 delete Claim 21 delete

Images