handover

Abstract

One disclosure of the present specification provides a method. The method may comprise the steps of: receiving a registration request message from a UE; transmitting a registration acceptance message to the UE; receiving a path switching request message from a target base station; and transmitting an authentication request message to a network entity related to data management.

Description

handover

[0001] This specification relates to mobile communications.

[0002] 3GPP (3rd Generation Partnership Project) LTE (Long-Term Evolution) is a technology designed to enable high-speed packet communications. Numerous approaches have been proposed to achieve LTE's goals of reducing costs for users and operators, improving service quality, expanding coverage, and increasing system capacity. 3GPP LTE's high-level requirements include reduced cost per bit, improved service availability, flexible use of frequency bands, a simple architecture, open interfaces, and adequate power consumption for terminals.

[0003] The International Telecommunication Union (ITU) and 3GPP have begun work on developing requirements and specifications for New Radio (NR) systems. 3GPP must identify and develop the technical components necessary to successfully standardize NR, meeting both urgent market needs and the longer-term requirements outlined by the ITU Radio communication sector (ITU-R) International Mobile Telecommunications (IMT)-2020 process. NR must also be able to utilize any spectrum band up to at least 100 GHz, ensuring that it remains available for wireless communications well into the future.

[0004] NR aims to be a single technology framework that addresses all deployment scenarios, usage scenarios, and requirements, including enhanced Mobile Broadband (eMBB), massive Machine Type Communications (mMTC), and Ultra-Reliable and Low Latency Communications (URLLC). NR must be inherently forward-compatible.

[0005] Handover can be used to support terminal mobility. However, conventional techniques have the problem of security not being protected during the handover procedure.

[0006] According to one embodiment of the present disclosure, a method is provided. The method may include the steps of: receiving a registration request message from a UE; transmitting a registration acceptance message to the UE; receiving a path switch request message from a target base station; and transmitting an authentication request message to a network entity involved in data management.

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

[0008] According to one embodiment of the present disclosure, a method is provided. The method may include the steps of: receiving a handover request message from a source base station; transmitting a handover request acknowledgement message to the source base station; and transmitting a path switch request message to a network entity involved in mobility.

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

[0010] Figure 1 illustrates an example of a communication system to which the implementation of this specification is applied.

[0011] Figure 2 illustrates an example of a wireless device to which the implementation of the present specification is applied.

[0012] Figure 3 shows an example of a UE to which the implementation of this specification is applied.

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

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

[0015] FIG. 7 is an example of an authentication procedure initiated 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] FIG. 12 is an example of a handover procedure and a re-authentication procedure according to one embodiment of the disclosure of the present specification.

[0021] FIG. 13a and FIG. 13b are examples of a handover procedure according to one embodiment of the disclosure of the present specification.

[0022] FIG. 14 is an example of a re-authentication 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 can 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 can be implemented using wireless technologies such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA can be implemented using 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 using wireless technologies such as IEEE (Institute of Electrical and Electronics Engineers) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or Evolved UTRA (E-UTRA). UTRA is part of the Universal Mobile Telecommunications System (UMTS). 3GPP (3rd Generation Partnership Project) Long-Term Evolution (LTE) is part of E-UMTS (Evolved UMTS) that utilizes E-UTRA.3GPP LTE uses OFDMA in the downlink (DL) and SC-FDMA in the uplink (UL). Evolution of 3GPP LTE includes LTE-A (Advanced), LTE-A Pro, and / or 5G NR (New Radio).

[0025] For convenience of explanation, the implementation of this specification is primarily described in relation to a 3GPP-based wireless communication system. However, the technical features 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 a 3GPP-based wireless communication system can 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] As used herein, "A or B" can mean "only A," "only B," or "both A and B." Alternatively, as used herein, "A or B" can be interpreted as "A and / or B." For example, as used herein, "A, B or C" can mean "only A," "only B," "only C," or "any combination of A, B and C."

[0028] As used herein, a slash ( / ) or a comma can mean "and / or." For example, "A / B" can mean "A and / or B." Accordingly, "A / B" can mean "only A," "only B," or "both A and B." For example, "A, B, C" can 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 identically to “at least one of A and B.”

[0030] Additionally, in this specification, “at least one of A, B and C” can mean “only A”, “only B”, “only C”, or “any combination of A, B and C”. Additionally, “at least one of A, B or C” or “at least one of A, B and / or C” can 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 individually described in 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 operational flowcharts disclosed herein may be applied to various fields requiring wireless communication and / or connectivity between devices (e.g., 5G).

[0034] Hereinafter, the present specification will be described in more detail with reference to the drawings. In the following drawings and / or description, the same reference numbers may refer to the same or corresponding hardware blocks, software blocks, and / or functional blocks, unless otherwise indicated.

[0035] Figure 1 illustrates an example of a communication system to which the implementation of this specification is applied.

[0036] The 5G usage scenario shown in FIG. 1 is only an example, and the technical features of this specification can 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), (2) massive machine type communication (mMTC), and (3) ultra-reliable and low latency communications (URLLC).

[0038] Referring to FIG. 1, a 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 a network of the communication system (1), but the implementation of the present disclosure is not limited to a 5G system and can be applied to future communication systems beyond the 5G system.

[0039] The base station (200) and the network (300) may be implemented as wireless devices, and a particular wireless device may operate as a base station / network node in relation to other wireless devices.

[0040] The 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. The wireless devices (100a to 100f) may include, but are not limited to, a robot (100a), a vehicle (100b-1 and 100b-2), an extended reality (XR) device (100c), a portable device (100d), a home appliance (100e), an Internet-of-Things (IoT) device (100f), and an artificial intelligence (AI) device / server (400). For example, the vehicles may include vehicles having wireless communication capabilities, autonomous vehicles, and vehicles capable of performing vehicle-to-vehicle communication. The 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 HMD (Head-Mounted Device) and HUD (Head-Up Display) 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., smart watches 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 personal digital assistant (PDA), a portable multimedia player (PMP), a navigation system, a slate PC, a tablet PC, an ultrabook, a vehicle, a vehicle with autonomous driving function, 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 a financial device), a security device, a weather / environmental device, a 5G service-related device, or a 4th industrial revolution-related device.

[0042] Wireless devices (100a to 100f) can be connected to a network (300) via a base station (200). AI technology can be applied to the wireless devices (100a to 100f), and the wireless devices (100a to 100f) can be connected to an AI server (400) via 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) can communicate with each other via the base station (200) / network (300), but can 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., vehicle-to-vehicle (V2V) / vehicle-to-everything (V2X) communication). Additionally, 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 / connection (150a, 150b, 150c) can be established between wireless devices (100a to 100f) and / or between wireless devices (100a to 100f) and a base station (200) and / or between base stations (200). Here, the wireless communication / connection 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 base station-to-base station communication (150c) (e.g., relay, IAB (Integrated Access and Backhaul)). Through the wireless communication / connection (150a, 150b, 150c), the wireless devices (100a to 100f) and the 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 of this specification, at least some of various configuration information setting processes for transmitting / receiving wireless signals, various signal processing processes (e.g., channel encoding / decoding, modulation / demodulation, resource mapping / demapping, etc.), and resource allocation processes can be performed.

[0044] NR supports multiple numerologies, or subcarrier spacings (SCS), to support diverse 5G services. For example, an SCS of 15 kHz supports wide areas in traditional cellular bands; an SCS of 30 kHz / 60 kHz supports dense urban areas, lower latency, and wider carrier bandwidth; and an SCS of 60 kHz or higher supports bandwidths greater than 24.25 GHz to overcome phase noise.

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

[0046] Frequency Range DefinitionFrequency RangeSubcarrier SpacingFR1450MHz - 6000MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0047] As described above, the numerical value of the frequency range of the NR system can be changed. For example, FR1 may include a band from 410 MHz to 7125 MHz, as shown in Table 2 below. For example, FR1 may include a frequency band above 6 GHz (or 5850, 5900, 5925 MHz, etc.). For example, the frequency band above 6 GHz (or 5850, 5900, 5925 MHz, etc.) included within FR1 may include an unlicensed band. The unlicensed band may be used for various purposes, such as for communications for vehicles (e.g., autonomous driving).

[0048] Frequency Range DefinitionFrequency RangeSubcarrier SpacingFR1410MHz - 7125MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0049] Here, the wireless communication technology implemented in the wireless device of the present specification may include not only LTE, NR, and 6G, but also Narrowband IoT (NB-IoT) for low-power communication. For example, NB-IoT technology may be an example of LPWAN (Low Power Wide Area Network) technology and may be implemented with standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above-described names. Additionally or alternatively, the wireless communication technology implemented in the wireless device of the present specification may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be called by various names such as eMTC (enhanced MTC). For example, LTE-M technology can be implemented by 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 above-described names. Additionally or alternatively, the wireless communication technology implemented in the wireless device of the present specification can include at least one of ZigBee, Bluetooth, and / or LPWAN considering low-power communication, and is not limited to the above-described names. For example, ZigBee technology can create PANs (Personal Area Networks) related to small / low-power digital communication based on various standards such as IEEE 802.15.4, and can be called by various names.

[0050] Figure 2 illustrates an example of a wireless device to which the implementation of the present specification is applied.

[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 case / service. For example, {the first wireless device (100) and the second wireless device (200)} may correspond to at least one of {the wireless devices (100a to 100f) and the base station (200)}, {the wireless devices (100a to 100f) and the wireless devices (100a to 100f)}, and / or {the base station (200) and the base station (200)} of FIG. 1. The first wireless device (100) and / or the second wireless device (200) may be configured by 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 alternatively, the memory (104) may be located external to the processing chip (101).

[0054] The processor (102) may control the memory (104) and / or the transceiver (106) and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed herein. For example, the processor (102) may process information in the memory (104) to generate first information / signal and transmit a wireless signal including the first information / signal via the transceiver (106). The processor (102) may receive a wireless signal including second information / signal via the transceiver (106) and store information obtained by processing the second information / signal in the memory (104).

[0055] A memory (104) may be operatively connected to the processor (102). The memory (104) may store various types of information and / or instructions. The memory (104) may store firmware and / or software code (105) that implements code, instructions and / or sets of instructions that, when executed by the processor (102), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (105) may implement instructions that, when executed by the processor (102), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (105) may control the processor (102) to perform one or more protocols. For example, the firmware and / or software code (105) may control the processor (102) to perform one or more air interface protocol layers.

[0056] Here, the processor (102) and memory (104) may be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). A transceiver (106) may be connected to the processor (102) and may transmit and / or receive wireless signals via one or more antennas (108). Each transceiver (106) may include a transmitter and / or a receiver. The transceiver (106) may be used interchangeably with an RF (Radio Frequency) unit. In the present 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 alternatively, the memory (204) may be located external to the processing chip (201).

[0059] The processor (202) may control the memory (204) and / or the transceiver (206) and may be configured to implement the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein. For example, the processor (202) may process information in the memory (204) to generate third information / signal and transmit a wireless signal including the third information / signal via the transceiver (206). The processor (202) may receive a wireless signal including fourth information / signal via the transceiver (206) and store information obtained by processing the fourth information / signal in the memory (204).

[0060] A memory (204) may be operatively connected to the processor (202). The memory (204) may store various types of information and / or instructions. The memory (204) may store firmware and / or software code (205) that implements code, instructions and / or sets of instructions that, when executed by the processor (202), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (205) may implement instructions that, when executed by the processor (202), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (205) may control the processor (202) to perform one or more protocols. For example, the firmware and / or software code (205) may control the processor (202) to perform one or more air 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 may transmit and / or receive wireless signals via one or more antennas (208). Each transceiver (206) may include a transmitter and / or a receiver. The transceiver (206) may be used interchangeably with the RF unit. In the present 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 physical (PHY) layer, a Media Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Resource Control (RRC) layer, and a Service Data Adaptation Protocol (SDAP) layer). One or more processors (102, 202) may generate one or more Protocol Data Units (PDUs), one or more Service Data Units (SDUs), messages, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed herein. One or more processors (102, 202) can generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data or information according to the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein and provide the signals to one or more transceivers (106, 206). One or more processors (102, 202) can receive signals (e.g., baseband signals) from one or more transceivers (106, 206) and obtain PDUs, SDUs, messages, control information, data or information according to the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein.

[0063] The one or more processors (102, 202) may be referred to as a controller, a microcontroller, a microprocessor, and / or a microcomputer. The 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 the one or more processors (102, 202). For example, the one or more processors (102, 202) may be configured by a set of a communication control processor, an Application Processor (AP), an Electronic Control Unit (ECU), a Central Processing Unit (CPU), a Graphic Processing Unit (GPU), and a Memory Control Processor. One or more memories (104, 204) may be coupled to one or more processors (102, 202) and may store various forms of data, signals, messages, information, programs, codes, instructions and / or commands. The one or more memories (104, 204) may be configured as random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), erasable programmable ROM (EPROM), flash memory, volatile memory, nonvolatile memory, hard drive, register, cache memory, computer readable storage media and / or combinations thereof.One or more memories (104, 204) may be located internally and / or externally to one or more processors (102, 202). Additionally, one or more memories (104, 204) may be connected to one or more processors (102, 202) via various technologies, such as wired or wireless connections.

[0064] One or more transceivers (106, 206) can transmit user data, control information, wireless signals / channels, etc., referred to in the descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed herein to one or more other devices. One or more transceivers (106, 206) can receive user data, control information, wireless signals / channels, etc., referred to in the descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed herein from one or more other devices. For example, one or more transceivers (106, 206) can be coupled to one or more processors (102, 202) and can transmit and receive wireless signals. For example, one or more processors (102, 202) can 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) may 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 coupled to one or more antennas (108, 208). Additionally and / or alternatively, 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., as described in the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein via one or more antennas (108, 208). In the present disclosure, one or more antennas (108, 208) may be multiple physical antennas or multiple logical antennas (e.g., antenna ports).

[0066] One or more transceivers (106, 206) may convert received user data, control information, wireless signals / channels, etc. from RF band signals to baseband signals in order to process the received user data, control information, wireless signals / channels, etc. using one or more processors (102, 202). One or more transceivers (106, 206) may convert processed user data, control information, wireless signals / channels, etc. from baseband signals to RF band signals using one or more processors (102, 202). For this purpose, one or more transceivers (106, 206) may include an (analog) oscillator and / or a filter. For example, one or more transceivers (106, 206) may up-convert an OFDM baseband signal to an OFDM signal via 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) may receive an OFDM signal at a carrier frequency and down-convert the OFDM signal to an OFDM baseband signal via 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 further 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., an audio I / O port, a video I / O port), a driving device, and a computing device. The additional components (140) may be connected to one or more processors (102, 202) via various technologies, such as a wired or wireless connection.

[0068] In the implementation of this specification, a UE can operate as a transmitter in the uplink and as a receiver in the downlink. In the implementation of this specification, a base station can operate as a receiver in the UL and as a transmitter in the DL. For the sake of convenience of description, it is mainly assumed below 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 in the first wireless device (100) can be configured to perform UE operations according to the implementation of this specification or to control a transceiver (106) to perform UE operations according to the implementation of this specification. A processor (202) connected to, mounted on, or released in the second wireless device (200) can be configured to perform base station operations according to the implementation of this specification or to control a transceiver (206) to perform base station operations according to the implementation of this specification.

[0069] In this specification, a base station may be referred to as a Node B, an eNode B (eNB), or a gNB.

[0070] Figure 3 shows an example of a UE to which the implementation of this specification is applied.

[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), a 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 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 flowcharts disclosed herein. A layer of a radio 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 processors, EXYNOS made by Samsung® TM Series processors, A-series processors made by Apple®, HELIO made by MediaTek® TM ATOM series processors made by Intel® TM It can be found in the series processors or the corresponding next-generation processors.

[0074] Memory (104) is operatively coupled to the processor (102) and stores various information for operating the processor (102). Memory (104) may include ROM, RAM, flash memory, memory cards, storage media, and / or other storage devices. When the implementation is implemented in software, the techniques described herein may be implemented using modules (e.g., procedures, functions, etc.) that perform the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein. The modules may be stored in memory (104) and executed by the processor (102). Memory (104) may be implemented within the processor (102) or external to the processor (102), in which case it may be communicatively coupled to the processor (102) via various methods known in the art.

[0075] A transceiver (106) is operably coupled to the processor (102) and transmits and / or receives a radio signal. The transceiver (106) includes a transmitter and a receiver. The transceiver (106) may include a baseband circuit for processing a radio frequency signal. The transceiver (106) controls one or more antennas (108) to transmit and / or receive a radio 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 results 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 that securely stores an International Mobile Subscriber Identity (IMSI) and associated keys, and is used to identify and authenticate subscribers in mobile devices such as mobile phones and computers. Additionally, many SIM cards can store contact information.

[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] Figure 4 shows an example of a 5G system structure to which the implementation of this specification is applied.

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

[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 illustrates the 5G system architecture for a non-roaming case using a reference point representation showing how various network functions interact with each other.

[0107] For clarity of the point-to-point diagram in Figure 4, UDSF, NEF, and NRF are not illustrated. 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 architecture includes the following benchmarks:

[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 UPF and data network.

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

[0116] The following benchmarks illustrate the interactions that exist between NF services in 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, and reference point between PCF and AMF of visited network for roaming scenarios.

[0126] - N16: Reference point between two SMFs (in 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 interconnected to serve a UE.

[0129] Describes the registration procedure. See section 4.2.2.2 of 3GPP TS 23.502 V16.3.0 (2019-12).

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

[0131] A 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 5GS; or

[0133] - mobility registration update; or

[0134] - Periodic registration update; or

[0135] - Emergency registration

[0136] The general registration procedures of Figures 5 and 6 apply to all registration procedures described above, but periodic registration updates do not need to include all parameters used in other registration procedures.

[0137] The general registration procedures of Figures 5 and 6 can also be used to register a UE for a 3GPP connection when it is already registered for a non-3GPP connection, and vice versa. Registering a UE for a 3GPP connection when it is already registered for a non-3GPP connection scenario may require an AMF change.

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

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

[0140] The registration request message may include AN parameters. For NG-RAN, the AN parameters include, for example, the 5G SAE temporary mobile subscriber identity (5G-S-TMSI) or globally unique AMF ID (GUAMI), the selected public land mobile network (PLMN) ID (or PLMN ID and network identifier (NID)), and the requested network slice selection assistance information (NSSAI). The AN parameters also include an establishment cause. The establishment cause provides the reason for requesting 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] A 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 RM-DEREGISTERED state), or a mobility registration update (e.g., the UE is in RM-REGISTERED state and initiates a registration procedure because the UE moves, or the UE wants to update capabilities or protocol parameters, or requests a change in the set of network slices the UE is allowed to use), or a periodic registration update (e.g., the UE is in RM-REGISTERED state and initiates a registration procedure because a periodic registration update timer expires), or an emergency registration (e.g., the UE is in a restricted service state).

[0142] When a UE performs initial registration, the UE indicates its UE ID in the registration request message, listed in decreasing priority order.

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

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

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

[0146] iv) Native 5G-GUTI allocated by another PLMN (if available);

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

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

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

[0150] For emergency registration, if the UE does not have a valid 5G-GUTI, the SUCI is included. If the UE does not have a subscriber permanent identifier (SUPI) and does not have a valid 5G-GUTI, the PEI (Permanent Equipment Identifier) ​​is included. Otherwise, the 5G-GUTI is included, indicating 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 PDU session currently established in the 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 indicate a valid AMF, the (R)AN selects an AMF based on the (R)AT and the requested NSSAI, if available.

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

[0155] If the (R)AN cannot select an appropriate AMF, the (R)AN performs AMF selection by forwarding a registration request message to the AMF configured in the (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 contain all of the 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 an N2 parameter. When NG-RAN is used, the N2 parameter includes the selected PLMN ID (or PLMN ID and NID), location information and cell ID related to the cell where the UE is camping, and a UE context request indicating that a UE context including security information should be established in the NG-RAN. When NG-RAN is used, the N2 parameter also includes an establishment cause.

[0159] If the registration type indicated by the UE is 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 invoke the Namf_Communication_UEContextTransfer service operation to the previous AMF, including the full registration request non-access stratum (NAS) message to request the UE's SUPI and UE context.

[0161] (5) Step 5: The old 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 not retrieved from the previous AMF, the new AMF may initiate an ID request procedure by sending an Identity Request message to request SUCI from the UE.

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

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

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

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

[0167] (11) Step 11: If the PEI was not provided by the UE or was not retrieved from the previous AMF, the new AMF may initiate the ID request procedure by sending an Identity Request message to the UE to retrieve the PEI. The PEI is transmitted encrypted, except when the UE performs emergency registration and cannot be authenticated.

[0168] (12) Step 12: Optionally, the new AMF can initiate ME ID checking by calling the N5g-eir_EquipmentIdentityCheck_Get service operation.

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

[0170] (13) Step 13: When step 14 below is performed, 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: New AMF can select PCF.

[0173] (16) Step 16: The new AMF may optionally perform AM policy association establishment / modification.

[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 old AMF are in the same PLMN, the new AMF may send a UE context modification request to the N3IWF / TNGF / W-AGF.

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

[0177] (20) Step 20: After the new AMF receives the 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 the UE a Registration Accept message indicating that the registration request has been accepted. If the new AMF allocates a new 5G-GUTI, it includes the 5G-GUTI. If the UE is already in the RM-REGISTERED state through another connection to the same PLMN, the UE uses the 5G-GUTI received in the Registration Accept message for both registrations. If the Registration Accept message does not include a 5G-GUTI, the UE uses the 5G-GUTI assigned to the existing registration for the new registration. If the new AMF allocates a new registration area, it sends the registration area to the UE in the Registration Accept message. If the Registration Accept message does not include a registration area, the UE considers the previous registration area to be valid. Mobility Restrictions are included if mobility restrictions apply to the UE and the registration type is not emergency registration. The new AMF indicates the PDU sessions 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 is connected to two AMFs belonging to different PLMNs via a 3GPP connection and a non-3GPP connection, the UE locally removes internal resources associated with PDU sessions in the current PLMN that are not marked as established in the received PDU session status. If PDU session status information is present in the Registration Accept message, the new AMF indicates the PDU session status to the UE.

[0180] The Allowed NSSAI provided in the Registration Accept message is valid for the registration area and applies to all PLMNs that have a tracking area included in the registration area. The Mapping of Allowed NSSAIs maps HPLMN S-NSSAIs to each S-NSSAI of the Allowed NSSAIs. The Mapping of Configured NSSAIs maps HPLMN S-NSSAIs to each S-NSSAI of the Configured NSSAI for the serving PLMN.

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

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

[0183] The UE may send a registration complete message to the new AMF to confirm that a new 5G-GUTI has been allocated.

[0184] (23) Step 23: In case of registration via 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 case of registration via non-3GPP connection, if the UE is in 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 may execute a network slice-specific authentication and authorization (NSSAA) procedure.

[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 communications may use examples of the security procedures described below.

[0189] Describes examples of primary authentication and key agreement. Describes an example authentication framework.

[0190] The purpose of the primary authentication and key agreement 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 agreement procedure is the anchor key K, which the AUSF of the home network provides to the SEAF of the serving network. SEAF Creates.

[0191] Keys for multiple security contexts can be derived from the KSEAF without the need to perform a new authentication. As a specific example, authentication performed over a 3GPP access network may provide keys that establish 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 an intermediate key called K AUSF is established between the UE and the HN as a result of the first authentication procedure. K AUSFmay be securely stored in the AUSF, depending on the home operator's policy for using the key, for example, if the control plane solution for roaming coordination or UE parameter update procedures or Authentication and Key Management for Applications (AKMA) is supported by the HPLMN.

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

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

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

[0196] Once the 5G AKA primary authentication is successfully completed, the AMF can initiate the NAS security mode command procedure with the UE.

[0197] Describes an example of the EAP framework.

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

[0199] - UE can perform peer role.

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

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

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

[0203] The primary authentication and key agreement procedure can bind the KSEAF to a serving network. Binding to a serving network prevents one serving network from claiming to be another, thereby providing implicit serving network authentication to the UE.

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

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

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

[0207] Describes an example of configuring a serving network name.

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

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

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

[0211] In 5G AKA, the Serving Network Name has a similar purpose of binding RES* and XRES* to a serving network.

[0212] The serving network name is a combination of the service code and the SN Id, separated by a ":" character, so that the service code comes before the SN Id.

[0213] The SN Id identifies the PLMN providing the service and is defined as the SNN - Network Identifier, except for standalone private networks.

[0214] Describes 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 network that authenticates it.

[0218] - Connect the service code and SN Id with the delimiter ":".

[0219] Describes an example of configuring a serving network name by SEAF.

[0220] SEAF configures service network names 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 delimiter ":".

[0224] An example of the procedure for starting authentication and selecting an authentication method is shown.

[0225] According to the example of Figure 7, primary authentication can be initiated.

[0226] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals, messages, and fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

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

[0228] Figure 7 shows an example of starting an authentication procedure and selecting an authentication method.

[0229] The UE may send an N1 message (e.g., containing a registration request message) to the Security Anchor Function (SEAF). For example, the SEAF may initiate authentication of the UE according to its policies during the procedure of establishing a signaling connection with the UE. The UE may use SUCI or 5G-GUTI for the registration request. For example, the registration request message may contain SUCI or 5G-GUTI.

[0230] For example, SEAF may be a function responsible for authenticating the serving AMF. For example, AMF may contain an entity called SEAF, or AMF may perform actions related to SEAF.

[0231] SEAF can send an authentication request message (e.g., Nausf_UEAuthentication_AuthenticationRequest message) to the Authentication Server Function (AUSF). Whenever SEAF wants 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_AuthenticationRequest message may contain 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 a 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 verify whether the SEAF requesting 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 can respond with "Unauthorized serving network" in the Nausf_UEAuthentication_Authenticate response.

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

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

[0241] - SUCI or SUPI;

[0242] - Serving network name;

[0243] - If received from SEAF, display Disaster Roaming Service.

[0244] When the UDM receives the Nudm_UEAuthentication_Get request, it calls SIDF when the SUCI is received. SIDF unmasks the SUCI to obtain the SUPI before the UDM processes the request.

[0245] According to SUPI, UDM / ARPF selects the authentication method.

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

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

[0248] Home network trigger authentication support is optional for both the Home Network (HN) and Serving Network (SN). If both networks (HN and SN) support home network trigger primary authentication, the following applies.

[0249] Examples of security mechanisms include:

[0250] The UDM can initiate primary authentication for UE-initiated procedures (e.g. UE registration in 5GC) or for events from the UE (e.g. SoR / UPU) or other NFs, taking into account local policies as well.

[0251] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals, messages, and fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the 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 Figure 8.

[0255] 0a. To determine when to trigger the primary authentication procedure, a business authentication policy can be configured in advance in the UDM.

[0256] 0b. The UE may register with the network. As part of the registration procedure, the serving AMF may register the UE with the UDM via Nudm_UECM_Registration as per TS 23.502 V18.5.0 section 4.2.2.2.2 or the examples in Figures 5 and 6. The AMF may provide a callback URI within the AMF registration to enable the UDM to create an implicit subscription for potential home network triggered re-authentication using the Nudm_UECM_Re-AuthenticationNotification service operation as in step 2.

[0257] 1a-c. The UDM can make its own decision based on an event or authentication policy and perform the home network triggered primary authentication as described in the following steps. For example, an NF, such as an AAnF, can use the UDM service to send a Nudm_UECM_AuthTrigger request to the UDM for primary authentication. The NF can send the Nudm_UECM_AuthTrigger request message along with the SUPI of the target UE to the UDM. The UDM can 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 reauthentication. The criteria for selecting an AMF may vary depending on the local UDM authentication policy.

[0259] 2. UDM can send Nudm_UECM_Re-AuthenticationNotification message to AMF / SEAF with SUPI of UE.

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

[0261] When the UE reconnects to the same AMF or connection becomes available, the AMF can check the authentication pending flag and perform reauthentication if necessary. Once the UE reauthentication is complete, the AMF can reset the authentication pending flag.

[0262] 4. As defined in the example in Figure 9, AMF / SEAF can initiate the primary authentication procedure.

[0263] UDM may execute other procedures (e.g. SoR / UPU) depending on what triggered the (re)authentication procedure in step 1.

[0264] Below, with reference to the example of 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] Requirements for 5GC and NG-RAN related to keys can be found in 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 intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals, messages, and fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the 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 of 5GS.

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

[0271] The key hierarchy (see Figure 9) contains 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 keys for AUSF in a home network (e.g., HPLMN in the example of Figure 9) are:

[0273] - K AUSF The derived key is:

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

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

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

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

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

[0279] The keys for NAS signaling are:

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

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

[0282] The keys for NG-RAN are:

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

[0284] The keys for UP traffic are:

[0285] - K UPenc is the key derived by ME and gNB from KgNB. K UPenc can only be used to protect UP traffic using specific encryption algorithms.

[0286] - K UPint ME and gNB are K gNB The key derived from K UPint can be used to protect UP traffic between ME and gNB using specific integrity algorithms.

[0287] The keys for RRC signaling are:

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

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

[0290] The intermediate keys are:

[0291] - Next Hop (NH) is a key derived by the 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 the ME and the NG-RAN (e.g., gNB or ng-eNB) when performing horizontal key derivation or vertical key derivation as specified in TS 33.501 V18.5.0 6.9.2.1.1 using the KDF as specified in TS 33.501 V18.5.0 Clause A.11 / A.12.

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

[0294] The keys for non-3GPP access are:

[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 is the key derived from K N3IWF is not transmitted between N3IWFs.

[0297] Describes an example of security handling related to mobility.

[0298] For example, we describe an example of handling keys in handover.

[0299] Describes an example of a key handle related to the access stratum.

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

[0301] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals, messages, and fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the 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] We outline a key processing model to clarify the intended structure of key derivation.

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

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

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

[0308] NH parameters can only be computed 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 handover with vertical key derivation, NH is additionally bound to target Physical Cell Identifier (PCI) and corresponding frequency ARFCN-DL, after which K is decoded from target gNB / ng-eNB. gNB can be used. In horizontal key derivation handover, the currently activated K gNBAfter K is additionally bound to the target PCI and its frequency ARFCN-DL on the target gNB / ng-eNB gNB can be used as

[0310] Describes an example of key handling related to the non-access stratum (NAS).

[0311] NAS aspects to be considered during mobility related procedures are K AMF This may include the possibility of change, the possibility of NAS algorithm change when AMF changes, and the possibility 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 with respect to the use of NAS algorithms. In this case, the target AMF may use the NAS algorithm ID and NAS algorithm type as inputs to the NAS key derivation function to derive the existing K AMF Re-derive the NAS key (if it has not changed) or generate a new K AMF Derive the NAS key from (if changed). K AMF If K is not changed, all inputs, except for the NAS algorithm ID, are identical in the re-derived K AMF If the NAS algorithm is changed, a new NAS key is derived regardless of the change.

[0312] Describes an example of key derivations for context modification procedure.

[0313] K AMF New K from gNB Each time a K is computed, AMF sends a message modifying the security context of the ng-eNB / gNB. gNB can be sent to the serving ng-eNB / gNB. AMF and UE can send new K gNB can be calculated. The NCC value 0 is the new K gNB It is related to the new K gNBFrom ng-eNB / gNB and UE are K NG-RAN * After calculating, the calculated K NG-RAN * to K gNB / K eNB can be used as

[0314] Describes an example of key derivations during handover.

[0315] For example, we describe examples of key derivation during handover in gNB-CU handover and ng-eNB handover.

[0316] gNB is responsible for K in any intra-NB-CU handover. gNB can maintain and new K in any handover gNB may have a policy to determine whether to derive the current K . During intra-NB-CU handover, the gNB may send the HO Command message to the current K gNB The UE must be notified whether to change or maintain the current K gNB Maintenance can only be performed during intra-NB-CU handover.

[0317] Currently K gNB When the target PCI, the corresponding frequency ARFCN-DL / EARFCN-DL, and the current K are changed, the gNB / ng-eNB and the UE are switched to the NH or the current K according to the following criteria: gNB Using K NG-RAN * can be derived. If an unused {NH, NCC} pair is available in the gNB (this is called vertical key derivation), the gNB uses that NH to derive K NG-RAN * can be derived. Otherwise (this is called horizontal key derivation), the gNB currently uses K gNB In K NG-RAN * can be derived. gNB is KNG-RAN* The HO Command message including the NCC used for derivation can be sent to the UE. After handover, the gNB / ng-eNB and the UE can use K NG-RAN * to K gNB It is used as

[0318] Currently K gNB If the gNB and UE must maintain the current K even after the handover, gNB You can continue to use it.

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

[0320] For horizontal key derivation, the source gNB / ng-eNB first determines the target PCI, the corresponding frequency ARFCN-DL / EARFCN-DL, and the currently activated K gNB From K NG-RAN * is calculated. For vertical key derivation, the source gNB / ng-eNB first calculates 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 *, NCC} pairs are forwarded to the target gNB / ng-eNB. The target gNB / ng-eNB receives the received K NG-RAN * K to be used with UE gNB It is used directly. The target gNB / ng-eNB receives the NCC value from the source gNB / ng-eNB as K gNB can be associated with. The target gNB / ng-eNB includes the received NCC in the prepared HO Command message, which is then sent back to the source gNB / ng-eNB in ​​a transparent container and delivered to the UE by the source gNB / ng-eNB.

[0322] When the target gNB / ng-eNB completes the handover signaling with the UE, the target gNB / ng-eNB can send an NGAP path switch request (PATH SWITCH REQUEST) message to the AMF. The AMF, which receives the NGAP path switch request, can increment the locally stored NCC value by 1 and calculate a new NH from the stored data using a function. The AMF uses the K of the currently activated 5G NAS security context to calculate the new NH. AMF can be used. The AMF can then send an NGAP Path Switch Request Acknowledge message containing the newly computed {NH, NCC} pair to the target gNB / ng-eNB. The target gNB / ng-eNB stores the received {NH, NCC} pair for future handovers and removes any previously unused stored {NH, NCC} pair.

[0323] AMF is a new K-level security context that is different from the 5G NAS security context that is currently the basis for the activated 5G AS security context. AMF A new 5G NAS security context may have been activated using the NGAP Path Switch Request Acknowledge message. In this case, if the AMF has not yet successfully performed the UE context modification procedure, the transmitted NGAP Path Switch Request Acknowledge message may additionally include the New Security Context Indicator (NSCI). In this case, the AMF may use the new K in the most recent NAS Security Mode Complete message. AMF and new initial K in uplink NAS count gNB can be derived. AMF is derived as a new initial K gNB can be associated with a new NCC value such as 0. Then, AMF is {derived new initial K gNB, a new NCC value initialized to 0} pair can be used as the newly computed {NH, NCC} pair and an NGAP Path Switch Request Acknowledge message containing it can be sent. In this case, the gNB / ng-eNB can set the keySetChangeIndicator field value to true for further handover. In this case, the gNB / ng-eNB can immediately perform intra-gNB-CU / intra-ng-eNB handover.

[0324] For target gNB KNG-RAN * Describes an example of a derivation function.

[0325] For handover and / or transition from RRC_INACTIVE state to RRC_CONNECTED state, the current K of the UE and NG-RAN gNB From K NG-RAN * or derive K from the new NH and target physical cell ID (PCI). NG-RAN * can be derived. In this case, the UE and NG-RAN can form the input S to 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 SSB of target PCELL)

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

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

[0332] KgNB, K WAGF, K TNGF, K TWIF and K N3IWF Describes an example of a derivation function related to .

[0333] K of UE and AMF 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 delimiter

[0338] - L1 = length of access type delimiter (e.g. 0x00 0x01)

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

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

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

[0342] Table 3 shows examples of access type delimiters.

[0343] The input key KEY is 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 cryptographically protected 5G radio bearer is established and a key change is performed on the fly.

[0345] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals, messages, and fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the 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 of FIG. 11, the UE can transmit a measurement report to a source base station (e.g., gNB / ng-eNB).

[0348] The source gNB / ng-eNB can decide Handover (HO).

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

[0350] The target gNB / ng-eNB can transmit a handover request Acknowledge message to the source base station. The handover request Acknowledge message can include a handover command (HandoverCommand). The handover command can include an NCC. For example, the target gNB / ng-eNB can create an RRC container called HandoverCommand and transmit it to the source base station. At this time, the target gNB / ng-eNB can transmit the NCC value included in the HandoverCommand to inform the terminal of the NCC value received from the source base station.

[0351] The source gNB / ng-eNB may 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 send an SNStatusTransfer message to the target base station.

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

[0354] The UE may 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 send a Path Switch Request Acknowledge message to the target base station. For example, the AMF can create a new NH and increase the NCC value. The Path Switch Request Acknowledge message can include the new NH and the increased NCC.

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

[0358] Security technology is essential for handover, a technology that supports terminal mobility. As a terminal accesses a new target node (e.g., a target base station), a new security key must be generated to protect signaling between the terminal and the base station. To achieve this, the AMF and terminal can create a KgNB and NH (Next Hop) based on the KAGMF. All KgNBs and NHs are associated with an NCC. In particular, when a path switch is required during a handover, an increase in the NCC value is required. For example, when a target node (e.g., a target base station) sends a path switch request message to the AMF, the AMF must increase the NCC value by 1. Currently, the NCC values ​​used are 0 to 7.

[0359] However, the prior art poses a problem: security may not be effectively protected when handover procedures are performed frequently. For example, if the NCC value continues to increase in a situation where terminal handovers occur frequently, there is a problem that it is not specifically defined how security based on the NCC value will be handled. In particular, as communication technologies advance in the future, new mobility support features may lead to more frequent handovers, and thus, security issues during handover procedures are expected to arise with the prior art. Furthermore, from a security perspective, repeatedly generating new keys using a single key as input may lead to key freshness issues.

[0360] To address these issues, one embodiment of the disclosure herein describes an example of a method for minimizing the security impact during a handover procedure. For example, according to various examples disclosed herein, when the NCC value reaches its maximum, a reauthentication procedure is triggered, thereby generating a new, fundamental root key. This ensures key freshness and initializes the NCC value, minimizing the impact on subsequent terminal services and security.

[0361] To address this issue, the present invention provides an example of re-performing primary authentication to generate a new root key required for security. Specific examples are described below with reference to the examples in FIGS. 12 through 15.

[0362] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals, messages, and fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

[0363] FIG. 12 is an example of a handover procedure and a re-authentication procedure according to one embodiment of the disclosure of the present specification.

[0364] The example in Figure 12 is an example of an overall handover procedure and re-authentication procedure.

[0365] In the example of Figure 12, the UE can perform a handover.

[0366] For reference, in the disclosure of this specification, the term source node may be used as a term having the same meaning as source base station, source gNB, source ng-eNB, etc. For reference, in the disclosure of this specification, the term target node may be used as a term having the same meaning as target base station, target gNB, target ng-eNB, etc.

[0367] 1. The target base station can send a PathSwitchRequest message to the AMF.

[0368] 2. AMF may decide to trigger primary authentication via UDM.

[0369] 3. AMF may send a PathSwitchRequestAcknowledge message to the target base station. The PathSwitchRequestAcknowledge message may include a new NH and a new NCC.

[0370] For example, if a path switch is required during a handover, the AMF can create a new NH and NCC and provide them to the target node. The NCC can have a value between 0 and 7. Each time a path switch procedure is performed (e.g., each time the AMF receives a path switch request message), the AMF can sequentially increase the NCC value.

[0371] 4. If the NCC value matches 7, AMF can trigger a re-authentication procedure.

[0372] For example, when the NCC value becomes 7, the AMF may request the UDM to perform a Re-authentication procedure, as there are no more values ​​available for subsequent handovers.

[0373] 5. AMF can send a re-authentication request message to UDM.

[0374] 6. UDM may send a re-authentication response message to AMF in response.

[0375] Afterwards, a re-authentication procedure (e.g., primary authentication in the example of Fig. 12) may be performed. When the re-authentication procedure is performed, the root key for security is regenerated, and NCC, NH, and K are sequentially gNB All security keys, including , can be newly generated.

[0376] Additionally, examples of the disclosure of the present specification may be described with reference to the Xn-Handover procedure. For example, the operating principles and procedures according to the examples of FIGS. 13a and 13b below may include a portion of the handover procedure of a terminal from a base station operation perspective and a procedure for requesting primary authentication from a 5G Core Network perspective.

[0377] Referring to FIGS. 13a and 13b, an example of the Xn-Handover procedure is described based on NCC.

[0378] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals, messages, and fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

[0379] FIG. 13a and FIG. 13b are examples of a handover procedure according to one embodiment of the disclosure of the present specification.

[0380] For reference, in FIGS. 13a and 13b, the Xn interface may be set up first between base stations.

[0381]

[0382] 0. The source gNB / ng-eNB and the target gNB / ng-eNB can share their configurations with each other through the Xn setup procedure. For example, the source base station can send an Xn setup request message to the target base station. The target base station can send an Xn setup response message to the source base station.

[0383] 1. The terminal registers with 5GC through the registration phase, and upon completion of initial setup with the base station, it can enter the RRC active state. At this time, measurement-related information can be configured in the terminal to enable handover to a nearby base station, depending on the situation.

[0384] 2. The terminal can perform measurements and transmit measurement reports to the source base station. For example, the terminal can detect signal strength for a set frequency range and, if a certain condition is met (e.g., the terminal determines that there is a base station with a stronger signal strength than the currently accessed base station), the terminal can transmit a measurement report to the source gNB / ng-eNB.

[0385] 3. The source base station can decide whether to initiate handover by considering the situation of the source gNB / ng-eNB.

[0386] 4. The source gNB / ng-eNB can send a handover request message (e.g., XnAP: Handover Request) to the target gNB / ng-eNB. Operations to prepare for the handover can be initiated. At this time, the handover request message is K NG-RAN * and NCC (Next Hop Chaining Count) may be included. K NG-RAN * Based on the NCC, the target gNB / ng-eNB can use the new gNB security key. The target gNB / ng-eNB can use the received K NG-RAN * K of terminal gNB can be used like this.

[0387] 5. The target gNB / ng-eNB can send a handover request Acknowledge message (e.g., XnAP: HandoverRequestAcknowledge message) to the source gNB / ng-eNB. To provide information about the target node to the UE, the target gNB / ng-eNB can include a transparent container (HandoverCommand) in the handover request Acknowledge message. In addition, the target gNB / ng-eNB can include the NCC received from the source base station in the transparent container (HandoverCommand) and send the handover request Acknowledge message to the source base station.

[0388] 6. The source base station may transmit an RRC reset message containing a handover command (HandoverCommand: HO command) to the UE.

[0389] For example, the Source gNB / ng-eNB can extract the HandoverCommand message from the received XnAP: HandoverRequestAcknowledge message and send the HandoverCommand message (which may include an NCC value) to the UE. The extracted HandoverCommand may include an NCC value.

[0390] 7. The source gNB / ng-eNB can send the SnStatus Transfer message to the target base station. For example, the source gNB / ng-eNB can send the UL / DL PDCP SN and HFN (Hyper Frame Number) status to the target gNB / ng-eNB via XnAP: SnStatus Transfer. The source gNB / ng-eNB can buffer the DL traffic coming from the UPF and forward it to the target gNB / ng-eNB.

[0391] 8. The terminal and target base station can perform RACH-related procedures. For example, the terminal can connect to the target gNB / ng-eNB via random access based on the reconfiguration information received in step 8.

[0392] 9. Once the connection is complete, the terminal can send an RRC reset complete message to the target gNB / ng-eNB.

[0393] 10. The target gNB / ng-eNB can send a path switch request message (e.g., NGAP: PATH SWITCH REQUEST) to the AMF.

[0394] 11. AMF can increase the NCC value it has by one and calculate a new NH based on the information it has.

[0395] If the NCC value increased by AMF becomes 7, AMF can perform Primary Authentication by sending Nudm_UECM_AuthTriggerRequest to UDM. (See example in Figure 14)

[0396] 12. The AMF may send a Path Switch Acknowledge message (e.g., NGAP: PATH SWITCH REQUEST ACKNOWLEDGE) to the target base station. For example, the Path Switch Acknowledge message may include the newly created {NH, NCC} pair from step 11. Upon receiving this message, the target gNB / ng-eNB may store the new {NH, NCC} pair and remove the existing pair.

[0397] 13. The target gNB / ng-eNB can send XnAP: UEContextRelase to release the resources of the terminal held by the source gNB / ng-eNB.

[0398] In the examples of FIGS. 13a and 13b, when AMF requests UDM to perform primary authentication according to step 11, the operation according to the example of FIG. 14 may be performed.

[0399] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals, messages, and fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

[0400] FIG. 14 is an example of a re-authentication procedure according to one embodiment of the disclosure of the present specification.

[0401] 0a. Operators can preset authentication policies in UDM regarding when primary authentication can be initiated.

[0402] 0b. During the terminal registration procedure, the AMF can subscribe by sending Nudm_UECM_Registration to the UDM to specify the serving AMF to which the terminal is registered.

[0403] 1a. In a situation such as step 11 of Fig. 13b, when the AMF increases the NCC value to 7, the AMF may send an authentication request message (e.g., a Nudm_UECM_AuthTriggerRequest message) to the UDM. The authentication request message may include SUPI.

[0404] 1b. The UDM can determine whether to trigger primary authentication based on received events and local policies. For example, the UDM can determine whether to perform primary authentication based on a preset authentication policy.

[0405] 1c. If UDM determines that primary authentication is required, UDM may send an authentication response message (e.g., Nudm_UECM_AuthTriggerResponse) to AMF. Step 1c may be omitted.

[0406] 2. UDM can send a re-authentication notification request message (e.g., Nudm_UECM_Re-AuthenticationNotification Request message) containing SUPI to AMF.

[0407] 3. AMF may send a re-authentication notification response message to the UDM. The re-authentication notification response message may include a result value.

[0408] For example, when AMF receives a re-authentication notification request message (e.g., Nudm_UECM_Re-AuthenticationNotification Request), it can determine whether to perform primary authentication by evaluating AMF's authentication policy, the status of the terminal, etc. If primary authentication is not performed, the cause value can be included when AMF sends Nudm_UECM_Re-AuthenticationNotification Response.

[0409] 4. The AMF may re-perform the primary authentication of the terminal and the 5GC. For example, the primary authentication procedure according to the example of FIG. 7 may be performed. With regard to the primary authentication, reference may also be made to S6.1.2 and S6.1.3 of TS 33.501V18.5.0. For example, the authentication procedure may be triggered according to the example of FIG. 7, and a specific authentication procedure may be performed based on S6.1.3 of TS 33.501V18.5.0.

[0410] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals, messages, and fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.

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

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

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

[0414] The first network entity may be a network entity related to mobility (e.g., AMF). The second network entity may be a network entity related to data management (e.g., UDM).

[0415] In step (S1501), the UE may transmit a registration request message to the first network entity.

[0416] In step (S1502), the first network entity may transmit a registration acceptance message to the UE.

[0417] In step (S1503), the target base station can transmit a path switching request message to the first network entity.

[0418] Based on the path switch message received, the Next Hop Chaining (NCC) value may be increased by 1. For example, the first network entity may increase the NCC value by 1.

[0419] For example, AMF is K according to the example of Fig. 10. AMF Based on this, NH, NCC, etc. can be derived.

[0420] For example, based on the receipt of a path switching message, the first network entity can increment the locally stored NCC value by 1 and compute a new new NH from the stored data using a function. The first network entity can compute the new new NH by using the K of the currently activated 5G NAS security context. AMF can be used. The first network entity can then send a path switch request acknowledge message containing the newly computed {NH, NCC} pair to the target base station. The target base station can store the received {NH, NCC} pair for future handovers and remove any previously unused stored {NH, NCC} pairs.

[0421] In step (S1504), the first network entity can transmit an authentication request message to the second network entity.

[0422] For example, based on the increased NCC value being greater than or equal to 7, the first network entity may send an authentication request message to the network entity involved in data management.

[0423] For example, the authentication request message may include the subscriber permanent identifier (SUPI) of the UE.

[0424] For example, a first network entity may receive a re-authentication notification request message including SUPI from a second network entity. For example, the first network entity may transmit a re-authentication notification response message to the second network entity.

[0425] For example, based on primary authentication with a second network entity, the NCC value is reset to 0, and K AMF can be re-set.

[0426] For example, based on the primary authentication with a network entity, the first network entity establishes a newly established K AMF Next Hop (NH) can be generated based on .

[0427] For example, the first network entity may send a path switching request acknowledge message containing NH and NCC pairs to the target base station.

[0428] According to one embodiment of the disclosure of the present specification, a network entity (or network control node) (e.g., AMF) related to mobility may increase an NCC value by 1 upon receiving a PATH SWITCH REQUEST. The network entity related to mobility may forward an NGAP PATH SWITCH REQUEST ACKNOWLEDGE including the increased NCC value to a target node (e.g., target gNB / en-gNB). For example, if the network entity related to mobility increases the NCC value so that the NCC value becomes 7, the network entity related to mobility sends a Nudm_UECM_AuthTriggerRequest to a network entity related to data management (e.g., UDM) and triggers a re-authentication procedure.

[0429] According to one embodiment of the disclosure of the present specification, a network entity (e.g., UDM) involved in data management can preset a configuration for whether to allow a re-authentication procedure for resetting the NCC value.

[0430] This specification may have various effects.

[0431] For example, according to one embodiment of the disclosure of this specification, security can be effectively protected during handover. For example, a re-authentication procedure can be triggered for a terminal that has undergone repeated handovers. Accordingly, key freshness can be guaranteed by generating a new root key. For example, according to one embodiment of the disclosure of this specification, by initializing the NCC value through the re-authentication process, the impact on the terminal's service and security can be minimized.

[0432] The effects that can be achieved through the specific examples of this specification are not limited to the effects listed above. For example, a person with ordinary skill in the relevant technical field may understand or derive various technical effects 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.

[0433] For reference, the operation of the terminal (e.g., UE) described in this specification may be implemented by the devices 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 instructions / programs (e.g., instructions, executable codes) executable by one or more processors (102 or 202). The 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 instructions / programs 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.

[0434] Additionally, the commands for performing the operations 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). In addition, the commands recorded in the storage medium may be executed by one or more processors (102 or 202) to perform the operations of the terminal described in the disclosure of this specification.

[0435] 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 devices of FIGS. 1 to 3 described below. For example, the network node or the base station may be the first device (100) or the second device (200) of FIG. 2. For example, the operation of the network node or the base station 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 instructions / programs (e.g., instructions, executable codes) 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 (106 or 206), and execute instructions / programs stored in one or more memories (104 or 204) to perform operations of a network node or base station as described in the disclosure of this specification.

[0436] Additionally, the instructions for performing the operations of the network node or base station described in the disclosure of this specification may be stored in a non-volatile (or non-transitory) computer-readable storage medium having the instructions recorded thereon. The storage medium may be included in one or more memories (104 or 204). In addition, the instructions recorded in the storage medium may be executed by one or more processors (102 or 202) to perform the operations of the network node or base station described in the disclosure of this specification.

[0437] Although the preferred embodiments have been described above by way of example, 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 described in the spirit and claims of this specification.

[0438] In the exemplary system described above, the methods are described based on a flowchart as a series of steps or blocks. However, the order of the steps described is not limited, and some steps may occur in a different order or simultaneously with other steps described above. Furthermore, those skilled in the art will understand that the steps depicted in the flowchart are not exclusive, and other steps may be included, or one or more steps in the flowchart may be deleted without affecting the scope of the invention.

[0439] The claims set forth in this specification may be combined in various ways. For example, the technical features of the method claims of this specification may be combined to implement a device, and the technical features of the device claims of this specification may be combined to implement a method. Furthermore, the technical features of the method claims and the technical features of the device claims of this specification may be combined to implement a device, and the technical features of the method claims and the technical features of the device claims of this specification may be combined to implement a method. Other implementations are within the scope of the claims.

Claims

1. A step of receiving a registration request message from a UE; A step of transmitting a registration acceptance message to the UE; A step of receiving a path switch request message from a target base station, Based on the receipt of the above path switch message, the Next Hop Chaining (NCC) value is increased by 1; and A method comprising the step of transmitting an authentication request message to a network entity involved in data management based on the increased NCC value being 7 or greater.

2. In paragraph 1, Based on the primary authentication with the above network entity, the NCC value is reset to 0, and K AMF A method characterized in that a new setting is made.

3. In paragraph 1 or 2, Based on the primary authentication with the above network entity, a newly established K AMF A method further comprising the step of generating a Next Hop (NH) based on the .

4. In any one of paragraphs 1 to 3, A method further comprising the step of transmitting a path switching request acknowledge message including NH and NCC pairs to the target base station.

5. In any one of paragraphs 1 to 4, The above authentication request message includes the subscriber permanent identifier (SUPI) of the UE, A method further comprising the step of receiving a re-authentication notification request message including the SUPI from the network entity.

6. In paragraph 5, A method further comprising the step of transmitting a re-authentication notification response message to said network entity.

7. One or more transmitters and receivers; one or more processors; and comprising one or more memories capable of storing instructions and being operable to the one or more processors; The actions performed based on the above instructions being executed by the one or more processors are: A device according to any one of claims 1 to 6.

8. Step of receiving a handover request message from a source base station; A step of transmitting a handover request approval message to the source base station; comprising the step of transmitting a path switch request message to a network entity involved in mobility, Based on the above path switch message being transmitted, the Next Hop Chaining (NCC) value is increased by 1, and A method characterized in that, based on the increased NCC value being 7 or greater, an authentication request message is transmitted by the network entity to a network entity involved in data management.

9. In any one of the 8 clauses, A method further comprising the step of receiving a path switching request acknowledge message including a Next Hop (NH) and NCC pair from a network entity related to said mobility.

10. One or more transmitters and receivers; one or more processors; and comprising one or more memories capable of storing instructions and being operable to the one or more processors; The actions performed based on the above instructions being executed by the one or more processors are: A device according to any one of claims 8 to 9.

Images