Method and apparatus for handling system information in case of detection of fake base station by utilizing quantum computing in next generation mobile communication

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The present disclosure relates to a method and an apparatus for distinguishing, by a terminal, system inter-terminal information from a fake base station.

Description

Method and apparatus for handling system information when detecting fake base stations using quantum computing in next-generation mobile communication

[0001] The present disclosure relates to the operation of a terminal in a mobile communication system. Specifically, it relates to a method and apparatus for a terminal to distinguish information between system terminals from a fake base station.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz band (e.g., the 3 terahertz (3 THz) band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), technologies such as beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands, support for various numerologies (such as the operation of multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources, initial access techniques to support multi-beam transmission and broadband, definition and operation of Band-Width Parts (BWP), Low Density Parity Check (LDPC) codes for high-volume data transmission, new channel coding methods such as Polar Codes for the reliable transmission of control information, and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) for supporting new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) for incorporating Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] As a result of the aforementioned developments and advancements in mobile communication systems, it has become possible to provide a variety of services, and thus measures to effectively provide these services are required.

[0009] This document describes the necessary transmission methods and procedures for positioning using inter-terminal communication, and aims to explain the message transmission methods required for each procedure and the specific contents of the messages.

[0010] The technical problems to be solved by the present invention are not limited to those mentioned above, and other unmentioned technical problems may be considered by those skilled in the art from the various embodiments of the present disclosure described below.

[0011] A method performed by a terminal of a wireless communication system according to an embodiment of the present invention for solving the above-mentioned problems may include: a step of determining whether authentication of system information is required; a step of transmitting a request message requesting authentication of system information to a base station when authentication of system information is required; and a step of receiving security-applied system information corresponding to system information from the base station.

[0012] According to an embodiment, uplink configuration information for transmitting the request message may be configured based on at least one of information configured from a core network entity, a master information block (MIB), or a system information block 1 (SIB1).

[0013] According to an embodiment, the system information may include at least one of MIB (master information block), SIB1 (system information block 1), or OSI (other system information).

[0014] According to an embodiment, the security-applied system information may include at least one of the following: time information regarding the time of encoding the system information, a Message Authentication Code-Integrity (MAC-I) or Digital Signature (DS) generated based on a post-quantum cryptography (PQC) algorithm applied to the system information, and signature information including a public key corresponding to the private key of the base station.

[0015] According to an embodiment, the security-applied system information may be received in units of system information blocks (SIBs) or system information messages (SIs).

[0016] According to an embodiment, the security-applied system information can be received in a divided manner.

[0017] A terminal of a wireless communication system according to an embodiment of the present invention for solving the above-mentioned problems may include: a transceiver; and a control unit that determines whether authentication of system information is required, and if authentication of the system information is required, transmits a request message requesting authentication of the system information to a base station through the transceiver, and receives system information with security applied corresponding to the system information from the base station through the transceiver.

[0018] A base station of a wireless communication system according to an embodiment of the present invention for solving the above-mentioned problems may include: a transceiver; and a control unit that, when authentication of system information is required, receives a request message requesting authentication of the system information from a terminal through the transceiver, generates security-applied system information by applying a security algorithm to the system information, and transmits the security-applied system information corresponding to the system information to the terminal through the transceiver.

[0019] A method performed by a base station of a wireless communication system according to an embodiment of the present invention for solving the above-mentioned problems may include: receiving a request message from a terminal requesting authentication of said system information when authentication of said system information is required; generating security-applied system information by applying a security algorithm to said system information; and transmitting said security-applied system information corresponding to said system information to said terminal.

[0020] According to an embodiment of the present invention, any terminal can obtain a relative or absolute position through another terminal.

[0021] The effects obtainable in the present disclosure are not limited to those mentioned in the various embodiments, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure pertains from the description below.

[0022] Figure 1 is a diagram illustrating the structure of a typical LTE system.

[0023] Figure 2 is a diagram showing the wireless protocol structure of a typical LTE system.

[0024] FIG. 3 is a drawing illustrating the structure of a next-generation mobile communication system according to one embodiment of the present disclosure.

[0025] FIG. 4 is a diagram showing the wireless protocol structure of a next-generation mobile communication system according to one embodiment of the present disclosure.

[0026] FIG. 5 is a block diagram illustrating the internal structure of a terminal according to one embodiment of the present disclosure.

[0027] FIG. 6 is a block diagram showing the configuration of an NR base station according to one embodiment of the present disclosure.

[0028] Figure 7 is a diagram showing the basic operation of a method for processing system information when an existing algorithm is applied.

[0029] FIG. 8 is a diagram showing a system information processing operation according to an embodiment of the present invention.

[0030] FIG. 9 is a diagram illustrating an example of a case corresponding to opt 1-1 among the authentication request methods of an MIB according to an embodiment of the present invention.

[0031] FIG. 10 is a diagram illustrating an example of a case corresponding to opt 1-2 among the authentication request methods of an MIB according to an embodiment of the present invention.

[0032] FIG. 11 is a diagram illustrating an example of a case corresponding to opt 1-3 among the authentication request methods of an MIB according to an embodiment of the present invention.

[0033] FIG. 12 is a diagram illustrating an example of a case corresponding to opt 1 among the methods for the auth req / response of SIB1 according to an embodiment of the present invention.

[0034] FIG. 13 is a diagram illustrating an example of a case corresponding to opt 2 among the methods for an auth request / response of SIB1 according to an embodiment of the present invention.

[0035] FIG. 14 is a diagram illustrating an example of a case corresponding to opt 1 among the methods for an OSI request auth req / response according to an embodiment of the present invention.

[0036] FIG. 15 is a diagram illustrating an example of a case corresponding to opt 2 among the methods for an OSI request auth req / response according to an embodiment of the present invention.

[0037] FIG. 16 is a diagram illustrating an example of a case corresponding to opt 1 among the segment transmission methods of OSI according to an embodiment of the present invention.

[0038] FIG. 17 is a diagram illustrating an example of a case corresponding to opt 2 among the segment transmission methods of OSI according to an embodiment of the present invention.

[0039] The operating principle of the present invention will be described in detail below with reference to the attached drawings. In describing the present invention below, specific descriptions of related known functions or configurations will be omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the invention. Furthermore, the terms described below are defined considering their functions in the present invention, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0040] Terms used in the following description to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc., are examples provided for the convenience of explanation. Accordingly, the present invention is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

[0041] Hereinafter, a base station is an entity that performs resource allocation for terminals and may be at least one of a gNode B, eNode B, Node B, BS (Base Station), radio access unit, base station controller, or a node on a network. A terminal may include a UE (User Equipment), MS (Mobile Station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions. In this disclosure, a downlink (DL) refers to a wireless transmission path of a signal transmitted by a base station to a terminal, and an uplink (UL) refers to a wireless transmission path of a signal transmitted by a terminal to a base station. Furthermore, while an LTE or LTE-A system may be described as an example below, embodiments of this disclosure may be applied to other communication systems having similar technical backgrounds or channel types. For example, 5th generation mobile communication technology (5G, new radio, NR) developed after LTE-A may be included in a system to which embodiments of this disclosure can be applied, and the 5G below may be a concept that includes existing LTE, LTE-A, and other similar services. Furthermore, the present disclosure may be applied to other communication systems with some modifications made at the discretion of a person with skilled technical knowledge, without departing significantly from the scope of the present disclosure. In this case, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams may be executed by computer program instructions.

[0042] Since these computer program instructions can be loaded onto the processor of a general-purpose computer, a computer for special purposes, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means for performing the functions described in the flowchart block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement functions in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing means of instruction for performing the functions described in the flowchart block(s). Since the computer program instructions can also be loaded onto the computer or other programmable data processing equipment, the instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a computer-executable process can also provide steps for performing the functions described in the flowchart block(s).

[0043] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specific logical function(s). Also, it should be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For example, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order depending on the corresponding function. In this case, the term "part" as used in this embodiment refers to software or hardware components such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), and the "part" may perform certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to run one or more processors. Accordingly, as an example, 'part' includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and 'parts' may be combined into a smaller number of components and 'parts' or further separated into additional components and 'parts'. Furthermore, the components and 'parts' may be implemented to utilize one or more CPUs within a device or secure multimedia card. Additionally, in an embodiment, 'part' may include one or more processors.

[0044] For the convenience of the following explanation, the present invention uses terms and names defined in the 5GS and NR specifications, which are standards defined by the 3GPP (The 3rd Generation Partnership Project) organization among existing communication standards. However, the present invention is not limited by the above terms and names and can be applied in the same way to wireless communication networks according to other standards. For example, the present invention can be applied to 3GPP 5GS / NR (5th generation mobile communication standard).

[0045] Figure 1 is a diagram illustrating the structure of a typical LTE system.

[0046] Referring to FIG. 1, as illustrated, the wireless access network of the LTE system may be composed of a next-generation base station (Evolved Node B, hereinafter ENB, Node B or base station) (1-05, 1-10, 1-15, 1-20), a Mobility Management Entity (MME) (1-25), and an S-GW (1-30, Serving-Gateway). A user terminal (User Equipment, hereinafter UE or terminal) (1-35) can connect to an external network through the ENB (1-05 to 1-20) and the S-GW (1-30).

[0047] In FIG. 1, the ENB (1-05 to 1-20) can correspond to the existing Node B of the UMTS system. The ENB (1-05 to 1-20) is connected to the UE (1-35) via a wireless channel and can perform more complex roles than the existing Node B. In an LTE system, all user traffic, including real-time services such as VoIP (Voice over IP) via the Internet Protocol, can be serviced through a shared channel. Therefore, a device is required to collect status information such as the buffer status, available transmission power status, and channel status of the UEs (1-35) and perform scheduling, and this can be handled by the ENB (1-05 to 1-20). A single ENB (1-05 to 1-20) can typically control multiple cells. For example, to achieve a transmission speed of 100 Mbps, the LTE system can use Orthogonal Frequency Division Multiplexing (OFDM) as a wireless access technology, for example, in a 20 MHz bandwidth. Additionally, the LTE system may apply an Adaptive Modulation & Coding (AMC) method that determines the modulation scheme and channel coding rate according to the channel conditions of the terminal (1-35). The S-GW (1-30) is a device that provides a data bearer and can create or remove the data bearer according to the control of the MME (1-25). The MME (1-25) is a device that is responsible for various control functions as well as mobility management functions for the terminal (1-35) and can be connected to multiple base stations (1-05 to 1-20).

[0048] Figure 2 is a diagram showing the wireless protocol structure of an existing LTE system.

[0049] Referring to FIG. 2, the wireless protocol of the LTE system may consist of a Packet Data Convergence Protocol (PDCP) (2-05, 2-40), Radio Link Control (RLC) (2-10, 2-35), Medium Access Control (MAC) (2-15, 2-30), etc., at the terminal and the ENB, respectively.

[0050] PDCP (2-05, 2-40) can be responsible for operations such as IP header compression / recovery. The main functions of PDCP (2-05, 2-40) can be summarized as follows.

[0051] - Header compression and decompression features (ROHC only)

[0052] - User data transfer function (Transfer of user data)

[0053] - Sequential delivery function (In-sequence delivery of upper layer PDUs at PDCP re-establishment procedure for RLC AM)

[0054] - Order reordering function (For split bearers in DC (only support for RLC AM): PDCP PDU routing for transmission and PDCP PDU reordering for reception)

[0055] - Duplicate detection function (Duplicate detection of lower layer SDUs at PDCP re-establishment procedure for RLC AM)

[0056] - Retransmission function (Retransmission of PDCP SDUs at handover and, for split bearers in DC, of ​​PDCP PDUs at PDCP data-recovery procedure, for RLC AM)

[0057] - Encryption and decryption functions (Ciphering and deciphering)

[0058] - Timer-based SDU discard in uplink.

[0059] Radio Link Control (RLC) (2-10, 2-35) can perform ARQ operations, etc., by reconfiguring PDCP Packet Data Units (PDUs) to an appropriate size. The main functions of RLC (2-10, 2-35) can be summarized as follows.

[0060] - Data transfer function (Transfer of upper layer PDUs)

[0061] - ARQ function (Error Correction through ARQ (only for AM data transfer))

[0062] - Concatenation, segmentation, and reassembly functions (Concatenation, segmentation, and reassembly of RLC SDUs (only for UM and AM data transfer))

[0063] - Re-segmentation function (Re-segmentation of RLC data PDUs (only for AM data transfer))

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

[0065] - Duplicate detection function (only for UM and AM data transfer)

[0066] - Error detection function (Protocol error detection (only for AM data transfer))

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

[0068] RLC re-establishment function

[0069] MAC (2-15, 2-30) is connected to multiple RLC layer devices configured in a terminal and can perform operations to multiplex RLC PDUs into MAC PDUs and demultiplex RLC PDUs from MAC PDUs. The main functions of MAC (2-15, 2-30) can be summarized as follows.

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

[0071] - Multiplexing and demultiplexing function (Multiplexing / demultiplexing of MAC SDUs belonging to one or different logical channels into / from transport blocks (TB) delivered to / from the physical layer on transport channels)

[0072] - Scheduling information reporting function

[0073] - HARQ function (Error correction through HARQ)

[0074] - Priority handling between logical channels of one UE

[0075] - Priority handling between UEs by means of dynamic scheduling

[0076] - MBMS service identification

[0077] - Transport format selection function

[0078] - Padding

[0079] The physical layer (2-20, 2-25) can perform the operation of channel coding and modulating upper layer data, making it into OFDM symbols and transmitting it to the wireless channel, or demodulating OFDM symbols received through the wireless channel and channel decoding them to transmit them to the upper layer.

[0080] Figure 3 is a diagram illustrating the structure of a next-generation mobile communication system.

[0081] Referring to FIG. 3, the wireless access network of a next-generation mobile communication system (hereinafter NR or 5G) may be composed of a next-generation base station (New Radio Node B, hereinafter NR gNB or NR base station) (3-10) and a next-generation wireless core network (New Radio Core Network, NR CN) (3-05). A next-generation wireless user terminal (New Radio User Equipment, NR UE or terminal) (3-15) can connect to an external network through the NR gNB (3-10) and the NR CN (3-05).

[0082] In FIG. 3, the NR gNB (3-10) can correspond to the eNB (Evolved Node B) of the existing LTE system. The NR gNB (3-10) is connected to the NR UE (3-15) via a wireless channel and can provide superior service compared to the existing Node B. In the next-generation mobile communication system, all user traffic can be serviced through a shared channel. Therefore, a device is required to collect status information such as the buffer status, available transmission power status, and channel status of the UEs (3-15) and perform scheduling, and the NR NB (3-10) can handle the scheduling. A single NR gNB (3-10) can control multiple cells. In the next-generation mobile communication system, to achieve ultra-high-speed data transmission compared to general LTE, a bandwidth greater than the general maximum bandwidth may be applied. Additionally, Orthogonal Frequency Division Multiplexing (OFDM) can be used as the wireless access technology, and beamforming technology can be additionally incorporated. In addition, the next-generation mobile communication system may apply an Adaptive Modulation & Coding (hereinafter referred to as AMC) method that determines the modulation scheme and channel coding rate according to the channel status of the terminal (3-10). The NR CN (3-05) can perform functions such as mobility support, bearer configuration, and QoS configuration. The NR CN (3-05) is a device responsible for various control functions as well as mobility management functions for the terminal (3-15) and can be connected to multiple base stations (3-10). Furthermore, the next-generation mobile communication system can be interoperable with an LTE system, and the NR CN (3-05) can be connected to the MME (3-25) via a network interface. The MME (3-25) can be connected to the eNB (3-30), which is an LTE base station.

[0083] FIG. 4 is a diagram showing the wireless protocol structure of a next-generation mobile communication system to which the present invention can be applied.

[0084] Referring to FIG. 4, the wireless protocol of the next-generation mobile communication system may consist of the NR Service Data Adaptation Protocol (SDAP) (4-01, 4-45), NR PDCP (4-05, 4-40), NR RLC (4-10, 4-35), NR MAC (4-15, 4-30), and NR PHY (4-20, 4-25), respectively, at the terminal and the NR base station.

[0085] The main functions of NR SDAP (4-01, 4-45) may include some of the following functions.

[0086] - User data transfer function (transfer of user plane data)

[0087] - Mapping function between a QoS flow and a DRB for both DL and UL for uplink and downlink

[0088] - Marking QoS flow ID in both DL and UL packets for uplink and downlink

[0089] - Function to map reflective QoS flow to data bearers for uplink SDAP PDUs (reflective QoS flow to DRB mapping for the UL SDAP PDUs).

[0090] For SDAP layer devices, the terminal may receive a Radio Resource Control (RRC) message indicating whether to use the header of the SDAP layer device or to use the functions of the SDAP layer device for each PDCP layer device, for each bearer, or for each logical channel. If the SDAP header is configured, the terminal may be instructed to update or reset the mapping information for the uplink and downlink QoS flows and data bearers using the 1-bit NAS reflective QoS indicator and the 1-bit AS reflective QoS indicator of the SDAP header. The SDAP header may include QoS flow ID information indicating QoS. The QoS information may be used for data processing priorities, scheduling information, etc., to support seamless service.

[0091] The main functions of NR PDCP (4-05, 4-40) may include some of the following functions.

[0092] - Header compression and decompression features (ROHC only)

[0093] - User data transfer function (Transfer of user data)

[0094] - Sequential delivery function (In-sequence delivery of upper layer PDUs)

[0095] - Out-of-sequence delivery of upper layer PDUs

[0096] - Reordering function (PDCP PDU reordering for reception)

[0097] - Duplicate detection function (Duplicate detection of lower layer SDUs)

[0098] - Retransmission of PDCP SDUs

[0099] - Encryption and decryption functions (Ciphering and deciphering)

[0100] - Timer-based SDU discard in uplink.

[0101] In the above description, the reordering function of the NR PDCP device may refer to a function that reorders PDCP PDUs received from a lower layer in order based on the PDCP SN (sequence number). The reordering function of the NR PDCP device may include a function of transmitting data to an upper layer in the reordered order, or a function of transmitting it immediately without considering the order, a function of recording lost PDCP PDUs by reordering, a function of reporting the status of lost PDCP PDUs to the transmitting side, and a function of requesting retransmission of lost PDCP PDUs.

[0102] The main functions of NR RLC(4-10, 4-35) may include some of the following functions.

[0103] - Data transfer function (Transfer of upper layer PDUs)

[0104] - Sequential delivery function (In-sequence delivery of upper layer PDUs)

[0105] - Out-of-sequence delivery of upper layer PDUs

[0106] - ARQ function (Error Correction through ARQ)

[0107] - Concatenation, segmentation, and reassembly functions of RLC SDUs

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

[0109] - Reordering function (Reordering of RLC data PDUs)

[0110] - Duplicate detection

[0111] - Error detection function (Protocol error detection)

[0112] - RLC SDU discard function

[0113] RLC re-establishment function

[0114] In the above description, the in-sequence delivery function of the NR RLC device may refer to the function of delivering RLC SDUs received from a lower layer to an upper layer in sequence. In the case where a single RLC SDU is received divided into multiple RLC SDUs, the in-sequence delivery function of the NR RLC device may include the function of reassembling and delivering them.

[0115] The in-sequence delivery function of the NR RLC device may include a function to rearrange received RLC PDUs based on an RLC SN (sequence number) or PDCP SN (sequence number), a function to record lost RLC PDUs by rearranging the order, a function to report the status of lost RLC PDUs to the transmitting side, and a function to request retransmission of lost RLC PDUs.

[0116] The in-sequence delivery function of the NR RLC device may include a function that, in the event of a lost RLC SDU, delivers only the RLC SDUs prior to the lost RLC SDU in order to the upper layer.

[0117] The in-sequence delivery function of the NR RLC device may include the function of delivering all RLC SDUs received before the timer started to the upper layer in order, even if there are lost RLC SDUs, if a predetermined timer has expired.

[0118] The in-sequence delivery function of the NR RLC device may include the function of delivering all RLC SDUs received up to that point to the upper layer in order when a predetermined timer expires, even if there are lost RLC SDUs.

[0119] The NR RLC device can process RLC PDUs in the order they are received and deliver them to the NR PDCP device, regardless of the sequence number (out-of-sequence delivery).

[0120] When an NR RLC device receives a segment, it can receive segments stored in a buffer or to be received later, reconstruct them into a complete RLC PDU, and then transmit it to an NR PDCP device.

[0121] The NR RLC layer may not include a concatenation function, and the function may be performed by the NR MAC layer or replaced by the multiplexing function of the NR MAC layer.

[0122] In the above description, the out-of-sequence delivery function of the NR RLC device may refer to a function of delivering RLC SDUs received from a lower layer directly to an upper layer regardless of order. The out-of-sequence delivery function of the NR RLC device may include a function of reassembling and delivering RLC SDUs when a single RLC SDU is received divided into multiple RLC SDUs. The out-of-sequence delivery function of the NR RLC device may include a function of storing the RLC SN or PDCP SN of the received RLC PDUs, sorting the order, and recording the lost RLC PDUs.

[0123] The NR MAC (4-15, 4-30) can be connected to multiple NR RLC layer devices configured in a terminal, and the main functions of the NR MAC may include some of the following functions.

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

[0125] - Multiplexing and demultiplexing functions (Multiplexing / demultiplexing of MAC SDUs)

[0126] - Scheduling information reporting function

[0127] - HARQ function (Error correction through HARQ)

[0128] - Priority handling between logical channels of one UE

[0129] - Priority handling between UEs by means of dynamic scheduling

[0130] - MBMS service identification

[0131] - Transport format selection function

[0132] - Padding

[0133] The NR PHY layer (4-20, 4-25) can perform the operation of channel coding and modulating upper layer data, creating OFDM symbols and transmitting them to the wireless channel, or demodulating OFDM symbols received through the wireless channel and channel decoding them to transmit them to the upper layer.

[0134] FIG. 5 is a block diagram illustrating the structure of a terminal according to one embodiment of the present invention.

[0135] Referring to the drawing above, the terminal includes an RF (Radio Frequency) processing unit (5-10), a baseband processing unit (5-20), a storage unit (5-30), and a control unit (5-40).

[0136] The RF processing unit (5-10) performs functions for transmitting and receiving signals through a wireless channel, such as signal band conversion and amplification. The RF processing unit (5-10) up-converts the baseband signal provided by the baseband processing unit (5-20) into an RF band signal, transmits it through an antenna, and down-converts the RF band signal received through the antenna into a baseband signal. For example, the RF processing unit (5-10) may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC (digital to analog converter), an ADC (analog to digital converter), etc. Although only one antenna is shown in the drawing, the terminal may be equipped with multiple antennas. Additionally, the RF processing unit (5-10) may include multiple RF chains. Furthermore, the RF processing unit (5-10) may perform beamforming. For the above beamforming, the RF processing unit (5-10) can adjust the phase and magnitude of each of the signals transmitted and received through multiple antennas or antenna elements. In addition, the RF processing unit can perform MIMO and can receive multiple layers when performing MIMO operation.

[0137] The baseband processing unit (5-20) performs a conversion function between a baseband signal and a bit sequence according to the physical layer specifications of the system. For example, when transmitting data, the baseband processing unit (5-20) generates complex symbols by encoding and modulating the transmitted bit sequence. Additionally, when receiving data, the baseband processing unit (5-20) restores the received bit sequence by demodulating and decoding the baseband signal provided by the RF processing unit (5-10). For example, in the case of following the OFDM (orthogonal frequency division multiplexing) method, when transmitting data, the baseband processing unit (5-20) generates complex symbols by encoding and modulating the transmitted bit sequence, maps the complex symbols to subcarriers, and then constructs OFDM symbols through IFFT (inverse fast Fourier transform) operation and CP (cyclic prefix) insertion. Additionally, upon receiving data, the baseband processing unit (5-20) divides the baseband signal provided by the RF processing unit (5-10) into OFDM symbol units, restores the signals mapped to subcarriers through a fast Fourier transform (FFT), and then restores the received bit sequence through demodulation and decoding.

[0138] The baseband processing unit (5-20) and the RF processing unit (5-10) transmit and receive signals as described above. Accordingly, the baseband processing unit (5-20) and the RF processing unit (5-10) may be referred to as a transmitting unit, a receiving unit, a transmitting and receiving unit, or a communication unit. Furthermore, at least one of the baseband processing unit (5-20) and the RF processing unit (5-10) may include a plurality of communication modules to support a plurality of different wireless access technologies. Additionally, at least one of the baseband processing unit (5-20) and the RF processing unit (5-10) may include different communication modules to process signals of different frequency bands. For example, the different wireless access technologies may include wireless LAN (e.g., IEEE 802.11), cellular network (e.g., LTE), etc. In addition, the above different frequency bands may include super high frequency (SHF) bands (e.g., 2 NRHz, NRHz) and millimeter wave (e.g., 60 GHz) bands.

[0139] The storage unit (5-30) stores data such as basic programs, application programs, and setting information for the operation of the terminal. In particular, the storage unit (5-30) can store information related to a second connection node that performs wireless communication using a second wireless connection technology. Additionally, the storage unit (5-30) provides the stored data upon request from the control unit (5-40).

[0140] The control unit (5-40) controls the overall operations of the terminal. For example, the control unit (5-40) transmits and receives signals through the baseband processing unit (5-20) and the RF processing unit (5-10). Additionally, the control unit (5-40) writes and reads data to and from the storage unit (5-40). To this end, the control unit (5-40) may include at least one processor. For example, the control unit (5-40) may include a communication processor (CP) that performs control for communication and an application processor (AP) that controls upper layers such as applications.

[0141] FIG. 6 is a block diagram showing the configuration of an NR base station according to one embodiment of the present invention.

[0142] As illustrated in the drawing above, the base station is configured to include an RF processing unit (6-10), a baseband processing unit (6-20), a backhaul communication unit (6-30), a storage unit (6-40), and a control unit (6-50).

[0143] The RF processing unit (6-10) performs functions for transmitting and receiving signals through a wireless channel, such as signal band conversion and amplification. The RF processing unit (6-10) upconverts the baseband signal provided by the baseband processing unit (6-20) into an RF band signal, transmits it through an antenna, and downconverts the RF band signal received through the antenna into a baseband signal. For example, the RF processing unit (6-10) may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc. Although only one antenna is shown in the drawing, the first connection node may be equipped with multiple antennas. Additionally, the RF processing unit (6-10) may include multiple RF chains. Furthermore, the RF processing unit (6-10) may perform beamforming. For beamforming, the RF processing unit (6-10) may adjust the phase and magnitude of each of the signals transmitted and received through multiple antennas or antenna elements. The above RF processing unit can perform down-to-down MIMO operation by transmitting one or more layers.

[0144] The baseband processing unit (6-20) performs a conversion function between a baseband signal and a bit sequence according to the physical layer specifications of the first wireless access technology. For example, when transmitting data, the baseband processing unit (6-20) generates complex symbols by encoding and modulating the transmitted bit sequence. Additionally, when receiving data, the baseband processing unit (6-20) restores the received bit sequence by demodulating and decoding the baseband signal provided by the RF processing unit (6-10). For example, in the case of following the OFDM method, when transmitting data, the baseband processing unit (6-20) generates complex symbols by encoding and modulating the transmitted bit sequence, maps the complex symbols to subcarriers, and then constructs OFDM symbols through IFFT operation and CP insertion. Additionally, upon receiving data, the baseband processing unit (6-20) divides the baseband signal provided by the RF processing unit (6-10) into OFDM symbol units, restores the signals mapped to subcarriers through FFT operations, and then restores the received bit sequence through demodulation and decoding. The baseband processing unit (6-20) and the RF processing unit (6-10) transmit and receive signals as described above. Accordingly, the baseband processing unit (6-20) and the RF processing unit (6-10) may be referred to as a transmitting unit, a receiving unit, a transmitting and receiving unit, a communication unit, or a wireless communication unit.

[0145] The backhaul communication unit (6-30) provides an interface for communicating with other nodes within the network. The backhaul communication unit (6-30) converts a bit sequence transmitted from the main base station to other nodes, such as an auxiliary base station or a core network, into a physical signal, and converts a physical signal received from the other nodes into a bit sequence.

[0146] The storage unit (6-40) stores data such as basic programs, application programs, and configuration information for the operation of the main station. In particular, the storage unit (6-40) can store information regarding bearers assigned to connected terminals, measurement results reported from connected terminals, etc. Additionally, the storage unit (6-40) can store information that serves as a criterion for determining whether to provide multiple connections to the terminal or to disconnect them. Furthermore, the storage unit (6-40) provides the stored data upon the request of the control unit (6-50).

[0147] The control unit (6-50) controls the overall operations of the base station. For example, the control unit (6-50) transmits and receives signals through the baseband processing unit (6-20) and the RF processing unit (6-10) or through the backhaul communication unit (6-30). Additionally, the control unit (6-50) writes and reads data to and from the storage unit (6-40). To this end, the control unit (6-50) may include at least one processor.

[0148] As background to the present invention, when system information is transmitted in NR, the terminal can use the information from the cell as is without verifying whether the cell is a cell that has completed authentication. Consequently, a fake base station (FBS) may cause delays in connecting to a legitimate cell by transmitting incorrect control information to the terminal according to its own needs, or cause malfunctions by transmitting information containing incorrect configuration data. Furthermore, while control information may be transmitted without issues, malicious acts such as obtaining user information through the terminal or sending phishing messages via SMS are possible by linking a malicious server to the actual application layer. In such cases, a method is required for the terminal to verify and use the system information provided by the selected cell.

[0149] In this regard, the assumption in the present invention is that the network and the terminal use asymmetric cryptography. In the network, a key management system assigns a private (security) key to each base station and can distribute a public key corresponding to the base station's private key to terminals using the corresponding cell. When a base station intends to transmit system information, it may transmit a digital signature (DS) using its own public key together with the original message or separately; upon receiving the message and digital signature, the terminal uses the given public key to verify the integrity and suitability of the information intended to be sent by the base station.

[0150] Another background factor is that post-quantum cryptography (PQC) algorithms, which replace existing security algorithms, are being considered for use in the encoding and decoding of digital signatures (DS). As the introduction of quantum computers becomes a reality, the problem arises that decoding can be easily achieved when applying existing algorithms. Consequently, PQC algorithms that significantly increase the difficulty of solving the problem have been introduced, and the configuration of DS based on this and decoding at the receiving end of the DS have been considered.

[0151] Figure 7 is a diagram showing the basic operation of a method for processing system information when an existing algorithm is applied.

[0152] Referring to FIG. 7, the diagram on the left shows a case where a system (system information) (750) is encoded using an existing security algorithm (780). The information required at this time includes the original system information (750), a private key (760) assigned to the base station, and time information (770) at the time of encoding, such as a time stamp or a time counter value. A Message Authentication Code-Integrity (MAC-I) or Digital Signature (DS) (790) can be generated using the existing algorithm (780). The generated MAC-I or DS (790) can be transmitted from the base station to the terminal as a single integrity-protected system information (700), together with the original system information (750) and the time stamp information (770).

[0153] In the drawing on the right side of FIG. 7, in step 730, additionally, a public key to be used for decryption at the terminal (UE) (710) may be transmitted from the base station (cell 1) (720) to the terminal (710) along with the integrity protected system information through a separate signature field (credential). Upon receiving the information, the terminal (710) can decrypt the integrity protected system info (information) (700) using the given time stamp information (770), MAC-I or DS (790), and the public key value included in the credential to determine (verify) whether the information matches the corresponding public key. If it matches the information, the terminal (710) can consider the original system info of the integrity protected system info to be information from an authenticated base station. That is, this message can be determined to be authenticated.

[0154] However, if the security algorithm is replaced with the PQC algorithm, the size of the DS can increase significantly from 200 to 400 bytes of the existing algorithm to 3000 to 7000 bytes. Consequently, transmitting integrity protected (IP) system information via broadcast every time may lead to a problem where a large amount of wireless resources are inevitably consumed.

[0155] Accordingly, in the present invention, a terminal transmits an authentication request for system information to a base station based on a specific message in a specific situation, and accordingly, the base station transmits information necessary for decoding the indicated system information to the terminal, thereby enabling the terminal to finally determine whether the system information is information from an authenticated cell (base station) or was transmitted from a cell of an FBS. Furthermore, since it is still difficult to send all DS information in a single transmission when transmitting information for decoding in this manner, the present invention proposes a method of transmitting this information in segments.

[0156] FIG. 8 is a diagram showing a system information processing operation according to an embodiment of the present invention.

[0157] Referring to FIG. 8, at step 830, the base station (cell 1) (820) may broadcast system information from a valid cell to the terminal (810), or may have previously broadcast it. Even in this case, at step 840, when the terminal (810) needs to use the system information or needs to verify the validity of the system information, the terminal (810) may trigger the authentication procedure for the desired system information. Then, at step 850, the terminal (810) may request authentication of the system information from the base station (cell 1) (820). According to an embodiment, this request signal or message may explicitly indicate the desired system information (e.g., including an indicator of the message).

[0158] Upon receiving such a request, the base station (820) can use the private key assigned to it in step 860 to encode the corresponding system information through the PQC algorithm to construct a digital signature (or MAC-I). Then, in step 870, it can include the public key associated with the private key of the base station (820) in the credential and transmit it to the terminal (810) along with the integrity-protected system information. Of course, if system information has been transmitted previously and the terminal (810) has distinguished and stored it, the base station (820) may transmit only the remaining DS and / or credential information, excluding the original system information, to the terminal (810) upon request.

[0159] When transmitting the information, the base station (820) can transmit it by segmentation, and the related schedule information can also be transmitted to the terminal (810).

[0160] In step 880, the terminal (810) that has received all of the segmented information can combine them. Then, the terminal (810) can extract a public key from the credential of the information or the information combined from the segmented information, and verify whether the original system information is valid by performing a decoding process using the DS and the received or original system information. If the information is valid, the terminal (810) can use the system information (e.g., apply, save, etc.).

[0161] The following proposes a solution regarding the detailed issue.

[0162] Issue 1: Under what circumstances can a terminal perform an authentication request for system information?

[0163] When the terminal reads the PSS (primary synchronization signal) and SSS (secondary synchronization signal) (SSB: synchronization signal and PBCH (physical broadcast channel) block) of a cell on a specific frequency, it may request the authentication status of the MIB (master information block) during the operation to read the MIB. Alternatively, when the terminal reads SIB1 (system information block 1) after the MIB has been read or after the authentication of the MIB has been verified, it may request the authentication status of SIB1. Alternatively, when the terminal reads other system information after the SIB1 has been read or after the authentication of SIB1 has been verified, it may request the authentication status of the other system information (OSI) or a specific SIB contained therein.

[0164] Alternatively, if a specific system information that the terminal has previously stored has passed for a certain period of time without being updated separately, the terminal may make an auth request to the system information.

[0165] Issue 2: Which system information should be protected? In other words, for which system information should the authentication request and response procedures be applied?

[0166] Based on the current NR, the following system information may exist in system information: MIB, SIB1, and other system information (OSI).

[0167] MIBs can be transmitted via PBCH, and since MIBs are transmitted in conjunction with SSBs transmitted from the cell, beam-specific MIBs can be transmitted for each beam.

[0168] Since the MIB contains basic information for receiving SIB1, the terminal requires the information from the MIB to read SIB1.

[0169] Since OSI-specific schedule information in SIB1 is required to receive OSI, the terminal must receive MIB and SIB1, and the authentication of each piece of information must be verified.

[0170] Based on NR, the information that can be included in the MIB is,

[0171] - Cell system frame number

[0172] - Subcarrier spacing information used for receiving SIB1, receiving msg 2 / 4 in random access, receiving paging messages, and broadcasting SI messages

[0173] - Frequency offset between the resource grid and the SSB associated with this MIB

[0174] - Frequency location and time information of Common CORESET (control resource set) (CORESET#0), configuration and time information of the search space, and parameters of the PDCCH (physical downlink control channel)

[0175] - Cell barring information and intra-frequency reselection allowance / disallowance information

[0176] It may include at least one of the following.

[0177] Basically, since all system information transmitted over the air (broadcast) can be intercepted by the FBS, it may be necessary to apply authentication requests and responses to all system information messages. However, depending on the actions performed by the FBS and the load placed on the system, the FBS may be filtered out using only a portion of the system information.

[0178] According to an embodiment, since the information included in the SS (synchronization signal) must be available to all terminals, the SS may not be included in the target of the auth req (request) / resp (response) operation. In the case of system information, it may be considered as the following options.

[0179] Opt 1. Considers only MIB.

[0180] Opt 2. Consider only SIB1

[0181] Opt 3. Consider SIB1 through SIBx excluding MIB

[0182] Opt 4. Considers all system information, including MIB, SIB1 through SIBx.

[0183] In the case of Opt 1, after the terminal checks the cell and confirms that the MIB is authenticated, all system information scheduled from that cell onward is considered valid.

[0184] In the case of Opt 2, there are difficulties in implementing the auth request / response of the MIB, and since SIB1 is representative in that it contains many types of core system information, if SIB1 is considered valid, then the MIB that scheduled SIB1 and the OSI that is scheduled due to SIB1 are all considered valid.

[0185] Opt 3 excludes MIBs due to the difficulty of implementing auth request / response, and in principle, requires that validity checks be performed on the remaining system information.

[0186] Opt 4 is based on the principle that all over-the-air transmitted information must be authenticated.

[0187] Issue 3: We will examine how the auth request / response works for each system information.

[0188] ISSUE 3-A: Protection of MIBs.

[0189] An MIB can be transmitted via a PBCH associated with a single SSB. Accordingly, a terminal may seek to receive an MIB associated with a specific SSB while measuring the SSB at the frequency of a specific cell. In this case,

[0190] a) When an MIB is received for the determined SSB,

[0191] b) For any SSB, if an associated MIB is received,

[0192] c) If MIBs are not received for all available MIBs during a specific period,

[0193] The terminal may request authentication of the MIB. For example, the request signal (message) may be the transmission of a random access preamble. In addition, the index of this preamble and / or the time / frequency of the UL (uplink) resource used when transmitting the preamble may be set to a resource specific to the MIB authentication request.

[0194] In this case, in case a), the request signal may be transmitted as a UL signal to a beam associated with the corresponding SSB or as a RACH (random access channel) preamble (random access preamble). Accordingly, the UL configuration for the auth request may include RACH configuration information associated with the corresponding SSB.

[0195] In case b), the terminal can request authentication of the MIB regardless of the beam associated with the SSB. In this case, the UL configuration may include a beam selection condition for transmitting a (random access) preamble. This condition may be the DL (downlink) RSRP (reference signal received power) / RSRQ (reference signal received quality) signal threshold of a specific beam. That is, based on the beam that exceeds this condition, a request signal corresponding to that beam can be transmitted.

[0196] In case c), the terminal can barring the cell or request an MIB authentication request. In this case, the terminal can also request MIB authentication regardless of beam.

[0197] The UL configuration for the above MIB auth request may include the following information.

[0198] - Frequency info UL: including frequency band list, absoluteFrequencyPointA, SCS for UL

[0199] - Initial UL BWP info to send request signal: including generic BWP config info, OnDemandAuthConfigCommon (same IEs as in RACHConfigCommon) on this UL BWP (or if BWP is not there in 6G, then just UL freq band)

[0200] ■ If the above a) case, the information corresponding to RACHconfigCommon may be information for transmission to a specific SSB, and if b) and c) case, it may be information for a common beam.

[0201] - pdcchConfig: coreset and search space frequency and time resource location information for PDCCH reception. To receive MIB and / or DS and / or credential and / or time stamp information over PDSCH with PDCCH schedule.

[0202] - Each random access resource (preamble, frequency / time resource, etc.) may be allocated differently depending on whether only decryption information (DS, time stamp information, credential information including public key) is requested for the purpose of MIB auth request, or whether decryption information and MIB information are requested together.

[0203] The above UL configuration may be provided to the terminal through the following cases.

[0204] Opt 1-1: The MIB itself may include the above UL configuration information.

[0205] In this case, after receiving the MIB, the terminal can first perform an authentication request using the information in the UL configuration, regardless of the authentication result. Therefore, when a response corresponding to the authentication request is received, the terminal can determine the authentication of the MIB and use that information. That is, the UL configuration information can be used first without being considered as an authentication determination target.

[0206] Opt 1-2. The above UL configuration information can be preconfigured in the terminal.

[0207] For each 6G-enabled frequency (or a subset thereof), if an MIB authentication request is possible on each UL band / frequency considering the UL frequency, the configuration information can be pre-configured in the terminal in a list format. Using this, when the terminal reads the SSB of a specific cell and needs to obtain MIB or SIB1 information, it can perform a preamble transmission using the corresponding UL configuration to the cell for the MIB authentication request and receive an authentication response.

[0208] Opt 1-3. UL configuration can be specified in the SIB1 of the corresponding cell.

[0209] In this case, the terminal first reads the MIB and, by applying the information in the MIB as is, can read up to SIB1. Then, it can request an MIB auth request based on the UL configuration existing in SIB1. If it receives a response corresponding to the auth request and the authentication is successful, the terminal can consider that the MIB or the MIB and SIB1 are authenticated.

[0210] FIG. 9 is a diagram illustrating an example of a case corresponding to opt 1-1 among the authentication request methods of an MIB according to an embodiment of the present invention.

[0211] Referring to FIG. 9, at step 930, the terminal (910) can receive the MIB. The MIB can be included in the SSB and transmitted by the base station (cell 1) (920). The MIB may also include UL configuration information for transmitting a request for authentication.

[0212] In step 940, the terminal (910) can read the SSB and acquire (or receive) the MIB. Then, if the received MIB is not authenticated (if authentication (verification) of the MIB is required), in step 950, the terminal (910) can transmit a random access preamble or an authentication request signal to the base station (920) through the information of the UL configuration included in the MIB. At this time, if there is a setting for signal transmission using a specific beam in the UL configuration, the terminal (910) can transmit the authentication request signal through that beam. If there is no beam-specific transmission setting in the UL configuration, the terminal (910) can select a beam using other beam selection metrics and then transmit the authentication request signal through the preamble / frequency / time resources specialized for that beam. With the above UL configuration, specialized preamble / frequency / time resources may be allocated for the MIB's auth request, and the UL signal (random access preamble or authentication request signal) may be transmitted through the specialized resources configured above for the MIB's auth request.

[0213] The base station (920) that receives the above authentication request signal can configure the DS (or MAC-I) based on the PQC algorithm in step 950 using the base station specific private key, time information based on the time of encoding of the MIB or the time of transmission of the MIB, and information of the MIB itself.

[0214] And the base station (920) can transmit information for decryption configured in this way (DS, signature information including a public key corresponding to a private key, time stamp information) and information including the original MIB (integrity protected (IP) MIB) to the terminal (910) in step 970. According to an embodiment, the auth request signal transmitted by the terminal (910) may include a request to transmit only the information for decryption excluding the MIB. In this case, the base station (920) can transmit only the information for decryption excluding the MIB to the terminal (910).

[0215] According to an embodiment, in step 955, the base station (910) can transmit schedule information to be transmitted to the terminal (910) via DCI (downlink control information) in the PDCCH, including information for decoding and information including the original MIB.

[0216] If necessary, the network (base station) (920) can perform segmentation on the IP MIB and transmit transmission schedule information corresponding to each segment to the terminal (910) via DCI in the PDCCH.

[0217] The above DCI may include at least one of information indicating that it is an integrity-protected MIB message, information indicating whether the information has been segmented, and, if segmented, information indicating which segment it is.

[0218] In step 960, the terminal (910) monitors the PDCCH through the PDCCH configuration information included in the UL configuration, finds the DCI, and uses a new RNTI value (e.g., authSI-RNTI) to find a preset authentication response, thereby descrambles the schedule information for which information including decoding information and the original MIB is transmitted on the PDSCH (physical downlink shared channel). According to an embodiment, if the information including decoding information and the original MIB is segmented and transmitted, the terminal (910) can use the new RNTI value to descramble the schedule information for which the segment is transmitted on the PDSCH. Here, the new RNTI value may be a predetermined value. Additionally, the DCI may include not only the schedule information but also information indicating whether the segment is the last segment, how many segments the terminal (910) is to receive in total, and which segment is currently scheduled.

[0219] According to the above schedule information, at step 970, the base station (920) can transmit an integrity protected MIB (information including information for decoding and the original MIB) to the terminal (910). When the integrity protected MIB is transmitted in segments, the terminal (910) can receive all segments.

[0220] A terminal (910) that receives information including the information for decoding and the original MIB can restore the MIB in step 980, check the validity according to the DS and credential, and if valid, use the information. Alternatively, a terminal (910) that receives all of the segments can assemble them to restore the MIB, check if the information is valid, and if valid, use the information.

[0221] FIG. 10 is a diagram illustrating an example of a case corresponding to opt 1-2 among the authentication request methods of an MIB according to an embodiment of the present invention.

[0222] Referring to FIG. 10, in step 1030, the terminal (1010) may have received from a related entity in the core network (CN) (1025) in advance, or may have received UL frequency resources / preamble / time resources / subcarrier spacing information, etc., for an auth req signal for MIB for each frequency operating in 6G based on manufacturer settings (step 1035). At this time, the UL signal setting may be set to the actual required value, and the combination of the preamble / time resources / frequency resources / subcarrier spacing information, etc. may be configured into a single ID and may be set for multiple IDs.

[0223] In step 1040, the terminal (1010) can select the cell (base station, cell 1) (1020) to be camped by measuring the SSB, and then perform the following operation. The SSB may include an MIB.

[0224] In step 1045, if the terminal (1010) receives (acquires) the MIB, and the MIB is not authenticated (if authentication (verification) of the MIB is required), in step 1050, the terminal (1010) can transmit a random access preamble or an authentication request signal to the base station (1020) through the information of the UL configuration included in the MIB. At this time, if there is a setting for signal transmission using a specific beam in the UL configuration, the terminal (1010) can transmit the signal through that beam. And, if there is no beam-specific transmission setting in the UL configuration, the terminal (1010) can select a beam using other beam selection metrics and then transmit the request signal through the preamble / frequency / time resources specialized for that beam. With the above UL configuration, specialized preamble / frequency / time resources may be allocated for the MIB's auth request, and the UL signal (random access preamble or authentication request signal) may be transmitted through the specialized resources configured above for the MIB's auth request.

[0225] The base station (1020) that receives the above signal can construct a DS (or MAC-I) based on the PQC algorithm in step 1055 using the base station specific private key, time information based on the time of encoding of the MIB or the time of transmission of the MIB, and information of the MIB itself.

[0226] The base station (1020) can transmit information for decoding configured in this way (DS, signature information including a public key corresponding to a private key, time stamp information) and information including the original MIB (IP MIB) to the terminal (1010) in step 1070. According to an embodiment, the auth request signal transmitted by the terminal (1010) may include a request to transmit only the information for decoding excluding the MIB. In this case, the base station (1020) can transmit only the information for decoding excluding the MIB to the terminal (1010).

[0227] According to an embodiment, in step 1060, the base station (1020) can transmit schedule information to be transmitted to the terminal (1010) via DCI in the PDCCH, including information for decoding and information including the original MIB.

[0228] If necessary, the network (1020) can perform segmentation on the IP MIB and transmit transmission schedule information corresponding to each segment to the terminal (1010) via DCI in the PDCCH.

[0229] The above DCI may include at least one of information indicating that it is an integrity-protected MIB message, information indicating whether the information has been segmented, and, if segmented, information indicating which segment it is.

[0230] In step 1065, the terminal (1010) monitors the PDCCH through the PDCCH configuration information included in the UL configuration, finds the DCI, and uses a new RNTI value (e.g., authSI-RNTI) to find a preset authentication response, thereby descrambles the schedule information for which information including decryption information and the original MIB is transmitted from the PDSCH. According to an embodiment, if the information including decryption information and the original MIB is segmented and transmitted, the terminal (1010) can use the new RNTI value to descramble the schedule information for which the segment is transmitted from the PDSCH. Here, the new RNTI value may be a predetermined value. Additionally, the DCI may include not only the schedule information but also information indicating whether the segment is the last segment, how many segments the terminal (1010) is to receive in total, and which segment the currently scheduled segment is.

[0231] According to the above schedule information, at step 1070, the base station (1020) can transmit an integrity protected MIB (information including information for decoding and the original MIB) to the terminal (1010). When the integrity protected MIB is transmitted in segments, the terminal (1010) can receive all segments.

[0232] A terminal (1010) that receives information including the information for decoding and the original MIB can restore the MIB in step 1080, check the validity according to the DS and credential, and if valid, use the information. Alternatively, a terminal (1010) that receives all of the segments can assemble them to restore the MIB, check if the information is valid, and if valid, use the information.

[0233] FIG. 11 is a diagram illustrating an example of a case corresponding to opt 1-3 among the authentication request methods of an MIB according to an embodiment of the present invention.

[0234] Referring to FIG. 11, at step 1030, the terminal (1110) can receive (acquire) the MIB. The MIB may be included in the SSB and transmitted by the base station (cell 1) (1120). Then, at steps 1140 and 1045, the terminal (1110) can receive SIB1 based on the information included in the MIB. Although the drawing shows that at step 1135, the terminal (1110) determines whether verification of the MIB is required and then receives SIB1 at step 1140, this is not limited thereto, and the terminal (1110) may determine whether verification of the MIB is required after receiving SIB1.

[0235] In step 1035, when the terminal (1110) receives the MIB, if the MIB is not authenticated (if verification (authentication) of the MIB is required), the terminal (1110) can transmit a random access preamble or an authentication request signal to the base station (1120) through the information of the UL configuration included in SIB1 in step 1050. At this time, if there is a setting for signal transmission using a specific beam in the UL configuration, the terminal (1110) can transmit the signal through that beam. If there is no beam-specific transmission setting in the UL configuration, the terminal (1110) can select a beam using other beam selection metrics and then transmit the request signal through the preamble / frequency / time resources specialized for that beam. With the above UL configuration, specialized preamble / frequency / time resources may be allocated for the MIB's authentication request, and a UL signal (random access preamble or authentication request signal) may be transmitted through the specialized resources configured for the MIB's authentication request. According to an embodiment, the authentication request may also request authentication for SIB1. In this case, the authentication request may include information regarding whether it requests authentication for the MIB and / or authentication for SIB1.

[0236] When the terminal (1110) receives an SSB in steps 1030 and 1135 and receives an MIB associated therewith, the MIB may contain PDCCH configuration information for SIB1. The terminal (1110) can receive SIB1 in steps 1140 and 1145 through this information.

[0237] This SIB information may include a UL signal configuration for the MIB auth request. This information may refer to the detail information of the previously described UL configuration. The terminal (1110) can transmit the MIB auth request signal to the base station (1120) using the UL configuration for the MIB auth request included in the SIB1.

[0238] The base station (1120) that receives the above signal can construct a DS (or MAC-I) based on the PQC algorithm in step 1155 using the base station specific private key, time information based on the time of encoding of the MIB or the time of transmission of the MIB, and information of the MIB itself.

[0239] The base station (1120) can transmit information for decoding configured in this way (DS, signature information including a public key corresponding to a private key, time stamp information) and information including the original MIB (IP MIB) to the terminal (1110) in step 1170. According to an embodiment, the auth request signal transmitted by the terminal (1110) may include a request to transmit only the information for decoding excluding the MIB. In this case, the base station (1120) can transmit only the information for decoding excluding the original MIB to the terminal (1110).

[0240] According to an embodiment, in step 1160, the base station (1120) can transmit schedule information to be transmitted to the terminal (1110) via DCI in the PDCCH, including information for decoding and information including the original MIB.

[0241] If necessary, the network (1120) can perform segmentation on the IP MIB and transmit transmission schedule information corresponding to each segment to the terminal (1110) via DCI in the PDCCH.

[0242] In step 1165, the terminal (1110) monitors the PDCCH through the PDCCH configuration information included in the UL configuration, finds the DCI, and uses a new RNTI value (e.g., authSI-RNTI) to find a preset authentication response, thereby descramble the schedule information for the information including the decryption information and the original MIB to be transmitted from the PDSCH. According to an embodiment, if the information including the decryption information and the original MIB is segmented and transmitted, the terminal (1110) can use the new RNTI value to descramble the schedule information for the segment to be transmitted from the PDSCH. Here, the new RNTI value may be a predetermined value. Additionally, the DCI may include not only the schedule information but also information indicating whether the segment is the last segment, how many segments the terminal (1110) should receive in total, and which segment the currently scheduled segment is.

[0243] According to the above schedule information, at step 1170, the base station (1120) can transmit an integrity protected MIB (information including information for decoding and the original MIB) to the terminal (1110). When the integrity protected MIB is transmitted in segments, the terminal (1110) can receive all segments.

[0244] A terminal (1110) that receives information including the information for decoding and the original MIB can restore the MIB in step 1180, check the validity according to the DS and credential, and if valid, use the information. Alternatively, a terminal (1110) that receives all of the segments can assemble them to restore the MIB, check if the information is valid, and if valid, use the information.

[0245] Issue 3-B: Protection of SIB1

[0246] SIB1 may include essential configuration information, such as the serving cell's connection and OSI scheduling information, and cell-specific wireless resource information that can be used in connected mode, inactive mode, or idle mode. Accordingly, the information of SIB1 may also need to be determined through the authentication request / response process whether it belongs to the FBS cell.

[0247] The signaling configuration information for the auth request of SIB1 may be similar to that for MIB. The signaling configuration information for the auth request of SIB1 may include some or all of the following information.

[0248] - Frequency info UL: including frequency band list, absoluteFrequencyPointA, SCS for UL transmission

[0249] - Initial UL BWP info to send request signal: including generic BWP config info, OnDemandAuthConfigCommon (same IEs as in RACHConfigCommon) on this UL BWP (or if BWP is not there in 6G, then just UL frequency band)

[0250] - pdcchConfig: coreset and search space frequency and time resource location information for PDCCH reception. To receive SIB1 and / or DS and / or credential and / or time stamp information over PDSCH with PDCCH schedule. The above PDCCH configuration information is a setting for receiving a response in an authentication request / response, and may be identical to the PDCCH setting in servingCellConfigCommonSIB, or may exist as a separate setting for the SIB1 authentication response.

[0251] - RACH-ConfigCommon for SIB1 auth request,

[0252] ■ Opt A: Same configurations are shared with the normal RACH config common while featureCombinationPreambleList can have preamble sets specific to auth request purpose. That is, it can use the same resources as the RACH resources (frequency and time resources) used when a terminal wants to perform random access to a base station in idle / inactive or connection mode when necessary, but the preamble can be configured for a separate SIB1 auth req purpose from the above general use.

[0253] ■ Opt B: another whole RACH configuration set specific to the SIB1 Auth Req. In other words, unlike the general configuration, settings for preamble / frequency / time resources for SIB1 auth requests can be provided.

[0254] Among the settings below, the information highlighted in bold can be considered as SIB1 auth req specific UL configuration.

[0255] RACH-ConfigCommon ::= SEQUENCE {

[0256] rach-ConfigGeneric RACH-ConfigGeneric,

[0257] totalNumberOfRA-Preambles INTEGER (1..63) OPTIONAL, -- Need S

[0258] ssb-perRACH-OccasionAndCB-PreamblesPerSSBCHOICE {

[0259] oneEighth ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64},

[0260] oneFourth ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64},

[0261] oneHalf ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64},

[0262] one ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64},

[0263] two ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32},

[0264] four INTEGER (1..16),

[0265] eight INTEGER (1..8),

[0266] sixteen INTEGER (1..4)

[0267] } OPTIONAL, -- Need M

[0268]

[0269] groupBconfigured SEQUENCE {

[0270] ra-Msg3SizeGroupA ENUMERATED {b56, b144, b208, b256, b282, b480, b640,

[0271] b800, b1000, b72, spare6, spare5,spare4, spare3, spare2, spare1},

[0272] messagePowerOffsetGroupB ENUMERATED { minusinfinity, dB0, dB5, dB8, dB10, dB12, dB15, dB18},

[0273] numberOfRA-PreamblesGroupA INTEGER (1..64)

[0274] } OPTIONAL, -- Need R

[0275] ra-ContentionResolutionTimer ENUMERATED { sf8, sf16, sf24, sf32, sf40, sf48, sf56, sf64},

[0276] rsrp-ThresholdSSBRSRP-Range OPTIONAL, -- Need R

[0277] rsrp-ThresholdSSB-SUL RSRP-Range OPTIONAL, -- Cond SUL

[0278] prach-RootSequenceIndex CHOICE {

[0279] l839 INTEGER (0..837),

[0280] l139 INTEGER (0..137)

[0281] },

[0282] msg1-SubcarrierSpacing SubcarrierSpacing OPTIONAL, -- Cond L139

[0283] restrictedSetConfig ENUMERATED {unrestrictedSet, restrictedSetTypeA, restrictedSetTypeB},

[0284] msg3-transformPrecoder ENUMERATED {enabled} OPTIONAL, -- Need R

[0285] ...,

[0286] [[

[0287] ra-PrioritizationForAccessIdentity-r16 SEQUENCE {

[0288] ra-Prioritization-r16 RA-Prioritization,

[0289] ra-PrioritizationForAI-r16 BIT STRING (SIZE (2))

[0290] } OPTIONAL, -- Cond InitialBWP-Only

[0291] prach-RootSequenceIndex-r16 CHOICE {

[0292] l571 INTEGER (0..569),

[0293] l1151 INTEGER (0..1149)

[0294] } OPTIONAL -- Need R

[0295] ]],

[0296] [[

[0297] ra-PrioritizationForSlicing-r17 RA-PrioritizationForSlicing-r17 OPTIONAL, -- Cond InitialBWP-Only

[0298] featureCombinationPreamblesList-r17 SEQUENCE (SIZE(1..maxFeatureCombPreamblesPerRACHResource-r17)) OF FeatureCombinationPreambles-r17 OPTIONAL -- Cond AdditionalRACH

[0299] ]]

[0300] }

[0301] 또 다른 실시 예에서,

[0302] Through SIB1 information, the terminal can receive information from the network even when not in a connected state; aside from the UL configuration for SIB1 authentication requests / responses, the terminal can selectively use only the additionally necessary information independently of the authentication request / response procedure. Basically, the majority of SIB1 information is required when connected, and since receiving all decryption-related information from the entire SIB1 causes latency due to segmentation, the terminal needs to be able to use the following information without verifying authentication via SIB1 authentication requests / responses to prevent performance degradation caused by latency while using it in idle / inactive mode. For example,

[0303] - Information for receiving paging, namely PCCH-config in servingcell config common SIB, can be used without a security check.

[0304] - The current cell's PLMN information, i.e., cellAccessRelatedInfo, is available.

[0305] - Current cell's ran area information,

[0306] - Current cell's TAC-related information

[0307] Accordingly, when the terminal receives SIB1 after receiving MIB in an idle / inactive state, the terminal may perform at least one of the following operations while verifying the validity of SIB1 authentication resulting from the SIB1 auth request and response.

[0308] - The terminal monitors the PDCCH on SIB1 and can receive corresponding paging messages through RA-RNTI.

[0309] - The terminal can obtain PLMN information of the corresponding cell.

[0310] - The terminal can obtain the ran area information of the corresponding cell.

[0311] - The terminal can obtain TA information of the corresponding cell.

[0312] In another embodiment, the information may be configured as a separate system information message or SIB, and may be used as separate system information so that the terminal does not have to perform a separate SIB auth request / response operation.

[0313] If a terminal requests some information from the system information in an auth request and the network is currently transmitting the corresponding system information as a response, the cell may transmit the corresponding system information along with a broadcast indicator in conjunction with the MIB, SIB1, or a separate SIB.

[0314] The broadcast indicator can indicate whether a MIB, SIB1, OSI, or a specific SIBx among OSI is currently broadcasting or not broadcasting. In this case, the MIB may be transmitted via the PBCH, SIB1 may be scheduled to the PDCCH and transmitted via the PDSCH, and a separate SIB may also be scheduled to the PDCCH and transmitted via the PDSCH. However, in all cases, the broadcast can be transmitted so that all camping terminals can receive it.

[0315] Such a broadcast indicator can be used when multiple terminals are camping in a cell and want to obtain integrity-protected system information of specific system information according to their needs, or want to obtain authentication information through an auth request for specific system information, by looking at the information of the broadcast indicator and, if it is broadcasting, each terminal can obtain integrity-protected system information by simply receiving the broadcasted information without transmitting individual auth request signals.

[0316] For the operation of SIB1's auth request / response, configuration information for the signal for SIB1's auth req must be provided.

[0317] In this regard, the following two are possible.

[0318] Opt 1. Send a signal to the terminal including the corresponding UL config in the MIB.

[0319] Opt 2. Send a signal to the terminal including the corresponding UL config in SIB1.

[0320] FIG. 12 is a diagram illustrating an example of a case corresponding to opt 1 among the methods for the auth req / response of SIB1 according to an embodiment of the present invention.

[0321] Referring to FIG. 12, in step 1230, the terminal (1210) can locate cell 1 (base station) (1220) and read the SSB. This SSB may contain an MIB, and the information contained in this MIB may include the information described in the previous drawings. Additionally, configuration information for the auth request signal of SIB1 may be included in the MIB.

[0322] After the terminal (1210) receives the MIB in step 1235, the terminal (1210) can obtain an integrity-unprotected SIB1 (referred to as original SIB1) in step 1240 using the PDCCH configuration information included therein. In step 1245, the terminal (1210) can verify this SIB1 and, if necessary, request an integrity-protected SIB1. Alternatively, in step 1245, the terminal (1210) may request an integrity-protected SIB1 immediately without obtaining the original SIB1.

[0323] In this case, according to the signal configuration information for the auth request of SIB1 included in the MIB, the terminal (1210) can transmit an auth request signal to the base station (1220) in step 1250. This signal may be similar to the information included in the previously described UL configuration. Additionally, the UL configuration may be instructed to the terminal (1210) that the preamble used during transmission, the frequency resource where the preamble is transmitted, and the time resource area are separated for use with SIB1. That is, upon seeing the signal transmitted from the indicated preamble and / or resource, the network (base station) (1220) recognizes that the signal is an auth request of SIB1 and can transmit an integrity-protected SIB1 to the terminal (1210). Furthermore, the UL signal transmitted by the terminal (1210) may include information requesting that the original SIB1 be included in the response message, or that it not be included. According to an embodiment, the original SIB may be included in the response message when there is no instruction from the terminal (1210), or the original SIB may not be included in the response message when there is no instruction from the terminal (1210). According to an embodiment, if the common UL setting is shared with other SI requests, the authentication request may include information indicating SIB1.

[0324] The base station (1220) that receives the above signal can construct a DS (or MAC-I) based on the PQC algorithm in step 1255 using the base station-specific private key, time information based on the time of encoding or transmission of SIB1, and information of SIB1 itself. The base station (1220) can transmit the information for decoding thus constructed (DS, signature information including a public key corresponding to the private key, time stamp information) and information including the original SIB1 (authenticated or IP (integrity protected) SIB1) to the terminal (1210) in step 1270. In another embodiment, the auth request signal transmitted by the terminal (1210) may include a request to transmit only the information for decoding excluding the original SIB1. In this case, the base station (1220) can transmit only the information for decoding excluding the original SIB1 to the terminal (1210).

[0325] According to an embodiment, in step 1260, the base station (1220) can transmit schedule information to be transmitted to the terminal (1210) via DCI in the PDCCH, including information for decoding and information including original SIB1.

[0326] If necessary, the network (1220) can perform segmentation on IP SIB1 and transmit schedule information for transmission corresponding to each segment to the terminal (1210) via DCI in the PDCCH.

[0327] The terminal (1210) monitors the PDCCH through the PDCCH configuration information included in the MIB, finds the DCI, and uses a new RNTI value (e.g., authSI-RNTI) to receive a pre-configured authentication response, thereby descrambles the schedule information for the information for decryption and the information including the original SIB1 to be transmitted from the PDSCH. According to an embodiment, if the information for decryption and the information including the original SIB1 are segmented and transmitted, the terminal (1210) can use the new RNTI value to descramble the schedule information for the segment to be transmitted from the PDSCH. Here, the new RNTI value may be set to a predetermined value in the terminal (1210). Additionally, the DCI may include not only the schedule information but also information indicating whether the segment is the last segment, how many segments the terminal (1210) should receive in total, and which segment the currently scheduled segment is.

[0328] According to the above schedule information, at step 1270, the base station (1210) can transmit integrity protected SIB1 (information including information for decoding and the original SIB1) to the terminal (1220). When the integrity protected SIB1 is transmitted in segments, the terminal (1210) can receive all segments.

[0329] A terminal (1210) that has received information including the information for decoding and the original SIB1 can restore SIB1 in step 1280 and attempt decoding according to DS and credential to perform authentication. And if valid, the information can be used. Alternatively, a terminal that has received all of the segments can assemble them to restore IP SIB1 and attempt decoding using the given decoding-related information to perform authentication.

[0330] FIG. 13 is a diagram illustrating an example of a case corresponding to opt 2 among the methods for an auth request / response of SIB1 according to an embodiment of the present invention.

[0331] In the case of option 2 exemplified in Fig. 13, all other information in SIB1 can be used after authentication is verified, but the terminal (1310) can use the auth request / response related configuration information regardless of authentication.

[0332] Referring to FIG. 13, in step 1330, the terminal (1310) can locate cell 1 (base station) (1320) and read the SSB. This SSB may contain an MIB, and the information contained in this MIB may include the information described in the previous drawings.

[0333] After the terminal (1310) receives the MIB in step 1335, the terminal (1310) can obtain an integrity-unprotected SIB1 (referred to as original SIB1) in step 1340 using the PDCCH configuration information contained therein. In step 1345, the terminal (1310) can verify this SIB1 and, if necessary, request an integrity-protected SIB1.

[0334] In this case, according to the signal configuration information for the auth request of SIB1 included in SIB1, the terminal (1310) can transmit an auth request signal to the base station (1320) in step 1350. This signal may be similar to the information included in the previously described UL configuration. Additionally, the UL configuration may be instructed to the terminal (1310) that the preamble used during transmission, the frequency resource where the preamble is transmitted, and the time resource area are separated for use with SIB1. That is, upon seeing the signal transmitted from the indicated preamble and / or resource, the network (base station) (1320) recognizes that the signal is the auth request of SIB1 and can transmit the integrity-protected SIB1 to the terminal (1310). Furthermore, the UL signal transmitted by the terminal (1310) may include information requesting that the original SIB1 be included in the response message, or requesting that it not be included. According to an embodiment, the original SIB1 may be included in the response message when there is no instruction from the terminal (1310), or the original SIB1 may not be included in the response message when there is no instruction from the terminal (1310). According to an embodiment, if the common UL setting is shared with other SI requests, the authentication request may include information indicating the SIB1.

[0335] The base station (1320) that receives the above signal can construct a DS (or MAC-I) based on the PQC algorithm in step 1355 using the base station specific private key, time information based on the time of encoding or transmission of SIB1, and information of SIB1 itself. The base station (1320) can transmit the information for decoding thus constructed (DS, signature information including a public key corresponding to the private key, time stamp information) and information including the original SIB1 (authenticated SIB1 or IP SIB1) to the terminal (1310) in step 1370. In another embodiment, the auth request signal transmitted by the terminal (1310) may include a request to transmit only the information for decoding excluding the original SIB1. In this case, the base station (1320) can transmit only the information for decoding excluding the original SIB1 to the terminal (1310).

[0336] According to an embodiment, in step 1360, the base station (1320) can transmit schedule information to be transmitted to the terminal (1310) via DCI in the PDCCH, including information for decoding and information including original SIB1.

[0337] If necessary, the network (1320) can perform segmentation on IP SIB1 and transmit schedule information for transmission corresponding to each segment to the terminal (1310) via DCI in the PDCCH.

[0338] The terminal (1310) monitors the PDCCH through the PDCCH configuration information included in the MIB or separate PDCCH configuration information for receiving IP SIB1 included in the auth req / response of SIB1, finds the DCI, and uses a new RNTI value (e.g., authSI-RNTI) to receive a pre-configured authentication response, thereby descrambles the schedule information for the transmission of information for decryption and information including the original SIB1 in the PDSCH. According to an embodiment, if the information for decryption and information including the original SIB1 are segmented and transmitted, the terminal (1310) can use the new RNTI value to descramble the schedule information for the transmission of the segment in the PDSCH. Here, the new RNTI value may be set to a predetermined value in the terminal (1310). Additionally, the DCI may include not only the schedule information but also information indicating whether the segment is the last segment, how many segments the terminal must receive in total, and which segment the currently scheduled segment is.

[0339] According to the above schedule information, at step 1370, the base station (1320) can transmit integrity protected SIB1 (information including information for decoding and the original SIB1) to the terminal (1310). When the integrity protected SIB1 is transmitted in segments, the terminal (1310) can receive all segments.

[0340] A terminal (1310) that has received information including the information for decoding and the original SIB1 can restore SIB1 in step 1380 and attempt decoding according to DS and credential to perform authentication. And if valid, the information can be used. Alternatively, a terminal that has received all of the segments can assemble them to restore IP SIB1 and attempt decoding using the given decoding-related information to perform authentication.

[0341] The drawing on the right side of FIG. 13 shows an example of IP system info. In this case, the system info (i.e., SIB1) (1391) being encoded and decoded may mean that the UL configuration information (1396) for the auth request / response of SIB1 is excluded. For example, as information required when encoding system information with a security algorithm (1394), the information (1391) excluding the UL configuration (1396) for the auth request / response from the system information, the private key (1392) assigned to the base station (1320), and the time information (1393) at the time of encoding, such as a time stamp or time counter value, may be included. Then, a MAC-I or DS (1395) is created, and the created MAC-I or DS (1395) is created as a single integrity-protected system information (1390) together with system information (1391) and time stamp information (1393) and can be transmitted from the base station (1320) to the terminal (1310). Then, the UL configuration (1396) for the auth request / response is not integrity-protected and can be transmitted to the terminal (1310) together with the integrity-protected system information (1390). Alternatively, a security algorithm (1394) can be applied to all SIB1 information and used for authentication verification, but the terminal (1310) can use the UL configuration information (1396) for the SIB1 auth request / response regardless of the authentication operation / or result.

[0342] Issue 3-C: Protection of SIBx, i.e., other system information

[0343] In the existing NR, since SIBs other than SIB1 are OSIs and are not always broadcast, SIB1 can broadcast the scheduling information and change-related indicator (valueTag) information for each OSI's SIBs. Additionally, multiple SIBs can be included within a single RRC message's system information, and this SI can be broadcast as a scheduling target. SIB1 can include the scheduling information for these SIs.

[0344] In such cases, the terminal's auth req / resp unit is as follows,

[0345] Opt 1. SIB Unit

[0346] Opt 2. SI units

[0347] There are two possible outcomes.

[0348] In the case of Opt 1, the unit of system information used by the terminal is grouped into SIBs and transmitted according to their characteristics, so the system information required for the purpose of use can be in SIB units. Accordingly, if the OSI that the terminal requires or needs to verify authentication for is SIB X, the terminal can transmit an auth request signal for the corresponding SIB X. UL configuration setting information for this can be included in SIB1.

[0349] Specific UL config information may include at least one of the following information.

[0350] - Frequency info UL: including frequency band list, absoluteFrequencyPointA, SCS for UL transmission

[0351] - Initial UL BWP info to send request signal: including generic BWP config info, OnDemandAuthConfigCommon (same IEs as in RACHConfigCommon) on this UL BWP (or if BWP is not there in 6G, then just UL frequency band)

[0352] - pdcchConfig: coreset and search space frequency and time resource location information for PDCCH reception. To receive SIB / SI message and / or DS and / or credential and / or time stamp information over PDSCH with PDCCH schedule. The above PDCCH configuration information is a configuration for receiving a response in an authentication request / response, and may be identical to the PDCCH configuration in servingCellConfigCommonSIB, or may exist as a separate configuration for the SIB1 authentication response.

[0353] - RACH-ConfigCommon for SIB based auth request,

[0354] ■ Opt A: Same configurations are shared with the normal RACH config common while featureCombinationPreambleList can have preamble sets specific to auth request purpose. That is, it can use the same resources as the RACH resources (frequency and time resources) used when a terminal wants to perform random access to a base station in idle / inactive or connection mode when necessary, but the preamble can be configured for a separate SIB-based auth request purpose from the above general use.

[0355] ■ Opt B: another whole RACH configuration set specific to the SIB-based Auth Req. In other words, unlike the general configuration, settings for preamble / frequency / time resources for SIB-based auth requests can be provided.

[0356] Additionally, if the above RACH-configcommon is intended for SIB-based authentication requests, the corresponding preamble / frequency / time resources may be separately allocated according to the SIB type scheduled in SIB1 and instructed to the terminal. Based on this information, when the terminal performs an authentication request for a specific SIB, it may transmit a signal following the RACH settings specialized for that SIB. In this case, there may be a disadvantage in that RACH resources become too granular depending on the type of SIB being operated or broadcast. Opposite to this is opt 2.

[0357] FIG. 14 is a diagram illustrating an example of a case corresponding to opt 1 among the methods for an OSI request auth req / response according to an embodiment of the present invention.

[0358] Referring to FIG. 14, at step 1430, the terminal (1410) can locate cell 1 (base station) (1420) and read the SSB. This SSB may contain an MIB, and the information contained in this MIB may include the information described in the previous drawings.

[0359] After the terminal (1410) receives the MIB in step 1435, the terminal (1410) can obtain SIB1 in step 1440 using the PDCCH configuration information contained therein. In step 1445, the terminal (1410) can obtain OSI schedule information from the obtained SIB1. Through the schedule information, an integrity-unprotected SIBx (referred to as the original SIBx) can be obtained. The terminal (1410) can verify this SIBx and, if necessary, request an integrity-protected SIBx. Alternatively, the terminal (1410) can request an integrity-protected SIBx immediately without obtaining the original SIBx. Depending on the embodiment, authentication of SIB1 may be performed if necessary.

[0360] In this case, according to the signal configuration information for each SIB type associated with the schedule information for each SI of SIB1, the terminal (1410) can transmit an auth req signal to the base station (1420) in step 1450. This signal may be similar to the information included in the previously described UL configuration. Upon seeing the signal transmitted to the indicated preamble and / or resource, the network (base station) (1420) recognizes that the signal is an auth req for SIBx and can transmit an integrity-protected SIBx to the terminal (1410). Additionally, the UL signal transmitted by the terminal (1410) may include information requesting that the original SIBx be included in the response message or not included. According to the embodiment, the original SIBx may be included in the response message in the absence of instructions from the terminal (1410), or the original SIBx may not be included in the response message in the absence of instructions from the terminal. According to an embodiment, information indicating SIBx may be included in the authentication request message.

[0361] The base station (1420) that receives the above signal can construct a DS (or MAC-I) based on the PQC algorithm in step 1455 using the SIBx, the base station specific private key, time information based on the time of encoding or transmission of the SIBx, and information of the SIBx itself. The base station (1420) can transmit the information for decoding thus constructed (DS, signature information including a public key corresponding to the private key, time stamp information) and information including the original SIBx (authenticated SIBx or IP SIBx) to the terminal (1410) in step 1470. In another embodiment, the auth request signal transmitted by the terminal (1410) may include a request to transmit only the information for decoding excluding the original SIBx. In this case, the base station (1420) can transmit only the information for decoding excluding the original SIBx to the terminal (1410).

[0362] According to an embodiment, in step 1460, the base station (1420) can transmit schedule information to be transmitted to the terminal (1410) via DCI in the PDCCH, including information for decoding and information including the original SIBx.

[0363] If necessary, the network (1420) can perform segmentation on the IP SIBx and transmit schedule information for transmission corresponding to each segment to the terminal (1410) via DCI in the PDCCH.

[0364] In step 1465, the terminal (1410) monitors the PDCCH through the PDCCH configuration information contained in the MIB or SIB1, finds the DCI, and uses a new RNTI value (e.g., authSI-RNTI) to receive a preset authentication response, thereby descrambles the schedule information for the information including the decryption information and the original SIBx to be transmitted from the PDSCH. According to an embodiment, if the information including the decryption information and the original SIBx is segmented and transmitted, the terminal (1410) can use the new RNTI value to descramble the schedule information for the segment to be transmitted from the PDSCH. Here, the new RNTI value may be set to a predetermined value in the terminal (1410). Additionally, the DCI may include not only the schedule information but also information indicating whether the segment is the last segment, how many segments the terminal must receive in total, and which segment the currently scheduled segment is.

[0365] According to the above schedule information, at step 1470, the base station (1420) can transmit integrity protected SIBx (information including information for decoding and the original SIBx) to the terminal (1410). When the integrity protected SIBx is transmitted in segments, the terminal (1410) can receive all segments.

[0366] A terminal (1410) that has received information including the information for decoding and the original SIBx can restore the SIBx at step 1480 and attempt decoding according to the DS and credential to perform authentication. And if valid, the information can be used. Alternatively, a terminal (1410) that has received all of the segments can assemble them to restore the IP SIBx and attempt decoding using the given decoding-related information to perform authentication.

[0367] The drawing on the right side of FIG. 14 illustrates an example of IP system information. For example, when encoding system information (SIBx) (1491) with a security algorithm (1494), the information required may include system information (1491), a private key (1492) assigned to the base station (1420), and time information (1493) at the time of encoding, such as a time stamp or time counter value. Then, a MAC-I or DS (1495) is created, and the created MAC-I or DS (1495) is created together with the system information (1491) and the time stamp information (1493) as a single integrity protected system information (1490) and can be transmitted from the base station (1420) to the terminal (1410).

[0368] In the case of Opt 2, an auth request can be performed for each SI message. If a terminal needs specific SIB information or if the SIB needs to verify authentication, it can make an auth request by directing the SI message scheduled by the SIB. UL configuration settings for this can be included in SIB1.

[0369] Specific UL config information may include at least one of the following information.

[0370] - Frequency info UL: including frequency band list, absoluteFrequencyPointA, SCS for UL transmission

[0371] - Initial UL BWP info to send request signal: including generic BWP config info, OnDemandAuthConfigCommon (same IEs as in RACHConfigCommon) on this UL BWP (or if BWP is not there in 6G, then just UL frequency band)

[0372] - RACH-ConfigCommon for SI based auth request,

[0373] ■ Opt A: Same configurations are shared with the normal RACH config common while featureCombinationPreambleList can have preamble sets specific to auth request purpose. That is, it can use the same resources as the RACH resources (frequency and time resources) used when a terminal wants to perform random access to a base station in idle / inactive or connection mode when necessary, but the preamble can be configured for SI-based auth request purposes separate from the above general use.

[0374] ■ Opt B: another whole RACH configuration set specific to the SI based Auth Req. In other words, unlike the general configuration, settings for preamble / frequency / time resources for SI based auth requests can be provided.

[0375] Additionally, if the above RACH-configcommon is for an SI-based auth request, the corresponding preamble / frequency / time resources may be separately allocated according to the SI scheduled in SIB1 and instructed to the terminal. Based on this information, when the terminal performs an auth request for a specific SI, it may transmit a signal according to the RACH settings specialized for that SI. To this end, the above RACH resource information may be added for each SI message according to the scheduling information of SIB1. For example, in the OSI scheduling information existing in SIB1 of the NR below, RACH setting information may be included in SchedulingInfo, which represents a single SI.

[0376] Alternatively, based on the order (1 to N) of scheduled SIs in SI-SchedulingInfo, RACH resources can be separated and configured according to the SIs in order 1 to N. In this case, the terminal transmits an auth request signal through a separate resource provided for the SI in the desired order, and the network can identify the order and the corresponding SI request target by checking the resource. The order of the SIs may be configured regardless of the current broadcast status, or requests may be made only to SIs that are currently in a broadcasting state.

[0377] SI-SchedulingInfo ::= SEQUENCE {

[0378] schedulingInfoListSEQUENCE (SIZE (1..maxSI-Message)) OF SchedulingInfo,

[0379] si-WindowLength ENUMERATED {s5, s10, s20, s40, s80, s160, s320, s640, s1280, s2560-v1710, s5120-v1710},

[0380] si-RequestConfig SI-RequestConfig OPTIONAL, -- Cond MSG-1

[0381] si-RequestConfigSUL SI-RequestConfig OPTIONAL, -- Cond SUL-MSG-1

[0382] systemInformationAreaID BIT STRING (SIZE (24)) OPTIONAL, -- Need R

[0383] ...

[0384] }

[0385]

[0386] SchedulingInfo ::= SEQUENCE {

[0387] si-BroadcastStatus ENUMERATED {broadcasting, notBroadcasting},

[0388] si-Periodicity ENUMERATED {rf8, rf16, rf32, rf64, rf128, rf256, rf512},

[0389] sib-MappingInfo SIB-Mapping

[0390] }

[0391] In an additional embodiment, only the SIs broadcasting in this SchedulingInfo may be selectively considered as SI-based auth req / resp targets, and the corresponding RACH settings may be assigned to instruct the terminal.

[0392] Alternatively, the RACH configuration may be assigned at the SIBx level, just like opt 1. Accordingly, the terminal may indicate the SIBx when making an auth request, and the network may perform broadcasting in SI units including the SIBx.

[0393] The cell (base station) that receives the above signal can broadcast the requested SI. At this time, by transmitting the DS, timer stamp, and public key values ​​together, the terminal can confirm that the corresponding SIB has been authenticated.

[0394] FIG. 15 is a diagram illustrating an example of a case corresponding to opt 2 among the methods for an OSI request auth req / response according to an embodiment of the present invention.

[0395] Referring to FIG. 15, at step 1530, the terminal (1510) can locate cell 1 (base station) (1520) and read the SSB. The SSB may contain an MIB, and the information contained in the MIB may include the information described in the previous drawings.

[0396] After the terminal (1510) receives the MIB at step 1535, the terminal (1510) can obtain SIB1 at step 1540 using the PDCCH configuration information included therein. At step 1545, the terminal (1510) can obtain OSI schedule information from the obtained SIB1. At step 1550, the terminal (1510) can obtain an integrity-unprotected SIBx (referred to as the original SIBx) through the schedule information. At step 1555, the terminal (1510) checks this SIBx and, if necessary, can request an integrity-protected SIBx. Alternatively, the terminal (1510) can directly request an integrity-protected SIBx without obtaining the original SIBx. For this request, the actual auth request can be performed at the SI message level including the corresponding SIBx. Depending on the embodiment, authentication of SIB1 may be performed if necessary.

[0397] In this case, the terminal (1510) may transmit an auth request signal to the base station (1520) in step 1560 according to the signal setting information for the auth request associated with the schedule information for each SI of SIB1 or the signal setting information for the auth request according to the SIB type included within each SI. This signal may be similar to the information included in the previously described UL configuration. Upon seeing the signal transmitted to the indicated preamble and / or resource, the network (base station) (1520) may recognize that the signal is an auth request of (a) SIBx or (b) an SI containing SIBx. Then, the base station (1520) may (a) schedule and transmit an SI containing the SIBx and other SIBy to the terminal (1510), or (b) schedule and transmit an SI containing the SIBy as it was when transmitting the original SIBx to the terminal (1510). At this time, an integrity protected SI can be transmitted at the transmitted SI level. Additionally, the UL signal transmitted by the terminal (1510) may include information requesting that the original SI be included in the response message or not included. According to an embodiment, the original SI may be included in the response message when there is no instruction from the terminal (1510), or the original SI may not be included in the response message when there is no instruction from the terminal (1510).

[0398] The base station (1520) that receives the above signal can construct a DS (or MAC-I) based on the PQC algorithm in step 1565 using the SI, the base station specific private key, time information based on the time of encoding of the SI or the time of transmission of the SI, and information of the SI itself. The base station (1520) can transmit the information for decoding thus constructed (DS, signature information including a public key corresponding to the private key, time stamp information) and information including the original SI (IP SIBx or IP SI) to the terminal (1510) in step 1580. In another embodiment, the auth request signal transmitted by the terminal (1510) may include a request to transmit only the information for decoding excluding the original SI. In this case, the base station (1520) can transmit only the information for decoding excluding the original SI to the terminal (1510).

[0399] According to an embodiment, in step 1570, the base station (1520) can transmit schedule information to be transmitted to the terminal (1510) via DCI in the PDCCH, including information for decoding and information including the original SI.

[0400] If necessary, the network (1520) can perform segmentation on IP SIBx or IP SI and transmit schedule information for transmission corresponding to each segment to the terminal (1510) via DCI in the PDCCH.

[0401] In step 1575, the terminal (1510) monitors the PDCCH through the PDCCH configuration information contained in the MIB or SIB1, finds the DCI, and uses a new RNTI value (e.g., authSI-RNTI) to receive a pre-configured authentication response, thereby descrambles the schedule information for the information including the information for decryption and the original SI to be transmitted from the PDSCH. According to an embodiment, if the information including the information for decryption and the original SI is segmented and transmitted, the terminal (1510) can use the new RNTI value to descramble the schedule information indicating that the segment is transmitted from the PDSCH. Here, the new RNTI value may be set to a predetermined value in the terminal (1510). Additionally, the DCI may include not only the schedule information but also information indicating whether the segment is the last segment, how many segments the terminal (1510) should receive in total, and which segment the currently scheduled segment is.

[0402] According to the above schedule information, at step 1480, the base station (1520) can transmit integrity protected SI (information including information for decoding and original SI) to the terminal (1510). When the integrity protected SI is transmitted in segments, the terminal (1510) can receive all segments.

[0403] A terminal (1510) that has received information including the information for decoding and the original SI can restore the SI in step 1585 and attempt decoding according to the DS and credential to perform authentication. Alternatively, a terminal (1510) that has received all of the segments can assemble them to restore the IP SI and attempt decoding using the given decoding-related information to perform authentication.

[0404] If the SI is authenticated, the terminal (1510) assumes that the information of the SIBx contained within the SI is authenticated and can use the information of the SIBx.

[0405] The drawing on the right side of FIG. 15 illustrates an example of IP SI. For example, when encoding a system information message (SIBx+SIBy) (1591) with a security algorithm (1594), the information required may include the system information message (SIBx+SIBy) (1591), a private key (1592) assigned to the base station (1450), and time information (1593) at the time of encoding, such as a time stamp or time counter value. Then, a MAC-I or DS (1595) is created, and the created MAC-I or DS (1595) is created together with the system information message (SIBx+SIBy) (1591) and the time stamp information (1593) as a single integrity protected system information (1590) and can be transmitted from the base station (1520) to the terminal (1510).

[0406] For all system information of MIB, SIB1, and OSI, upon an on-demand request, the terminal may request the base station to transmit the original system information and decryption information for authentication verification together, or the terminal may request the base station to transmit only the decryption information for authentication verification. When setting up for the transmission of an Auth request signal, the base station separates the RACH resources according to the two cases above and sets them for the terminal, and the terminal can transmit the Auth request signal according to the set RACH resources.

[0407] In addition, the UL configuration for authentication request / response for MIB, SIB1, OSI's SIB, or SI in the previous embodiments may include a DL configuration used when receiving an authentication response message / signal in response to the authentication request. This DL configuration may include at least one of the following: time and frequency location information of a control resource and search space for receiving a PDCCH, SCS, associated SSB ID information, and time and frequency location information of a resource of a PDSCH associated with the PDCCH. If the DL configuration information exists in the authentication request / response information, the terminal can monitor the PDCCH based on the configuration to obtain scheduling information from the necessary DCI to the PDSCH, and receive the necessary response data therefrom.

[0408] Issue 4: Segment Transmission Method

[0409] FIG. 16 is a diagram illustrating an example of a case corresponding to opt 1 among the segment transmission methods of OSI according to an embodiment of the present invention.

[0410] When the terminal (1610) receives the SIB, it may contain only a part or one of the segments. For example, the SIB segment may consist of three pieces of information, such as a number indicating which segment it is, a type indicating whether the segment is the last segment, and a container containing actual information. After receiving the segment of the SIB, the terminal (1610) decodes it and receives all the segment fragments. Once the final segment is received, the terminal can combine the information of each segment's container in order to construct the final SIB.

[0411] In the case of OSI, since a specific SIBx becomes an SI unit during transmission, a segment can also be transmitted by including the segment of the SIBx in the SI when opt 1. Alternatively, depending on the transmission capacity, a specific segment of the SIBx and other SIB types can be transmitted by including them in a single SI. Additionally, the SI in which the segment is transmitted may contain at least one of all segments, and the SI may include a DS capable of decrypting the corresponding SIBx, time stamp information, and credential information containing a public key.

[0412] Referring to FIG. 16, the network (1620) may transmit only the segment of the requested SIB in a single SI transmitted at once as needed, or transmit the segment along with other SIBs. This can be selectively considered in accordance with the request situation of the terminal (1610) and the transmission period of each SIB in the network (1620). Of course, in this case, the SIB type and periodicity included in each SI transmission may be given in advance as schedule information to SIB1.

[0413] To look more specifically, referring to FIG. 16, at step 1630, the terminal (1610) can locate cell 1 (base station) (1620) and read the SSB. This SSB may contain an MIB, and the information contained in this MIB may include the information described in the previous drawings.

[0414] After the terminal (1610) receives the MIB, it can obtain SIB1 in step 1635 using the PDCCH configuration information included therein. The terminal (1610) can obtain OSI schedule information from the obtained SIB1. Through the schedule information, it can obtain an integrity-unprotected SIBx (referred to as the original SIBx). In step 1640, the terminal (1610) checks this SIBx and, if necessary, requests an integrity-protected SIBx. Alternatively, the terminal (1610) can directly request an integrity-protected SIBx in step 1640 without obtaining the original SIBx. For this request, the actual auth request can be performed at the SI message level including the corresponding SIBx.

[0415] In this case, the terminal (1610) may transmit an auth request signal to the base station (1620) in step 1640 according to the signal setting information for the auth request associated with the schedule information for each SI of SIB1 or the signal setting information for the auth request according to the SIB type included within each SI. This signal may be similar to the information included in the previously described UL configuration. Upon seeing the signal transmitted to the indicated preamble and / or resource, the network (base station) (1620) may recognize that the signal is (a) an auth request of a SIBx or (b) an auth request of an SI containing a SIBx. Then, the base station (1620) may (a) schedule and transmit an SI containing the SIBx and another SIBy to the terminal (1610), or (b) schedule and transmit an SI containing the SIBy as it was originally transmitted when the SIBx was transmitted.

[0416] The base station (1620) that receives the above auth request signal can construct a DS (or MAC-I) based on the PQC algorithm using the base station-specific private key, time information based on the time of encoding or transmission of the SIBx, and information of the SI itself. The base station (1620) can transmit information for decoding thus constructed (DS, signature information including a public key corresponding to the private key, time stamp information) and information including the original SIBx to the terminal (1610). Although not illustrated, the base station (1620) can transmit schedule information for the transmission of the SIBx to the terminal (1610) via the DCI in the PDCCH.

[0417] The base station (1620) can perform segmentation on the integrity protected SIBx to be transmitted in step 1645. According to an embodiment, the segmentation may be performed according to the period of the SIBx to be transmitted. That is, the segmentation may be performed based on the same period as the SIBx for the configuration of the SI.

[0418] In steps 1650, 1660, and 1670, the base station (1620) can transmit the segmented SIBx to the terminal (1610) in accordance with the corresponding transmission cycle. And the terminal (1610) can store the segments received in steps 1655, 1665, and 1675.

[0419] For example, if SIBx (e.g., SIB7) is divided into three segments, in step 1650, the base station (1620) can transmit the first segment of SIBx to the terminal (1610) as an SI message. The SI message may include a DS that can decrypt the SIBx, time stamp information, and credential information including a public key.

[0420] And at step 1660, the base station (1620) may transmit to the terminal (1610) a second segment in the next cycle, including the second segment in the SI message, according to the transmission cycle of the SIBx. According to an embodiment, information capable of decoding the SIBx may be transmitted along with the second segment.

[0421] And in step 1670, in the next transmission cycle, the base station (1620) can transmit the last segment to the terminal (1610) via an SI message. According to an embodiment, information capable of decoding SIBx may be transmitted along with the last segment. According to an embodiment, if there is another SIBy (e.g., SIB8, SIB11, etc.) with the same transmission cycle as SIBx and it needs to be transmitted, the base station (1620) may include the SIBy, etc. in the SI message and transmit it to the terminal (1610), taking into consideration the transmission resources of the SI message.

[0422] The terminal (1610) that has received all segments can perform authentication by assembling them in step 1675 to restore the IP SIBx and attempting to decrypt using the given decryption-related information.

[0423] Below FIG. 16, an example of the configuration of integrity protected system information (1690) is illustrated. The integrity protected system information (1690) may include a system information source (SIBx) (1695), a private key assigned to a base station (1620), and time information (1694) at the time of encoding, such as a time stamp or time counter value, MAC-I, or Digital signature (DS) (1696). This integrity protected system information (1690) may be segmented (1691, 1692, 1693) and transmitted to a terminal (1610).

[0424] FIG. 17 is a diagram illustrating an example of a case corresponding to opt 2 among the segment transmission methods of OSI according to an embodiment of the present invention.

[0425] In OSI opt 2, the target of the segment may be an SI. In that case, each SI segment may consist of a segment number, a type, and a container, and after all segments are received, the terminal (1710) may combine the segments to form a final SI. Likewise, in this case, at least one SI transmission unit that transmits including the corresponding SI segment may include a DS for decoding the SI, time stamp information, and credential information including a public key. This case may be useful in contrast to opt 1 when the terminal (1710) has a demand for system information that is scheduled for a group of SIBs rather than individual SIBs. That is, SIBx and SIBy are included and transmitted within the SI, and when the terminal (1710) wants to use SIBx, if there is a continuous occurrence of using SIBy as well, performing an auth request / response based on the same SI rather than performing an auth request / response for each SIB can ensure the saving of signaling overhead and wireless resources.

[0426] To look more specifically, with reference to FIG. 17, at step 1730, the terminal (1710) can locate cell 1 (base station) (1720) and read the SSB. This SSB may contain an MIB, and the information contained in this MIB may include the information described in the previous drawings.

[0427] After the terminal (1710) receives the MIB, it can obtain SIB1 in step 1735 using the PDCCH configuration information included therein. The terminal (1710) can obtain OSI schedule information from the obtained SIB1. Through the schedule information, it can obtain an integrity-unprotected SIBx (referred to as the original SIBx). In step 1740, the terminal (1710) checks this SIBx and, if necessary, requests an integrity-protected SIBx. Alternatively, the terminal (1710) can directly request an integrity-protected SIBx in step 1740 without obtaining the original SIBx. For this request, the actual auth request can be performed at the SI message level including the corresponding SIBx.

[0428] In this case, the terminal (1710) may transmit an auth request signal to the base station (1720) in step 1740 according to the signal configuration information for the auth request associated with the schedule information for each SI of SIB1 or the signal configuration information for the auth request according to the SIB type included within each SI. This signal may be similar to the information included in the previously described UL configuration. Upon seeing the signal transmitted to the indicated preamble and / or resource, the network (base station) (1720) may recognize that the signal is an auth request of (a) SIBx or (b) an SI containing SIBx. Then, the base station (1720) may (a) schedule and transmit an SI containing the corresponding SIBx and another SIBy to the terminal (1710), or (b) schedule and transmit an SI containing the original SIBy as it was when transmitting the SIBx. At this time, an integrity protected SI may be transmitted at the level of the transmitted SI. In the case of the above authentication request, the SI sequence or SI message ID of SI-SchedulingInfo may be included.

[0429] The base station (1720) that receives the above auth request signal can construct a DS (or MAC-I) based on the PQC algorithm using the SI, the base station specific private key, time information based on the time of encoding or transmission of the SI, and information about the SI itself. The base station (1720) can transmit information for decoding thus constructed (DS, signature information including a public key corresponding to the private key, time stamp information) and information including the original SI to the terminal (1710). Although not illustrated, the base station (1720) can transmit schedule information for the transmission of the SI to the terminal (1710) via DCI in the PDCCH.

[0430] The base station (1720) can perform segmentation on the integrity-protected SI message to be transmitted. According to an embodiment, the segmentation may be performed according to the period of the SI to be transmitted. The system information included in the SI message to be transmitted may correspond to the SI sequence of the SI-SchedulingInfo or the SI message ID.

[0431] In steps 1750, 1760, and 1770, the base station (1720) can transmit the segmented SIs to the terminal (1710) in accordance with the corresponding transmission cycle. And the terminal (1710) can store the segments received in steps 1755, 1765, and 1775.

[0432] For example, if the SI is divided into three segments, at step 1750, the base station (1720) can transmit the first segment of the SI to the terminal (1710). The SI message may include a DS that can decrypt the SI, time stamp information, and credential information including a public key.

[0433] And at step 1760, the base station (1720) can transmit a second segment in the next cycle to the terminal (1710) according to the transmission cycle of SI. According to an embodiment, information capable of decoding SI may be transmitted along with the second segment.

[0434] And in step 1770, in the next transmission cycle, the base station (1720) can transmit the last segment to the terminal (1710). According to an embodiment, information capable of decoding SI may be transmitted along with the last segment.

[0435] The terminal (1710) that has received all segments can assemble them in step 1775 to restore the IP SI and attempt to decode using the given decoding information to perform authentication.

[0436] Below FIG. 17, an example of the configuration of integrity protected system information (1790) is illustrated. The integrity protected system information (1790) may include a system information message source (SIBx, SIBy, SIBz) (1795), a private key assigned to a base station (1720), and time information (1794) at the time of encoding, such as a time stamp or time counter value, MAC-I, or Digital signature (DS) (1796). This integrity protected system information (1790) may be segmented (1791, 1792, 1793) and transmitted to a terminal (1790).

[0437] As in the case of FIG. 17, the IP system information referred to in the specification of the present invention, namely integrity-protected system information, may be viewed as a single block of information or message including original system information, time stamp information, DS, and credential information. Alternatively, depending on the embodiment, IP system information may mean that it includes at least some of the original system information, time stamp information, DS, and credential information. For example, IP system information may mean only the original system information, time stamp information, and DS. The key point is that the base station derives the DS using the PQC algorithm with the original system information, time stamp information, and a base station-specific private key, and when the base station transmits a response to an authentication request, it transmits the original system information, time stamp information, DS, and credential information, regardless of how the IP system information is defined. IP system information may be defined as an information unit at an intermediate stage.

[0438] Methods according to the embodiments described in the claims or specification of the present invention may be implemented in the form of hardware, software, or a combination of hardware and software.

[0439] When 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 are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present invention.

[0440] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, ROM (Read Only Memory), Electrically Erasable Programmable Read Only Memory (EEPROM), magnetic disc storage devices, Compact Disc-ROM (CD-ROM), Digital Versatile Discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

[0441] In addition, the above program may be stored on an attachable storage device that can be accessed via a communication network such as the Internet, Intranet, Local Area Network (LAN), Wide LAN (WLAN), or Storage Area Network (SAN), or a combination thereof. Such a storage device may be connected to a device performing an embodiment of the present invention through an external port. Additionally, a separate storage device on a communication network may be connected to a device performing an embodiment of the present invention.

[0442] In the specific embodiments of the present invention described above, the components included in the invention are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present invention is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed in the singular form, or even if a component is expressed in the singular form, it may be composed in the plural form.

[0443] Meanwhile, although specific embodiments have been described in the detailed description of the present invention, it is understood that various modifications are possible within the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

Claims

1. A method performed by a terminal of a wireless communication system, A step for determining whether authentication of system information is required; If authentication of the above system information is required, a step of transmitting a request message requesting authentication of the above system information to a base station; and A method comprising the step of receiving security-applied system information corresponding to the above system information from the base station.

2. In Paragraph 1, A method characterized in that uplink configuration information for transmitting the above request message is configured based on at least one of information configured from a core network entity, a master information block (MIB), or a system information block 1 (SIB1).

3. In Paragraph 1, A method characterized in that the above system information includes at least one of MIB (master information block), SIB1 (system information block 1), or OSI (other system information).

4. In claim 1, the security-applied system information is, A method characterized by including at least one of signature information including time information regarding the time of encoding the system information, a MAC-I (Message Authentication Code-Integrity) or DS (Digital signature) generated based on a PQC (post quantum cryptography) algorithm applied to the system information, and a public key corresponding to the private key of the base station.

5. In Paragraph 1, The above-mentioned security-applied system information is received in units of system information blocks (SIBs) or system information messages (SIs), and A method characterized by receiving the above-mentioned security-applied system information in a divided manner.

6. In a terminal of a wireless communication system, Transmitter / receiver; and Determine whether authentication of system information is required, and If authentication of the above system information is required, a request message requesting authentication of the above system information is transmitted to the base station through the above transceiver, and A terminal comprising a control unit that receives security-applied system information corresponding to the above system information from the base station through the transmission and reception unit.

7. In Paragraph 6, A terminal characterized in that the uplink configuration information for transmitting the above request message is configured based on at least one of information configured from a core network entity, a master information block (MIB), or a system information block 1 (SIB1).

8. In Paragraph 6, A terminal characterized in that the above system information includes at least one of MIB (master information block), SIB1 (system information block 1), or OSI (other system information).

9. In Paragraph 6, the security-applied system information is, A terminal characterized by including at least one of signature information including time information regarding the time of encoding the above-mentioned system information, a MAC-I (Message Authentication Code-Integrity) or DS (Digital signature) generated based on a PQC (post quantum cryptography) algorithm applied to the above-mentioned system information, and a public key corresponding to the private key of the above-mentioned base station.

10. In Paragraph 6, The above-mentioned security-applied system information is received in units of system information blocks (SIBs) or system information messages (SIs), and A terminal characterized by receiving the above-mentioned security-applied system information in a divided manner.

11. In a base station of a wireless communication system, Transmitter / receiver; and If authentication of system information is required, a request message requesting authentication of the system information is received from the terminal through the transmission and reception unit, and A security algorithm is applied to the above system information to generate secure system information, and A base station comprising a control unit that transmits the security-applied system information corresponding to the above system information to the terminal through the transmission and reception unit.

12. In Paragraph 11, A base station characterized in that uplink configuration information for transmitting the above request message is configured in the terminal based on at least one of information configured from a core network entity, a master information block (MIB), or a system information block 1 (SIB1).

13. In Paragraph 11, A base station characterized by the above system information including at least one of MIB (master information block), SIB1 (system information block 1), or OSI (other system information).

14. In claim 11, the security-applied system information is, A base station characterized by including at least one of signature information including time information regarding the time of encoding the above-mentioned system information, a MAC-I (Message Authentication Code-Integrity) or DS (Digital signature) generated based on a PQC (post quantum cryptography) algorithm applied to the above-mentioned system information, and a public key corresponding to the private key of the base station.

15. In Paragraph 11, The above-mentioned security-applied system information is transmitted in units of system information blocks (SIBs) or system information messages (SIs), and A base station characterized by the fact that the above-mentioned security-applied system information is divided and transmitted.

Images