Method and apparatus for security key update in wireless communication system
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SAMSUNG ELECTRONICS CO LTD
- Filing Date
- 2024-12-31
- Publication Date
- 2026-08-07
AI Technical Summary
[0034] This disclosure provides efficient communication methods in wireless communication systems.
Smart Images

Figure CN122536192A_ABST
Abstract
Description
Technical Field
[0001] This disclosure generally relates to wireless communication systems, and more specifically, to methods and apparatus for updating security keys in wireless communication systems. Background Technology
[0002] 5G mobile communication technology defines a wide frequency band, enabling high transmission rates and new services. It can be implemented not only in "sub-6GHz" bands such as 3.5GHz, but also in "above 6GHz" bands, including 28GHz and 39GHz, known as mmWave. Furthermore, 6G mobile communication technology (referred to as "super 5G systems") is being considered in terahertz bands (e.g., the 95GHz to 3THz band) to achieve transmission rates fifty times faster than 5G and ultra-low latency one-tenth that of 5G.
[0003] At the outset of 5G mobile communication technology development, standardization was underway regarding the following aspects to support services and meet performance requirements for enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine-type communication (mMTC): beamforming and massive MIMO to mitigate radio wave path loss and increase radio wave transmission distance in millimeter waves; parameter sets supporting dynamic operation for efficient utilization of millimeter wave resources and time slot formats (e.g., operating multiple subcarrier spacings); initial access technologies to support multi-beam transmission and broadband; the definition and operation of BWP (bandwidth portion); new channel coding methods such as LDPC (low-density parity-check) codes for large-volume data transmission and polar codes for highly reliable transmission of control information; L2 preprocessing; and network slicing for providing dedicated networks for specific services.
[0004] Currently, given the services that 5G mobile communication technology needs to support, discussions are underway regarding improvements and performance enhancements to the initial 5G mobile communication technology. Physical layer standardization already exists for technologies such as V2X (Vehicle-to-Everything), NR-U (New Radio Unlicensed), NR UE power saving, Non-Terrestrial Networks (NTN), and positioning. V2X (Vehicle-to-Everything) is used to assist autonomous vehicles in making driving decisions and enhancing user convenience based on vehicle location and status information transmitted by the vehicle. NR-U (New Radio Unlicensed) aims to comply with the system operation requirements related to various regulations in unlicensed frequency bands. Non-Terrestrial Networks (NTN) is UE-satellite direct communication used to provide coverage in areas where communication with terrestrial networks is impossible.
[0005] In addition, standardization is underway for air interface architectures / protocols for technologies such as: Industrial Internet of Things (IIoT) for supporting new services through interoperability and convergence with other industries; IAB (Integrated Access and Backhaul) for providing nodes for network service area extension by supporting wireless backhaul and access links in an integrated manner; mobility enhancements including conditional handover and DAPS (Dual Active Stack) handover; and two-step random access (2-step RACH for NR) for simplifying the random access process. Standardization is also underway for system architectures / services such as: 5G baseline architectures (e.g., service-based architectures or service-based interfaces) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies; and Mobile Edge Computing (MEC) for UE location-based reception services.
[0006] With the commercialization of 5G mobile communication systems, the number of connected devices will increase exponentially, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of connected devices. To this end, new research has been initiated related to: effectively supporting extended reality (XR) such as AR (Augmented Reality), VR (Virtual Reality), and MR (Mixed Reality); improving 5G performance and reducing complexity by leveraging artificial intelligence (AI) and machine learning (ML); AI service support; metaverse service support; and drone communication.
[0007] Furthermore, this development of 5G mobile communication systems will not only lay the foundation for the development of technologies such as: new waveforms for providing coverage in the terahertz band of 6G mobile communication technology; multi-antenna transmission technologies such as full-dimensional multiple-input multiple-output (FD-MIMO); array antennas and massive MIMO; metamaterial-based lenses and antennas for improving terahertz band signal coverage; high-dimensional spatial multiplexing technologies using orbital angular momentum (OAM); and reconfigurable smart surfaces (RIS); but also for the development of technologies such as: full-duplex technologies for improving the frequency efficiency of 6G mobile communication technology and improving system networks; AI-based communication technologies for system optimization by leveraging satellites and artificial intelligence (AI) from the design stage and internalizing end-to-end AI support functions; and next-generation distributed computing technologies for enabling complex services beyond the computing power limitations of UEs by utilizing ultra-high-performance communication and computing resources.
[0008] The descriptions set forth in the Background section should not be assumed to be prior art simply because they are set forth in the Background section. The Background section may describe aspects or embodiments of this disclosure. Summary of the Invention
[0009] Technical issues
[0010] This disclosure relates to methods and apparatus for updating security keys in wireless communication systems.
[0011] Solution to the problem
[0012] This disclosure provides efficient communication methods in wireless communication systems.
[0013] One aspect of this disclosure provides a user equipment (UE) for facilitating communication in a wireless network. The UE includes a transceiver configured to: receive master security key update information for one or more candidate cells from a serving cell; and receive a command from the serving cell indicating that a cell transition from the serving cell to a target cell among the one or more candidate cells has been triggered. The UE includes a processor operatively coupled to the transceiver. The processor is configured to: perform a cell transition from the serving cell to the target cell; and perform a security update for the target cell based on the master security key update information associated with the target cell.
[0014] In some embodiments, the transceiver is further configured to receive the master security key update identifier of each candidate cell from the serving cell. The processor is also configured to: maintain a variable for storing the master security key update identifier of the service cell; and perform a security update based on determining that the master security key update identifier of the target cell differs from the master security key update identifier of the serving cell stored in the variable.
[0015] In some embodiments, the processor is further configured to replace the master security key update identifier stored in the variable with the master security key update identifier of the target cell.
[0016] In some embodiments, the transceiver is further configured to receive a list including one or more entries for the master security update information of the respective candidate cells. Each entry includes master security key update information.
[0017] In some embodiments, the processor is configured to perform a security update based on a master security key update information in a predetermined entry or indicated entry in a list of master security update information associated with the target unit.
[0018] In some embodiments, the processor is also configured to remove predetermined or indicated entries from a list of primary security update information associated with the target cell.
[0019] In some embodiments, the command includes a primary security update information identifier associated with the target cell, and a security update is performed based on the primary security update information identified by the primary security update information identifier.
[0020] In some embodiments, primary security update information associated with the target cell is included in the command, and security updates for the target cell are performed based on the primary security update information.
[0021] In some embodiments, the master security key update information includes a first field indicating whether the UE needs to export a new master security key, and a second field containing parameters for exporting the new master security key.
[0022] One aspect of this disclosure provides a method performed by a user equipment (UE) in a wireless network. The method includes: receiving master security key update information for one or more candidate cells from a serving cell; receiving a command from the serving cell indicating that a cell handover is triggered from the serving cell to a target cell among the one or more candidate cells; performing the cell handover from the serving cell to the target cell; and performing a security update for the target cell based on the master security key update information associated with the target cell.
[0023] In some embodiments, the method further includes: receiving a master security key update identifier for each candidate cell from a serving cell; maintaining a variable storing the master security key update identifier for the serving cell; and performing the security update based on determining that the master security key update identifier for the target cell is different from the master security key update identifier for the serving cell stored in the variable.
[0024] In some embodiments, the method further includes replacing the master security key update identifier stored in the variable with the master security key update identifier of the target cell.
[0025] In some embodiments, the method further includes receiving a list of master security update information including one or more entries for corresponding candidate cells. Each entry includes master security key update information.
[0026] In some embodiments, a security update is performed based on a master security key update information in a predetermined entry or indicated entry in a list of master security update information associated with the target cell.
[0027] In some embodiments, the method further includes removing predetermined or indicated entries from a list of primary security update information associated with the target cell.
[0028] In some embodiments, the command includes a primary security update information identifier associated with the target cell, and a security update is performed based on the primary security update information identified by the primary security update information identifier.
[0029] In some embodiments, primary security update information associated with the target cell is included in the command, and a security update for the target cell is performed based on the primary security update information.
[0030] In some embodiments, the master security key update information includes a first field indicating whether the UE needs to export a new master security key, and a second field containing parameters for exporting the new master security key.
[0031] One aspect of this disclosure provides a base station (BS) for facilitating communication in a wireless network. The BS includes a transceiver configured to: send master security key update information for one or more candidate cells to a user equipment (UE); and send a command to the UE indicating that a cell transition from the BS's serving cell to a target cell among the one or more candidate cells has been triggered. The master security key update information associated with the target cell is used for security updates of the target cell.
[0032] In some embodiments, the transceiver is also configured to send the master security key update identifier for each candidate cell to the UE.
[0033] Beneficial effects of the invention
[0034] This disclosure provides efficient communication methods in wireless communication systems. Attached Figure Description
[0035] Figure 1 An example of a wireless network according to an embodiment is shown.
[0036] Figure 2A An example of a wireless transmission path according to an embodiment is shown.
[0037] Figure 2B An example of a wireless reception path according to an embodiment is shown.
[0038] Figure 3A An example of a user equipment (“UE”) according to an embodiment is shown.
[0039] Figure 3B An example of a base station (“BS”) according to an embodiment is shown.
[0040] Figure 4 An example process for updating the master security key according to an embodiment is shown.
[0041] Figure 5 An example process for updating the master security key according to an embodiment is shown.
[0042] Figure 6 An example process for updating the master security key according to an embodiment is shown.
[0043] Figure 7 An example process for updating the master security key according to an embodiment is shown.
[0044] Figure 8 An example process for updating the master security key according to an embodiment is shown.
[0045] Figure 9 An example process for updating the master security key according to an embodiment is shown.
[0046] Figure 10 An example process for updating the master security key according to an embodiment is shown.
[0047] Figure 11 An example process for updating the master security key is shown according to an embodiment.
[0048] Figure 12 An example of an LTM cell switching command MAC CE according to an embodiment is shown.
[0049] Figure 13 An example MAC subheader for an LTM cell transition MAC CE according to an embodiment is shown.
[0050] Figure 14 An example of an LTM cell switching command MAC CE according to an embodiment is shown.
[0051] Figure 15 An example of an LTM cell switching command MAC CE according to an embodiment is shown.
[0052] Figure 16 An example of an LTM cell switching command MAC CE according to an embodiment is shown.
[0053] Figure 17 An example of an LTM cell switching command MAC CE according to an embodiment is shown.
[0054] Figure 18 An example process for updating the master security key according to an embodiment is shown.
[0055] Figure 19 The configuration of a UE in a wireless communication system according to various embodiments is shown.
[0056] Figure 20 The configuration of a base station or network entity in a wireless communication system according to various embodiments is shown.
[0057] In one or more embodiments, not all of the components depicted in each figure may be required, and one or more embodiments may include additional components not shown in the figures. Variations in the arrangement and type of components may be made without departing from the scope of this subject matter disclosure. Additional components, different components, or fewer components may be utilized within the scope of this subject matter disclosure. Detailed Implementation
[0058] This application claims U.S. Provisional Application No. 63 / 617,611, filed January 4, 2024, entitled “MASTER SECURITY KEY UPDATE FOR L1 / L2 TRIGGERED MOBILITY”; U.S. Provisional Application No. 63 / 617,616, filed January 4, 2024, entitled “L2 SIGNALING FOR SECURITY KEY UPDATE FOR L1 / L2 TRIGGERED MOBILITY”; U.S. Provisional Application No. 63 / 618,171, filed January 5, 2024, entitled “MASTER SECURITY KEY UPDATE FOR L1 / L2 TRIGGERED MOBILITY”; and U.S. Provisional Application No. 63 / 618,171, filed December 17, 2024, entitled “SECURITY KEY UPDATE IN WIRELESS”. Priority to U.S. nonprovisional application No. 18 / 984,893, “NETWORKS”, all of which are incorporated herein by reference in their entirety.
[0059] Mobility management operations, including network handover, represent a critical aspect of any wireless communication system. These systems include, for example, LTE and 5G New Radio (NR), as well as upcoming technologies currently being termed "6G." Mobility is currently controlled by the network with the assistance of the user equipment (UE) to maintain optimal connection quality. The network can hand over the UE to a target cell with superior signal quality.
[0060] Enhanced broadband mechanisms requiring high speed and low latency necessitate more complex handover mechanisms. Therefore, Conditional Handover (CHO) and Layer 1 / Layer 2 Triggered Mobility (LTM) have been introduced to provide additional conditions for specific networks or their slices, thereby improving handover speed. However, the use of these enhancements introduces its own latency, at least because the network needs to exchange some data with the UE during the handover process. Therefore, the initiation of a planned handover triggered by the network introduces its own latency, signaling overhead, and downtime.
[0061] The detailed description set forth below in conjunction with the accompanying drawings is intended to describe various embodiments and is not intended to represent the only embodiments in which the subject matter can be practiced. Rather, this detailed description includes specific details to provide a thorough understanding of the subject matter of the invention. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the scope of this disclosure. Therefore, the drawings and description are to be considered illustrative rather than restrictive in nature. The same reference numerals denote the same elements.
[0062] The following description pertains to certain implementations for the purpose of describing the innovative aspects of this disclosure. However, those skilled in the art will readily recognize that a variety of different approaches can be used to apply the teachings herein. The examples in this disclosure are based on current 5G NR systems, advanced 5G (5G-A) and its further improvements and advancements, as well as upcoming 6G communication systems. However, in various cases, the described embodiments can also be implemented in any device, system, or network capable of transmitting and receiving radio frequency (RF) signals according to other technologies, such as 3G and 4G systems or further implementations thereof. For example, the principles of this disclosure can be applied to Global System for Mobile Communications (GSM), GSM / General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Terrestrial Trunking Radio (TETRA), Wideband CDMA (W-CDMA), Evolved Data Optimized (EV-DO), 1xEV-DO, EV-DO Rev A, EV-DO Rev B, High-Speed Packet Access (HSPA), High-Speed Downlink Packet Access (HSDPA), High-Speed Uplink Packet Access (HSUPA), Evolved High-Speed Packet Access (HSPA+), Long Term Evolution (LTE), Enhanced 5G NR, AMPS, or other known signals for communication within wireless, cellular, or IoT networks, such as one or more of the aforementioned systems utilizing 3G, 4G, 5G, 6G, or further implementations thereof. This technology can also be associated with and applied to any of the existing or proposed IEEE 802.11 standards, Bluetooth standards, and other wireless communication standards.
[0063] Wireless communication, as described above, is one of the most commercially successful innovations in history. Aside from automation software, robotics, machine learning, and other software that automates the use of these types of communication devices, the absolute number of wireless or cellular subscribers continues to grow. A year ago, the number of users of all types of communication services exceeded five billion. This number has long been surpassed and continues to grow rapidly. Demand for services employing wireless data services is also increasing rapidly, partly due to the growing popularity of smartphones and other mobile data devices (such as tablets, notepad computers, netbooks, e-book readers, and dedicated machine-type devices) among consumers and businesses. It goes without saying that improvements in radio interface efficiency and coverage are crucial to meeting the high growth of mobile data services and supporting new applications and deployments.
[0064] To continue accommodating the rapidly increasing demands for wireless data traffic over the years and to facilitate the growth and complexity of so-called “vertical applications” (i.e., code written or generated to achieve goals unique to a user or entity, such as enterprise resource planning and customer relationship management software), 5G communication systems have been developed and are currently being commercially deployed. Advanced 5G, as defined in 3GPP Release 18, represents a further upgrade to various aspects of 5G and has already been introduced in some countries as an optimization of 5G. Development of Advanced 5G is ongoing. The development and enhancement of 5G can also enable greater overall efficiency in processing resources, for example, in intensive machine learning environments involving precision medical instruments, measuring devices, robotics, etc. Due to the development of 5G and its anticipated follow-up technologies, these devices are expected to have more robust access to one or more application programming interfaces (APIs) and other software routines, and will be able to operate at faster speeds.
[0065] Among other advantages, 5G can be implemented using higher frequency bands, particularly 28 GHz or 60 GHz. More generally, such bands can include those above 6 GHz. A key benefit of these higher frequency bands is potentially significantly superior data rates. One disadvantage is the requirement for line-of-sight (LOS) in some cases, the difficulty of penetrating obstacles between the base station and the UE at higher frequencies, and a shorter overall transmission range. When transmitting at these millimeter-wave (mmW) frequencies, 5G systems rely on more directional communication (e.g., using multiple antennas, implementing massive MIMO, transmit and / or receive beamforming, temporary power boosting, etc.). Furthermore, 5G can advantageously use lower frequency bands (such as below 6 GHz) for transmission to achieve more robust and longer-range coverage and for mobility support (including handover, etc.). As described above, various aspects of this disclosure can be applied to 5G deployments, currently developing 6G systems, and subsequent versions. The latter category can include those standards applied to the THz band. To reduce radio wave propagation loss and increase transmission distance, as described in the section, emerging technologies such as MIMO, full-dimensional MIMO (FD-MIMO), array antennas, digital and analog beamforming, massive MIMO technology and other technologies are discussed in various 3GPP-based standards that define the implementation of 5G communication systems.
[0066] In addition, in 5G communication systems, development of system network improvements based on advanced small cells, cloud radio access networks (RAN) ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), and receiver interference cancellation are underway or have already been deployed. With the emergence of exemplary technologies such as neural network machine learning, autonomous or partially controlled electric vehicles, or hydrogen-based vehicles, these 5G advancements are expected to play potentially significant roles in their respective implementations. Other advanced access technologies within the 5G framework that have been developed or are under development include, for example, advanced coding and modulation (ACM) schemes using hybrid frequency shift keying (FSK), frequency orthogonal amplitude modulation (FQAM), and sliding window superposition coding (SWSC); and advanced access technologies using filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA).
[0067] Also under development is the principle of 6G technology, which could be commercially available by the end of the decade or even earlier. 6G systems are expected to inherit most or all of the improvements brought by 5G and further enhance them, while also adding new features and functionalities. Furthermore, 6G is expected to open up previously untapped (blank) bandwidth areas to increase overall capacity. As previously stated, the principles disclosed herein are expected to apply equally effectively to 6G systems and more advanced systems.
[0068] Figure 1 An example of a wireless network 100 according to an embodiment is shown. Figure 1 The embodiment of the wireless network 100 shown is for illustrative purposes only. Other embodiments of the wireless network 100 may be used without departing from the scope of this disclosure. It should be noted initially that the nomenclature can vary widely depending on the system. For example, in Figure 1 In this context, the term "BS" (base station) can also be referred to as eNodeB (eNB), gNodeB (gNB), or, in the commercial rollout of 6G, BS may have another name. For the purposes of this disclosure, BS and gNB are used interchangeably. Therefore, depending on the network type, the term "gNB" can refer to any component (or set of components) configured to provide wireless network access to remote terminals, such as a base transceiver station, radio base station, transmitting point (TP), transmitting-receiving point (TRP), terrestrial gateway, airborne gNB, satellite system, mobile base station, macro cell, micro cell, WiFi access point (AP), etc. Return to Reference Figure 1Network 100 includes BSs (or gNBs) 101, 102, and 103. BS 101 communicates with BS 102 and BS 103. BSs can be connected via known backhaul connections or other connectivity methods, such as wireless connections. BS 101 also communicates with at least one Internet Protocol (IP) based network 130. Network 130 may include the Internet, a proprietary IP network, or another network.
[0069] Similarly, depending on the type of network 100, other well-known terms may be used instead of "user equipment" or "UE," such as "mobile station," "subscriber station," "remote terminal," "wireless terminal," or "user device." For convenience, the terms "user equipment" and "UE" are used interchangeably with "subscriber station" in this patent document to refer to a remote wireless device that wirelessly accesses the gNB, whether the UE is a mobile device (such as a mobile phone or smartphone) or is generally considered to be a fixed device (such as a desktop computer, vending machine, appliance, or any device with a wireless connection compatible with network 100). Continue to refer to Figure 1 BS 102 provides wireless broadband access to IP network 130 to a first plurality of user equipments (UEs) within coverage area 120 of BS 102. The first plurality of UEs includes UE 111, which may be located in a small business (SB); UE 112, which may be located in an enterprise (E); UE 113, which may be located in a WiFi hotspot (HS); UE 114, which may be located in a first residence (R); UE 115, which may be located in a second residence (R); and UE 116, which may be a mobile device (M), such as a cellular phone, wireless laptop computer, wireless PDA, etc. BS 103 provides wireless broadband access to IP network 130 to a second plurality of UEs within coverage area 125 of BS 103. The second plurality of UEs includes UE 115 and UE 116, which are located in both coverage areas 120 and 125. In some embodiments, one or more of BS 101-103 may communicate with each other and with UE 111-116 using 6G, 5G, LTE, LTE-A, WiMAX or other advanced wireless communication technologies.
[0070] exist Figure 1 In the diagram, as noted, the dashed lines represent the approximate extents of coverage areas 120 and 125 of BS 102 and 103, respectively, and are shown as approximately circular for illustrative and explanatory purposes. It should be clearly understood that, depending on the configuration of the BS, the coverage areas associated with the AP (such as coverage areas 120 and 125) can have other shapes, including irregular shapes. Although Figure 1 An example of a wireless network 100 is shown, but more details can be found on other wireless networks. Figure 1Various modifications can be made. For example, the wireless network 100 can include any number of BS / gNBs and any number of UEs in any suitable arrangement. Furthermore, BS 101 can communicate directly with any number of UEs and provide these UEs with wireless broadband access to the IP network 130. Similarly, each BS 102 or 103 can communicate directly with the IP network 130 and provide the UEs with direct wireless broadband access to the network 130. Additionally, gNBs 101, 102, and / or 103 can provide access to other or additional external networks, such as external telephone networks or other types of data networks.
[0071] It should be understood that in a 5G system, BS 101 may include multiple antennas, multiple radio frequency (RF) transceivers, transmit (TX) processing circuitry, and receive (RX) processing circuitry. BS 101 may also include a controller / processor, memory, and a backhaul or network interface. The RF transceivers can receive incoming RF signals from the antennas, such as signals from the UE in network 100. The RF transceivers can down-convert the incoming RF signals to generate intermediate (IF) or baseband signals. The IF or baseband signals are sent to the RX processing circuitry, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuitry then sends the processed baseband signal to the controller / processor for further processing.
[0072] The controller / processor may include control BS 101 ( Figure 1 The controller / processor is one or more processors or other processing devices that control the overall operation of the UE, RX processing circuitry, and TX processing circuitry to receive uplink signals and transmit downlink signals, based on well-known principles. The controller / processor may also support additional functions, such as more advanced wireless communication functions. For example, the controller / processor may support beamforming or directional routing operations, where outgoing signals from multiple antennas are weighted differently to effectively guide outgoing signals in a desired direction. The controller / processor may also support OFDMA operations, where outgoing signals can be assigned to subsets of different subcarriers for different receivers (e.g., different UEs 111-114). The controller / processor may support various other functions in BS 101, including combining MIMO and OFDMA in the same transmission opportunity. In some embodiments, the controller / processor may include at least one microprocessor or microcontroller. The controller / processor is also capable of executing programs and other processes residing in memory, such as the OS. The controller / processor may move data into or out of memory as needed for the execution process.
[0073] The controller / processor is also coupled to a backhaul or network interface. The backhaul or network interface allows BS 101 to communicate with other BSs, devices, or systems via a backhaul connection or over a network. The interface can support communication via any suitable wired or wireless connection. For example, the interface can allow BS 101 to communicate via a wired or wireless LAN or via a wired or wireless connection to a larger network, such as the Internet. The interface can include any suitable structure that supports communication via a wired or wireless connection, such as an Ethernet or RF transceiver. Memory is coupled to the controller / processor. A portion of the memory can include RAM, and another portion of the memory can include flash memory or other ROM.
[0074] For the purposes of this disclosure, a processor may include not only a main processor, but also other hardware, firmware, middleware, or software implementations that can be responsible for performing various functions. Furthermore, the processor executing code in memory may include multiple processors and other components, and may include one or more physical memories. Therefore, for example, executable code or data may reside in different physical memories, and this embodiment remains within the spirit and scope of this disclosure.
[0075] Figure 2A An example of a wireless transmission path 200A according to an embodiment is shown. Figure 2B An example of a wireless receiving path 200B according to an embodiment is shown. In the following description, a transmitting path 200A can be implemented in a gNB / BS (such as...). Figure 1 The BS 102) is implemented, while the receive path 200B can be implemented in the UE (such as...). Figure 1 The receiving path 200B is implemented in the UE 111 (SB). However, it should be understood that the receiving path 200B can be implemented in the BS, and the transmitting path 200A can be implemented in the UE. In some embodiments, the receiving path 200B is configured to support codebook design and architecture for a system with a 2D antenna array as described in some embodiments of this disclosure. That is, each of the BS and UE includes both transmitting and receiving paths, enabling full-duplex communication such as voice sessions.
[0076] Transmission path 200A includes: a channel coding and modulation block 205 for modulating and encoding data bits into symbols; a serial-to-parallel (S-to-P) conversion block 210; an inverse fast Fourier transform (IFFT) block 215 of size N for converting N frequency-based signals back to the time domain before transmission; a parallel-to-serial (P-to-S) block 220 for serializing the parallel data blocks from IFFT block 215 into a single data stream (note that a BS / UE with multiple transmission paths can each transmit a separate data stream); and a cyclic prefix addition block 225 for adding a guard interval, which can be a copy of the end portion of an orthogonal frequency domain modulation (OFDM) symbol (or any modulation scheme used) and is typically at least as long as the delay spread to mitigate the effects of multipath propagation. Alternatively, the cyclic prefix can contain data about the corresponding frame or other data unit. Next, an upconverter (UC) 230 modulates the baseband (or, in some cases, intermediate frequency (IF)) signal onto a carrier signal for use as an RF signal transmitted via an antenna.
[0077] The receive path 200B essentially comprises the opposite circuitry and includes a downconverter (DC) 255 for removing the data stream from the carrier signal and restoring it to a baseband (or IF) data stream in other embodiments; a cyclic prefix removal block 260 for removing guard intervals (or removing intervals of varying lengths); a serial-to-parallel (S-to-P) block 265 for acquiring the data stream and parallelizing it into N data streams for faster operation; a multi-input size N Fast Fourier Transform (FFT) block 270 for converting N time-domain signals into symbols in the frequency domain; a parallel-to-serial (P-to-S) block 275 for serializing the symbols; and a channel decoding and demodulation block 280 for decoding the data and demodulating the symbols into bits using any demodulation and decoding scheme initially used for modulating and encoding the data in the reference transmission path 200A.
[0078] As another example, in Figure 2A In the transmission path 200A, the channel coding and modulation block 205 receives a set of information bits, applies coding (such as low-density parity-check (LDPC) coding), and modulates the input bits (such as using quadrature phase shift keying (QPSK), quadrature amplitude modulation (QAM), orthogonal frequency domain multiple access (OFDMA), or other current or future modulation schemes) to generate a frequency domain modulated symbol sequence. The serial-to-parallel block 210 converts (such as demultiplexing) the serial modulated symbols into parallel data to generate N parallel symbol streams, where, as indicated, N is in BS 102 and UE 116 ( Figure 1The size of the IFFT / FFT used is specified. An IFFT block 215 of size N performs an IFFT operation on N parallel symbol streams to generate a time-domain output signal. A parallel-to-serial block 220 converts (e.g., multiplexes) the parallel time-domain output symbols from the IFFT block 215 of size N to generate a serial time-domain signal. A cyclic prefix addition block 225 inserts a cyclic prefix into the time-domain signal. An upconverter 230 modulates (e.g., upconverts) the output of the cyclic prefix addition block 225 from baseband (or, in other embodiments, intermediate frequency IF) to an RF frequency for transmission via a wireless channel. The signal may also be filtered at baseband before conversion to the RF frequency.
[0079] The transmitted RF signal from BS 102 reaches UE 116 after passing through the radio channel, and UE 116 performs the opposite operation to that at BS 102. Figure 1 Downconverter 255 (e.g., at UE 116) downconverts the received signal to baseband or IF frequency, and cyclic prefix removal block 260 removes the cyclic prefix to generate a serial time-domain baseband signal. Serial-to-parallel block 265 converts or multiplexes the time-domain baseband signal into a parallel time-domain signal. FFT block 270 of size N performs an FFT algorithm to generate N parallel frequency-domain signals. Parallel-to-serial block 275 converts the parallel frequency-domain signals into a sequence of modulated data symbols. Channel decoding and demodulation block 280 demodulates and decodes the modulated symbols to recover the original input data stream. The data stream can then be segmented and processed accordingly using a processor and its associated memory. Figure 1 Each of the BSs 101-103 can implement a transmission path 200A similar to that sent to UEs 111-116 in the downlink. Similarly, each of the BSs 101-103 can implement a reception path 200B similar to that received from UEs 111-116 in the uplink. Likewise, to enable bidirectional signaling, each UE 111-116 can implement a transmission path 200A for sending to BSs 101-103 in the uplink, and each UE 111-116 can implement a reception path 200B for receiving from gNBs 101-103 in the downlink. In this way, a given UE can bidirectionally exchange signals with BSs within its range, and vice versa.
[0080] Figure 2A and Figure 2B Each of the components can be implemented using only hardware or a combination of hardware and software / firmware. As a specific example, Figure 2A and 2BAt least some components can be implemented in software, while others can be implemented using configurable hardware or a hybrid of software and configurable hardware. For example, FFT block 270 and IFFT block 215 can be implemented as configurable software algorithms, where the value of size N can be modified depending on the implementation. Furthermore, although described as using FFT and IFFT, this exemplary implementation is for illustrative purposes only and should not be construed as limiting the scope of this disclosure. For example, other types of transforms such as Discrete Fourier Transform (DFT) and Inverse Discrete Fourier Transform (IDFT) functions can be used instead of FFT / IFFT. It should be understood that for DFT and IDFT functions, the value of variable N can be any integer (e.g., 1, 2, 3, 4, etc.), while for FFT and IFFT functions, the value of variable N can be any integer a power of 2 (e.g., 1, 2, 4, 8, 16, etc.). Additionally, although... Figure 2A and 2B An example of a wireless transmit and receive path is shown, but it is possible to modify it further. Figure 2A and 2B Make various changes. For example, you can combine, further subdivide, or omit. Figure 2A and 2B It includes various components and allows for the addition of additional components as needed. Furthermore, Figure 2A and 2B This is intended to illustrate examples of the types of transmit and receive paths that can be used in a wireless network. Any other suitable architecture can be used to support wireless communication in a wireless network. For example, by... Figure 2A and 2B The functions performed by the modules can be executed by a processor that executes the correct code in the memory corresponding to each module.
[0081] Figure 3A A user equipment (“UE”) 300A according to an embodiment is shown (e.g., it may be...). Figure 1 Examples include UE 116 or another UE. It should be emphasized that... Figure 3A The UE 300A embodiment described herein is for illustrative purposes only, and Figure 1 UEs 111-116 can have the same or similar configurations. However, UEs have a wide variety of configurations, and Figure 3A UE 300A does not limit the scope of this disclosure to any particular implementation of the UE. Reference is now made to... Figure 3AThe UE 300A includes components such as an antenna 305 (which may be a single antenna or an array or multiple arrays in other UEs), a radio frequency (RF) transceiver 310, transmit (TX) processing circuitry 315 coupled to the RF transceiver 310, a microphone 320, and receive (RX) processing circuitry 325. The UE 300A also includes a speaker 330 coupled to the receive processing circuitry 325, a main processor 340, an input / output (I / O) interface (IF) 345 coupled to the processor 340, a keypad (or other input device) 350, a display 355, and a memory 360 coupled to the processor 340. In addition to data, the memory 360 also includes a basic operating system (OS) program 361 and one or more applications 362. In some embodiments, the display 355 may also constitute an input touchpad, and in this case, it may be bidirectionally coupled to the processor 340.
[0082] Depending on the complexity and configuration of the UE, the RF transceiver may include more than one transceiver. RF transceiver 310 receives incoming RF signals transmitted by the BS of network 100 from antenna 305. The RF transceiver transmits and receives radio data and control information. In this example, the RF transceiver is operatively coupled to processor 340 via TX processing circuitry 315 and RF processing circuitry 325. RF transceiver 310 may then down-convert the incoming RF signal to generate an intermediate frequency (IF) or baseband signal. In some embodiments, down-conversion may be performed by another device coupled to the transceiver. The IF or baseband signal is sent to RX processing circuitry 325, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signal. RX processing circuitry 325 sends the processed baseband signal to speaker 330 (e.g., in the context of a voice call) or to main processor 340 for further processing (e.g., for web browsing data or any number of other applications). TX processing circuitry 315 receives analog or digital voice data from microphone 320, or in other cases, it may receive other outgoing baseband data (such as web data, email, or interactive video game data) from main processor 340. TX processing circuitry 315 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. RF transceiver 310 receives the processed outgoing baseband or IF signal from TX processing circuitry 315 and up-converts it into an RF signal transmitted via antenna 305. Alternative methods and arrangements may be used to perform the same operation without departing from the spirit or scope of this disclosure.
[0083] The main processor 340 may include one or more processors or other processing devices and executes a basic OS program 361 stored in memory 360 to control the overall operation of the UE 116. For example, the main processor 340 may control the RF transceiver 310, RX processing circuitry 325, and TX processing circuitry 315 to receive forward channel signals and transmit reverse channel signals according to well-known principles. In some embodiments, the main processor 340 includes at least one microprocessor or microcontroller. The transceiver 310 is coupled directly to the processor 340 or via an intermediate element. The main processor 340 is also capable of executing other processes and programs residing in memory 360, such as CLTM in a wireless communication system as described in embodiments of this disclosure. The main processor 340 may move data into or out of memory 360 as needed for the execution of the process. In some embodiments, the main processor 340 is configured to execute application program 362 based on OS program 361 or in response to signals received from an operator of the BS or UE. The main processor 340 is also coupled to an I / O interface 345, which provides the UE 300A with the ability to connect to other devices, such as laptops and handheld computers. The I / O interface 345 is the communication path between these accessories and the main controller 340. The main processor 340 is also coupled to a keypad 350 and a display unit 355. The operator of the UE 300A can use the keypad 350 to input data into the UE 300A. The display 355 may be a liquid crystal display or other display capable of displaying text and / or at least limited graphics from a website. Memory 360 is coupled to the main processor 340. A portion of the memory 360 may include random access memory (RAM), and another portion of the memory 360 may include flash memory or other read-only memory (ROM).
[0084] Figure 3AThe UE 300A may also include additional or different types of memory, including dynamic random access memory (DRAM), non-volatile flash memory, static RAM (SRAM), and cache memory at different levels. While the main processor 340 may be a complex instruction set computer (CISC) based processor with one or more cores, it should be noted that in other embodiments, the processor may include multiple processors. The processor may also include a reduced instruction set computer (RISC) based processor. Various other components of the UE 300A may include separate processors, or they may be partially or wholly controlled by firmware or middleware. For example, any one or more components of the UE 300A may include one or more digital signal processors (DSPs), one or more field-programmable gate arrays (FPGAs), one or more programmable logic devices (PLDs), one or more application-specific integrated circuits (ASICs), and / or one or more system-on-a-chip (SoCs) for performing the various tasks discussed above. In some implementations, the UE 300A may rely on middleware or firmware, whose updates may be received from time to time. For devices typically targeted at compact smartphones and other UEs, hardware designs can be implemented to reflect this smaller aspect ratio. The antenna can extend from the device or be located within other UEs; it can also be embedded within the UE body. The display panel may include a layer of indium tin oxide or a similar compound to enable the display to function as a touchpad. In short, although... Figure 3A An example of UE300A was explained, but it is possible to... Figure 3A Various changes may be made without departing from the scope of this disclosure. For example, combinations, further subdivisions, or omissions may be made. Figure 3A The main processor 340 can be divided into various components, and additional components can be added as needed. As an example, the main processor 340 can be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Furthermore, although... Figure 3A This may include a UE configured as a mobile phone or smartphone (e.g., Figure 1 The UE is 116 in the original text, but it can be configured to operate as other types of mobile or fixed devices. For example, the UE can be incorporated into tower desktop computers, tablet computers, laptops, workstations, and servers.
[0085] Figure 3B An example of a BS 300B according to an embodiment is shown. Non-exhaustive examples of the BS 300B could be... Figure 1 An example of BS 102. As stated above, for the purposes of this disclosure, the terms BS and gNB are used interchangeably. Figure 3B The BS300B embodiment shown is for illustrative purposes only, and Figure 1Other BSs can have the same or similar configurations. However, BS / gNBs have a wide variety of configurations, and it should be emphasized that... Figure 3B The BS shown does not limit the scope of this disclosure to any particular implementation of the BS. For example, BS 101 and BS 103 may include [missing information - likely related to specific implementations of the BS]. Figure 1 BS 102 or BS 300B (in Figure 3B They have the same or similar structures, or they can have different structures. For example... Figure 3B As shown, the BS 300B includes multiple antennas 370a-370n, multiple corresponding RF transceivers 372a-372n, transmit (TX) processing circuitry 374, and receive (RX) processing circuitry 376. The transceivers 372a-372n are coupled directly to the processor or via intermediate elements. In some embodiments, one or more of the multiple antennas 370a-370n include a 2D antenna array. The BS 300B also includes a controller / processor 378 (hereinafter referred to as "processor 378"), a memory 380, and a backhaul or network interface 382. The RF transceivers 372a-372n receive incoming RF signals from the antennas 370a-370n, such as signals transmitted by the UE or other BSs. The RF transceivers 372a-372n down-convert the corresponding incoming RF signals to generate IF or baseband signals. The IF or baseband signal is sent to the RX processing circuit 376, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signal. The RX processing circuit 376 sends the processed baseband signal to the controller / processor 378 for further processing. The TX processing circuit 374 receives analog or digital data (such as voice data, network data, email, interactive video game data, or data used in machine learning programs) from the processor 378. The TX processing circuit 374 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. RF transceivers 372a-372n receive the outgoing processed baseband or IF signal from the TX processing circuit 374 and up-convert the baseband or IF signal into an RF signal transmitted via antennas 370a-370n. It should be noted that the above is descriptive in nature; in reality, not all antennas 370-370n need to be active simultaneously.
[0086] Processor 378 may include one or more processors or other processing devices that control the overall operation of BS 300B. For example, processor 378 may control the reception of forward channel signals and the transmission of reverse channel signals by RF transceivers 372a-372n, RX processing circuitry 376, and TX processing circuitry 374 according to well-known principles. Processor 378 may also support additional functions, such as more advanced wireless communication functions. For example, processor 378 may perform blind interference sensing (BIS) processes (such as those performed by BIS algorithms) and decode the received signal after subtracting interference signals. Processor 378 may support any of a variety of other functions in BS 300B. In some embodiments, processor 378 includes at least one microprocessor or microcontroller or an array thereof. Processor 378 is also capable of executing programs and other processes residing in memory 380, such as a basic operating system (OS). Processor 378 is also capable of supporting CLTM in wireless communication systems as described in embodiments of this disclosure. In some embodiments, controller / processor 378 supports communication between entities, such as web RTCs. The processor 378 can move data into or out of the memory 380 as needed during execution. The backhaul or network interface 382 allows the BS 300B to communicate with other devices or systems via a backhaul connection or network. Interface 382 can support communication via any suitable wired or wireless connection. For example, when the BS 300B is implemented as part of a cellular communication system (such as a cellular communication system supporting 5G, 5G-A, LTE, or LTE-A), interface 382 can allow the BS 102 ( Figure 1 It communicates with other BSs via wired or wireless backhaul connections. (Return to Reference) Figure 3B Interface 382 may allow BS 102 to communicate via a wired or wireless local area network or via a wired or wireless connection to a larger network, such as the Internet. Interface 382 includes any suitable architecture supporting communication via a wired or wireless connection, such as an Ethernet or RF transceiver. Memory 380 is coupled to processor 378. A portion of memory 380 may include RAM, and another portion of memory 380 may include flash memory or other ROM. In some exemplary embodiments, multiple instructions, such as a dual-spectrum exponential algorithm (BIS), may be stored in memory. The multiple instructions are configured to cause processor 378 to perform the BIS process and decode the received signal after subtracting at least one interference signal determined by the BIS algorithm.
[0087] The BS 102's transmit and receive paths are described in more detail below (in...). Figure 3BIn the example, the BS 300B (implemented using RF transceivers 372a-372n, TX processing circuitry 374, and / or RX processing circuitry 376) supports aggregation communication with Frequency Division Duplex (FDD) cells or Time Division Duplex (TDD) cells, or some combination of both. That is, communication with multiple UEs can be achieved by allocating the transceiver's uplink to a certain frequency and establishing downlinks using different frequencies (FDD). In TDD, uplink and downlink division is achieved by allocating certain time for uplink transmissions to the BS and other time for downlink transmissions from the BS to the UE. Although... Figure 3B This shows something similar to or equivalent to BS 102 ( Figure 1 An example of BS 300B, but applicable to Figure 3B Various changes can be made. For example, BS 300B can include any number of Figure 3B Each component is shown. As a specific example, an access point may include multiple interfaces 382, and a processor 378 may support routing capabilities to route data between different network addresses. As another example, although for simplicity... Figure 3B The description includes a single instance of TX processing circuitry 374 and a single instance of RX processing circuitry 376, but the BS 300B may include multiple instances of each (such as one transmit or receive per RF transceiver).
[0088] As an example, LTE version 13 supports up to 16 CSI-RS (Channel State Information - Reference Signal) antenna ports, allowing the BS to be equipped with a large number of antenna elements (such as 64 or 128). In this case, multiple antenna elements are mapped to a single CSI-RS port. Furthermore, Rel.14 LTE supports up to 32 CSI-RS ports. For next-generation cellular systems such as 5G, the maximum number of CSI-RS ports can be even greater. CSI-RS is a reference signal sent by the BS to the UE to allow the UE to estimate the downlink radio channel quality. CSI-RS can be transmitted on any available OFDM symbols and subcarriers configured in the Radio Resource Control (RRC) message. The UE measures various radio channel quality parameters (time delay, signal-to-noise ratio, power) and reports the results to the BS.
[0089] Figure 3BThe BS 300B may also include additional or different types of memory 380, including dynamic random access memory (DRAM), non-volatile flash memory, static RAM (SRAM), and different levels of cache memory. While the main processor 378 may be a complex instruction set computer (CISC) based processor with one or more cores, in other embodiments, the processor may include multiple processors or an array of processors. Typically, in embodiments, the processing power and requirements of the BS may be much higher than those of a typical UE, although this is not necessary. Some BSs may include large structures on towers or other structures, and their immobility allows them to obtain a fixed power supply without requiring any local power, except for a backup battery in power outage-type events. The processor 378 may also include a reduced instruction set computer (RISC) based processor or an array thereof. Various other components of the BS 300B may include separate processors, or they may be partially or wholly controlled by firmware or middleware. For example, any one or more components of the BS 300B may include one or more digital signal processors (DSPs), one or more field-programmable gate arrays (FPGAs), one or more programmable logic devices (PLDs), one or more application-specific integrated circuits (ASICs), and / or one or more system-on-a-chip (SoCs) for performing the various tasks described above. In some implementations, the BS 300B may rely on middleware or firmware, whose updates may be received from time to time. In some configurations, the BS may include stacked motherboard layers to accommodate greater processing demands and process channel state information (CSI) and other data received from nearby UEs.
[0090] In short, although Figure 3B An example of BS was explained, but it is possible to... Figure 3B Various changes may be made without departing from the scope of this disclosure. For example, combinations, further subdivisions, or omissions may be made. Figure 3B The BS can contain various components and can add additional components as needed. As an example mentioned above, the main processor 378 can be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs)—or, in some cases, multiple motherboards for enhanced functionality. The BS can also include a large number of solid-state drive (SSD) storage or magnetic hard drives for long-term data retention. Furthermore, while one example of the BS 300B is a tower-based structure, this description is merely exemplary, and the BS can exist in other forms based on well-known principles.
[0091] The following provides a description of various aspects of this disclosure. The text in the written description and the corresponding drawings are provided by way of example only to help the reader understand the principles of this disclosure. They are not intended and should not be construed as limiting the scope of this disclosure in any way. Although certain embodiments and examples have been provided, those skilled in the art will understand based on the disclosure herein that changes can be made to the illustrated embodiments and examples without departing from the scope of this disclosure.
[0092] From the following detailed description, aspects, features, and advantages of this disclosure will become apparent. Several embodiments and implementations are shown for illustrative purposes. This disclosure is also capable of further and different embodiments, and several details thereof may be modified in various obvious ways without departing from the spirit and scope of this disclosure. Therefore, the drawings and description are to be considered illustrative in nature and not restrictive. This disclosure is illustrated in the accompanying figures by way of example rather than limitation.
[0093] Although the following exemplary descriptions and embodiments employ Orthogonal Frequency Division Multiplexing (OFDM) or Orthogonal Frequency Division Multiple Access (OFDMA) for illustrative purposes, other encoding / decoding techniques may be used. That is, this disclosure can be extended to other OFDM-based transmission waveforms or multiple access schemes such as filtered OFDM (F-OFDM). Furthermore, the principles of this disclosure are equally applicable to different encoding and modulation methods. Examples include LDPC, QPSK, BPSK, QAM, etc.
[0094] This disclosure covers several components that can be used in combination or together with each other or can operate as independent solutions. Given the large number of terms and jargon used in conveying concepts related to wireless communication, those skilled in the art have developed numerous acronyms to refer to common elements, components, and processes. For the reader's convenience, a non-exhaustive list of example acronyms is provided below. As will be apparent in the following text, many of these acronyms below and in the remainder of the document may have been newly created by the inventors, while others may currently be familiar. For example, certain acronyms (e.g., CLTM) may have been developed by the inventors and designed to help provide an effective description of unique features within this disclosure. A list of common and unique acronyms is provided below (Table 1).
[0095] Table 1
[0096] abbreviation:
[0097] L1 Floor 1
[0098] L2 Floor 2
[0099] L3 floor 3
[0100] UE User Equipment
[0101] gNB base station
[0102] NW Network
[0103] NR New Radio
[0104] 3GPP Third Generation Partnership Project
[0105] HO switching
[0106] CHO condition switching
[0107] MCG main cell group
[0108] SCG auxiliary community group
[0109] AS Access Layer
[0110] NAS Non-Access Layer
[0111] RRC Radio Resource Control
[0112] DU Distributed Unit
[0113] CU Central Unit
[0114] UL-SCH uplink shared channel
[0115] DL-SCH downlink shared channel
[0116] DL downlink
[0117] UL uplink
[0118] IE Information Elements
[0119] SpCell Special Community
[0120] SCell Auxiliary Community
[0121] PScell primary and secondary cells
[0122] The following documents are incorporated herein by reference in their entirety, as if fully set forth herein: i) 3GPP TS 38.300 v17.6.0; ii) 3GPP TS 38.331 v17.6.0; and iii) 3GPP TS 38.321 v17.6.0.
[0123] 3GPP (3rd Generation Partnership Project) has developed technical specifications and standards to define the new 5G radio access technology, known as 5G NR. Mobility processing is a critical aspect of any mobile communication system that includes 5G systems. For mobility in connected modes, handover is initiated by the network based on Layer 3 (L3) measurements via higher-layer signaling (such as RRC messages). However, this process introduces increased latency, signaling overhead, and downtime, which can become critical in some scenarios with frequent handovers, such as when the UE is in a vehicular environment or moving at high speed in a frequency range 2 (FR2) deployment. It is necessary to reduce latency, signaling overhead, and downtime during handover. This requires the adoption of L1 / L2 triggered mobility (LTM), where handover is triggered by L1 / L2 signaling based on L1 measurements. More specifically, LTM refers to a mobility mechanism in which the UE uses beam switching triggered by L1 / L2 signaling to switch from a source cell to a target cell, with the beam switching decision based on L1 measurements of the beams between neighboring cells.
[0124] In version 18, subsequent LTM has been introduced for scenarios within the gNB-CU. Subsequent LTM supports cell handover between cells within the same gNB or CU. Cell handover between L1 / L2 mobility candidates is performed without requiring RRC reconfiguration, and the security key remains unchanged (i.e., not updated) during LTM cell handover within the gNB-CU. For LTM candidate cells, the LTM candidate cell configuration in version 18 lacks a master key update for configuring security key updates. Therefore, the UE retains the current security key used for the source cell and does not update it for the target cell.
[0125] In version 19 or next-generation wireless communications, LTM can be extended to gNB-CU scenarios to support cell handover between cells of different BSs (e.g., gNB or CU). In these scenarios, RRC reconfiguration during LTM cell handover can be avoided by pre-configuring a list of LTM candidate cells.
[0126] For gNB-CU inter-LTM within a Primary Cell Group (MCG), the master security key must be updated when the source and target cells belong to different gNBs or CUs. Therefore, for gNB-CU inter-LTM within an MCG, the UE must perform a master security key update. However, in subsequent LTMs or conditional LTMs, both inter-CU LTMs and intra-CU LTMs can occur, and the network may not know in advance whether the next cell transition will be an inter-CU LTM or an intra-CU LTM. Therefore, it is necessary to specify the configuration for updating the master security key for the LTM candidate cell list and the security key update procedure for LTM cell transitions to support both intra-CU and inter-CU LTMs within the MCG. Additionally, it is necessary to specify, for example, a configuration for signaling security key update information via L2 signaling for LTM cell transitions to support both intra-CU and inter-CU LTMs within the MCG.
[0127] This disclosure provides configuration and procedures for updating the master security key for both intra-CU LTM and inter-CU LTM. This disclosure also provides signaling procedures for updating the security key for both intra-CU LTM and inter-CU LTM.
[0128] The various embodiments described in this disclosure can be applied to subsequent LTM and conditional LTM for intra-CU mobility and inter-CU mobility.
[0129] In some embodiments, for each LTM candidate cell, the network configures a master security key update in the IE ltm-CandidateConfig, which includes an RRCReconfiguration message for configuring the LTM candidate cell. For example, the IE ltm-CandidateConfig includes an IE masterKeyUpdate within the RRCReconfiguration message. In embodiments, when a ReconfigurationWithSync IE is part of an LTM candidate IE associated with the MCG, the IE masterKeyUpdate resides within the RRCReconfiguration message container in the ltm-CandidateConfig of each LTM candidate cell.
[0130] In some embodiments, IE masterKeyUpdate may include the keySetChangeIndicator field, which indicates whether the UE needs to export a new master key (K_gNB). When reconfigurationWithSync is included, the value "true" may indicate that K_gNB is exported from a security key (K_AMF) used in a recently successful Non-Access Stratum (NAS) Security Mode Command (SMC) procedure or an N2 handover procedure with a K_AMF change. The value "false" may indicate that K_gNB is obtained from the current K_gNB or from the next hop (NH). This field may be mandatory in IEmasterKeyUpdate used for LTM candidate cells.
[0131] In some embodiments, IE masterKeyUpdate may include the field nextHopChainingCount, which indicates parameters used to export the K_gNB key when keySetChangeIndicator is set to the value "false". This field may be mandatory in IE masterKeyUpdate for LTM candidate cells.
[0132] In some embodiments, IE masterKeyUpdate may include a field called nas-Container. This field is used to transmit UE-specific NAS layer information between the network and the UE. The RRC layer is transparent to this field, although it affects the activation of Access Layer (AS) security after an inter-system handover to the NR system. This field may optionally be present in IE masterKeyUpdate for LTM candidate cells.
[0133] In some embodiments, for each LTM candidate cell associated with the MCG, the UE receives master security key update information (e.g., IE masterKeyUpdate) within the RRC reconfiguration message in the IE ltm-CandidateConfig. For LTM cell transition execution, when the LTM cell transition is triggered by an indication from a lower layer (L1 or L2) or when reconfiguration is performed for subsequent LTM execution conditions, the UE can apply the RRC reconfiguration message in ltm-CandidateConfig within the LTM-Candidate IE in VarLTM-Config, identified by the LTM candidate configuration identifier received from the lower layer. If IE masterKeyUpdate is included in the RRC reconfiguration message, the UE performs an access stratum (AS) security key update procedure.
[0134] Additionally, if an LTM cell transition is triggered while timer T311 is running and performing cell selection, the UE can apply an RRC reconfiguration message in the ltm-CandidateConfig within the LTM-Candidate IE of the VarLTM-Config associated with the LTM candidate configuration identifier of the selected cell. If masterKeyUpdate is included in the RRC reconfiguration message, the UE performs the AS security key update procedure.
[0135] Figure 4 An example procedure 400 for updating the master security key according to an embodiment is illustrated. For illustrative purposes, example procedure 400 can be performed by the UE. Although one or more operations are described or illustrated in a specific order, in other embodiments, the operations may be rearranged in a different order, which may include performing multiple operations in at least partially overlapping time periods. In this example, the master security key update in the LTM reconfigures the information in the container using RRC.
[0136] refer to Figure 4 Process 400 can begin in operation 401. In operation 401, for each LTM candidate cell associated with the MCG, the UE receives master security key update information in an RRCReconfiguration message. In this implementation, the UE receives the master security key update information (e.g., IE masterKeyUpdate) within the RRCReconfiguration message container in ltm-CandidateConfigure. Then, process 400 proceeds to operation 403.
[0137] In operation 403, the UE receives an indication from a lower layer (L1 or L2) that an LTM cell handover from the source cell to the target cell has been triggered for the MCG. Then, procedure 400 proceeds to operation 405.
[0138] In Operation 405, for the target cell, the UE performs LTM cell transition and AS security key update based on the master security key update information (e.g., IE masterKeyUpdate) in the RRCReconfiguration message.
[0139] In some embodiments, a Master Security Key Update ID and associated Master Security Key Update information can be configured for each candidate cell. Additionally, a Master Security Key Update ID for the serving cell can be configured for the serving cell. For LTM candidate cells belonging to the same BS, gNB, or CU as the serving cell (i.e., candidate cells within the CU), the network can configure the candidate cell's Master Security Key Update ID to be the same as the serving cell's Master Security Key Update ID. Conversely, for LTM candidate cells belonging to different BS, gNB, or CUs than the serving cell, the network can configure the candidate cell's Master Security Key Update ID to be different from the serving cell's Master Security Key Update ID. The UE can determine whether to perform a Master Security Key Update for LTM cell transition by comparing the serving cell's Master Security Key Update ID with the candidate cell's Master Security Key Update ID.
[0140] In some embodiments, for each LTM candidate cell associated with the MCG, the UE receives the serving cell's master security key update ID, the master security key update ID of each candidate cell, and the master security key update information (e.g., IE masterKeyUpdate) for each candidate cell in the LTM configuration. In this implementation, for each LTM candidate cell associated with the MCG, the master security key update information (e.g., IE masterKeyUpdate) may be included within the RRCReconfiguration message in the IE ltm-CandidateConfig of the LTM configuration. When ReconfigurationWithSync is part of the LTM-Candidate IE associated with the MCG, IE masterKeyUpdate may exist in the RRCReconfiguration message in the ltm-CandidateConfig of each LTM candidate cell. The master security key update information (e.g., IE masterKeyUpdate) may include the elements described above.
[0141] In some embodiments, the Master Security Key Update ID (e.g., ltm-MasterKeyUpdateID) is included in ltm-Candidate for each LTM candidate cell in the LTM configuration, and the Serving Cell Master Security Key Update ID (e.g., ltm-ServingCellMasterKeyUpdateID) is included in the LTM configuration. The UE maintains a variable (VarLTM-ServingCellMasterKeyUpdateID) that stores the Serving Cell Master Security Key Update ID associated with the MCG's LTM configuration and performs the following operations:
[0142] - If the received LTM-Config includes ltm-ServingCellMasterKeyUpdateID:
[0143] --If the current VarLTM-ServingCellMasterKeyUpdateID includes ltm-ServingCellMasterKeyUpdateID:
[0144] --- Replace the ltm-ServingCellMasterKeyUpdateID value in VarLTM-ServingCellMasterKeyUpdateID with the received ltm-ServingCellMasterKeyUpdateID;
[0145] --otherwise:
[0146] ---Store the received ltm-ServingCellMasterKeyUpdateID in VarLTM-ServingCellMasterKeyUpdateID.
[0147] In some embodiments, for a cell group that triggers LTM configuration release, when the UE performs RRC reconstruction or RRC release, or when the UE transitions to RRC idle, the UE can remove all entries in VarLTM-ServingCellMasterKeyUpdateID.
[0148] In some embodiments, for LTM cell switching execution, when receiving an indication to trigger an LTM cell switching for the MCG from a lower layer (L1 or L2), or when performing an LTM cell switching after cell selection performed while timer T311 is running, the UE may maintain the variable VarLTM-ServingCellMasterKeyUpdateID. In this embodiment, the UE may perform the following operations:
[0149] - If an LTM cell transition is triggered by an indication from a lower layer or a reconfiguration is performed for a subsequent LTM execution (condition), the UE applies the RRCReconfiguration message in the IE tm-CandidateConfig within the IE of the VarLTM-Config identified by the LTM candidate configuration identifier received from the lower layer;
[0150] --If masterKeyUpdate is included in the RRCReconfiguration message:
[0151] ---If the value of the ltm-MasterKeyUpdateID field included in the LTM-Candidate IE in VarLTM-Config for the target cell indicated by the lower layer or for the selected cell used for cell reselection is not equal to the value of ltm-ServingCellMasterKeyUpdateID in VarLTM-ServingCellMasterKeyUpdateID:
[0152] ----Execute the AS security key update process;
[0153] Replace the value of ltm-ServingCellMasterKeyUpdateID in VarLTM-ServingCellMasterKeyUpdateID with the value of ltm-MasterKeyUpdateID in LTM-Candidate in VarLTM-Config;
[0154] - Otherwise, for example, when LTM cell switching is triggered while timer T311 is running and cell selection is being performed, the UE applies the RRCReconfiguration message in ltm-CandidateConfig within ltm-CandidateIE of VarLTM-Config associated with the LTM candidate configuration identifier of the selected cell.
[0155] --If masterKeyUpdate is included in the RRCReconfiguration message:
[0156] ---If the value of the ltm-MasterKeyUpdateID field contained in the LTM-Candidate IE in VarLTM-Config for the target cell indicated by a lower layer or for the selected cell used for cell reselection is not equal to the value of ltm-ServingCellMasterKeyUpdateID within VarLTM-ServingCellMasterKeyUpdateID, then:
[0157] ----Execute the AS security key update process;
[0158] Replace the value of ltm-ServingCellMasterKeyUpdateID in VarLTM-ServingCellMasterKeyUpdateID with the value of ltm-MasterKeyUpdateID in LTM-Candidate in VarLTM-Config.
[0159] Figure 5 An example procedure 500 for updating a master security key according to an embodiment is illustrated. For illustrative and explanatory purposes, example procedure 500 can be performed by a UE. Although one or more operations are described or illustrated in a specific order, in other embodiments, the operations may be rearranged in a different order, which may include performing multiple operations in at least partially overlapping time periods.
[0160] refer to Figure 5 Procedure 500 can begin in operation 501. In operation 501, the UE receives the serving cell's master security key update ID, the master security key update ID of each candidate cell, and the master security key update information (e.g., IE masterKeyUpdate) from the LTM configuration. Then, procedure 500 proceeds to operation 503.
[0161] In operation 503, the UE maintains and stores a variable for the serving cell's master security key update ID associated with the MCG's LTM configuration. Then, procedure 500 proceeds to operation 505.
[0162] In operation 505, the UE receives an indication from a lower layer (L1 or L2) that an LTM cell handover from the source cell to the target cell has been triggered for the MCG. Then, procedure 500 proceeds to operation 507.
[0163] In Operation 507, for the target cell, the UE performs an LTM cell transition. If the target cell's Master Security Key Update ID differs from the Serving Cell's Master Security Key Update ID stored in a variable, the UE can apply the RRCReconfiguration message in ltm-CandidateConfig and perform an AS security key update.
[0164] In some embodiments, a security configuration can be configured for LTM, including configuring a Master Security Key Update ID for each candidate cell and a Serving Cell Master Security Key Update ID for the serving cell. For LTM candidate cells belonging to the same BS, gNB, or CU as the serving cell (i.e., candidate cells within the CU), the network can configure the Master Security Key Update ID of the candidate cell to be the same as the Master Security Key Update ID of the serving cell. Conversely, for LTM candidate cells belonging to different BS, gNB, or CUs than the serving cell, the network can configure a Master Security Key Update ID for the candidate cell that is different from the Master Security Key Update ID of the serving cell. The UE can determine whether to perform a Master Security Key Update for LTM by comparing the Master Security Key Update ID of the serving cell with the Master Security Key Update ID of the LTM candidate cell.
[0165] In some embodiments, the UE receives an MCG LTM configuration, which includes a security configuration, a serving cell master security key update ID, and a master security key update ID for each LTM candidate cell. In this embodiment, the security configuration (ltm-SecurityConfig) is included in the LTM configuration (LTM-Config) used for the MCG. ltm-SecurityConfig includes a list of master security configurations to be added or modified (ltm-masterSecurityCellSetToAddModList) and a list of master security configurations to be released (ltm-masterSecurityCellSetToReleaseList), as follows:
[0166] The `--ltm-masterSecurityCellSetToAddModList` option includes a list of master security configurations (ltm-masterSecurityConfig), where each ltm-masterSecurityConfig can include...
[0167] ---A list of LTM master key update information (ltm-masterKeyUpdateList), and each entry in the list (ltm-masterKeyUpdate) may include:
[0168] ----The ID of the LTM master security key update information (ltm-masterKeyID), and / or
[0169] ---- Field keySetChangeIndicator and / or
[0170] ---- Fields nextHopChainingCount and / or
[0171] ----Field nas-Container.
[0172] ---Master Security Key Update ID (ltm-masterKeyUpdateID).
[0173] The ltm-masterSecurityCellSetToReleaseList can include a list of master security key update IDs (ltm-masterKeyUpdateID).
[0174] In some embodiments, the UE maintains a variable (VarLTM-Config) storing the security configuration for the LTM configuration of the MCG, and performs the following operations:
[0175] --If the received LTM-Config includes ltm-masterSecurityCellSetToReleaseList:
[0176] ---If VarLTM-Config includes ltm-masterSecurityConfig associated with ltm-masterKeyUpdateID included in ltm-masterSecurityCellSetToReleaseList,
[0177] Remove the entry ltm-masterSecurityConfig associated with ltm-masterKeyUpdateID from VarLTM-Config.
[0178] --If the received LTM-Config includes ltm-masterSecurityCellSetToAddModList:
[0179] ---For an ltm-masterSecurityConfig that has an ltm-masterKeyUpdateID in ltm-masterSecurityCellSetToAddModList, and if VarLTM-Config includes an ltm-masterSecurityConfig with the same ltm-masterKeyUpdateID,
[0180] Replace the ltm-masterSecurityConfig entry in VarLTM-Config with the received ltm-masterSecurityConfig identified by ltm-masterKeyUpdateID;
[0181] ---otherwise,
[0182] Add the received ltm-masterSecurityConfig with ltm-masterKeyUpdateID to VarLTM-Config.
[0183] In some embodiments, the Master Security Key Update ID (ltm-MasterKeyUpdateID) is included in the IE ltm-Candidate of each LTM candidate cell in the LTM configuration, and the Serving Cell Master Security Key Update ID (ltm-ServingCellMasterKeyUpdateID) is included in the LTM configuration (LTM-Config). The UE maintains a variable (VarLTM-ServingCellMasterKeyUpdateID) that stores the Serving Cell Master Security Key Update ID associated with the MCG's LTM configuration and performs the following operations:
[0184] --If the received LTM-Config includes ltm-ServingCellMasterKeyUpdateID:
[0185] ---If the current VarLTM-ServingCellMasterKeyUpdateID includes ltm-ServingCellMasterKeyUpdateID:
[0186] Replace the ltm-ServingCellMasterKeyUpdateID value in VarLTM-ServingCellMasterKeyUpdateID with the received ltm-ServingCellMasterKeyUpdateID;
[0187] ---otherwise:
[0188] The received ltm-ServingCellMasterKeyUpdateID is stored in VarLTM-ServingCellMasterKeyUpdateID.
[0189] In some embodiments, for a cell group that triggers LTM configuration release, when the UE performs RRC reconstruction or RRC release, or when the UE transitions to RRC idle, the UE can remove all entries in VarLTM-ServingCellMasterKeyUpdateID.
[0190] In some embodiments, for LTM cell switching execution, when receiving an indication that an LTM cell switching has been triggered for an MCG from a lower layer (L1 or L2), or when performing an LTM cell switching after a cell selection performed while timer T311 is running, the UE may maintain or preserve the variable VarLTM-ServingCellMasterKeyUpdateID, and may perform the following operations:
[0191] --If the LTM cell transition is triggered by an indication from a lower layer, or if the LTM cell transition is triggered while timer T311 is running and cell selection is being performed, or if the transition is performed in response to a subsequent LTM execution (conditional) reconfiguration:
[0192] ---The UE application is identified by the LTM candidate configuration received from the lower layer, specifically the RRCReconfiguration message in the LTM-CandidateConfig within the identified VarLTM-Config, and / or
[0193] ---If the value of the ltm-MasterKeyUpdateID field contained in the LTM-Candidate IE in VarLTM-Config for the target cell indicated by a lower layer or for the selected cell used for cell reselection is not equal to the value of ltm-ServingCellMasterKeyUpdateID within VarLTM-ServingCellMasterKeyUpdateID, then:
[0194] In VarLTM-Config's ltm-masterSecurityConfig, the ltm-MasterKeyUpdateID is the same as the ltm-MasterKeyUpdateID contained in the target cell's LTM-Candidate. Consider the ltm-masterKeyUpdate in the first entry of ltm-masterKeyUpdateList.
[0195] ----Use the information in ltm-masterKeyUpdate to perform the AS security key update process, and / or
[0196] Remove the selected ltm-masterKeyUpdate from the ltm-masterKeyUpdateList included in ltm-masterSecurityConfig within VarLTM-Config.
[0197] Replace the value of ltm-ServingCellMasterKeyUpdateID in VarLTM-ServingCellMasterKeyUpdateID with the value of ltm-MasterKeyUpdateID in LTM-Candidate of the target cell.
[0198] In some embodiments, the LTM cell transition command MAC CE may include a field indicating a master key ID to identify master security key update information configured in the higher layers. The UE may apply ltm-masterKeyUpdate, identified by ltm-masterKeyID, which has the same value as the master key ID indicated in the MAC CE for master security key updates. For LTM cell transition execution, upon receiving an indication that an LTM cell transition has been triggered for the MCG via a lower layer, the UE performs the following operations:
[0199] - If the LTM cell transition is triggered by an indication from a lower layer, or if it is performed in response to a reconfiguration for a subsequent LTM execution (condition):
[0200] --The UE applies the RRCReconfiguration message in the LTM-CandidateConfig within the LTM-CandidateIE of the VarLTM-Config identified by the LTM Candidate Configuration Identifier received from the lower layer, and / or
[0201] --If the value of the ltm-MasterKeyUpdateID field within the LTM-Candidate IE in VarLTM-Config for the target cell indicated by the lower layer or for the selected cell for cell reselection is not equal to the value of ltm-ServingCellMasterKeyUpdateID within VarLTM-ServingCellMasterKeyUpdateID, and if the value of the master key ID is received from the lower layer, then:
[0202] ---In the ltm-masterSecurityConfig of VarLTM-Config, where the ltm-MasterKeyUpdateID is the same as the ltm-MasterKeyUpdateID contained in the LTM-Candidate of the target cell, consider the ltm-masterKeyUpdate in the ltm-masterKeyUpdateList identified by the ltm-masterKeyID that matches the value of the master key ID indicated by the lower layer.
[0203] ---Use the information in ltm-masterKeyUpdate to perform the AS security key update process, and / or
[0204] ---Remove the selected ltm-masterKeyUpdate from the ltm-masterKeyUpdateList included in ltm-masterSecurityConfig within VarLTM-Config.
[0205] --- Replace the value of ltm-ServingCellMasterKeyUpdateID in VarLTM-ServingCellMasterKeyUpdateID with the value of ltm-MasterKeyUpdateID in LTM-Candidate in VarLTM-Config.
[0206] Figure 6 An example procedure 600 for updating a master security key according to an embodiment is shown. For illustrative and explanatory purposes, example procedure 600 can be performed by a UE. Although one or more operations are described or shown in a specific order, in other embodiments, the operations may be rearranged in a different order, which may include performing multiple operations in at least partially overlapping time periods.
[0207] refer to Figure 6 Procedure 600 can begin in operation 601. In operation 601, the UE receives the serving cell's primary security key update ID, the primary security key update ID of each candidate cell, and a list of primary security configurations from the LTM configuration. Each entry in the list of primary security configurations includes a primary security key update ID and primary key update information including the list of primary security key updates. Then, procedure 600 proceeds to operation 603.
[0208] In operation 603, the UE can maintain a variable storing the serving cell's primary security key update ID associated with the MCG's LTM configuration. Additionally, the UE can add, modify, or release the primary security configuration based on the LTM configuration. Then, procedure 600 proceeds to operation 605.
[0209] In operation 605, the UE may receive an indication from a lower layer (L1 or L2) that an LTM cell handover from the source cell to the target cell has been triggered for the MCG. Then, procedure 600 proceeds to operation 607.
[0210] In operation 607, the UE performs an LTM cell transition. The UE can determine whether the target cell's Master Security Key Update ID is different from the serving cell's Master Security Key Update ID stored in a variable. If the target cell's Master Security Key Update ID is different from the Master Security Key Update ID, the UE can perform an AS security key update based on the Master Key Update information included in the first entry of the Master Security Configuration list. In another embodiment, the UE can perform an AS security key update based on the Master Key Update information included in an entry of the Master Security Configuration list, indicated by the target cell's Master Security Key Update ID.
[0211] In some embodiments, a security configuration including a list of master security key update information is configured for LTM, along with the master security key update ID for each candidate cell and the master security key update ID for the serving cell. For LTM candidate cells belonging to the same BS, gNB, or CU as the serving cell (i.e., candidate cells within the CU), the network can configure the master security key update ID of the candidate cell to be the same as the master security key update ID of the serving cell. For LTM candidate cells belonging to different BS, gNB, or CUs than the serving cell, the network can configure a different master security key update ID for the candidate cell than the serving cell. The UE determines whether to perform a master security key update procedure for LTM by comparing the master security key update ID of the serving cell with the master security key update ID of the LTM candidate cells.
[0212] In some embodiments, the UE receives an MCG LTM configuration, which includes a security configuration, a serving cell master security key update ID, and a master security key update ID for each LTM candidate cell. In this embodiment, the security configuration (ltm-SecurityConfig) is included in the LTM configuration (LTM-Config) used for the MCG. ltm-SecurityConfig includes a list of master security configurations to be added or modified (ltm-masterSecurityConfigToAddModList) and a list of master security configurations to be released (ltm-masterSecurityConfigToReleaseList). The UE can perform the following operations:
[0213] -ltm-masterSecurityConfigToAddModList can include
[0214] --A list of LTM master security key update configurations (ltm-masterSecurityConfig), and each entry includes
[0215] ---LTM master security information ID (ltm-masterSecurityConfigID), and / or
[0216] ---The keySetChangeIndicator field as described above, and / or
[0217] ---The nextHopChainingCount field as described above, and / or
[0218] ---The field nas-Container as mentioned above.
[0219] -ltm-masterSecurityCellSetToReleaseList can include the ID of the master security key update configuration (ltm-masterSecurityConfigID).
[0220] In some embodiments, when the LTM configuration includes a security configuration (ltm-SecurityConfig), the UE maintains a variable (VarLTM-Config) storing the security configuration for the MCG's LTM configuration and performs the following operations:
[0221] - If the received LTM-Config includes ltm-masterSecurityConfigToReleaseList:
[0222] --If VarLTM-Config includes an ltm-masterSecurityConfig with an ltm-masterSecurityConfigID that is included in ltm-masterSecurityConfigToReleaseList
[0223] ---Remove the entry ltm-masterSecurityConfig identified by ltm-masterSecurityConfigID from VarLTM-Config.
[0224] - If the received LTM-Config includes ltm-masterSecurityConfigToAddModList:
[0225] --For an ltm-masterSecurityConfig that has an ltm-masterSecurityConfigID in ltm-masterSecurityConfigToAddModList, and if VarLTM-Config includes an ltm-masterSecurityConfig with the same ltm-masterSecurityConfigID,
[0226] --- Replace the ltm-masterSecurityConfig entry in VarLTM-Config with the received ltm-masterSecurityConfig identified by ltm-masterSecurityConfigID;
[0227] --otherwise,
[0228] ---Add the received ltm-masterSecurityConfig with ltm-masterSecurityConfigID to VarLTM-Config.
[0229] In some embodiments, the Master Security Key Update ID (ltm-MasterKeyUpdateID) is included in the IE ltm-Candidate of each LTM candidate cell in the LTM configuration, and the Serving Cell Master Security Key Update ID (ltm-ServingCellMasterKeyUpdateID) is included in the LTM configuration (LTM-Config). When configuring the Serving Cell Master Security Key Update ID, the UE can maintain a variable (VarLTM-ServingCellMasterKeyUpdateID) that stores the Serving Cell Master Security Key Update ID associated with the LTM configuration of the MCG, and perform the following operations:
[0230] - If the received LTM-Config includes ltm-ServingCellMasterKeyUpdateID:
[0231] --If the current VarLTM-ServingCellMasterKeyUpdateID includes ltm-ServingCellMasterKeyUpdateID:
[0232] --- Replace the ltm-ServingCellMasterKeyUpdateID value in VarLTM-ServingCellMasterKeyUpdateID with the received ltm-ServingCellMasterKeyUpdateID;
[0233] --otherwise:
[0234] ---Store the received ltm-ServingCellMasterKeyUpdateID in VarLTM-ServingCellMasterKeyUpdateID.
[0235] In some embodiments, for a cell group that triggers LTM configuration release, when the UE performs RRC reconstruction or RRC release, or when the UE enters RRC idle, the UE can remove all entries in VarLTM-ServingCellMasterKeyUpdateID.
[0236] In some embodiments, the LTM cell transition command MAC CE may include a field indicating a master key ID to identify master security key update information configured in the higher layers. The UE applies a master security key update to the ltm-masterSecurityConfig identified by the master security configuration ID (ltm-masterSecurityConfigID), which has the same value as the master key ID indicated in the MAC CE. For LTM cell transition execution, upon receiving an indication that an LTM cell transition has been triggered for the MCG via a lower layer, the UE performs the following operations:
[0237] - If the LTM cell transition is triggered by an indication from a lower layer, or if it is performed in response to a reconfiguration for a subsequent LTM execution (condition):
[0238] --The UE applies the RRCReconfiguration message in the ltm-CandidateConfig within the LTM-Candidate IE of the VARLTM-Config identified by the LTM candidate configuration identifier received from the lower layer, and / or
[0239] --If the value of the ltm-MasterKeyUpdateID field within the LTM-Candidate IE in VarLTM-Config, which is included for the target cell indicated by the lower layer or for the selected cell for cell reselection, is not equal to the value of ltm-ServingCellMasterKeyUpdateID within VarLTM-ServingCellMasterKeyUpdateID, and if the value of the master key ID is received from the lower layer, then:
[0240] ---Consider the ltm-masterSecurityConfig in the VarLTM-Config identified by ltm-masterSecurityConfigID, where ltm-masterSecurityConfigID has a value for the master key ID indicated by the lower layer.
[0241] ---Use the information in ltm-masterSecurityConfig to perform the AS security key update process, and / or
[0242] ---Remove the selected ltm-masterSecurityConfig from VarLTM-Config.
[0243] --- Replace the value of ltm-ServingCellMasterKeyUpdateID in VarLTM-ServingCellMasterKeyUpdateID with the value of ltm-MasterKeyUpdateID in LTM-Candidate in VarLTM-Config.
[0244] Figure 7 An example procedure 700 for updating the master security key according to an embodiment is illustrated. For illustrative purposes, example procedure 700 can be performed by the UE. Although one or more operations are described or illustrated in a specific order, in other embodiments, the operations may be rearranged in a different order, which may include performing multiple operations in at least partially overlapping time periods. In this example, the master security key update in the LTM is based on the master security key update ID and pre-configured master security key update information.
[0245] refer to Figure 7 Procedure 700 can begin in operation 701. In operation 701, the UE receives the serving cell's primary security key update ID, the primary security key update ID of each candidate cell, and a list of primary security configurations from the LTM configuration. Each entry in the list of primary security configurations includes the primary security key update ID and primary security key update information. Then, procedure 700 proceeds to operation 703.
[0246] In operation 703, the UE can maintain a variable storing the serving cell's primary security key update ID associated with the MCG's LTM configuration. Additionally, the UE can add, modify, or release one or more primary security configurations based on the LTM configuration. Then, procedure 700 proceeds to operation 705.
[0247] In operation 705, the UE may receive an indication that an LTM cell handover from the source cell to the target cell has been triggered for the MCG via a lower layer (L1 or L2). Then, procedure 700 proceeds to operation 707.
[0248] In operation 707, the UE performs an LTM cell handover. The UE can determine whether the target cell's Master Security Key Update ID is different from the serving cell's Master Security Key Update ID stored in a variable. If the target cell's Master Security Key Update ID is different from the serving cell's Master Security Key Update ID, the UE can perform an AS security key update based on the Master Key Update information associated with the Master Security Configuration ID indicated by the lower layer.
[0249] In some embodiments, a security configuration can be configured for LTM that includes a list of master security key update information. The network indicates the ID of the master security key update information, enabling the UE to perform a master security key update.
[0250] In some embodiments, the UE receives an MCG LTM configuration that includes security configurations. The security configuration (ltm-SecurityConfig) can be included in the LTM configuration (LTM-Config) used for the MCG. ltm-SecurityConfig can include a list of master security configurations to be added or modified (ltm-masterSecurityConfigToAddModList) and a list of master security configurations to be released (ltm-masterSecurityConfigToReleaseList). The following is an example:
[0251] -ltm-masterSecurityConfigToAddModList can include
[0252] --A list of LTM master security key update configurations (ltm-masterSecurityConfig), and each entry includes
[0253] ---LTM master security information ID (ltm-masterSecurityConfigID), and / or
[0254] ---The keySetChangeIndicator field as described above, and / or
[0255] ---The nextHopChainingCount field as described above, and / or
[0256] ---The field nas-Container as mentioned above.
[0257] -ltm-masterSecurityCellSetToReleaseList can include the ID of the master security key update configuration (e.g., ltm-masterSecurityConfigID).
[0258] In some embodiments, the security configuration (ltm-SecurityConfig) may be included in the LTM configuration. The UE may maintain or preserve a variable (VarLTM-Config) storing the security configuration for the LTM configuration of the MCG, and perform the following operations:
[0259] - If the received LTM-Config includes ltm-masterSecurityConfigToReleaseList:
[0260] --If VarLTM-Config includes an ltm-masterSecurityConfig with an ltm-masterSecurityConfigID that is included in ltm-masterSecurityConfigToReleaseList
[0261] ---Remove the entry ltm-masterSecurityConfig identified by ltm-masterSecurityConfigID from VarLTM-Config.
[0262] - If the received LTM-Config includes ltm-masterSecurityConfigToAddModList:
[0263] --For an ltm-masterSecurityConfig that has an ltm-masterSecurityConfigID in ltm-masterSecurityConfigToAddModList, and if VarLTM-Config includes an ltm-masterSecurityConfig with the same ltm-masterSecurityConfigID,
[0264] --- Replace the ltm-masterSecurityConfig entry in VarLTM-Config with the received ltm-masterSecurityConfig identified by ltm-masterSecurityConfigID;
[0265] --otherwise,
[0266] ---Add the received ltm-masterSecurityConfig with ltm-masterSecurityConfigID to VarLTM-Config.
[0267] In some embodiments, the LTM cell transition command MAC CE may include a field indicating a master key ID to identify master security key update information configured in the higher layers. The UE applies an ltm-masterSecurityConfig identified by an ltm-masterSecurityConfigID, which has the same value as the master key ID indicated in the MAC CE, to the master security key update. For LTM cell transition execution, upon receiving an indication that an LTM cell transition has been triggered for the MCG via a lower layer, the UE performs the following operations:
[0268] - If the LTM cell transition is triggered by an indication from a lower layer, or if it is performed in response to a reconfiguration for a subsequent LTM execution (condition):
[0269] --The UE applies the RRCReconfiguration message in the LTM-CandidateConfig within the LTM-CandidateIE of the VarLTM-Config identified by the LTM Candidate Configuration Identifier received from the lower layer, and / or
[0270] --If the master key ID value is received from the lower layer:
[0271] ---Consider the ltm-masterSecurityConfig in the VarLTM-Config identified by ltm-masterSecurityConfigID, where ltm-masterSecurityConfigID has a value for the master key ID indicated by the lower layer.
[0272] ---Use the information in ltm-masterSecurityConfig to perform the AS security key update process, and / or
[0273] ---Remove the selected ltm-masterSecurityConfig in VarLTM-Config.
[0274] Figure 8 An example procedure 800 for updating the master security key according to an embodiment is illustrated. For illustrative and explanatory purposes, example procedure 800 can be performed by the UE. Although one or more operations are described or illustrated in a specific order, in other embodiments, the operations may be rearranged in a different order, which may include performing multiple operations in at least partially overlapping time periods. In this example, the master security key update in the LTM is based on pre-configured master security key update information and an indication from a lower layer identifying the master security key update information.
[0275] refer to Figure 8 Procedure 800 can begin in operation 801. In operation 801, the UE receives a list of primary security configurations from the LTM configuration. Each primary security configuration includes a primary security configuration ID and associated primary security key update information. Then, procedure 800 proceeds to operation 803.
[0276] In operation 803, the UE adds, modifies, or releases one or more primary security configurations based on variables stored in the LTM configuration. Then, procedure 800 proceeds to operation 805.
[0277] In operation 805, the UE receives an indication that an LTM cell handover from the source cell to the target cell has been triggered by an MCG performed at a lower layer (L1 or L2). Then, procedure 800 proceeds to operation 807.
[0278] In operation 807, the UE performs an LTM cell handover. The primary security configuration ID is indicated from the lower layer. The UE performs an AS security key update based on the master key update information identified by the primary security configuration ID indicated by the lower layer.
[0279] In some embodiments, for each LTM candidate cell, the network provides master security key update information in the LTM cell transition command MAC CE. In some embodiments, when the UE receives an indication from a lower layer that an LTM cell transition process has been triggered for the MCG, the UE performs the following operations:
[0280] - If the LTM cell transition is triggered by an indication from a lower layer, or if it is performed in response to a reconfiguration for a subsequent LTM execution (condition):
[0281] --The UE applies the RRCReconfiguration message in the LTM-CandidateConfig within the LTM-CandidateIE of the VarLTM-Config identified by the LTM Candidate Configuration Identifier received from the lower layer, and / or
[0282] --If master security key update information is received from a lower layer (e.g., the keySetChangeIndicator field and / or the nextHopChainingCount field):
[0283] ---Use information received from the lower layer to perform the AS security key update process, and / or
[0284] ---Remove the selected ltm-masterSecurityConfig in VarLTM-Config.
[0285] Figure 9An example procedure 900 for updating a master security key according to an embodiment is illustrated. For illustrative and explanatory purposes, example procedure 900 can be performed by a UE. Although one or more operations are described or illustrated in a specific order, in other embodiments, the operations may be rearranged in a different order, which may include performing multiple operations in at least partially overlapping time periods. In this example, the master security key update in the LTM is based on master security key update information received from a lower layer.
[0286] refer to Figure 9 Procedure 900 can begin in operation 901. In operation 901, the UE receives an indication that an LTM cell switch has been triggered for the MCG via a lower layer (L1 or L2). Then, procedure 900 proceeds to operation 903.
[0287] In operation 903, the UE receives master security key update information for LTM from the lower layer. Then, process 900 proceeds to operation 905.
[0288] In Operation 905, the UE performs an LTM cell handover. The UE performs an AS security key update based on the master key update information received from the lower layer.
[0289] In some embodiments, a security configuration that includes a list of master security key update information can be configured for LTM. The UE performs a master security key update based on the master security key update request included in the LTM cell transition command MAC CE.
[0290] In some embodiments, the UE receives an MCG LTM configuration including security configurations. In this embodiment, the security configuration (ltm-SecurityConfig) is included in the LTM configuration (LTM-Config) used for the MCG. ltm-SecurityConfig includes a list of master security configurations to be added or modified (ltm-masterSecurityConfigToAddModList) and a list of master security configurations to be released (ltm-masterSecurityConfigToReleaseList), as follows:
[0291] -ltm-masterSecurityConfigToAddModList can include
[0292] --A list of LTM master security key update configurations (ltm-masterSecurityConfig), and each entry includes
[0293] ---LTM master security information ID (ltm-masterSecurityConfigID), and / or
[0294] ---The keySetChangeIndicator field as described above, and / or
[0295] ---The nextHopChainingCount field as described above, and / or
[0296] ---The field nas-Container as described above.
[0297] -ltm-masterSecurityCellSetToReleaseList can include the ID of the master security key update configuration (ltm-masterSecurityConfigID).
[0298] In some embodiments, the security configuration (ltm-SecurityConfig) is included in the LTM configuration. The UE maintains a variable (VarLTM-Config) that stores the security configuration for the LTM configuration of the MCG, and performs the following operations:
[0299] - If the received LTM-Config includes ltm-masterSecurityConfigToReleaseList:
[0300] --If VarLTM-Config includes an ltm-masterSecurityConfig with an ltm-masterSecurityConfigID that is included in ltm-masterSecurityConfigToReleaseList
[0301] ---Remove the entry ltm-masterSecurityConfig identified by ltm-masterSecurityConfigID from VarLTM-Config.
[0302] - If the received LTM-Config includes ltm-masterSecurityConfigToAddModList:
[0303] --For an ltm-masterSecurityConfig that has an ltm-masterSecurityConfigID in ltm-masterSecurityConfigToAddModList, and if VarLTM-Config includes an ltm-masterSecurityConfig with the same ltm-masterSecurityConfigID,
[0304] --- Replace the ltm-masterSecurityConfig entry in VarLTM-Config with the received ltm-masterSecurityConfig identified by ltm-masterSecurityConfigID;
[0305] --otherwise,
[0306] ---Add the received ltm-masterSecurityConfig with ltm-masterSecurityConfigID to VarLTM-Config.
[0307] In some embodiments, the LTM cell transition command MAC CE may include a field indicating a master security key update request. The UE may select an ltm-masterSecurityConfig identified by the ltm-masterSecurityConfigID, which has the lowest value in the UE variables, for the master security key update. For LTM cell transition execution, upon receiving an indication from a lower layer that an LTM cell transition has been triggered for the MCG, the UE performs the following operations:
[0308] - If the LTM cell transition is triggered by an indication from a lower layer, or if it is performed in response to a reconfiguration for a subsequent LTM execution (condition):
[0309] --The UE applies the RRCReconfiguration message in the LTM-CandidateConfig within the LTM-CandidateIE of the VarLTM-Config identified by the LTM Candidate Configuration Identifier received from the lower layer, and / or
[0310] --If a master security key update request is received from a lower layer:
[0311] ---Select the ltm-MasterSecurityConfig identified by the lowest value of ltm-masterSecurityConfigID in VarLTM-Config.
[0312] ---Use the information in ltm-masterSecurityConfig to perform the AS security key update process, and / or
[0313] ---Remove the selected ltm-masterSecurityConfig in VarLTM-Config.
[0314] Figure 10 An example procedure 1000 for updating a master security key according to an embodiment is illustrated. For illustrative and explanatory purposes, example procedure 1000 can be performed by a UE. Although one or more operations are described or illustrated in a specific order, in other embodiments, the operations may be rearranged in a different order, which may include performing multiple operations in at least partially overlapping time periods. In this example, the master security key update in the LTM is based on pre-configured master security key update information and an indicated master security key update request.
[0315] refer to Figure 10 Procedure 1000 can begin in operation 1001. In operation 1001, the UE receives a list of primary security configurations from the LTM configuration. Each primary security configuration includes primary security key update information and a primary security configuration ID. Then, procedure 1000 proceeds to operation 1003.
[0316] In operation 1003, the UE uses variables stored in the LTM configuration to add, modify, or release one or more master security configurations. Then, procedure 1000 proceeds to operation 1005.
[0317] In operation 1005, the UE receives an indication that an LTM cell handover has been triggered for the MCG via a lower layer. Then, procedure 1000 proceeds to operation 1007.
[0318] In Operation 1007, the UE performs an LTM cell handover. If an instruction to request a master security key update is received from a lower layer, the UE performs an AS security key update based on the master security key update information associated with the lowest value in the master security configuration ID stored in a variable.
[0319] In some embodiments, a security configuration including a list of master security configurations can be configured for LTM. The network notifies the UE of the master security configuration ID to perform a master security key update. The UE can receive an MCG LTM configuration including the security configurations. In an implementation, the security configuration (ltm-SecurityConfig) is included in the LTM configuration (LTM-Config) used for MCG. ltm-SecurityConfig includes a list of master security configurations to be added or modified (ltm-masterSecurityCellSetToAddModList) and a list of master security configurations to be released (ltm-masterSecurityCellSetToReleaseList), as follows:
[0320] -ltm-masterSecurityCellSetToAddModList can include a list of master security configurations (i.e., ltm-masterSecurityConfig), where each ltm-masterSecurityConfig can include...
[0321] --A list of LTM master key update information (i.e., ltm-masterKeyUpdateList), and each entry in the list (i.e., ltm-masterKeyUpdate) may include:
[0322] ---The ID of the LTM master security key update information (i.e., ltm-masterKeyID), and / or
[0323] ---The keySetChangeIndicator field as described above, and / or
[0324] ---The nextHopChainingCount field as described above, and / or
[0325] ---The field nas-Container as described above.
[0326] --Master security configuration ID (e.g., ltm-masterSecurityConfigID).
[0327] -ltm-masterSecurityCellSetToReleaseList can include a list of master security configuration IDs (e.g., ltm-masterSecurityConfigID).
[0328] In some embodiments, the UE maintains a variable (VarLTM-Config) storing the security configuration for the LTM configuration of the MCG, and performs the following operations:
[0329] - If the received LTM-Config includes ltm-masterSecurityCellSetToReleaseList:
[0330] --If VarLTM-Config includes ltm-masterSecurityConfig associated with ltm-masterSecurityConfigID included in ltm-masterSecurityCellSetToReleaseList,
[0331] ---Remove the entry ltm-masterSecurityConfig associated with ltm-masterSecurityConfigID from VarLTM-Config.
[0332] - If the received LTM-Config includes ltm-masterSecurityCellSetToAddModList:
[0333] --For an ltm-masterSecurityConfig that has an ltm-masterSecurityConfigID in ltm-masterSecurityCellSetToAddModList, and if VarLTM-Config includes an ltm-masterSecurityConfig with the same ltm-masterSecurityConfigID,
[0334] --- Replace the ltm-masterSecurityConfig entry in VarLTM-Config with the received ltm-masterSecurityConfig identified by ltm-masterSecurityConfigID;
[0335] --otherwise,
[0336] ---Add the received ltm-masterSecurityConfig with ltm-masterSecurityConfigID to VarLTM-Config.
[0337] In some embodiments, the LTM cell transition command MAC CE may include a field indicating a master key ID to identify master security key update information configured in higher layers. The UE applies an ltm-masterSecurityConfig identified by an ltm-masterSecurityConfigID, which has the same value as the master key ID indicated in the MAC CE, for master security key updates. For LTM cell transition execution, when an instruction for an LTM cell transition process is triggered at a lower layer for an MCG, the UE performs the following operations:
[0338] - If the LTM cell transition is triggered by an indication from a lower layer, or if it is performed in response to a reconfiguration for a subsequent LTM execution (condition):
[0339] --The UE applies the RRCReconfiguration message in the LTM-CandidateConfig within the LTM-CandidateIE of the VarLTM-Config identified by the LTM Candidate Configuration Identifier received from the lower layer, and / or
[0340] --If the master key ID value is received from the lower layer:
[0341] ---In the VarLTM-Config identified by the ltm-masterSecurityConfigID, which matches the value of the master key ID indicated by the lower layer, select the first entry ltm-masterKeyUpdate in ltm-masterKeyUpdateList.
[0342] ---Use the information in ltm-masterKeyUpdate to perform the AS security key update process, and / or
[0343] ---Remove the selected ltm-masterKeyUpdate from the ltm-masterKeyUpdateList included in ltm-masterSecurityConfig within VarLTM-Config.
[0344] Figure 11An example procedure 1100 for updating the master security key according to an embodiment is illustrated. For illustrative purposes, example procedure 1100 can be performed by the UE. Although one or more operations are described or illustrated in a specific order, in other embodiments, the operations may be rearranged in a different order, which may include performing multiple operations in at least partially overlapping time periods. In this example, the master security key update in LTM is based on a pre-configured list of cell group-based master security key update information and an indicated master security configuration ID.
[0345] refer to Figure 11 Procedure 1100 can begin in operation 1101. In operation 1101, the UE receives the primary security configuration list from the LTM configuration. The list of primary security configurations includes one or more entries. Each entry includes a list of primary security configuration IDs and primary security key update information. Then, procedure 1100 proceeds to operation 1103.
[0346] In operation 1103, the UE uses variables stored in the LTM configuration to add, modify, or release one or more master security configurations. Then, procedure 1100 proceeds to operation 1105.
[0347] In operation 1105, the UE receives an indication that an LTM cell handover has been triggered for the MCG via a lower layer. Then, procedure 1100 proceeds to operation 1107.
[0348] In operation 1107, the UE performs an LTM cell handover. If a Master Security Configuration ID is received from a lower layer, the UE performs an AS security key update based on the Master Security Key Update Information in the first entry of the list of Master Security Configurations that can be identified by the Master Security Configuration ID.
[0349] In some embodiments, AS security key updates can be performed as follows:
[0350] 1> If the master security key update information (e.g., the keySetChangeIndicator field and / or the nextHopChainingCount field) is selected from the pre-configured LTM security configuration and / or provided by low-level indicators used for LTM execution:
[0351] 2> If keySetChangeIndicator is set to 1:
[0352] 3> Derive or update the KgNB key based on the KAMF key;
[0353] 2> Otherwise:
[0354] 3> Use the nextHopChainingCount value indicated by the lower layer to export or update the KgNB key based on the current KgNB key or NH;
[0355] 2> Store the nextHopChainingCount value;
[0356] 2> Export the key associated with the KgNB key as follows:
[0357] 3> If securityAlgorithmConfig is included in SecurityConfig:
[0358] 4> Export the KRRCenc and KUPenc keys associated with the cipheringAlgorithm indicated in securityAlgorithmConfig;
[0359] 4> Export the KRRCint and KUPint keys associated with the integrityProtAlgorithm indicated in securityAlgorithmConfig;
[0360] 3> Otherwise:
[0361] 4> Export the KRRCenc and KUPenc keys associated with the current cipheringAlgorithm;
[0362] 4> Export the KRRCint and KUPint keys associated with the current integrityProtAlgorithm.
[0363] In some embodiments, the UE can report master security key update information selected from a pre-configured security configuration. In an implementation, the UE can set the content of the RRCReconfigurationComplete message for LTM as follows:
[0364] 1> If RRCReconfiguration includes reconfigurationWithSync in MCG's spCellConfig:
[0365] 2>- If the AS security key update process is performed via a (conditional) reconfiguration execution due to a subsequent LTM, and a new K_gNB key value has been selected and / or exported:
[0366] 3> Include selectedKgNB and set its value to the selected KgNB key value;
[0367] 2> If the RRCReconfiguration message is applied due to a subsequent LTM (conditional) reconfiguration execution:
[0368] 3> Include selectedPCellForCLTM and set it to the information of the selected PCell (PCI and / or logical ID).
[0369] In some embodiments, the UE receives master security key update information via MAC CE (e.g., LTM cell transition command MAC CE). The UE then sends the received information to a higher layer for AS security key update.
[0370] Figure 12 An example of an LTM cell switching command MAC CE 1200 according to an embodiment is shown.
[0371] refer to Figure 12 The LTM cell transition command MAC CE 1200 includes a Master Key ID field indicating Master Security Key Update information, which is pre-configured in higher layers for application to LTM Master Security Key Updates. Existing or enhanced LTM cell transition commands MAC CE can be used. MAC CE 1200 can be identified by a MAC subheader with an eLCID as specified in Table 2. An example of a MAC subheader for MAC CE is provided in... Figure 13 As shown in the image.
[0372] Figure 13 An example MAC subheader 1300 of an LTM cell switching MAC CE according to an embodiment is shown.
[0373] refer to Figure 13 The MAC sub-header 1300 includes reserved (R) bits, format (F) bits, a logical channel ID (LCID) field, an enhanced LCID (eLCID) field, and an 8-bit L field. In an embodiment, in Table 2, the eICID for the enhanced LTM cell switching command MAC CE is specified using reserved code point 224 and reserved index 288. Additionally, in Table 2, which shows example values for an 8-bit byte eICID used for the downlink shared channel (DL-SCH), the eICID for the LTM cell switching command MAC CE is specified using reserved code point 225 and reserved index 289.
[0374] Table 2
[0375]
[0376] Return to reference Figure 12 The Master Key ID field is set to 0 to indicate that a master security key update should not be triggered. When the field is set to a value greater than 0, it indicates the master key ID. In this example, the field can be 3 bits long. Figure 12 Other fields not described in this disclosure are similar to or the same as fields in existing MAC CE.
[0377] In some embodiments, when a UE receives an LTM cell transition command MAC CE, it can perform the following operations at the MAC layer: The MAC entity can:
[0378] 1> If the MAC entity receives an LTM cell handover command (MAC CE) on the serving cell:
[0379] 2> Indicate to the upper layer that the LTM cell handover process has been triggered and the target configuration ID included in the MAC CE;
[0380] 2> If the MAC CE includes a master key ID, or if the MAC CE includes a master key ID with a value greater than 0:
[0381] 3> Indicate the master key ID to the upper layer.
[0382] In some embodiments, the LTM cell transition command MAC CE may include a keySetChangeIndicator field and / or a nextHopChainingCount field, which indicate master security key update information for LTM. Existing LTM cell transition commands MAC CE or enhanced LTM cell transition commands MAC CE may be used.
[0383] Figure 14 An example of an LTM cell switching command MAC CE 1400 according to an embodiment is shown.
[0384] Reference Figure 14 The LTM cell switching command MAC CE 1400 includes a master key (MK) field, a key set change indicator (KC) field, and a next-hop chain count field.
[0385] The MK field indicates whether master security key update information exists in the MAC CE 1400. This field is set to 1 to indicate the presence of the KC field and / or the next-hop chain count field. This field is set to 0 to indicate the absence of the KC field and / or the next-hop chain count field, and the presence of the R bit. The length of this field can be one (1) bit.
[0386] The KC field is set to 1 to indicate that the K_gNB key was derived from the K_AMF key being used via a recently successful NAS SMC procedure or an N2 switchover procedure with a K_AMF change for K_gNB key updates. The KC field is set to 0 to indicate that the new K_gNB key was obtained from the current K_gNB key or from the next-hop key. The length of this field can be one (1) bit.
[0387] The next-hop chain count field indicates the integer value of the next-hop chain count to be used to derive the master key K_gNB. The length of this field can be three (3) bits. Figure 14 Other fields not described in this disclosure are similar to or the same as fields in existing MAC CE.
[0388] In some embodiments, when the LTM cell transition command MAC CE is received, the UE performs the following operations in the MAC layer: The MAC entity may:
[0389] 1> If the MAC entity receives an LTM cell handover command (MAC CE) on the serving cell:
[0390] 2> Indicate to the upper layer that the LTM cell handover process has been triggered and the target configuration ID included in the MAC CE;
[0391] 2> If the MAC CE includes master security key update information (e.g., the keySetChangeIndicator field and / or the nextHopChainingCount field)
[0392] 3> Indicate master security key update information to the upper layer (e.g., the keySetChangeIndicator field and / or the nextHopChainingCount field).
[0393] In some embodiments, the UE may receive secondary security key update information in a MAC CE, such as an LTM cell transition command MAC CE. The UE may then send the secondary security key update information to a higher layer for AS security key updates. The MAC CE may include a field indicating a secondary key ID. The secondary key ID identifies the secondary security key update information pre-configured in the higher layer to be applied to the secondary security key update for LTM. Existing LTM cell transition commands MAC CEs or enhanced LTM cell transition commands MAC CEs may be used. The MAC CE may be identified by a MAC subheader having an eLCID as specified in Table 2.
[0394] Figure 15 An example of an LTM cell switching command MAC CE 1500 according to an embodiment is shown.
[0395] refer to Figure 15 The LTM cell switching command MAC CE 1500 includes a secondary key ID field. This field indicates the secondary key ID. This field can be set to 0 to indicate that a secondary security key update is not triggered. This field can be set to a value greater than 0 to indicate the secondary key ID. The length of this field can be three (3) bits. Figure 15 Other fields not described in this disclosure are similar to or the same as fields in existing MAC CE.
[0396] In some embodiments, when the LTM cell transition command MAC CE is received, the UE performs the following operations in the MAC layer: The MAC entity may:
[0397] 1> If the MAC entity receives an LTM cell handover command (MAC CE) on the serving cell:
[0398] 2> Indicate to the upper layer that the LTM cell handover process has been triggered and the target configuration ID included in the MAC CE;
[0399] 2> If the MAC CE includes a secondary key ID, or if the MAC CE includes a secondary key ID with a value greater than 0:
[0400] 3> Indicate the secondary key ID to the upper layer.
[0401] In some embodiments, the LTM cell transition command MAC CE may include a secondary key counter (SK counter) field, which indicates secondary security key update information for LTM. Existing or enhanced LTM cell transition commands MAC CE may be used. The MAC CE may be identified by a MAC subheader having the eLCID specified in Table 2.
[0402] Figure 16 An example of an LTM cell switching command MAC CE 1600 according to an embodiment is shown.
[0403] Reference Figure 16 The LTM cell switching command MAC CE 1600 includes the SK field and the SK counter field.
[0404] The SK field indicates whether secondary security key update information exists in the MAC CE 1600. This field can be set to 1 to indicate the presence of the SK counter field. Conversely, this field can be set to 0 to indicate that the SK counter field does not exist, and instead, an R bit is present. The length of this field can be one (1) bit.
[0405] The SK counter field indicates the value of the SK counter used to derive the secondary key S-KgNB. This field can be 16 bits long. Fields set to 0, 1, …, 65535 indicate integer values 0, 1, …, 65535 respectively.
[0406] In some embodiments, when the LTM cell transition command MAC CE is received, the UE performs the following operations in the MAC layer: The MAC entity may:
[0407] 1> If the MAC entity receives an LTM cell handover command (MAC CE) on the serving cell:
[0408] 2> Indicate to the upper layer that the LTM cell handover process has been triggered and the target configuration ID included in the MAC CE;
[0409] 2> If the MAC CE includes secondary security key update information (e.g., the SK-Counter field)
[0410] 3> Indicate secondary security key update information to the upper layer (e.g., field SK counter).
[0411] Figure 17 An example of an LTM cell switching command MAC CE 1700 according to an embodiment is shown.
[0412] Reference Figure 17 The LTM cell switching command MAC CE 1700 includes a master key (MK) field.
[0413] When the MK field is set to 1, it indicates a request for a master security key update. When the field is set to 0, it indicates that a master security key is not requested. The length of this field can be one (1) bit. Figure 17 Other fields not described in this disclosure are similar to or the same as fields in existing MAC CE.
[0414] In some embodiments, when an LTM cell transition command MAC CE is received, the UE performs the following procedures in the MAC layer. The MAC entity may:
[0415] 1> If the MAC entity receives an LTM cell handover command (MAC CE) on the serving cell:
[0416] 2> Indicate to the upper layer that the LTM cell handover process has been triggered and the target configuration ID included in the MAC CE;
[0417] 2> If a master security key update request is indicated in the MAC CE
[0418] 3> Indicate a master security key update request to the upper layer.
[0419] Figure 18 An example procedure 1800 for updating a master security key according to an embodiment is shown. For illustrative and explanatory purposes, example procedure 1800 can be performed by a UE. Although one or more operations are described or shown in a specific order, in other embodiments, the operations may be rearranged in a different order, which may include performing multiple operations in at least partially overlapping time periods.
[0420] refer to Figure 18 Procedure 1800 can begin in operation 1801. In operation 1801, the UE receives master security key update information for one or more candidate cells from the serving cell. In some embodiments, the UE receives a master security key update identifier for each candidate cell from the serving cell.
[0421] In operation 1803, the UE receives from the serving cell a command indicating that a cell handover has been triggered from the serving cell to a target cell among one or more candidate cells. In some embodiments, the command includes a primary security update information identifier associated with the target cell.
[0422] In Operation 1805, the UE performs a cell handover from the serving cell to the target cell.
[0423] In operation 1807, the UE performs a security update for the target cell based on the master security key update information associated with the target cell. In some embodiments, the UE maintains a variable storing the master security key update identifier of the serving cell and performs the security update based on determining that the master security key update identifier of the target cell is different from the master security key update identifier of the serving cell stored in the variable. In some embodiments, the UE replaces the master security key update identifier stored in the variable with the master security key update identifier of the target cell.
[0424] In some embodiments, the UE receives a list of master security update information including one or more entries for a corresponding candidate cell. Each entry includes master security key update information. The UE performs a security update based on the master security key update information in a predetermined entry or indicated entry in the list of master security update information associated with the target cell. The UE removes the predetermined entry or indicated entry from the list of master security update information associated with the target cell.
[0425] In some embodiments, the UE receives primary security update information associated with the target cell in a cell handover command. The UE performs a security update for the target cell based on the primary security update information.
[0426] In some embodiments, the master security key update information includes a first field indicating whether the UE needs to export a new master security key and a second field including parameters for exporting the new master security key.
[0427] Figure 19 This is a block diagram of the internal configuration of the UE according to an embodiment.
[0428] like Figure 19 As shown, the UE according to the embodiment may include a transceiver 1910, a memory 1920, and a processor 1930. The transceiver 1910, memory 1920, and processor 1930 of the UE can operate according to the communication method of the UE described above. However, the components of the UE are not limited thereto. For example, the UE may include more or fewer components than those described above. Furthermore, the processor 1930, transceiver 1910, and memory 1920 may be implemented as a single chip. In addition, the processor 1930 may include at least one processor.
[0429] also, Figure 19 The UE corresponds to Figure 3A UE.
[0430] Transceiver 1910 is collectively referred to as UE receiver and UE transmitter, and can transmit signals to or receive signals from a base station or network entity. Signals transmitted to or received from a base station or network entity may include control information and data. Transceiver 1910 may include an RF transmitter for up-converting and amplifying the frequency of the transmitted signal, and an RF receiver for amplifying the frequency of the received signal for low noise and down-conversion. However, this is only an example of transceiver 1910, and the components of transceiver 1910 are not limited to RF transmitters and RF receivers.
[0431] In addition, transceiver 1910 can receive signals via a wireless channel and output them to processor 1930, and can also transmit signals output from processor 1930 via a wireless channel.
[0432] The memory 1920 can store programs and data required for the operation of the UE. Furthermore, the memory 1920 can store control information or data included in signals received by the UE. The memory 1920 can be a storage medium such as read-only memory (ROM), random access memory (RAM), hard disk, CD-ROM, and DVD, or a combination of storage media.
[0433] The processor 1930 can control a series of processes to enable the UE to operate as described above. For example, the transceiver 1910 can receive data signals including control signals transmitted by a base station or network entity, and the processor 1930 can determine the result of receiving the control signals and data signals transmitted by the base station or network entity.
[0434] Figure 20 This is a block diagram of the internal configuration of a base station or network entity according to an embodiment.
[0435] like Figure 20 As shown, a base station or network entity according to an embodiment may include a transceiver 2010, a memory 2020, and a processor 2030. The transceiver 2010, memory 2020, and processor 2030 of the base station or network entity can operate according to the communication method of the base station or network entity described above. However, the components of the base station or network entity are not limited thereto. For example, the base station or network entity may include more or fewer components than those described above. Additionally, the processor 2030, transceiver 2010, and memory 2020 may be implemented as a single chip. Furthermore, the processor 2030 may include at least one processor.
[0436] also, Figure 20 The base station (or network entity) corresponds to Figure 3B The base station.
[0437] Transceiver 2010 is collectively referred to as a base station (or network entity receiver) and a base station (or network entity) transmitter, and can transmit / receive signals to / from a terminal, network entity, or base station. Signals transmitted to or received from a terminal, network entity, or base station may include control information and data. Transceiver 2010 may include an RF transmitter for up-converting and amplifying the frequency of the transmitted signal, and an RF receiver for amplifying the frequency of the received signal for low noise and down-converting. However, this is only an example of transceiver 2010, and the components of transceiver 2010 are not limited to RF transmitters and RF receivers.
[0438] In addition, transceiver 2010 can receive signals via a wireless channel and output them to processor 2030, and can also transmit signals output from processor 2030 via a wireless channel.
[0439] The memory 2020 can store programs and data required for the operation of a base station or network entity. Furthermore, the memory 2020 can store control information or data included in signals acquired by the base station or network entity. The memory 2020 can be a storage medium such as a read-only memory (ROM), random access memory (RAM), hard disk, CD-ROM, and DVD, or a combination of storage media.
[0440] The processor 2030 can control a series of processes to cause the base station or network entity to operate as described above. For example, the transceiver 2010 can receive data signals including control signals transmitted by the terminal, network entity, or base station, and the processor 2030 can determine the result of receiving the control signals and data signals transmitted by the terminal, network entity, or base station.
[0441] This disclosure provides various embodiments for performing master security key updates in various scenarios, such as subsequent LTM or conditional LTM, both inter-CU and intra-CU LTM. This disclosure provides various embodiments to provide configurations for master security key updates for LTM candidate cell lists and security key update procedures for LTM cell transitions.
[0442] Unless otherwise specified, references to singular elements are not intended to indicate one and only one, but rather one or more. For example, a “one” module can refer to one or more modules. In the absence of further constraints, elements preceded by “a,” “an,” “the,” or “the” do not preclude the presence of additional identical elements.
[0443] Titles and subtitles (if any) are used for convenience only and do not limit this disclosure. Words of example are used to indicate that they are intended as examples or illustrations. Within the scope of the use of terms such as “comprising,” “having,” etc., such terms are intended to be inclusive in a manner similar to the term “comprising,” as “comprising” is interpreted when used as a transitional word in the claims. Relational terms such as “first” and “second” may be used to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between these entities or actions.
[0444] Phrases such as aspect, that aspect, on the other hand, some aspects, one or more aspects, implementation, that implementation, another implementation, some implementations, one or more implementations, embodiment, that embodiment, another embodiment, some embodiments, one or more embodiments, configuration, that configuration, another configuration, some configurations, one or more configurations, subject matter, disclosure, this disclosure, other variations thereof, etc., are used for convenience and do not imply that disclosures associated with such phrases are essential to the subject matter, or that such disclosures apply to all configurations of the subject matter. Disclosures associated with such phrases may apply to all configurations or one or more configurations. Disclosures associated with such phrases may provide one or more examples. Phrases such as aspect or some aspects may refer to one or more aspects, and vice versa, and this similarly applies to other foregoing phrases.
[0445] The phrase "at least one" preceding a series of items, separated by the terms "and" or "or," modifies the list as a whole, rather than each member of the list. The phrase "at least one of..." does not require the selection of at least one item; rather, it allows for the inclusion of at least one of any one item, and / or at least one of any combination of items, and / or at least one of each item. For example, each of the phrases "at least one of A, B, and C" or "at least one of A, B, or C" refers to only A, only B, or only C; any combination of A, B, and C; and / or at least one of each of A, B, and C.
[0446] It should be understood that the specific order or hierarchy of the disclosed steps, operations, or processes is an explanation of exemplary methods. Unless otherwise expressly stated, it should be understood that the specific order or hierarchy of steps, operations, or processes may be performed in a different order. Some steps, operations, or processes may be performed simultaneously, or may be performed as part of one or more other steps, operations, or processes. The appended method claims (if any) present elements of various steps, operations, or processes in a sample order, but this does not imply limitation to the specific order or hierarchy presented. These may be performed serially, linearly, in parallel, or in different orders. It should be understood that the described instructions, operations, and systems can generally be integrated together in a single software / hardware product or packaged into multiple software / hardware products.
[0447] This disclosure is provided to enable any person skilled in the art to practice the various aspects described herein. In some cases, well-known structures and components are shown in block diagram form to avoid obscuring the concept of the subject matter. This disclosure provides numerous examples of the subject matter, and the subject matter is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the principles described herein can be applied to other aspects.
[0448] All structural and functional equivalents of the various aspects described throughout this disclosure, which are now or hereafter known to a person skilled in the art, are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is explicitly stated in the claims. No claim element is to be interpreted pursuant to paragraph 6 of 35 U.S.SC § 112 unless it is explicitly stated using the phrase “means for…” or, in the case of a method claim, using the phrase “steps for…”.
[0449] The title, background art, description of the drawings, abstract, and figures are incorporated herein by reference and are provided as illustrative examples rather than as limiting descriptions. It should be understood at the time of filing that they are not intended to limit the scope or meaning of the claims. Furthermore, the detailed description provides illustrative examples, and various features are combined in various embodiments for the purpose of simplifying this disclosure. The approach of this disclosure should not be construed as reflecting an intention to require more features than expressly recited in each claim. Rather, as reflected in the following claims, the inventive subject matter lies in all features of fewer than those in a single disclosure configuration or operation. The appended claims are incorporated herein by reference, wherein each claim is independently claimed as a separate subject matter.
[0450] The claims are not intended to be limited to the aspects described herein, but rather to conform to the full scope consistent with the language claims and to include all legal equivalents. Nevertheless, no claim is intended to include subject matter that does not meet the requirements of applicable patent law, nor should they be interpreted in this manner.
Claims
1. A user equipment (UE) in a wireless communication system, the UE comprising: The transceiver is configured as follows: Receive master security key update information for at least one candidate cell from the base station (BS); and The BS received an instruction that triggered a cell handover from the serving cell to a target cell among at least one of the candidate cells; and A processor operatively coupled to the transceiver, the processor being configured to: Perform cell handover from the serving cell to the target cell; and A security update for the target cell is performed based on the master security key update information associated with the target cell.
2. The UE according to claim 1, wherein: The transceiver is also configured to: Receive the master security key update identifier for each candidate cell from the BS; and The processor is also configured to: Maintain the variable for updating the master security key of the storage service cell; and A security update is performed based on the fact that the master security key update identifier of the target cell is different from the master security key update identifier of the serving cell stored in a variable.
3. The UE according to claim 2, wherein, The processor is also configured to replace the master security key update identifier stored in the variable with the master security key update identifier of the target cell.
4. The UE according to claim 1, wherein, The transceiver is also configured to receive a list of master security update information including one or more entries for the corresponding candidate cells, each entry including master security key update information.
5. The UE according to claim 4, wherein, The processor is configured to perform a security update based on the master security key update information in a predetermined entry or indicated entry in a list of master security update information associated with the target cell.
6. The UE according to claim 5, wherein, The processor is also configured to remove predetermined or indicated entries from the list of primary security update information associated with the target cell.
7. A method performed by a user equipment (UE) in a wireless communication system, the method comprising: Receive master security key update information for at least one candidate cell from the base station (BS); The BS received an instruction that triggered a cell handover from the serving cell to a target cell among at least one of the candidate cells; Perform cell transfer from the serving cell to the target cell; and A security update for the target cell is performed based on the master security key update information associated with the target cell.
8. The method according to claim 7, further comprising: Receive the master security key update identifier for each candidate cell from the BS; Maintain the variable for updating the master security key of the storage service cell; and A security update is performed based on the fact that the master security key update identifier of the target cell is different from the master security key update identifier of the serving cell stored in a variable.
9. The method of claim 8 further includes replacing the master security key update identifier stored in the variable with the master security key update identifier of the target cell.
10. The method of claim 7, further comprising receiving a list including one or more entries of corresponding candidate cells, each entry including master security key update information.
11. The method according to claim 10, wherein, Security updates are performed based on master security key update information in a predefined or indicated entry in the list of master security update information associated with the target cell.
12. The method of claim 11 further includes removing a predetermined or indicated entry from the list of primary security update information associated with the target cell.
13. A base station (BS) in a wireless communication system, the BS comprising: The transceiver is configured as follows: Send master security key update information for at least one candidate cell to the user equipment (UE); and A command is sent to the UE indicating that a cell handover has been triggered from the serving cell of the BS to a target cell among at least one candidate cell. Among them, the master security key update information associated with the target cell is used for security updates to the target cell.
14. The BS according to claim 13, wherein, The transceiver is also configured to: Send the master security key update identifier for each candidate cell to the UE.
15. A method performed by a base station (BS) in a wireless communication system, the method comprising: Send master security key update information for at least one candidate cell to the user equipment (UE); and A command is sent to the UE indicating that a cell handover has been triggered from the serving cell of the BS to a target cell among at least one candidate cell. Among them, the master security key update information associated with the target cell is used for security updates to the target cell.