Handover security

Abstract

The present disclosure provides a method. The method may comprise the steps of: receiving, from a UE, a first RRC reconfiguration complete message; transmitting a path switch request message to a mobility-related network entity; receiving, from the network entity, a path switch request acknowledge message; transmitting, to one or more other base stations, a new KgNB* for a candidate cell; transmitting an RRC reconfiguration message to the UE; and receiving, from the UE, a second RRC reconfiguration complete message.

Description

Handover security

[0001] This specification relates to mobile communication.

[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, usage, and requirements, including eMBB (enhanced Mobile Broadband), mMTC (massive Machine Type-Communications), and URLLC (Ultra-Reliable and Low Latency Communications). NR must be forward compatible by nature.

[0005] L1 / L2 Layer Triggered Mobility (LTM) can be supported as an example of a procedure for rapid handover. However, there is a problem in that security is not effectively protected while the LTM procedure is being executed.

[0006] According to one embodiment of the present specification, a method is provided. The method may include the steps of: receiving a first RRC reset complete message from a UE; transmitting a route switch request message to a network entity related to mobility; receiving a route switch request acknowledge message from said network entity; transmitting a new KgNB* for a candidate cell to one or more other base stations; transmitting an RRC reset message to a UE; and receiving a second RRC reset complete message from said UE.

[0007] According to one embodiment, a device for implementing the above method is provided.

[0008] According to one embodiment of the present specification, a method is provided. The method may include the step of receiving a path switch request message from a target base station; and the step of transmitting a path switch request acknowledge message to the target base station.

[0009] According to one embodiment, a device for implementing the above method is provided.

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

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

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

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

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

[0015] FIG. 7 is an example in which an authentication procedure is disclosed according to one embodiment of the disclosure of the present specification.

[0016] FIG. 8 is an example of a primary authentication procedure according to one embodiment of the disclosure of the present specification.

[0017] FIG. 9 is an example of a key hierarchy structure according to one embodiment of the disclosure of the present specification.

[0018] FIG. 10 is an example of key chaining according to one embodiment of the disclosure of the present specification.

[0019] FIG. 11 is an example of key handling based on a handover procedure according to one embodiment of the disclosure of the present specification.

[0020] Figure 12 is an example of the LTM procedure.

[0021] FIGS. 13a to 13c are first examples of a procedure according to one embodiment of the disclosure of the present specification.

[0022] FIGS. 14a to 14c are second examples of a procedure according to one embodiment of the disclosure of the present specification.

[0023] FIG. 15 illustrates an example of operations according to one embodiment of the disclosure of the present specification.

[0024] 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 Multi-Carrier 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).

[0025] 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.

[0026] 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.

[0027] 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."

[0028] 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."

[0029] 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."

[0030] 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."

[0031] 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 (e.g., PDCCH)," "PDCCH" may be proposed as an example of "control information."

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

[0033] 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.

[0034] 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.

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

[0036] 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.

[0037] The three main requirement 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.

[0038] 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.

[0039] 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.

[0040] 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), Internet-Of-Things (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 (Augmented Reality) / VR (Virtual Reality) / MR (Mixed Reality) devices and may be implemented in the form of HMDs (Head-Mounted Devices) and HUDs (Head-Up Displays) 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.

[0041] 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.

[0042] 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).

[0043] 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) can 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.

[0044] 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.

[0045] 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).

[0046] Frequency Range Definition Frequency Range Subcarrier Spacing FR1 450 MHz - 6000 MHz 15, 30, 60 kHz FR2 24 250 MHz - 52600 MHz 60, 120, 240 kHz

[0047] 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. For example, 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).

[0048] Frequency Range Definition Frequency Range Subcarrier Spacing FR1 4 10 MHz - 7 125 MHz 15, 30, 60 kHz FR2 24 250 MHz - 5 2600 MHz 60, 120, 240 kHz

[0049] 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 eMTC (enhanced MTC). 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 with consideration 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.

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

[0051] In FIG. 2, the first wireless device (100) and / or the second wireless device (200) may be implemented in various forms depending on the use example / service. For example, {the first wireless device (100) and the second wireless device (200)} may correspond to at least one of {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. The first wireless device (100) and / or the second wireless device (200) may be composed of various components, devices / parts and / or modules.

[0052] 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).

[0053] 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). Additionally and / or generally, the memory (104) may be placed outside the processing chip (101).

[0054] 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).

[0055] 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 firmware and / or software code (105) that implements code, instructions, and / or a set of instructions that perform the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification when executed by the processor (102). For example, firmware and / or software code (105) may implement instructions that perform the descriptions, functions, procedures, proposals, methods, and / or operation flowcharts disclosed in this specification when executed by the processor (102). For example, firmware and / or software code (105) may control the processor (102) to perform one or more protocols. For example, firmware and / or software code (105) may control the processor (102) to perform one or more wireless interface protocol layers.

[0056] Here, the processor (102) and memory (104) may be part of a communication modem / circuit / chip designed to implement RAT (e.g., LTE or NR). A transceiver (106) may be connected to the processor (102) and 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.

[0057] 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).

[0058] 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). Additionally and / or generally, the memory (204) may be placed outside the processing chip (201).

[0059] 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).

[0060] 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 firmware and / or software code (205) that implements code, instructions, and / or sets of instructions that perform descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed in this specification when executed by the processor (202). For example, firmware and / or software code (205) may implement instructions that perform descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed in this specification when executed by the processor (202). For example, firmware and / or software code (205) may control the processor (202) to perform one or more protocols. For example, firmware and / or software code (205) may control the processor (202) to perform one or more wireless interface protocol layers.

[0061] 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.

[0062] 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, an RLC (Radio Link Control) layer, a PDCP (Packet Data Convergence Protocol) layer, an 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), one or more SDUs (Service Data Units), 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) including a PDU, SDU, message, control information, data, or information according to the description, function, procedure, proposal, method, and / or operation flowchart 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 description, function, procedure, proposal, method, and / or operation flowchart disclosed in this specification.

[0063] One or more processors (102, 202) may be referred to as a controller, a microcontroller, a microprocessor, and / or a microcomputer. 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). For example, one or more processors (102, 202) may be composed of a set of communication control processors, application processors (APs), electronic control units (ECUs), central processing units (CPUs), graphic processing units (GPUs), and memory control processors. 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 be composed of Random Access Memory (RAM), Dynamic RAM (DRAM), Read-Only Memory (ROM), Erasable Programmable ROM (EPROM), flash memory, volatile memory, non-volatile memory, hard drive, register, 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.

[0064] 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.

[0065] One or more transceivers (106, 206) may be connected to one or more antennas (108, 208). Additionally and / or generally, one or more transceivers (106, 206) may include 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., mentioned 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).

[0066] 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).

[0067] Although not illustrated in FIG. 2, the wireless device (100, 200) may include additional components. The additional components (140) may be configured in various ways depending on the type of the wireless device (100, 200). For example, the additional components (140) may include at least one of a power unit / battery, an input / output (I / O) device (e.g., audio I / O port, video I / O port), a driving unit, and a computing unit. The additional components (140) may be connected to one or more processors (102, 202) through various technologies, such as wired or wireless connections.

[0068] In an implementation of the present specification, the UE may operate as a transmitting device in the uplink and as a receiving device in the downlink. In an implementation of the present 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 the present specification or to control a transceiver (106) to perform UE operations according to an implementation of the present 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 the present specification or to control a transceiver (206) to perform base station operations according to an implementation of the present specification.

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

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

[0071] Referring to FIG. 3, the UE (100) can correspond to the first wireless device (100) of FIG. 2.

[0072] The UE (100) includes a processor (102), memory (104), transceiver (106), one or more antennas (108), a power management module (141), a battery (142), a display (143), a keypad (144), a SIM (Subscriber Identification Module) card (145), a speaker (146), and a microphone (147).

[0073] 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 DSP, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), 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.

[0074] 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.

[0075] 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.

[0076] The power management module (141) manages the power of the processor (102) and / or the transceiver (106). The battery (142) supplies power to the power management module (141).

[0077] The display (143) outputs the result processed by the processor (102). The keypad (144) receives input to be used by the processor (102). The keypad (144) can be displayed on the display (143).

[0078] A SIM card (145) is an integrated circuit for securely storing an International Mobile Subscriber Identity (IMSI) 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.

[0079] The speaker (146) outputs sound-related results processed by the processor (102). The microphone (147) receives sound-related input to be used by the processor (102).

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

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

[0082] - AUSF (Authentication Server Function)

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

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

[0085] - USDF (Unstructured Data Storage Function)

[0086] - NEF (Network Exposure Function)

[0087] - I-NEF (Intermediate NEF)

[0088] - NRF (Network Repository Function)

[0089] - NSSF (Network Slice Selection Function)

[0090] - PCF (Policy Control Function)

[0091] - SMF (Session Management Function)

[0092] - UDM (Unified Data Management)

[0093] - UDR (Unified Data Repository)

[0094] - UPF (User Plane Function)

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

[0096] - AF (Application Function)

[0097] - UE (User Equipment)

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

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

[0100] - NWDAF (Network Data Analytics Function)

[0101] - CHF (CHarging Function)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0126] - 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)

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

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

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

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

[0131] 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.

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

[0133] - Mobility registration update; or

[0134] - Periodic registration update; or

[0135] - Emergency registration

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

[0137] The general registration procedure of Figures 5 and 6 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.

[0138] First, the procedure of Fig. 5 is explained.

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

[0140] 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.

[0141] The registration request message may include a registration type. The registration type indicates whether the UE wants to perform an initial registration (e.g., the UE is in the RM-DEREGISTERED state), or a mobility registration update (e.g., the UE is in the RM-REGISTERED state and initiates the registration process because the UE moves, or the UE wants to update a capability or protocol parameter, or requests a change to the set of network slices allowed for the UE to use), or a periodic registration update (e.g., 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 (e.g., the UE is in the restricted service state).

[0142] 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.

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

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

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

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

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

[0148] 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.

[0149] 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.

[0150] 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.

[0151] 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.

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

[0153] 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, where available.

[0154] 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.

[0155] 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.

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

[0157] 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.

[0158] 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.

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

[0160] (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.

[0161] (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.

[0162] (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.

[0163] (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).

[0164] (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.

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

[0166] (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 to the new AMF is complete. If the authentication / security procedure fails, registration is rejected and the new AMF may call the Namf_Communication_RegistrationCompleteNotify service operation to the previous AMF with a reject indication reason code. The previous AMF may continue as if no UE context passing service operation was received.

[0167] (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.

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

[0169] Now, the procedure of Fig. 6 following the procedure of Fig. 5 is explained.

[0170] (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.

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

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

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

[0174] (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.

[0175] (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.

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

[0177] (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.

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

[0179] 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.

[0180] 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.

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

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

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

[0184] (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.

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

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

[0187] Below, an example of a security procedure between a UE and a 5G network function is described.

[0188] UEs, base stations, and networks performing mobile communication may use examples of security procedures described below.

[0189] Explains examples of primary authentication and key agreement. Explains examples of authentication frameworks.

[0190] The purpose of the primary authentication and key consensus procedure is to enable mutual authentication between the UE and the network and to provide keying material that can be used between the UE and the serving network in subsequent security procedures. The keying material generated by the primary authentication and key consensus procedure is the anchor key K provided by the AUSF of the home network to the SEAF of the serving network. SEAF Creates.

[0191] Keys for two or more security contexts can be derived from KSEAF without the need to execute new authentication. As a specific example, authentication executed over a 3GPP access network may provide a key that establishes security between a UE and an N3IWF used for untrusted non-3GPP access.

[0192] Anchor Key K SEAF is K AUSF It is derived from the intermediate key called K AUSF It is established between the UE and HN as a result of the first authentication process. K AUSFDepending on the home operator's policy regarding the use of the key, for example, if a control plane solution for roaming coordination or a UE parameter update procedure or Authentication and Key Management for Applications (AKMA) is supported by HPLMN, it can be securely stored in AUSF.

[0193] UE and serving networks support EAP-AKA and 5G AKA authentication methods.

[0194] The USIM can reside in the UICC. The UICC can be removable or non-removable.

[0195] If the terminal supports 3GPP access functions, for non-3GPP access networks, the credentials used for EAP-AKA and 5G AKA must reside in the UICC.

[0196] Once the 5G AKA first-level certification is successfully completed, the AMF can initiate the NAS security mode command procedure with the UE.

[0197] Explains an example of the EAP framework.

[0198] The EAP framework is specified in RFC 3748. It defines the roles of peers, pass-through authenticators, and backend authentication servers. The backend authentication server acts as the EAP server that terminates the EAP authentication method with the peer. In 5G systems, the EAP framework is supported in the following ways:

[0199] - The UE can act as a peer.

[0200] - SEAF can act as a pass authenticator.

[0201] - AUSF can serve as a backend authentication server.

[0202] Explains an example of the granularity of anchor key binding to a serving network.

[0203] The primary authentication and key consensus procedure can bind KSEAF to the service network. Binding to the serving network prevents one serving network from claiming to be another serving network, and thus provides implicit serving network authentication to the UE.

[0204] This implicit serving network certification must be provided to the UE regardless of the access network technology, so it applies to both 3GPP and non-3GPP access networks.

[0205] Additionally, the anchor key provided to the serving network can be specific to the authentication performed between the UE and the 5G core network. For example, the key K transmitted from the home network to the serving network in previous mobile network generations. ASME It must be cryptographically separated from.

[0206] Anchor key binding can be achieved by including a parameter called "serving network name" in the key derivation chain leading from the long-term subscriber key to the anchor key.

[0207] Explains an example of the configuration of a serving network name.

[0208] The serving network name is used to derive the anchor key. This serves two purposes:

[0209] - The anchor key binds the anchor key to the serving network, including the serving network identifier (SN Id).

[0210] - Verify that the anchor key, including the service code set to "5G", is specific for authentication between the 5G core network and the UE.

[0211] In 5G AKA, serving network names have a similar purpose of binding RES* and XRES* to serving networks.

[0212] The serving network name is formed by connecting the service code and SN Id with the separator ":" so that the service code comes before the SN Id.

[0213] SN Id identifies the PLMN providing the service and is defined as an SNN-network identifier, except for standalone private networks.

[0214] This explains an example of configuring a serving network name by a UE.

[0215] The UE can configure the service network name as follows:

[0216] - Set the service code to "5G".

[0217] - Set the network identifier to the SN Id of the authenticating network.

[0218] - Connect the service code and SN ID with the separator ":".

[0219] This explains an example of configuring serving network names by SEAF.

[0220] SEAF configures the service network name as follows:

[0221] - Set the service code to "5G".

[0222] - Set the network identifier to the SN Id of the serving network to which AUSF transmits authentication data.

[0223] - Connect the service code and SN ID with the separator ":".

[0224] This shows an example of the procedure for starting authentication and selecting an authentication method.

[0225] According to the example in Fig. 7, the first authentication can be initiated.

[0226] The following drawings are made 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.

[0227] FIG. 7 is an example in which an authentication procedure is disclosed according to one embodiment of the disclosure of the present specification.

[0228] Figure 7 shows an example of the start of the authentication process and the selection of the authentication method.

[0229] A UE may send an N1 message (e.g., including a registration request message) to a Security Anchor Function (SEAF). For example, the SEAF may initiate authentication for the UE according to the SEAF's policy during the process of establishing a signaling association with the UE. The UE may use SUCI or 5G-GUTI in the registration request. For example, the registration request message may include SUCI or 5G-GUTI.

[0230] For example, SEAF can be a function responsible for the authentication function of a serving AMF. For instance, an AMF may include an entity named SEAF, or the AMF may perform operations related to SEAF.

[0231] SEAF can send an authentication request message (e.g., Nausf_UEAuthentication_Authentication_Request_Message) to the Authentication Server Function (AUSF). Whenever SEAF wishes to initiate authentication, it can call the Nausf_UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate request message to the AUSF.

[0232] Here, the Nausf_UEAuthenticate_authentication request message may include one of the following:

[0233] - SUCI, or

[0234] - SUPI.

[0235] If SEAF has a valid 5G-GUTI and re-authenticates the UE, SEAF may include SUPI in the Nausf_UEAuthentication_Authenticate request message. Otherwise, SUCI may be included in the Nausf_UEAuthentication_Authenticate Request.

[0236] The Nausf_UEAuthentication_Authenticate request may additionally include the serving network name.

[0237] The Nausf_UEAuthentication_Authenticate request may additionally include a disaster roaming service indication.

[0238] Upon receiving a Nausf_UEAuthentication_Authenticate request message, the AUSF can determine whether the SEAF requesting from the serving network is authorized to use the serving network name in the Nausf_UEAuthentication_Authenticate request by comparing it with the expected serving network name. The AUSF temporarily stores the received serving network name. If the serving network is not authorized to use the serving network name, the AUSF may respond with "Unauthorized serving network" in the Nausf_UEAuthentication_Authenticate response.

[0239] In the case of disaster roaming, AUSF can check local settings and, if allowed, send a Nudm_UEAuthentication_Get request to the UDM.

[0240] The Nudm_UEAuthentication_Get request sent from AUSF to UDM includes the following information:

[0241] - SUCI or SUPI;

[0242] - Serving network name;

[0243] - Disaster roaming service indication if received from SEAF.

[0244] The UDM that receives the Nudm_UEAuthentication_Get request calls SIDF when SUCI is received. SIDF obtains SUPI by unhiding SUCI before the UDM processes the request.

[0245] UDM / ARPF selects an authentication method based on SUPI.

[0246] In the case of disaster roaming, UDM checks the local configuration and, if allowed, proceeds with the selected authentication method.

[0247] Referring to the example in Fig. 8, an example of a primary authentication procedure triggered by a home network is described.

[0248] Support for Home Network Triggered Authentication is optional for the Home Network (HN) and Serving Network (SN). If both networks (HN and SN) support Home Network Triggered Primary Authentication, the following description applies.

[0249] Examples of security mechanisms are as follows.

[0250] UDM can also take local policies into account to initiate primary authentication for procedures initiated by the UE (e.g., UE registration in 5GC) or for events of the UE (e.g., SoR / UPU) or other NFs.

[0251] The following drawings are made 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.

[0252] FIG. 8 is an example of a primary authentication procedure according to one embodiment of the disclosure of the present specification.

[0253] Figure 8 is an example of a primary authentication procedure triggered by a home network.

[0254] Steps 0a and 0b are prerequisites for the entire procedure of Fig. 8.

[0255] 0a. To determine when to trigger the first authentication process, a carrier authentication policy can be pre-configured in the UDM.

[0256] 0b. A UE may register with a network. As part of the registration process, a serving AMF may register the UE with a UDM via Nudm_UECM_Registration in accordance with Section 4.2.2.2.2 of TS 23.502 V18.5.0 or the examples in FIGS. 5 and 6. To create an implicit subscription for potential home network-triggered re-authentication using the Nudm_UECM_Re-AuthenticationNotification service operation as in Step 2, the UDM may provide a callback URI within the AMF registration.

[0257] 1a-c. Based on events or authentication policies, the UDM may decide on its own and perform home network trigger primary authentication as described in the following steps. For example, an NF such as AAnF may use the UDM service to send a Nudm_UECM_AuthTrigger request to the UDM for primary authentication. The NF may send a Nudm_UECM_AuthTrigger request message to the UDM along with the target UE's SUPI. The UDM may approve the request with a Nudm_UECM_AuthTrigger response to the NF.

[0258] If different AMFs are registered with the UDM for different accesses, the UDM can select one AMF to perform re-authentication. The criteria for selecting an AMF may vary depending on the local UDM authentication policy.

[0259] 2. UDM can send a Nudm_UECM_Re-AuthenticationNotification message to AMF / SEAF along with the UE's SUPI.

[0260] 3. After receiving the Nudm_UECM_Re-AuthenticationNotification message from the UDM, the AMF / SEAF may determine whether to execute the primary authentication procedure based on its own local authentication policy and the UE status (e.g., whether the UE is in a handover or is already authenticated by the AMF before receiving the authentication notification from the UDM). If the AMF / SEAF determines that it cannot execute primary authentication as described in Step 4 (e.g., due to a local policy), the AMF / SEAF may send an authentication response message to the UDM indicating the cause of the failure; otherwise, it may approve the request. If the AMF / SEAF approves the request but cannot initiate primary authentication for the UE (e.g., because it cannot connect to the UE), the AMF / SEAF may set the authentication pending flag. Upon receiving a failure from the AMF, the UDM may check if another AMF is available through a different connection. If available, the UDM may select another AMF and retry Step 2.

[0261] When a UE reconnects to the same AMF or becomes able to connect, the AMF checks the authentication pending flag and can perform re-authentication if necessary. Once UE re-authentication is complete, the AMF can reset the authentication pending flag.

[0262] 4. As defined in the example of Fig. 9, the AMF / SEAF can initiate the first certification procedure.

[0263] UDM can execute other procedures (e.g., SoR / UPU) depending on the reason that triggered the (re)authentication procedure in Step 1.

[0264] Below, with reference to the example in Fig. 9, an example of a key hierarchy, key derivation, and distribution scheme is described.

[0265] An example of a key hierarchy is as follows.

[0266] For requirements regarding keys for 5GC and NG-RAN, refer to TS 33.501 V18.5.0 S5.1.3. Below, the keys for key hierarchy generation in 5GS are described in detail.

[0267] The following drawings are made 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.

[0268] FIG. 9 is an example of a key hierarchy structure according to one embodiment of the disclosure of the present specification.

[0269] The example in Fig. 9 shows an example of key hierarchy generation in 5GS.

[0270] The key associated with authentication (see Fig. 9) includes the following keys: K, CK / IK. For Extensible Authentication Protocol - Authentication and Key Agreement (EAP-AKA'), the keys CK', IK' are keys derived from CK, IK as specified in Section 6.1.3.1 of TS 33.501 V18.5.0. For example, EAP-AKA' may be a description based on RFC4187 (EAP-AKA). For example, RFC4187 (EAP-AKA) may be modified for 3gpp use and enhanced into RFC5448 (EAP-AKA').

[0271] The key hierarchy (see Fig. 9) includes the following keys: K AUSF , K SEAF , K AMF , K NASint , K NASenc , K N3IWF , K gNB , K RRCint , K RRCenc , K UPint and K UPenc .

[0272] The key for AUSF in a home network (e.g., HPLMN in the example of Fig. 9) is as follows:

[0273] - K AUSF It is a derived key:

[0274] - i) For example, in the EAP-AKA case, ME and AUSF K from CK', IK' AUSF Derives. Here, AUSF receives CK' and IK'. CK' and IK' are part of the AV (Authentication Vector) transformed by ARPF; or,

[0275] - ii) For example, in the 5G AKA case, ME and ARPF K from CK and IK AUSF Derive . Here, AUSF is K AUSF Can receive. KAUSF is part of the 5G HE AV (Home Environment Authentication Vector) generated from ARPF.

[0276] - K SEAF ME and AUSF are K AUSF It is the anchor key derived from. K SEAF AUSF provides to the SEAF of the serving network.

[0277] The keys for AMF in network services are as follows:

[0278] - K AMF is the key derived by ME and SEAF from KSEAF. K AMF It can be additionally derived by ME and source AMF when performing horizontal key derivation.

[0279] The key for NAS signaling is as follows:

[0280] - K NASint ME and AMF are K AMF It is the key derived from. K NASint It can be used only to protect NAS signaling with a specific integrity algorithm.

[0281] - K NASenc is the key derived by ME and AMF from KAMF. K NASenc It can be used to protect NAS signaling with a particular encryption algorithm.

[0282] The key for NG-RAN is as follows:

[0283] - K gNB is the key derived by ME and AMF from KAMF. When ME and source gNB perform horizontal key derivation or vertical key derivation, K by ME and source gNB gNB is additionally derived. K gNB is K between ME and ng-eNBeNB It can be used as.

[0284] The key for UP traffic is as follows:

[0285] - K UPenc is the key derived by ME and gNB from KgNB. K UPenc It can only be used for UP traffic protection using a specific encryption algorithm.

[0286] - K UPint ME and gNB are K gNB It is the key derived from. K UPint It can be used to protect UP traffic between ME and gNB using a specific integrity algorithm.

[0287] The keys for RRC signaling are as follows:

[0288] - K RRCint is the key derived by ME and gNB from KgNB. For example, K RRCint It can only be used for RRC signaling protection using a specific integrity algorithm.

[0289] - K RRCenc is the key derived by ME and gNB from KgNB. For example, K RRCenc It can only be used for RRC signal protection using a specific encryption algorithm.

[0290] The middle keys are as follows:

[0291] Next Hop (NH) is a key derived by ME and AMF to provide forward security, as described in TS 33.501 V18.5.0 Clause A.10.

[0292] - K NG-RAN* is a key derived by ME and NG-RAN (e.g., gNB or ng-eNB) when performing horizontal key derivation or vertical key derivation using KDF as specified in TS 33.501 V18.5.0 Clause A.11 / A.12, as specified in TS 33.501 V18.5.0 6.9.2.1.1.

[0293] - K AMF ' is a key that can be derived by the ME and the AMF when the UE moves from one AMF to another using the KDF specified in Annex A.13 of TS 33.501 V18.5.0 during the inter-AMF mobility procedure specified in Clause 6.9.3 of TS 33.501 V18.5.0.

[0294] The key for non-3GPP access is as follows:

[0295] - K N3IWF is a key derived by ME and AMF from K AMF for the non-3GPP access. K N3IWF is not forwarded between N3IWFs.

[0296] - K N3IWF ME and AMF are K for non-3GPP access AMF It is the key derived from. K N3IWF is not transmitted between N3IWF.

[0297] Explains examples of security handling related to mobility.

[0298] For example, I will explain an example of handling keys during a handover.

[0299] Explains examples of key handles related to the access stratum.

[0300] K during handover NG-RAN The general principle of key processing for * / NH is illustrated in Fig. 10.

[0301] The following drawings are made 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.

[0302] FIG. 10 is an example of key chaining according to one embodiment of the disclosure of the present specification.

[0303] Figure 10 shows an example of a model for handover key chaining.

[0304] Explains an overview of the key processing model to clarify the intended structure of key derivation.

[0305] If an initial AS security context needs to be established between the UE and the gNB / ng-eNB, the AMF and the UE KgNB and derive the Next Hop parameter (NH). K gNB and NH is K AMF It is derived from. The NH Chaining Counter (NCC) is for each K gNB and is associated with NH parameters. All K gNB is associated with the NCC corresponding to the derived NH value. At initial setup, K gNB is K AMF Directly derived from, and K gNB It is considered to be associated with a virtual NH parameter with an NCC value of 0. The NH value derived during initial setup is associated with an NCC value of 1.

[0306] AMF is K gNBWhether to send the key or the {NH, NCC} pair to the serving gNB / ng-eNB is described in detail below in “Key Derivation for Context Modification Procedure” and “Key Derivation for Context Modification Procedure”. The AMF does not send the NH value to the gNB / ng-eNB during initial connection setup. The gNB / ng-eNB initializes the NCC value to 0 after receiving the NGAP Initial Context Setup Request message.

[0307] The UE and gNB / ng-eNB use K to protect communication with each other gNB Uses. K to be used between the UE and the target gNB / ng-eNB during handover and the transition from RRC_INACTIVE to RRC_CONNECTED. gNB The standard is K NG-RAN It is called *, and K NG-RAN * is the currently active K gNB Or it is derived from the NH parameter. K NG-RAN This currently active K gNB When derived from, this is called horizontal key derivation (see Fig. 10). K NG-RAN When derived from this NH parameter, it is called vertical key derivation (see Fig. 10).

[0308] NH parameters can be calculated only by the UE and the AMF. NH parameters can be arranged so that they are provided from the AMF to the gNB / ng-eNB in ​​a manner that achieves forward security.

[0309] In a handover with vertical key derivation, after NH is additionally bound to the target Physical Cell Identifier (PCI) and the corresponding frequency ARFCN-DL, K in the target gNB / ng-eNB gNB It can be used as. In a horizontal key derivation handover, the currently active K gNBAfter additionally binding to the target PCI and the corresponding frequency ARFCN-DL, K in the target gNB / ng-eNB gNB로 It can be used.

[0310] Explains an example of key handling related to Non-Access Stratum (NAS).

[0311] The NAS aspects to be considered during mobility-related procedures are K AMF This may include the possibility of change, the possibility of changing the NAS algorithm when the AMF changes, and the possibility of the existence of parallel NAS connections. It is possible that the source AMF and the target AMF do not support the same set of NAS algorithms or have different priorities regarding the use of NAS algorithms. In this case, the target AMF uses the NAS algorithm ID and NAS algorithm type as inputs to the NAS key derivation function to the existing K AMF Re-derive the NAS key from (if unchanged), or a new K AMF Derive the NAS key from (if changed). K AMF If is not changed, all inputs, in particular all inputs except the NAS algorithm ID, are identical in the re-derivation. K AMF If it is changed, a new NAS key is derived regardless of changes to the NAS algorithm.

[0312] This explains examples of key derivations for context modification procedures.

[0313] K AMF From new K gNB Whenever is calculated, the AMF modifies the security context of the ng-eNB / gNB with the corresponding K as a message. gNB It can send to the serving ng-eNB / gNB. The AMF and UE have a new K gNB It can be calculated. An NCC value of 0 is the new K gNB It is related to. New K gNBFrom ng-eNB / gNB and UE are K NG-RAN After calculating *, the calculated K NG-RAN * ul K gNB / KeNB It can be used as.

[0314] Explains examples of key derivations during handover.

[0315] For example, an example of key derivation during handover in gNB-CU handover and ng-eNB handover is explained.

[0316] gNB is K in any intra-NB-CU handover gNB Can maintain and a new K in any handover gNB It may have a policy determining whether to derive. During an intra-NB-CU handover, the gNB, through an HO Command message, determines the current K gNB You must inform the UE whether to change or maintain it. Current K gNB Maintenance can be performed only during intra-NB-CU handover.

[0317] Current K gNB If changed, the gNB / ng-eNB and UE shall have the target PCI, the corresponding frequency ARFCN-DL / EARFCN-DL, and NH or the current K according to the following criteria. gNB Using, K NG-RAN * can be derived. If unused {NH, NCC} pairs in the gNB are available (this is called vertical key derivation), the gNB uses the corresponding NH to derive K NG-RAN * can be derived. Otherwise (this is called horizontal key derivation), gNB is the current K gNB from K NG-RAN * can be derived. gNB is KNG-RAN An HO Command message containing the NCC used for derivation can be transmitted to the UE. After handover, the gNB / ng-eNB and the UE KNG-RAN K gNB It is used as.

[0318] Current K gNB를 If maintenance is required, the gNB and UE remain the current K even after the handover. gNB를 You can continue to use it.

[0319] For example, an example of key derivation during a handover in Xn-handover is explained.

[0320] For horizontal key derivation, the source gNB / ng-eNB first selects the target PCI, the corresponding frequency ARFCN-DL / EARFCN-DL, and the currently active K. gNB From K NG-RAN* Calculate. For vertical key derivation, the source gNB / ng-eNB first derives K from the target PCI, the corresponding frequency ARFCN-DL / EARFCN-DL, and NH. NG-RAN* Calculate.

[0321] Next, the source gNB / ng-eNB is {K NG-RAN Delivers the *, NCC} pair to the target gNB / ng-eNB. The target gNB / ng-eNB receives the received K NG-RAN* K to use with UE gNB It is used directly as K. The Target gNB / ng-eNB uses the NCC value received from the Source gNB / ng-eNB. gNB It can be associated with. The target gNB / ng-eNB includes the received NCC in a prepared HO Command message, and this message is placed in a transparent container and sent back to the source gNB / ng-eNB, which then delivers it to the UE by the source gNB / ng-eNB.

[0322] When the target gNB / ng-eNB completes handover signaling with the UE, the target gNB / ng-eNB can send an NGAP Path Switch Request message to the AMF. Upon receiving the NGAP Path Switch Request, the AMF increments the locally stored NCC value by 1 and can calculate the new NH from the stored data using a function. To calculate the new NH, the AMF uses the K of the currently active 5G NAS security context. AMF It can be used. Then, the AMF can send an NGAP path switch request acknowledgment message containing the newly calculated {NH, NCC} pairs to the target gNB / ng-eNB. The target gNB / ng-eNB stores the received {NH, NCC} pairs for future handover and removes any previously unused stored {NH, NCC} pairs.

[0323] AMF is a new K distinct from the 5G NAS security context that forms the basis of the currently active 5G AS security context. AMF A new 5G NAS security context may have been enabled using . In this case, if the AMF has not yet successfully performed the UE context modification procedure, the transmitted NGAP route switch request acknowledgment message may additionally include an NSCI (New Security Context Indicator). In this case, the AMF uses the new K of the most recent NAS security mode completion message. AMF and new initial K in uplink NAS count gNB It can be derived. The AMF is the derived new initial K gNB를 It can be associated with a new NCC value such as 0. Then, AMF is {derived new initial K gNBThe pair {NH, NCC}, with the new NCC value initialized to 0, can be used as the newly calculated {NH, NCC} pair, and an NGAP path switch request acknowledgment message containing it can be sent. In this case, the gNB / ng-eNB can set the keySetChangeIndicator field value to true during an additional handover. In this case, the gNB / ng-eNB can immediately perform an intra-gNB-CU / intra-ng-eNB handover.

[0324] For the target gNB KNG-RAN Explains examples of the derivation function.

[0325] For handover, and / or to transition from RRC_INACTIVE to RRC_CONNECTED state, the current K of the UE and NG-RAN gNB From K NG-RAN Deriving *, or K from new NH and target physical cell ID (PCI) NG-RAN * can be derived. In this case, the UE and NG-RAN can form input S in the KDF using the following parameters.

[0326] - FC = 0x70

[0327] - P0 = PCI (Target PCI)

[0328] - L0 = Length of PCI (e.g., 0x00 0x02)

[0329] - P1 = ARFCN-DL (Absolute frequency of the target PCELL's SSB)

[0330] - L1 = Length of ARFCN-DL (e.g., 0x00 0x03)

[0331] The input key KEY becomes the 256-bit NH if the index NCC at the handover increases, and otherwise becomes the current 256-bit K gNB (If the source is gNB) or K eNB (If the source is ng-eNB) it can be.

[0332] KgNB, K WAGF, K TNGF, K TWIF and K N3IWF Explains examples of derivation functions related to.

[0333] UE and AMF's K AMF and Key K from Uplink NAS COUNT gNB , K WAGF , K TNGF , K TWIF and K N3IWF를 When deriving, the input S to the KDF can be formed using the following parameters.

[0334] - FC = 0x6E

[0335] - P0 = Uplink NAS Count

[0336] - L0 = Length of Uplink NAS Count (e.g., 0x00 0x04)

[0337] - P1 = Access type identifier

[0338] - L1 = Length of access type separator (e.g., 0x00 0x01)

[0339] The values ​​of the access type identifiers are defined in Table 3. The values ​​0x00 and 0x03 through 0xf0 are reserved for future use, and the values ​​0xf1 through 0xff are reserved for private use.

[0340] The connection type identifier can be set to the 3GPP (0x01) value when deriving the KgNB. K N3IWF , K WAGF , K TWIF or K TNGF를 When deriving, the access type identifier can be set to a non-3GPP (0x02) value. .

[0341] Access Type Separator Value 3GPP Access 0x01 Non-3GPP Access 0x02

[0342] Table 3 is an example of an access type separator.

[0343] The input key KEY is a 256-bit K AMF It could be.

[0344] K gNB, K WAGF, K TNGF, K TWIF and K N3IWF The related derivation function can be applied when a password-protected 5G radio bearer is set up and a key change is performed on the fly.

[0345] The following drawings are made 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.

[0346] FIG. 11 is an example of key handling based on a handover procedure according to one embodiment of the disclosure of the present specification.

[0347] According to the example in Fig. 11, the UE can transmit a measurement report to the source base station (e.g., gNB / ng-eNB).

[0348] Source gNB / ng-eNB can determine Handover (HO).

[0349] The source gNB / ng-eNB can send a HandoverRequest message to the target base station (e.g., gNB / ng-eNB). For example, the source gNB / ng-eNB can send an XnAP-based message to the target base station (e.g., gNB / ng-eNB). The HandoverRequest message may include AS security information. For example, the AS security information is K gNBIt may include * and NCC. For example, based on the KgNB of the source base station, the KgNB* and NCC values ​​generated with the target PCI and DL ARFCN values ​​as input may be included in the HandoverRequest message.

[0350] The target gNB / ng-eNB can send a Handover Request Acknowledge message to the source base station. The Handover Request Acknowledge message may include a Handover Command. The Handover Command may include an NCC. For example, the target gNB / ng-eNB can create an RRC Container named HandoverCommand and send it to the source base station. At this time, the target gNB / ng-eNB may include the NCC value in the HandoverCommand and send it in order to inform the terminal of the NCC value received from the source base station.

[0351] The source gNB / ng-eNB can send an RRC reset message to the UE. The RRC reset message includes a handover command, and the handover command may include an NCC value.

[0352] The source gNB / ng-eNB can transmit SNStatusTransfer messages to the target base station.

[0353] The UE and the target gNB / ng-eNB can perform the Random Access Channel (RACH) procedure. The UE can complete access to the target base station.

[0354] The UE can send an RRCReconfigurationComplete message to the target base station.

[0355] The target gNB / ng-eNB can send a PathSwitchRequest message to the AMF.

[0356] The AMF can transmit a Route Switch Request Acknowledge message to the target base station. For example, the AMF can generate a new NH and increment the NCC value by one. The Route Switch Request Acknowledge message may include the new NH and the incremented NCC.

[0357] The target gNB / ng-eNB can send a UEContextRelease message to the source base station. A UEContextRelease message can be sent to clear the UE context of the source base station.

[0358] Below, L1 / L2 Triggered Mobility (LTM) is explained.

[0359] LTM may be a procedure that includes the following actions. For example, according to LTM, the gNB receives an L1 measurement report from the UE, and based on the measurement report, the gNB can change the UE's serving cell according to a cell switch command transmitted via MAC CE. The cell switch command may represent an LTM candidate setting previously prepared by the gNB and provided to the UE via RRC signaling. The UE can then switch to the target setting according to the cell switch command. The LTM procedure can be used to reduce mobility latency.

[0360] When the network establishes an LTM, the TCI status of one or more cells different from the current serving cell may be enabled. For example, the TCI status of an LTM candidate cell may be enabled in advance before that cell becomes the serving cell. Accordingly, the UE can synchronize with the cell and switch to one of those cells more quickly when the cell switch is triggered. All enabled TCI statuses, except for those received in the cell switch command, may be disabled when the LTM cell switch is executed.

[0361] If the network has established an LTM, it may initiate the UL TA acquisition (e.g., referred to as early TA) procedure for one or more cells different from the current serving cell. If the cell's NTA is the same as the current serving cell or NTA=0, the early TA acquisition procedure is not required. The network may request the UE to perform early TA acquisition for the candidate cell prior to cell switching. The early TA acquisition procedure may be triggered by a PDCCH command as specified in Section 9.2.6 of 3GPP TS 38.300 V18.2.0, or realized based on UE-based TA measurements as configured by the RRC. In the former case, the gNB / gNB-DU to which the candidate cell belongs may calculate the TA value and transmit it via the gNB-CU to the gNB / gNB-DU to which the serving cell belongs. When the serving cell triggers the LTM cell switch, it may transmit an LTM cell switch command Medium Access Control Control Element (MAC CE) containing a TA value. In the latter case, the UE performs a TA measurement for the candidate cell after being configured by the RRC, but the exact time at which the UE performs the TA measurement may vary depending on the UE implementation. If the UE does not contain a valid TA value when receiving the cell switch command, it may apply a self-measured TA value and perform LTM without RACH. The network may also transmit an LTM cell switch command MAC CE containing a TA value without early TA acquisition.

[0362] Based on the availability of valid TA values, the UE may perform RACH-free LTM or RACH-based LTM cell switching. If a valid TA value is included in the cell switch command, the UE may apply that TA value in accordance with network instructions. If UE-based TA measurement is established but a valid TA value is not provided in the cell switch command, the UE may apply a valid TA value on its own if available. If a valid TA value is available, the UE may perform RACH-free LTM cell switching upon receiving the cell switch command. If a valid TA value is not available, the UE may perform RACH-based LTM cell switching.

[0363] Regardless of whether terminal-based TA measurement for a specific candidate cell is configured, the terminal follows a PDCCH order to perform a random access procedure to one or more cells. This also applies to candidate cells for terminals capable of deriving their own TA values. Additionally, if the network has configured terminal-based measurement, the terminal follows the terminal-based measurement configuration regardless of whether it has initiated random access to the candidate cells. In the case of LTM without RACH, the UE can access the target cell using a configured grant or a dynamic grant. Configurable grants are provided in the LTM candidate configuration, and the UE can select a configured grant occasion associated with the beam indicated in the cell switch command. When the LTM cell switch for the target cell starts, the UE can begin monitoring the target cell's PDCCH for dynamic scheduling. If there are no valid PUCCH resources for a Scheduling Request (SR) triggered before the LTM without RACH procedure is complete, the UE may not trigger the random access procedure.

[0364] The following principles apply to LTM:

[0365] - The security key is retained during the LTM cell switch;

[0366] - Subsequent LTM is supported.

[0367] LTM supports both intra-gNB-DU mobility and inter-gNB-DU mobility within the same gNB-CU. LTM supports both intra-frequency and inter-frequency mobility, including mobility to inter-frequency cells that are not the current serving cell. LTM can be supported for licensed spectrum. The following scenarios are supported:

[0368] - PCell changes in non-CA scenarios and non-Dual connectivity (DC) scenarios;

[0369] - Changes to PCell and SCell in the CA scenario;

[0370] - DC Scenario: Includes PCell changes and MCG SCell changes, and intra-SN PSCell and SCG SCell changes without MN intervention. Simultaneous changes to PCell and PSCell may not be supported.

[0371] While the UE saves the LTM candidate settings, the UE may execute all L3 handovers except for DAPS handovers. In the RRC messages that the UE applies for all L3 handovers (excluding DAPS), the LTM candidate settings may be added / modified / unset by the target cell.

[0372] Explains an example of control plane handling related to the LTM procedure.

[0373] The cell switch command may be included in a MAC CE containing information necessary to perform an LTM cell switch.

[0374] For the entire procedure of the LTM, refer to Fig. 12. Subsequent LTMs can be performed by repeating the steps of initial synchronization, LTM cell switch execution, and LTM cell switch completion after each LTM cell switch is completed, without releasing other LTM candidate configurations. General procedures through a wireless interface can be applied to the SCG LTM.

[0375] The following drawings are made 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.

[0376] Figure 12 is an example of the LTM procedure.

[0377] The example in FIG. 12 illustrates an example of a signaling procedure for LTM. According to the example in FIG. 12, the procedure for LTM can be performed as follows.

[0378] The UE can be in the RRC_CONNECTED state.

[0379] 1. The UE can transmit measurement reports to the gNB.

[0380] For example, the UE can send a MeasurementReport message to the gNB. The gNB can determine the LTM settings and start LTM preparation.

[0381] gNB can prepare LTM candidates.

[0382] 2. The gNB can send an RRC reset message to the UE. The RRC reset message may include LTM candidate settings.

[0383] For example, the gNB can send an RRCReconfiguration message containing LTM candidate settings to the UE.

[0384] 3. The UE can send an RRC reset complete message to the gNB.

[0385] For example, the UE can save the LTM candidate settings and send the RRCReconfigurationComplete message to the gNB.

[0386] 4a. Downlink (DL) synchronization between the LTM candidate cell and the UE can be performed.

[0387] For example, the UE can perform DL synchronization with the LTM candidate cell before receiving a cell switch command. The UE can enable and disable the TCI status of the LTM candidate cell as triggered by the gNB.

[0388] 4b. Uplink (UL) synchronization between the LTM candidate cell and the UE can be performed.

[0389] For example, the UE may perform UL synchronization with the LTM candidate cell before receiving a cell switch command. For example, the UE may perform UL synchronization with the LTM candidate cell by using a UE-based TA measurement (if configured) or by sending a preamble toward the candidate cell as triggered by a gNB. If a UE-based TA measurement is configured, the UE may obtain the TA value of the candidate cell through the measurement. The UE may perform an early TA acquisition for the candidate cell requested by the network before receiving a cell switch command, as specified in Section 9.2.6 of TS 38.300 V18.2.0. This is done via a CFRA triggered by the source cell's PDCCH command, after which the UE may send a preamble to the specified candidate cell. To minimize data interruption of the source cell due to CFRA for the candidate cell, the UE does not receive random access responses from the network for the purpose of obtaining the TA value, and the TA value of the candidate cell may be indicated in the cell switch command. The UE does not maintain a TA timer for the candidate cell and may rely on the network implementation to guarantee TA validity.

[0390] 5. The UE can transmit L1 measurement reports to the gNB.

[0391] For example, the UE can perform L1 measurements on the configured LTM candidate cell and transmit the L1 measurement report to the gNB. L1 measurements can be performed only when the RRC reset (step 2) is applied.

[0392] gNB can determine LTM.

[0393] 6. The gNB can send LTM cell switch command messages (including MAC CE) to the UE.

[0394] The gNB may decide to execute a cell switch for the target cell and transmit an LTM cell switch command MAC CE that triggers the cell switch. For example, the MAC CE may include a target setup ID indicating the index of the candidate setup of the target cell, a beam indicating the TCI status or a beam indicating the DL TCI status and UL TCI status, and, if possible, a timing pre-command for the target cell.

[0395] The UE can detach from the source and apply the target settings. For example, the UE can switch to the target cell and apply the candidate settings indicated by the target setting ID.

[0396] 7. The UE and the target cell can perform the RACH procedure.

[0397] The UE can perform a random access procedure to the target cell if there is no valid TA for the target cell.

[0398] 8. The LTM cell switch can be completed.

[0399] For example, the UE can complete the LTM cell switch procedure by sending an RRCReconfigurationComplete message to the target cell. If the UE performed the RA procedure in Step 7, the UE considers the LTM cell switch execution to be successfully completed when the random access procedure is successfully completed. In the case of LTM without RACH, the UE considers the LTM cell switch execution to be successfully completed when it determines that the network has successfully received the first UL data.

[0400] For subsequent LTM cell switch execution, steps 4 through 8 may be performed multiple times using the LTM candidate configuration provided in step 2.

[0401] The procedure through the wireless interface described in Fig. 12 can be applied to both intra-NB-DU LTM and inter-NB-DU LTM.

[0402] Examples of user plane handling are as follows.

[0403] After receiving the LTM cell switch command MAC CE, the UE can perform a MAC reset. Whether the UE performs an RLC reset and PDCP data recovery during the cell switch can be explicitly controlled by the network via the RRC signal.

[0404] Examples of RACH-less handovers are as follows.

[0405] RACH-less handover can be configured for the UE during the Intra-NB Handover (HO) procedure. The RACH-less handover procedure can apply the following features:

[0406] - The UE can use the same timing advance value as the source cell in the target cell or a timing advance value of 0.

[0407] - A handover command for the UE may include a beam identifier for the beam that the UE will use in the target cell. The beam may be determined based on UE measurement reports and / or gNB implementations. For example, gNB implementations may include using the target cell's knowledge of the beam that the UE uses in a co-located source cell, etc.

[0408] - The handover command may include a configured UL grant. If there is no configured valid uplink grant, the UE may fall back to RACH. Alternatively, a UL grant may be dynamically signaled by the target cell.

[0409] - Based on a configured UL grant or a dynamically signaled UL grant, the UE may send an RRCReconfigurationComplete message. If the target cell successfully receives UL data, the RACH-free handover execution may be terminated.

[0410] Hereinafter, various examples of the disclosure of this specification will be described.

[0411] The application of security technology is essential even in handover, a technology designed to support terminal mobility. As the terminal accesses a new target node, signaling between the terminal and the base station must be protected at the new target node as well. To protect the signaling between the terminal and the base station, the generation of a new security key is required. To generate a new security key, the AMF and the terminal can create KgNBs and NHs (Next Hops) based on the KAMF. At this time, all KgNBs and NHs can be associated with the NCC. For example, as explained in the example in Fig. 10, all KgNBs and NHs can be associated with the NCC.

[0412] LTM (L1 / L2 Layer Triggered Mobility) is currently being discussed. LTM is a mobility feature that evolves existing handover procedures to support faster handover processes. According to LTM, to execute the handover process quickly, the terminal can pre-configure context regarding nearby cells (or base stations) capable of handover. Subsequently, once the terminal reports an additional measurement report to the base station, the handover can be completed immediately without additional signaling between the target base station and the source base station.

[0413] For LTM-based operations, the context regarding the target base station cell that the terminal possesses in advance includes security information. As an additional case, it is necessary to consider situations where the security context of the AMF may be updated during or after the LTM procedure. To this end, a security key update between the terminal and the base station is required in cases where an AMF security context update may occur. For example, when a security key update occurs between the terminal and the base station, it is necessary to update the security key for the candidate cell to be configured for the terminal in preparation for a subsequent LTM. However, according to conventional technology, there is a problem in that the procedure required for such situations has not been discussed. Consequently, there is a problem that security may not be effectively guaranteed when an LTM-based handover procedure is performed.

[0414] To solve these problems, in various examples disclosed in this specification, when a security key update between a terminal and a base station is required due to an update of the security context of an AMF, the security key can be effectively updated. For example, in this case, a method is presented to newly update the security key to the candidate cell during Intra cell handover / Inter-gNB CU handover for a subsequent LTM.

[0415] The disclosure of this specification describes examples for solving problems based on the first and second examples of the procedure.

[0416] The first scenario is as follows. During the LTM procedure, the AMF [regarding] a new K AMFBased on this, a new 5G NAS security context can be activated. In this case, when the previously activated 5G AS security is different from the current 5G NAS security, a procedure to refresh the 5G AS security key may be performed during the subsequent Intra-gNB-CU handover. At this time, for LTM, a method to update the context for the candidate cell based on the AS security key updated during the Intra-gNB-CU handover may be described. Based on the examples of FIGS. 13a to 13c, a first example of a procedure according to the disclosure of this specification is described in detail.

[0417] The second scenario is as follows. When a KAMF update occurs in the AMF, the AMF can update the gNB's security key through the NGAP: UE Context Modification Request transmitted to the gNB. During the Intra Cell Handover for LTM, the context for the candidate cell can be updated based on the updated gNB's security key. Based on the examples of FIGS. 14a through 14c, a second example of the procedure according to the disclosure of this specification is described in detail.

[0418] For reference, the first and / or second examples of the procedure according to the disclosure of this specification may be applied in combination.

[0419] Referring to FIGS. 13a to 13c, a first example of a procedure according to the disclosure of the present specification will be described.

[0420] The following drawings are made 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.

[0421] FIGS. 13a to 13c are first examples of a procedure according to one embodiment of the disclosure of the present specification.

[0422] Referring to Figures 13a through 13c, an example is described in which a handover within the gNB-CU is performed after LTM execution when the security context is updated in the AMF.

[0423] 0. The terminal's state is RRC_CONNECTED.

[0424] 1. The UE can send a measurement report message to the source gNB.

[0425] For example, if a preset measurement condition is satisfied before Figures 13a to 13c are performed, the terminal can transmit the Measurement Report to the source gNB.

[0426] 2. The Source gNB can derive new security information for each candidate cell within the Target gNB.

[0427] For example, the Source gNB can decide whether to start the LTM procedure. If it decides to start the LTM procedure, the Source gNB [prescribes] K for the candidate cells of the surrounding target gNBs. gNB Can generate *

[0428] 3. The source gNB can send a handover request message to the target gNB. For example, the handover request message may be a handover request message for an LTM. In step 3, the target gNB may be a candidate gNB that could become the target gNB.

[0429] For example, Source gNB is the newly created K gNB You can include * and NCC values ​​in the Handover Request and send them to gNBs that can be targets.

[0430] 4. The target gNB can send a handover request ACK message to the source gNB. For example, the handover request ACK message may be a handover request ACK message for the LTM.

[0431] For example, the Target gNB can send a Handover Request Acknowledge to the source gNB, including the NCC value received from the source gNB.

[0432] 5. The source gNB can send an RRC reset message to the UE.

[0433] For example, the terminal receives an RRC Reconfiguration message and configures the received candidate cell for future access (e.g., future access to a target gNB).

[0434] 6. The UE can send an RRC Reconfiguration Complete message to the source gNB.

[0435] 7. The UE can send measurement reports to the source gNB.

[0436] For example, after step 6, when the terminal transmits the Measurement Report to the source gNB, the source gNB can start LTM execution.

[0437] For example, the source gNB can determine the LMT.

[0438] 8. The source gNB can transmit an LTM Cell Switch Command over MAC CE to the terminal. The terminal sends a new K for the target gNB's candidate cell. gNB Generates **

[0439] For reference, the terminal can derive KgNB** from KgNB*. KgNB** may also be referred to as the new KgNB*. In the disclosure of this specification, the new KgNB* and KgNB** may be used as terms with the same meaning.

[0440] 9. The source gNB can send a Cell Switch (or cell change) Notification to the target gNB.

[0441] 10. The terminal can access a specific cell of the target gNB by performing a RACH procedure. Alternatively, the terminal can access a specific cell of the target gNB using RACH less.

[0442] 11. If the cell switch is successful, the terminal can send RRC Reconfiguration Complete to the target gNB.

[0443] 12. The Target gNB can send a path switch request message to the AMF.

[0444] For example, the Target gNB can send NGAP: PATH SWITCH REQUEST to the AMF.

[0445] If, AMF new K AMF A new NAS security context can be activated by creating it. If the existing AS security context is different from the new NAS security context, the AMF can set the NSCI (New Security Context Indicator) to true in the NGAP: PATH SWITCH REQUEST ACKNOWLEDGE message. For example, the AMF can send a path switch request ACK message containing the NSCI set to true to the target gNB. The AMF [sets] the new K AMFand based on the UL NAS COUNT of the most recently received NAS Security Mode Complete message, a new K gNB It can generate and set NCC to 0. In this way, AMF is the newly generated {new K gNB You can send an NGAP: PATH SWITCH REQUEST ACKNOWLEDGE message containing the pair , NCC=0} to the target gNB.

[0446] 13. The Target gNB can receive NGAP: PATH SWITCH REQUEST ACKNOWLEDGE from the AMF.

[0447] If the NSCI value (New Security Context Indicator) included in the received message is set to true, the target gNB can immediately perform an Intra-gNB-CU handover.

[0448] Since a new KgNB is scheduled to be created later through Intra-gNB-CU handover, the target gNB does not pass the updated key to the candidate cell of a neighboring gNB for the Subsequent LTM.

[0449] 14. Target gNB can trigger Intra gNB-CU HO.

[0450] For example, after LTM execution, the target gNB becomes the UE serving gNB. Based on the NSCI value (New Security Context Indicator: true) received in Step 3, the target gNB (serving gNB) triggers an Intra gNB-CU HO.

[0451] 15. The source gNB is a new K for the candidate cells of surrounding target gNBs. gNB Generates *

[0452] 16. Source gNB is the newly created new K gNB The * and NCC values ​​can be transmitted to gNBs that can be targets. For example, a Source gNB can transmit a newly generated security key value to other gNBs through the interface (Xn) between gNBs. For example, the Source gNB can transmit the newly generated new K gNB Messages containing * and NCC values ​​can be sent to gNBs that can be targets.

[0453] 17. The target gNB can send an RRC Reconfiguration message to the terminal.

[0454] For example, in step 5, the terminal can receive a configuration for a candidate cell. For example, the terminal sets the received configuration for the candidate cell for future access.

[0455] 18. The terminal may access a specific cell of the target gNB by performing a RACH procedure. Alternatively, the terminal may access a specific cell of the target gNB using RACH less. For security context updates, a RACH procedure according to the example in Step 18 may be performed. The cell performing the RACH procedure in Step 18 is the same as the cell performing the RACH procedure in Step 10.

[0456] 19. The terminal can send an RRC Reconfiguration Complete message to the target gNB.

[0457] For reference, the following description may apply to the RRC reset message of Step 17.

[0458] For example, an RRC reset message may include MasterKeyUpdate IE. MasterKeyUpdate IE may include keySetChangeIndicator and NAS-container set to true. keySetChangeIndicator indicates that the UE has a new K gNB It can indicate whether to derive. NAS-container can include ngKSI. ngKSI can mean Key Set Identifier for Next Generation Radio Access Network.

[0459] For example, if a UE receives masterKeyUpdate IE and nas-Container (which may include ngKSI) is included in the received masterKeyUpdate, the UE can pass nas-Container to the upper layer. If the UE receives masterKeyUpdate IE and keySetChangeIndicator is set to true, the UE [retrieves] a new K AMF Based on the key, K gNB You can derive or update the key.

[0460] For example, the NSCI included in the NGAP: Path Switch Request ACK message of Step 13 may be set to true. After Step 13, an RRCReconfiguration message may occur during the subsequent Intra-gNB-CU handover operation. For example, in Step 17, the target gNB may send an RRCReconfiguration message to the UE that includes a keySetChangeIndicator. The keySetChangeIndicator may be set to true. The RRC reconfiguration message includes a NAS container, and the NAS container may include an ngKSI. The ngKSI is a new KAMF It can be an index pointing to. UE is a new K AMF Based on, K gNB You can create a new one.

[0461] For reference, the following description may apply to ngKSI. An AMF may assign a key set identifier ngKSI. ngKSI may include a value indicating whether the 5G NAS security context is a native 5G NAS security context or a mapped 5G NAS security context, and a security context parameter type.

[0462] Hereinafter, a second example of a procedure according to the disclosure of the present specification will be described with reference to FIGS. 14a to 14c.

[0463] The following drawings are made 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.

[0464] FIGS. 14a to 14c are second examples of a procedure according to one embodiment of the disclosure of the present specification.

[0465] A second example of a procedure according to one embodiment of the disclosure of this specification may include the following operations. K in AMF AMF When an update occurs, the AMF can update the gNB's security key by sending the NGAP: UE Context Modification Request to the gNB. During the Intra Cell Handover for LTM, the AMF can update the context for the candidate cell based on the updated gNB's security key.

[0466] 0~6. Steps 0 to 6 of FIGS. 13a to 13c can be performed in the same manner.

[0467] 7. The UE can send measurement reports to the source gNB.

[0468] For example, after step 6, when the terminal transmits the Measurement Report to the source gNB, the source gNB can start LTM execution.

[0469] 8. The source gNB can transmit an LTM Cell Switch Command over MAC CE to the terminal. The terminal sends a new K for the target gNB's candidate cell. gNB Generates **

[0470] 9. The source gNB can send a Cell Switch (or cell change) Notification to the target gNB.

[0471] 10. The terminal can access a specific cell of the target gNB by performing a RACH procedure. Alternatively, the terminal can access a specific cell of the target gNB using RACH less.

[0472] 11. If the cell switch is successful, the terminal can send RRC Reconfiguration Complete to the target gNB.

[0473] 12. The Target gNB can send a path switch request message to the AMF.

[0474] For example, the Target gNB sends an NGAP: PATH SWITCH REQUEST to the AMF. The AMF increments its existing NCC value by one and can calculate a new NH based on the information the AMF has.

[0475] 13. The Target gNB can receive NGAP: PATH SWITCH REQUEST ACKNOWLEDGE from the AMF.

[0476] The AMF may send an NGAP: PATH SWITCH REQUEST ACKNOWLEDGE containing the newly generated {NH, NCC} pair in step 12 to the target gNB. Upon receiving this message, the target gNB may store the new {NH, NCC} pair and remove the existing pair.

[0477] 14. The target gNB can transfer the newly generated key to a candidate cell of a neighboring gNB for a subsequent LTM procedure.

[0478] 15a and 15b. The Target gNB may transmit RRC Reconfiguration to the terminal. For example, the Target gNB may transmit an NCC value to the terminal via RRC Reconfiguration. The terminal may transmit RRC Reconfiguration Complete to the target gNB. If this RRC message does not contain an NCC value, the NCC value may be transmitted to the terminal in a subsequent LTM.

[0479] After step 15, the target gNB becomes the source gNB.

[0480] 16. After LTM execution is completed, a new K at the AMF later AMF can be generated.

[0481] 17. AMF obtains a new K through the NGAP: UE CONTEXT MODIFICATION REQUEST message. AMF The new K generated by gNB Delivers.

[0482] 18. Source gNB sends NGAP: UE CONTEXT MODIFICATION RESPONSE to AMF and initiates the intra-cell handover procedure.

[0483] 19. Newly received K gNB Based on this, the target gNB is a new K for the candidate cells of surrounding target gNBs. gNB Can generate *

[0484] 20. Source gNB is the newly created new K gNB You can include * and NCC values ​​in and send them to gNBs that can be targets.

[0485] 21. The target gNB can send an RRC Reconfiguration message to the terminal.

[0486] For example, the terminal receives an RRC Reconfiguration message and configures the received candidate cell for future access.

[0487] 22. The terminal may access a specific cell of the target gNB by performing a RACH procedure. Alternatively, the terminal may access a specific cell of the target gNB using RACH less. For security context updates, a RACH procedure according to the example in Step 22 may be performed. The cell performing the RACH procedure in Step 22 is the same as the cell performing the RACH procedure in Step 10.

[0488] 23. The terminal can send an RRC Reconfiguration Complete message to the target gNB (e.g., the source gNB after step 15).

[0489] According to the examples disclosed in this specification, the security context of the second network entity (e.g., AMF) may be updated during the LTM procedure of the first network entity (e.g., gNB). In this case, the first network entity (e.g., gNB) may receive a PATH SWITCH REQUEST ACKNOWLEDGE from the second network entity (e.g., AMF) containing the NSCI (New Security Context Indicator) set to true.

[0490] For example, in such a case, the first network entity (e.g., gNB) performs an Intra-gNB-CU Handover, and during this process, the updated key pair (new K gNB , new NCC) can be transmitted to the candidate cells of the target gNBs.

[0491] According to the examples disclosed in this specification, after the LTM procedure, the security context of the second network entity (e.g., AMF) may be updated. In this case, the second network entity (e.g., AMF) may transmit the updated security key to the first network entity (e.g., gNB) via the NGAP: UE CONTEXT MODIFICATON REQUEST message.

[0492] For example, in such a case, due to the above procedure, the first network entity (e.g., gNB) performs an intra-cell handover, and in this process, the updated key pair (new K gNB , new NCC) can be transmitted to the candidate cells of the target gNBs.

[0493] The following drawings are made 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.

[0494] FIG. 15 illustrates an example of operations according to one embodiment of the disclosure of the present specification.

[0495] For reference, the procedure illustrated in FIG. 15 is merely an example, and the scope of disclosure of this specification is not limited by the example of FIG. 15.

[0496] For example, regarding the example of FIG. 15, the operations described in the examples of FIG. 1 to 14c may also be applied. For example, even if the operations, contents, etc. are not directly described in the example of FIG. 15, the operations, contents, etc. described in various examples of the disclosure of this specification may be applied.

[0497] For reference, in the disclosure of this specification, the first base station may be a target base station (e.g., target gNB) in the procedure related to LTM. The second base station may be a base station other than the first base station. The network entity may be a network entity related to mobility (e.g., AMF).

[0498] For reference, before step (S1501) is performed, the first base station may receive an L1 / L2 Triggered Mobility (LTM) cell switch notification message from the source base station.

[0499] Before step (S1501) is performed, the first base station may receive a handover request message related to LTM from the source base station. For example, the handover request message is K gNBIt may include * and Next Hop (NH) Chaining Counter (NCC). For example, the first base station may send a handover request Ack message related to the LTM to the source base station.

[0500] In step (S1501), the UE can transmit an RRC reset complete message to the first base station.

[0501] In step (S1502), the first base station can transmit a path switch request message to a network entity.

[0502] Network entities are new K AMF It can generate. Based on this, in step (S1503), the network entity can include an NSCI value set to true in the path switch request Ack message.

[0503] In step (S1503), the network entity can transmit a path switch request Ack message to the first base station.

[0504] For example, a path switch request acknowledge message may include a New Security Context Indicator (NSCI) value set to true.

[0505] For example, based on the reception of an NSCI value set to true, the first base station can trigger an Intra gNodeB Central Unit (gNB-CU) handover.

[0506] For example, based on the reception of an NSCI value set to true, the first base station can derive a new KgNB* for a candidate cell.

[0507] In step (S1504), the first base station can transmit the security key to the second base station.

[0508] For example, based on the reception of an NSCI value set to true, the first base station [sets] a new K for the candidate cellgNB * can be transmitted to one or more base stations, including a second base station.

[0509] In step (S1505), the first base station may transmit an RRC reset message to the UE. For example, the RRC reset message is a new K AMF It may include a Key Set Identifier (KSI) related to it.

[0510] For example, based on KSI, UE, a new K gNB It can generate.

[0511] In step (S1506), the UE can transmit an RRC reset complete message to the first base station.

[0512] This specification may have various effects.

[0513] For example, according to one embodiment of the disclosure of this specification, when a security key update between a terminal and a base station is required due to a security context update of an AMF, security can be effectively guaranteed in a subsequent LTM as well. For example, in such a case, for a subsequent LTM, a new security key can be updated for a candidate cell based on the operation of the base station and / or AMF during an Intra-cell handover / Inter-gNB CU handover.

[0514] 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.

[0515] For reference, the operation of the terminal (e.g., UE) described in this specification may be implemented by the device of FIGS. 1 to 3 described above. For example, the terminal may be the first device (100) or the second device (200) of FIG. 2. For example, the operation of the terminal described in this specification may be processed by one or more processors (102 or 202). The operation of the terminal described in this specification may be stored in one or more memories (104 or 204) in the form of an instruction / program (e.g., instruction, executable code) executable by one or more processors (102 or 202). One or more processors (102 or 202) may control one or more memories (104 or 204) and one or more transceivers (105 or 206) and execute the instruction / program stored in one or more memories (104 or 204) to perform the operation of the terminal (e.g., UE) described in the disclosure of this specification.

[0516] Additionally, instructions for performing the operation of the terminal described in the disclosure of this specification may be stored in a non-volatile computer-readable storage medium. The storage medium may be included in one or more memories (104 or 204). And, the instructions recorded in the storage medium may perform the operation of the terminal described in the disclosure of this specification by being executed by one or more processors (102 or 202).

[0517] For reference, the operation of a network node (e.g., AMF, SMF, PCF, UDM, SEAF, AUSF, etc.) or a base station (e.g., NG-RAN, gNB, RAN, eNB, (R)AN, ng-eNB, ng-eNB, etc.) described in this specification may be implemented by the device of FIGS. 1 to 3, which will be described below. For example, the network node or base station may be the first device (100) or the second device (200) of FIG. 2. For example, the operation of a network node or base station described in this specification may be processed by one or more processors (102 or 202). The operation of a terminal described in this specification may be stored in one or more memories (104 or 204) in the form of an instruction / program (e.g., instruction, executable code) executable by one or more processors (102 or 202). One or more processors (102 or 202) can control one or more memories (104 or 204) and one or more transceivers (106 or 206) and execute instructions / programs stored in one or more memories (104 or 204) to perform the operation of a network node or base station as described in the disclosure of this specification.

[0518] Additionally, instructions for performing the operation of a network node or base station described in the disclosure of this specification may be stored in a non-volatile (or non-transient) computer-readable storage medium. The storage medium may be contained in one or more memories (104 or 204). And, the instructions recorded in the storage medium may perform the operation of a network node or base station described in the disclosure of this specification by being executed by one or more processors (102 or 202).

[0519] Although preferred embodiments have been described by way of example above, the disclosure of this specification is not limited to such specific embodiments, and may be modified, changed, or improved in various forms within the scope of the spirit and claims of this specification.

[0520] In the exemplary system described above, methods are described based on a flowchart as a series of steps or blocks, but are not limited to the order of the described steps, and some steps may occur in a different order or simultaneously with other steps as described above. Furthermore, a person skilled in the art will understand that the steps shown in the flowchart are not exclusive, and that other steps may be included, or that one or more steps of the flowchart may be omitted without affecting the scope of rights.

[0521] 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

1. A step of receiving a first Radio Resource Control (RRC) reset completion message from User Equipment (UE); A step of transmitting a path switch request message to a network entity related to mobility; A step of receiving a path switch request acknowledge message from the network entity, The above path switch request acknowledge message includes a New Security Context Indicator (NSCI) value set to true, and Based on the reception of the NSCI value set to true above, an Intra gNodeB Central Unit (gNB-CU) handover is triggered; Based on the receipt of the NSCI value set to true above, a new K for the candidate cell gNB A step of transmitting * to one or more other base stations; Step of sending an RRC reset message to the UE; and A method comprising the step of receiving a second RRC reset completion message from the UE.

2. In Paragraph 1, A method further comprising the step of deriving a new KgNB* for the candidate cell based on receiving the NSCI value set to true.

3. In Paragraph 1, The above network entity is a new K AMF A method in which the NSCI value set to true is received based on the generation of the above.

4. In Paragraph 1, The method further includes the step of receiving an L1 / L2 Triggered Mobility (LTM) cell switch notification message from a source base station, A method in which, after the above LTM cell change notification is received, the above RRC reset completion message is received from the above UE.

5. In Paragraph 1, A step of receiving a handover request message related to LTM from a source base station, The above handover request message is K gNB Includes * and Next Hop (NH) Chaining Counter (NCC); and A method further comprising the step of transmitting a handover request Ack message related to the above LTM to the source base station.

6. In Paragraph 1, The above RRC reset message is a new K AMF Includes the Key Set Identifier (KSI) related to, Based on the above KSI, a new K by the above UE gNB The method by which it is generated.

7. One or more transmitters / receivers; One or more processors; and It includes one or more memories that store instructions and can be connected to operate with one or more processors, and The operation performed based on the execution of the above instruction by the above one or more processors is: A device that is a method according to any one of paragraphs 1 through 6.

8. Receiving a path switch request message from a target base station; and The method includes the step of transmitting a path switch request acknowledge message to the target base station, The above path switch request acknowledge message includes a New Security Context Indicator (NSCI) value set to true, and Based on the transmission of the NSCI value set to true above, an Intra gNodeB Central Unit (gNB-CU) handover is triggered, and The NSCI value set to true above is a new K for the candidate cell of the target base station. gNB A method used to transmit * to one or more other base stations.

9. In Paragraph 8, New K AMF It further includes a step to generate, The above new K AMF A method in which the NSCI value set to true is transmitted based on this generated.

10. One or more transmitters / receivers; One or more processors; and It includes one or more memories that store instructions and can be connected to operate with one or more processors, and The operation performed based on the execution of the above instruction by the above one or more processors is: A device that is a method according to any one of paragraphs 8 to 9.

Images