Security updating method and device

By receiving and calculating the security key of the target auxiliary node for security updates, the security update problem in the SCG LTM process between central units is solved, which reduces latency and signaling overhead and improves communication efficiency.

CN120390215APending Publication Date: 2025-07-29MEDIATEK SINGAPORE PTE LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510051966.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-01-26
Filing Date
2025-01-13
Publication Date
2025-07-29

AI Technical Summary

Technical Problem

In mobile communication, during the mobility (LTM) process triggered by the secondary cell group (SCG) layer 1/layer 2 between central units, the prior art fails to effectively solve the problem of security updates, resulting in increased delay and signaling overhead.

Method used

Through the mobility LTM configuration triggered by receiving layer 1/layer 2, the security key of the target secondary node is calculated and the message is encrypted using the key for security updates.

Benefits of technology

Reduces the delay and signaling overhead during cell handover and improves the throughput of user equipment.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120390215A_ABST
    Figure CN120390215A_ABST
Patent Text Reader

Abstract

The invention provides a security updating method and device. One embodiment provides a security update method, comprising: receiving, by a processor of an apparatus, a mobility LTM configuration triggered by a Layer 1 / Layer 2 associated with a Secondary Cell Group (SCG) from a network node; the processor obtains a security key of a target auxiliary node SN, wherein the security key of the target SN is calculated based on the LTM configuration; and transmitting, by the processor, at least one message encrypted with the security key of the target SN to the target SN. By using the invention, the mobility management can be better carried out.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention generally relates to mobile communications, and more specifically, to security updates for secondary cell group (SCG) layer 1 / layer 2 triggered mobility (LTM) in an inter-Central Unit (CU) scenario for a User Equipment (UE) and a network device in mobile communications. Background Art

[0002] Unless otherwise stated, the methods described in this section are not prior art for the claims and are not considered prior art merely by being included in this section.

[0003] In mobile communications, handover refers to the process of transferring an ongoing communication session of a user equipment from one cell to another in a connected state to ensure seamless connectivity and service continuity for the user, especially when the user is moving. In a traditional handover (e.g., a type of cell handover) specified in 3GPP R17, the serving cell handover is triggered by layer 3 (L3) measurements and switches from the serving cell to the target cell through Radio Resource Control (RRC) signaling. This L3-based mobility involves reconfiguration of the upper layers (e.g., the RRC layer and / or the Packet Data Convergence Protocol (PDCP) layer) and reset of the lower layers (e.g., the Media Access Control (MAC) layer and / or the Physical (PHY) layer), which inevitably results in long latency, high signaling overhead, and long interruption time. In R18, a low layer-triggered mobility (also known as LTM) was introduced to enable the cell handover process through L1 or L2 signaling, which can maintain the configuration of the upper layer and / or minimize the changes in the lower layer configuration to reduce the latency during the cell handover process.

[0004] During the LTM process, LTM preparation and early synchronization are performed before the LTM cell handover execution. When the conditions are met, a cell handover command is indicated to the UE to trigger the cell handover process. In the preparation phase, the configuration for the candidate cell is pre-configured through an RRC message. However, since the current L1 / L2-based inter-CU mobility does not support security updates, a solution for the corresponding process needs to be developed. Summary of the Invention

[0005] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce the concepts, key points, benefits, and advantages of the novel and non-obvious technologies described in the present invention. Selected implementations are further described in the detailed description below. Therefore, the following summary is not intended to identify the basic features of the claimed subject matter nor to be used to determine the scope of the claimed subject matter.

[0006] An object of the present invention is to propose solutions or a solution to solve the security update problem related to SCG LTM in the CU - between scenario for a UE and a network device in mobile communication.

[0007] An embodiment of the present invention provides a security update method, including: receiving, by a processor of a device, a layer 1 / layer 2 triggered mobility LTM configuration related to a secondary cell group (SCG) from a network node; obtaining, by the processor, a security key of a target secondary node (SN), where the security key of the target SN is calculated based on the LTM configuration; and transmitting, by the processor, at least one message encrypted with the security key of the target SN to the target SN.

[0008] An embodiment of the present invention provides a device for security update, including: a transceiver configured to wirelessly communicate with a wireless network during operation; and a processor communicatively coupled to the transceiver such that during operation, the processor performs the following operations: receiving, via the transceiver, an LTM configuration related to an SCG from a network node; obtaining a security key of a target SN, where the security key of the target SN is calculated based on the LTM configuration; and transmitting, via the transceiver, at least one message encrypted with the security key of the target SN to the target SN.

[0009] The present invention provides a security update method, including: configuring, by a processor of a network node, at least one candidate SN for a UE; and transmitting, by the processor, an LTM configuration related to an SCG to the UE, where the LTM configuration includes at least one sk - counter list for security update of the candidate SN.

[0010] It should be noted that although the descriptions provided herein can be in the context of certain radio access technologies, networks, and network topologies, such as LTE, LTE - Advanced, LTE - Advanced Pro, 5G, NR, IoT, NB - IoT, IIoT, B5G, and 6G, the proposed concepts, solutions, and any variations / derivatives thereof can be implemented in other types of radio access technologies, networks, and network topologies, for other types of radio access technologies, networks, and network topologies, and implemented by other types of radio access technologies, networks, and network topologies. Therefore, the scope of the present invention is not limited to the examples described herein. Description of the Drawings

[0011] The accompanying drawings contain content for further understanding of the present invention and form a part of the present invention. These drawings illustrate embodiments of the present invention and, together with the description, are used to explain the principles of the present invention. It should be noted that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to their actual size in order to clearly illustrate the concepts of the present invention.

[0012] Figure 1 is an example mobile communication network according to an embodiment of the present invention.

[0013] Figure 2 This is an example scenario of the inter-central unit SCG LTM according to an embodiment of the present invention.

[0014] Figure 3 This is an example scenario of a security update according to an embodiment of the present invention.

[0015] Figure 4 This is another example scenario of security update according to an embodiment of the present invention.

[0016] Figure 5 is an example communication system according to an embodiment of the present invention.

[0017] Figure 6 is an example process according to an embodiment of the present invention.

[0018] Figure 7 is an example process according to an embodiment of the present invention. DETAILED DESCRIPTION

[0019] The present invention discloses detailed embodiments and implementations of the claimed subject matter. However, it should be understood that the invented embodiments and implementations are merely illustrations of the claimed subject matter that can be implemented in various forms. Moreover, the present invention can be implemented in many different forms and should not be interpreted as being limited to the exemplary embodiments and implementations set forth in the present invention. On the contrary, these exemplary embodiments and implementations are provided to make the description of the present invention comprehensive and complete, and to fully convey the scope of the present invention to those skilled in the art. In the following description, details of known features and technologies may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.

[0020] Overview

[0021] Embodiments of the present invention relate to various technologies, methods, schemes, and / or solutions related to secure updates of SCG LTMs in inter-CU scenarios in mobile communications. According to the present invention, various possible solutions can be implemented individually or in combination. That is, while these possible solutions may be described separately below, two or more of these possible solutions may be implemented in one or more combinations.

[0022] Figure 1 is an example mobile communication network 100 according to an embodiment of the present invention. Figure 1As shown, the mobile communication network 100 supports various wireless communication services and can operate functionally between at least one core network 110 and multiple base stations (e.g., eNB, gNB, or transmission and reception point (TRP)) using different protocol split options. In some implementations, the multiple base stations can be gNBs implemented as a central unit (CU) 120 and distributed units (DUs) 130-132 associated with serving coverage / cells (e.g., cells 1-3). In some implementations, the service data application protocol (SDAP) and packet data convergence protocol (PDCP) layers can be located in the CU 120, while the radio link control (RLC), media access control (MAC), and physical (PHY) layers can be located in the DUs 130-132.

[0023] Figure 2 is an example scenario of SCG LTM between central units according to an embodiment of the present invention. As Figure 2 shown, the CUs 210-230 are respectively connected to the DUs 211-231. The DUs 211-231 are respectively connected to radio units (RUs) 213-233. Each cell 215-235 can be composed of the range covered by the corresponding RU 213-233. In this embodiment, the RU 213 provides a control plane connection to the core network in the case of multi-radio dual connectivity (MR-DC), so the RU 213 is referred to as the master node (MN) 213. The RUs 223 and 233 provide additional resources for the UE 201 in the case of MR-DC and are referred to as secondary nodes (SNs) 223 and 233. The SNs 223 and 233 may belong to the same or different radio access technologies (RATs). The protocol stacks including PDCP, RLC, and MAC are different in any two of the CUs 210-230 and the corresponding DUs 211-231.

[0024] In scenario 200, the process of supporting SCG LTM between central units is provided. The UE 201 may move from the edge of one cell to another cell, where the source cell and the target cell belong to different CUs. For example, the UE 201 may hand over from the SN 223 belonging to the CU 220 to the SN 233 belonging to the CU 230. In one embodiment, the SCG LTM is initiated by the SN (e.g., SN 223) without involving the MN 213. For example, signaling radio bearer 3 (SRB 3) signaling is used for SN-initiated SCG LTM, and the signaling is transmitted from the SN 223 to the UE 201. Alternatively, SRB3 signaling is used for SN-initiated SCG LTM, and the signaling is transmitted from the SN 223 to the MN 213 and then from the MN 213 to the UE 201. The signaling can originate from the SN 223 or the UE 201 and terminate at the peer end, regardless of whether SRB3 is used.

[0025] During the SCG LTM between central units, the user equipment 201 may receive an SCG-related LTM configuration (also referred to as an SCG LTM configuration) from the source SN 223. The SCG LTM configuration may be a radio resource control reconfiguration message, which includes an SCG configuration, such as one or more candidate SNs and a list of one or more security key counters (sk-counter) for SCG handover. In addition, the SCG LTM configuration may include an indication for indicating whether the candidate SN belongs to a different central unit. The UE 201 may obtain the security key of the target SN 233 calculated based on the SCG LTM configuration. In one example, the SCG LTM configuration may only contain a list of sk-counters, and a single list of sk-counters may be associated with all candidate SNs of the UE 201. For example, if there is only one candidate SN for the UE 201, a single list of sk-counters may be associated with one candidate SN, or if there are multiple candidate SNs for the UE 201, a single list of sk-counters may be associated with multiple candidate SNs. Alternatively, the SCG LTM configuration may include one or more sk-counter lists based on candidate SNs, and each sk-counter list is associated with a candidate SN. More specifically, the sk-counter list may include one or more sk-counters (or referred to as sk-counter values), and the security key of the target SN 233 may be calculated based on the master node security key (e.g., the security key of the MN 213) and one sk-counter selected from the sk-counter list. In one embodiment, the security key of the target SN 233 is calculated based on the MN security key and the first unused sk-counter in the sk-counter list. In addition, the UE 201 may obtain the RRC encryption key (i.e., KRRCenc) and the user plane (UP) encryption key (i.e., KUPenc) from the security key of the target SN 233 for encryption and integrity protection algorithms. After the SCG LTM cell handover between central units is completed, the UE 201 may transmit a message (e.g., an RRC reconfiguration complete message) encrypted with the security key of the target SN 233 to the target SN 233.

[0026] Figure 3This is an example scenario of a security update according to an embodiment of the present invention. In scenario 300, the SCG LTM is initiated by SN 310 without involving MN 320. In the SCG LTM preparation phase, as shown in operations 341 to 345, SN 310 starts the SCG LTM process and forwards an RRC reconfiguration message containing the SCG LTM configuration to UE 330. In one embodiment, the SCG LTM configuration includes an indication for each candidate SN to indicate whether the candidate SN belongs to a different CU. Before knowing which candidate SN is the target SN, as shown in operation 343, UE 330 can calculate and store the key for each candidate SN based on the sk-counter included in the SCG LTM configuration and the security key of MN 320. In one embodiment, the SCG LTM configuration includes a list of sk-counters for all candidate SNs (i.e., each UE provides a list of sk-counters). The sk-counter used for calculating the security key is the first unused sk-counter in the sk-counter list. In one example, all candidate SNs correspond to the same security key. That is, UE 330 performs the calculation once in operation 343, and the result (i.e., the security key) can be used for any target SN. In another embodiment, the SCG LTM configuration includes one or more sk-counter lists based on candidate SNs, and each sk-counter list based on a candidate SN is associated with a candidate SN (i.e., each SN provides a sk-counter list to UE). UE 330 calculates the security key for each candidate SN based on the first unused sk-counter in the corresponding sk-counter list. That is, UE 330 performs the calculation for each candidate SN in operation 343 so that each candidate SN has its own security key. In the early synchronization phase, as shown in operations 346 and 347, UE 330 can perform downlink (DL) synchronization and uplink (UL) synchronization with candidate cells (e.g., candidate SNs). In the SCG LTM execution phase, as shown in operations 348 to 352, UE 330 can transmit an L1 measurement report to SN 310 and receive an SCG LTM cell handover command (e.g., SCG LTM cell handover command MAC CE) from SN 310. In this embodiment, the target SN is indicated by the SCG LTM cell handover command. UE 330 can obtain the security key of the target SN from the security keys calculated and stored in operation 343 before. In the SCG LTM completion phase, as shown in operation 353, UE 330 can generate an RRC reconfiguration complete message and then forward it to the target SN to complete the LTM. The RRC reconfiguration complete message is encrypted with the security key of the target SN. As Figure 3As shown, during the LTM preparation phase, the security keys of all candidate SNs may be pre-computed and stored. This means that scenario 300 applies to the case of performing the fast RRC handling function.

[0027] Figure 4 is another example scenario of security update according to an embodiment of the present invention. In scenario 400, the SCG LTM is initiated by SN 410 without the participation of MN 420. As shown in operations 441 to 444, during the SCG LTM preparation phase, UE 430 receives an RRC reconfiguration message containing the SCG LTM configuration, such as a candidate SN list and at least one sk-counter list. In one example, the SCG LTM configuration includes a sk-counter list applicable to all candidate SNs. In another example, the SCG LTM configuration includes one or more candidate-SN-based sk-counter lists, each candidate-SN-based sk-counter list being associated with a candidate SN. As shown in operations 445 and 446, during the early synchronization phase, UE 430 may perform downlink synchronization and uplink synchronization with candidate cells (e.g., candidate SNs). As shown in operations 447 to 452, during the SCG LTM execution phase, UE 430 receives an SCG LTM cell handover command (e.g., an SCG LTM cell handover command MACCE) from SN 410, which command indicates the target SN to be switched to. As shown in operation 449, after receiving the SCG LTM cell handover command, UE 430 may compute the security key of the target SN. For example, UE 430 may compute the security key of the target SN based on the security key of MN 420 and the first unused sk-counter in the corresponding sk-counter list. In one embodiment, after computing the security key of the target SN, UE 430 may remove the currently used sk-counter from the sk-counter list and compute another security key for a subsequent SCG LTM based on the next unused sk-counter in the sk-counter list.

[0028] For example, if all candidate SNs share the same sk-counter list, and the list includes unused sk-counters A1, A2, and A3. After calculating the security key of the target SN using the unused sk-counter A1, it is removed from the list. Subsequently, the unused sk-counter A2 is used to calculate another security key for the next SCG LTM. When each candidate SN has its own different sk-counter list, the first unused sk-counter in another sk-counter list is used for the next SCG LTM. For example, if the LTM configuration includes sk-counter lists A and B, where sk-counter list A includes unused sk-counters A1, A2, and A3, and sk-counter list B includes unused sk-counters B1, B2, and B3. If the UE 430 calculates the security key of the target SN using the unused sk-counter A1, it is removed from sk-counter list A. The UE 430 can also calculate another security key for the next SCG LTM using sk-counter B1 in sk-counter list B.

[0029] When the UE 430 receives an indication of a subsequent SCG LTM, it can perform the security key calculation for the next target SN. Alternatively, the UE 430 can calculate and store the security key for the next target SN during the preparation phase of the subsequent SCG LTM. As shown in operation 453, at the completion phase of the SCG LTM, the UE 430 can generate an RRC reconfiguration complete message encrypted with the security key and transmit the encrypted RRC reconfiguration complete message to the target SN.

[0030] Although the above embodiments focus on SCG LTM between central units, it should be noted that the security update process of SCG LTM can also be used in the intra-central unit scenario. In the present invention, the term SN may refer to different base stations or different cells of the same CU / DU. The security key of the MN may also be referred to as KgNB, kgNB, KgNB, KNG-RAN, or other terms used in the art. The security key of the target SN may also be referred to as S-KgNB, s-kgNB, S-KNG-RAN, secondary key, or other terms used in the art. The sk-counter list may also be referred to as the sk-counter value list or other terms used in the art. The SCG LTM cell handover command MAC CE may also be referred to as the SCG cell handover command MAC CE, SCG LTM cell handover MAC CE, SCG LTM cell handover command, or other terms used in the art. The RRC reconfiguration message used in the SCG LTM preparation phase may also be referred to as the pre-configuration message, SCG LTM configuration message, SCG LTM pre-configuration message, or other terms used in the art.

[0031] Based on the above embodiments, the security update in the SCG LTM between central units can be supported. Compared with traditional SCG mobility, the SCG LTM between central units with security enhancements can reduce interruptions and signaling overhead and improve the throughput of the UE.

[0032] Exemplary Embodiments

[0033] Figure 5 FIG. 500 is an example communication system according to an embodiment of the present invention, which at least includes an example communication device 510 and an example network device 520. The communication device 510 and the network device 520 can perform various functions to implement the solutions, techniques, processes, and methods related to the security update of SCG LTM in the CU-to-CU scenario in mobile communication described herein, including the above scenarios / solutions and the processes 600 and 700 described below.

[0034] The communication device 510 can be part of an electronic device, which can be a UE, such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. For example, the communication device 510 can be implemented in a smartphone, a smartwatch, a personal digital assistant, a digital camera, or a computing device such as a tablet computer, a laptop computer, or a notebook computer. The communication device 510 can also be part of a machine-type device, which can be an IoT, NB-IoT, or IIoT device, such as a fixed or static device, a household device, a wired communication device, or a computing device. For example, the communication device 510 can be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. Alternatively, the communication device 510 can be implemented in the form of one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more reduced instruction set computing (RISC) processors, or one or more complex instruction set computing (CISC) processors. The communication device 510 can include Figure 5 at least some of the components shown in, such as the processor 512. The communication device 510 can also include one or more other components that are not relevant to the solution proposed in the present invention (e.g., an internal power supply, a display device, and / or a user interface device), but for the sake of brevity, these components of the communication device 510 are not shown in Figure 5 and are not described below.

[0035] The network device 520 can be part of a network equipment, which can be a network node, such as a satellite, a base station, a small cell, a router, or a gateway. For example, the network device 520 can be implemented as an eNB in an LTE network, as a gNB in a 5G / NR, Internet of Things, NB-IoT, or IIoT network, or as a satellite or a base station in a 6G network. The network device 520 can include Figure 5 at least some of the components shown in, such as the processor 522. The processor 522 can further include a protocol stack and a set of control function modules and circuits. The network device 520 can also include one or more other components that are not relevant to the solution proposed in the present invention (e.g., an internal power supply, a display device, and / or a user interface device), but for the sake of brevity, these components of the network device 520 are not shown in Figure 5 and are not described below.

[0036] On the one hand, each of the processors 512 and 522 can be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, even when using the singular term "a processor" to refer to the processors 512 and 522, according to some implementations of the present disclosure, each of the processors 512 and 522 may include multiple processors, while in other implementations may include a single processor. On the other hand, each of the processors 512 and 522 can be implemented in the form of hardware (and optionally, firmware), the electronic components of which include, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more variable capacitors, which are configured and arranged according to the specific purposes of the present disclosure. In other words, in at least some implementations, the processors 512 and 522 are special-purpose machines that are specifically designed, arranged, and configured to perform specific tasks in a device (e.g., represented by the communication device 510) and a network (e.g., represented by the network device 520) according to various implementations of the present disclosure.

[0037] In some implementations, the communication device 510 may further include a transceiver 516 coupled to the processor 512, capable of wirelessly transmitting and receiving data. In some implementations, the communication device 510 may further include a memory 514 coupled to the processor 512, which can be accessed by the processor 512 and store data therein.

[0038] In some implementations, the network device 520 may further include a transceiver 526 coupled to the processor 522, capable of wirelessly transmitting and receiving data, and a memory 524 that can be accessed by the processor 522 and store data therein. Accordingly, the communication device 510 and the network device 520 can communicate wirelessly through their respective transceivers 516 and 526.

[0039] For purposes of illustration and not limitation, descriptions of the capabilities of the communication device 510 and the network device 520 are provided below in processes 600 and 700. Among them, the communication device 510 is implemented as or serves as a communication device or a user equipment (UE), and the network device 520 is implemented as or serves as a network node (e.g., a base station) of a communication network.

[0040] Illustrative process

[0041] Figure 6is an example process 600 according to an embodiment of the present invention. Process 600 may represent a part or all of implementing the scenarios / schemes described above related to SCG LTM security update in the CU - to - CU scenario in mobile communication. Process 600 may represent an aspect of the functionality implementation of communication device 510. Process 600 may include one or more operations, actions, or functions, as shown by one or more blocks 610, 620, and 630. Although shown as discrete blocks, depending on the desired implementation, the various blocks of process 600 may be divided into more blocks, combined into fewer blocks, or deleted. In addition, the blocks of process 600 may be executed in the Figure 6 order shown, or may be executed in a different order. Process 600 may be implemented by communication device 510 or any suitable user equipment or machine - type device. For illustrative purposes only and without limitation, process 600 is described below in the context of communication device 510 as a user equipment. Process 600 may start from block 610.

[0042] In block 610, process 600 may involve the processor 512 of communication device 510 receiving, via transceiver 516, an LTM configuration related to the SCG from a network node (e.g., network device 520). Process 600 may continue from block 610 to block 620.

[0043] In block 620, process 600 may involve the processor 512 obtaining the security key of the target SN. The security key of the target SN is calculated based on the LTM configuration. Process 600 may continue from block 620 to block 630.

[0044] In block 630, process 600 may involve the processor 512 transmitting, via transceiver 516, at least one message encrypted with the security key to the target SN.

[0045] In some implementations, the LTM configuration may include a sk - counter list, where the sk - counter list is related to one or more candidate SNs.

[0046] In some implementations, the LTM configuration may include at least one sk - counter list, and each sk - counter list is related to a candidate SN.

[0047] In some implementations, the security key of the target SN is calculated based on the MN security key and a sk - counter selected from the sk - counter list included in the LTM configuration.

[0048] In some implementations, the selected sk - counter is the first unused sk - counter in the sk - counter list.

[0049] In some implementations, process 600 may further involve the processor 512 calculating multiple security keys for multiple candidate SNs during the LTM preparation phase. Additionally, process 600 may involve the processor 512 storing the multiple security keys. The security key for the target SN is obtained from the stored multiple security keys.

[0050] In some implementations, obtaining the security key for the target SN may further include calculating the security key for the target SN when receiving an SCG LTM cell handover command from a network node.

[0051] In certain implementations, the security key for the target SN is calculated based on the MN security key and the first unused sk-counter in the sk-counter list included in the LTM configuration. Process 600 may further involve the processor 512 removing the first unused sk-counter from the sk-counter list. Additionally, process 600 may involve the processor 512 calculating another security key for another SN based on the second unused sk-counter in the sk-counter list.

[0052] In certain implementations, process 600 may involve the processor 512 receiving an indication via the transceiver 516, where the indication is used to indicate whether a candidate SN belongs to a different CU.

[0053] Figure 7 is an example process 700 according to an embodiment of the present invention. Process 700 may represent a part or all of the scenarios / schemes described above related to SCG LTM security update in an inter-CU scenario in mobile communication. Process 700 may represent an aspect of the functionality implementation of the network device 520. Process 700 may include one or more operations, actions, or functions, as shown by one or more blocks 710 and 720. Although shown as discrete blocks, depending on the desired implementation, the various blocks of process 700 may be divided into more blocks, combined into fewer blocks, or deleted. Additionally, the blocks of process 700 may be executed Figure 7 in the order shown, or may be executed in a different order. Process 700 may be implemented by the network device 520 or any base station or network node. For illustrative purposes only and without limitation, process 700 is described below in the context of the network device 520. Process 700 may start from block 710.

[0054] In block 710, process 700 may involve the processor 522 of the network device 520 configuring at least one candidate SN for a UE (e.g., the communication device 510). Process 700 may proceed from 710 to 720.

[0055] At block 720, process 700 may involve the processor 522 transmitting, via transceiver 526, an LTM configuration related to the SCG to the UE. The LTM configuration may include at least one sk-counter list for security updates for candidate SNs.

[0056] In some implementations, process 700 may further involve the processor 522 transmitting, via transceiver 526, an indication as to whether a candidate SN belongs to a different CU.

[0057] Additional Notes

[0058] The subject matter described in this invention sometimes shows different components included in or connected to different other components. However, it should be understood that these depicted architectures are merely examples, and in fact many other architectures that implement the same functions can be implemented. In a conceptual sense, any arrangement of components that implement the same function is effectively "associated" so that the desired function can be achieved. Therefore, regardless of the architecture or intermediate components, any two components combined in this invention to achieve a specific function can be regarded as being "associated" with each other so that the desired function can be achieved. Similarly, any two components so associated can also be regarded as being "operationally connected" or "operationally coupled" to each other to achieve the desired function, and any two components that can be so associated can also be regarded as being "operationally couplable" to each other to achieve the desired function. Specific examples of being operationally couplable include, but are not limited to, components that can physically mate and / or physically interact and / or components that can wirelessly interact and / or wirelessly interact and / or components that can logically interact and / or logically interact.

[0059] Furthermore, regarding any plural and / or singular terms substantially used in this invention, those skilled in the art can convert from plural to singular and / or from singular to plural at an appropriate time according to the context and / or application. For the sake of clarity, various singular / plural permutations can be explicitly set forth in this invention.

[0060] In addition, those skilled in the art will understand that, generally, the terms used in the present invention and especially the terms used in the appended claims (e.g., the body of the appended claims) are generally meant to be "open" terms. For example, the term "comprising" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "including" should be interpreted as "including but not limited to", and so on. Those skilled in the art will also understand that if a specific number of introduced claim recitations is intended, such intention will be explicitly recited in the claim, and there is no such intention in the absence of such recitation. For example, for the sake of understanding, the appended claims may include the use of introductory phrases "at least one" and "one or more". However, the use of such phrases should not be construed as implying that any particular claim that introduces a claim recitation by the indefinite article "a" or "an" limits the introduced claim recitation to only including one embodiment of such recitation, even when the same claim includes an introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an". For example, "a and / or an" should be interpreted to mean "at least one" or "one or more", and the same applies to the use of definite articles used to introduce claim recitations. In addition, even if a specific number of introduced claim recitations is explicitly recited, those skilled in the art will also recognize that such recitation should be interpreted to mean at least the recited number. For example, in the absence of other modifiers, a basic recitation of "two recitations" means at least two recitations or two or more recitations. In addition, in cases where a convention similar to "at least one of A, B, and C, etc." is used, in the sense that those skilled in the art will understand the meaning of this convention, it generally means such an interpretation (e.g., "a system having at least one of A, B, and C" will include, but not be limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In cases where a convention similar to "at least one of A, B, or C, etc." is used, in the sense that those skilled in the art will understand the meaning of this convention, it generally means such an interpretation (e.g., "a system having at least one of A, B, or C" will include, but not be limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art should also understand that, whether in the specification, claims, or drawings, any conjunctive words and / or phrases that actually represent two or more alternatives should be understood to contemplate the possibility of including one of these items, any one of these items, or both of these items. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B".

[0061] As can be seen from the above, it is understood that various embodiments of the present invention have been described for illustrative purposes, and various modifications can be made without departing from the scope and spirit of the present invention. Therefore, the various embodiments disclosed in the present invention are not meant to be limiting, and the true scope and spirit are determined by the appended claims.

Claims

1. A security update method, comprising: receiving, by a processor of a device, a layer 1 / layer 2 triggered mobility (LTM) configuration related to a secondary cell group (SCG) from a network node; obtaining, by the processor, a security key of a target secondary node (SN), wherein the security key of the target SN is calculated based on the LTM configuration; and transmitting, by the processor, at least one message encrypted with the security key of the target SN to the target SN.

2. The security update method according to claim 1, wherein, The LTM configuration includes a list of security key counters (sk-counters), wherein the sk-counter list is related to one or more candidate SNs.

3. The security update method according to claim 1, wherein The LTM configuration includes at least one sk-counter list, and each sk-counter list is related to a candidate SN.

4. The security update method according to claim 1, wherein The security key of the target SN is calculated based on a master node (MN) security key and a sk-counter selected from the sk-counter list included in the LTM configuration.

5. The security update method according to claim 4, wherein The selected sk-counter is the first unused sk-counter in the sk-counter list.

6. The security update method according to claim 1, wherein Further comprising: calculating, by the processor, security keys of multiple candidate SNs during an LTM preparation phase; and storing, by the processor, the multiple security keys, wherein the security key of the target SN is obtained from the stored multiple security keys.

7. The security update method according to claim 1, characterized in that Obtaining the security key of the target SN further comprises: calculating, by the processor, the security key of the target SN when receiving an SCG LTM cell handover command from the network node.

8. The security update method according to claim 7, wherein The security key of the target SN is calculated based on the MN security key and the first unused sk-counter in the sk-counter list included in the LTM configuration. The method further comprises: removing, by the processor, the first unused sk-counter from the sk-counter list; and calculating, by the processor, another security key of another SN based on the second unused sk-counter in the sk-counter list.

9. The security update method according to claim 1, wherein Further comprising: receiving, by the processor, an indication, wherein the indication is used to indicate whether a candidate SN belongs to a different central unit.

10. A device for security update, comprising: a transceiver for wirelessly communicating with a wireless network during operation; and a processor communicatively coupled to the transceiver such that, during operation, the processor performs the following operations: receiving, via the transceiver, an LTM configuration related to an SCG from a network node; obtaining a security key of a target SN, wherein the security key of the target SN is calculated based on the LTM configuration; and transmitting, via the transceiver, at least one message encrypted with the security key of the target SN to the target SN.

11. The device according to claim 10, characterized in that, The LTM configuration includes a list of security key counters (sk-counters), wherein the sk-counter list is related to one or more candidate SNs.

12. The device according to claim 10, characterized in that, The LTM configuration includes at least one sk-counter list, and each sk-counter list is related to a candidate SN.

13. The device according to claim 10, characterized in that, The security key of the target SN is calculated based on the security key of the master node MN and an sk-counter selected from the sk-counter list included in the LTM configuration.

14. The device according to claim 13, characterized in that, The selected sk-counter is the first unused sk-counter in the sk-counter list.

15. The device according to claim 10, characterized in that, During operation, the processor also performs the following operations: Calculate the security keys of multiple candidate SNs during the LTM preparation phase; and Store the multiple security keys, wherein the security key of the target SN is obtained from the stored multiple security keys.

16. The device according to claim 10, characterized in that, Obtaining the security key of the target SN further includes: Calculating the security key of the target SN when receiving an SCG LTM cell handover command from the network node.

17. The device according to claim 16, characterized in that, The security key of the target SN is calculated based on the security key of the MN and the first unused sk-counter in the sk-counter list included in the LTM configuration, and during operation, the processor also performs the following operations: Remove the first unused sk-counter from the sk-counter list; and Calculate another security key of another SN based on the second unused sk-counter in the sk-counter list.

18. The device according to claim 10, wherein During operation, the processor also performs the following operations: Receive an indication through the transceiver, where the indication is used to indicate whether the candidate SN belongs to a different central unit.

19. A security update method, including: Configure at least one candidate SN for the UE by a processor of a network node; and Transmit an LTM configuration related to the SCG to the UE by the processor, where the LTM configuration includes at least one sk-counter list for security update of the candidate SN.

20. The security update method according to claim 19, further including: Transmit an indication by the processor to indicate whether the candidate SN belongs to a different CU.