Consideration is given to a method of authenticating an access layer based on a public key infrastructure in a handover in a next generation wireless communication system

Abstract

This disclosure relates to 5G or 6G communication systems for supporting higher data transmission rates than 4G communication systems such as LTE. In a wireless communication system according to an embodiment of the invention, a method for operating a serving base station for mutual authentication in the access layer (AS) portion during handover includes the following steps: receiving a measurement report from a terminal; determining, based on the measurement report, whether the terminal meets handover conditions; if the terminal meets the handover conditions, determining whether the target base station to which the terminal will connect during handover and the serving base station belong to the same authentication area (AA); and sending a handover command to the terminal, the handover command being configured differently depending on whether the target base station and the serving base station belong to the same AA.

Description

Technical Field

[0001] This disclosure relates to a method and apparatus for performing public key infrastructure (PKI) based mutual authentication between a UE and a BS during wireless device handover in a next-generation mobile communication system. Background Technology

[0002] Given the generational evolution of wireless communication, technologies primarily designed for human services have been developed, such as voice calls, multimedia services, and data services. With the commercialization of 5G (fifth-generation) communication systems, the number of connected devices is expected to grow exponentially. These devices will increasingly connect to communication networks. Examples of connected things can include vehicles, robots, dashboards, home appliances, displays, and smart sensors connected to various infrastructure, construction machinery, and factory equipment. Mobile devices are expected to evolve in various forms, such as augmented reality glasses, virtual reality headsets, and holographic devices. To provide a wide range of services by connecting hundreds of billions of devices and things in the 6G (sixth-generation) era, efforts have been made to develop improved 6G communication systems. For these reasons, 6G communication systems are referred to as "beyond 5G" systems.

[0003] The 6G communication system, which is expected to be commercially available around 2030, will have peak data rates in the terabyte (1,000 gigabyte) range and radio latency of less than 100 μsec, and will therefore be 50 times faster than the 5G communication system and have 1 / 10 of its radio latency.

[0004] To achieve such high data rates and ultra-low latency, 6G communication systems have been considered for implementation in the terahertz band (e.g., the 95 GHz to 3 THz band). Since path loss and atmospheric absorption in the terahertz band are expected to be more severe than in the millimeter-wave band introduced in 5G, technologies that can ensure signal transmission distance (i.e., coverage) will become even more critical. Key technologies for ensuring coverage include the development of radio frequency (RF) elements, antennas, novel waveforms with better coverage than orthogonal frequency division multiplexing (OFDM), beamforming and massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, and multi-antenna transmission technologies such as massive MIMO. Furthermore, new technologies for improving terahertz band signal coverage, such as metamaterial-based lenses and antennas, orbital angular momentum (OAM), and reconfigurable smart surfaces (RIS), are discussed.

[0005] Furthermore, to improve spectrum efficiency and overall network performance, the following technologies have been developed for 6G communication systems: full-duplex technology, enabling uplink and downlink transmissions to use the same frequency resources simultaneously; integrated network technologies utilizing satellites, High Altitude Platform Stations (HAPS), etc.; improved network architectures to support mobile base stations and achieve network operation optimization and automation; dynamic spectrum sharing technology based on spectrum usage prediction to avoid collisions; the use of artificial intelligence (AI) in wireless communication to improve overall network operation by leveraging AI from the 6G development design phase and internalizing end-to-end AI support functions; and next-generation distributed computing technologies to overcome the limitations of UE computing capabilities through ultra-high-performance communication and computing resources accessible on the network (such as mobile edge computing MEC, cloud, etc.). In addition, efforts are being made to enhance device connectivity, optimize networks, promote the software-defined networking of network entities, and increase the openness of wireless communication by designing new protocols for use in 6G communication systems, developing mechanisms for achieving hardware-based secure environments and secure data usage, and developing technologies for maintaining privacy.

[0006] The research and development of hyper-connected 6G communication systems (including human-to-machine (P2M) and machine-to-machine (M2M) communication is expected to enable the next hyper-connected experience. Specifically, 6G communication systems are expected to provide services such as truly immersive extended reality (XR), high-fidelity mobile holograms, and digital copies. Furthermore, 6G communication systems will enable services such as enhanced security and reliability in remote surgery, industrial automation, and emergency response, allowing these technologies to be applied to various fields such as industry, healthcare, automotive, and home appliances. Summary of the Invention

[0007] [Technical Issues]

[0008] This disclosure provides a method and apparatus for performing public key infrastructure (PKI)-based authentication between a UE and a BS in the access stratum (AS) portion during handover in a mobile communication system.

[0009] [Technical Solution]

[0010] According to embodiments of this disclosure, a method for operating a serving base station (BS) is provided for mutual authentication of an access layer (AS) portion during handover in a wireless communication system. The method includes: receiving a measurement report from a user equipment (UE); identifying, based on the measurement report, whether the UE meets handover conditions; if the UE meets the handover conditions, identifying whether the target BS to which the UE is connected during handover and the serving BS belong to the same authentication area (AA); and sending a handover command to the UE, the handover command varying depending on whether the target BS and the serving BS belong to the same AA.

[0011] According to the implementation method, when the target BS and the serving BS belong to the same AA, the handover command may include intra-AA handover information; and when the target BS and the serving BS do not belong to the same AA, the handover command may include inter-AA handover information.

[0012] According to the implementation method, when handover information within an AA is sent, mutual authentication based on public key infrastructure (PKI) may not be performed between the UE and the target BS, and the UE may perform a key update process for the target BS; and when handover information between AAs is sent, mutual authentication based on PKI may be performed between the UE and the target BS.

[0013] According to the implementation method, an AA can be a group of cells that are served by physically or logically identical computing nodes.

[0014] According to the implementation method, the same computing node can be a logically or physically identical computing node. A logically identical computing node can be implemented as software from the same operator, software with the same permissions, or software that executes the same process, and a physically identical computing node can be implemented as hardware from the same operator, hardware with the same permissions, or the same hardware component.

[0015] According to the implementation method, when inter-AA handover information is sent, the UE can be separated from the serving BS, and then PKI-based mutual authentication can be performed between the UE and the target BS.

[0016] According to another implementation, when inter-AA handover information is sent, PKI-based mutual authentication can be performed between the UE and the target BS, and the serving BS can forward PKI-based authentication packets to the target BS.

[0017] According to another implementation, when inter-AA handover information is sent, PKI-based mutual authentication can be performed between the UE and the target BS. The serving BS can send PKI-based authentication packets to the network entity, and the network entity can transmit PKI-based authentication packets to the target BS.

[0018] According to embodiments of this disclosure, a method for operating a user equipment (UE) to perform mutual authentication of an access layer (AS) portion during a handover in a wireless communication system includes: receiving a handover command from a serving base station (BS), the handover command varying depending on whether the target base station (BS) to which the UE is connected during the handover belongs to the same authentication area (AA) as the serving BS; and determining, based on information included in the handover command, whether to perform public key infrastructure (PKI)-based mutual authentication with the target BS.

[0019] According to the implementation method, when the target BS and the serving BS belong to the same AA, the handover command may include intra-AA handover information; and when the target BS and the serving BS do not belong to the same AA, the handover command may include inter-AA handover information.

[0020] According to the implementation method, when receiving handover information within an AA, mutual authentication based on public key infrastructure (PKI) may not be performed between the UE and the target BS, and the UE may perform a key update process for the target BS; and when receiving handover information between AAs, mutual authentication based on PKI may be performed between the UE and the target BS.

[0021] According to the implementation method, an AA can be a group of cells that are served by physically or logically identical computing nodes.

[0022] According to the implementation method, upon receiving handover information between AAs, the UE can be separated from the serving BS, and then PKI-based mutual authentication can be performed between the UE and the target BS.

[0023] According to another implementation, upon receiving handover information between AAs, the UE can perform PKI-based mutual authentication with the target BS, and the serving BS can forward PKI-based authentication packets to the target BS.

[0024] According to another implementation, upon receiving handover information between AAs, the UE can perform PKI-based mutual authentication with the target BS. The serving BS can send PKI-based authentication packets to the network entity, and the network entity can transmit PKI-based authentication packets to the target BS.

[0025] A serving base station (BS) supports mutual authentication of the access stratum (AS) portion during handover in a wireless communication system. The BS includes a transceiver and a controller. The controller is connected to the transceiver and configured to control the transceiver and perform control to: receive a measurement report from a user equipment (UE); identify, based on the measurement report, whether the UE meets handover conditions; if the UE meets the handover conditions, identify whether the target BS to which the UE connects during handover and the serving BS belong to the same authentication area (AA); and send a handover command to the UE, the handover command varying depending on whether the target BS and the serving BS belong to the same AA.

[0026] A user equipment (UE) for performing inter-authentication of the access layer (AS) during handover in a wireless communication system, the UE including a transceiver and a controller. The controller is connected to the transceiver and configured to control the transceiver and perform control to: receive a handover command that changes based on whether the target base station (BS) to which the UE is connected during handover belongs to the same authentication area (AA) as the serving BS; and determine, based on information included in the handover command, whether to perform public key infrastructure (PKI)-based inter-authentication with the target BS.

[0027] Embodiments of this disclosure provide a method and apparatus for performing mutual authentication between a wireless device and a BS during handover in a mobile communication system when the wireless device performs public key infrastructure (PKI)-based authentication in the access layer (AS) portion.

[0028] During a handover, the serving BS sends a command to the UE. The UE receives this information and performs authentication if required with the target BS. The UE completes authentication with the target BS and uses the generated key as the key to introduce an encryption key between the BS and the UE.

[0029] During this process, the serving BS may send information, including information indicating whether authentication with the target BS is required when the UE switches over.

[0030] The UE can perform authentication with the pre-defined BS before the handover command.

[0031] The serving BS can instruct the UE to authenticate with the pre-selected BS before handover.

[0032] The target BS can independently determine whether to allow or deny authentication in response to authentication requests from the serving BS or from the UE.

[0033] [Beneficial Effects]

[0034] According to this disclosure, when a UE switches from a serving BS to another BS in a wireless communication system, the security of wireless communication between the UE and the BS can be enhanced by authentication of the access stratum (AS) portion based on public key infrastructure (PKI). Attached Figure Description

[0035] Figure 1 The structure of an LTE system according to an embodiment of this disclosure is shown.

[0036] Figure 2 The radio protocol structure in an LTE system according to an embodiment of the present disclosure is shown.

[0037] Figure 3 A radio protocol structure in a next-generation mobile communication system according to an embodiment of the present disclosure is shown.

[0038] Figure 4 An example of the structure of a mobile communication system according to an embodiment of the present disclosure is shown.

[0039] Figure 5 An example of the structure of a computing node (CN) for managing multiple BSs in a mobile communication system is shown according to an embodiment of the present disclosure.

[0040] Figure 6 The process of a BS broadcasting AA information to a UE via an SIB according to an embodiment of the present disclosure is illustrated.

[0041] Figure 7a and Figure 7b An example of a switching process according to an embodiment of this disclosure is shown.

[0042] Figure 8a and Figure 8b The authentication process during UE handover according to an embodiment of this disclosure is illustrated.

[0043] Figure 9a and Figure 9b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0044] Figure 10a and Figure 10b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0045] Figure 11a and Figure 11b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0046] Figure 12a and Figure 12b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0047] Figure 13a and Figure 13b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0048] Figure 14a and Figure 14b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0049] Figure 15 The switching command process of a BS according to an embodiment of the present disclosure is shown.

[0050] Figure 16 The handover process of a UE according to an embodiment of this disclosure is illustrated.

[0051] Figure 17 The process of performing PKI-based authentication when the UE is configured to connect to the RAN, according to an embodiment, is illustrated.

[0052] Figure 18a and Figure 18b The present disclosure illustrates a process for identifying the validity of a certificate when the UE performs PKI-based authentication with the RAN, according to an embodiment of the present disclosure.

[0053] Figure 19a and Figure 19b The process of identifying certificate validity when the UE performs PKI-based authentication with the RAN, according to another embodiment of this disclosure, is illustrated.

[0054] Figure 20a and Figure 20b The process of identifying certificate validity when the UE performs PKI-based authentication with the RAN, according to another embodiment of this disclosure, is illustrated.

[0055] Figure 21a and Figure 21b The process of identifying certificate validity when the UE performs PKI-based authentication with the RAN, according to another embodiment of this disclosure, is illustrated.

[0056] Figure 22 This is a block diagram illustrating a UE device and a BS device according to embodiments of the present disclosure. Detailed Implementation

[0057] In the following, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0058] In describing embodiments of this disclosure, descriptions related to techniques well-known in the art and not directly associated with this disclosure will be omitted. The purpose of omitting unnecessary descriptions is to prevent confusion regarding the main ideas of this disclosure and to more clearly convey those main ideas.

[0059] For the same reason, some elements may be exaggerated, omitted, or shown schematically in the accompanying drawings. Furthermore, the dimensions of each element do not perfectly reflect the actual dimensions. In the drawings, identical or corresponding elements have the same reference numerals.

[0060] The advantages and features of this disclosure, as well as the ways in which they are implemented, will become apparent from the following detailed description of the embodiments in conjunction with the accompanying drawings. However, this disclosure is not limited to the embodiments set forth below, but can be implemented in a variety of different forms. The following embodiments are provided only to fully disclose this disclosure and to inform those skilled in the art of its scope, which is defined solely by the scope of the appended claims. Throughout this specification, the same or similar reference numerals denote the same or similar elements.

[0061] Here it will be understood that each block of a flowchart, and combinations of blocks within a flowchart, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart blocks. These computer program instructions can also be stored in a computer-usable or computer-readable storage medium that can direct the computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-usable or computer-readable storage medium produce an article of writing including means for implementing the functions specified in the flowchart blocks or blocks. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus, thereby producing a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowchart blocks.

[0062] Furthermore, each block of the flowchart may represent a module, segment, or section of code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions recorded in a block may occur sequentially. For example, two blocks shown consecutively may actually execute substantially simultaneously, or these blocks may sometimes execute in reverse order, depending on the functions involved.

[0063] As used in embodiments of this disclosure, "unit" refers to a software or hardware element that performs a predetermined function, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC). However, "unit" is not always limited to software or hardware. A "unit" may be configured to be stored in addressable storage media or to execute one or more processors. Thus, "unit" includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and parameters. Elements and functions provided by a "unit" may be combined into a smaller number of elements or "units," or divided into a larger number of elements or "units." Furthermore, elements and "units" may be implemented as one or more CPUs within a playback device or a secure multimedia card.

[0064] In the following description, for convenience, terms for identifying access nodes, terms relating to network entities, terms relating to messages, terms relating to interfaces between network entities, terms relating to various identification information, etc., are used by way of example. Therefore, this disclosure is not limited to the terms used below, and other terms relating to subjects with equivalent technical meaning may be used.

[0065] In the following description, for ease of description, terms and names defined in 5G, NR, and LTE system standards will be used to describe this disclosure. However, this disclosure is not limited to these terms and names and can be applied in the same manner to systems conforming to other standards.

[0066] In other words, the following detailed description of the embodiments of this disclosure is primarily directed to communication standards defined by 3GPP. However, it is clear to those skilled in the art that the main ideas of this disclosure can be applied, with some modifications, to other communication systems with similar technical backgrounds without significantly departing from the scope of this disclosure.

[0067] Wireless communication systems are evolving into broadband wireless communication systems, which use communication standards such as 3GPP High-Speed ​​Packet Access (HSPA), LTE {Long Term Evolution or Evolved Universal Terrestrial Radio Access (E-UTRA)}, LTE-Advanced (LTE-A), LTE-Pro, 3GPP2 High-Rate Packet Data (HRPD), Ultra Mobile Broadband (UMB), IEEE 802.16e, and typically voice-based services to provide high-speed and high-quality packet data services.

[0068] As a typical example of a broadband wireless communication system, the LTE system employs an Orthogonal Frequency Division Multiplexing (OFDM) scheme in the downlink (DL) and a Single-Carrier Frequency Division Multiple Access (SC-FDMA) scheme in the uplink (UL). The uplink is the radio link through which user equipment (UE) (or mobile station (MS)) transmits data or control signals to the base station (BS) (next-generation base station (gNB) or eNode B (eNB)), while the downlink is the radio link through which the base station transmits data or control signals to the UE. This multiple access scheme separates the data or control information of each user by allocating and operating time-frequency resources for transmitting data or control information to each user, thus avoiding overlap and establishing orthogonality.

[0069] Because post-LTE communication systems, namely 5G communication systems, must freely reflect the diverse needs of users, service providers, and others, they must support services that meet these diverse needs. Services considered in 5G communication systems include enhanced mobile broadband (eMBB) communication, massive machine-type communication (mMTC), and ultra-reliable low-latency communication (URLLC), among others.

[0070] eMBB aims to provide higher data rates than those supported by existing LTE, LTE-A, or LTE-Pro systems. For example, in 5G communication systems, eMBB must provide a peak data rate of 20Gbps in the downlink and 10Gbps in the uplink for a single base station. Furthermore, 5G communication systems must provide increased user-aware data rates and maximum data rates to the UE. To meet these requirements, improved transmit / receive technologies, including further enhanced multiple-input multiple-output (MIMO) transmission, are needed. Moreover, the data rates required by 5G communication systems can be achieved using a frequency bandwidth greater than 20MHz in the 3GHz to 6GHz band or 6GHz or higher, instead of using a maximum of 20MHz of transmission bandwidth in the 2GHz band used in LTE.

[0071] Furthermore, in 5G communication systems, mMTC is considered to support application services such as the Internet of Things (IoT). To effectively deliver IoT, mMTC needs to support connections for a large number of UEs within a cell, enhance UE coverage, improve battery life, and reduce UE costs. Since IoT provides communication capabilities to various sensors and devices, it must support a large number of UEs within a cell (e.g., 1,000,000 UEs / km). 2 Furthermore, because the UE may be located in shadow areas such as the basement of a building (where no cell coverage exists due to the nature of the service), mMTC-enabled UEs may require wider coverage than other services provided by 5G communication systems. Since it is difficult to frequently replace the UE's battery, mMTC-enabled UEs must be configured to be inexpensive and require very long battery life, such as 10 to 15 years.

[0072] Finally, URLLC is a cellular-based mission-critical wireless communication service that can be used for remote control of robots or machines, industrial automation, drones, remote healthcare, emergency alerts, and more. Therefore, URLLC must provide communication with ultra-low latency and ultra-high reliability. For example, services supporting URLLC must meet an air interface latency of less than 0.5ms and also require 10... -5 Or even lower packet error rates. Therefore, for services that support URLLC, 5G systems must provide shorter transmission time intervals (TTIs) than other services, and also require a design that allocates significant resources in the frequency band to ensure the reliability of the communication link.

[0073] The three services in a 5G communication system—eMBB, URLLC, and mMTC—can be multiplexed and transmitted within a single system. In this case, different transmit / receive technologies and parameters can be used between the services to meet their varying requirements.

[0074] Furthermore, services such as mobile holograms, virtual reality, and augmented reality are emerging in communications. To support these services, component technologies such as artificial intelligence (AI), sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology are being researched in communication systems.

[0075] Figure 1 The structure of an LTE system according to an embodiment of this disclosure is shown.

[0076] Figure 1 An example is shown where multiple base stations (BS) and user equipment (UE) move and change the connected BS in a mobile communication system to which embodiments of the present disclosure are applied.

[0077] BSS 1-20 and 1-30 can connect to some neighboring BS, and can also connect to the mobile communication core network (CN) 1-40, such as the evolved packet core (EPC) or the 5G core network (5GC).

[0078] The radio access technologies for BS 1-20 and 1-30 can be LTE, NR, WiFi, etc., but are not limited to these. For example, BS 1-20 and 1-30 can be mobile communication BSs independent of radio access technologies.

[0079] UE 1-10 can connect to a BS to receive mobile communication services. It can connect to different BSs depending on its mobility and can continuously receive mobile communication services through a handover (HO or handover) procedure. Figure 1 In the example, UE 1-10, which is already connected to BS 1-20, can disconnect from BS 1-20 and connect to the new BS 1-30.

[0080] Figure 2 The radio protocol structure in an LTE system according to an embodiment of the present disclosure is shown.

[0081] refer to Figure 2 UE 2-100 and LTE eNB 2-200 respectively include Packet Data Convergence Protocol (PDCP) 2-110 and 2-210, Radio Link Control (RLC) 2-120 and 2-220, and Media Access Control (MAC) 2-130 and 2-230 in the radio protocol of the LTE system. Elements of the radio protocol may be referred to as layers, entities, or devices.

[0082] Packet Data Convergence Protocol (PDCP) 2-110 and 2-210 perform the operation of compressing / reconstructing IP headers. The main functions of PDCP are described below.

[0083] - Header compression and decompression functions (Header compression and decompression: ROHC only)

[0084] - User data transmission function (transmission of user data)

[0085] Sequential transfer function (sequential transfer of upper-layer PDUs in the PDCP reconstruction process of RLC AM)

[0086] - Sequence rearrangement function (for separate bearers in DC (RLC AM only): routing of PDCPPDU for transmission and reordering of PDCP PDU for reception)

[0087] - Duplicate detection function (duplicate detection of low-level service data units (SDUs) in the PDCP reconstruction process of RLC AM)

[0088] - Retransmission function (retransmission of PDCP SDU during handover (for separate bearers in DC), retransmission of PDCP PDU during PDCP data recovery process (for RLC AM))

[0089] - Encryption and decryption functions (encryption and decryption)

[0090] - Timer-based SDU discarding function (timer-based SDU discarding in uplink)

[0091] The Radio Link Control (RLC) 2-120 and 2-220 reconfigure PDCP Packet Data Units (PDUs) to the appropriate size and perform ARQ operations. The main functions of the RLC are described below.

[0092] - Data transmission function (transmission of upper-layer PDUs)

[0093] -ARQ function (error correction via ARQ (for AM data transmission only))

[0094] - Cascading, segmentation, and reassembly functions (cascading, segmentation, and reassembly of RLC SDUs (for UM and AM data transmission only))

[0095] - Re-segmentation function (re-segmentation of RLC data PDUs (only for AM data transmission))

[0096] - Reordering function (Reordering of RLC data PDUs (only for UM and AM data transfer))

[0097] - Copy detection function (only for UM and AM data transfer)

[0098] - Error detection function (protocol error detection (AM data transmission only))

[0099] -RLC SDU deletion function (RLC SDU discard (only for UM and AM data transfer))

[0100] -RLC Reconstruction Function (RLC Reconstruction)

[0101] MACs 2-130 and 2-230 connect to various RLC layer devices included in a UE and perform operations for multiplexing RLCPDUs to MAC PDUs and demultiplexing RLC PDUs from MAC PDUs. The main functions of the MACs are described below.

[0102] - Mapping function (mapping between logical channels and transport channels)

[0103] - Multiplexing and demultiplexing functions (multiplexing MAC SDUs belonging to one or different logical channels into transport blocks (TBs) passed to the physical layer on the transport channel / demultiplexing MAC SDUs belonging to one or different logical channels from transport blocks (TBs) passed from the physical layer on the transport channel)

[0104] - Scheduling information reporting function (Scheduling Information Report)

[0105] - HARQ functionality (error correction via HARQ)

[0106] - Logical channel priority control function (priority processing between logical channels of a UE)

[0107] -UE priority control function (performs priority processing among UEs through dynamic scheduling)

[0108] -MBMS service identification function (MBMS service identification)

[0109] -Transmission format selection function (Transmission format selection)

[0110] - Fill function (Fill)

[0111] Physical layers 2-140 and 2-240 perform channel coding and modulation operations on higher-layer data to generate OFDM symbols and transmit OFDM symbols via radio channels, or demodulate and channel decode OFDM symbols received via radio channels and transmit the demodulated and channel-decoded OFDM symbols to higher layers.

[0112] Figure 3 The structure of a radio protocol in a next-generation mobile communication system according to an embodiment of the present disclosure is shown.

[0113] refer to Figure 3 In the radio protocols included in next-generation mobile communication systems, UE 3-100 and NR gNB 3-200 respectively include NR Service Data Application Protocol (SDAP) 3-110 and 3-210, NR PDCP 3-120 and 3-220, NR RLC 3-130 and 3-230, and NR MAC 3-140 and 3-240. Elements of a radio protocol can be referred to as layers, entities, or devices.

[0114] The main functions of NR SDAP 3-110 and 3-210 may include some of the following functions.

[0115] - User data transmission function (transmission of user plane data)

[0116] - The function of mapping uplink and downlink QoS flows and data bearers (mapping between QoS flows and DRBs for both DL and UL).

[0117] - Functionality to tag uplink and downlink QoS flow IDs (tag QoS flow IDs in DL and UL packets)

[0118] - Functionality for mapping reflected QoS flows to data bearers for uplink SDAP PDUs (Mapping reflected QoS flows from UL SDAP PDUs to DRBs)

[0119] For SDAP layer devices, the UE can receive RRC messages regarding whether to configure the SDAP layer device header or functionality for each PDCP layer device, each bearer, or each logical channel. If the SDAP header is configured, the 1-bit NAS-reflected QoS indicator and the 1-bit AS-reflected QoS indicator in the SDAP header can instruct the UE to update or reconfigure information regarding the mapping of QoS flows and data bearers in the uplink and downlink. The SDAP header may include QoS flow ID information indicating QoS. QoS information can be used as data processing priority and scheduling information to smoothly support service.

[0120] The main functions of NR PDCP 3-120 and 3-220 may include some of the following functions.

[0121] Header compression and decompression functions (header compression and decompression: ROHC only)

[0122] - User data transmission function (transmission of user data)

[0123] - Sequential pass function (sequential pass of upper-layer PDUs)

[0124] - Disordered transfer function (out-of-order transfer of upper-layer PDUs)

[0125] - Reordering function (for reordering received PDCP PDUs)

[0126] - Duplicate detection function (duplicate detection of low-level SDUs)

[0127] - Retransmission function (PDCP SDU retransmission)

[0128] - Encryption and decryption functions (encryption and decryption)

[0129] - Timer-based SDU discarding function (timer-based SDU discarding in uplink)

[0130] The reordering function of the NR PDCP device is to reorder the PDCP PDUs received by the lower layer based on the PDCP sequence number (SN). It may also include the function of sequentially transmitting the reordered data to the higher layer, directly sending the recorded data regardless of the order, recording the PDCP PDUs lost due to reordering, reporting the status of the lost PDCP PDUs to the transmitting side, and requesting the retransmission of the lost PDCP PDUs.

[0131] The main functions of NR RLC 3-130 and 3-230 may include some of the following functions.

[0132] - Data transmission function (transmission of upper-layer PDUs)

[0133] - Sequential pass function (sequential pass of upper-layer PDUs)

[0134] - Disordered transfer function (out-of-order transfer of upper-layer PDUs)

[0135] -ARQ functionality (error correction via ARQ)

[0136] - Cascading, segmentation, and reassembly functions (cascading, segmentation, and reassembly of RLC SDU)

[0137] - Re-segmentation function (re-segmentation of RLC data PDUs)

[0138] - Reordering function (reordering RLC data PDUs)

[0139] - Duplicate detection function (duplicate detection)

[0140] - Error detection function (protocol error detection)

[0141] -RLC SDU deletion function (RLC SDU discard)

[0142] -RLC Reconstruction Function (RLC Reconstruction)

[0143] The sequential delivery function (Sequential Delivery) of NR RLC devices is the function of sequentially transmitting PDCP PDUs received from lower layers to higher layers. When an original RLC SDU is divided into multiple RLC SDUs and then received, it may include the following functions: reassembling and transmitting RLC SDUs; reordering received RLC PDUs based on the RLC sequence number (SN) or PDCP SN; recording PDCP PDUs lost due to reordering; reporting the status of lost PDCP PDUs to the transmitting side; requesting retransmission of lost PDCP PDUs (if lost RLC SDUs exist); transmitting only RLC SDUs before the lost RLC SDU to higher layers sequentially if a predetermined timer expires, even if lost RLC SDUs exist; transmitting all received RLC SDUs sequentially to higher layers before the start of a timer; or transmitting all RLCSDUs received up to that time sequentially to higher layers, even if lost RLC SDUs exist, if a predetermined timer expires.

[0144] Furthermore, NR RLC devices can process RLC PDUs sequentially according to their reception order (based on arrival order, regardless of sequence number or SN) and can transmit RLC PDUs to PDCP devices regardless of their order (out-of-order transmission). If the received RLC SDU is a segment, the NR RLC device can receive segments stored in the buffer or those to be received in the future, reconfigure these segments into a complete RLC PDU, process the RLC PDU, and then send it to the PDCP device. The NR RLC layer may not include concatenation functionality, and this functionality can be performed by the NR MAC layer or replaced by the multiplexing functionality of the NR MAC layer.

[0145] The out-of-order function (out-of-order transmission) of NR RLC devices is the function of directly transmitting RLC SDUs received from lower layers to higher layers regardless of the order of the RLC SDUs. When an original RLC SDU is divided into multiple RLC SDUs and then received, it may include the functions of reassembling and transmitting RLC PDUs, storing the RLC SN or PDCP SN of the received RLC PDUs, reordering RLCPDUs, and recording lost RLC PDUs.

[0146] NR MAC 3-140 and 3-240 can be connected to multiple NR RLC layer devices configured in a UE, and the main functions of NR MAC may include some of the following functions.

[0147] - Mapping function (mapping between logical channels and transport channels)

[0148] - Multiplexing and demultiplexing functions (MAC SDU multiplexing / demultiplexing)

[0149] - Scheduling information reporting function (Scheduling Information Report)

[0150] - HARQ functionality (error correction via HARQ)

[0151] - Logical channel priority control function (priority processing between logical channels of a UE)

[0152] -UE priority control function (performs priority processing among UEs through dynamic scheduling)

[0153] -MBMS service identification function (MBMS service identification)

[0154] -Transmission format selection function (Transmission format selection)

[0155] - Fill function (Fill)

[0156] NR PHY layers 3-150 and 3-250 perform operations for channel coding and modulation of higher-layer data to generate OFDM symbols and transmit OFDM symbols via radio channels, or demodulate and channel decode OFDM symbols received via radio channels and transmit the demodulated and channel-decoded OFDM symbols to higher layers.

[0157] Figure 4 An example of the structure of a mobile communication system according to an embodiment of the present disclosure is shown.

[0158] refer to Figure 4 Base stations (BS) 4-200 and 4-300 can be implemented as mobile communication base stations connected to a mobile communication core network (CN) 4-100, independent of LTE, eNB, NR gNB, WiFi AP, or radio access technologies, and connected to a mobile communication core network (CN) such as an evolved packet core (EPC) or a 5G core network (5GC).

[0159] exist Figure 4 In this configuration, BS 4-200 and 4-300 can be configured as a single unit or divided into multiple units. BSs configured in this way support the mobile communication functions of each division.

[0160] Examples of functions include PDCP / RLC / MAC / PHY / RF layers. A single unit can support multiple functions, which can be distributed and supported by multiple units, or a single function can be supported by one or more partitioned units.

[0161] BS 4-200 and 4-300 can be connected via an inter-BS interface such as the X2 or Xn interface, and BS 4-200 and 4-300, as well as CN 4-100, can be connected between the BS and the core network via an interface such as the S1 or NG interface.

[0162] The techniques proposed in this disclosure can be applied to situations where a UE 4-100 is connected to one of BS 4-200 and 4-300 and performs a handover between BS 4-200 and 4-300, regardless of the internal configuration of BS 4-200 and 4-300.

[0163] During a normal handover, the serving BS can determine the target BS based on measurement information sent by UE 4-100 according to its internal policy, and send radio configuration information received from the target BS to UE 4-100 to connect UE 4-100 to the target BS. Through this process, UE 4-100 can hand over from the serving BS to the target BS.

[0164] Figure 5 An example of the structure of a computing node (CN) for managing multiple BSs in a mobile communication system is shown according to an embodiment of the present disclosure.

[0165] Figure 5 The CN shown can be implemented as a mobile communication base station that is independent of LTE, eNB, NR, gNB, WiFi AP or radio access technology and connected to a mobile communication core network (CN) such as an evolved packet core (EPC) or a 5G core network (5GC).

[0166] exist Figure 5 In this configuration, a compute node (CN) is a unit that manages one or more base stations (BSs). BSs and CNs configured in this way each support various mobile communication functions. Examples of these functions include RRC / PDCP / RLC / MAC / PHY / RF layers.

[0167] The same CN can be logically identical or physically identical. Logically identical CNs can be implemented as software with the same owner (or operator), software with the same permissions, or software performing the same process. Physically identical CNs can be implemented as hardware with the same owner (or operator), hardware with the same permissions, or the same hardware components.

[0168] A CN manages one or more BSs, and authentication is performed by the UE on a CN when the AS portion between the UE and the BS is authenticated. The set of one or more BSs (or cells) managed by a CN may be referred to as an Authentication Area (AA). Depending on the implementation, the AA may be configured differently for each specific UE, scenario, or service.

[0169] According to one implementation, the ratio of the number of cells to the number of CNs within an AA can be "1:n" (where N is a natural number greater than or equal to 1). According to another implementation, the ratio of the number of cells to the number of CNs within an AA can be "M:N" (where M and N are natural numbers greater than or equal to 1).

[0170] In the embodiments of this disclosure, when a UE hands over within an AA served by the same CN, it does not need to perform new PKI authentication with the target BS.

[0171] For example, in Figure 5 In this context, CN1 can be partitioned and support functions together with BS1 to BS4, and can manage BS1 to BS4. The BS managed by CN1 is Authentication Zone 1 (AA1).

[0172] In addition, Figure 5 In this context, CN2 can be used to partition and support functions along with BS5 through BS8, and can also manage BS5 through BS8. BSs managed by CN2 are referred to as Authentication Zone 2 (AA2).

[0173] Figure 6 The process of a BS broadcasting AA information to a UE via an SIB according to an embodiment of the present disclosure is illustrated.

[0174] In embodiments of this disclosure, the authentication area (AA) is a set of one or more BSs managed by the CN, and the BS can notify the UE of the area to be authenticated.

[0175] exist Figure 6 In this context, RAN 6-20 can periodically (or non-periodically) transmit AA information to UE 6-10 via System Information Block (SIB).

[0176] RAN 6-20 can be periodically (using timer T) AA 6-40) or non-periodicly transmits AA information, and when UE 6-10 receives AA information broadcast by RAN 6-20, UE 6-10 should know whether the corresponding RAN belongs to a specific AA. Through this method, UE 6-10 can receive AA information not only through the SIB of the serving BS but also through the SIBs of neighboring cells. Furthermore, through this method, in RRC inactive or RRC idle states, and in RRC connected states, UE 6-10 can receive AA information as needed through the SIBs transmitted by RAN 6-20.

[0177] In operation 6-30, RAN 6-20 configures the SIBx in the SIB to indicate the transmission of AA information and broadcasts the SIB. Subsequently, in operation 6-50, RAN 6-20 can insert the AA information into SIBx and broadcast it.

[0178] When AA information is received, in operation 6-80, UE 6-10 can compare the AA information with the UE's current AA and identify whether the RAN that sent the AA information belongs to the same AA as the serving BS. The AA information sent by RAN 6-20 may have an identifier to distinguish whether the AA information was sent by another RAN or by the corresponding RAN before or after the AA information.

[0179] RAN 6-20 can be based on a predetermined period (T) determined in advance by UE 6-10 and RAN 6-20. AA This allows you to send AA information without setting the SIBx bit for sending AA in the SIB used for sending AA information.

[0180] Figure 7a and Figure 7b An example of a switching process according to an embodiment of this disclosure is shown.

[0181] according to Figure 7a During a normal handover, the serving BS 7-120 determines the target BS 7-130 based on the measurement information sent by the UE 7-100 according to its internal policy. It then sends the radio configuration information received from the target BS 7-130 to the UE 7-100 and connects the UE 7-100 to the target BS 7-130. Through this process, the UE 7-100 hands over from the serving BS 7-120 to the target BS 7-130. The detailed process shown in Figure 7 is described below.

[0182] The serving BS 7-120 can send measurement control 7-210 to the UE 7-100. The measurement information provided by the serving BS 7-120 is used to control the mobility of the UE 7-100. Thereafter, data communication (packet data) 7-220 is performed according to regular communication.

[0183] In measurement operation 7-230, UE 7-100 can measure the radio signal strength of neighboring BS cells, and when measurement control 7-210 meets the conditions, it sends a measurement report 7-240 to the serving BS 7-120.

[0184] Upon receiving Measurement Report 7-240, Serving BS 7-120 can determine the handover of UE 7-100 based on Measurement Report 7-240 in Operation 7-250. Serving BS 7-120 can send a Handover Request Message 7-260 to Target BS 7-130 to transmit the information required to prepare for the handover.

[0185] The target BS 7-130 can perform admission control 7-270 to determine whether handover is permitted. During this process, the target BS 7-130 configures the resources required to connect the UE 7-100 to the target BS 7-130.

[0186] When the HO (Hosting Request) is complete, the target BS 7-130 may send a handover request Ack (acknowledgment) 7-280 to the serving BS 7-120. The handover request Ack 7-280 includes information required to connect UE 7-100 to the target BS 7-130. The handover request Ack message includes radio connection reconfiguration message information received from the target BS 7-130, and the serving BS 7-120 may send an RRC (Reconfiguration Control Request) connection reconfiguration message 7-290 to UE 7-100. The RRC connection reconfiguration message 7-290 includes radio connection reconfiguration message information received from the target BS 7-130.

[0187] Upon receiving an RRC connection reconfiguration message 7-290 containing the parameters required for handover, UE 7-100 leaves the previous cell and performs synchronization 7-300 to access the new cell. Furthermore, in operations 7-310 and 7-320, serving BS 7-120 transmits the received packets to target BS 7-130. Target BS 7-130 receives packets from serving BS 7-120.

[0188] UE 7-100 performs synchronization 7-340 against target BS 7-130 and accesses target BS 7-130 via RACH. Target BS 7-130 allocates uplink (UL) resources and responds via TA. UE 7-100 sends an RRC connection reconfiguration completion 7-360 and indicates that the handover is complete.

[0189] Subsequently, in operation 7-370, UE 7-100 can receive packet data through target BS 7-130. Target BS 7-130 performs the path change procedure 7-380 with the network (MME, etc.) to notify UE 7-100 that the cell has changed. When a UE context release message is received from the network, serving BS 7-120 performs UE context release 7-390.

[0190] However, when performing the regular handover shown in Figure 7, direct authentication is not performed between the UE and the BS. That is, direct authentication does not exist in the Access Layer (AS) portion.

[0191] In embodiments of this disclosure, man-in-the-middle (MITM) attacks between the UE and BS due to unauthenticated AS portions can be avoided. Furthermore, in embodiments of this disclosure, strong radio signals are transmitted to the UE, thereby preventing man-in-the-middle attacks by fake base stations (FBSs) relaying radio signals between the UE and BS.

[0192] In embodiments of this disclosure, forgery of FBS PHY / MAC / RRC control plane (CP) messages due to unauthenticated AS portions can be prevented. In embodiments of this disclosure, attacks involving forged SIB information and the sending of false disaster messages to the UE can be avoided.

[0193] In this disclosure, the UE and BS perform public key infrastructure (PKI)-based authentication, thereby enabling secure communication with the target to which they wish to communicate. Through this disclosure, the BS and UE can protect messages by encrypting / decrypting or digitally signing them using a key known in advance by the BS / UE or a key generated through authentication.

[0194] Figures 8 to 14 illustrate the process of performing a PKI-based AS partial authentication process in a switching scenario according to an embodiment of the present disclosure, which differs from the switching process in Figure 7.

[0195] Figure 8a and Figure 8b The authentication process during UE handover according to an embodiment of this disclosure is illustrated.

[0196] According to Figure 8a During the handover, the serving BS 8-120 can determine the target BS 8-130 based on the measurement information sent by the UE 8-100 and according to its internal policy. It will then send the radio configuration information received from the target BS 8-130 to the UE 8-100 and connect the UE 8-100 to the target BS 8-130.

[0197] exist Figure 8a and Figure 8b In the illustrated implementation, service BS 8-120 can identify that the service BS belongs to the same AA as the target BS 8-130, and allows the generation of keys through existing key derivation without PKI-based authentication. The detailed process is described below.

[0198] Serving BS 8-120 can send measurement control 8-210 to UE 8-100. The measurement information provided by Serving BS 8-120 is used to control the mobility of UE 8-100. Thereafter, data communication (packet data) 8-220 is performed according to regular communication.

[0199] In measurement operation 8-230, UE 8-100 measures the radio signal strength of neighboring BS cells, and when measurement control 8-210 meets the conditions, sends a measurement report 8-240 to serving BS 8-120. Upon receiving measurement report 8-240, in operation 8-250, serving BS 8-120 determines whether to hand over UE 8-100 and identifies whether serving BS 8-120 and target BS 8-130 belong to the same AA. Serving BS 8-120 may send a handover request message 8-260 to target BS 8-130 to transmit the information required for preparing for handover. Target BS 8-130 performs admission control 8-270 to determine whether handover is permitted. During this process, target BS 8-130 configures the resources required to connect UE 8-100 to the target BS.

[0200] When the HO (Hosting Organization) preparation is complete, the target BS 8-130 sends a handover request Ack (acknowledgment) 8-280 to the serving BS 8-120. The handover request Ack 8-280 includes the information required to connect UE 8-100 to the target BS 8-130. The handover request Ack message includes radio connection reconfiguration message information received from the target BS 8-130, and the serving BS 8-120 sends an RRC (Reconfiguration Control Code) connection reconfiguration message 8-290 to UE 8-100. The RRC connection reconfiguration message 8-290 includes radio connection reconfiguration message information received from the target BS 8-130.

[0201] The serving BS 8-120 configures the HO bit within the AA in the RRC connection reconfiguration message 8-290 and notifies the UE 8-100 that the serving BS 8-120 and the target BS 8-130 belong to the same AA and do not require PKI authentication, so as to allow the generation of a key between the UE 8-100 and the target BS 8-130 through key derivation.

[0202] Upon receiving RRC connection reconfiguration message 8-290, which includes the required handover parameters and the HO bit within the AA, UE 8-100 leaves the previous cell and performs synchronization 8-300 to access the new cell. Furthermore, in operations 8-310 and 8-320, serving BS 8-120 sends the received packets to target BS 8-130. Target BS 8-130 receives packets from serving BS 8-120.

[0203] UE 8-100 performs synchronization 8-340 against target BS 8-130 and accesses the target BS via RACH. Target BS 8-130 allocates a UL and responds via TA. UE 8-100 sends an RRC connection reconfiguration completion 8-360 and indicates that the handover is complete. Subsequently, in operation 8-370, UE 8-100 can receive packet data through target BS 8-130. Target BS 8-130 performs a path change 8-380 in the network (MME, etc.) to notify the UE that the cell has changed. When a UE context release message is received from the network, serving BS 8-120 performs a UE context release 8-390.

[0204] Subsequently, UE 8-100 and target BS 8-130 share the AS portion encryption key via key derivation during intra-AA handover.

[0205] Figure 9a and 9b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0206] According to Figure 9a During the handover, the serving BS 9-120 can determine the target BS 9-130 based on the measurement information sent by the UE 9-100 and according to its internal policy. It then sends the radio configuration information received from the target BS 9-130 to the UE 9-100 and connects the UE 9-100 to the target BS 9-130. The serving BS 9-120 identifies that it belongs to a different AA than the target BS 9-130 and allows the generation of a key between the UE 9-100 and the target BS 9-130 through PKI-based authentication. In Figure 8, the compute node (CN) refers to the base station, the BS, and the target to be authenticated. The detailed process is described below.

[0207] Serving BS 9-120 sends Measurement Control 9-210 to UE 9-100. The measurement information provided by Serving BS 9-120 is used to control the mobility of UE 9-100. Subsequently, data communication (packet data) 9-220 is performed according to regular communication. In Measurement Operation 9-230, UE 9-100 measures the radio signal strength of neighboring BS cells, and when Measurement Control 9-210 meets the conditions, sends a Measurement Report 9-240 to Serving BS 9-120. Upon receiving Measurement Report 9-240, in Operation 9-250, Serving BS 9-120 determines the handover for UE 9-100 and identifies whether Serving BS 9-120 and target BS 9-130 belong to the same AA.

[0208] Serving BS 9-120 may send a handover request message 9-260 to target BS 9-130 to transmit the information required for handover preparation. Target BS 9-130 performs admission control 9-270 to determine whether handover is permitted. During this process, target BS 9-130 configures the resources required to connect UE 9-100 to target BS 9-130. When HO preparation is complete, target BS 9-130 sends a handover request Ack (acknowledgment) 9-280, which includes the information required to connect UE 9-100 to target BS 9-130. The handover request Ack message includes radio connection reconfiguration message information received from the target BS 9-130, and the serving BS 9-120 sends an RRC connection reconfiguration message 9-290 to the UE 9-100, which includes radio connection reconfiguration message information received from the target BS 9-130.

[0209] In operation 9-290, the serving BS 9-120 configures the inter-AA HO bit in the RRC connection reconfiguration message 9-290 and notifies the UE 9-100 that PKI authentication is required because the serving BS 9-120 and the target BS 9-130 belong to different AAs. According to an implementation, the RRC connection reconfiguration message 9-290 may include information indicating an inter-AA HO of a non-inter-AA HO bit type, and this information may indicate that the serving BS 9-120 and the target BS 9-130 belong to different AAs.

[0210] When UE 9-100 receives an RRC connection reconfiguration message 9-290, which includes the required handover parameters and inter-AA HO bits (or inter-AA HO information), it leaves the previous cell and performs synchronization 9-300 to access the new cell. Additionally, in operations 9-310 and 9-320, serving BS 9-120 sends received packets to target BS 9-130. Target BS 9-130 receives packets from serving BS 9-120. In operation 9-330, target BS 9-130 may send buffered packets from serving BS 9-120 to AMF 9-140. UE 9-100 performs synchronization 9-340 against the target BS and accesses target BS 9-130 via RACH. In operation 9-350, target BS 9-130 assigns a UL and responds via TA. UE 9-100 and target BS 9-130 perform PKI-based authentication, and... Figures 17 to 2 Figure 1 shows the detailed operation of PKI-based authentication 9-360.

[0211] UE 9-100 sends an RRC connection reconfiguration completion message (9-370) and indicates that the handover is complete. Subsequently, in operation (9-380), UE 9-100 can receive packet data through the target BS 9-130. The target BS 9-130 performs a path change in the network (MME, etc.) (9-390) to notify UE 9-100 that it has been handed over. When a UE context release message is received from the network, the serving BS 9-120 performs a UE context release (9-400).

[0212] Subsequently, after PKI-based authentication, UE 9-100 and target BS 9-130 share the AS portion encryption key using the generated key.

[0213] Figure 10a and 10b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0214] According to Figure 10a During handover, the serving BS 10-120 can determine the target BS 10-130 based on measurement information sent by the UE 10-100 and its internal policy. It then sends the radio configuration information received from the target BS 10-130 to the UE 10-100 and connects the UE 10-100 to the target BS 10-130. The serving BS 10-120 identifies that it belongs to a different AA than the target BS 10-130 and allows the generation of a key between the UE 10-100 and the target BS 10-130 via PKI-based authentication. The serving BS 10-120 can forward message transmissions for the UE 10-100 to authenticate the target BS 10-130, reducing handover interruption time, which is the handover latency during the handover process. The compute node (CN) refers to the base station, the BS, and the target to be authenticated; the detailed process is described below.

[0215] Serving BS 10-120 sends Measurement Control 10-210. Measurement information provided by Serving BS 10-120 is used to control the mobility of UE 10-100. Subsequently, data communication (packet data) 10-220 is performed according to regular communication. In Measurement Operation 10-230, the UE measures the radio signal strength of neighboring BS cells, and when Measurement Control 10-210 meets the conditions, sends a Measurement Report 10-240 to Serving BS 10-120. Upon receiving Measurement Report 10-240, in Operation 10-250, Serving BS 10-120 determines, through appropriate determination, whether to hand over UE 10-100 and identifies whether Serving BS 10-120 belongs to the same AA as target BS 10-130. Serving BS 10-120 may send a Handover Request Message 10-260 to target BS 10-130 to transmit the information required for handover preparation. The target BS 10-130 performs admission control 10-270 to determine whether handover is permitted. During this process, the target BS 10-130 configures the resources required to connect UE 10-100 to the target BS 10-130. When HO preparation is complete, the target BS 10-130 sends a handover request Ack (acknowledgment) 10-280, which includes the information required to connect UE 10-100 to the target BS. The handover request Ack message includes radio connection reconfiguration message information received from the target BS 10-130, and the serving BS 10-120 sends an RRC connection reconfiguration message 10-290 to UE 10-100, which includes radio connection reconfiguration message information received from the target BS 10-130. In operation 10-290, service BS 10-120 configures the inter-AA HO bit (or inter-AA HO information) in RRC connection reconfiguration message 10-290 to notify service BS 10-200 and target BS 10-130 that they belong to different AAs and require PKI authentication, and configures the PKI fwd bit to notify that authentication with target BS 10-130 can be performed through service BS 10-120.

[0216] When UE 10-100 receives RRC connection reconfiguration message 10-290, which includes handover required parameters and inter-AA HO bits (or inter-AA HO information) / PKI fwd bits, UE 10-100 performs PIK-based authentication with the target BS 10-130, and Figures 17 to 2Detailed operation 10-300 is shown in Figure 1. During the authentication process between UE 10-100 and target BS 10-13, in operation 10-300, serving BS 10-120 and target BS 10-130 can perform direct communication, and serving BS 10-120 can transmit authentication messages to target BS 10-130.

[0217] UE 10-100 leaves its previous cell and performs synchronization 10-310 to access the new cell. Additionally, in operations 10-320 and 10-330, serving BS 10-120 sends received packets to target BS 10-130. Target BS 10-130 receives packets from serving BS 10-120. In operation 10-340, target BS 10-130 may send buffered packets received from serving BS 10-120 to AMF 10-140.

[0218] UE 10-100 performs synchronization (10-350) against target BS 10-130 and accesses the target BS via RACH. In operation (10-360), target BS 10-130 allocates a UL and responds via TA. UE 10-100 sends an RRC connection reconfiguration completion (10-370) and indicates that the handover is complete. Subsequently, in operation (10-380), UE 10-100 can receive packet data through the target BS. Target BS 10-130 performs a path change (10-390) in the network (MME, etc.) to notify UE 10-100 that the cell has changed. When a UE context release message is received from the network, serving BS 10-120 performs a UE context release (10-390).

[0219] Following PKI-based authentication, UE 10-100 and target BS 10-130 share the AS portion encryption key using the generated key.

[0220] Figure 11a and 11b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0221] According to Figure 11aDuring the handover, the serving BS 11-120 can determine the target BS 11-130 based on the measurement information sent by the UE 11-100 and its internal policy. It will then send the radio configuration information received from the target BS 11-130 to the UE 11-100 and connect the UE 11-100 to the target BS 11-130. The serving BS 11-120 recognizes that it belongs to a different AA than the target BS 11-130 and allows the generation of a key between the UE 11-100 and the target BS 11-130 via PKI-based authentication.

[0222] During the process of UE 11-100 transmitting a message for authentication with the target BS, the serving BS 11-120 can forward this message via AMF 11-140. The compute node (CN) refers to the base station, the BS, and the target to be authenticated; the detailed process is described below.

[0223] Serving BS 11-120 sends measurement control 11-210. The measurement information provided by Serving BS 11-120 is used to control the mobility of UE 11-100. Subsequently, data communication (packet data) 11-220 is performed according to regular communication. In measurement operation 11-230, UE 11-100 measures the radio signal strength of neighboring BS cells, and when the conditions of measurement control 11-210 are met, sends a measurement report 11-240 to Serving BS 11-120. Upon receiving measurement report 11-240, in operation 11-250, Serving BS 11-120 determines the handover of UE 11-100 and identifies whether Serving BS 11-120 belongs to the same AA as the target BS 11-130.

[0224] Serving BS 11-120 sends a handover request message 11-260 to target BS 11-130 to transmit information required for handover preparation via AMF 11-240. Target BS 11-130 performs admission control 11-270 to determine whether handover is permitted. During this process, target BS 11-130 configures the resources required to connect UE 11-100 to target BS 11-130. When HO preparation is complete, target BS 11-130 sends a handover request Ack (acknowledgment) 11-280, which includes the information required to connect UE 11-100 to target BS 11-130. The handover request Ack message includes radio connection reconfiguration message information received from the target BS 11-130, and the serving BS 11-120 sends an RRC connection reconfiguration message 11-290 to the UE 11-100. The RRC connection reconfiguration message 11-290 also includes the radio connection reconfiguration message information received from the target BS 11-130. In operation 11-290, the serving BS configures the inter-AA HO bit (or inter-AA HO information) in the RRC connection reconfiguration message 11-290 to notify the serving BS 11-120 that it and the target BS 11-130 belong to different AAs and require PKI authentication, and configures the PKI fwd bit to notify that authentication with the target BS 11-130 can be performed through the serving BS 11-120.

[0225] When UE 11-100 receives RRC connection reconfiguration message 11-290, which includes handover required parameters and inter-AA HO bits (or inter-AA HO information) / PKI fwd bits, UE 11-100 performs PIK-based authentication with the target BS 11-130, and Figures 17 to 2 Detailed operation 11-300 is shown in Figure 1.

[0226] During the authentication process between UE 11-100 and target BS 11-130, serving BS 11-120 and target BS 11-130 can perform direct communication, and in operation 11-300, serving BS 11-120 can transmit an authentication message to target BS 11-130. UE 11-100 leaves the previous cell and performs synchronization 11-310 to access the new cell. Furthermore, in operations 11-320 and 11-330, serving BS 11-120 sends received packets to the target BS. Target BS 11-130 receives packets from serving BS 11-120. UE 11-100 performs synchronization 11-350 with target BS 11-130 and accesses the target BS via RACH. In operation 11-360, target BS 11-130 assigns a UL and responds via TA. UE 11-100 sends an RRC connection reconfiguration completion message (11-370) and indicates that the handover is complete. Subsequently, in operation (11-380), UE 11-100 can receive packet data through the target BS 11-130. The target BS 11-130 performs a path change in the network (MME, etc.) (11-390) to notify UE 11-100 that it has been handed over. When a UE context release message is received from the network, the serving BS 11-120 performs a UE context release (11-400).

[0227] Following PKI-based authentication, UE 11-100 and target BS 11-130 share the AS portion encryption key using the generated key.

[0228] Figure 12a and 12b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0229] refer to Figure 12a The serving BS 12-120 can configure the UE 12-100 to allow it to authenticate with another BS. When the UE 12-100 receives a message from the serving BS allowing it to authenticate with another BS, it identifies the BS that needs to be authenticated based on the authentication area (AA) information sent by the BS.

[0230] UE 12-100 and AA differ in that the BS performing authentication is different from that of serving BS 12-120. Serving BS 12-120 can forward message transmissions used by UE 12-100 to authenticate the target BS 12-130. The compute node (CN) refers to the base station, BS, and the target to be authenticated; the detailed process is described below.

[0231] Serving BS 12-120 sends Measurement Control 12-210. Measurement information provided by Serving BS 12-120 is used to control the mobility of UE 12-100. Subsequently, data communication (packet data) 12-220 is performed according to regular communication. In Measurement Operation 12-230, UE 12-100 measures the radio signal strength of neighboring BS cells, and when Measurement Control 12-210 meets the conditions, sends a Measurement Report 12-235 to Serving BS 12-120.

[0232] In operation 12-240, serving BS 12-120 determines whether to allow UE 12-100 to perform authentication with another BS. In operation 12-245, serving BS 12-120 sets the bit in the RRC connection reconfiguration message to allow UE 12-100 to perform authentication with another BS, and sends the RRC connection reconfiguration message to UE 12-100. In operation 12-250, UE 12-100 receives AA information sent by the BS and identifies whether the BS belongs to a different AA than serving BS 12-120.

[0233] UE 12-100 and target BS 12-120 perform PKI-based authentication, and Figures 17 to 2 Detailed operation 12-255 is shown in Figure 1. During the authentication process between UE 12-100 and target BS 12-130, in operation 12-255, serving BS 12-120 and target BS 12-130 can perform direct communication, and serving BS 12-120 can transmit authentication messages to target BS 12-130.

[0234] UE 12-100 measures the radio signal strength of neighboring BS cells in measurement operation 12-260, and sends a measurement report 12-260 to serving BS 12-120 when measurement control 12-210 meets the conditions. Upon receiving measurement report 12-260, serving BS 12-120 determines the handover to UE 12-100 in operation 12-265 and identifies whether serving BS 12-120 belongs to the same AA as target BS 12-130.

[0235] Serving BS 12-120 may send a handover request message 12-270 to target BS 12-130 to transmit the information required for handover preparation. Target BS 12-130 performs admission control 12-280 to determine whether handover is permitted. During this process, target BS 12-130 configures the resources required to connect UE 12-100 to target BS 12-130. When HO preparation is complete, target BS 12-130 sends a handover request Ack (acknowledgment) 12-290, which includes the information required to connect UE 12-100 to target BS 12-130. The handover request Ack message includes radio connection reconfiguration message information received from the target BS 12-130, and the serving BS 12-120 sends an RRC connection reconfiguration message 12-300 to the UE 12-100, which includes radio connection reconfiguration message information received from the target BS 12-130.

[0236] In Operation 12-230, the serving BS 12-120 configures the inter-AA HO bit (or inter-AA HO information) in the RRC connection reconfiguration message 12-300 to notify the serving BS 12-120 and the target BS 12-130 that they belong to different AAs and require PKI authentication. It also configures the PKI fwd bit to notify the target BS 12-130 that authentication can be performed through the serving BS 12-120. When UE 12-100 receives the RRC connection reconfiguration message 12-200, which includes the handover required parameters and the inter-AA HO bit (or inter-AA HO information) / PKI fwd bit, UE 12-100 and the target BS 12-130 can perform PKI-based authentication. However, if authentication was performed beforehand in Operation 12-300, authentication is not required.

[0237] UE 12-100 leaves its previous cell and performs synchronization 12-310 to access the new cell. Additionally, in operations 12-320 and 12-330, serving BS 12-120 sends received packets to target BS 12-130. Target BS 12-130 receives packets from serving BS 12-120.

[0238] UE 12-100 performs synchronization (12-350) against target BS 12-130 and accesses the target BS via RACH. In operation (12-360), target BS 12-130 assigns a UL and responds via TA. UE 12-100 sends an RRC connection reconfiguration completion (12-370) and indicates that the handover is complete. Subsequently, in operation (12-380), UE 12-100 can receive packet data through target BS 12-130. Target BS 12-130 performs a path change (12-390) in the network (MME, etc.) to notify the UE that it has been handed over. When a UE context release message is received from the network, serving BS 12-120 performs a UE context release (12-400).

[0239] Following PKI-based authentication, UE 12-100 and target BS 12-130 share the AS portion encryption key using the generated key.

[0240] Figure 13a and 13b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0241] according to Figure 13a The serving BS 13-120 can configure UE 13-100 to allow it to authenticate with another BS. When UE 13-100 receives a message from the serving BS 13-120 allowing it to authenticate with another BS, it identifies the BS that needs authentication based on the Authentication Area (AA) information sent by the BS. UE 13-100 performs authentication with BSs whose AA is different from that of the serving BS 13-120. During the process of UE 13-100 transmitting a message for authenticating with the target BS 13-130, the serving BS 13-120 can forward this message via AMF 13-140. The compute node (CN) refers to the base station, the BS, and the target to be authenticated; the detailed process is described below.

[0242] Serving BS 13-120 sends Measurement Control 13-210. Measurement information provided by Serving BS 13-120 is used to control the mobility of UE 13-100. Subsequently, data communication (packet data) 13-220 is performed according to regular communication. In Measurement Operation 13-230, UE 13-100 measures the radio signal strength of neighboring BS cells, and when Measurement Control 13-210 meets the conditions, sends a Measurement Report 13-235 to Serving BS 13-120. In Operation 13-240, it is determined whether UE 13-100 is allowed to perform authentication with another BS. In Operation 13-245, Serving BS 13-120 sets the bit in the RRC Connection Reconfiguration message to allow UE 13-100 to perform authentication with another BS, and sends the RRC Connection Reconfiguration message to UE 13-100.

[0243] In operation 13-250, UE 13-100 receives AA information sent by the BS and identifies whether the BS belongs to a different AA than the serving BS. UE 13-100 performs PKI-based authentication with the target BS 13-130, and... Figures 17 to 2 Detailed operation 13-255 is shown in Figure 1.

[0244] During the process of UE 13-100 transmitting a message for authentication with target BS 13-130, in operation 13-255, serving BS 13-120 can forward this message via AMF 13-140. In measurement operation 13-260, UE 13-100 measures the radio signal strength of neighboring BS cells, and when measurement control 13-210 meets the conditions, sends a measurement report 13-260 to serving BS 13-120. Upon receiving measurement report 13-260, serving BS 13-120 determines the handover to UE 13-100 in operation 10-265 and identifies whether serving BS 13-120 belongs to the same AA as target BS 13-130.

[0245] Serving BS 13-120 may send a handover request message 13-270 to target BS 13-130 to transmit information required for handover preparation. Target BS 13-130 performs admission control 13-280 to determine whether handover is permitted. During this process, target BS 13-130 configures the resources required for UE 13-100 to connect to target BS 13-130. When HO preparation is complete, target BS 13-130 sends a handover request Ack (acknowledgment) 13-290, which includes the information required for UE 13-100 to connect to target BS 13-130. The handover request Ack message includes radio connection reconfiguration message information received from the target BS 13-130, and the serving BS 13-120 sends an RRC connection reconfiguration message 13-300 to the UE 13-100, which includes radio connection reconfiguration message information received from the target BS 13-130.

[0246] In RRC connection reconfiguration message 13-300, the serving BS configures the inter-AA HO bit (or inter-AA HO information) to notify the serving BS and the target BS that they belong to different AAs, thus requiring UE 13-100 to perform PKI authentication. It also configures the PKI fwd bit to notify the target BS 13-130 that authentication can be performed via the serving BS 13-120 (in operation 13-230). When UE 13-100 receives RRC connection reconfiguration message 13-200, which includes the handover required parameters and the inter-AA HO bit (or inter-AA HO information) / PKI fwd bit, UE 13-100 and the target BS 13-130 can perform PKI-based authentication. However, if authentication was performed beforehand in operation 13-300, it is not required to perform authentication. UE 13-100 leaves the previous cell and performs synchronization 13-310 to access the new cell. Furthermore, in operations 13-320 and 13-330, serving BS 13-120 sends the received packets to target BS 13-130. Target BS 13-130 receives packets from serving BS 13-120.

[0247] UE 13-100 performs synchronization with the target BS (13-350) and accesses the target BS via RACH. In operation 13-360, the target BS 13-130 assigns a UL and responds via TA. UE 13-100 sends an RRC connection reconfiguration completion message (13-370) and indicates that the handover is complete. Subsequently, in operation 13-380, UE 13-100 can receive packet data through the target BS. The target BS 13-130 performs a path change in the network (MME, etc.) (13-390) to notify the UE that it has been handed over. When a UE context release message is received from the network, the serving BS 13-120 performs a UE context release (13-400).

[0248] Following PKI-based authentication, UE 13-100 and target BS 13-130 share the AS portion encryption key using the generated key.

[0249] Figure 14a and 14b The authentication process during UE handover according to another embodiment of this disclosure is illustrated.

[0250] according to Figure 14a UE 14-100 identifies the BS requiring authentication based on the Authentication Area (AA) information sent by the BS. UE 14-100's AA differs from the BS performing authentication for the serving BS 14-120. The compute node (CN) refers to the base station, the BS, and the target to be authenticated; the detailed process is described below.

[0251] Serving BS 14-120 sends measurement control 14-210. The measurement information provided by Serving BS 14-120 is used to control the mobility of UE 14-100. Subsequently, data communication (packet data) 14-220 is performed according to regular communication. In measurement operation 14-230, UE 14-100 measures the radio signal strength of neighboring BS cells, and when the conditions of measurement control 14-210 are met, sends a measurement report 14-235 to Serving BS 14-120. In operation 14-240, UE 14-100 determines whether authentication with another BS is permitted. In operation 14-250, UE 14-100 receives AA information sent by a BS and identifies whether the BS belongs to a different AA than Serving BS 14-120.

[0252] UE 14-100 and target BS 14-130 perform PKI-based authentication, and Figures 17 to 2Detailed operation 14-255 is shown in Figure 1. During the process of UE 14-100 transmitting a message for authentication with target BS14-130, in operation 14-255, serving BS 14-120 can forward the message via AMF 14-140.

[0253] In measurement operation 14-260, UE 14-100 measures the radio signal strength of neighboring BS cells, and when measurement control 14-210 meets the conditions, it sends a measurement report 14-260 to serving BS 14-120. Upon receiving measurement report 14-260, serving BS 14-120 determines a handover for UE 14-100, and in operation 14-265 identifies whether serving BS 14-120 belongs to the same AA as target BS 14-130. Serving BS 14-120 may send a handover request message 14-270 to target BS 14-130 to transmit the information required for preparing for the handover. Target BS 14-130 performs admission control 14-280 to determine whether the handover is permitted. During this process, target BS 14-130 configures the resources required to connect UE 14-100 to target BS 14-130. When the HO (Hosting Organization) is ready, the target BS 14-130 sends a handover request Ack (acknowledgment) 14-290, which includes the information required for UE 14-100 to connect to the target BS 14-130. The handover request Ack message includes radio connection reconfiguration message information received from the target BS 14-130, and the serving BS 14-120 sends an RRC (Reconfiguration Control Code) connection reconfiguration message 14-300 to UE 14-100, which includes the radio connection reconfiguration message information received from the target BS 14-130.

[0254] In RRC connection reconfiguration message 14-300, serving BS 14-120 configures the inter-AA HO bit (or inter-AA HO information) to notify serving BS 14-120 and target BS 14-130 that they belong to different AAs, thus requiring UE 14-100 to perform PKI authentication. It also configures the PKI fwd bit to notify that authentication with target BS 14-130 can be performed through serving BS 14-120 (in operation 14-230). When UE 14-100 receives RRC connection reconfiguration message 14-200, which includes handover required parameters and the inter-AA HO bit (or inter-AA HO information) / PKI fwd bit, UE 14-100 and target BS 14-130 can perform PKI-based authentication; however, if authentication was performed beforehand in operation 14-300, authentication is not required.

[0255] UE 14-100 leaves its previous cell and performs synchronization 14-310 to access the new cell. Additionally, in operations 14-320 and 14-330, serving BS 14-120 sends received packets to target BS 14-130. Target BS 14-130 receives packets from serving BS 14-120. UE 14-100 performs synchronization 14-350 with target BS 14-130 and accesses target BS 14-130 via RACH. In operation 14-360, target BS 14-130 assigns a UL and responds via TA. UE 14-100 sends an RRC connection reconfiguration completion message 14-370 and indicates that the handover is complete. Subsequently, in operation 14-380, UE 14-100 can receive packet data through the target BS. The target BS 14-130 performs a path change 14-390 in the network (MME, etc.) to notify the UE 14-100 that the cell has been changed. When a UE context release message is received from the network, the serving BS 14-120 performs a UE context release 14-400.

[0256] Following PKI-based authentication, UE 14-100 and target BS 14-130 share the AS portion encryption key using the generated key.

[0257] Figure 15 The switching command process of a BS according to an embodiment of the present disclosure is shown.

[0258] refer to Figure 15 When the BS receives measurement report 15-110 from the UE, it identifies whether the handover conditions are met in operation 15-120. If the handover conditions are met in operation 15-120, the corresponding BS identifies whether the BS and the BS to be handed over belong to the same AA in operation 15-130. If the BS belongs to the same AA, in operation 15-140, the BS sets the intra-AA handover bit and sends a handover command to the UE. If the BS does not belong to the same AA, in operation 15-150, the BS sets the inter-AA handover bit (or inter-AA HO information) and sends a handover command.

[0259] Figure 16 The handover process of a UE according to an embodiment of this disclosure is illustrated.

[0260] refer to Figure 16In operation 16-110, the UE identifies whether it has received a handover command from the BS. When a handover command is received, the UE identifies the intra-AA handover bit (or intra-AA HO information) in operation 16-120. If the intra-AA handover bit (or intra-AA HO information) exists, an intra-AA handover is performed in operation 16-130. If the intra-AA handover bit (or intra-AA HO information) does not exist, or if the inter-AA handover bit (or inter-AA HO information) exists, an inter-AA handover, including a PKI-based authentication process, is performed in operation 16-140.

[0261] Figure 17 The present disclosure illustrates the process by which a UE performs public key infrastructure (PKI)-based authentication when it is configured to connect to a BS.

[0262] Figure 17 The process of mutual authentication between the UE and BS as described in this disclosure is illustrated.

[0263] exist Figure 17 In operation 17-30, UE 17-10 can first send an authentication request message including its own 6G identifier to RAN 17-15 to access RAN 17-15.

[0264] In operation 17-40, after receiving the authentication request message from UE 17-10, RAN 17-15 may send a message (Auth-Req) requesting EAP-TLS (TLS Initiated) authentication for RAN 17-15. In operation 17-40, RAN 17-15 may insert the 6G key set identifier (6G_KSI) corresponding to the appropriate authentication identifier and an anti-bidding down between architectures (ABBA) parameter to prevent security features from being downgraded from higher to lower versions into the authentication request message (Auth-Req), and then send the authentication request message.

[0265] When UE 17-10 receives TLS initiation information from RAN 17-15, in operation 17-50, UE 17-10 may send an authentication response message (Auth-Resp) to RAN 17-15, including TLS client_hello information. The TLS client_hello information can be a random value (or a client seed value) to prevent eavesdropping by unauthorized personnel.

[0266] When RAN 17-15 receives TLS client_hello information included in the authentication response message (Auth-Resp) from UE 17-10, in operation 17-60, RAN 17-15 may send an authentication request message (Auth-Req) to UE 17-10, including TLS RAN_hello, TLS certificate (RAN certificate), TLS RAN_key_exchange (temporary session key), TLS certificate_request (whether to request UE certificate), TLS RAN_hello_done information, and at least one of 6G KSI and ABBA. The TLSRAN_hello information may include a random value (or RAN seed value) to prevent eavesdropping by unauthorized personnel. The TLSRAN_key_exchange information may include a temporary session key (PreMasterSecret) to prevent man-in-the-middle (MITM) attacks.

[0267] At this point, unless an emergency TLC call is used, RAN 17-15 can set the certificate_request and verify the UE certificate. In Operation 17-70, UE 17-10 can identify the RAN certificate (TLS certificate) included in the authentication request message (Auth-Req) of RAN 17-15 and perform authentication to determine if the RAN certificate (TLS certificate) is valid. UE 17-10 can identify the expiration date of the RAN certificate (TLS certificate), check its validity, and recognize its content. UE 17-10 can check the RAN certificate (TLS certificate) by examining for cancellation of certificate issuance, illegal certificate issuance, certificate errors, key leaks, etc.

[0268] Please refer to the following attached diagram for a detailed description of the UE 17-10 RAN certificate certification process.

[0269] After verifying that the certificate of RAN 17-15 is correct, in operation 17-80, in response to the verification, UE 17-10 may send an authentication response message (Auth-Resp) to the RAN, including at least one of the following: TLS certificate (UE certificate), TLS client_key_exchange (temporary session key), TLScertificate_verify, TLS change_cipher_spec (available cipher specification information), and TLS end information. The TLS client_key_exchange information may include a temporary session key (PreMasterSecret) used to prevent man-in-the-middle (MITM).

[0270] According to the implementation method, UE 17-10 can encrypt the temporary session key (TLS client_key_exchange) using the RAN public key and send the session key to RAN 17-15.

[0271] Upon receiving the certificate from UE 17-10, RAN 17-15 verifies the certificate in Operation 17-90. RAN 17-15 can identify the expiration date of the RAN certificate (TLS certificate), check the validity of the UE certificate (TLS certificate), and identify the content of the UE certificate (TLS certificate). RAN 17-15 can verify the validity of the UE certificate (TLS certificate) by checking for cancellation of certificate issuance, illegal certificate issuance, certificate errors, key leaks, etc.

[0272] RAN 17-15 can recognize the certificate of UE 17-10, select a suitable cipher specification from the cipher specifications sent by UE 17-10, specify the same cipher specification in TLS change_cipher_spec, and send an authentication request message (Auth-Req) including TLS completion information to UE 17-10 in operation 17-100. In operation 17-100, the authentication request message (Auth-Req) may include 6G KSI and ABBA information.

[0273] In Operation 17-110, UE 17-10 may send an Authentication Response Message (Auth-Resp) as a response to an Authentication Request Message (Auth-Req) to RAN 17-15. RAN 17-15 may use the highest valid 256 (128) bits of the EMSK generated at this time as the session key (gNB key). A pseudo-random function (PRF) may be used when generating the EMSK; for example, a hash-based RFC4306 may be generated using parameters including a first random value, a second random value, and a temporary session key (PreMasterSecret). The Authentication Response Message (Auth-Resp) may include an EAP response and an EAP type (EAP-TLS).

[0274] In operation 17-120, RAN 17-15 can send an EAP success message to UE 17-10. The EAP success message indicates that authentication with UE 17-10 is successful (EAP successful), includes the 6G-KSI and ABBA parameters, and introduces the gNB key. Upon receiving the EAP success message, as with RAN 17-15, UE 17-10 can use the highest valid 256 (128) bits in the EMSK as the session key (gNB key).

[0275] In other words, UE 17-10 can generate a session key using a temporary session key (TLS client_key_exchange) and the information required for authentication. A pseudo-random function (PRF) can be used when generating the EMSK; for example, a hash-based RFC4306 can be generated using parameters including a first random value, a second random value, and the temporary session key (PreMasterSecret). RAN 17-15 can also generate a session key using a temporary session key (TLS client_key_exchange) and the information required for authentication. Depending on the implementation, after generating the session key, RAN 17-15 and UE 17-10 can discuss encryption algorithms.

[0276] Figure 18a and Figure 18b The present disclosure illustrates a process for identifying the validity of a certificate when the UE performs PKI-based authentication with the RAN, according to an embodiment of the present disclosure.

[0277] exist Figure 18a and Figure 18b The illustrated implementation describes the process of downloading the Credential Revocation List (CRL) during the mutual authentication process and identifying whether the CRL includes the corresponding RAN certificate (or the corresponding UE's certificate). At this point, since UE 18-10 cannot perform communication and therefore cannot request the CRL from a network entity (e.g., a Certification Authority (CA) server), a process is required for RAN 18-15 to forward (or allow) UE 18-10's CRL request message to the network.

[0278] In operation 18-30, UE 18-10 can first send an authentication request message including its own 6G identifier to RAN 18-15 to access RAN 18-15. After receiving the authentication request message from UE 18-10, in operation 18-40, RAN 18-15 can send a message (Auth-Req) to UE 18-10 requesting EAP-TLS authentication (TLS initiation) for RAN 18-15. In operation 18-40, RAN 18-15 can insert the 6G key set identifier (6G_KSI) corresponding to the corresponding authentication identifier and the inter-architecture anti-dimensionality reduction (ABBA) parameter used to prevent security features from being downgraded from higher versions to lower versions into the authentication request message (Auth-Req), and then send the authentication request message.

[0279] When UE 18-10 receives TLS initiation information from RAN 18-15, it can send an authentication response message (Auth-Resp) including TLS client_hello information to RAN 18-15 in operation 18-50.

[0280] When RAN 18-15 receives TLS client_hello information included in the authentication response message (Auth-Resp) from UE 18-10, it may send an authentication request message (Auth-Req) to UE in operation 18-60, including at least one of the following: TLS RAN_hello, TLS certificate (RAN certificate), TLSRAN_key_exchange, TLS certificate_request (whether to request UE certificate), TLS RAN_hello_done information, 6G KSI and ABBA parameters.

[0281] At this point, unless an emergency TLS call is used, RAN 18-15 can set a certificate_request and verify the UE certificate. UE 18-10 should verify the RAN certificate included in the authentication request message of RAN 18-15. Even if the RAN certificate is legally signed by the CA, UE 18-10 needs additional confirmation because the RAN certificate may be revoked later.

[0282] Therefore, UE 18-10 should receive a Credential Revocation List (CRL) from the CA that includes the RAN certificate content or from a server designated by the CA for certificate verification that records whether the RAN certificate has been revoked.

[0283] In order to transmit a CRL request message (CRL-req) to Unified Data Management (UDM) 18-30 to receive a CRL for a RAN certificate, during Operation 18-70, UE 18-10 may send a CRL request message (CRL-req (TLS Certificate Revocation List Download Request)) to RAN 18-15.

[0284] Upon receiving a CRL request message (CRL-req), RAN 18-15 should generally reject UE 18-10's NAS communication since UE 18-10 is not yet authenticated. However, RAN 18-15 may exceptionally allow the transmission of the CRL request message (CRL-req). In Operation 18-80, RAN 18-15 may forward the corresponding CRL request message (CRL-req (TLS Certificate Revocation List Download Request)) to the network entity (NE) acting as the RAN Certificate CA, i.e., UDM 18-20 here. During this process, UE 18-10 may determine whether to forward the corresponding CRL request message (CRL-req) to a server acting as the CA known to RAN 18-15 based on messages included in the packet (such as the UE's IP or current information).

[0285] In Operation 18-90, UDM 18-20 can recognize the CRL request message (CRL-Req) received from UE 18-10 and send a CRL response message (CRL-Resp (TLS Certificate Revocation List)) including CRL information to RAN 18-15 to send the CRL information requested by UE 18-10. In Operation 18-100, RAN 18-15 can forward the CRL response message (CRL-Resp (TLS Certificate Revocation List)) including CRL information to UE 18-10.

[0286] In Operation 18-110, UE 18-10 can identify the RAN certificate included in the authentication request message of RAN 18-15 and determine whether the RAN certificate is a valid certificate.

[0287] After verifying that RAN 18-15's certificate is correct, in response to the verification in Operation 18-120, UE 18-10 may send an authentication response message (Auth-Resp) to RAN, including at least one of the following: TLS certificate (UE certificate), TLS client_key_exchange, TLS certificate_verify, TLSchange_cipher_spec (available cipher specification information), and TLS end information. Upon receiving UE 18-10's certificate, RAN 18-15 may verify UE 18-10's certificate in Operation 18-130.

[0288] According to the implementation, the process of receiving the Credential Revocation List (CRL) of the UE certificate from UDM 18-20 can be performed between operations 18-120 and operations 18-130.

[0289] To receive the CRL of the UE certificate, RAN 18-15 can send a CRL request message (CRL-req) for the UE certificate to the network entity (NE) acting as the CA for the UE certificate, i.e., UDM 18-20 in this case. UDM 18-20 can then send a CRL response message (CRL-Resp) to RAN 18-15, which includes the CRL information of the UE certificate. Afterward, RAN 18-15 can identify the CRL information of the UE certificate and determine whether the UE certificate has been revoked.

[0290] RAN 18-15 can recognize the certificate of UE 18-10, select a suitable cipher specification from the cipher specifications sent by UE 18-10, specify the same cipher specification in TLS change_cipher_spec, and send an authentication request message (Auth-Req) including TLS completion information to UE 18-10 in operation 18-140. The authentication request message may also include 6G KSI and ABBA information.

[0291] In Operation 5-150, UE 18-10 may send an empty authentication response message (Auth-Resp) to RAN 18-15 as a response to the authentication request message. RAN 18-15 uses the most valid 256 (128) bits of the EMSK generated at this time as the gNB key. RAN 18-15 may send an EAP success message in Operation 18-160, indicating that authentication with UE 18-10 was successful (EAP successful) and introducing the gNB key. Upon receiving EAP success, as with RAN 18-15, UE 18-10 may use the most valid 256 (128) bits of the EMSK as the gNB key.

[0292] Figure 19a and 19b This invention illustrates a process for identifying the validity of a certificate when the UE performs PKI-based authentication with the RAN, according to another embodiment of the present disclosure.

[0293] exist Figure 19a and 19b In the illustrated implementation, the revocation of the corresponding certificate (RAN certificate or UE certificate) can be identified via the Online Certificate Status Protocol (OCSP) during the mutual authentication process. At this time, since UE 19-10 cannot perform communication and therefore cannot request OCSP from the CA, RAN 19-15 can perform the process of allowing UE 19-10 to communicate with an OSCP request message (OSCP-Req).

[0294] In operation 19-30, UE 19-10 can first send an authentication request message including its own 6G identifier to RAN 19-15 to access RAN 19-15. After receiving the authentication request message from UE 19-10, RAN 19-15 can send a message (Auth-Req) to UE 5-10 in operation 19-40 requesting EAP-TLS authentication (TLS initiation) to RAN 19-15.

[0295] In operation 19-40, RAN 19-15 may insert the 6G key set identifier (6G_KSI) corresponding to the identifier of the corresponding authentication and the inter-architecture anti-dimensionality reduction (ABBA) parameter used to prevent security features from being downgraded from higher versions to lower versions into the authentication request message (Auth-Req).

[0296] When UE 19-10 receives TLS initiation information from RAN 19-15, it can send an authentication response message (Auth-Resp) including TLS client_hello information to RAN 19-15 in operation 19-50.

[0297] When RAN 19-15 receives a TLS RAN_hello message included in the authentication response message (Auth-Resp) from UE 19-10, in operation 19-60, RAN 19-15 may send an authentication request message (Auth-Req) to UE 19-10, including at least one of the following: TLS certificate (RAN certificate), TLS RAN_key_exchange, TLS certificate_request (whether to request the UE certificate), TLS RAN_hello_done information, 6GKSI, and ABBA parameters. At this time, unless a TLC emergency call is used, RAN 19-15 may set the certificate_request and verify the UE certificate.

[0298] UE 19-10 should verify the RAN certificate included in the authentication request message of RAN 19-15. Even if the RAN certificate is legally signed by the CA, it may be revoked later, thus requiring UE 19-10 to confirm the revocation of the RAN certificate. UE 19-10 may send a response request to the Online Certificate Status Protocol (OCSP), a protocol used to identify in real time whether the corresponding RAN certificate in the CA included in the certificate content or in a pre-defined server designated by the CA for certificate verification has been revoked.

[0299] In order to identify in real time whether the corresponding RAN certificate has been revoked by UDM 19-20, UE 19-10 can send an OSCP request message (OSCP-req (TLS certificate status request)) to RAN 19-15 during operation 19-70.

[0300] When an OSCP request message (OSCP-req) is received from UE 19-10, RAN 19-15 should generally reject NAS communication from UE 19-10 since UE 19-10 has not yet been authenticated. However, since the OSCP request message does not correspond to regular data transmission, RAN 19-15 may exceptionally allow the transmission.

[0301] In operation 19-80, RAN 19-15 may forward the corresponding OSCP request message (O-req (TLS certificate status request)) to the NE acting as the RAN certificate CA, i.e., UDM 19-20 here. During this process, UE 19-10 may determine, based on messages included in the packet (such as the UE's IP or current information), whether to forward the corresponding OSCP request message to a server known to RAN 19-15 as the CA.

[0302] In operation 19-90, UDM 19-20 can recognize the OSCP request message received from UE 19-10 and send an OSCP response message (OSCP-Resp) to RAN 19-15, which includes the RAN certificate status information (TLS certificate status response) requested by UE 19-10. In operation 19-100, RAN 19-15 can retransmit the corresponding OSCP response message (OSCP-Resp (TLS certificate status response)) to UE 19-10.

[0303] In Operation 19-110, UE 19-10 identifies the RAN certificate included in the authentication request message of RAN 19-15 and determines whether the RAN certificate is a valid certificate.

[0304] After verifying that the certificate of RAN 19-15 is correct, in operation 19-120, UE 19-10 may send an authentication response message (Auth-Resp) to RAN 19-15. This message includes at least one of the following: TLS certificate (UE certificate), TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec (available cipher specification information), and TLS end information.

[0305] According to the implementation method, between operations 19-120 and 19-130, the process of identifying whether a UE certificate has been revoked can be performed through the Online Certificate Status Protocol (OCSP) for the UE certificate.

[0306] To identify in real time whether a UE certificate has been revoked by UDM 19-20, RAN 19-15 can send an OSCP request message (TLS certificate status request) for the UE certificate to the NE acting as the RAN certificate CA, i.e., UDM 19-20 in this case. UDM 19-20 can then send an OSCP response message to RAN 19-15 containing the UE certificate status information (TLS certificate status response) requested by RAN 19-15. Subsequently, RAN 19-15 can identify whether the corresponding UE certificate has been revoked based on the UE certificate status information (TLS certificate status response).

[0307] In operation 19-130, RAN 19-15 receives and recognizes the certificate of UE 19-10. RAN 19-15 recognizes the certificate of UE 19-10, selects a suitable cipher specification from the cipher specifications sent by UE 19-10, specifies the same cipher specification in TLS change_cipher_spec, and sends an authentication request message (Auth-Req) including TLS completion information to UE 19-10 in operation 19-140. In operation 19-140, the authentication response message may include 6G KSI and ABBA information. In operation 19-150, UE 19-10 may send an empty Auth-Resp message to RAN as its response message. RAN 19-15 uses the highest valid 256 (128) bits of the EMSK generated at this time as the gNB key.

[0308] In operation 19-160, RAN 19-15 may send an EAP success message to UE 19-10. The EAP success message indicates that authentication with UE 19-10 was successful (EAP successful) and introduces the gNB key. Upon receiving the EAP success message, as with RAN 19-15, UE 19-10 may use the highest valid 256 (128) bits in the EMSK as the gNB key.

[0309] Figure 20a and Figure 20b The process of identifying certificate validity when the UE performs PKI-based authentication with the RAN, according to another embodiment of this disclosure, is illustrated.

[0310] exist Figure 20a and Figure 20b The illustrated implementation describes the process of downloading the Credential Revocation List (CRL) during the mutual authentication process and identifying whether the CRL includes the corresponding RAN certificate. At this point, since UE 20-10 cannot perform communication and therefore cannot request the CRL from a network entity (e.g., a Certification Authority (CA) server), RAN 20-15 is required to forward UE 5-10's CRL request message to the network (or allow UE 5-10's CRL request message to enter the network).

[0311] exist Figure 20a and Figure 20b In the implementation shown, after temporary mutual authentication between UE 20-10 and RAN 20-15, UE 20-10 and UDM 20-20 directly send and receive CRL request / response messages in operations 20-140 and 20-150.

[0312] During operation 20-30, UE 20-10 can first send an authentication request message including its own 6G identifier to RAN 20-15 to access RAN 20-15.

[0313] After receiving the authentication request message from UE 20-10, RAN 20-15 may send a message (Auth-Req) to UE 20-10 in operation 20-40 requesting EAP-TLS authentication (TLS initiation) of RAN 20-15.

[0314] In operation 20-40, RAN 20-15 may insert the 6G key set identifier (6G_KSI) corresponding to the corresponding authentication identifier and the inter-architecture anti-dimensionality reduction (ABBA) parameter used to prevent security features from being downgraded from a higher version to a lower version into the authentication request message (Auth-Req), and send the authentication request message to UE 20-10.

[0315] When UE 20-10 receives TLS initiation information from RAN 20-15, it can send an authentication response message (Auth-Resp) including TLS client_hello information to RAN 20-15 during operation 20-50.

[0316] When RAN 20-15 receives TLS client_hello information included in the authentication response message (Auth-Resp) from UE 20-10, in operation 20-60, RAN 20-15 may send an authentication request message (Auth-Req) to UE 20-10 including at least one of the following: TLS RAN_hello, TLS certificate (RAN certificate), TLS RAN_key_exchange, TLS certificate_request (whether to request UE certificate), TLS RAN_hello_done information, 6G KSI, and ABBA parameters.

[0317] At this point, unless a TLC emergency call is used, RAN 20-15 can set a certificate_request and verify the UE certificate. UE 20-10 should verify the RAN certificate included in the authentication request message of RAN 20-15. Even if the RAN certificate is legally signed by the CA, it may be revoked later, therefore confirmation from UE 20-10 is required.

[0318] Therefore, UE 20-10 should receive a Credential Revocation List (CRL) from the CA, which includes the RAN certificate content, or from a server designated by the CA for certificate verification, which records whether the RAN certificate has been revoked. However, since UE 20-10 has not yet been authenticated, it cannot perform AS and NAS communication.

[0319] In operation 20-70, UE 20-10 may temporarily perform authentication using only the RAN certificate without verifying whether the certificate has been revoked. After confirming that the RAN certificate is valid, in operation 20-80, UE 20-10 may, in response to the confirmation, send an authentication response message to RAN 20-15 including at least one of the following: TLS certificate (UE certificate), TLS client_key_exchange, TLS certificate_verify, TLSchange_cipher_spec (available cipher specification information), and TLS end information.

[0320] In operation 20-90, RAN 20-15 receives and recognizes the certificate of UE 20-10. RAN 20-15 recognizes the certificate of UE 20-10, selects a suitable cipher specification from the cipher specifications sent by UE 20-10, specifies the same cipher specification in TLSchange_cipher_spec, and sends an authentication request message including TLS completion information in operation 20-100. In operation 20-100, the authentication request message may also include 6G KSI and ABBA information. In operation 20-110, UE 20-10 may send an empty Auth-Resp message to RAN 20-15 as its response message. RAN 20-15 uses the highest valid 256 (128) bits of the EMSK generated at this time as the gNB key. In operation 20-120, RAN 20-15 can send an EAP success message to UE 20-10. The EAP success message indicates that authentication with UE 20-10 is successful (EAP successful) and introduces the gNB key. Upon receiving the EAP success message, as with RAN 20-15, UE 20-10 can use the highest valid 256 (128) bits in the EMSK as the gNB key.

[0321] For future NAS communication, in Operation 20-130, UE 20-10 can perform authentication between the core network and the UE.

[0322] UE 20-10 can verify whether the temporarily certified RAN certificate has been revoked after NAS communication. In operation 20-140, UE 20-10 can send a CRL request message ((CRL-req)) for the RAN certificate to UEM 20-20. In operation 20-160, UDM20-20 can recognize the CRL request message ((CRL-req)) received from UE 20-10 and send the CRL information of the requested RAN certificate to UE 20-10.

[0323] Subsequently, in Operation 20-160, UE 20-10 can identify whether a RAN certificate exists in the CRL and is included in the authentication request message of RAN 20-15, and identify whether the RAN certificate is a valid certificate.

[0324] According to the implementation method, RAN 20-15 may send a CRL request message ((CRL-req)) for a UE certificate to UEM 20-20. UDM 20-20 may recognize the CRL request message (CRL-Req) for a UE certificate and send the CRL information of the UE certificate requested by RAN 20-15 to RAN 20-15.

[0325] Figure 21a and 21b The process of identifying certificate validity when the UE performs PKI-based authentication with the RAN, according to another embodiment of this disclosure, is illustrated.

[0326] exist Figure 21a and 21b In this implementation, during the mutual authentication process, UE 21-10 needs to identify whether the corresponding RAN 21-15 certificate has been revoked via the Online Certificate Status Protocol (OCSP). However, since UE 21-10 cannot perform communication and therefore cannot request OCSP from the CA, UE 21-10 can only temporarily identify the RAN certificate and verify whether the RAN certificate has been revoked after the NAS authentication is completed in the future.

[0327] exist Figure 21a and 21b In the implementation shown, after UE 21-10 and UDM 21-20 perform temporary mutual authentication between UE 21-10 and RAN 21-15, OSCP request / response messages are directly sent and received in operations 21-140 and 21-150.

[0328] In operation 21-30, UE 21-10 can first send an authentication request message including its own 6G identifier to RAN 21-15 to access RAN 21-15.

[0329] After receiving the authentication request message from UE 21-10, RAN 21-15 can send a message (Auth-Req) to UE 21-10 in operation 21-40 requesting EAP-TLS authentication (TLS initiation) for RAN 21-15. In operation 21-40, RAN 21-15 can insert the 6G key set identifier (6G_KSI) corresponding to the corresponding authentication identifier and the inter-architecture anti-dimensionality reduction (ABBA) parameter used to prevent security features from being downgraded from higher to lower versions into the authentication request message (Auth-Req), and send the authentication request message to UE 21-10.

[0330] When UE 21-10 receives TLS initiation information from RAN 21-15, in operation 21-50, UE 21-10 may send an authentication response message (Auth-Resp) including TLS client_hello information to RAN 21-15.

[0331] When RAN 21-15 receives TLS client_hello information (Auth-Resp) included in the authentication response message from UE 21-10, in operation 21-60, RAN 21-15 may send an authentication request message (Auth-Req) to UE 21-10 including at least one of the following: TLS RAN_hello, TLS certificate (RAN certificate), TLS RAN_key_exchange, TLS certificate_request (whether to request UE certificate), TLS RAN_hello_done information, 6G KSI, and ABBA parameters.

[0332] At this point, unless an emergency TLC call is used, RAN 21-15 can set a certificate_request and verify the UE certificate. UE 21-10 should verify the RAN certificate included in the authentication request message of RAN 21-15.

[0333] Even if a RAN certificate is legally signed by a CA, it may be revoked later. Therefore, UE 21-10 needs to confirm the revocation of a RAN certificate. Thus, UE 21-10 should receive an OSCP indicating whether the corresponding RAN certificate has been revoked in real time from the CA included in the certificate content or from a server designated by the CA for certificate verification.

[0334] However, since UE 21-10 has not been authenticated and therefore cannot perform AS and NAS communication, in Operation 21-70, UE 21-10 can temporarily perform authentication using only the RAN certificate without verifying whether the certificate has been revoked.

[0335] After verifying that the certificate of RAN 21-15 is correct, in operation 21-80, UE 21-10 may, in response to the verification, send an authentication response message to RAN 21-15 including at least one of the following: TLS certificate (UE certificate), TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec (available cipher specification information), and TLS end information.

[0336] In operation 21-90, RAN 21-15 receives and recognizes the certificate of UE 21-10. RAN 21-15 recognizes the UE's certificate, selects a suitable cipher specification from the cipher specifications sent by UE 21-10, specifies the same cipher specification in TLS change_cipher_spec, and sends an authentication request message (Auth-Req) including TLS completion information to UE 21-10 in operation 20-100. In operation 21-100, the authentication response message may include 6G KSI and ABBA information.

[0337] In operation 21-110, UE 21-10 may send an empty Auth-Resp message to RAN 21-15 as a response message. RAN 21-15 uses the highest valid 256 (128) bits of the EMSK generated at this time as the gNB key.

[0338] In operation 21-120, RAN 21-15 can send an EAP success message to UE 21-10, indicating that authentication with UE 21-10 is successful and the gNB key has been introduced. Upon receiving EAP success, as with RAN 21-15, UE 21-10 can use the highest valid 256 (128) bits in the EMSK as the gNB key.

[0339] For future NAS communication, in operation 21-130, UE 21-10 can perform authentication between the core network and the UE. UE 21-10 can verify whether the temporary authentication certificate has been revoked after NAS communication. To this end, in operation 21-140, UE 21-10 can send an OSCP request message (OCSP-req) to UDM 21-20. In operation 21-150, UDM 21-20 can recognize the OSCP request message (OCSP-Req) received from UE 21-10 and send an OSCP response message (OCSP-Resp) containing the OCSP information requested by UE 21-10 to UE 21-10.

[0340] In Operation 21-160, UE 21-10 identifies whether RAN 21-15's certificate has been revoked based on the OSCP response message, and identifies whether the RAN certificate is a valid certificate.

[0341] According to the implementation method, RAN 21-15 may send an OSCP request message (OSCP-req) for a UE certificate to UEM 21-20. UDM 21-20 may recognize the OSCP request message (OSCP-Req) for the UE certificate and send the OSCP information of the UE certificate requested by RAN 21-15 to RAN 21-15.

[0342] Figure 22 This is a block diagram illustrating a UE device and a RAN device according to embodiments of the present disclosure.

[0343] according to Figure 22 UE 22-100 includes transceiver 22-110, controller 22-120, and storage unit 22-130. However, the components of UE 22-100 are not limited to the examples described above, and UE 22-100 may include, for example, more or fewer components than those shown. Furthermore, transceiver 22-110, storage unit 22-130, and controller 22-120 may be implemented as a single chip.

[0344] Transceiver 22-110 can transmit and receive signals to and from RAN 22-140. Signals may include control information and data. For this purpose, transceiver 22-110 may include an RF transmitter for up-conversion and amplification of the transmitted signal, and an RF receiver for low-noise amplification and down-conversion of the received signal. However, this is only one implementation of transceiver 22-110, and the components of transceiver 22-110 are not limited to RF transmitters and RF receivers. Furthermore, transceiver 22-110 can receive signals via a radio channel, output signals to controller 22-120, and transmit signals output from controller 22-120 via a radio channel. Additionally, transceiver 22-110 may include an RF transceiver for a first radio communication technology and an RF transceiver for a second radio communication technology, wherein one transceiver can perform physical layer processing according to the first and second radio communication technologies.

[0345] Storage unit 22-130 can store programs and data required for the operation of UE 22-100. Furthermore, storage unit 22-130 can store control information or data included in signals transmitted and received by UE 22-100. Storage unit 22-130 can be configured using storage media such as ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media. There can be multiple storage units 22-130.

[0346] Controller 22-120 can control a series of processes to allow UE 22-100 to operate according to embodiments of this disclosure. For example, controller 22-120 can calculate and determine information received from RAN 22-140 via transceiver 22-110. There can be multiple controllers 22-120, and controller 22-120 can perform operations controlling UE 22-100 components by executing programs stored in storage unit 22-130.

[0347] RAN 22-140 includes transceiver 22-150, controller 22-160, connector 22-170, and storage unit 22-180. However, the components of RAN 22-140 are not limited to the examples described above, and RAN 22-150 may include, for example, more or fewer components than those shown. Furthermore, transceiver 22-150, storage unit 22-180, and controller 22-160 may be implemented as a single chip.

[0348] Transceiver 22-150 can transmit signals to and receive signals from UE 22-100. Signals may include control information and data. For this purpose, transceiver 22-150 may include an RF transmitter for up-conversion and amplification of the transmitted signals, and an RF receiver for low-noise amplification and down-conversion of the received signals. However, this is only one implementation of transceiver 22-150, and the components of transceiver 22-150 are not limited to RF transmitters and RF receivers. Furthermore, transceiver 22-150 can receive signals via a radio channel, output signals to controller 22-160, and transmit signals output from controller 22-160 via a radio channel.

[0349] Controller 22-160 can control a series of processes to allow RAN 22-140 to operate according to embodiments of this disclosure. For example, controller 22-160 can generate information to be sent to UE 22-100 and send it to UE 22-100 via transceiver 22-150. There can be multiple controllers 22-160, and controllers 22-160 can perform operations controlling RAN 22-140 elements by executing programs stored in storage unit 22-180.

[0350] Storage units 22-180 can store programs and data required for RAN operation. Furthermore, storage units 22-180 can store control information and data included in signals transmitted and received by the RAN. Storage units 22-180 can be configured using storage media such as ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media. The number of storage units 22-140 can be multiple.

[0351] Connector 22-170 is a device for connecting RAN 22-140 and the core network, and can perform operations for sending messages to the physical layer for processing to send and receive messages from the core network.

[0352] The methods according to the various embodiments described in the claims or in this disclosure may be implemented by hardware, software, or a combination of hardware and software.

[0353] When the method is implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium may be configured to be executed by one or more processors within an electronic device. At least one program may include instructions that cause the electronic device to perform the method as defined in the appended claims and / or as disclosed herein, according to various embodiments of this disclosure.

[0354] The program (software module or software) may be stored in non-volatile memory including random access memory and flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), disk storage devices, optical disc ROM (CD-ROM), digital versatile disc (DVD), or other types of optical storage devices, or magnetic tape cassettes. Alternatively, any combination of some or all of these memories may form a memory storing the program. Furthermore, multiple such memories may be included in an electronic device.

[0355] Furthermore, the program can be stored in an attachable storage device that can access the electronic device via a communication network such as the Internet, intranet, local area network (LAN), wide area network (WLAN), and storage area network (SAN), or a combination thereof. This storage device can be accessed via an external port. Additionally, a separate storage device on the communication network can access portable electronic devices.

[0356] In the detailed embodiments described above, elements included in this disclosure are represented in a singular or plural form according to the presented embodiments. However, for the sake of convenience, the singular or plural form has been suitably chosen as presented, and this disclosure is not limited to elements represented in a singular or plural form. Thus, an element represented in a plural form may also include a single element, or an element represented in a singular form may include multiple elements.

[0357] Although specific embodiments have been described in detail in this disclosure, it will be apparent that various modifications and changes can be made thereto without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined by the appended claims and their equivalents.

Claims

1. A method of operating a serving base station (BS) for inter-authentication of an access stratum (AS) part in case of performing handover in a wireless communication system, the method comprising: receiving a measurement report from a user equipment (UE); identifying whether the UE satisfies a handover condition based on the measurement report; in case that the UE satisfies the handover condition, identifying whether a target BS to which the UE is connected for handover and the serving BS belong to a same authentication area (AA); in case that the target BS and the serving BS do not belong to the same AA, transmitting a handover command including inter- AA handover information; and in case that a public key infrastructure (PKI) based inter-authentication between the UE and the target BS is completed, transmitting a PKI based authentication packet to the target BS. 2.The method of claim 1, further comprising: in case that the target BS and the serving BS belong to the same AA, transmitting a handover command including intra- AA handover information. in case that the intra- AA handover information is transmitted, not performing the PKI based inter-authentication between the UE and the target BS, and performing a key update procedure by the UE for the target BS, and 3. The method of claim 2, wherein, in case that the inter- AA handover information is transmitted, performing the PKI based inter-authentication between the UE and the target BS. The AA is a group of cells served by physically or logically same computing nodes.

4. The method of claim 1, wherein, The same computing nodes are logically or physically equivalent computing nodes, 5. The method of claim 4, wherein, The logically same computing nodes are implemented as same operator's software, software with same rights, or software performing same procedures, and The physically same computing nodes are implemented as same operator's hardware, hardware with same rights, or same hardware components. In case that the inter- AA handover information is transmitted, the UE and the serving BS are detached from each other, and then the PKI based inter-authentication is performed between the UE and the target BS.

6. The method of claim 3, wherein, 7.The method of claim 3, wherein, the serving BS transmits a PKI based authentication packet to a network entity, and the network entity transmits the PKI based authentication packet to the target BS. 8.A method of operating a user equipment (UE) for inter-authentication of an access stratum (AS) part in case of performing handover in a wireless communication system, the method comprising: in case that a target base station (BS) of the UE and a serving BS of the UE do not belong to a same authentication area (AA), receiving a handover command including inter- AA handover information from the serving BS; and based on the handover command, performing a public key infrastructure (PKI) based inter-authentication with the target BS. 9.The method of claim 8, further comprising: in case that the target BS and the serving BS belong to the same AA, receiving a handover command including intra- AA handover information from the serving BS. ​ ​ 10. The method of claim 9, wherein, In case the intra-AA handover information is received, the PKI based mutual authentication is not performed between the UE and the target BS, and a key update procedure is performed by the UE for the target BS.

11. The method of claim 8, wherein, The AA is a set of cells served by physically or logically identical computing nodes.

12. The method of claim 10, wherein, In case the inter-AA handover information is received, the UE detaches from the serving BS and then performs the PKI based mutual authentication with the target BS. 13.A serving base station (BS) supporting mutual authentication of an access stratum (AS) part in case of performing handover in a wireless communication system, the BS comprising: a transceiver; and a controller connected to the transceiver and configured to control the transceiver and perform control to perform operations of the method according to any one of claims 1 to 7. 14.A user equipment (UE) for mutual authentication of an access stratum (AS) part in case of performing handover in a wireless communication system, the UE comprising: a transceiver; and a controller connected to the transceiver and configured to control the transceiver and perform control to perform operations of the method according to any one of claims 8 to 12.

Images