Secure key derivation method and apparatus for layer 1 / layer 2 triggered mobility

Abstract

The invention provides a secure key derivation method and apparatus for layer 1 / layer 2 triggered mobility. One embodiment provides a security key derivation method for layer 1 / layer 2 triggered mobility, comprising: receiving, by a processor of an apparatus, security key update information from a network node during an LTM procedure; deriving, by the processor, a security key for the target cell based on the security key update information; performing, by the processor, an LTM cell handover to switch to the target cell; and transmitting, by the processor, a message encrypted with the security key to the target cell. By using the invention, the mobility management can be better carried out.

Description

Technical Field

[0001] The present invention generally relates to mobile communications, and more particularly, to security key derivation for Layer 1 (L1) / Layer 2 (L2) Triggered Mobility (LTM) associated with User Equipment (UE) and network equipment in mobile communications. Background Art

[0002] Unless otherwise indicated, the approaches described in this section are not prior art to the claims and are not admitted to be prior art by inclusion in this section.

[0003] In mobile communications, handover refers to the process of transferring an ongoing communication session of a user equipment (UE) from one cell to another in a connected state to ensure seamless connectivity and service continuity for users, particularly when on the move. In traditional handover (e.g., a type of cell handover) specified in 3GPP Release 17, serving cell handover is triggered by Layer 3 (L3) measurements, with the serving cell switched to the target cell via Radio Resource Control (RRC) signaling. This L3-based mobility involves reconfiguration of upper layers (e.g., the RRC layer and / or Packet Data Convergence Protocol (PDCP) layer) and reset of lower layers (e.g., the Medium Access Control (MAC) layer and / or the Physical (PHY) layer), which inevitably results in long delays, high signaling overhead, and long interruption times. In Release 18, a type of low-layer triggered mobility (also known as Layer 1 / Layer 2 Triggered Mobility (LTM)) was introduced to enable the cell handover process via L1 or L2 signaling. This can maintain upper layer configurations and / or minimize changes to lower layer configurations, thereby reducing delays during the cell handover process.

[0004] During the LTM process, LTM preparation and pre-synchronization are performed before executing an LTM cell handover. When conditions are met, a cell handover command is issued to the UE, triggering the cell handover process. During the preparation phase, candidate cell configurations are pre-configured via RRC messages. However, since current L1 / L2-based inter-CU mobility does not support security updates, a solution for this 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 techniques described herein. Selected implementations are further described in the detailed description below. Therefore, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter.

[0006] An object of the present invention is to propose a solution or arrangement to solve the problems related to conditional LTM in relation to user equipment and network equipment in mobile communications.

[0007] An embodiment of the present invention provides a security key derivation method for layer 1 / layer 2 triggered mobility, comprising: a processor of a device receiving security key update information from a network node during an LTM process; the processor deriving a security key of a target cell based on the security key update information; the processor performing LTM cell switching to switch to the target cell; and the processor transmitting a message encrypted with the security key to the target cell.

[0008] An embodiment of the present invention provides an apparatus comprising: a transceiver configured to perform wireless communications during operation; and a processor communicatively coupled to the transceiver, such that during operation, the processor performs the following operations: receiving security key update information from a network node via the transceiver during an LTM process; deriving a security key of a target cell based on the security key update information; performing an LTM cell handover to handover to the target cell; and transmitting a message encrypted with the security key to the target cell via the transceiver.

[0009] An embodiment of the present invention provides a security key derivation method for layer 1 / layer 2 triggered mobility, comprising: determining, by a processor of a network node, at least one candidate cell for a UE; and transmitting, by the processor, security key update information to the UE during an LTM process for security key derivation associated with the at least one candidate cell.

[0010] It is worth noting that although the description provided herein may 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 concepts, solutions, and any variations / derivatives thereof may be implemented in, for, and 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings are included to provide a further understanding of the present invention and constitute a part of this disclosure. These drawings illustrate embodiments of the present invention and, together with the description, serve to explain the principles of the 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 1is an example mobile communication network according to an embodiment of the present invention.

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

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

[0015] Figure 4 This is another example scenario of security key derivation 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 derivation of secure keys for LTMs 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 individually 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, a mobile communication network 100 supports various wireless communication services and can operate using different protocol splitting options between at least one core network 110 and multiple base stations (BSs), such as evolved Node Bs (eNBs), next-generation Node Bs (gNBs), or transmission and reception points (TRPs). In some embodiments, the multiple base stations can be implemented as gNBs as a central unit (CU) 120 and distributed units (DUs) 130-132 associated with service coverage / cells (e.g., cells 1-3). In some embodiments, the service data application protocol (SDAP) and PDCP layers may be located in the CU 120, while the radio link control (RLC), medium access control (MAC), and physical (PHY) layers may be located in the DUs 130-132.

[0023] Figure 2 This is an example scenario of inter-CU LTM according to an embodiment of the present invention. Figure 2 As shown, CUs 210 and 220 are connected to core network 205 via a next generation (NG) interface. CUs 210 and 220 are connected to each other via an Xn interface. In scenario 200, each CU is connected to two DUs via an F1 interface, and each DU is connected to multiple radio units (RUs). A cell can consist of the coverage area of ​​one or more RUs under the same DU. For example, CU 210 is connected to DUs 211 and 212, DU 211 is connected to RUs 213, 214, and 215, and cell 216 consists of the coverage area of ​​RU 213.

[0024] In scenario 200, user equipment 201 may move from the edge of one cell to another, where the source and target cells may belong to different CUs. For example, UE 201 moves from cell 216 belonging to CU 210 to cell 225 belonging to CU 220. The protocol stacks including PDCP, RLC, and MAC in CUs 210 and 220, and corresponding DUs 211 and 221, are different. In scenario 200, an inter-CU LTM procedure can be used to reduce outages and improve throughput for UE 201. In one embodiment, dynamic vertical security key derivation can be supported during the inter-CU LTM procedure.

[0025] Specifically, UE 201 may receive security key update information from a BS associated with RU 213 during the inter-CU LTM process. In one embodiment, the security key update information is received during the LTM preparation phase of the inter-CU LTM process. For example, the security key update information may be carried by a radio resource control (RRC) message (e.g., an RRC reconfiguration message that specifies an LTM candidate configuration). In another embodiment, the security key update information may be received during the LTM cell switching execution phase. For example, the security key update information may be carried by an LTM cell switching command, which may be carried by a MAC-control element (CE) message. In another embodiment, the security key update information may be received before UE 201 receives the LTM cell switching command. For example, the security key update information is carried by a MAC-CE message different from the LTM cell switching command, or the security key update information is indicated by a downlink control information (DCI) format. In another embodiment, the security key update information may be indicated by a message received at the same or different phases of the inter-CU LTM process. For example, the security key update information may be indicated by a combination of an RRC message received in the LTM preparation phase and an LTM cell handover command received in the LTM cell handover execution phase. The security key update information may include one or more next hop link counter (NCC) values ​​or NCC-related information related to the LTM candidate cell. In addition, according to one embodiment, the security key update information is used for the current LTM cell handover indicated by the LTM cell handover command. Based on the security key update information, the UE 201 can determine whether to perform a vertical key derivation process or a horizontal key derivation process for the target cell of the current LTM cell handover. In another embodiment, the security key update information is used for the next LTM cell handover. Based on the security key update information, the UE 201 can perform a vertical or horizontal key derivation process for the target cell of the next LTM cell handover in advance.

[0026] Figure 3This is an example scenario of security key derivation according to an embodiment of the present invention. In the inter-CU LTM process 300, the user equipment 310 receives security key update information during the LTM preparation phase. Specifically, as shown in operations 331 to 333, the UE 310 in RRC connection mode may send a measurement report to the base station 320, and then the BS 320 decides to configure LTM (for example, determine one or more LTM candidate cells for the UE 310). In operation 334, the BS 320 transmits an RRC reconfiguration message containing the LTM candidate configuration and security key update information to the UE 310. In one example, the security key update information may include one or more NCC values ​​of the candidate cells. Alternatively, the security key update information may include NCC-related information of the candidate cells. In operation 335, the UE 310 stores the LTM candidate configuration and security key update information, and transmits an RRC reconfiguration completion message to the BS 320. The UE 310 may store the identifiers of all candidate cells for future security key updates. Then, in the early synchronization phase as shown in operations 336 and 337, the UE 310 performs downlink (DL) synchronization and uplink (UL) synchronization with the candidate cell.

[0027] During the LTM cell handover execution phase, as shown in operations 338 to 340, UE 310 may perform L1 measurements on candidate cells and transmit L1 measurement reports to BS 320. BS 320 then decides to perform a cell handover to the target cell and transmits an LTM cell handover command MAC-CE to UE 310. In operation 341, UE 310 derives the target cell's security key based on the security key update information received in operation 334 and the target cell identifier (ID) included in the LTM cell handover command MAC-CE. For example, based on the security key update information included in the current LTM cell handover indication, UE 310 may perform a vertical key derivation process to derive the target cell's security key. As shown in operations 342 and 343, UE 310 switches to the target cell, applies configurations related to the target cell, and performs a random access channel (RACH) procedure on the target cell.

[0028] Finally, in the LTM cell handover completion phase, as shown in operation 344, UE 310 completes the LTM cell handover process by sending an RRC reconfiguration complete message to the target cell. Specifically, the RRC reconfiguration complete message is encrypted using the security key of the target cell derived in operation 341.

[0029] Figure 4This is another example scenario for security key derivation according to an embodiment of the present invention. In the inter-CU LTM process 400, security key update information is received during the LTM cell handover execution phase. As shown in operation 410, the RRC reconfiguration message from BS 320 may include the LTM candidate configuration. As shown in operation 420, the security key update information is included in the LTM cell handover command. Figure 4 and Figure 3 Operations with the same reference numerals shown in FIG. 5 may be the same or similar, and thus detailed descriptions are omitted here.

[0030] In the aforementioned embodiments, the manner in which the vertical key derivation process is performed may be related to the content of the security key update information, where the above information is conveyed by one or a combination of the LTM Candidate Configuration message, the LTM Cell Handover Command MAC-CE, and a new message received before the LTM Cell Handover is executed. In one embodiment, when the security key update information includes an explicit NCC value for the candidate cell, the security key for the target cell may be derived based on the NCC value and the target cell ID. For example, the next hop (NH) value is first derived based on the NCC value of the target cell included in the security key update information, and then the security key is derived based on the NH value and the target cell ID. In another embodiment, the NCC value is not directly provided to the UE (e.g., due to security considerations). Instead, the base station provides NCC-related information to the UE as security key update information. The NCC-related information may be an NCC increment indicator, the difference between the new NCC value and the previous NCC value, or parameters of a specific formula used to derive the NCC value. The NCC value of the target cell is first derived based on the NCC-related information. Subsequently, the security key for the target cell is derived based on the derived NCC value and the target cell ID. For example, the NH value is derived based on the derived NCC value, and then the security key is derived based on the NH value and the target cell ID. In one example, the new NCC value of the target cell can be determined by increasing the previous NCC value by a specific value (e.g., 1), where this increment is indicated by an NCC increment indicator. Specifically, the UE may be pre-configured with a list of increment values. During the vertical key derivation process, an increment value is selected from these increment values ​​based on the NCC increment indicator to increase the previous NCC value. In another example, the new NCC value of the target cell may be equal to the previous NCC value plus the difference between the new NCC value and the previous NCC value, where the difference is indicated by the security key update information. In another example, the new NCC value of the target cell may be derived using a specific formula that takes as input the parameters indicated by the security key update information and the previous NCC value. In the aforementioned example, the previous NCC value is maintained by the UE and may be the NCC value of the current serving cell or the NCC value of the target cell in the previous LTM cell handover. The formula is maintained by the UE and the core network (e.g., the Access and Mobility Management Function (AMF)). In another embodiment, when security key update information is delivered via two or more messages, the UE may first determine the target cell's NCC value based on these messages and then derive the target cell's security key. For example, the NCC value list may be preconfigured by the LTM Candidate Configuration message, and the index for selecting the NCC value may be indicated by the LTM Cell Handover Command MAC-CE message. The UE may derive the target cell's NCC value based on the LTM Candidate Configuration message and the LTM Cell Handover Command MAC-CE message, and then derive the target cell's security key.

[0031] In one embodiment, if security key update information for the vertical key derivation process is missing, the UE may perform a horizontal key derivation process to derive security keys for the target cell. For example, at a specific stage of the LTM process, the UE may expect to receive one or more specific messages carrying security key update information for the vertical key derivation process. If the UE does not receive such messages, or if the message indicates that the vertical key derivation process should not be performed for the current LTM cell handover, the UE may perform a horizontal key derivation process for the target cell.

[0032] In one embodiment, the target cell's security key or any intermediate data generated during the vertical and / or horizontal key derivation process (e.g., newly derived NCC values ​​and / or NH values) may be stored for future security key updates. Furthermore, the UE may be instructed by a subsequent LTM cell handover command MAC CE to perform another LTM cell handover. In one example, the UE may perform a horizontal or vertical key derivation process based on the network's instructions (including security key information for the next LTM cell handover) and perform the same actions described above during the LTM cell handover execution and LTM cell handover completion phases. For example, assume that the UE is handing over from cell A to cell B in the current LTM cell handover and from cell B to cell C in the next LTM cell handover. During the LTM preparation phase or LTM cell handover execution phase of the LTM process for handovers from cell A to cell B, the UE may receive security key update information for the next LTM cell handover. During the current LTM process, the UE may derive the security key for cell C, the target cell for the next LTM cell handover, by performing a vertical or horizontal key derivation process based on the security key update information for the next LTM cell handover. Thus, delay is reduced by deriving the security key in advance.

[0033] Illustrative Embodiments

[0034] Figure 5 1 is an example communication system 500 according to an embodiment of the present invention, which includes at least 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 schemes, techniques, processes, and methods described herein related to secure key derivation for LTM in mobile communications, including the above-mentioned scenarios / schemes and processes 600 and 700 described below.

[0035] The communication device 510 may be part of an electronic device, which may 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 may be implemented in a smartphone, a smart watch, a personal digital assistant, a digital camera, or a computing device, such as a tablet, a laptop, or a notebook computer. The communication device 510 may also be part of a machine type device, which may be an IoT, NB-IoT, or IIoT device, such as a fixed or static device, a home device, a wired communication device, or a computing device. For example, the communication device 510 may 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 may 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 may include Figure 5 The communication device 510 may also include one or more other components not related to the solution proposed by the present invention (e.g., internal power supply, display device and / or user interface device), but for the sake of simplicity, these components of the communication device 510 are shown in FIG. Figure 5 Not shown in the figure, nor described below.

[0036] The network device 520 may be part of a network device, which may be a network node, such as a satellite, a base station, a small base station, a router, or a gateway. For example, the network device 520 may be implemented as an eNB in ​​an LTE network, as a gNB in ​​a 5G / NR, IoT, NB-IoT, or IIoT network, or as a satellite or base station in a 6G network. The network device 520 may include Figure 5 At least some of the components shown in FIG5 , such as processor 522. Processor 522 may further include a protocol stack and a set of control function modules and circuits. Network device 520 may also include one or more other components not related to the proposed solution of the present invention (e.g., an internal power supply, a display device and / or a user interface device), but for the sake of simplicity, these components of network device 520 are shown in FIG5 . Figure 5 Not shown in the figure, nor described below.

[0037] In one aspect, each of processor 512 and processor 522 can be implemented as one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, even when the singular term "a processor" is used to refer to processor 512 and processor 522, in some implementations of the present invention, each of processor 512 and processor 522 may include multiple processors, while in other implementations, each may include a single processor. In another aspect, each of processor 512 and processor 522 can be implemented in hardware (and optionally, firmware) whose electronic components 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, configured and arranged for the specific purposes of the present invention. In other words, in at least some implementations, processor 512 and processor 522 are special-purpose machines specifically designed, arranged, and configured to perform specific tasks in devices (e.g., represented by communication device 510) and networks (e.g., represented by network device 520) in accordance with various implementations of the present invention.

[0038] In some implementations, the communication device 510 may further include a transceiver 516 coupled to the processor 512 and 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 and capable of being accessed by the processor 512 and storing data therein.

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

[0040] For purposes of illustration and not limitation, a description of the capabilities of the communication apparatus 510 and the network apparatus 520 is provided below in processes 600 and 700. The communication apparatus 510 is implemented as or serves as a communication device or UE, and the network apparatus 520 is implemented as or serves as a network node (e.g., a base station) of a communication network.

[0041] Illustrative Process

[0042] Figure 66 is an example process 600 according to an embodiment of the present invention. Process 600 may represent a portion or all of the implementation of the scenario / scheme described above related to security key derivation for LTM in mobile communications. Process 600 may represent one aspect of the functional implementation of communication device 510. Process 600 may include one or more operations, actions, or functions, as shown in one or more blocks 610-640. Although shown as discrete blocks, the various blocks of process 600 may be divided into more blocks, combined into fewer blocks, or deleted depending on the desired implementation. In addition, the blocks of process 600 may be arranged in Figure 6 The process 600 is performed in the order shown, or may be performed in a different order. The process 600 may be implemented by the communication device 510 or any suitable UE or machine type device. For illustrative purposes only and without limitation, the process 600 is described below in the context of the communication device 510 being a user equipment. The process 600 may begin at block 610.

[0043] At block 610, process 600 may involve processor 512 of communication device 510 receiving security key update information from a network node (eg, network device 520) during an LTM process via transceiver 516. Process 600 may continue from block 610 to block 620.

[0044] At block 620 , process 600 may involve processor 512 deriving a security key for the target cell based on the security key update information.

[0045] At block 630 , process 600 may involve processor 512 performing an LTM cell handover to a target cell. Process 600 may continue from block 630 to block 640 .

[0046] At block 640 , process 600 may involve processor 512 transmitting, via transceiver 516 , a message encrypted with the security key to the target cell.

[0047] In some implementations, the security key update information is carried by an RRC message received during the LTM preparation phase.

[0048] In some implementations, the security key update information is carried by the LTM cell handover command.

[0049] In some implementations, the LTM cell switching command is carried by a MAC-CE message.

[0050] In some implementations, the security key update information is received prior to receiving the LTM cell handover command.

[0051] In some implementations, the security key update information is carried by a MAC-CE message different from the LTM cell handover command, or is indicated by a DCI format.

[0052] In some implementations, the security key update information includes an NCC value.Process 600 may further involve processor 512 deriving a security key for the target cell based on the NCC value and the target cell identifier.

[0053] In some implementations, the security key update information includes NCC-related information. Process 600 may further involve processor 512 deriving an NCC value based on the NCC-related information. In addition, process 600 may also involve processor 512 deriving a security key for the target cell based on the NCC value and the target cell identifier.

[0054] In some implementations, the NCC-related information may include an NCC increment indicator.

[0055] In some implementations, the NCC-related information may include a difference between the NCC value and the second NCC value.

[0056] In some implementations, the second NCC value may include a previous NCC value maintained in the communication device 510 .

[0057] In some implementations, the NCC-related information may include parameters of a formula used to derive the NCC value.

[0058] In some implementations, process 600 may further involve processor 512 storing the security key or intermediate data generated during derivation of the security key.

[0059] In some implementations, the security key update information is used for the security key derivation process of the next LTM cell handover.

[0060] In some implementations, the security key update information is used in a vertical key derivation process.Process 600 may further involve processor 512 performing a horizontal key derivation process to derive a security key when the security key update information is missing.

[0061] Figure 7 700 is an example process according to an embodiment of the present invention. Process 700 may represent a portion or all of the implementation of the scenario / scheme described above related to security key derivation for LTM in mobile communications. Process 700 may represent one aspect of the functional implementation of 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, the various blocks of process 700 may be divided into more blocks, combined into fewer blocks, or deleted depending on the desired implementation. In addition, the blocks of process 700 may be arranged in a manner such that: Figure 77. The process 700 may be performed in the order shown, or may be performed in a different order. Process 700 may be implemented by network device 520 or any base station or network node. For illustration purposes only and without limitation, process 700 will be described below in the context of network device 520. Process 700 may begin at block 710.

[0062] At block 710 , process 700 may involve processor 522 of network device 520 determining at least one candidate cell for a UE (eg, communication device 510 ). Process 700 may continue from block 710 to block 720 .

[0063] At block 720 , process 700 may involve processor 522 transmitting, via transceiver 526 , security key update information to the UE during an LTM process for security key derivation associated with at least one candidate cell.

[0064] In some implementations, security key update information is transmitted via transceiver 526 during the LTM preparation phase.

[0065] In some implementations, the security key update information is carried by the LTM cell handover command.

[0066] In some implementations, the security key update information may include an NCC value or NCC-related information.

[0067] Additional Notes

[0068] The subject matter described in the present 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 achieve the same function can be implemented. In a conceptual sense, any arrangement of components that achieve the same function is effectively "associated" so that the desired function is achieved. Therefore, regardless of the architecture or intermediate components, any two components that are combined to achieve a specific function in the present invention can be regarded as "associated" with each other so that the desired function is achieved. Similarly, any two components that are so associated can also be regarded as "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 "operationally couplable" to each other to achieve the desired function. Specific examples of operational coupling include, but are not limited to, components that can be physically matched and / or physically interacted and / or components that can wirelessly interact and / or wirelessly interact and / or components that logically interact and / or logically interactable.

[0069] Furthermore, with respect to any plural and / or singular terms used in the present invention, those skilled in the art may convert from plural to singular and / or from singular to plural as appropriate for the context and / or application. For clarity, various singular / plural interchangeability may be explicitly stated in the present invention.

[0070] Furthermore, those skilled in the art will understand that, in general, the terms used in the present invention and particularly in the appended claims (e.g., the bodies of the appended claims) are generally intended to be “open-ended” terms, e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “comprising” 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 an introduced claim recitation is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation, such intent is absent. For example, to aid understanding, the appended claims may include the use of the introductory phrases “at least one” and “one or more.” However, the use of such phrases should not be interpreted as implying that a claim recitation, introduced by the indefinite article “a” or “an,” will include any particular claim of such introduced claim recitation to embodiments that include only one such recitation, even when the same claim includes the introductory phrases “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.” The same applies to the use of definite articles used to introduce claim recitations. Furthermore, even when a specific number of an introduced claim recitation is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the basic recitation of "two recitations" without other modifiers means at least two recitations or two or more recitations. Furthermore, where a convention similar to "at least one of A, B, and C, etc." is used, such interpretation is generally intended in the sense that one skilled in the art would understand this convention (e.g., "a system having at least one of A, B, and C" would include but is not limited to systems having A alone, B alone, C alone, A and B together, A and C together, and / or A, B, and C together, etc.). Where a convention similar to "at least one of A, B, or C, etc." is used, such interpretation is generally intended in the sense that one skilled in the art would understand this convention (e.g., "a system having at least one of A, B, or C" would include but is not limited to systems having A alone, B alone, C alone, 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 will also understand that any transitional words and / or phrases that actually indicate two or more options, whether in the specification, claims, or drawings, should be understood to include the possibility of one, any, or both of these options. For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B".

[0071] It will be appreciated that various embodiments of the present invention have been described for illustrative purposes and that various modifications may be made without departing from the scope and spirit of the present invention. Therefore, the various embodiments disclosed herein are not intended to be limiting, and the true scope and spirit are to be determined by the appended claims.

Claims

1. A method for derivation of security keys for layer 1 / layer 2 triggered mobility, comprising: receiving, by a processor of the device, security key update information from a network node during a layer 1 / layer 2 triggered mobility LTM procedure; Derivation, by the processor, of a security key for the target cell based on the security key update information; executing, by the processor, an LTM cell handover to switch to the target cell; as well as The processor transmits a message encrypted with the security key to the target cell.

2. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 1, wherein: The security key update information is carried by the radio resource control RRC message received during the LTM preparation phase.

3. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 1, wherein: The security key update information is carried by the LTM cell switching command.

4. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 1, wherein: The security key update information is received before receiving the LTM cell switching command.

5. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 4, wherein: The security key update information is carried by a Media Access Control MAC-Control Element CE message different from the LTM cell handover command, or is indicated by a Downlink Control Information DCI format.

6. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 1, wherein: The security key update information includes a next hop link counter NCC value, and the method further includes: The processor derives the security key of the target cell based on the NCC value and a target cell identifier.

7. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 1, wherein: The security key update information includes NCC related information, and the method further includes: Derivation, by the processor, of an NCC value based on the NCC-related information; and The security key of the target cell is derived by the processor based on the NCC value and the target cell identifier.

8. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 7, wherein: The NCC related information includes: NCC increment indicator; the difference between the NCC value and a second NCC value; or Parameters of the formula used to derive this NCC value.

9. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 8, wherein: The second NCC value includes a previous NCC value maintained in the device.

10. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 1, wherein: Further including: The security key or intermediate data generated during derivation of the security key is stored by the processor.

11. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 1, wherein: The security key update information is used in the security key derivation process of the next LTM cell handover.

12. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 1, wherein: The security key update information is used in a vertical key derivation process, and the method further comprises: When the security key update information is missing, the processor performs a horizontal key derivation process to derive the security key.

13. An apparatus comprising: a transceiver for wireless communication during operation; as well as A processor is communicatively coupled to the transceiver such that, during operation, the processor performs the following operations: receiving, by the transceiver, security key update information from a network node during an LTM process; deriving a security key of the target cell based on the security key update information; Perform LTM cell handover to switch to the target cell; as well as A message encrypted with the security key is transmitted to the target cell through the transceiver.

14. The device according to claim 13, wherein The security key update information is carried by the RRC message received during the LTM preparation phase.

15. The device according to claim 13, wherein The security key update information is carried by the LTM cell switching command.

16. The device according to claim 13, wherein The security key update information includes an NCC value, and during operation, the processor further performs the following operations: The security key of the target cell is derived based on the NCC value and the target cell identifier.

17. The device according to claim 13, wherein The security key update information includes NCC related information, and during operation, the processor further performs the following operations: deriving an NCC value based on the NCC-related information; as well as deriving the security key of the target cell based on the NCC value and the target cell identifier, The NCC-related information includes: NCC increment indicator; the difference between the NCC value and a second NCC value; or Parameters of the formula used to derive this NCC value.

18. The device according to claim 13, wherein The security key update information is used in a vertical key derivation process, and during operation, the processor further performs the following operations: When the security key update information is missing, the processor performs a horizontal key derivation process to derive the security key.

19. A method for derivation of security keys for layer 1 / layer 2 triggered mobility, comprising: determining, by a processor of the network node, at least one candidate cell for a user equipment UE; as well as Security key update information is transmitted by the processor to the UE during the LTM process for use in security key derivation associated with the at least one candidate cell.

20. The method for derivation of security keys for layer 1 / layer 2 triggered mobility according to claim 19, wherein: The security key update information is transmitted during the LTM preparation phase or carried in the LTM cell handover command; or The security key update information includes an NCC value or NCC-related information.

Images