Lower layer triggered mobility handover procedure

Abstract

A method, apparatus and computer program are described comprising: storing a local counter; in response to determining that vertical key derivation is to be used to generate a key for encrypting and / or decrypting communications between a user equipment and a next generation Node B, gNB, updating the local counter in accordance with a predetermined algorithm such that the local counter will align with a corresponding counter in a network node, wherein the key generated using the vertical key derivation is generated based at least in part on the updated local counter.

Description

Technical Field

[0001] Example embodiments may relate to apparatus and / or methods for a mobility (LTM) handover process triggered by a lower layer. Background Technology

[0002] An improved handover process is still needed for switching devices between cells in a cellular network. Summary of the Invention

[0003] The scope of protection sought by the various embodiments of the present invention is set forth in the independent claims. Embodiments and features (if any) described in this specification that do not fall within the scope of the independent claims are to be interpreted as examples useful for understanding the various embodiments of the invention.

[0004] According to a first aspect, an apparatus is provided, comprising: a component for storing a local counter; and a component for: updating the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in a network node, wherein the key generated using vertical key derivation is generated at least in part based on the updated local counter.

[0005] Some example embodiments also include components for storing a second local counter, wherein updating the local counter according to a predetermined algorithm includes incrementing the local counter based on the amount of the second local counter. Example embodiments may also include: components for obtaining an indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with a different gNB; components for obtaining an indication of whether a previous handover was a handover between cells associated with the same gNB or between cells associated with a different gNB; and components for determining whether to generate a key using horizontal key derivation or vertical key derivation, at least in part based on one or both of the following: the indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with a different gNB, and the indication of whether a previous handover was a handover between cells associated with the same gNB or between cells associated with a different gNB.

[0006] In some embodiments, the component for determining whether to use horizontal key derivation or vertical key derivation to generate the key is configured to: determine that horizontal key derivation should be used when the current handover and the previous handover are handovers between cells associated with the same gNB. In some embodiments, the component for determining whether to use horizontal key derivation or vertical key derivation to generate the key is configured to: determine that vertical key derivation should be used when the current handover is a handover between cells associated with the same gNB and the previous handover is a handover between cells associated with different gNBs, and wherein the component for updating the local counter is configured to: reset a second local counter to zero in response to updating the local counter. In some embodiments, the component for determining whether to use horizontal key derivation or vertical key derivation to generate the key is configured to: determine that horizontal key derivation should be used when the current handover is a handover between cells associated with different gNBs; and the apparatus further includes a component for: incrementing a second local counter in response to the current handover being a handover between cells associated with different gNBs.

[0007] In some embodiments, the apparatus may be the current gNB and further includes: a component for providing an indication to a user equipment of the value of a local counter. The apparatus may be the current gNB and further includes: a component for obtaining a candidate cell list; a component for performing a handover between cells associated with the current gNB; a component for informing one or more gNBs associated with cells in the candidate cell list that a handover between cells associated with the current gNB has occurred; a component for generating a key for each cell in the candidate cell list using horizontal key derivation for use in a cell handover event to that cell; and a component for transmitting the generated key for each of the one or more gNBs for use in a cell handover event to a cell associated with that gNB. The apparatus may be the current gNB and further includes: components for obtaining a list of candidate cells; components for performing a handover from a cell associated with a different gNB to a cell associated with the current gNB; components for: informing one or more gNBs associated with cells in the candidate cell list that a handover between cells associated with different gNBs has occurred; components for: generating a key for each cell in the candidate cell list using horizontal key derivation for use in a cell handover event to that cell; and components for: sending the generated key to each network node in one or more gNBs for use in a cell handover event to a cell associated with that gNB. In some example embodiments, the apparatus may be the current gNB and further includes: components for storing a current cell ID corresponding to a cell associated with a user equipment; components for obtaining a target cell ID corresponding to a target cell from the current cell to which the user equipment is to be handed over; and components for: determining, based on the target cell ID and the current cell ID, whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs.

[0008] In some example embodiments, the apparatus may be a user equipment and further includes: a component for generating a key using the determined key derivation, wherein if vertical key derivation is selected, the generated key is at least partially based on a local counter. In some example embodiments, the apparatus may be a user equipment and further includes: a component for storing a current cell ID; a component for receiving a target cell ID from a gNB; and a component for: determining, based on the target cell ID and the current cell ID, whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs.

[0009] The second aspect provides a method comprising: storing a local counter; in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, updating the local counter according to a predetermined algorithm such that the local counter is aligned with a corresponding counter in the network node, wherein the key generated using vertical key derivation is generated at least in part based on the updated local counter.

[0010] In some example embodiments, the method further includes: storing a second local counter, wherein updating the local counter according to a predetermined algorithm includes: incrementing the local counter by an amount based on the second local counter. In some examples, the method may further include: obtaining an indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs; obtaining an indication of whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs; and determining whether to generate a key using horizontal key derivation or vertical key derivation based on one or both of the following: the indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs, and the indication of whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs.

[0011] In some embodiments, determining whether to use horizontal key derivation or vertical key derivation to generate a key includes: determining that horizontal key derivation should be used when the current handover and the previous handover are handovers between cells associated with the same gNB. In some embodiments, determining whether to use horizontal key derivation or vertical key derivation to generate a key includes: determining that vertical key derivation should be used when the current handover is a handover between cells associated with the same gNB and the previous handover was a handover between cells associated with different gNBs, and further includes: resetting a second local counter to zero in response to updating a local counter. In some embodiments, determining whether to use horizontal key derivation or vertical key derivation to generate a key includes: determining that horizontal key derivation should be used when the current handover is a handover between cells associated with different gNBs; and the method further includes: incrementing a second local counter in response to the current handover being a handover between cells associated with different gNBs.

[0012] In some example embodiments, the method may further include providing the user equipment with an indication of the value of a local counter. The method may also include: obtaining a list of candidate cells; performing a handover between cells associated with the current gNB; informing one or more gNBs (other than the current gNB) associated with cells in the candidate cell list that a handover between cells associated with the current gNB has occurred; generating a key for each cell in the candidate cell list using horizontal key derivation for use in a cell handover event to that cell; and sending one or more of the generated keys to each of the one or more gNBs (other than the current gNB) for use in a cell handover event to a cell associated with that gNB. The method may additionally or alternatively include: obtaining a list of candidate cells; completing a handover from a cell associated with a different gNB to a cell associated with the current gNB; informing one or more gNBs (other than the current gNB) associated with cells in the candidate cell list that a handover between cells associated with different gNBs has occurred; generating a key using horizontal key derivation for each cell in the candidate cell list associated with a gNB other than the current gNB, for use in a cell handover event to that cell; and sending one or more of the generated keys to each of the one or more gNBs (other than the current gNB) for use in a cell handover event to a cell associated with that gNB. In some example embodiments, the method may further include: storing a current cell ID corresponding to a cell associated with the user equipment; obtaining a target cell ID corresponding to a target cell from which the user equipment is to be handed over; and determining, based on the target cell ID and the current cell ID, whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs.

[0013] In some example embodiments, the method may further include: generating a key using the determined key derivation, wherein if a vertical key derivation is selected, the generated key is at least partially based on a local counter. The method may further include: storing the current cell ID; receiving a target cell ID from the gNB; and determining, based on the target cell ID and the current cell ID, whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs.

[0014] A third aspect provides a computer program including a set of instructions, which, when executed on a device, are configured to cause the device to perform a method comprising: storing a local counter; and updating the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in a network node, wherein the key generated using vertical key derivation is generated at least in part based on the updated local counter.

[0015] In some example embodiments, the third aspect may include any other features mentioned with respect to the method of the second aspect.

[0016] A fourth aspect of the invention provides a non-transitory computer-readable medium having computer-readable code stored thereon, which, when executed by at least one processor, causes the at least one processor to perform a method comprising: storing a local counter; and updating the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in a network node, wherein the key generated using vertical key derivation is generated at least in part based on the updated local counter.

[0017] The fourth aspect may include any other features mentioned in relation to the method of the second aspect.

[0018] A fifth aspect of the invention provides an apparatus having at least one processor and at least one memory, the at least one memory storing computer-readable code that, when executed, controls the at least one processor to: store a local counter; and, in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, update the local counter according to a predetermined algorithm such that the local counter is aligned with a corresponding counter in a network node, wherein the key generated using vertical key derivation is generated at least in part based on the updated local counter.

[0019] The fifth aspect may include any other features mentioned in relation to the method of the second aspect.

[0020] A sixth aspect provides a user equipment, comprising: means for storing a local counter; means for storing a second local counter; means for: in response to determining that a key for encrypting and / or decrypting communication between the user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, updating the local counter by incrementing the local counter by an amount based on the second local counter according to a predetermined algorithm, such that the local counter is aligned with a corresponding counter in a network node; and means for generating a key using vertical key derivation based at least in part on the updated local counter.

[0021] In some example embodiments, the user equipment may further include: components for obtaining an indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs; components for obtaining an indication of whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs; and components for determining whether to generate a key using horizontal key derivation or vertical key derivation, based at least in part on one or both of the following: the indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs, and the indication of whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs.

[0022] The component for determining whether to use horizontal key derivation or vertical key derivation to generate the key can be configured to: determine that horizontal key derivation should be used when the current handover and the previous handover are handovers between cells associated with the same gNB. The component for determining whether to use horizontal key derivation or vertical key derivation to generate the key can be configured to: determine that vertical key derivation should be used when the current handover is a handover between cells associated with the same gNB and the previous handover was a handover between cells associated with different gNBs, and the component for updating the local counter can be configured to: reset a second local counter to zero in response to updating the local counter. The component for determining whether to use horizontal key derivation or vertical key derivation to generate the key can be configured to: determine that horizontal key derivation should be used when the current handover is a handover between cells associated with different gNBs; and the user equipment may also include a component for: incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs.

[0023] In some example embodiments, the user equipment may further include: a component for storing the current cell ID; a component for receiving the target cell ID from the gNB; and a component for determining, based on the target cell ID and the current cell ID, whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs. In some embodiments, the component for receiving the target cell ID from the gNB may receive the target cell ID in a Media Access Control command element (MAC CE) command.

[0024] In some example embodiments, the user equipment may also include a component for encrypting and / or decrypting communication between the user equipment and the gNB using a key generated by a component for generating a key using vertical key generation.

[0025] The seventh aspect provides a method comprising: storing a local counter; storing a second local counter; updating the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in the network node; and generating a key using vertical key derivation based at least in part on the updated local counter.

[0026] In some example embodiments, the method may further include: obtaining an indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs; obtaining an indication of whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs; and determining whether to generate a key using horizontal key derivation or vertical key derivation based on one or both of the following: the indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs, and the indication of whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs.

[0027] Determining whether to use horizontal key derivation or vertical key derivation to generate the key may include: when the current handover and the previous handover are handovers between cells associated with the same gNB, determining that horizontal key derivation should be used. Determining whether to use horizontal key derivation or vertical key derivation to generate the key may include: when the current handover is a handover between cells associated with the same gNB and the previous handover was a handover between cells associated with different gNBs, determining that vertical key derivation should be used; and the method may further include: resetting a second local counter to zero in response to updating a local counter. Determining whether to use horizontal key derivation or vertical key derivation to generate the key may include: when the current handover is a handover between cells associated with different gNBs, determining that horizontal key derivation should be used; and the method may further include: incrementing a second local counter in response to the current handover being a handover between cells associated with different gNBs.

[0028] In some example embodiments, the method may further include: obtaining a list of candidate cells; performing a handover between cells associated with the current gNB; informing one or more gNBs (other than the current gNB) associated with cells in the candidate cell list that a handover between cells associated with the current gNB has occurred; generating a key for each cell in the candidate cell list using horizontal key derivation for use in a cell handover event to that cell; and sending one or more of the generated keys to each of the one or more gNBs (other than the current gNB) for use in a cell handover event to a cell associated with that gNB. In some example embodiments, the method may further include: obtaining a list of candidate cells; completing a handover from a cell associated with a different gNB to a cell associated with the current gNB; informing one or more gNBs (other than the current gNB) associated with cells in the candidate cell list that a handover between cells associated with different gNBs has occurred; generating a key using horizontal key derivation for each cell in the candidate cell list associated with a gNB other than the current gNB, for use in a cell handover event to that cell; and sending one or more of the generated keys to each of the one or more gNBs (other than the current gNB) for use in a cell handover event to a cell associated with that gNB. Sending the generated keys may include sending the keys via the Xn interface.

[0029] In some example embodiments, the method further includes: storing the current cell ID; receiving the target cell ID from the gNB; and determining, based on the target cell ID and the current cell ID, whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs. Receiving the target cell ID from the gNB may include receiving the target cell ID in a Media Access Control command element (MAC CE) command.

[0030] In some example embodiments, the method may further include encrypting and / or decrypting communication between the user equipment and the gNB using a key generated through vertical key generation.

[0031] The eighth aspect provides a computer program including a set of instructions, which, when executed on a device, are configured to cause the device to perform a method comprising: completing when the claims are finalized.

[0032] In some example embodiments, the eighth aspect may include any other features mentioned in relation to the method of the seventh aspect.

[0033] A ninth aspect of the present invention provides a non-transitory computer-readable medium having computer-readable code stored thereon, the computer-readable code, when executed by at least one processor, causing the at least one processor to perform a method comprising: storing a local counter; storing a second local counter; updating the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in a network node; and generating a key using vertical key derivation, at least in part based on the updated local counter.

[0034] The ninth aspect may include any other features mentioned in relation to the method of the seventh aspect.

[0035] A tenth aspect of the invention provides an apparatus having at least one processor and at least one memory, the at least one memory storing computer-readable code, which, when executed, controls the at least one processor to: store a local counter; store a second local counter; update the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in a network node; and generate a key using vertical key derivation, at least in part based on the updated local counter.

[0036] The tenth aspect may include any other features mentioned in relation to the method of the seventh aspect.

[0037] The eleventh aspect provides a next-generation node (gNB) including: components for storing a local counter; components for storing a second local counter; components for: in response to determining that a user equipment (UE) needs to use vertical key derivation to generate a key for encrypting and / or decrypting communication between the UE and the gNB, updating the local counter by incrementing the local counter by an amount based on the second local counter according to a predetermined algorithm, such that the local counter is aligned with a corresponding counter in the network node; and components for sending an indication of the local counter to the UE.

[0038] In some example embodiments, the gNB may further include: means for obtaining an indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs; means for obtaining an indication of whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs; and means for determining whether to generate a key using horizontal key derivation or vertical key derivation, based at least in part on one or both of the following: the indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs, and the indication of whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs.

[0039] The component for determining whether to use horizontal or vertical key derivation to generate the key can be configured to: determine that horizontal key derivation should be used when the current handover and the previous handover are handovers between cells associated with the same gNB. The component for determining whether to use horizontal or vertical key derivation to generate the key can be configured to: determine that vertical key derivation should be used when the current handover is a handover between cells associated with the same gNB and the previous handover was a handover between cells associated with different gNBs, and the component for updating the local counter can be configured to: reset a second local counter to zero in response to updating the local counter. The component for determining whether to use horizontal or vertical key derivation to generate the key can be configured to: determine that horizontal key derivation should be used when the current handover is a handover between cells associated with different gNBs; and the gNB may also include a component for: incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs.

[0040] In some example embodiments, the gNB may further include: components for obtaining the current cell ID; components for obtaining the target cell ID; and components for determining, based on the target cell ID and the current cell ID, whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs. In some embodiments, the components for receiving the target cell ID from the gNB may receive the target cell ID in a Media Access Control command element (MAC CE) command.

[0041] In some example embodiments, the gNB includes a Distributed Unit (DU) and a Centralized Unit (CU), and the DU includes: components for storing local counters; components for determining whether a user equipment (UE) generates a key using horizontal key derivation or vertical key derivation; and components for updating the local counters. The DU may also include components for sending an indication to the UE regarding the local counter value. In some example embodiments, the DU includes components for storing a second counter, and the DU further includes: components for updating the second counter after the components for sending the indication to the UE regarding the local counter have sent the indication; and components for indicating the updated local counter value and the updated second local counter value to the CU. In some example embodiments, the CU includes components for forwarding the updated local counter value and the updated second local counter value to the CU of the gNB associated with the candidate cell.

[0042] The twelfth aspect provides a method comprising: storing a local counter; storing a second local counter; updating the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in the network node; and sending an indication to the user equipment for the local counter.

[0043] In some example embodiments, the method further includes: the user equipment determining, at least in part, based on an instruction sent to a local counter, whether to use horizontal key derivation or vertical key derivation to generate a key for encrypting and / or decrypting communication between the user equipment and the gNB.

[0044] In some example embodiments, the method further includes: obtaining an indication of whether the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs; obtaining an indication of whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs; and The key is determined based on one or both of the following: an indication of whether the current handover is between cells associated with the same gNB or between cells associated with different gNBs, and an indication of whether the previous handover was between cells associated with the same gNB or between cells associated with different gNBs.

[0045] Determining whether a key is generated using horizontal or vertical key derivation may include: when the current handover and the previous handover are between cells associated with the same gNB, determining that horizontal key derivation should be used. Determining whether a key is generated using horizontal or vertical key derivation may include: when the current handover is between cells associated with the same gNB and the previous handover was between cells associated with different gNBs, determining that vertical key derivation should be used; and the method may further include: resetting a second local counter to zero in response to updating a local counter. Determining whether a key is generated using horizontal or vertical key derivation may include: when the current handover is between cells associated with different gNBs, determining that horizontal key derivation should be used; and the method may further include: incrementing a second local counter in response to the current handover being between cells associated with different gNBs.

[0046] In some example embodiments, the method further includes: obtaining a list of candidate cells; performing a handover between cells associated with the current gNB; informing one or more gNBs (other than the current gNB) associated with cells in the candidate cell list that a handover between cells associated with the current gNB has occurred; generating a key for each cell in the candidate cell list using horizontal key derivation for use in a cell handover event to that cell; and sending one or more of the generated keys to each of the one or more gNBs (other than the current gNB) for use in a cell handover event to a cell associated with that gNB. In some example embodiments, the method additionally or alternatively includes: obtaining a list of candidate cells; completing a handover from a cell associated with a different gNB to a cell associated with the current gNB; informing one or more gNBs (other than the current gNB) associated with cells in the candidate cell list that a handover between cells associated with different gNBs has occurred; generating a key using horizontal key derivation for each cell in the candidate cell list associated with a gNB other than the current gNB, for use in a cell handover event to that cell; and sending one or more of the generated keys to each of the one or more gNBs (other than the current gNB) for use in a cell handover event to a cell associated with that gNB. Sending the generated keys may include sending the keys via the Xn interface.

[0047] In example embodiments, the gNB Distributed Unit (DU) associated with the gNB performs the following actions: storing a local counter, determining whether the user equipment (UE) uses horizontal or vertical key derivation to generate the key, updating the local counter, and sending an indication to the UE regarding the local counter. In some example embodiments, the DU further performs the following actions: storing a second counter; updating the second counter after sending the indication to the UE regarding the local counter; and indicating the updated local counter value and the updated second local counter value to the gNB Centralized Unit (CU) associated with the same gNB associated with the DU. In some example embodiments, the CU may forward the updated local counter value and the updated second local counter value to the CU of the gNB associated with the candidate cell. In some example embodiments, the CU of the gNB associated with the candidate cell may forward the updated local counter value and the updated second local counter value to the DU of the gNB associated with the candidate cell.

[0048] The thirteenth aspect provides a computer program including a set of instructions, which, when executed on a device, are configured to cause the device to perform a method comprising: storing a local counter; storing a second local counter; updating the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in a network node; and sending an instruction to the user equipment for the local counter.

[0049] In some example embodiments, the thirteenth aspect may include any other features mentioned with respect to the method of the twelfth aspect.

[0050] A fourteenth aspect of the present invention provides a non-transitory computer-readable medium having computer-readable code stored thereon, the computer-readable code, when executed by at least one processor, causing the at least one processor to perform a method comprising: storing a local counter; storing a second local counter; updating the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in a network node; and sending an instruction to the user equipment for the local counter.

[0051] The fourteenth aspect may include any other features mentioned in relation to the method of the twelfth aspect.

[0052] The fifteenth aspect of the present invention provides an apparatus having at least one processor and at least one memory, the at least one memory storing computer-readable code, which, when executed, controls the at least one processor to: store a local counter; store a second local counter; update the local counter according to a predetermined algorithm in response to determining that a key for encrypting and / or decrypting communication between a user equipment and a next-generation node (gNB) is to be generated using vertical key derivation, such that the local counter is aligned with a corresponding counter in the network node; and send an instruction to the user equipment for the local counter.

[0053] The fifteenth aspect may include any other features mentioned in relation to the method of the twelfth aspect. Attached Figure Description

[0054] Exemplary embodiments will now be described by way of non-limiting example with reference to the accompanying drawings, in which: Figure 1 This is a diagram illustrating model 100 that generates keys sequentially using horizontal key generation and vertical key generation; Figure 2 This is a schematic diagram of radio access network 200; Figure 3 and Figure 4 This is a message flow sequence diagram illustrating example message flow sequence 300; Figure 5 This is a block diagram illustrating an apparatus 400 according to some example embodiments; Figure 6 This is a flowchart illustrating method 500 according to an example embodiment; Figure 7 This is a flowchart of Example Algorithm 600 used to update the local next-hop link counter value; Figure 8 This is a block diagram illustrating a user equipment 700 according to some example embodiments; Figure 9 This is a flowchart illustrating method 800 according to an example embodiment; Figure 10 This is a block diagram of system 900 according to an example embodiment; Figures 11 to 15 This is a message flow sequence diagram illustrating message flow sequences 1000, 1100, and 1200 according to an example embodiment; Figure 16 This is a block diagram illustrating a gNB 1300 according to some example embodiments; Figure 17 This is a flowchart illustrating method 1400 according to an example embodiment; Figures 18 to 22This is a message flow sequence diagram illustrating message flow sequences 1500, 1600, and 1700 according to an example embodiment; Figure 23 This is a block diagram 1800 showing the subsequent key derivation steps in the context of the elements of model 100; Figure 24 This is a block diagram of the components of a system according to an example embodiment; and Figure 25 An example of a tangible medium for storing computer-readable code is shown, which, when run by a computer, can perform methods according to the above example embodiments. Detailed Implementation

[0055] To improve the security of communication between user equipment and network nodes, messages between user equipment and network nodes can be encrypted by the transmitting device or apparatus using a key, and decrypted by the receiving device or apparatus using a matching or corresponding key.

[0056] Generating the key at the device where it will be used reduces the need to transmit the key.

[0057] A matching key can be generated using a matching key derivation algorithm with matching input.

[0058] There are two methods for deriving matching keys: horizontal key derivation and vertical key derivation. These key derivation methods can be used to generate new keys when user equipment hands over between cells to provide forward security / confidentiality.

[0059] Figure 1 This is a diagram illustrating model 100 that generates keys sequentially using horizontal key generation and vertical key generation.

[0060] Horizontal key derivation 110 generates a new key 112, referred to in this example as KgNB, because the key generated in this example is the key used for communication between the gNB and the user equipment. Horizontal key derivation uses the following as inputs: the prior key, the downlink (DL) frequency of the cell to which the user equipment is being handed over, and the physical cell ID (PCI) of the cell to which the user equipment is being handed over.

[0061] Vertical key derivation 114 uses the following items as input to generate a new key: the next hop parameter (NH) value, the downlink (DL) frequency of the cell to which the user equipment is being handed over, and the physical cell ID (PCI) of the cell to which the user equipment is being handed over.

[0062] Therefore, both horizontal and vertical key derivation utilize PCI and DL frequencies. Horizontal key derivation leverages the previous key. Vertical key derivation effectively refreshes the key using the NH value. Vertical key derivation is used to separate the key space for each Radio Access Network (RAN) node. The NH value can be provided to the RAN node by the Access and Mobility Function (AMF). The vertical key generated by each RAN node uses the new NH value provided by the AMF. Therefore, the security domain is separated from the previous RAN node.

[0063] In short, horizontal key derivation uses the following inputs: • Current active key (e.g., K) gNB );as well as • Regarding the PCI and DL frequencies of the next cell, To produce the following output: • New key (e.g., K) gNB ).

[0064] Vertical key derivation uses the following inputs: • The new NH value (which can be provided to the serving gNB / RAN node by the AMF after the path handover, or it can be determined by the UE using the same algorithm used by the AMF); and • Regarding the PCI and DL frequencies of the next cell, To produce the following output: • New key (e.g., K) gNB ).

[0065] Figure 2 This is a schematic diagram of a radio access network 200. The network includes device 210. Device 210 can be configured to communicate with network node 220 through a specific cell (i.e., cell 215), which can be associated with a specific location and specific network node 220 resources.

[0066] Network node 220 communicates with other network nodes, which are schematically shown by network node 235 (the network may include more network nodes, but these are not shown). In some examples, network nodes 220 and 235 may be gNBs. Network nodes 220 and 235 communicate with core network 205. Core network 205 may include Access and Mobility Functions (AMF).

[0067] Network node 220 can determine that device 210 should communicate with the network through a cell other than cell 215. For example, this can be determined based on measurements received by network node 220 that indicate different cells will provide better connectivity. Preferred cells may be cells such as cell 225 associated with the same network node 220, or preferred cells may be cells such as cell 230 associated with a different network node 235.

[0068] Reconfiguring a device to communicate through a different cell than the current cell can be called handover. Reconfiguring a device to communicate through a different cell associated with the same network node as the current cell can be called intra-node handover. Reconfiguring a device to communicate through a different cell associated with a different network node than the current cell can be called inter-node handover.

[0069] Figure 3 and Figure 4 This is a message flow sequence diagram illustrating example message flow sequence 300. Figure 3 This shows the first part of the message stream sequence. Figure 4 This shows the second part of the message stream sequence. Figure 3 Steps 320 to 350 are shown, while Figure 4 Steps 350 to 376 are shown. Message stream sequence 300 does not use a low-level triggered mobility (LTM) process.

[0070] Sequence 300 includes messages between user equipment (UE) 310, first gNB (gNB1) 312, second gNB (gNB2) 314 and access and mobility function (AMF) 316.

[0071] In step 320, the first gNB 312 stores the NH and next-hop link counter (NCC) values ​​for the next switch.

[0072] In this example, assume that UE 310 initially has an NCC value of "0", and the previous handover experienced by UE 310 was an intra-gNB handover, so the NCC value was not incremented after the handover. Assume that the key initially used by UE 310 is "KgNB-A".

[0073] In step 322, gNB 312 sends a measurement control message to UE 310.

[0074] In step 324, UE 310 sends a measurement report message to gNB 312.

[0075] In step 326, using the measurement report received in step 324, gNB 312 determines that an inter-gNB handover should occur (i.e., because the measurement report indicates the target cell at the second gNB 314). The first gNB 312 generates a target key KgNB as "KgNB-B".

[0076] In step 328, the first gNB 312 sends the current NCC value "0" and the new key "KgNB-B" along with the switching request to the second gNB 314.

[0077] In step 330, the second gNB 314 stores the new key “KgNB-B” for later use. The second gNB 314 embeds the received NCC value “0” into the target cell configuration.

[0078] In step 332, the second gNB 314 sends the target cell configuration to the first gNB 312 using a handover (HO) request acknowledgment (ACK) message.

[0079] In step 334, the first gNB 312 generates a handover command, encapsulates the target cell configuration (including the NCC value), and sends the handover command to the UE 310. The UE 310 receives and decodes the handover command. The handover command is in the form of a Radio Resource Control (RRC) message.

[0080] In step 336, UE 310 sees that the NCC value remains unchanged at "0" and determines that it should perform horizontal key generation. UE 310 uses the current key "KgNB-A" along with the PCI and DL frequencies of the target cell to generate "KgNB-B". Because the algorithm used to generate "KgNB-B" on both the UE and network sides is the same, "KgNB-B" is generated independently by UE 310 and the network, and the two match.

[0081] In steps 338 and 340, UE 310 establishes a connection with the second gNB 314 (using a random access channel) and sends an RRC reconfiguration complete message to the second gNB 314. UE 310 encrypts its message using "KgNB-B".

[0082] In step 342, the second gNB 314 sends a path switching request to the AMF 316.

[0083] In step 344, AMF 316 increments the NCC value of the UE (increment by one).

[0084] In step 346, AMF 316 generates a new "NH" value.

[0085] In step 348, AMF 316 sends the incremented NCC value and the new NH value as part of the path switching request confirmation message to the second gNB 314.

[0086] In step 350, the second gNB 314 stores the NH and NCC values ​​and does not use them at this stage. At this point, the second gNB 314 has become the serving gNB of UE 310.

[0087] After a period of time, UE 310 can send another measurement report. In some examples, this subsequent measurement report may be triggered by a certain amount of time elapsed since the previous measurement report was sent, but the specific trigger for sending this measurement report is not necessary for the subsequent handover process. The report may indicate that another target cell (this time in the same gNB) has become a strong candidate cell for handover.

[0088] In step 352, the second gNB 314 may decide to trigger an intra-gNB handover in response to receiving a measurement report.

[0089] In step 354, the second gNB 314 determines that vertical key derivation should be used to generate the key because the stored NCC value has been incremented (in step 344). The second gNB 314 uses the stored NH value along with the target cell PCI and DL frequency to generate "KgNB-C". The second gNB 314 stores "KgNB-C". The second gNB 314 places the incremented NCC value "1" in the target cell configuration and compiles the handover command.

[0090] In step 356, the second gNB 314 then sends an HO command to the UE 310 (as part of an RRC reconfiguration message). The NCC value is embedded in the handover command.

[0091] In step 358, UE 310 decodes the HO command and sees that the NCC value has been incremented to "1". UE 310 determines that it should use vertical key generation because the NCC value has been incremented. UE 310 uses the algorithm pre-configured for UE 310 by AMF 316 to generate a new NH value. The NH values ​​generated by UE 310 and AMF 316 are mapped to each other because the same algorithm is used. Then, UE 310 uses the NH value, PCI, and DL frequency to generate the target key "KgNB-C".

[0092] In step 360, UE 310 establishes a connection with the second gNB 314 via a random access channel.

[0093] In step 362, UE 310 sends an RRCReconfigutation completion message to the second gNB 314. UE 310 encrypts the message using the newly generated key, and then sends the message to the second gNB 314, which decrypts the message using its stored KgNB-C.

[0094] In step 364, the second gNB 314 does not receive a new NH value from the AMF, and the switching in steps 352 to 362 is an intra-gNB switching.

[0095] Because no new NH value was received in step 364, the next handover occurring from steps 366 to 376 uses the level key generation. In the example shown, this handover is also an intra-gNB handover.

[0096] Steps 366, 368, 370, 372, 374 and 376 correspond to steps 352, 354, 356, 358, 360 and 362, respectively.

[0097] This method relies on transmitting a new NCC value to the UE using an RRC reconfiguration message. In this method, after each cell change, the key derivation method to be used is indicated to the UE using the NCC value in the handover command.

[0098] Low-layer triggered mobility (LTM) dynamic handover is a method in which the UE stores multiple RRC configurations and can be instructed to change the configuration using messages below the RRC layer. For example, a Media Access Control (MAC) control element (MAC CE) can be used to instruct the UE to use different configurations, which are pre-configured for a specific cell.

[0099] In some examples, a horizontal key derivation can be used to generate a key, and the key can be transmitted to each candidate gNB for use in cases where the UE is handed over to the cell associated with that gNB. A list of keys can be shown to the UE (e.g., a list of candidate cell PCI and DL frequencies), and the UE can use the list to determine the next key for the target gNB.

[0100] However, if the candidate cell configuration is reused without a new RRC reconfiguration, the NCC value may not be updated. If the NCC value does not increase, vertical key derivation may not be triggered.

[0101] Therefore, if RRC reconfiguration is required to update the NCC value, LTM dynamic switching may be incompatible with vertical key derivation.

[0102] LTM dynamic handover provides faster handover between cells, and vertical key derivation provides separation between security domains of different network nodes, so it may be desirable to allow vertical key derivation to be used with LTM dynamic handover.

[0103] Therefore, a method is proposed to enable the UE to generate vertical keys for subsequent cell handovers.

[0104] The UE can determine the next key derivation to use after the cell handover command. This determination can be based internally on knowledge of whether the source cell and the target cell belong to the same gNB, or based on an indication in the LTM handover command from the source gNB.

[0105] By using appropriate methods on both the UE and network sides, the generation of an updated key for inter-gNB LTM can be achieved without RRC reconfiguration between cell handover commands.

[0106] In some example embodiments, the updated NCC value can be derived by the UE or gNB by updating the locally stored NCC value using an appropriate algorithm, without relying on the updated NCC value indicated by the AMF. Therefore, the locally stored NCC value can be aligned with the AMF NCC value, or aligned with the AMF NCC value during vertical key derivation.

[0107] By aligning the locally stored NCC value with the NCC value stored at the AMF at least during vertical key derivation, the locally stored NCC value can be used to generate a key corresponding to the key generated by the network device using the NCC and / or NH provided by the AMF.

[0108] Figure 5 This is a block diagram illustrating an apparatus 400 according to some example embodiments.

[0109] The device 400 includes a memory 405 and a processor 410.

[0110] Memory 405 can store local counters.

[0111] Processor 410 can update a local counter stored in memory 405 according to a predetermined algorithm, such that the local counter is aligned with the corresponding counter in the network node (e.g., the network node may be an AMF). This update step can be performed in response to determining whether to use vertical key derivation to generate a key for encrypting and / or decrypting communication between the user equipment and the next-generation node B gNB.

[0112] Figure 6 This is a flowchart illustrating method 500 according to an example embodiment. The steps of method 500 can be performed by device 400.

[0113] In step 510, it is determined that vertical key generation will be used to generate the key.

[0114] In step 512, the stored local counter is updated according to a predetermined algorithm such that the local counter is aligned with the corresponding counter in the network node (e.g., the network node may be an AMF). The stored local counter may be stored in memory 405, and the update may be performed by processor 410. The means to determine which vertical key derivation to use may be means 400, but the update step 512 may be performed by a different means than the means that performs step 510 (e.g., step 510 may be performed by a means other than means 400).

[0115] By aligning the local counter with the value at the network node, the local counter and the network node counter can be used to generate a corresponding key without transmitting the network node counter to device 400. In the example where device 400 is a user equipment, this allows the local counter to be updated without RRC reconfiguration. In the example where device 400 is a network node, this reduces the amount of signaling between network nodes required to provide the counter value to the user equipment.

[0116] In some examples, device 400 maintains a second local counter, and updating the local counter according to a predetermined algorithm in step 512 includes incrementing the local counter by an amount based on the second local counter. For example, the second local counter may track the difference between the value of the local counter and the value of the corresponding counter.

[0117] In some examples, step 510 includes determining whether to generate the key using horizontal key derivation or vertical key derivation, and this step is performed by device 400 (or, in some examples, by processor 410). This determination may be based at least in part on the following indications: whether the current handover of the user equipment from one cell to another is a handover between cells associated with the same gNB or between cells associated with different gNBs, and whether the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs.

[0118] If the current handover and the previous handover are between cells associated with the same gNB, then it can be determined in step 510 to use horizontal key derivation. The corresponding network node counter (in some examples, it may be an NCC counter maintained by the AMF) may remain unchanged after such a handover, so there may be no update of the corresponding network node counter to track, and if the key derivation is horizontal, the alignment of the local counter at the user equipment with the corresponding counter on the network side may be unnecessary.

[0119] If the current handover between cells is between cells associated with the same gNB, and the previous handover between cells was between cells associated with different gNBs, then it can be determined in step 510 to use vertical key derivation. As above, the local counter can be incremented by an amount based on the second local counter to align it with the corresponding counter at the network node, and the second local counter can be reset to zero. Using vertical key derivation provides separation between the security domains of the previous gNB (the serving gNB before the previous handover) and the current gNB. Aligning the value of the local counter with the value of the corresponding counter allows key derivation based on the local counter to provide a key corresponding to key derivation based on the corresponding counter. Resetting the second local counter to zero reflects the alignment between the local counter and the corresponding counter.

[0120] If the current handover is between cells associated with different gNBs, then in step 510 it can be determined that a horizontal key derivation should be used, and the second local counter can be incremented. The incrementing of the second local counter reflects that, in response to the handover between cells associated with different gNBs, the corresponding network node counter increases, while the local counter does not.

[0121] In some embodiments, determining whether a handover between cells is between cells associated with the same gNB or between cells associated with different gNBs can be performed by processor 410 based at least in part on the current cell ID and the target cell ID stored in memory 405. In some examples, the current cell ID and the target cell ID can be mapped to key update groups, and mapping the current cell ID and the target cell ID to the same key update group may indicate that the current cell and the target cell are associated with the same gNB, while mapping the current cell ID and the target cell to different key update groups may indicate that the current cell and the target cell are associated with different gNBs. In embodiments where device 400 is a user equipment, the current cell ID and / or the target cell ID may be obtained by device 400 via a MAC CE.

[0122] In step 514, a key is generated using a local counter via vertical key derivation. If device 400 is a user equipment, device 400 may generate the key in this step. In other embodiments, the local counter may be sent to different devices, or the value of the local counter may be indicated to different devices for key derivation.

[0123] User equipment method In some examples, the user equipment (UE) can be configured to generate security keys for one or more target cells based on internally maintained or locally sourced NCC counter values. The UE can use vertical key derivation to generate a key for use after handover to the target cell, i.e., the target K-GNB, based on the NH value derived from the local NCC counter values ​​and the target cell's PCI and DL frequencies. If the local NCC count remains unchanged, the UE can generate a key using horizontal key derivation based on the previous key and the target cell PCI and DL frequencies.

[0124] If the key update group IDs of the current cell and the new cell are different, the UE can determine that it needs to generate a new key based on vertical key derivation. A key update group can correspond to a set of cells associated with the same gNB. After a handover between cells in different key update groups, the AMF NCC value can be incremented.

[0125] In some example embodiments, the user equipment can be configured to generate a security key for the target cell based on the NCC value received in the LTM handover command (e.g., via a MAC CE command). The user equipment can generate the target K-GNB based on the NCC value provided in the cell handover command. When providing NCC values ​​to user equipment (e.g., in LTM handover commands), it may be unnecessary for user equipment to maintain and update its internal NCC count.

[0126] Network methods If LTM mobility is configured for inter-gNB scenarios, the new serving gNB can update each candidate cell using the NH value generated from the NCC value received from the AMF via the path handover message.

[0127] During the LTM preparation process, each candidate gNB can provide the initial serving gNB with its key update group ID and its association with the candidate cell. This allows the UE or other devices to determine whether the handover is between cells associated with different gNBs and to decide when to use horizontal key derivation or vertical key derivation to generate a new K-gNB based on NH / NCC.

[0128] Key update algorithm As shown above, the local NCC value can be updated according to the algorithm to align it with the NCC value stored by the AMF and / or with the NCC value used to determine the key on the network side.

[0129] The following shows three cases handled by the example algorithm used to update the NCC value.

[0130]

[0131] Table 1: Overview of the decision logic used for key generation If the configuration instructs the UE not to update the key, then the algorithm can be omitted.

[0132] The algorithm can use previous and / or current switching types, or indications of previous and / or current switching types, as input to determine the key generation type to use.

[0133] In the example algorithm, in addition to the local NCC value, the NCC_Delta value is also stored locally.

[0134] For each gNB handover, the NCC value may not be incremented, but the NCC_increment is incremented to align the sum of the local NCC and the NCC_increment with the NCC value maintained at the AMF.

[0135] In some example implementations, the NCC_increment value tracks the number of gNB handovers between vertical key generation. The AMF NCC value is incremented after being notified of the gNB handover, and the NCC_increment value can track the increment of this AMF NCC value.

[0136] Scenario A: The current handover is an "intra-gNB" handover (handover of a user equipment between cells associated with the same gNB), and the previous handover was also an "intra-gNB" handover. In this case, key generation is horizontal. The NCC value remains the same in this scenario. Furthermore, the NCC_increment value is not incremented. In some cases, an "intra-gNB" handover can be indicated by a zero NCC_increment value.

[0137] Scenario B: The current handover is an "intra-gNB" handover, and the previous handover was an "inter-gNB" handover (a handover of a user equipment from a cell associated with a first gNB to a second gNB). In this case, key generation is vertical. Vertical key generation keeps the security domains of different gNBs separate. In this case, the NCC value can be incremented by the value of NCC_increment. The NCC_increment value can now be reset to 0 (the difference between the locally stored NCC and the NCC stored in the AMF should be zero). The previous "inter-gNB" handover can be indicated by a non-zero NCC_increment value, or otherwise.

[0138] Scenario C: The current handover is an "inter-gNB" handover. In this case, key generation is horizontal. This can disregard the previous handover type (i.e., the previous handover could have been an intra-gNB or inter-gNB handover). In this case, the NCC value remains unchanged. The NCC_increment value is incremented (because the local NCC value remains unchanged, and the NCC value stored in the AMF can be incremented upon receiving a path handover request, so the difference between the NCC value stored in the AMF and the local NCC value can be incremented).

[0139] Figure 7 This is a flowchart of Example Algorithm 600 used to update local NCC values.

[0140] In step 610, an indication is obtained as to whether the current handover and previous handovers are handovers between cells associated with different network nodes. For example, it can be determined whether the current handover is a handover between cells associated with the same network node based on the target cell ID and the current cell ID, or an indication of the cell ID. The type of previous handover can be explicitly indicated or inferred, for example, based on the stored NCC_increment value.

[0141] In step 612, it is determined whether the current handover is between cells associated with different network nodes. If the current handover is between cells associated with different network nodes, the algorithm can proceed to step 614. If the current handover is not between cells associated with different network nodes, the algorithm can proceed to step 616.

[0142] In step 614, the NCC_increment is incremented, while the local NCC value remains unchanged. The level key generation is then determined.

[0143] In step 616, it is determined whether the previous handover was a handover between cells associated with different network nodes. If the previous handover was not a handover between cells associated with different network nodes, the algorithm can proceed to step 618. If the previous handover was a handover between cells associated with different network nodes, the algorithm can proceed to step 620.

[0144] In step 618, the level key generation is determined. The local NCC value can remain unchanged. The NCC increment can also remain unchanged (and can be zero).

[0145] In step 620, the vertical key generation is determined. The local NCC value is incremented by NCC delta. The method then proceeds to step 622.

[0146] In step 622, the NCC_increment is reset. At this stage, the local NCC value can be aligned with the NCC value stored at the AMF.

[0147] Algorithm 600 or other example algorithms can be executed at different devices in the network. In some example embodiments, algorithm 600 can be executed by device 400. Memory 405 can store local NCC values ​​and NCC_increments, while processor 410 can execute the algorithm based on obtained indications about whether the current handover and previous handovers are handovers between cells associated with different network nodes.

[0148] On the network side, if a user equipment switches to a cell associated with a different gNB after having already performed an inter-gNB handover, the previous handover type may be unknown.

[0149] In some example embodiments, each candidate gNB (e.g., each gNB corresponding to one or more candidate cells from which a user equipment can be handed over from the serving gNB) can be informed of previous inter-gNB handovers by the serving gNB. The candidate gNB can receive potential keys generated using level key derivation from the serving gNB for use when the user equipment is handed over to that candidate gNB. In embodiments where apparatus 400 is a gNB, these keys can be generated using processor 410. In some examples, the Xn interface can be used to send one or more keys from one gNB to one or more other gNBs.

[0150] In subsequent horizontal key generation, it may be sufficient for the candidate gNB to be informed that the PCI and DL frequencies of the UE's current serving cell are sufficient. Using this information, the candidate gNB can generate subsequent keys. However, the current serving gNB can indicate to the candidate gNB that a handover between cells associated with the current serving gNB has occurred, derive a key using the horizontal key derivation to use in the event of a cell handover to the candidate gNB, and send the generated key. In embodiments where apparatus 400 is a gNB, these keys can be generated using processor 410.

[0151] Figure 8 This is a block diagram of a user equipment 700 according to an example embodiment. The user equipment 700 includes a memory 705 and a processor 710. In some embodiments, the user equipment 700 may include features of a device 400.

[0152] Memory 705 can store a local counter and a second local counter. In some examples, the local counter and the second local counter correspond to the NCC value and the NCC increment value, respectively.

[0153] Processor 710 can update a local counter stored in memory 705 by incrementing a local counter by an amount based on a second local counter, according to a predetermined algorithm, such that the local counter is aligned with the corresponding counter in the network node (e.g., the network node could be an AMF). This update step can be performed in response to determining that a key for encrypting and / or decrypting communication between the user equipment and the next-generation node B gNB should be generated using vertical key derivation. Processor 710 can generate the key using vertical key derivation, at least in part, based on the updated local counter.

[0154] Figure 9 This is a flowchart of method 800 according to an example embodiment. Some or all of the steps of method 800 may be performed by user equipment 700. In some embodiments, method 800 may include the steps of method 500.

[0155] In step 810, it is determined that vertical key generation will be used to generate the key.

[0156] In step 812, according to a predetermined algorithm, the stored local counter is updated by incrementing the local counter by an amount based on the second local counter, such that the local counter is aligned with the corresponding counter in the network node (e.g., the network node may be an AMF). The stored local counter and the second local counter may be stored in memory 705, and the update may be performed by processor 710.

[0157] In step 814, a key is generated using a local counter via vertical key derivation. This step can be performed by processor 710.

[0158] In the example embodiments of user equipment 700 and method 800, local NCC and NCC_increment are maintained on the user equipment side. Keys are generated on both the network side and the user equipment side based on the current handover type and the previous handover type.

[0159] Figure 10 This is a block diagram of system 900 according to an example embodiment.

[0160] System 900 includes user equipment 905 (which may include features of user equipment 700), a first gNB 910, a second gNB 920, and an AMF 930. The first gNB 910 may include a first centralized unit (CU1) 912 and a first distributed unit (DU1) 914. The second gNB may also include a second centralized unit (CU2) 922 and a second distributed unit (DU2) 924.

[0161] User equipment 905 is shown communicating with a first gNB 910 via a first distributed unit 912. User equipment 905 can communicate with other gNBs (such as a second gNB 920) via a handover process.

[0162] gNBs 910 and 920 are shown as each comprising a centralized unit and a distributed unit. In some embodiments, gNBs 910 and 920 may include multiple distributed units communicating with the centralized unit.

[0163] Figure 11 A message stream sequence 1000 according to an example embodiment is shown.

[0164] Message flow sequence 1000 can occur between elements of system 900.

[0165] In step 1010, UE 905 sends a measurement report to DU1 914.

[0166] In step 1012, DU1 914 sends a measurement report to CU1 912.

[0167] In step 1014, in response to receiving a measurement report, CU1 912 triggers the LTM preparation process. CU1 912 can generate keys for all candidate cells using horizontal key derivation. CU1 912 can create key update groups. Candidate cells can be mapped to key update groups corresponding to their associated gNBs. Using this mapping, the indication of the key update group can be determined based on the indication of the candidate cell (e.g., a candidate cell ID can be mapped to a key update group ID), and candidate cells mapped to different key update groups can indicate that the candidate cell is associated with a different gNB.

[0168] In step 1016, an LTM preparation request is sent to the target gNB 920. The key generated using level key derivation and the configured groups (multiple) / mappings can be embedded in this request.

[0169] In step 1018, the target gNB 920 / CU2 922 prepares the LTM configuration by embedding the key update group / mapping into the LTM configuration.

[0170] In steps 1020 and 1022, CU2 922 obtains the context from DU2 924 by sending a UE context establishment request message to DU2 924 and receiving a UE context establishment response message from DU2 924.

[0171] In step 1024, in the confirmation message, LTM preparation is notified from CU2 922 to CU1 912.

[0172] In steps 1026 and 1028, CU1 912 contacts DU1 914 to prepare for UE measurement configuration by sending a UE context modification request message to DU1 914 and receiving a UE context modification response message from DU1 914.

[0173] In step 1030, UE 905 is configured using a set of rules for key generation. The rules for key generation may include algorithm 600. UE 905 stores these configured rules for further key generation during the handover process. UE 905 also stores a key update group, enabling determination of whether the handover is an intra-gNB handover. The rules for key generation and the key update group can be provided to UE 905 in an RRC reconfiguration message.

[0174] In step 1032, UE 905 sends a reconfiguration complete message.

[0175] Therefore, message flow sequence 1000 can prepare the UE for the LTM procedure. One or more key update groups can be associated with one or more candidate cells, such that cells within the same key update group are associated with the same gNB. A key derived using horizontal key derivation may have already been generated for each candidate cell.

[0176] Figure 12 and Figure 13 The first and second parts of message stream sequence 1100 are shown. In this message stream sequence, the UE maintains its local NCC value. This message stream sequence contains two handovers, both of which occur between cells associated with different gNBs.

[0177] Message flow sequence 1100 can occur between elements of system 900.

[0178] In step 1110, UE 905 sends an L1 (physical layer) measurement report to DU1 914.

[0179] In step 1112, and in response to receiving the measurement report, DU1 914 sends a cell handover command to UE 905. The cell handover command may be a MAC CE command indicating the target cell ID. The cell handover command may also indicate whether the cell handover corresponds to a handover between cells associated with different gNBs.

[0180] In step 1114, DU1 914 notifies CU1 912 of the change in the cell serving UE 905.

[0181] In step 1116, UE 905 performs a cell handover. UE 905 determines whether the handover is between cells associated with different gNBs based on the indicated target cell ID. In other embodiments, the handover status can be indicated in the MAC CE command. UE 905 may use an algorithm such as Algorithm 600 at this stage to determine the updated NCC value and the updated NCC_increment value. UE 905 may also determine at this stage whether to use horizontal key derivation or vertical key derivation, also using a key derivation algorithm such as Algorithm 600.

[0182] In this example, the handover is between cells associated with different gNBs, so the NCC_increment is incremented by 1, the local NCC value is not updated, and it is derived using the horizontal key.

[0183] Using horizontal key derivation, UE 905 can derive a key corresponding to the key derived on the network side. The corresponding key generated using horizontal key derivation can be provided to CU2 922 during the LTM preparation process, such as step 1016 of message flow sequence 1000, or after the LTM handover process, for use after inter-gNB handover.

[0184] In step 1118, UE 905 sends an RRC reconfiguration complete message to DU2 924 and CU2 922.

[0185] In step 1120, DU2 924 sends an access notification to CU2 922.

[0186] In step 1122, the serving node CU2 922 notifies CU1 912 of the next key (multiple) generated using the level key derivation, for use in the event of an inter-gNB handover to CU1 912's cell. If the network and / or UE 905 is configured for LTM handover between cells associated with more gNBs, the next key generated using the level key derivation can be notified to more gNBs. The current serving node CU2 922 can send the next key (multiple) via the Xn interface.

[0187] In step 1124, the previous serving node CU1 912 can compute the next key using horizontal key derivation based on the previous key. Since CU1 912 is the previous serving node, it will have the information needed to compute the next key using horizontal key derivation. This step is optional, and CU2 922 can alternatively send the next key generated using horizontal key derivation to CU1 (e.g., via the Xn interface). If the optional step 1124 occurs, it may not be necessary to send the next key to the previous serving node CU1 912, but other nodes configured for LTM may still need to receive the next key generated using horizontal key derivation.

[0188] In step 1126, the new current serving node sends a path switching request to AMF 930, notifying AMF 930 of the inter-gNB handover. AMF 920 will increment its NCC counter.

[0189] In step 1128, AMF 930 sends a path handover confirmation message to the current serving node CU2 922. This message includes an incremented NCC value and an updated NCC value to generate a key on the network side for use after the next handover, if the next handover is vertical.

[0190] In step 1130, CU2 922 uses vertical key derivation to calculate the next key (using NCC and NH values). At this stage, the key generated using horizontal key derivation has been transmitted to or otherwise obtained by a candidate gNB outside the serving gNB, and the serving gNB has generated a vertical key. Because the previous handover was an inter-gNB handover, if the next handover is an intra-gNB handover (and the serving gNB after the handover is the current serving gNB), the next key will be vertical. Because horizontal key generation is used when a handover results in a change of serving gNB, the next key will be horizontal if the next handover is not between cells associated with the current serving gNB.

[0191] In step 1132, UE 905 sends another L1 measurement report to the current serving gNB (in this example, DU2 924 sent to the current serving gNB). This measurement report may contain measurements, based on which the serving gNB can determine that a second handover is expected.

[0192] In step 1134, DU2 924 responsively sends a cell handover command. The cell handover command may be a MAC CE command indicating the target cell ID. The cell handover command may also indicate whether the cell handover corresponds to a handover between cells associated with different gNBs. In this case, the cell handover does indeed correspond to a handover between cells associated with different gNBs.

[0193] In step 1136, DU2 924 sends a serving cell change notification to CU2 922. CU2 922 determines that the cell change corresponds to an inter-gNB handover (e.g., according to the indication in the serving cell change notification).

[0194] In step 1138, CU2 922 may delete the NH value received in step 1128 and / or the key generated using vertical key derivation, since vertical key derivation will not be used in the event of a gNB handover.

[0195] In step 1140, in response to the cell handover command of step 1134, UE 905 performs an LTM cell change procedure. UE 905 can determine, based on the indication in the cell handover command, that the handover is between cells associated with different gNBs, and therefore needs to use horizontal key derivation. Therefore, UE 905 may not align its locally maintained NCC value with the AMF NCC value, and may increment its NCC_increment value again. UE 905 can then use horizontal key derivation to generate a key corresponding to the key generated on the network side (in step 1122 or 1124).

[0196] In step 1142, UE 905 sends an RRC reconfiguration complete message to the new service CU and DU of the new service gNB, namely CU1 912 and DU1 914.

[0197] In step 1144, CU1 912 uses the key obtained in step 1122 or 1124 to decrypt the message from UE 905.

[0198] In step 1146, similar to step 1122, the new serving node CU1 912 notifies CU2 922 of the next key (multiple) generated using the level key derivation, for use in the event of an inter-gNB handover to a cell of CU2 922. If the network and / or UE 905 is configured for LTM handover between cells associated with more gNBs, the next key (multiple) generated using the level key derivation can be notified to more gNBs. The current serving node CU1 912 can send the next key (multiple) via the Xn interface.

[0199] Steps 1148 and 1150 correspond to steps 1126 and 1128, respectively.

[0200] Figure 14 and Figure 15The first and second parts of message stream sequence 1200 are shown. In this message stream sequence, the UE maintains its local NCC value. This message stream sequence contains three handovers: the first between cells associated with different gNBs, the second between cells associated with the same gNB, and the third between cells associated with different gNBs.

[0201] Message stream sequence 1200 can occur between elements of system 900.

[0202] In step 1210, UE 905 sends an L1 (physical layer) measurement report to DU1 914.

[0203] In step 1212, and in response to receiving the measurement report, DU1 914 sends a cell handover command to UE 905. The cell handover command may be a MAC CE command indicating the target cell ID. The cell handover command may also indicate whether the cell handover corresponds to a handover between cells associated with different gNBs.

[0204] In step 1214, DU1 914 notifies CU1 912 of the change in the cell serving UE 905.

[0205] In step 1216, UE 905 performs a cell handover. UE 905 determines whether the handover is between cells associated with different gNBs based on the indicated target cell ID. In other embodiments, the handover status can be indicated in the MAC CE command. UE 905 may use an algorithm such as Algorithm 600 at this stage to determine the updated NCC value and the updated NCC_increment value. UE 905 may also determine at this stage whether to use horizontal key derivation or vertical key derivation, also using a key derivation algorithm such as Algorithm 600.

[0206] In this example, the handover is between cells associated with different gNBs, so the NCC_increment is incremented by 1, the local NCC value is not updated, and it is derived using the horizontal key.

[0207] Using horizontal key derivation, UE 905 can derive a key corresponding to the key derived on the network side. The corresponding key generated using horizontal key derivation can be provided to CU2 922 during the LTM preparation process, such as step 1014 of message flow sequence 1000, or after the LTM handover process, for use after inter-gNB handover.

[0208] In step 1218, UE 905 sends an RRC reconfiguration complete message to DU2 924 and CU2 922.

[0209] In step 1220, DU2 924 sends an access notification to CU2 922.

[0210] In step 1222, the serving node CU2 922 notifies CU1 912 of the next key (multiple) generated using the level key derivation, for use in the event of an inter-gNB handover to CU1 912's cell. If the network and / or UE 905 are configured for LTM handovers between cells associated with more gNBs, the next key (multiple) generated using the level key derivation can be notified to more gNBs. The current serving node CU2 922 can send the next key (multiple) via the Xn interface.

[0211] In step 1224, the new current serving node sends a path switching request to AMF 930, notifying AMF 930 of the inter-gNB handover. AMF 920 will increment its NCC counter.

[0212] In step 1226, AMF 930 sends a path handover confirmation message to the current serving node CU2 922. This message includes an incremented NCC value and an updated NCC value to generate a key on the network side for use after the next handover, if the next handover is vertical.

[0213] In step 1228, CU2 922 uses vertical key derivation to calculate the next key (using NCC and NH values). At this stage, the key generated using horizontal key derivation has been transmitted to or otherwise obtained by a candidate gNB outside the serving gNB, and the serving gNB has already generated a key using vertical key derivation. Because the previous handover was an inter-gNB handover, if the next handover is an intra-gNB handover (and the serving gNB after the handover is the current serving gNB), the next key will be vertical. Because horizontal key generation is used when a handover results in a change of serving gNB, the next key will be horizontal if the next handover is not between cells associated with the current serving gNB.

[0214] In step 1232, UE 905 sends another L1 measurement report to the current serving gNB (in this example, DU2 924 sent to the current serving gNB). This measurement report may contain measurements, based on which the serving gNB can determine that a second handover is expected.

[0215] In step 1234, DU2 924 responsively sends a cell handover command. The cell handover command may be a MAC CE command indicating the target cell ID. The cell handover command may also indicate whether the cell handover corresponds to a handover between cells associated with different gNBs. In this case, the cell handover corresponds to a handover between cells associated with the same gNB (i.e., CU2 922 will remain the centralized unit serving UE 905).

[0216] In step 1236, DU2 924 sends a serving cell change notification to CU2 922. CU2 922 determines that the cell change corresponds to an intra-gNB handover (e.g., according to the indication in the serving cell change notification).

[0217] In step 1238, in response to the cell handover command of step 1234, UE 905 performs an LTM cell change procedure. During the LTM cell change procedure, algorithm 600 can be used to determine the key generation type to be used and the updated NCC value. UE 905 can determine, based on the indication in the cell handover command, that the handover is between cells associated with the same gNB, and UE 905 can determine that the previous handover was between cells associated with different gNBs (e.g., based on the non-zero NCC_increment value incremented in step 1216), and therefore, vertical key derivation should be used. Therefore, UE 905 can align its locally maintained NCC value with the AMF NCC value by incrementing the local NCC_increment value and resetting the NCC_increment value to zero. UE 905 can then use vertical key derivation to generate a key corresponding to the key generated on the network side (in step 1228).

[0218] In step 1240, UE 905 sends an RRC reconfiguration complete message to the serving CU and DU of the serving gNB, namely CU2 922 and DU2 924.

[0219] In step 1242, similar to step 1222, CU2 922 notifies CU1 912 of the next key (multiple) generated using the level key derivation, for use in the event of an inter-gNB handover to CU1 912's cell. If the network and / or UE 905 is configured for LTM handover between cells associated with more gNBs, the next key (multiple) generated using the level key derivation can be notified to more gNBs. The current serving node CU2 922 can send the next key (multiple) via the Xn interface.

[0220] In step 1244, UE 905 sends another L1 measurement report to the current serving gNB (in this example, DU2 924 sent to the current serving gNB). This measurement report may contain measurements, based on which the serving gNB can determine that a third handover is expected.

[0221] In step 1246, DU2 924 responsively sends a cell handover command. The cell handover command may be a MAC CE command indicating the target cell ID. The cell handover command may also indicate whether the cell handover corresponds to a handover between cells associated with different gNBs. In this case, the cell handover corresponds to a handover between cells associated with different gNBs (i.e., after the handover, CU2 922 will no longer be the centralized unit serving UE 905).

[0222] Steps 1248 to 1254 correspond to steps 1214 to 1218 and 1222. Steps 1248, 1250, 1252 and 1254 correspond to steps 1214, 1216, 1218 and 1222 respectively, wherein the switching direction from one gNB to another gNB is reversed.

[0223] Figure 16 This is a block diagram of a gNB 1300 according to an example embodiment. The gNB 1300 includes a memory 1305, a processor 1310, and a transmitter 1315. In some embodiments, the gNB 1300 may include features of a device 400.

[0224] Memory 1305 can store a local counter and a second local counter. In some examples, the local counter and the second local counter correspond to the NCC value and the NCC increment value, respectively.

[0225] Processor 1310 can update the local counter stored in memory 1305 by incrementing the local counter by an amount based on a second local counter, according to a predetermined algorithm, such that the local counter is aligned with the corresponding counter in the network node (e.g., the network node may be an AMF). This update step can be performed in response to determining whether to use vertical key derivation to generate a key for encrypting and / or decrypting communication between the user equipment and the next-generation node B gNB.

[0226] The transmitter 1315 may send an updated value of a local counter, determined by the processor 1310, to the user equipment. The user equipment may use the updated value of the local counter to determine whether to use horizontal key derivation and / or vertical key derivation. The user equipment may additionally or alternatively use the updated value of the local counter as part of the key derivation.

[0227] Figure 17This is a flowchart of method 1400 according to an example embodiment. Some or all of the steps of method 1400 may be performed by gNB 1300. In some embodiments, method 1400 may include the steps of method 500.

[0228] In step 1410, it is determined that vertical key generation will be used to generate the key.

[0229] In step 1412, according to a predetermined algorithm, the stored local counter is updated by incrementing the local counter by an amount based on the second local counter, such that the local counter is aligned with the corresponding counter in the network node (e.g., the network node may be an AMF). The stored local counter and the second local counter may be stored in memory 1305, and the update may be performed by processor 1310.

[0230] In step 1414, the value of the local counter or an indication of the value of the local counter is sent to the user equipment. This step can be performed by transmitter 1315.

[0231] In the example embodiments of gNB 1300 and method 1400, local NCC and NCC_increment are maintained on the gNB side. Keys are generated on the network side and user equipment side based on the current handover type and the previous handover type.

[0232] The gNB 1300 can have the features of the gNB 910 or 920 of the system 900.

[0233] In some example implementations, the local NCC and NCC_increment are maintained by the gNB's DU.

[0234] Figure 18 A message stream sequence 1500 according to an example embodiment is shown.

[0235] Message stream sequence 1500 can occur between elements of system 900.

[0236] In step 1510, UE 905 sends a measurement report to DU1 914.

[0237] In step 1512, DU1 914 sends a measurement report to CU1 912.

[0238] In step 1514, in response to receiving a measurement report, CU1 912 triggers the LTM preparation process. CU1 912 can generate keys for all candidate cells using the level key derivation. CU1 912 can create key update groups. Candidate cells can be mapped to key update groups corresponding to their associated gNBs. Using the mapping, the indication of the key update group can be determined based on the indication of the candidate cell (e.g., a candidate cell ID can be mapped to a key update group ID), and candidate cells mapped to different key update groups can indicate that the candidate cell is associated with a different gNB.

[0239] In step 1516, an LTM preparation request is sent to the target gNB 920. The key generated using horizontal key derivation and the configured key update groups (multiple) / configured mappings can be embedded in this request.

[0240] In step 1518, the target gNB 920 / CU2 922 prepares the LTM configuration by embedding the key update group / mapping into the LTM configuration.

[0241] In steps 1520 and 1522, CU2 922 obtains the context from DU2 924 by sending a UE context establishment request message to DU2 924 and receiving a UE context establishment response message from DU2 924. In step 1520, a key update group configuration / mapping is provided to DU2 924. CU2 922 may additionally or alternatively utilize a set of rules for key generation to configure DU2 924, which may include algorithm 600.

[0242] In step 1524, in a confirmation message, LTM preparation is notified from CU2 922 to CU1 912.

[0243] In steps 1526 and 1528, CU1 912 contacts DU1 914 to prepare for UE measurement configuration by sending a UE context modification request message to DU1 914 and receiving a UE context modification response message from DU1 914. In step 1526, CU1 912 provides DU1 914 with a key update group configuration / mapping. CU1 912 may additionally or alternatively utilize a set of rules for key generation to configure DU1 914, which may include algorithm 600.

[0244] In step 1530, an RRC reconfiguration message is sent to UE 905 to configure UE 905 for the LTM procedure. Key update group configuration / mapping can also be provided to UE 905.

[0245] In step 1532, UE 905 sends a reconfiguration complete message.

[0246] Therefore, message flow sequence 1500 can prepare the UE for the LTM procedure. Using the mapping between candidate cells and key update groups, the DU can determine whether the handover is between cells associated with the same gNB or between cells associated with different gNBs based on the mapping and the identifiers of the current cell and the target / next cell. Using this determination and the rules for key generation, the DU can indicate to the UE the key derivation method to be used for the next key, for example, by transmitting a changed or unchanged NCC value to the UE. The DU can also indicate the NCC value to the UE without explicitly sending the NCC value, for example, by mapping the NCC value to another indicator.

[0247] Figure 19 and Figure 20 The first and second parts of message flow sequence 1600 are shown. In this message flow sequence, the network maintains local NCC values ​​at the serving DU. This message flow sequence contains two handovers, both of which occur between cells associated with different gNBs.

[0248] Message stream sequence 1600 can occur between elements of system 900.

[0249] In step 1610, DU1 is storing the local NCC value and the NCC_increment value. The NCC_increment value can be zero (e.g., because the previous handover was an intra-gNB handover), and the NCC value can be aligned with the AMF NCC value.

[0250] In step 1612, UE 905 sends an L1 (physical layer) measurement report to DU1 914.

[0251] In step 1614, and in response to receiving the measurement report, DU1 914 determines that the cell serving UE 905 needs to be changed to a different cell (“target” cell). DU1 914 uses the mapping configured during the LTM preparation process to determine the key update group for the cell ID mapped to the target cell. In this case, the target cell corresponds to a different key update group than the current serving cell, so the handover is between cells associated with different gNBs. DU1 914 uses a configured algorithm (such as Algorithm 600) to determine the key derivation type and the updated NCC value. In this case, because the handover is between gNBs, the key derivation type is horizontal, and the updated NCC value remains unchanged. The NCC_increment value is incremented by 1.

[0252] In step 1616, DU1 914 sends a cell handover command to UE 905. The cell handover command indicates the target cell ID and the updated NCC value. The cell handover command can be a MAC CE command.

[0253] In step 1618, DU1 914 notifies CU1 912 of the change in the cell serving UE 905. In step 1618, DU1 914 may also notify CU1 912 of the updated local NCC value and NCC_increment value, so that these values ​​can be provided to the next serving DU.

[0254] In step 1620, UE 905 performs a cell handover. Based on the updated NCC value, UE 905 can determine whether to use horizontal key derivation or vertical key derivation, such that the key derivation used at UE 905 matches the key derivation used on the network side (e.g., at CU2 922, i.e., the CU of the new serving gNB). In this case, the horizontal key derivation can be determined based on the updated NCC value being the same as the previous NCC value.

[0255] Using horizontal key derivation, UE 905 can derive a key corresponding to the key derived on the network side. This corresponding key, generated using horizontal key derivation, can be provided to CU2 922 during the LTM preparation process, such as step 1516 of message flow sequence 1500, or after the LTM handover process, for use after inter-gNB handover.

[0256] In step 1622, UE 905 sends an RRC reconfiguration complete message to DU2 924 and CU2 922.

[0257] In step 1624, DU2 924 sends an access notification to CU2 922.

[0258] In step 1626, the serving node CU2 922 notifies CU1 912 of the next key (multiple) generated using the level key derivation, for use in the event of a handover between gNBs to CU1 912's cell. If the network and / or UE 905 are configured for LTM handovers between cells associated with more gNBs, the next key (multiple) generated using the level key derivation can be notified to more gNBs. The current serving node CU2 922 can send the next key (multiple) via the Xn interface. CU1 912 also shares the local NCC value and NCC_increment value with CU2 922 (i.e., with the other CUs (multiple) corresponding to the candidate cell gNB).

[0259] In step 1628, the new current serving node sends a path switching request to AMF 930, notifying AMF 930 of the inter-gNB handover. AMF 920 increments its NCC counter.

[0260] In step 1630, AMF 930 sends a path handover confirmation message to the current serving node CU2 922. This message includes an incremented NCC value and an updated NCC value to generate a key on the network side for use after the next handover, if the next handover is vertical.

[0261] In step 1632, CU2 922 uses vertical key derivation to calculate the next key (using NCC and NH values). At this stage, the key generated using horizontal key derivation has been transmitted to or otherwise obtained by a candidate gNB outside the serving gNB, and the serving gNB has already generated a key using vertical key derivation. Since the previous handover was an inter-gNB handover, if the next handover is an intra-gNB handover (and the serving gNB after the handover is the current serving gNB), the next key will be vertical. Since horizontal key generation is used when a handover results in a change of serving gNB, the next key will be horizontal if the next handover is not between cells associated with the current serving gNB.

[0262] In step 1634, UE 905 sends another L1 measurement report to the current serving gNB (in this example, DU2 924 to the current serving gNB). This measurement report may contain measurements based on which the serving gNB (or, in this example, DU2 924 of the current serving gNB) can determine that a second handover is expected.

[0263] In step 1636, and in response to receiving the measurement report, DU2 924 determines that the cell serving UE 905 needs to be changed to a different cell (“target” cell). DU2 924 uses the mapping configured during the LTM preparation process to determine the key update group for the cell ID mapped to the target cell. In this case, the target cell corresponds to a different key update group than the current serving cell, so the handover is between cells associated with different gNBs. DU2 924 uses a configured algorithm (such as Algorithm 600) to determine the key derivation type and the updated NCC value. In this case, because the handover is between gNBs, the key derivation type is horizontal, and the updated NCC value remains unchanged. The NCC_increment value is incremented by 1 (incrementing to 2, assuming the NCC_increment was zero in step 1610).

[0264] In step 1638, DU2 914 sends a cell handover command to UE 905. The cell handover command indicates the target cell ID and the updated NCC value. The cell handover command can be a MAC CE command.

[0265] In step 1640, DU2 914 notifies CU2 912 of the change in the cell serving UE 905. In step 1618, DU2 914 may also notify CU2 912 of the updated local NCC value and NCC_increment value, so that these values ​​can be provided to the next serving DU.

[0266] In step 1642, UE 905 performs a cell handover, similar to the cell handover in step 1620. As in step 1620, the updated NCC value is the same as the previous NCC value, therefore the key derivation used is horizontal.

[0267] In step 1644, UE 905 sends an RRC reconfiguration complete message to the new service CU and DU of the new service gNB, namely CU1 912 and DU1 914.

[0268] In step 1648, CU1 912 uses the key obtained in step 1626 and generated using the horizontal key derivation to decrypt the message from UE 905.

[0269] In step 1650, similar to step 1626, CU2 922 provides CU1 912 with the updated local NCC value and NCC_increment value, and CU1 912 provides CU2 922 with the next key generated using the horizontal key derivation.

[0270] In steps 1652 and 1654, similar to steps 1628 and 1630, CU1 912 sends a path switching request to AMF 930. AMF 930 increments the NCC value, and AMF returns the updated NCC and NH values ​​in the path switching confirmation message. The updated NH and NCC values ​​can be used on the network side to derive keys using vertical key derivation.

[0271] Figure 21 and Figure 22 The first and second parts of message flow sequence 1700 are shown. In this message flow sequence, the UE maintains its local NCC value. This message flow sequence contains three handovers: the first between cells associated with different gNBs, the second between cells associated with the same gNB, and the third between cells associated with different gNBs.

[0272] Message flow sequence 1700 can occur between elements of system 900.

[0273] Steps 1710 to 1732 involve the first intra-gNB handover, and therefore correspond to comparable steps 1610 to 1632 of method 1600.

[0274] In step 1734, UE 905 sends another L1 measurement report to the current serving gNB (in this example, DU2 924 to the current serving gNB). This measurement report may contain measurements based on which the serving gNB (or, in this example, DU2 924 of the current serving gNB) can determine that a second handover is expected.

[0275] In step 1736, and in response to receiving a measurement report, DU2 924 determines that the cell serving UE 905 is to be changed to a different cell (“target” cell). DU2 924 uses the mapping configured during the LTM preparation process to determine the key update group for the cell ID mapped to the target cell. Unlike step 1636, in this case, the target cell corresponds to the same key update group as the current serving cell, so the handover is between cells associated with the same gNB. DU2 924 uses a configured algorithm (such as Algorithm 600) to determine the key derivation type and the updated local NCC value. In this case, because the handover is an intra-gNB handover, and the previous handover was an inter-gNB handover (which can be inferred from the non-zero NCC_increment value in some examples), the NCC value increments by the NCC_increment value, and the key derivation type is vertical. If we take the initial local NCC value in step 1710 to 0, the updated local NCC will be 1 because the NCC_increment value is 1. After updating the local NCC value, the NCC_increment value is reset to zero, and the local NCC value is now aligned with the AMF NCC value.

[0276] In step 1738, similar to step 1638, DU2 914 sends a cell handover command to UE 905. The cell handover command indicates the target cell ID and the updated NCC value. The cell handover command can be a MAC CE command.

[0277] In step 1740, DU2 914 notifies CU2 912 of the change in the cell serving UE 905. In step 1618, DU2 914 may also notify CU2 912 of the updated local NCC value and NCC_increment value, so that these values ​​can be provided to the next serving DU.

[0278] In step 1742, UE 905 performs a cell handover, similar to the cell handover in steps 1620 and 1720. Unlike steps 1620 and 1720, the updated NCC value is different from the previous NCC value, therefore the key derivation used is vertical.

[0279] In step 1744, UE 905 sends an RRC reconfiguration complete message to DU2 924 and CU2 922.

[0280] In step 1746, similar to step 1626, the previous service CU (which is also the current service CU in this case, i.e., CU2 922) sends the updated local NCC and NCC_increment to the other CUs configured for LTM (in this case, only CU1 912), and the current service CU CU2 922 sends the next key generated using the level key derivation to the other CUs configured for LTM.

[0281] In step 1748, UE 905 sends another L1 measurement report to the current serving gNB.

[0282] Steps 1750 to 1760 correspond to steps 1714 to 1722 and 1726, illustrating subsequent gNB handovers, which will use horizontal key derivation.

[0283] Figure 23 This is a block diagram 1800 showing the subsequent key derivation steps in the context of the elements of model 100.

[0284] Block diagram 1800 illustrates vertical key derivation step 1810 and horizontal key derivation step 1812 based on the initial NH value and the previous key, respectively, and shows the progress of the NCC value and key as handover to cells in different key update groups occurs.

[0285] The initial key KgNB 1820 can be generated by the UE served by the cell corresponding to the first key update group (key update group 1) for encrypting and / or decrypting communication between the UE and the gNB. KgNB 1820 is generated using vertical key derivation 1810 based on the NH value (as well as the cell ID and downlink frequency, not shown). In this example, the NCC value stored at the AMF and the local NCC value can initially be 1 (the initial values ​​are not important for the purposes of this example).

[0286] In the first handover, the UE is switched to the cell corresponding to the second key update group (key update group 2). Since the key update group has changed, this handover is an inter-gNB / inter-CU handover, so the second key KgNB 1822 is derived using horizontal key derivation 1812. The local NCC value remains unchanged, but the NCC_increment is incremented by 1, becoming 1. KgNB 1822 is sent as a message to other gNBs / CUs for subsequent horizontal key derivation (for inter-gNB / inter-CU handovers).

[0287] In the second handover, the UE is switched to the cell corresponding to the third key update group (key update group 3). The key update group changes again, therefore this handover is an inter-gNB / inter-CU handover, so the third key KgNB 1824 is derived using horizontal key derivation 1812. The local NCC value remains unchanged, but the NCC_increment is incremented by 1, becoming 2. KgNB 1824 is sent as a message to other gNBs / CUs for subsequent horizontal key derivation (for inter-gNB / inter-CU handover).

[0288] In the third handover, the UE is switched to service by the cell corresponding to key update group 3. The key update group remains unchanged, therefore this handover is intra-gNB / intra-CU. The previous handover was inter-gNB / inter-CU, so the fourth key KgNB 1826 is derived using vertical key derivation 1810. The NCC value increments by the NCC_increment (2 in this case), becoming 3. The NCC_increment value is reset. The updated NCC and NH values ​​are used to derive the key. KgNB 1826 is sent as a message to other gNBs / CUs for subsequent horizontal key derivation (for inter-gNB / inter-CU handover).

[0289] In the fourth handover, the UE is again switched to the cell corresponding to key update group 3. The key update group remains unchanged, therefore this handover is intra-gNB / intra-CU. Previous handovers were also intra-gNB / intra-CU handovers, therefore horizontal key derivation is used, and the fifth key KgNB 1828 is derived from KgNB 1826. KgNB 1828 is sent as a message to other gNBs / CUs for subsequent horizontal key derivation (for inter-gNB / inter-CU handovers).

[0290] For the sake of completeness, Figure 24 This is a schematic diagram of one or more components in the previously described exemplary embodiments, which are generally referred to below as processing system 1900. Processing system 1900 may, for example, be comprised of the devices mentioned in the following claims.

[0291] The processing system 1900 may include a processor 1902, a memory 1904 tightly coupled to the processor and including RAM 1914 and ROM 1912, and optionally a user input 1910 and a display 1918. The processing system 1900 may include one or more network / device interfaces 1908 for connecting to a network / device, such as a wired or wireless modem. The network / device interface 1908 may also operate as a connection to other devices, such as devices that are not network-side devices. Therefore, direct connections between devices / devices without network involvement are possible.

[0292] The processor 1902 is connected to each of the other components in order to control their operation.

[0293] Memory 1904 may include non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD). The ROM 1912 of memory 1904 stores the operating system 1915, and may also store software applications 1916. The RAM 1914 of memory 1904 is used by processor 1902 for temporary data storage. The operating system 1915 may contain code that, when executed by the processor, implements aspects of methods 500, 800, and 1400 described above, as well as aspects of message flow sequences 300, 1000, 1100, 1200, 1500, 1600, and 1700 and algorithm 600. Note that in the case of small devices, memory may be best suited for small-size applications, i.e., hard disk drives (HDDs) or solid-state drives (SSDs) are not always used.

[0294] The processor 1902 can take any suitable form. For example, it can be a microcontroller, multiple microcontrollers, a processor, or multiple processors.

[0295] The processing system 1900 can be a standalone computer, server, console, or its network. The processing system 1900 and the necessary structural components can all be embedded within a device, such as an IoT device, i.e., in a very small size.

[0296] In some example embodiments, the processing system 1900 may also be associated with external software applications. These may be applications stored on a remote server device / device and may run partially or entirely on the remote server device / device. These applications may be referred to as cloud-hosted applications. The processing system 1900 may communicate with the remote server device / device to utilize the software applications stored there.

[0297] Figure 25 A tangible medium in the form of a removable memory unit 2010 storing computer-readable code is illustrated, which, when run by a computer, can execute the methods according to the example embodiments described above. The removable memory unit 2010 may be a memory stick, such as a USB memory stick, having internal memory 2030 for storing computer-readable code. The internal memory 2030 can be accessed by a computer system via a connector 2020. Of course, other forms of tangible storage media can be used, as will be apparent to those skilled in the art. The tangible medium can be any device / apparatus capable of storing data / information that can be exchanged between devices / apparatus / networks.

[0298] Embodiments of the present invention can be implemented in software, hardware, application logic, or a combination of software, hardware, and application logic. The software, application logic, and / or hardware can reside on memory or any computer medium. In example embodiments, the application logic, software, or instruction set is maintained on any of a variety of conventional computer-readable media. In the context of this document, "memory" or "computer-readable medium" can be any non-transitory medium or component that can contain, store, transmit, propagate, or transfer instructions for use by or in connection with an instruction execution system, apparatus, or device (such as a computer).

[0299] In relevant contexts, references to “computer-readable medium,” “computer program product,” “tangible computer program,” or “processor” or “processing circuitry” should be understood to encompass not only computers with different architectures (such as single / multiprocessor architectures and sequencer / parallel architectures) but also special-purpose circuits (such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), signal processing devices / apparatus, and other devices / apparatus). References to computer programs, instructions, code, etc., should be understood to refer to software used in programmable processor firmware, such as the programmable content of hardware devices / apparatus as processor instructions, or the configured settings or configuration settings of fixed-function devices / apparatus, gate arrays, programmable logic devices / apparatus, etc.

[0300] If necessary, the different functions discussed herein can be executed in different orders and / or simultaneously with each other. Furthermore, if necessary, one or more of the above functions can be optional or can be combined. Similarly, it should be understood that... Figure 3 , 4 The algorithms, flow charts, and signaling diagrams for numbers 6, 7, 9, 11, 12, 13, 14, 15, 17, 18, 19, 20, 21, and 22 are merely examples, and the various operations depicted therein may be omitted, reordered, and / or combined.

[0301] It should be understood that the above exemplary embodiments are purely illustrative and do not limit the scope of the invention. Other variations and modifications will be apparent to those skilled in the art after reading this specification.

[0302] Furthermore, the disclosure of this application should be understood to include any novel feature or any novel combination of features or any generalization thereof explicitly or implicitly disclosed herein, and new claims may be formulated during the examination of this application or any application derived therefrom to cover any such feature and / or combination of such features.

[0303] Although various aspects of the invention are set forth in the independent claims, other aspects of the invention include other combinations of features from the described exemplary embodiments and / or dependent claims with features of the independent claims, and not only those combinations expressly set forth in the claims.

[0304] It should also be noted that while various examples have been described above, these descriptions should not be considered limiting. Rather, several changes and modifications may be made without departing from the scope of the invention as defined in the appended claims.

Claims

1. An apparatus comprising: A component used to store local counters; The component is used to: in response to determining that a key for encrypting and / or decrypting communication between the user equipment and the next-generation node (gNB) should be generated using vertical key derivation, update the local counter according to a predetermined algorithm such that the local counter is aligned with the corresponding counter in the network node. The key generated using the vertical key derivation is generated at least in part based on the updated local counter.

2. The apparatus of claim 1, further comprising a component for storing a second local counter, Updating the local counter according to the predetermined algorithm includes: The local counter is incremented based on the amount of the second local counter.

3. The apparatus according to claim 2, further comprising: A component used to obtain an indication of whether the current handover is between cells associated with the same gNB or between cells associated with different gNBs; A component used to obtain an indication of whether a previous handover was between cells associated with the same gNB or between cells associated with different gNBs; as well as The component is used to determine, at least in part, whether to generate a key using horizontal key derivation or vertical key derivation based on one or both of the following: the indication that the current handover is a handover between cells associated with the same gNB or between cells associated with different gNBs, and the indication that the previous handover was a handover between cells associated with the same gNB or between cells associated with different gNBs.

4. The apparatus of claim 3, wherein the component for determining whether to use horizontal key derivation or vertical key derivation to generate the key is configured to: determine that horizontal key derivation should be used when the current handover and the previous handover are handovers between cells associated with the same gNB.

5. The apparatus of any one of claims 3 or 4, wherein the component for determining whether to generate the key using horizontal key derivation or vertical key derivation is configured to: determine that vertical key derivation should be used when the current handover is a handover between cells associated with the same gNB and the previous handover is a handover between cells associated with different gNBs, and wherein the component for updating the local counter is configured to: reset the second local counter to zero in response to updating the local counter.

6. The apparatus according to any one of claims 3-5, wherein: The component used to determine whether to use horizontal key derivation or vertical key derivation to generate a key is configured to: determine that horizontal key derivation should be used when the current handover is a handover between cells associated with different gNBs; and The apparatus further includes components for incrementing a second local counter in response to the current handover being a handover between cells associated with different gNBs.

7. The apparatus according to any one of claims 1 to 6, wherein the apparatus is a current gNB, and further comprises: A component used to provide the user equipment with an indication of the value of the local counter.

8. The apparatus according to claim 7, further comprising: Components used to obtain a list of candidate cells; Components for performing handover between cells associated with the current gNB; A component for informing one or more gNBs associated with cells in the candidate cell list that a handover between cells associated with the current gNB has occurred; The component is used for the following: for each cell in the candidate cell list, a key is generated using horizontal key derivation for use in a cell handover event to that cell; as well as The component is used to send the generated key to each of the one or more gNBs for use in a cell handover event to the cell associated with that gNB.

9. The apparatus according to claim 7 or 8, further comprising: Components used to obtain a list of candidate cells; A component used to complete a handover from a cell associated with a different gNB to a cell associated with the current gNB; The component is used to indicate to one or more gNBs associated with cells in the candidate cell list that a handover between cells associated with different gNBs has occurred; The component is used for the following: for each cell in the candidate cell list, a key is generated using horizontal key derivation for use in a cell handover event to that cell; as well as The component is used to send the generated key to each network node in one or more gNBs for use in a cell handover event to the cell associated with that gNB.

10. The apparatus according to any one of claims 7 to 9, further comprising: A component for storing the current cell ID, which corresponds to the cell associated with the user equipment; A component for obtaining the target cell ID corresponding to the target cell, wherein the user equipment is to be handed over from the current cell to the target cell; as well as The component is used to determine, based on the target cell ID and the current cell ID, whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs.

11. The apparatus according to any one of claims 1 to 6, wherein the apparatus is a user equipment, and further comprises: The component for generating a key using the determined key derivation, wherein if vertical key derivation is selected, the generated key is at least partially based on the local counter.

12. The apparatus of claim 11, further comprising: Component used to store the current cell ID; Components used to receive the target cell ID from the gNB; as well as The component is used to determine, based on the target cell ID and the current cell ID, whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs.

13. A method comprising: Store local counters; In response to determining that vertical key derivation should be used to generate a key for encrypting and / or decrypting communication between the user equipment and the next-generation node (gNB), the local counter is updated according to a predetermined algorithm such that the local counter is aligned with the corresponding counter in the network node. The key generated using the vertical key derivation is generated at least in part based on the updated local counter.

14. The method of claim 13, further comprising: Store a second local counter. Updating the local counter according to the predetermined algorithm includes: incrementing the local counter based on the amount of the second local counter.

15. The method of claim 14, further comprising: Obtain an indication of whether the current handover is between cells associated with the same gNB or between cells associated with different gNBs; Obtain an indication of whether the previous handover was between cells associated with the same gNB or between cells associated with different gNBs; as well as The component that determines whether to use horizontal or vertical key derivation to generate the key is based on one or both of the following: the indication that the current handover is between cells associated with the same gNB or between cells associated with different gNBs, and the indication that the previous handover was between cells associated with the same gNB or between cells associated with different gNBs.

16. The method of claim 15, wherein determining whether to generate the key using horizontal key derivation or vertical key derivation comprises: When the current handover and the previous handover are handovers between cells associated with the same gNB, it is determined that the horizontal key derivation should be used.

17. The method of claim 15 or 16, wherein determining whether to generate the key using horizontal key derivation or vertical key derivation comprises: When the current handover is a handover between cells associated with the same gNB and the previous handover was a handover between cells associated with different gNBs, determining that vertical key derivation should be used, and further comprising: resetting the second local counter to zero in response to updating the local counter.

18. The method according to any one of claims 15 to 17, wherein: Determining whether to use horizontal or vertical key derivation to generate the key includes: when the current handover is between cells associated with different gNBs, determining that horizontal key derivation should be used; and The method further includes incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs.

19. The method according to any one of claims 13 to 18, further comprising providing the user equipment with an indication of the value of the local counter.

20. The method of claim 19, further comprising: Obtain the list of candidate cells; Perform a handover between cells associated with the current gNB; Indicates to one or more gNBs other than the current gNB that a handover between cells associated with the current gNB has occurred; For each cell in the candidate cell list, a key is generated using horizontal key derivation for use in cell handover events to that cell; as well as One or more generated keys are sent to each of the one or more gNBs other than the current gNB for use in a cell handover event to the cell associated with that gNB.

21. The method according to claim 19 or 20, further comprising: Obtain the list of candidate cells; Complete the handover from a cell associated with a different gNB to a cell associated with the current gNB; Indicates to one or more gNBs (other than the current gNB) associated with cells in the candidate cell list that a handover between cells associated with different gNBs has occurred; For each cell in the candidate cell list associated with a gNB other than the current gNB, a key is generated using horizontal key derivation for use in a cell handover event to that cell. as well as Send one or more generated keys to each of the one or more gNBs other than the current gNB for use in a cell handover event to the cell associated with that gNB.

22. The method according to any one of claims 19-21, further comprising: Store the current cell ID, which corresponds to the cell associated with the user equipment; Obtain the target cell ID corresponding to the target cell, and the user equipment shall be handed over from the current cell to the target cell; as well as Based on the target cell ID and the current cell ID, determine whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs.

23. The method according to any one of claims 13 to 18, further comprising: A key is generated using the determined key derivation, wherein if a vertical key derivation is selected, the generated key is at least partially based on the local counter.

24. The method of claim 23, further comprising: Store the current cell ID; Receive the target cell ID from the gNB; as well as Based on the target cell ID and the current cell ID, determine whether the handover from the current cell to the target cell is a handover between cells associated with the same gNB or a handover between cells associated with different gNBs.

Images